클로드 코드 플러그인, TDD 개발 속도 높여… AI가 코드 구현 담당

그는 지난 3개월 동안 이 고민이 가장 컸다고 언급하며, 단순히 TDD를 자동화하는 것을 넘어 AI가 생성한 코드를 인간 개발자가 어떻게 효과적으로 이해하고 활용할지에 대한 깊은 고민에서 목표를 전환했다고 설명했다.

이는 AI가 코드를 생성하는 시대에 개발자의 역할과 필요한 역량 변화에 대한 인식을 반영한 것이다. 개발자가 모든 코드를 직접 작성하는 것이 아닌, AI가 생성한 코드를 검토하고 통합하는 과정에서 '이해'가 핵심적인 과제로 부상했다는 판단이다.

이러한 목표 변경은 플러그인의 설계 방향에도 영향을 미쳤다. 그는 플러그인이 생성된 코드의 맥락과 의미를 명확히 제시하여, 개발자가 빠르고 정확하게 코드의 의도를 파악하고 문제 발생 시 효과적으로 대응할 수 있도록 돕는 데 초점을 맞추게 되었다고 덧붙였다.

백명석 개발자는 AI가 만든 코드를 사람이 일일이 검토하려 할 경우, 오히려 생산성이 떨어질 수 있다고 지적했다. 이는 AI의 할루시네이션(환각 현상) 우려 때문에 AI 코드 사용을 주저하던 회사들이 있었으나, 이러한 우려에도 불구하고 AI를 적극적으로 사용한 회사들이 결국 생산성 향상을 이뤘던 사례와 비교했다.

백명석 개발자는 잘 이해하지 못하는 코드를 배포하는 것에 대한 불안감을 인정하면서도, AI 코드에 대한 과도한 라인별 검토가 오히려 생산성을 저해할 수 있다고 설명했다. 그는 AI의 할루시네이션 위험에도 불구하고 이를 활용한 기업들이 생산성 이점을 얻었음을 강조하며, 새로운 접근 방식의 필요성을 시사했다.

그는 AI 기술의 발전이라는 거대한 흐름을 거스를 수는 없지만, 개발자가 이 변화에 어떻게 대응하고 활용할지는 선택할 수 있다고 강조했다.

이는 개발자들이 AI 기술을 두려워하거나 회피하기보다는, 이를 적극적으로 받아들이고 자신의 역량을 강화하는 방향으로 나아가야 한다는 메시지를 담고 있다. AI를 활용하여 생산성을 높이고, 더 가치 있는 작업에 집중하는 방법을 터득하는 것이 중요하다고 그는 덧붙였다.

이 모드는 개발자가 프로젝트의 특성이나 복잡성에 따라 TDD 적용 속도를 유연하게 조절할 수 있도록 설계되었다. 그는 가장 빠른 '하이', 중간 속도의 '미드', 그리고 가장 철저한 '로우' 모드를 제시했다.

'로우' 모드는 전통적인 TDD 절차인 '레드-그린-리팩터링(RGB)'을 각각 별도의 커밋으로 나누어 진행하는 방식이다. 즉, 실패하는 테스트를 추가하고, 이를 통과시키는 코드를 작성한 후, 코드를 개선하는 리팩터링 과정을 모두 독립적인 커밋으로 기록하여 변경 이력을 명확히 한다. 이는 개발자가 각 단계의 목적을 명확히 인지하고 신중하게 진행할 수 있도록 돕는다.

'미드' 모드는 RGB의 세 단계를 하나의 커밋으로 묶어서 처리한다. 이는 로우 모드보다 개발 속도를 높이면서도 TDD의 핵심 원칙을 유지할 수 있도록 한다. 반면 '하이' 모드는 여덟 개의 테스트가 필요한 한 기능 전체를 AI가 한 번에 구현하는 방식으로, 가장 빠른 개발 속도를 제공한다. 이 모드는 AI의 강력한 코드 생성 능력을 최대한 활용하여, 특정 기능 구현에 필요한 테스트들을 일괄적으로 처리하고 코드를 생성함으로써 개발 시간을 크게 단축시키는 것을 목표로 한다.

백명석 개발자는 TDD 플랜을 수립하는 새로운 방식으로 'AI와 인터뷰' 방식을 도입했다고 밝혔다. 이 기능은 플러그인에 'TDD 플랜 인풋'으로 추가되어, 개발자가 실행하면 AI가 지속적으로 질문을 던지며 요구사항을 상세화하는 과정을 거친다.

예를 들어, 개발자가 '장바구니에 상품을 넣으면 총액을 보여주는 기능'을 만들고 싶다고 하면, AI는 '마일리지와 쿠폰 적용', '배송비' 등 추가적인 요소를 제안한다. 이후 AI는 '음수일 때는 어떻게 할 것인가', '0일 때는 어떻게 할 것인가'와 같이 예외 상황에 대한 질문을 던지며 요구사항을 구체화한다. 이러한 상호작용을 통해 개발자와 AI가 반복적인 대화를 주고받으면, 최종적으로는 상세한 TDD 플랜 문서가 생성된다.

