AI 개발 도구를 네 번 바꾸고도 남은 것

대딸깍 시대가 왔지만 의도가 엉성하면 결과도 엉성하게 나옵니다. 도구를 네 번 바꾸고도 남은 것은 상위 설계였습니다.

구현 요령보다 먼저 꺼낸 이야기

사내 학습 모임의 첫 순서를 맡아 제가 AI로 개발해 온 방식을 이야기했습니다. 정답을 가르치는 자리가 아니라, 개발자 한 명이 지나온 경로를 보여주는 자리였습니다.

구현과 검증, 테스트에 어떤 도구를 쓰는지는 개인화 영역이라고 선을 그었습니다. 예전부터 개발자는 VS Code와 IntelliJ와 Eclipse 중 하나를 골랐고, 저마다 다른 플러그인을 썼습니다. AI 도구도 무엇이 더 좋은지를 따지기 시작하면 비슷한 이야기로 흐릅니다.

제가 다루고 싶었던 것은 기능 요구를 받은 다음입니다. 그 요구를 어떻게 상세화하고, 무엇부터 확인하고, 어디서 결정을 내리는지에 관한 이야기였습니다. 이 과정을 더 수월하게 만들려고 도구를 바꿔 왔습니다. M365 Copilot에 묻던 때부터 CLI/TUI, ADE, Bot 체계까지 네 번 옮겼습니다. 각 단계마다 좋아진 것이 있었고, 그만큼 안 풀린 것이 남았습니다.

M365 Copilot에 묻던 때

처음 M365 Copilot을 제대로 쓴 일은 Terraform 코드 구현이었습니다. 개발 경험은 있었지만 IaC는 해보지 않은 영역이었습니다. Terraform 문법부터 구성 요소까지 차례대로 익히기에는 시간이 부족했습니다. 개념을 익히면서 코드를 만들어 내는 데 Copilot을 썼습니다.

모르는 영역에 들어갈 수 있다는 것 자체가 새로웠습니다. 이전이라면 학습에 들어갈 시간을 마련하지 못해 시작하지 못했을 일을 해볼 수 있었습니다.

대신 작업 방식은 거칠었습니다. 웹 채팅에서 답을 받고, 코드를 복사해서 작업하던 곳에 붙여 넣었습니다. 실행되지 않으면 오류를 다시 가져가 물었습니다. 대화가 길어지면 새 창에서 처음부터 시작했습니다. 환각도 많았습니다. 시간을 아꼈다는 느낌은 거의 없었지만, 막혀 있던 문제는 조금씩 풀렸습니다.

이때 맥락은 작업하는 곳에 없었습니다. 매번 제가 설명했고, 답도 제가 옮겼습니다.

CLI와 TUI 안에 맥락을 모으던 때

CLI와 TUI 기반 도구로 옮기면서 MCP를 제대로 쓰기 시작했습니다. AI가 파일 몇 개를 읽는 수준을 넘어 작업 환경에 직접 닿았습니다. 프롬프트를 잘 쓰는 법보다 필요한 맥락을 어떻게 구성할지가 중요해졌고, AGENTS.md와 CLAUDE.md 같은 파일도 작업의 일부가 됐습니다.

메인 context를 오래 유지하려고 MCP와 에이전트를 나눴습니다. tmux 화면 안에서 지시하는 에이전트와 일하는 에이전트를 따로 띄웠고, Claude Teammate도 썼습니다. 다른 AI 도구를 headless 모드로 불러 서로 다른 답을 받아 보기도 했습니다.

그런데 에이전트를 늘릴수록 context 사용량은 더 커졌습니다. 새 에이전트는 앞에서 무슨 일이 있었는지 몰랐습니다. 일을 시작할 때마다 도구와 배경을 다시 건네야 했고, 그 에이전트가 상황을 파악하는 데도 비용이 들었습니다. 여러 에이전트가 동시에 움직이는 모습은 빨라 보였지만 마지막 결과가 그만큼 나아졌는지는 알기 어려웠습니다.

한 화면에 여러 세션을 모아도 맥락은 각 세션 안에 갇혀 있었습니다.

ADE가 터미널 사이를 잇던 때

