AI 코딩 에이전트 클로드, 100만 토큰 컨텍스트에도 여전히 20만 토큰이 최적

발표자는 1년 전까지만 해도 코드를 한 줄 한 줄 손으로 직접 작성하는 것을 선호했지만, 이제는 AI 코딩 에이전트 덕분에 여러 작업을 동시에 처리할 수 있게 되었다고 밝혔습니다. 그는 탭을 전환하고 에이전트의 작동 방식을 확인하며 입력 요청을 검토하는 방식으로 작업 방식을 변화시켰습니다. 이러한 변화는 개발 생산성 향상에 크게 기여했다고 설명했습니다.

발표자는 자신이 클로드를 사용하며 다른 대안보다 더 잘 작동한다고 평가했습니다. 하지만 이 발표에서 다룰 내용은 코덱스, 제미니, 또는 로컬 머신에서 실행되는 다른 모델에도 동일하게 적용될 수 있다고 강조했습니다. 즉, 특정 AI 에이전트에 한정되지 않고 보편적으로 적용 가능한 개발 방법론을 제시하겠다는 의미입니다.

클로드 오퍼스 모델은 최대 100만 토큰의 컨텍스트 창을 지원하며, 소네트 4.6 모델은 60만 토큰까지 가능합니다. 하지만 발표자는 20만 토큰을 넘지 않도록 컨텍스트를 간결하게 유지하는 것이 좋다고 조언했습니다. 컨텍스트가 너무 많아지면 에이전트가 혼란스러워하거나 모순된 아이디어를 유지하다가 제대로 작동하지 않을 수 있기 때문입니다. 이는 효율적인 AI 에이전트 활용을 위한 중요한 지침입니다.

발표자는 AI 에이전트와 함께하는 마인드풀 엔지니어링을 위한 5가지 아이디어를 제시했습니다. 첫째, 소스 코드의 새 버전과 같은 명확한 사양(spec)을 준비하는 것입니다. 둘째, 권력 분리 원칙을 적용하여 에이전트 간 역할과 책임을 명확히 합니다. 셋째, 완료 정의에 대한 객관적인 설명을 제공하여 작업의 완성도를 측정합니다. 마지막으로 한계 설정과 컨텍스트 창, 컨텍스트 로테이션 등을 효과적으로 관리하는 방법을 설명했습니다. 이러한 아이디어들은 에이전트 종류와 관계없이 적용 가능하다고 강조했습니다.

AI 에이전트 개발 프로세스는 네 가지 단계로 구성됩니다. 먼저 '탐색(explore)' 단계에서 요구 사항을 파악합니다. 다음 '제안(propose)' 단계에서는 설계, 제안, 사양, 그리고 구현을 위한 작업 목록을 만듭니다. 이어서 '적용(apply)' 단계에서는 에이전트가 실제 코드를 작성하고 테스트를 실행하며, 코드 검토 주기를 거쳐 코드를 완성합니다. 마지막으로 '보관(archive)' 단계에서는 완성된 변경 사항을 프로덕션에 배포하고 관련 기록을 추가하여 프로젝트 이력을 관리합니다.

발표자는 개발 과정에서 발생하는 모든 대화, 설계 결정, 질문과 답변을 GitHub 저장소에 기록한다고 밝혔습니다. GitHub에 커밋하면 개발 이력이 자동으로 제대로 남게 됩니다. 이는 경영진과 상위 관리자들이 선호하는 개발 로그를 자동으로 생성하는 것과 같은 효과를 냅니다. 그는 이 방식이 개발 진행 상황을 투명하게 공개하고 관리하는 데 매우 유용하다고 설명했습니다. 이를 통해 수동으로 개발 로그를 작성할 필요 없이 효율적인 이력 관리가 가능해집니다.

