더 똑똑한 모델이 필요했던 게 아니라, 온보딩(Onboarding)이 필요했다

실제 티켓(Ticket) 작업 시 AI의 병목 현상이 지능 때문이 아닌 이유. 당신의 뇌는 예열된 상태로 시작하지만, 모델은 차가운 상태로 시작하기 때문입니다.

두 사람이 동일한 티켓을 받습니다. 한 명은 제로(Zero) 상태에서 시작합니다.

티켓이 저에게 전달되면, 제목을 다 읽기도 전에 제 뇌는 활성화됩니다. 이 서비스가 해당 로직을 담당하고 있군요. 경로는 아마 이쯤에 있을 겁니다. 저 컨트롤러(Controller)에는 새로운 메서드(Method)가 필요하고, 체인의 끝에는 제가 수정해야 할 DAO가 있겠네요. 제가 똑똑해서가 아닙니다. 그저 이 코드베이스(Codebase)에 충분히 오래 머물렀기에 머릿속에 이미 지도가 그려져 있는 것뿐입니다.

동일한 티켓을 AI에게 건네주면, AI는 빈 벽을 응시하고 있는 것과 같습니다. AI는 코드를 가지고 있습니다. 하지만 AI에게 없는 것은 지도입니다. 우리의 레이어(Layer), 명명 규칙(Naming), 혹은 우리가 지난주에 거의 동일한 것을 배포했다는 사실을 알지 못합니다. 같은 티켓, 같은 리포지토리(Repo)임에도 불구하고, 우리 중 한 명은 예열된 상태로 시작하고 다른 한 명은 차가운 상태로 시작합니다.

처음부터 그 사실을 이해했다고 말씀드리고 싶지만, 그렇지 않았습니다. 처음 우리 워크플로(Workflow)에 AI를 연결했을 때, 저는 대부분의 사람들이 가정하는 것처럼 생각했습니다. 모델이 스스로 코드베이스를 파악할 만큼 충분히 똑똑할 것이라고 말이죠. 리포지토리를 가리켜주고, 티켓을 주면, 유용한 결과물을 얻을 수 있을 것이라고 믿었습니다. 그 가정이 바로 제 코앞에서 터져버린 문제였으며, 그 난장판을 치우면서 저는 게임의 핵심이 지능이 아니라 컨텍스트(Context)라는 것을 배웠습니다.

처음에 제가 얼마나 순진했는지 말씀드리겠습니다. 몇 주 동안 모든 티켓은 똑같은 방식으로 시작되었습니다. Jira 티켓을 스크린샷 찍어 Claude에 붙여넣고, AI가 코드를 뒤지며 정보가 어디에 있는지 파악하는 동안 기다렸습니다. 그러고 나서 코딩을 시작했습니다. 제가 통합 레이어(Integration layer) 역할을 하고 있었던 것입니다. Jira에서 복사해서, Claude에 붙여넣고, 기다리고, 반복하기. 어느 시점부터 이것은 AI를 사용하는 느낌이 아니라, AI를 위해 내가 수행하는 잡무처럼 느껴지기 시작했습니다. 이 루프(Loop)는 다른 무언가가 실행해야 할 만큼 멍청한 작업이었습니다. 그래서 저는 그 '무언가'를 만들었습니다.

그래서 자동화를 시도했지만, AI는 자신 있게 틀린 답을 내놓았습니다

워크플로우 자체는 간단합니다. 티켓이 할당되고, 그에 맞춰 브랜치가 자동으로 생성되며, 에이전트가 해당 용도를 위해 따로 보관하는 폴더에 구현 계획을 작성합니다. 저희는 계획용, 기능 노트용, 팀원들이 계속 참고하는 자료를 위한 전용 폴더들을 갖추고 있습니다. 에이전트는 티켓을 읽고 코드를 검색한 다음, 계획을 남깁니다. 이 계획에는 작업 내용, 아마도 변경될 파일들, 진행 방법, 그리고 아직 불분명한 점들이 포함됩니다. 그런 다음 그 계획을 다시 티켓에 연결하여 누가 작업을 맡기기를 기다리게 합니다.