이는 개발 초기 단계에 '나는 동작 가능한 환경에서 개발을 시작했다'는 것을 확보하기 위함이다. 즉, 가장 기본적인 구조와 최소한의 기능이 제대로 작동하는지 먼저 확인하여 개발 환경의 안정성을 보장하는 것이다.

워킹 스켈레톤을 구현할 때는 비즈니스 로직에 과도하게 집중하기보다는, 인프라와 기본적인 연동이 원활하게 이루어지는지 확인하는 데 초점을 맞춘다. 이는 복잡한 비즈니스 로직 개발에 앞서 기반 환경을 견고히 함으로써, 이후 발생할 수 있는 잠재적인 문제들을 예방하고 개발 효율성을 높이는 전략이다.

사용자 스토리는 '장바구니 결제 금액 확인'과 같이 고객 관점에서 '누구로서, 무엇을 원해, 왜'라는 세 가지 문장으로 구성되어, 매우 단순하고 명확하게 작성된다. 이는 현재 아는 정보가 많지 않으므로 복잡하게 만들지 않는 것이 중요하다고 그는 덧붙였다.

이러한 사용자 스토리를 바탕으로 거킨 시나리오를 작성한다. 예를 들어, '상품 합계, 쿠폰, 마일리지를 정해서 금액을 만든다'는 사용자 스토리에 대해, 거킨 시나리오는 'Given(주어진 상황), When(행동), Then(결과)' 형식으로 구체적인 테스트 케이스를 테이블 형태로 정의한다. 이는 각 조건에 따라 쿠폰과 마일리지를 적용하고 최종 결제 금액을 확인하는 시나리오가 된다. 이 과정을 거치면 '스텝스(steps)'라는 파일이 생성되어 각 시나리오의 실행 단계가 명확해진다.

백명석 개발자는 AI가 생성한 테스트 결과물이 일반적인 유닛 테스트 코드보다 가독성이 뛰어나다고 주장했다. 그는 이렇게 생성된 테스트를 통해 어떤 케이스가 테스트 커버리지에 포함되고, 어떤 케이스가 누락되었는지 명확하게 파악할 수 있다고 설명했다.

이는 개발자가 코드를 일일이 분석하지 않아도, 테스트 결과물 자체만으로 기능의 동작 범위와 예외 처리 여부를 한눈에 확인할 수 있음을 의미한다. 특히 다양한 조건과 시나리오에 대한 테스트 케이스들이 체계적으로 정리되어 있어, 누락된 테스트를 찾아내고 보완하는 과정이 훨씬 수월하다고 그는 덧붙였다.

그는 커밋을 신호등처럼 잘게 나누면 문제가 생겼을 때 이해하기 쉽고, 커밋 로그를 통해 AI에게 설명을 요청하기도 용이할 것이라고 예상했다.

AI는 방대한 양의 정보를 처리하는 데 제약이 없으므로, 커밋을 잘게 나누어 많은 맥락을 제공하는 것이 AI의 이해도를 높이는 데 도움이 될 것이라고 설명했다. 이는 사람이 너무 잘게 나뉜 커밋에 짜증을 내거나 너무 큰 덩어리에 답답함을 느끼는 것과 달리, AI는 분할된 정보량에 영향을 받지 않기 때문이라고 덧붙였다.

따라서 테스트와 스펙을 정교하게 작성하면, 개발자는 코드 자체보다는 테스트 결과와 커밋 로그를 통해 기능의 안정성과 변경 사항을 파악할 수 있게 된다. 이는 개발자가 코드 이해에 드는 시간을 절약하고, 더 높은 수준의 문제 해결에 집중할 수 있도록 하여 전체적인 생산성 향상에 기여할 것으로 보인다.

그는 개발자가 직접 코드를 작성할 때도 적용해야 할 기법이나 절차를 잊어버리거나 건너뛰는 경우가 있는데, 플러그인을 사용하면 이러한 실수를 줄일 수 있다고 설명했다.

플러그인은 스킬 형태로 다양한 개발 노하우와 절차를 포함하고 있어, 개발 과정에서 필요한 시점에 자동으로 개입하여 개발자를 돕는다. 그는 플러그인 사용 시 다소 속도가 느리다는 점을 언급하면서도, 한 번 해보면 AI가 알아서 적절한 순간에 나타나 도움을 주는 방식이 유용할 것이라고 덧붙였다.

백명석 개발자는 자신이 제작한 플러그인이 '하네스 엔지니어링 위 클로드 코드'라는 책의 내용을 많이 반영하여 변경되었다고 밝혔다. 그는 책의 PDF를 AI에 제공하여 절차에 맞게 플러그인을 수정하도록 지시했고, 그 결과 많은 부분이 개선되었다고 설명했다.