리뷰어 에이전트는 작업 내용, 사양, 설계, 작업 목록이 일치하는지 확인하여 코드 검토를 수행합니다. 일치하면 '좋다'고 판단하지만, 불일치할 경우 오케스트레이터에게 '차단(B)', '경고(W)', '사소한 지적(N)' 목록을 반환합니다. 이 분류는 리뷰어 에이전트가 자체적으로 생성한 것입니다. 사소한 지적의 경우 오케스트레이터가 개발자에게 수정 여부를 묻지만, 경고나 차단이 발생하면 자동으로 워커 에이전트에게 돌아가 문제를 해결하고 재검토하는 과정을 반복합니다.

LLM 프롬프트 작성 시 '당신은 주니어 .NET 웹 엔지니어입니다'와 같이 역할을 설명하기보다는 'ASP.NET Core 1.0 Razor Pages'처럼 명확한 기술 이름을 사용하는 것이 좋습니다. 발표자는 기술 이름을 사용하면 LLM이 가능한 응답 목록을 좁혀 원하는 결과를 찾을 가능성이 높아진다고 설명했습니다. 이는 자동 완성 기능에서 정확도를 높이는 것과 유사하며, LLM이 캐릭터처럼 행동하게 하는 것이 아니라 사실적인 정보를 주어 자동 완성 기능을 개선하는 것이 중요하다고 강조했습니다.

AI 에이전트를 분리하는 주된 이유는 동일한 에이전트를 계속 사용하면 작업 검토가 제대로 이루어지지 않기 때문입니다. 에이전트가 이미 코드를 생성하면서 '이것은 작동한다'는 정보를 가지고 있기 때문에, 같은 에이전트에게 코드 검토를 요청하면 자신의 코드를 이미 알고 있다고 판단하여 객관적인 검토의 필요성을 느끼지 못합니다. 이는 GitHub에서 개발자가 스스로 풀 리퀘스트를 승인하는 것과 같다고 비유하며, 객관적인 검토를 위해 에이전트 분리가 필수적이라고 설명했습니다.

소프트웨어 개발에서 '완료'의 정의는 명확한 기준을 가집니다. 첫째, 빌드가 깔끔하게 이루어져야 합니다. 둘째, 모든 테스트가 통과해야 하며, 코드 커버리지 목표를 설정하고 달성해야 합니다. 시스템은 XUnit이나 Microsoft 테스트 프레임워크 같은 도구에서 필요한 숫자를 추출하는 명령을 알고 있으며, 이러한 규칙을 따릅니다. 셋째, GitHub Actions와 CI를 설정하여 코드 표준을 준수하고 커버리지가 이전 릴리스보다 떨어지지 않도록 관리합니다. 마지막으로, `dotnet format`을 실행하여 코드가 깔끔하게 포맷되도록 자동화하며, 만약 두 번째 실행에서 변경 사항이 감지되면 문제가 발생한 것으로 간주합니다.

발표자는 현재 AI를 통해 개발하는 방식이 지난 수년간 소프트웨어를 구축했어야 했던 방식과 매우 유사하다고 지적했습니다. 그는 이러한 AI 개발 프로세스가 지향하는 바가 바로 이것이며, 이를 통해 개발자들이 한 단계 더 발전할 수 있다고 강조했습니다. 즉, AI를 활용한 개발은 과거의 모범 사례를 따르면서도 효율성을 극대화하는 방향으로 진화하고 있다는 것입니다.

발표자는 현재 AI 사용 방식이 결국 중단될 것이며, 언젠가는 토큰 사용에 대한 비용을 지불해야 할 것이라고 경고했습니다. 그는 두 가지 가능성 중 하나가 현실화될 것으로 보는데, 하나는 AI 사용량을 심각하게 줄이는 것이고, 다른 하나는 콴 4(Quen 4)나 딥 시크 5(DeepSeek 5)와 같은 모델들을 64GB 또는 128GB RAM이 장착된 로컬 머신에서 직접 실행하게 될 것이라는 예측입니다. 이는 장기적으로 AI 개발 환경의 큰 변화를 예고합니다.