다음에는 Orca 같은 ADE 체계로 옮겼습니다. 여기서 눈에 들어온 것은 편집 화면보다 pty를 다루는 방식이었습니다. 런타임이 각 터미널의 pty를 쥐고, 다른 쪽은 핸들을 통해 입력을 넣거나 출력을 읽습니다. 에이전트가 대화로 모든 내용을 다시 전달하지 않아도 터미널끼리 일을 이어 줄 수 있었습니다.

사람이 화면 앞에 앉아 명령을 옮기지 않아도 됐고, 에이전트 사이의 전달에 쓰이던 AI 비용도 줄었습니다. CLI/TUI 단계에서 막혔던 터미널 사이의 연결을 프로그램이 맡은 셈입니다.

하지만 작업이 끝난 뒤에는 다시 문제가 생겼습니다. 일주일 전에 한 작업을 이어가려면 지난 세션을 다시 열거나, 남겨 둔 문서를 읽혀야 했습니다. 프로젝트 경로마다 비슷한 설정을 만들고 같은 설명을 반복했습니다. context 안에서 일을 이어가는 문제는 나아졌지만, 세션과 프로젝트의 경계는 그대로였습니다.

문서로 남기는 것만으로도 부족했습니다. 새 세션이 그 문서를 읽고 다시 상황을 파악하는 순간부터 또 비용이 들었습니다. 저는 context를 관리하는 데서 더 나아가 세션 자체를 관리하고 싶어졌습니다.

Bot에게 역할과 기록을 맡긴 때

Bot 체계에서는 프로젝트마다 한 에이전트를 두는 대신 역할자를 나눴습니다. 사용자 요청을 받고 일을 분배하는 역할, 구조를 설계하는 역할, 구현하고 테스트하는 역할, 결과를 문서로 남기는 역할을 따로 뒀습니다. 각 역할자는 여러 프로젝트를 오가며 그곳의 AGENTS.md나 CLAUDE.md를 읽고 일합니다.

세션도 기록으로 남기게 했습니다. 작업에서 나온 내용은 별도 위키에 쌓이고, 다음 작업은 그 기록을 읽은 상태에서 출발합니다. 어느 한 세션이나 프로젝트 폴더에만 있던 맥락을 밖으로 꺼낸 것입니다. 여러 장치에서 시작한 작업도 한곳에 모이도록 구성했습니다.

역할자를 나누고 칸반 상태로 일을 넘기는 구현은 이미 두 글에 적었습니다. 한 명이던 AI 에이전트를 넷으로 나눈 이유와 Hermes 에이전트들은 대화가 아니라 칸반 상태로 일을 넘긴다에서 그 구조를 볼 수 있습니다.

이 체계도 완성된 답은 아니었습니다. 기록이 늘면 무엇을 남기고 다시 꺼낼지 관리해야 합니다. 역할자마다 다른 의견을 내면 사람이 조정해야 합니다. 여러 장치에서 작업이 이어진다는 것은 언제 어디서든 일이 이어진다는 뜻이기도 했습니다.

네 번 바꾸고 나서

돌아보면 도구를 옮긴 계기는 매번 불만이었습니다. M365 Copilot에서는 환각 때문에 속이 터졌고, ADE에서 터미널 사이가 이어진 뒤에도 지난 세션을 이어받지 못하는 것이 불만이었습니다. 남긴 문서를 다시 읽히는 과정마저 짜증스러웠습니다. 불만이 생기면 다음 방식을 찾았고, 그렇게 매번 묻던 쪽에서 역할자와 기록을 직접 짜 두고 일하는 쪽으로 왔습니다.

최근 들은 한 팟캐스트에서 제 생각과 많이 비슷한 이야기를 들었습니다. AI에게 “해줘”라고 부탁하는 데서 그치지 말고 자기 일에 맞는 도구를 만들어 써야 한다는 이야기였습니다. 도구로 쓰려면 손에 익은 숙련보다 높은 수준의 개념 이해가 필요하고, 결과가 마음에 들지 않을 때 그 불만족을 예민하게 느끼고 고쳐 나가는 감각이 사람에게 남는 영역이라고 했습니다.

제가 네 번을 바꾸는 동안 놓지 못한 것도 그쪽이었습니다. 세션을 저장하고 생각을 기록하는 데까지 왔지만, 일에 어떻게 접근할지를 정하는 상위 설계는 여전히 필요했습니다. 대딸깍 시대가 왔다고 해도 의도가 엉성하면 결과도 엉성하게 나왔습니다. 최종 결정도 결국 사람이 해야 했습니다.