특히, 플러그인에 '에이전트' 개념이 중요하게 도입되었다고 강조했다. 에이전트는 '스킬'을 사용하며, 전체적인 개발 흐름을 관리하는 '오케스트레이션 스킬'이 에이전트와 스킬을 호출하면 자율적으로 동작하도록 설계되었다. 이로 인해 개발자는 시작점만 알면 이후 과정은 AI가 알아서 다음 단계를 진행하며 질문을 던지므로, 전체 흐름을 일일이 지시할 필요가 없어졌다.

그는 잠들기 전에 AI에게 하이 모드와 미드 모드를 각각 실행하여 브랜치를 만들고 PR(Pull Request)까지 올리도록 지시하는 방식으로 검증했다고 설명했다. 반면, '로우 모드'는 자신이 직접 수동으로 검증을 진행했다고 덧붙였다.

이전에는 AI가 코드를 만든 후 사람이 직접 작동 여부를 확인해야 했지만, 이제는 AI에게 '네가 만든 코드가 잘 도는지 검증해라'라고 지시하면, AI가 스스로 검증 과정을 거쳐 성공 여부를 알려준다고 설명했다.

이러한 자동 검증 시스템 덕분에 개발자는 코드 자체를 일일이 들여다보기보다는, AI가 보고한 검증 결과를 바탕으로 문제가 발생한 부분에만 집중할 수 있게 되었다. 이는 개발자가 코드 디버깅에 소요되는 시간을 대폭 줄이고, 효율성을 높이는 데 기여한다.

백명석 개발자는 AI가 생성한 코드가 현재 완벽하지는 않지만, 충분히 괜찮은 수준이라고 평가했다. 그는 사용자들의 피드백과 개선 제안을 통해 AI 코드가 점진적으로 더 나아질 것이라고 전망했다.

사용자들이 플러그인을 사용하면서 발견한 개선점들을 '풀 리퀘스트(PR)' 형태로 제출하면, 이러한 제안들이 반영되어 AI 모델이 지속적으로 발전할 수 있다는 설명이다. 이는 개발자와 AI가 상호작용하며 함께 성장하는 협력적인 개발 생태계를 강조하는 부분이다.

백명석 개발자는 시간 제약상 플러그인 시연을 직접 보여주기는 어렵다고 밝혔다. 대신 그는 사용자들이 직접 해볼 것을 권장하며, 관련된 두 개의 저장소(레포지토리)를 안내했다.

하나는 'MS 클로드 플러그인즈(msbaek-claude-plugins)'로, 이를 받아 설치하면 된다. 다른 하나는 'msbaek-tdd-plugin-verification'으로, 이 검증 프로젝트를 참조하여 로컬 환경에서 플러그인을 직접 사용해보고 테스트해보는 것이 필요하다고 설명했다.

그는 개발자가 원한다면 언제든 코드를 이해할 수 있는 구조를 만들되, 매번 모든 코드를 깊이 이해할 필요 없이 생산성을 극대화해야 한다고 주장했다.

이를 위해 커밋을 잘게 나누고 많은 맥락 정보를 넣어두면, 개발자가 필요할 때 AI에게 질문하거나 커밋 단위를 통해 코드를 이해할 수 있다. 그러나 궁극적으로는 거킨 시나리오와 같은 상위 수준의 문서만 보고도 기능의 동작을 파악하고 배포할 수 있는 환경을 구축하여, AI가 증폭시키는 생산성을 인간의 이해 병목으로 인해 늦추지 않아야 한다고 설명했다.

그는 변경의 위험이 낮고 영향이 적은 경우에는 빠르게 큰 덩어리로 진행할 수 있지만, 장애 발생 시 금전적 손실로 이어지는 등 위험이 높은 경우에는 모든 것을 철저히 이해하고 작은 덩어리로 접근해야 한다고 설명했다.

모든 상황에 하나의 개발 방법을 적용하려 하면 가장 느리고 보수적인 방법을 선택할 수밖에 없게 되므로, 프로젝트의 특성과 위험도를 평가하여 적절한 전략을 선택하는 것이 중요하다고 덧붙였다.

백명석 개발자는 엔터프라이즈 환경에서 다양한 사업 영역을 모두 만족하는 단일하고 복잡한 솔루션을 만드는 것보다는, 역할을 분리하여 접근해야 한다고 밝혔다. 그는 TDD를 세 가지 방법으로 나눈 것처럼, 플러그인 개발 시에도 에이전트, 스킬, 그리고 전체 흐름을 관장하는 오케스트레이터를 나누어 설계해야 한다고 설명했다.

이러한 분리된 접근 방식은 각 요소의 독립성을 높이고, 특정 도메인의 복잡성에 맞춰 유연하게 대응할 수 있도록 한다. 그는 심지어 이러한 에이전트와 스킬, 오케스트레이터의 설계 및 구현까지도 AI가 도와줄 수 있다고 덧붙였다.