서류상으로는 제가 수동으로 하던 것과 정확히 같습니다. 하지만 실제로는 이 계획들이 엉망이었습니다.

영어가 틀린 정도의 엉망함이 아니었습니다. 자신감 있게 잘못된 수준의 엉망함이었습니다. 에이전트는 전체 리포지토리(repo)에 대한 읽기 권한과 검색 도구를 가지고 있었기 때문에, 여기저기를 뒤져 관련 있어 보이는 파일에 착륙하여 그 위에 계획을 세웠습니다. 이 계획들은 컨트롤러(controller)에 유효성 검사 로직을 넣었습니다. 데이터베이스 쿼리(database query)를 서비스 레이어(service layer)에 바로 넣기도 했습니다. 둘 다 저희가 구축하는 방식과는 거꾸로입니다. 저희에게 유효성 검사는 미들웨어(middleware)에 속하며, 모든 데이터베이스 호출은 DAO 레이어(DAO layer)에 존재해야 하며, 절대로 서비스 레이어에 있어서는 안 됩니다.

그래서 그 계획들은 자신이 무슨 말을 하는지 아는 것처럼 보였고, 개발자를 거절당하는 풀 리퀘스트(PR)로 곧장 이끌었습니다. 주니어 개발자가 이것을 믿는 상황을 상상해 보세요. 그들이 계획이 설명하는 코드를 작성하고, PR을 열었지만 리뷰에서 혹독하게 비판받은 다음, 'AI 계획' 때문에 잘못된 길로 안내되었다며 혼란스러워하는 모습을 말입니다.

게다가 속도 문제도 있었습니다. 실행할 때마다 에이전트는 어디서부터 시작해야 할지 아무것도 없기 때문에 아키텍처에 대한 그림을 처음부터 다시 그렸습니다. 이것이 바로 콜드 스타트(cold start) 문제입니다. 저는 실제 문제를 해결하지 않은 채 자동화만 했습니다. 제가 하던 잡무를 넘겨주고, 수동 버전의 가치를 만들었던 유일한 것을 버린 것입니다. 저는 이미 코드의 형태를 알고 있었지만, 에이전트는 몰랐고 저에게 그것을 알아낼 방법도 주지 않았습니다.

문제는 모델이 얼마나 똑똑하냐가 아니었습니다

저의 첫 번째 본능은 명백히 틀린 것이었습니다. '아마 더 나은 모델을 쓰면 해결될 거야'라고 생각했죠. 하지만 그렇지 않았습니다. 더 나은 모델이라 할지라도 우리 저장소(repo)에서 DAO가 데이터베이스에 접근할 수 있는 유일한 곳이라는 사실은 여전히 알지 못합니다. 그런 것은 가격 페이지에서 돈을 주고 살 수 있는 게 아닙니다. 그것은 지능의 문제가 아닙니다.

그때 비로소 깨달음이 왔습니다. 문제는 모델이 얼마나 똑똑하냐가 아니었습니다. 에이전트는 매번 아무런 정보 없이 차갑게(cold) 시작했고, 저는 이미 준비된 상태(warm)였습니다. 저는 정작 머릿속에 지도가 없어서 발생한 문제인데도 뇌(모델)를 업그레이드하려고만 했습니다. 그리고 그 지도는 아무도 작성해 둔 적이 없었습니다. 신입 사원도 첫날에 정확히 똑같은 벽에 부딪힐 것입니다. 차이점은 우리가 신입 사원에게 천재성을 기대하지 않는다는 점입니다. 우리는 그들에게 온보딩(Onboarding)을 해줄 것을 기대합니다.

그래서 저는 에이전트를 더 똑똑하게 만들려는 시도를 멈추고, 대신 온보딩을 시작했습니다. 신입 사원은 더 큰 뇌를 얻는 것이 아닙니다. 그들은 문서(docs)를 받고, 컨벤션(conventions)을 배우며, 누군가가 이전 사람의 작업물을 가리키며 "저렇게 하세요"라고 말해주는 과정을 거칩니다. 저도 똑같은 것을 만들었습니다. 다만 하나의 거대한 파일 대신 계층(layers) 구조로 만들었습니다.