발표자는 Claude Opus 4.8이 .NET LTS의 현재 버전이 8이고 C#의 현재 버전이 11이라고 자신 있게 말한다고 지적했습니다. 이는 클로드의 학습 데이터가 2년 전 것이기 때문에 .NET 10이 존재한다는 사실을 모르는 데서 비롯됩니다. 그는 클로드가 .NET 9는 알고 있었지만 장기 지원 버전이 아니었기 때문에 8을 사용하려 했다고 덧붙였습니다. 이는 AI 모델이 항상 최신 정보를 반영하지 못할 수 있음을 보여주는 사례입니다.

코딩 에이전트가 개발 과정에서 어떤 문제를 발견하고 해결 방법을 확신하지 못할 때, 아키텍트인 발표자에게 결정을 요청한다고 설명했습니다. 에이전트는 지시를 따랐고, '아키텍트의 결정'이라고 명시하며 책임을 위임했습니다. 발표자는 즉흥적으로 할 일이 아니며, 예를 들어 그룹 4에서 '기존 턴 메모리 지속성 배선을 뒤집는 것'이라고 설명된 부분이 실제로는 존재하지 않는 배선인 경우처럼 모호한 상황에서 에이전트가 판단을 내리지 않고 전문가의 개입을 요청한다고 설명했습니다.

개발 프로세스에서 작업자와 검토자 에이전트는 매번 새롭게 생성되며 재활용되지 않습니다. 이는 최초 작업을 구현한 작업자와 검토자가 동일한 에이전트가 아니라는 의미입니다. 작업자들은 검토자가 자신의 작업을 검토하고 다시 보내줄 때까지 기다리지 않으며, 검토자는 '이 코드는 이런 식으로 망가졌다'고 피드백한 후 완전히 새로운 작업자 에이전트를 생성합니다. 이 방식은 이전 작업의 맥락에 얽매이지 않고 객관적이고 독립적인 검토 및 수정이 가능하도록 합니다. 이를 통해 코드 품질과 효율성을 동시에 확보할 수 있습니다.

발표자는 청중에게 자신이 제시한 코드를 맹목적으로 복사하여 사용하지 말 것을 강조했습니다. 대신 그는 이 발표에서 제시된 다섯 가지 원칙을 가져가서 자신만의 방식으로 활용하여 코드를 개발할 것을 권고했습니다. 이는 단순한 코드 복사보다는 원칙에 대한 이해를 바탕으로 창의적이고 효과적인 개발을 독려하기 위함입니다.

발표자는 개발자의 역할이 명세서와 로드맵을 관리하며 상위 수준의 내용을 유지하는 것이라고 설명했습니다. 그는 AI 도구들을 '유용한 바보 무리'에 비유하며, 매우 명확한 지시를 내리면 올바른 일을 할 가능성이 높다고 강조했습니다. 이는 개발자가 AI 도구를 단순히 사용하는 것을 넘어, AI가 효과적으로 작동할 수 있도록 명확한 지침과 구조를 제공하는 역할을 해야 함을 의미합니다. 명확한 지침 없이는 AI의 잠재력을 최대한 활용하기 어렵다는 메시지입니다.

발표자는 현재 자신이 개발 중인 AI 관련 오픈소스 프로젝트 'Demonic AI'를 소개했습니다. 이 프로젝트는 GitHub의 `github.com/demonicAI`에서 찾아볼 수 있으며, 아직 공개되지 않은 다른 부분도 있다고 언급했습니다. 그는 또한 'DCLI'라는 또 다른 프로젝트도 진행 중이라고 밝히며, 이 모든 것 중에서 성공할 프로젝트가 있을 것이라고 말했습니다. 이는 그의 AI 연구 및 개발 활동이 오픈소스 생태계에 기여하고 있음을 보여줍니다.