고인물? 새내기?

지난 포스팅에서 개발 환경을 모노레포로 통합 하여, 동일한 Claude 세션 안에서 앱과 서버들을 한꺼번에 개발할 수 있게 했다고 이야기했다. 덕분에 명세 동기화 문제나 연동 디버깅의 번거로움이 크게 줄었다. 그런데 이렇게 앱과 여러 서버를 하나의 세션에서 다루다 보면, 또 다른 효율 저하 요인이 생긴다. 바로 컨텍스트 사이즈 제약 이다. 컨텍스트 압축이라는 새로운 문제 요즘은 Max 요금제 기준으로 기본 1MB 컨텍스트를 제공해서 예전만큼 빡빡하지는 않다. 하지만 불과 두어 달 전까지만 해도 컨텍스트 크기가 지금보다 훨씬 작았다(그래도 다른 서비스보다는 컸다). 그래서 한꺼번에 많은 코드를 분석시키고 대화를 조금만 이어가면, 빈번한 컨텍스트 압축 이 발생하곤 했다. 컨텍스트 압축이 일어나면 대화의 맥락이 흐려지기 시작한다. 방금 전까지 이해하고 있던 내용을 다시 설명해야 하거나, 이미 정한 구현 방향을 잊고 다른 길로 가기도 한다. 모노레포로 프로젝트를 합친 직후에 이 문제가 두드러지게 나타났다. 해결: 에이전트 팀 구성하기 이 문제를 줄이기 위해 Claude Code가 지원하는 서브에이전트(Sub-agent) 기능 을 적극적으로 활용하기로 했다. 앱과 각 서버를 담당할 전문 에이전트를 만들고, 이들을 총괄할 팀 리더 에이전트 를 따로 두는 방식이다. 말 그대로 "에이전트 팀"을 꾸리는 셈이다. 페르소나 구성은 대략 이렇게 잡았다. 팀 리더 └─ 제품 전체 기획 / 각 개발자에게 업무 지시 앱 개발자 └─ 모바일 앱 개발에 능숙한 개발자 서버#1 개발자 └─ Node.js 개발에 뛰어난 개발자 서버#2 개발자 └─ Python 개발자 이렇게 담당 프로젝트의 특성에 맞춰 각 에이전트의 페르소나를 정의한다. 테스터 에이전트를 따로 두는 분들도 있는데, 나는 별도로 분리하지 않았다. 서브에이전트 생성은 Claude Code에서 프롬프트로 설정할 수 있고, 추가한 뒤에는 세션을 새로 ...

바이브 코딩을 하는 가장 큰 이유는 아마도 개발 생산성 향상 일 것이다. 그래서인지 바이브 코딩을 하면서 자연스럽게 "어떻게 하면 효율을 더 높일 수 있을까?"를 고민하게 된다. 직접 코드를 작성하지 않으니, 그만큼 남는 시간을 프로세스 개선에 투자하게 되는 셈이다. 지난 포스팅에서 앱과 서버를 함께 개발할 때 명세 문서를 작성하고, 이를 기반으로 AI 에이전트에게 개발을 지시하는 방식을 소개했었다. 오늘은 이 방식을 실제로 사용하면서 겪었던 불편함과, 그것을 어떻게 개선했는지 이야기해보려 한다. 기존 개발 환경 앱에 기능을 추가하다 보니 서비스가 하나가 아니라 여러 개가 되었다. 당시 내 개발 환경을 간단히 그려보면 이런 구조였다. 개발 Macbook └─ 앱 프로젝트/ ├─ docs/ └─ src/ Ubuntu 서버 ├─ server1 프로젝트/ │ ├─ docs/ │ └─ src/ └─ server2 프로젝트/ ├─ docs/ └─ src/ iOS 앱 개발은 어쩔 수 없이 Mac에서 해야 했다. 서버는 DB도 돌려야 하고, 실제 운영 환경과 동일한 조건에서 개발하는 게 나을 것 같아 Ubuntu에서 진행했다. Macbook 용량도 부족한데 DB 서버를 계속 띄워놓기도 부담스러웠고, 초기에 API 서버가 PHP + Apache 조합이었던 것도 분리한 이유 중 하나였다. 기존 개발 프로세스 새로운 기능을 추가하거나 수정할 때는 이런 순서로 작업했다. VS Code에서 앱 프로젝트를 열고, Claude를 이용해 명세를 작성 한다. 작성된 명세를 구현이 필요한 각 프로젝트의 docs 폴더에 복사 한다. VS Code에서 각 프로젝트를 연다. 서버의 경우 VS Code의 원격 연결을 이용한다. 각 프로젝트에서 Claude를 실행하고, docs 폴더의 명세를 기반으로 개발을 지시 한다. 문제점 문제...

