AI가 개발자를 대체할 것인가에 대한 모든 논쟁은 동일한 지점에 집중됩니다. 바로 모델이 코드를 작성할 수 있는가 하는 점입니다. 하지만 이는 잘못된 질문입니다. 왜냐하면 소프트웨어 출시를 느리게 만들었던 것은 코드의 초안을 작성하는 작업이 아니었기 때문입니다.

출시를 느리게 만드는 것은 코드 주변의 모든 것입니다. 코드를 리뷰하는 것, 문서화하는 것, 계정·데이터베이스·API 및 결제 시스템을 다섯 번째로 다시 구축하는 것, 지난 네 개와 똑같이 생긴 또 다른 고객 포털을 만드는 것, 그리고 처리되는 데이터 때문에 모델을 자체 하드웨어에서 실행해야 하는지 결정하는 것 등이 그것입니다.

이것이야말로 현재 에이전트(Agent)들이 진정으로 잘하는 작업이며, 편리하게도 아무도 하고 싶어 하지 않았던 작업이기도 합니다.

병목 현상은 결코 코드를 작성하는 것이 아니었다

혼자서 제품을 출시해 본 사람에게 시간이 실제로 어디에 쓰였는지 물어보십시오. 기능 구현 작업인 경우는 드뭅니다. 3일 동안 방치된 풀 리퀘스트 (Pull Request), 6번의 커밋 전부터 동기화가 어긋나기 시작한 문서, 이전 프레임워크와 달라서 처음부터 다시 구축해야 했던 인증 (Auth) 흐름 등이 대부분입니다.

이 중 그 어떤 것도 지적으로 어려운 작업이 아닙니다. 이는 범위가 정해져 있고, 반복적이며, 검증 가능합니다. 이는 정확히 에이전트에게 맡기고 나중에 검증할 수 있는 작업의 특성입니다. 데이터 모델, 아키텍처 (Architecture), 무엇을 구축하지 않을 것인지와 같이 진정으로 판단이 필요한 부분은 여전히 당신의 몫으로 남습니다.

코딩 에이전트로부터 실질적인 가치를 얻고 있는 팀들은 제품 전체를 요구하지 않습니다. 그들은 결코 흥미롭지 않았던 부분들을 에이전트에게 넘겨주고 있습니다.

코딩 에이전트가 실제로 제 역할을 하는 곳

수익률(Payoff)이 높은 순서대로 세 가지 영역이 있습니다.

첫 번째는 코드 리뷰 (Code review)입니다. 실제 프로젝트를 바탕으로 모든 풀 리퀘스트 (Pull Request)를 검토하는 에이전트는 지루한 유형의 버그를 일관되게 잡아내며, 금요일 오후 6시라고 해서 지치지도 않습니다. 아키텍처에 대한 시니어 리뷰어를 대체하지는 못하겠지만, 시니어 리뷰어가 시간을 소비하는 대부분의 작업을 제거해 줄 것입니다.

문서화 (Documentation)는 두 번째이며, 아무도 좋아하지 않기 때문에 과소평가되어 있습니다. 소스 코드로부터 생성된 문서는 소스와 발맞추어 유지됩니다. 수기로 작성된 문서의 실패 모드 (failure mode)는 문서 자체가 나쁘다는 것이 아니라, 9개월 전에는 정확했으나 더 이상 정확하지 않게 되었을 때 아무도 이를 알아차리지 못한다는 점입니다.

위임된 기능 작업 (Delegated feature work)은 세 번째입니다. 이 방식은 작업이 잘 정의되어 있고 에이전트 (agent)가 테스트를 실행할 수 있을 때 효과적입니다. 이 두 가지 중 어느 것도 충족되지 않을 때 실패하며, 사람들이 이 방식에 대해 불만을 갖는 대부분의 경우가 바로 이때입니다.

패턴을 살펴보면, 에이전트는 빠르고 정직한 피드백 신호 (feedback signal)가 있는 곳 어디에서나 잘 작동합니다. 에이전트에게 실행 가능한 테스트 스위트 (test suite)를 제공하면 수렴 (converge)합니다. 그것을 제거하면 에이전트는 자신만만하게 추측할 뿐입니다.

