코덱스로 5년 일을 2주에 끝낸 아사나

협업 도구로 잘 알려진 미국 소프트웨어 기업 아사나(Asana)가 사내에서 "최소 5년"으로 잡아뒀던 개발 과제를 2주 만에 끝냈다는 사례가 공개됐다. 오픈AI가 자사 코딩 에이전트 코덱스(Codex)의 도입 사례로 소개한 내용인데, 흥미로운 건 시간만 줄어든 게 아니라는 점이다. 원래 견적은 약 600만 달러였고, 실제로 쓴 돈은 모델과 인프라 비용을 합쳐 약 1만 2천 달러였다.
개발 현장에서 오랫동안 "언젠가는 해야 하지만 아무도 손대지 않는 일"로 남아 있던 작업의 성격을 생각하면, 이 숫자는 단순한 속도 자랑 이상의 의미를 갖는다.

AI 코딩 도구가 자동완성 수준을 넘어섰다는 이야기는 2025년부터 계속 나왔다.
다만 대부분은 "새 기능을 빨리 만든다"는 쪽이었다. 이번 사례가 눈길을 끄는 이유는 방향이 반대이기 때문이다.
새로 짓는 게 아니라, 이미 쌓여 있는 낡은 코드를 걷어내는 일에 에이전트를 투입했다.
그리고 그 일은 인간 개발자들이 가장 미루고 싶어 하는 종류의 작업이다.

5년·600만 달러 계획이 2주·1만 2천 달러로 바뀐 이유

아사나가 걷어낸 대상은 엔자임(Enzyme)이라는 프런트엔드 테스트 도구다.
리액트(React)로 만든 화면이 의도대로 동작하는지 검사하는 데 오래 쓰였던 라이브러리인데, 몇 년 전부터 활발한 유지보수가 사실상 끊겼다. 문제는 도구가 낡았다는 데서 끝나지 않았다. 엔자임에 묶인 테스트 코드가 수년치로 누적되면서, 리액트 버전을 올리거나 프런트엔드 구조를 현대화하려는 시도 자체를 막는 걸림돌이 된 것이다.
개발자들이 흔히 말하는 '기술 부채', 그중에서도 이자가 계속 붙는 종류의 부채였다.

이런 작업이 왜 5년이라는 견적을 받았는지는 조금만 들여다보면 이해가 된다.
테스트 코드 하나를 새 도구 방식으로 바꾸는 일 자체는 어렵지 않다. 대신 그 하나가 수천 개, 수만 개로 늘어나고, 각각이 조금씩 다른 방식으로 작성돼 있으며, 잘못 바꾸면 원래 잡아내야 할 버그를 못 잡는 '조용한 실패'가 생긴다.
그래서 대부분의 회사는 이 일을 한 번에 끝내지 못한다. 새 코드는 새 도구로 쓰고, 옛 코드는 건드리지 않은 채 "여유가 생기면 하자"며 몇 년을 흘려보낸다. 아사나의 5년짜리 계획도 그런 현실적인 판단의 결과였다.

공개된 수치를 정리하면 차이가 선명해진다.

• 기존 계획 — 최소 5년, 비용 추정 약 600만 달러(1달러 1,400원 기준 약 84억 원)
• 실제 결과 — 달력 기준 2주, 엔지니어 실투입 약 1.5주, 모델·인프라 비용 약 1만 2천 달러(약 1,700만 원)
• 비용 비율 — 600만 달러 대비 1만 2천 달러, 약 500분의 1 수준

물론 이 비교를 그대로 받아들이는 데는 조건이 붙는다. 600만 달러라는 견적은 '엔지니어 몇 명이 몇 년간 이 일에 붙는다'는 인건비 환산치이고, 그 5년 동안 그 인력이 아무 일도 못 한다는 뜻은 아니다.
반대로 1만 2천 달러에는 진행 상황을 확인하고 변경 사항을 검토한 엔지니어의 시간이 온전히 반영돼 있지 않다.
그래도 보수적으로 깎아서 읽어도 자릿수가 두세 개 차이 난다는 사실은 남는다.
그동안 "비용 대비 효과가 안 나온다"는 이유로 영구 보류됐던 작업들의 계산식이 바뀌는 지점이다.

모든 수년짜리 프로젝트가 몇 주로 줄어들지는 않을 것이다. 하지만 에이전트는 엔지니어에게 장인정신을 발휘할 여유를 주고, 한때 불가능해 보였던 일을 시도할 만한 일로 바꿔놓는다. — 암리탄시 라가브(Amritansh Raghav), 아사나 CTO

 