요즘 개발되는 앱의 상당수는 앱 단독으로 동작하지 않고, 서버와 통신하는 구조로 만들어진다. 내가 개발하는 앱도 당연히 백엔드 서버를 이용하고 있다. 서버 개발이라는 벽 지난 포스팅 에서도 언급했듯이, 나는 요즘 일반적으로 많이 쓰이는 PHP나 Node.js 같은 기술에 대한 경험이 별로 없다. 그래서 이전에는 작은 기능 하나를 서버에 추가하려 해도 오랜 시간을 소비해야 했다. 결국 가급적이면 서버에 의존하지 않는 기능만 만들곤 했다. 내가 AI를 개발에 이용하기 시작한 주요 이유 중 하나가 바로 이 서버 개발 때문이었다. 처음에는 외주를 통해 개발되어 있던 기존 서버에 Cursor를 이용해 엔드포인트를 하나씩 추가하거나 수정하는 방식으로 진행했다. 응답이 제각각인 문제 그런데 이 과정에서 문제가 생겼다. AI가 새로운 엔드포인트를 만들 때마다 서버의 응답 형태가 조금씩 달라지면서, 클라이언트와 통합하는 데 어려움이 발생한 것이다. REST API에 대한 경험 없이 단순히 AI에게 구현만 시킨 결과였다. 문서화로 인터페이스 통일하기 이러한 비효율을 극복하기 위해 선택한 방법이 바로 지난 포스팅 에서 이야기한 문서화였다. 기능 개발의 전반적인 상황을 설명하고, 클라이언트와 서버 간의 인터페이스까지 함께 문서화하도록 했다. 그리고 생성된 문서를 앱과 서버 양쪽 프로젝트에 포함시켜, 이를 기반으로 개발하도록 함으로써 각 구현 단계에서 서로 다른 방식으로 구현되는 것을 방지했다. AI는 항상 새로운 개발자다 여기서 한 가지 주의할 점이 있다. 이미 한 번 구현된 서버에 새로운 엔드포인트를 추가해야 할 때, 기존과 동일한 방식으로 인터페이스를 구성해야 한다는 것을 반드시 함께 지시해야 했다. AI는 항상 새로운 개발자라고 보면 된다. 새로운 개발자는 자기 방식으로 개발하려는 경향 이 있다. 그래서 이전에 작성한 문서를 함께 제공하고, 이를 기반으로 작성하라고 명확히 지시해야 한다. 요즘은 AI 에이전트들이 프로젝트의 기존 코...

나는 오랫동안 개발을 업으로 하고 있다. 주로 소규모 기업에서 거의 1인 개발을 해왔다. 다른 개발자가 있더라도 각자 자기 일을 하는 그런 회사였다. 그러다 보니 여러 명이 하나의 프로젝트를 같이 수행하는 형태의 일이 별로 익숙하지 않다. 혼자 개발하고 테스트하다 보니, 체계화된 문서화도 나에겐 익숙하지 않다. 장기간 나만의 룰로 관습적으로 개발을 해왔다. 매번 새로 입사한 개발자 AI를 통해 코딩을 시작한 초기에는 에이전트에게 내가 지금 하고자 하는 일과 현재 상황을 전달하는 방법에 집중할 수밖에 없었다. AI 에이전트와 일하는 것은 매번 새로 입사한 개발자와 일하는 상황과 같다고 느꼈다. 아무것도 모르는 개발자에게 전후 사정 설명 없이 "이걸 해줘" 하면, 원하는 대로 동작하는 것 같지만 제대로 동작하지 않는 결과물을 만들어 내곤 했다. 그리고 이걸 수정하기 위해 대화가 길어지면 에이전트가 맥락을 잃어버리는 경우가 빈번히 발생했다. 문서화라는 해답 그래서 선택한 방법이 문서화였다. 내가 개발하고자 하는 기능을 문서로 정리하고, 이 문서를 기반으로 에이전트에게 개발을 요청하는 방식이다. 비슷한 시기에 AI를 이용한 코딩 관련 콘텐츠를 보면 문서화 이야기가 많았고, 그 시기에 아마존에서 출시한 Kiro라는 IDE는 이런 부분을 아예 내장하기까지 했다. 이야기했듯이 나는 문서화에 익숙하지 않다. 그래서 개발하고자 하는 기능을 문서로 정리하는 작업도 나에게는 그렇게 만만한 작업이 아니었다. 그래서 선택한 방법은 "문서화도 에이전트에게 시키자" 였다. 에이전트와 기획 회의하기 새로운 기능 개발이 필요하면 기획 회의를 에이전트와 진행한다. 보통 대화는 이렇게 시작한다. "지금부터 이런이런 기능을 개발하기 위한 기획 문서를 작성할 예정이다. 아직 코딩을 하지는 않을 것이다." 왜 "아직 코딩을 하지는 않을 것이다"라고 붙였을까 궁금할 텐데, 개발용 에이전트들은...