상단에는 얇은 진입점(entry point)이 있습니다. 프로젝트의 기본 사항과 함께 "이런 종류의 작업이라면 저것을 읽어보세요"라고 안내하는 포인터(pointers)가 있습니다. 진짜 지식은 그곳에 있지 않습니다. 그 아래에는 아키텍처(architecture)가 평면적으로 명시된 핵심 컨벤션(core conventions) 문서가 자리 잡고 있습니다. 컨트롤러(Controllers)는 서비스(services)를 호출하고, 서비스는 DAO를 호출하며, DAO가 데이터베이스를 소유합니다. 검증(Validation)은 미들웨어(middleware)에서 이루어집니다. 명명 규칙(naming rules)과 우리가 깨뜨리지 않는 패턴(patterns)들이 정의되어 있습니다. 그다음에는 에이전트가 필요할 때만 여는 일련의 특화된 파일들이 있습니다. 온콜(on-call) 데이터베이스 작업을 위한 파일 하나, 데이터 모델(data model)을 위한 파일 하나, 번역(translations)을 위한 파일 하나가 있습니다. 에이전트는 매번 이 파일들을 읽지 않습니다. 티켓(ticket)이 실제로 해당 영역을 건드릴 때만 적절한 파일을 찾아 읽습니다.

그다음 저는 에이전트의 행동 지침(marching orders)을 다시 작성했습니다. 에이전트가 무언가를 검색하기 전에, 엔트리 포인트(entry point)와 핵심 문서(core doc)를 먼저 읽도록 했습니다. 우선 전체적인 구조를 파악하여 방향을 잡게 한 것입니다. 그러고 나서야 비로소 티켓(ticket)과 관련된 영역을 찾아보게 했습니다. 그리고 가장 큰 효과를 발휘한 지침은 가장 단순한 것이었습니다. '가장 유사한 기존 구현 사례를 찾아 그 패턴을 복사하라'는 것이었습니다. 이는 제가 신입 사원에게 첫날 그대로 말해주는 내용과 토씨 하나 틀리지 않고 같습니다. '새로운 방식을 발명하지 마세요. 우리가 이미 만들어 놓은 것 중 유사한 것을 찾아 그대로 따르세요.'

결과는 거의 즉각적으로 나타났습니다. 검증(Validation) 로직은 미들웨어(middleware)에 나타났고, 쿼리(Queries)는 DAO에 나타났습니다. 모델이 화요일과 수요일 사이에 더 똑똑해진 것이 아니었습니다. 저는 단지 제 머릿속에 담겨 있던 규칙들을 글로 적어 내려갔고, 에이전트가 무엇인가를 건드리기 전에 그 규칙들을 반드시 읽도록 강제했을 뿐입니다.

대부분의 사람들이 건너뛰는 부분은 그 이후의 단계입니다. 한 번 작성하고 잊어버리는 메모리 계층(memory layer)은 빠르게 부패합니다. 코드는 움직이고, 컨벤션(conventions)은 변하며, 그 문서들은 조용히 노후화되어 결국 에이전트가 몇 달 전에는 맞았지만 지금은 틀린 규칙을 따르게 됩니다. 그래서 우리는 유지보수(upkeep)를 워크플로우(workflow) 자체에 내재화했습니다. 에이전트가 새로운 것을 배우거나, 특정 영역의 작동 방식을 바꾸는 기능을 출시할 때, 메모리를 업데이트하는 것은 나중에 누군가 기억해서 해야 할 일이 아니라 업무의 일부가 되었습니다. 리포지토리(repo)가 스스로 문서를 최신 상태로 유지하는 것입니다. 사람이 작업하면서 멘탈 모델(mental model)을 업데이트하듯, 에이전트도 똑같은 방식으로 업데이트해야 하며, 그렇지 않으면 다시 자신만만하게 틀린 답을 내놓는 상태로 되돌아가게 됩니다.

그다음, 계획이 반박하기 시작했다

계획(plans)을 신뢰할 수 있게 되자, 제가 계획하지 않았던 부분이 오히려 가장 좋은 부분이 되었습니다. 계획 자체가 더 이상 가장 가치 있는 요소가 아니게 된 것입니다.