다섯 문장 프롬프트와 병렬로 돌아간 에이전트 네 대

구체적인 진행 방식은 생각보다 단순하다. 아사나 엔지니어들은 정교한 자동화 파이프라인을 짜지 않았다.
시작점은 다섯 문장 분량의 프롬프트 하나였다. 여기서 최대 네 대의 코딩 에이전트가 동시에 돌아갔고, 각 에이전트는 코드베이스 사본을 따로 하나씩 받아 서로 간섭하지 않는 상태에서 작업했다. 여러 에이전트를 한 저장소에 붙이면 서로의 변경을 덮어쓰며 충돌이 나는데, 사본을 분리하는 방식으로 그 문제를 피한 것이다.

사람이 빠진 것도 아니다. 담당 엔지니어는 하루 두 번 진행 상황을 확인했고, 에이전트가 제안한 변경 사항은 전부 사람이 검토했다.
하루 두 번이라는 간격이 인상적인데, 이는 에이전트가 그 사이에 스스로 판단하며 상당량을 처리할 수 있다는 뜻이기도 하고, 반대로 리뷰 없이 병합되는 코드는 없었다는 뜻이기도 하다. 자율성과 통제를 동시에 유지한 셈이다.

또 하나 눈여겨볼 교훈은 "복잡하게 세팅하지 않는 게 더 잘 통했다"는 대목이다.
정교한 규칙과 단계별 지시를 잔뜩 붙이는 대신, 목표를 짧고 명확하게 준 쪽이 결과가 좋았다는 것이다.
최근 코딩 에이전트를 실무에 붙여본 개발자들 사이에서 반복적으로 나오는 이야기와도 겹친다.
지시를 지나치게 세분화하면 모델이 스스로 더 나은 경로를 찾을 여지를 막고, 예외 상황마다 사람이 규칙을 덧붙여야 하는 유지보수 부담만 늘어난다.

정리하면 이번 사례의 성공 조건은 세 가지로 압축된다.

• 병렬화 — 작업을 독립된 단위로 쪼갤 수 있어서 에이전트 여러 대를 동시에 붙일 수 있었다
• 격리 — 각 에이전트에게 별도 작업 공간을 주어 충돌과 되돌리기 비용을 없앴다
• 사람의 검토 — 자동 병합 대신 전량 리뷰로 품질 게이트를 유지했다

---

왜 하필 테스트 코드가 첫 전장이 됐을까

에이전트에게 맡길 일을 고를 때 가장 중요한 기준은 난이도가 아니라 검증 가능성이다.
테스트 코드 마이그레이션은 이 기준에서 거의 이상적인 과제다. 바꾼 결과가 맞는지 사람이 눈으로 일일이 판단할 필요 없이, 테스트를 실행해 통과 여부로 즉시 확인할 수 있다. 에이전트가 스스로 실행하고, 실패하면 원인을 읽고, 다시 고치는 순환이 성립한다.
반대로 "사용자가 이 화면을 더 좋아할까" 같은 판단이 필요한 일에서는 이 순환이 만들어지지 않는다.

이런 성격 때문에 대규모 테스트 전환은 AI 활용 사례가 일찍부터 축적된 분야이기도 하다.
에어비앤비는 대규모 테스트 마이그레이션에 대형 언어 모델을 투입한 과정을 엔지니어링 블로그로 공개했고, 허브스팟 역시 엔자임에서 리액트 테스팅 라이브러리로 옮긴 경험을 정리해 공유했다.
개별 개발자들이 수천 개 규모의 리액트 테스트를 AI 에이전트와 구문 분석 도구를 조합해 옮긴 기록도 어렵지 않게 찾을 수 있다.
아사나 사례는 그 계보 위에 있으면서, 규모와 비용 절감 폭에서 한 단계 위를 보여준 경우다.

그래서 이 사례를 자기 조직에 적용하려면 질문을 바꿔야 한다. "우리도 AI로 개발 속도를 5배 올릴 수 있나"가 아니라, "우리 조직에 쌓여 있는 일 중에서 정답 판정이 자동으로 되는 반복 작업이 무엇인가"를 먼저 찾는 것이다.
오래된 라이브러리 제거, 폐기 예정 API 호출 정리, 코딩 규칙 일괄 적용, 반복되는 설정 파일 정비, 타입 정의 보강 같은 일들이 후보가 된다. 하나같이 중요하지만 우선순위 회의에서 늘 밀려나던 항목들이다.

