관제탑과 빌더
AI에게 일을 시키는 구조를 만들다
AI에게 코드를 만들어달라고 시킬 수 있다는 건 알았다. 문제는 "어떤 AI에게, 어떤 방식으로" 시킬 것인가였다.
선택지가 두 가지 있었다. 하나는 Claude Code라는 터미널 기반 도구. 검은 화면에 글자를 입력하면 AI가 파일을 만들고, 코드를 실행하고, 에러가 나면 스스로 고친다. 다른 하나는 Cowork라는 데스크톱 앱. 같은 AI인데 마우스로 클릭할 수 있는 화면이 있고, 파일을 드래그해서 넣을 수 있다.
직감적으로는 Cowork가 편해 보였다. 클릭할 수 있으니까. 터미널은 여전히 낯설었다. 하지만 직감을 믿기 전에, AI에게 물어보기로 했다. "이 프로젝트를 진행하는 데 이 두 가지 도구 중 뭐가 더 나은지 비교해줘. 기준은 세 가지 — 내가 얼마나 개입해야 하는가, 결과물의 완성도, 걸리는 시간."
AI에게 자기 자신을 평가해달라고 시키는 것은 묘한 경험이었다. 그리고 돌아온 답은 꽤 솔직했다.
Claude Code가 압도적으로 유리하다고 했다. 이유는 단순했다. 터미널에서는 코드를 쓰고, 실행하고, 에러를 보고, 고치는 전체 순환을 AI 혼자 돌릴 수 있다. "테스트가 통과할 때까지 수정해"라고 시키면 실제로 반복한다. Cowork는 파일을 만들어주지만 실행은 못 한다. 요리를 해줄 수는 있는데 맛을 볼 수가 없는 셈이다. 맛을 보려면 내가 따로 실행해야 한다.
Python 모듈 18개를 만들고, 데이터베이스를 구축하고, 테스트를 돌리는 작업 — 이건 Cowork의 설계 목적이 아니었다. Cowork는 문서 정리, 리서치 종합, 파일 관리에 적합한 도구였다.
그래서 구조를 나눴다.
채팅창은 "관제탑"이 됐다. 전체 설계를 잡고, 진행 상황을 추적하고, 에러가 나면 원인을 분석하는 곳. 터미널의 Claude Code는 "빌더"가 됐다. 관제탑에서 내린 결정을 실제로 실행하는 곳.
이 비유가 자연스럽게 떠오른 건, 내가 하는 역할이 명확해졌기 때문이다. 나는 비행기를 조종하지 않는다. 비행기(코드)를 조종하는 건 AI가 한다. 나는 관제탑에 앉아서 "활주로 17번으로 이동해", "고도를 낮춰"라고 지시한다. 그리고 레이더(체크리스트)를 보면서 비행기가 계획된 경로를 따라가고 있는지 확인한다.
이 구조가 작동하려면 한 가지가 필요했다. 관제탑과 빌더 사이의 정보 흐름이다.
관제탑에서 설계를 한다. 그 설계를 문서로 만든다. 빌더에게 그 문서를 주면서 "이 문서대로 만들어"라고 시킨다. 빌더가 만든다. 에러가 나면 빌더에서 에러 로그를 복사한다. 관제탑에 붙여넣는다. 관제탑이 원인을 분석하고 해결책을 제시한다. 그 해결책을 빌더에 전달한다. 이 순환.
단순해 보이지만, 이 순환이 정립되기 전과 후의 생산성 차이는 컸다. 이전에는 "이것도 해주고 저것도 해줘"를 한 곳에서 섞어서 요청했다. 설계를 물어보다가 바로 코드를 만들어달라고 하고, 에러가 나면 같은 맥락에서 고쳐달라고 했다. AI가 혼란스러워하는 게 느껴졌다. 아니, 정확히 말하면 AI가 혼란스러워하는지 모르겠지만, 결과물의 일관성이 떨어졌다.
역할을 분리하자 결과가 좋아졌다. 관제탑에서는 "왜"와 "무엇을"만 다루고, 빌더에서는 "어떻게"만 다룬다. 관제탑에서 "분석기 모듈의 반환 타입을 AnalysisResult 객체로 통일해야 한다"라는 결론을 내리면, 빌더에게는 "src/modules/analyzer.py를 수정해서 AnalysisResult를 반환하도록 바꿔줘"라고 구체적으로 시킨다.
내가 PM이고 AI가 개발자라는 비유는 이 시점에서 자리를 잡았다. 더 정확하게는, AI는 유능한 신입이다. 시킨 일은 빠르고 정확하게 한다. 하지만 시키지 않은 일을 알아서 하거나, 전체 프로젝트의 방향을 잡는 건 못 한다. 그리고 가끔 요청하지 않은 기능을 미리 만들어놓는 경향이 있다. 신입 특유의 열정이랄까. 그래서 빌드 프롬프트에 "이번 단계에서 인증 코드는 절대 작성하지 마라"같은 금지 조항을 넣어야 했다.
퇴근 후 노트북을 열면, 먼저 관제탑을 연다. 어제 어디까지 했는지 확인한다. 오늘 할 일을 정한다. 그 다음에 터미널을 연다. 빌더에게 일을 시킨다.
이 순서가 습관이 되면서, 시간이 적은 게 오히려 장점이 됐다. 저녁 두세 시간밖에 없으니까, "오늘은 이것만 한다"라는 범위가 강제된다. 범위가 좁으면 AI에게 주는 지시도 명확해진다. 명확한 지시는 명확한 결과를 만든다.
시간이 적으면 실수할 여유도 적다. 그래서 저녁 시간밖에 없는 사람은 오히려 더 전략적이 된다 — 는 걸, 나는 이 무렵에 알게 됐다.
🔧 이 에피소드의 기술 용어 해설
터미널 (Terminal) 컴퓨터에게 글자로 명령을 내리는 검은 화면. 마우스로 클릭하는 대신 타이핑으로 파일을 만들고, 프로그램을 실행하고, 서버를 돌린다. 처음에는 두렵지만, 바이브코딩에서는 이 화면이 작업의 중심이 된다.
에이전트 (Agent) 사용자의 지시를 받아 스스로 계획을 세우고, 실행하고, 결과를 확인하는 AI 프로그램. 단순히 질문에 답하는 챗봇과 달리, 파일을 읽고 쓰고, 명령어를 실행하고, 에러를 보고 스스로 수정까지 한다.
CLI (Command Line Interface) 터미널에서 글자로 조작하는 방식. 반대말은 GUI(Graphical User Interface), 즉 마우스로 클릭하는 방식. Claude Code는 CLI 기반, Cowork는 GUI 기반이다.
디버깅 (Debugging) 코드에서 버그(오류)를 찾아 고치는 과정. 벌레(bug)를 잡는다는 뜻에서 유래했다. 바이브코딩에서는 AI가 에러 로그를 읽고 원인을 추적해주기 때문에, 코드를 읽을 줄 몰라도 디버깅이 가능하다.