저는 에이전트가 계획을 작성한 후 스스로의 계획을 혹독하게 검증(grill)하는 단계를 추가했습니다. 에이전트는 마치 시니어 개발자가 디자인 리뷰(design review)를 하듯 자신이 작성한 내용을 되짚어 봅니다. 모호한 부분은 어디인가? 어떤 엣지 케이스(edge case)가 누락되었는가? 코드를 한 줄이라도 쓰기 전에 실제 답변이 필요한 가설은 무엇인가? 에이전트는 이러한 질문들을 적어 내려가고, 각 질문 옆에 스스로 권장하는 답변을 함께 작성합니다.

그리고 에이전트는 원칙을 고수합니다. 제가 실제로 티켓(ticket)을 구현하기 위해 돌아왔을 때, 에이전트는 제가 그냥 진행하라고 말하더라도 그 질문들에 대한 답변이 완료될 때까지 코드를 작성하기 시작하지 않습니다. 에이전트는 제가 평소에 건너뛰었다가 나중에 반쯤 완성된 기능과 엉망인 PR(Pull Request)로 대가를 치르게 되는 바로 그 디자인 논의(design conversation)를 전면으로 끌어올립니다.

결과적으로 출력물의 수준이 성장했습니다. 그것은 단순한 "계획"에서 "단 한 줄의 코드도 존재하기 전의 강제된 디자인 논의"로 변했습니다. 가치는 정답이 아니라 질문으로 옮겨갔습니다. 이것이 현재 제가 지키기 위해 가장 치열하게 싸울 부분이며, 동시에 제가 처음부터 만들려고 의도했던 것이 아닌 부분입니다.

QA에게 실제로 무엇이 배포되었는지 알려주기

이 방식이 조용히 결실을 맺는 또 다른 지점은 코드가 완료된 후, 즉 배포(deploy) 시점입니다.

티켓 하나가 첫 시도에 깔끔하게 배포되는 경우는 거의 없습니다. 배포되면 QA가 무언가를 발견하고, 다시 돌아오고, 패치(patch)를 거쳐 다시 배포됩니다. 단 하나의 티켓이 이러한 과정을 여러 차례 반복할 수 있습니다. 지저분한 현실은, 몇 번의 배포가 지나고 나면 아무도 방금 무엇이 나갔는지 완전히 확신하지 못한다는 것입니다. QA는 티켓을 열어보지만, 이번 릴리스(release)에서 어떤 사항들이 처리되었고 어떤 것들이 여전히 열려 있는지 알 수 없습니다. 그래서 그들은 전체를 다시 테스트하거나, 잘못된 부분을 다시 테스트하여 실제로 변경된 부분을 놓치기도 합니다.

이제 배포가 이루어지면, 에이전트가 배포 내용에 무엇이 포함되었는지 읽고 해당 티켓에 요약을 남깁니다. "무엇이 배포되었습니다. 티켓의 이 항목들은 완료되었습니다. 이 항목들은 아직 완료되지 않았습니다." QA는 추측하는 대신 무엇을 확인해야 할지 알고 티켓을 엽니다. 작은 변화이지만, 이는 실제로 반복되는 혼란의 근원을 제거하며, 매 릴리스마다 아무도 수동으로 작성하고 싶어 하지 않는 바로 그 접착제(glue) 역할을 합니다.

그것이 바로 실제 관통하는 핵심(throughline)입니다. 이 모든 과정은 "AI가 내 코드를 작성한다"는 것이 아닙니다. 이미 사용 중인 도구들 사이, 즉 티켓(ticket)과 코드베이스(codebase), 배포(deploy), 그리고 QA 패스(QA pass) 사이의 간극에 AI가 자리 잡고, 예전에는 제가 직접 짊어져야 했던 컨텍스트(context)를 대신 옮겨주는 것입니다.

무엇이 변했는가, 그리고 무엇을 건너뛰는가

이것은 스탠드업(standup) 미팅을 위해 한 번 만들어 스크린샷을 찍어둔 데모가 아닙니다. 우리는 실제로 이것을 사용합니다.