주의할 점도 분명하다. 테스트를 형식만 새 도구 문법으로 바꿔놓고 실제 검증 강도는 떨어뜨리는 변환이 섞여 들어올 수 있다.
통과하는 테스트가 곧 좋은 테스트는 아니기 때문이다. 아사나가 모든 변경을 사람이 검토했다고 강조한 이유가 여기에 있다고 보는 편이 자연스럽다. 에이전트를 늘리는 순간 병목은 코드 작성이 아니라 리뷰로 이동한다.

 

200% 향상과 19% 지연, 숫자는 아직 싸우고 있다

이런 사례가 나올 때마다 따라붙는 반론이 있다. AI 코딩 도구가 실제로 개발자를 더 빠르게 만드는지에 대한 측정 결과가 아직 엇갈린다는 것이다. 한 무작위 대조 실험에서는 AI를 쓴 개발자가 55.8% 빨랐다는 결과가 나왔지만, 연구기관 METR의 실험에서는 오히려 19% 느렸다는 반대 결과가 나왔다. 숙련된 개발자가 자기가 잘 아는 코드베이스에서 작업할 때, AI 제안을 읽고 검증하는 시간이 직접 쓰는 시간보다 더 들었다는 해석이었다. 더 흥미로운 건 참가자들이 스스로는 "빨라졌다"고 느꼈다는 점이다.

다만 그 연구도 지금은 다르게 읽힌다. METR는 2026년 2월 자사 2025년 결과에 현재 상황을 반영하지 않는다는 취지의 경고를 덧붙였고, 같은 실험을 다시 하려 했지만 개발자들이 "AI 없이 일하고 싶지 않다"며 참여를 꺼려 계획을 바꿔야 했다.
결국 5월에는 실험 대신 기술직 종사자 설문으로 방향을 틀었고, 응답자들은 AI 덕분에 조직에서 자신의 가치가 두 배가 됐다고 인식했다. 1년 사이 도구의 성능과 사용자의 숙련도가 함께 변했다는 뜻이다.

같은 도구를 같은 사람이 써도 1년 전과 지금의 결과가 다르다. AI 생산성 논쟁에서 가장 자주 빠지는 변수는 모델의 성능이 아니라, 그 도구를 다루는 사람의 숙련도다.

업계 쪽 수치는 훨씬 낙관적이다. 생성형 AI 단계에서 개발자 생산성이 30% 올랐다면 에이전트 단계에서는 200%까지 올랐다는 컨설팅 분석이 돌아다니고, 구글은 사내 코딩 작업의 75%가 AI에 의해 이뤄진다는 수치를 내놨다.
앤트로픽이 공개한 MCP는 월 9,700만 건대 다운로드로 사실상 표준 자리를 굳혔고, 구글의 A2A 프로토콜도 100곳 넘는 기업이 채택했다. 도구와 규격이 빠르게 자리를 잡는 국면인 것은 분명하다. 다만 이 수치들은 대개 도구를 파는 쪽에서 나온다는 점을 감안해서 읽는 게 좋다.

두 진영의 숫자를 함께 놓고 보면 결론은 의외로 단순하다. 에이전트는 모든 개발을 균일하게 빠르게 만드는 도구가 아니다.
판정이 자동화되고 병렬로 쪼갤 수 있으며 사람이 하기 싫어하는 대량 반복 작업에서는 자릿수 단위의 차이를 내고, 맥락과 판단이 얽힌 설계 작업에서는 오히려 검증 비용이 붙는다. 아사나가 고른 과제가 정확히 전자였다. 그래서 이 사례의 교훈은 "에이전트를 도입하라"가 아니라 "에이전트에게 맞는 일을 먼저 찾아라"에 가깝다.

---

아사나 CTO의 말처럼, 모든 5년짜리 계획이 2주로 접히지는 않을 것이다.
그러나 계산식이 바뀌면 후보 목록이 바뀐다. 지금까지 "해야 하지만 비용이 안 맞는다"는 이유로 영구 보류 상태였던 항목들, 즉 각 조직의 오래된 기술 부채 목록이 다시 검토 대상에 오른다는 뜻이다.
개인 개발자 입장에서도 같은 질문이 유효하다. 내가 미뤄둔 리팩터링이나 테스트 보강 중에 지금 기준으로는 하루짜리 일이 된 것이 없는지 한 번쯤 확인해볼 만하다.