SaaS의 지루한 부분들

모든 MVP (Minimum Viable Product)에는 동일한 스캐폴딩 (scaffolding)이 필요합니다. 사용자 계정, 데이터베이스 (database), API, 결제 (billing), 대시보드 (dashboard), 그리고 고객이 로그인하여 자신의 데이터를 볼 수 있는 방법 등이 그것입니다.

이 부분은 사이드 프로젝트를 조용히 죽게 만드는 요인인데, 사용자가 '기능'이라고 부를 만한 것을 전혀 만들어내지 못하면서도 몇 주간의 작업 시간을 잡아먹기 때문입니다. 또한 이 부분은 거의 완전히 해결된 문제입니다. 이를 다섯 번째로 직접 만드는 것은 선택의 문제이지, 필수 사항이 아닙니다.

고객 포털 (Customer portals)도 마찬가지입니다. 브랜드 로고가 적용된 로그인, 대시보드, 데이터베이스 기반 페이지, 웹훅 (webhook) API 등이 필요합니다. 제품 간에 요구 사항이 거의 변하지 않으며, 바로 그렇기 때문에 매번 당신의 인생에서 한 달을 소비해서는 안 됩니다.

셀프 호스팅 (Self-Hosting)이 가치 있는 경우

자체 모델을 실행하는 것은 세 가지 상황에서는 가치가 있지만, 그 외의 모든 상황에서는 주의를 분산시키는 요소입니다.

데이터가 법적으로 귀하의 인프라를 떠날 수 없는 경우에 가치가 있습니다. 워크로드 (workload)가 대량이며 예측 가능한 경우에도 가치가 있는데, 그 시점부터는 토큰당 비용 계산 (per-token math)이 API를 사용하는 것보다 유리해지기 때문입니다. 마지막으로, 동작이 고정되어 있어야 하는 경우에도 가치가 있습니다. 조용히 개선되는 호스팅 모델은 조용히 귀하의 출력값을 변화시키는 호스팅 모델이기 때문입니다.

만약 위의 어떤 경우에도 해당하지 않는다면, 셀프 호스팅 (self-hosting)은 제품이 아닌 인프라에 한 달을 소비하게 만드는 방법이 되기 일쑤입니다. 이 조언의 솔직한 버전은, 대부분의 프로젝트는 API를 기반으로 시작해야 하며, 운영 비용을 정당화할 수 있을 만큼 트래픽 규모가 실제로 커졌을 때 나중에 이전해야 한다는 것입니다.

핵심 요약 (The Takeaway)

유용한 프레임워크는 에이전트 (agent)가 코드를 작성할 수 있느냐가 아닙니다. 귀하의 프로세스 중 어떤 부분이 명확한 완료 정의 (definition of done)를 가지고 있으며, 이를 확인할 방법이 있느냐 하는 것입니다.

리뷰 (review), 문서화 (docs), 테스트 (tests), 스캐폴딩 (scaffolding), 그리고 다섯 번째로 반복되는 동일한 결제 연동 (billing integration) 등은 모두 이에 해당합니다. 반면 아키텍처 (architecture), 제품 결정 (product decisions), 그리고 무엇을 만들지 말아야 할지 아는 것은 해당하지 않으며, 아마 당분간은 계속 그러할 것입니다.

첫 번째 범주를 넘겨주고 두 번째 범주를 유지한다면, 한 사람이 출시할 수 있는 소프트웨어의 양은 상당히 달라집니다.

이러한 각 요소에 대한 가이드, 즉 코딩 에이전트 (coding agents), 자동화된 코드 리뷰 (automated code review), 기술 문서화 (technical documentation), SaaS 구축, 고객 포털 (customer portals) 및 셀프 호스팅 AI (self-hosted AI)는 여기에서 확인할 수 있습니다: https://www.aiappsapi.com/ai-development/