진정한 변화는 AI가 무엇을 내뱉느냐가 아니라, 제가 어떻게 일하느냐에 있습니다. 이제 저는 동시에 서너 개의 티켓을 처리합니다. 각 티켓은 이미 브랜치(branch)가 생성되어 있고 컨텍스트가 로드된 상태로 나타나기 때문에, 매번 발생하는 콜드 스타트 비용(cold-start tax)을 지불할 필요가 없습니다. "이게 뭐지, 어디에 있지, 여기서는 어떻게 하지"와 같은 그 비용이야말로, 예전에 저를 한 번에 하나의 티켓에만 매여 있게 만들었던 바로 그 요소였습니다.

제 역할을 다하지 못하는 부분에 대해서도 솔직하게 말씀드리겠습니다. 작은 티켓의 경우, 저는 계획(plan)을 무시하고 그냥 바로 작업을 수행합니다. 그게 더 빠릅니다. 파이프라인(pipeline)이 신성불가침한 것은 아니며, 모든 아주 작은 티켓을 파이프라인에 밀어 넣는 것 자체가 일종의 낭비가 될 수 있기 때문입니다.

진행 과정에서 더 어리석은 고충도 있었습니다. 처음에는 만료되는 액세스 토큰(access token)을 발급하는 계획으로 시작해서, 누군가 수동으로 새로운 시크릿(secret)을 다시 붙여넣을 때까지 한동안 전체 시스템이 계속 죽어버리는 일이 반복되었습니다. 아주 최첨단스러운 일이었죠. 제대로 된 키(key)로 교체한 후에는 더 이상 문제를 일으키지 않았습니다. 아직 몇 가지 거친 부분들은 남아 있습니다. 에이전트(agent)는 주로 이름을 검색하여 파일을 찾는데, 이는 "addInvoice가 어디 있지" 같은 질문에는 훌륭하지만 "오프라인 결제는 어디서 처리하지" 같은 질문에는 무용지물입니다. 따라서 더 똑똑한 검색 단계(search step)를 도입하는 것이 명백한 다음 단계입니다. 그리고 저는 계획이 정말 좋은지 아직 측정하지 않고 있습니다. 신호(signal)는 바로 눈앞에 있는데 말이죠. 머지된 PR(merged PR)이 실제로 변경한 파일과 계획이 변경하겠다고 말한 파일을 비교해 보는 것입니다. 현재로서는 "도움이 된다"는 것이 숫자가 아닌 느낌에 불과합니다. 그 점이 저를 괴롭힙니다.

요점

모델이 병목(bottleneck)이었던 적은 없었습니다. 컨텍스트(context)가 병목이었습니다.

더 큰 모델을 찾는 것으로는 이 중 그 어떤 것도 개선하지 못했습니다. 제가 개선한 방법은 신입 사원에게 말해줄 법한 내용들을 글로 적는 것이었습니다. 검증(validation)이 어디서 이루어지는지, 데이터베이스 호출(database calls)이 어디에 있는지 말입니다. '우리가 이미 만들어 놓은 가장 유사한 것을 복사해서 사용하세요'라고 말이죠. 그러고 나서 에이전트(agent)가 코드에 손을 대기 전에 그 모든 내용을 읽도록 강제했고, 코드가 계속 변하더라도 그 노트들을 최신 상태로 유지했습니다. 지루한 해결책이 흥미로운 해결책을 이겼고, 계속해서 이겨왔습니다.

AI가 차가운 상태(cold start)가 아닌 따뜻하게 예열된 상태(warm start)로 시작하게 되자, 계획 자체가 핵심이 아니게 되었습니다. 모든 티켓(ticket)은 컨텍스트(context)가 이미 로드된 상태로 전달되며, 덕분에 저는 티켓들을 하나씩 힘들게 처리하는 대신 네 개 정도를 동시에 처리할 수 있게 되었습니다.

그러니 직장에서 이 작업을 시작하려 한다면, 모델부터 시작하지 마세요. 당신의 뇌가 묻지 않아도 스스로 로드하는 컨텍스트, 즉 이미 알고 있어서 굳이 적을 필요가 없었던 것들부터 시작하세요. 그것이 바로 AI에게 결여된 부분입니다. 나머지는 배관(plumbing) 작업일 뿐입니다.