요즘 개발되는 앱의 상당수는 앱 단독으로 동작하지 않고, 서버와 통신하는 구조로 만들어진다. 내가 개발하는 앱도 당연히 백엔드 서버를 이용하고 있다. 서버 개발이라는 벽 지난 포스팅 에서도 언급했듯이, 나는 요즘 일반적으로 많이 쓰이는 PHP나 Node.js 같은 기술에 대한 경험이 별로 없다. 그래서 이전에는 작은 기능 하나를 서버에 추가하려 해도 오랜 시간을 소비해야 했다. 결국 가급적이면 서버에 의존하지 않는 기능만 만들곤 했다. 내가 AI를 개발에 이용하기 시작한 주요 이유 중 하나가 바로 이 서버 개발 때문이었다. 처음에는 외주를 통해 개발되어 있던 기존 서버에 Cursor를 이용해 엔드포인트를 하나씩 추가하거나 수정하는 방식으로 진행했다. 응답이 제각각인 문제 그런데 이 과정에서 문제가 생겼다. AI가 새로운 엔드포인트를 만들 때마다 서버의 응답 형태가 조금씩 달라지면서, 클라이언트와 통합하는 데 어려움이 발생한 것이다. REST API에 대한 경험 없이 단순히 AI에게 구현만 시킨 결과였다. 문서화로 인터페이스 통일하기 이러한 비효율을 극복하기 위해 선택한 방법이 바로 지난 포스팅 에서 이야기한 문서화였다. 기능 개발의 전반적인 상황을 설명하고, 클라이언트와 서버 간의 인터페이스까지 함께 문서화하도록 했다. 그리고 생성된 문서를 앱과 서버 양쪽 프로젝트에 포함시켜, 이를 기반으로 개발하도록 함으로써 각 구현 단계에서 서로 다른 방식으로 구현되는 것을 방지했다. AI는 항상 새로운 개발자다 여기서 한 가지 주의할 점이 있다. 이미 한 번 구현된 서버에 새로운 엔드포인트를 추가해야 할 때, 기존과 동일한 방식으로 인터페이스를 구성해야 한다는 것을 반드시 함께 지시해야 했다. AI는 항상 새로운 개발자라고 보면 된다. 새로운 개발자는 자기 방식으로 개발하려는 경향 이 있다. 그래서 이전에 작성한 문서를 함께 제공하고, 이를 기반으로 작성하라고 명확히 지시해야 한다. 요즘은 AI 에이전트들이 프로젝트의 기존 코...
나는 오랫동안 개발을 업으로 하고 있다. 주로 소규모 기업에서 거의 1인 개발을 해왔다. 다른 개발자가 있더라도 각자 자기 일을 하는 그런 회사였다. 그러다 보니 여러 명이 하나의 프로젝트를 같이 수행하는 형태의 일이 별로 익숙하지 않다. 혼자 개발하고 테스트하다 보니, 체계화된 문서화도 나에겐 익숙하지 않다. 장기간 나만의 룰로 관습적으로 개발을 해왔다. 매번 새로 입사한 개발자 AI를 통해 코딩을 시작한 초기에는 에이전트에게 내가 지금 하고자 하는 일과 현재 상황을 전달하는 방법에 집중할 수밖에 없었다. AI 에이전트와 일하는 것은 매번 새로 입사한 개발자와 일하는 상황과 같다고 느꼈다. 아무것도 모르는 개발자에게 전후 사정 설명 없이 "이걸 해줘" 하면, 원하는 대로 동작하는 것 같지만 제대로 동작하지 않는 결과물을 만들어 내곤 했다. 그리고 이걸 수정하기 위해 대화가 길어지면 에이전트가 맥락을 잃어버리는 경우가 빈번히 발생했다. 문서화라는 해답 그래서 선택한 방법이 문서화였다. 내가 개발하고자 하는 기능을 문서로 정리하고, 이 문서를 기반으로 에이전트에게 개발을 요청하는 방식이다. 비슷한 시기에 AI를 이용한 코딩 관련 콘텐츠를 보면 문서화 이야기가 많았고, 그 시기에 아마존에서 출시한 Kiro라는 IDE는 이런 부분을 아예 내장하기까지 했다. 이야기했듯이 나는 문서화에 익숙하지 않다. 그래서 개발하고자 하는 기능을 문서로 정리하는 작업도 나에게는 그렇게 만만한 작업이 아니었다. 그래서 선택한 방법은 "문서화도 에이전트에게 시키자" 였다. 에이전트와 기획 회의하기 새로운 기능 개발이 필요하면 기획 회의를 에이전트와 진행한다. 보통 대화는 이렇게 시작한다. "지금부터 이런이런 기능을 개발하기 위한 기획 문서를 작성할 예정이다. 아직 코딩을 하지는 않을 것이다." 왜 "아직 코딩을 하지는 않을 것이다"라고 붙였을까 궁금할 텐데, 개발용 에이전트들은...