요즘IT는 지난 10월 클로드 코드 세미나 ‘클코나잇’을 열고 클로드 코드를 현업에서 실제로 활용하는 다양한 사례를 공유했습니다. 스타트업 개발팀의 자동화 사례, 클로드 코드 맥스플랜을 아깝지 않게 쓰는 법, 팀에서 바이브 코딩을 표준화한 테크 리드의 사례, 엔터프라이즈급 웹앱을 구축한 사례를 공유했는데요. 참가자들에게 “클로드 현업 꿀팁의 장” “실전에 도움되는 세미나” “최근 웨비나 중 가장 유익했다”라고 호평을 받았습니다. 아쉽게도 참석하지 못한 분들을 위해 그날의 핵심 내용을 정리해 콘텐츠로 다시 전해드립니다.

이번 글은 세미나 첫 번째 주제였던 “스타트업 개발 자동화: 에이전트가 Feature를 80% 구현하는 법”입니다. 개발자들을 위한 클로드코드 딥다이브 세미나참가 신청도 열려 있으니 많은 관심 부탁드립니다.

안녕하세요. 이번 클코나잇에서 '스타트업 개발 자동화' 발표 세션을 맡게 된 히로인스개발 리더 김효준이라고 합니다.

먼저 저희 회사를 간단히 소개하겠습니다. 패러다임시프트는 4060을 메인 타겟으로 한 엄마들을 위한 버티컬 소셜 플랫폼 히로인스를 개발하고 있습니다. 최근에는 커머스까지 확장해 나가고 있습니다.

스타트업의 ‘속도’ UP 위한 AI 개발 자동화의 시작

저희는 초기 스타트업입니다. 아주 극초기는 아니지만 여전히 매우 초기이며 수많은 가설과 실험 그리고 실패를 경험하고 있습니다.

다들 아시다시피 스타트업에선 속도가 매우 중요합니다. 그러나 리소스가 매우 적은 것도 현실입니다. 그러다 보니 자연스럽게 개발 리더로서 '어떻게 하면 우리 팀의 생산성을 올릴 수 있을까'를 꾸준히 고민해왔습니다. 그렇게 LLM 시대에서 자연스럽게 '어떻게 AI를 통해서 우리 팀의 생산성을 올릴 수 있을까'를 생각해왔습니다.

오늘 발표를 통해 저희 팀에서 진행했던 에이전트를 통한 개발 자동화 히스토리를 공유해 드리도록 하겠습니다.

초기 자동화 시도와 한계 (Cursor & Composer)

다들 Cursor 많이 써보셨을 것 같은데요. 저희 팀도 Cursor 에이전트가 나오기 전, 초창기 'Composer'라는 기능을 활용했었습니다. 여러 작업을 동시에 도와주는, 당시로서는 꽤 고마운 기능이었죠.

저희는 이 Composer 때부터 여러 시도를 해보기 시작했습니다. 첫 번째 타깃은 백엔드 E2E 자동화였습니다. 패턴이 가장 명확하면서도, 역설적으로 가장 공수가 많이 드는 작업이었기 때문입니다.

하지만 결과는 '성공도 실패도 아닌' 모호한 상태였습니다. 겉보기엔 결과가 나쁘지 않았지만, 사소한 컨벤션 오류나 자잘한 에러들이 계속 발생했습니다. 결국, AI가 만든 코드를 사람이 매번 다시 리뷰하고 수정해야 하는 구조가 반복되었습니다.

에이전트의 핵심, 'Planning'을 컨트롤하려는 노력

그래서 에이전트를 더 공부해 보기로 했습니다. 에이전트의 기본인 ReAct(Reasoning and Acting) 프레임워크는 유저의 요청이 오면 [계획 → 행동 → 관찰 → 생각]을 계속 반복하는 루프 구조입니다.

가만 보니, 'Tool-calling(행동)'이나 'Thinking loop(생각)' 단계는 이미 Cursor가 훌륭하게 갖추고 있었습니다. 이걸 따로 구현해 보려고 시도도 해봤지만, 공수가 너무 컸죠.

결국 고민은 'Cursor라는 도구 안에서 어떻게 하면 내 목표를 더 빨리 달성할까?'였고, '아, 결국 플래닝(Planning)이 문제구나. 이걸 내가 컨트롤할 수 없을까?'라는 결론에 이르렀습니다.

Composer 이후 정식 출시된 Cursor 에이전트에도 플래닝을 제어하는 기능은 없었습니다.

그래서 프롬프트로 어떻게든 플래닝을 컨트롤해 보려고 했습니다. 사진처럼 체크박스 To-do list를 주고,"각 단계를 진행할 때마다 이 To-do list를 다시 읽어라"라고 지시해서 컨텍스트를 강제로 유지시켰습니다. 또, 단계별로 필요한 문서도 그 순간에만 읽도록 시켰죠.

지금 돌이켜보면 이게 저의 가장 원시적인 '컨텍스트 엔지니어링' 시도였던 것 같습니다. 생각보다 잘 작동해서 꽤 오래 이 구조로 작업을 해왔습니다.

하지만 컨텍스트가 조금만 길어져도 에이전트가 체크박스 리마인더를 놓치거나 엉뚱한 방향으로 가버렸고, 결국 또 사람이 중간중간 개입해야 하는 한계는 여전했습니다.

'클로드 코드'와 E2E 피드백 루프를 통한 확신

그러다 '클로드 코드(Claude Code)'를 만나게 되었습니다.

Max 요금제 덕분에 토큰 걱정 없이 마음껏 테스트해볼 수 있었고, 무엇보다 To-do list가 기본 기능으로 내장되어 있어 이전처럼 To-do list 자체를 놓치는 일이 없었습니다.

게다가 CLI 기반이라는 점은, IDE에 갇혀 있지 않고 다양한 실험을 할 수 있는 유연한 환경을 제공해 주었습니다.

저희는 이 기능들을 활용해 바로 자동화에 도전했습니다.

클로드 코드 내부의 To-do list 생성 기능을 저희가 원하는 형태로 만들도록 가이드했습니다.

또 다른 핵심은 ‘'E2E 테스트 기반의 피드백 루프'를 구축한 것입니다. 아시다시피 LLM은 비결정적이라 결과물의 퀄리티가 보장되지 않습니다. 하지만 명확한 피드백 루프를 돌릴 수 있게 환경을 만들어주니, 클로드 코드가 그 안에서 스스로 길을 찾아 제대로 된 결과물을 가져오는 것을 확인했습니다.

그 결과, 저희는 자동화에 대한 확신을 가지고 이 방향을 계속 밀고 나가게 되었습니다.

신뢰할 수 있는 시스템을 위한 질문의 전환

저희 개발 프로세스를 더 깊게 살펴보기 전에, 최근 클로드 코드 팀이 발표한 영상 내용을 잠시 공유해 드리고 싶습니다. "프로덕션에서 어떻게 '바이브 코딩'을 하는가"라는 주제였는데, 저희는 여기서 두 가지 중요한 점을 발견했습니다.

첫 번째는 AI 코딩에 대한 '불신'입니다. 클로드 코드 팀은 지금의 우려를 과거 컴파일러 초창기 시절에 비유합니다. 당시에도 초기 컴파일러를 믿지 못해 많은 이들이 직접 어셈블리어를 확인했던 것처럼 말입니다. 하지만 생산성이 지수적으로 폭발하자, 인간이 그 결과를 감당할 수 없게 되면서 결국 컴파일러를 '강제로' 신뢰하는 단계로 넘어갔습니다.

AI 코딩도 마찬가지라는 겁니다. 지금은 몇 시간 단위의 작업만 자동화하지만, 곧 일주일치 작업을 자동화하는 시대가 올 것입니다. 그때 생산되는 코드의 양을 고려하면, 우리는 결국 AI를 신뢰하는 단계로 들어설 수밖에 없습니다.

그래서 저희는 '질문을 바꿔야 한다'는 결론을 얻었습니다. 'AI를 신뢰할 수 있느냐?'가 아니라, '어떻게 하면 책임감 있게 신뢰할 수 있는 시스템을 만들 것인가?'로 말입니다.

두 번째는 실패 원인입니다. '바이브 코딩'이 실패하는 주된 이유는 '기술 부채'와 '사이드 이펙트 관리 실패'입니다. 그래서 이를 관리하기 위해 작업을 '격리'하고 '인수 테스트'를 진행하라고 합니다. 특히 트리 구조의 가장 끝단, 즉 '리프 노드(leaf node)'에서만 '바이브 코딩'을 시도하라고 가이드합니다.

스펙 주도 개발(Spec Driven Development, SDD)의 기준

이걸 정리해서 저희 내부의 개발 기준을 만들어가고 있습니다. 저희는 '바이브 코딩'이라는 용어가 오해를 부를 수 있어, '스펙 코딩(Spec-coding)'이라고 부르기로 했습니다. 이미 많은 도구들이 '스펙 주도 개발(Spec-Driven Development)'을 시작하고 있어서 저희도 확신을 갖고 진행 중입니다.

위에서 말한 클로드 코드 팀의 두 가지 내용을 저희가 어떻게 해석하고 적용했는지 설명드리겠습니다.

책임감 있게 신뢰할 수 있는 시스템 : 스펙

먼저 '책임감 있게 신뢰할 수 있는 시스템'에 대한 저희의 답은 '스펙'입니다.

저는 개발자의 본질이 '요구사항'이라는 거대한 압축파일을 '논리'와 '코드'로 풀어내는 과정이라고 봅니다. 기술이 발전하며 어셈블리나 메모리를 몰라도 개발할 수 있게 되었듯, LLM 시대는 이 '코드 레이어' 자체를 한 단계 더 추상화하고 있습니다.

앞으로의 복잡성을 감당하려면, 이제 우리도 이 '압축된 형태(스펙)'로 개발을 관리해야 한다고 생각했습니다. 곧, '스펙이 코드가 되는 시스템'을 만들어야 한다고 결론 내렸습니다.

리프 노드에서 바이브코딩 : 코어 인프라 빼고 전부 다 리프 노드로?

두 번째로 '리프 노드(leaf node)에서 바이브 코딩'하라는 조언은, 저희는 발상을 전환해 봤습니다.

"만약 코어 인프라를 제외한 전부를 리프 노드로 만들면 어떨까?" 그렇게 되면 시스템 대부분을 AI 기반으로 개발할 수 있게 됩니다. 이는 AI 컨텍스트 엔지니어링, 즉 '컨텍스트 압축' 관점에서도 최적화된 구조일 거라 생각했고, 이 아이디어를 기반으로 현재 아키텍처를 계속 고민하고 있습니다.

스펙 문서 관리 방식: Task, Development, Feature

이제 저희 히로인스 팀이 해석한 SDD 스펙을 소개해 드리겠습니다. 다만 저희도 이제 막 시작하며 고도화하는 실험 단계임을 미리 말씀드립니다.

어, 현재 저희는 스펙 문서를 세 가지 기준으로 작성하며 깃허브에서 관리하고 있습니다.

첫째, Task 문서입니다. 이것은 실제 주어진 업무(Task) 단위의 문서입니다. 개발 초기에 이 Task 문서를 기반으로 설계를 잡고, 유스케이스(use case)와 엣지 케이스 등을 정리합니다. 팀원들은 이 문서를 바탕으로 초기 설계를 함께 리뷰하며 논리적 허점이 없는지 확인한 뒤, 다음 단계인 개발 문서로 넘어갑니다.

둘째, Development 문서입니다. 저희는 이 문서를 사실상 '코드'와 동일한 수준으로 취급하려고 노력하고 있습니다. 물론 자연어는 코드보다 명확한 규칙(Rule)을 세우기 어렵다는 한계가 있습니다. 하지만 저희는 피어 리뷰와 AI 리뷰를 통해, 이 문서가 논리적으로 놓치는 부분이 없도록 작성하는 것을 원칙으로 삼고 있습니다. 이 문서는 특정 언어나 프레임워크에 종속되지 않고 '논리' 자체에만 집중하는 문서이기에, 저희가 최대한 챙기려는 부분입니다.

셋째, Feature 문서입니다. 이 문서는 '단일 원천 소스(Single Source of Truth)' 역할을 합니다. Task 문서는 업무 흐름에 따라 파편화되기 쉬워서, 그 조각들만으로는 하나의 기능 전체를 설명하기 어렵습니다. 그래서 저희는 이 Feature 문서를, AI가 해당 기능의 전체 맥락을 이해하는 핵심 도구로 활용하고 있습니다.

위 장표는 문서 예시입니다. 왼쪽은 신규 개발 건의 Task 문서 예시인데요, 보시다시피 프론트/백엔드 구분 없이 유저의 행동 단위나 개체 단위를 기준으로 설계를 진행합니다.

그리고 오른쪽 Development 문서는 코드와 1:1로 매핑되는 API나 컴포넌트 명세입니다. 이렇게 Mermaid로 논리 흐름을 시각화하고, 더 디테일한 논리 문장을 완성한 뒤 엣지 케이스까지 정리하는 방식입니다.

고통에서 확신으로: SDD 도입 후 팀의 변화

위에서 말씀드린 것처럼, 저희는 아직 이 방식을 계속 실험 중이며 여러 가지를 시도하고 있습니다. 그래서 팀 내부에서 지속적으로 피드백을 주고받고 있습니다.

팀 내 회고 결과, 솔직히 처음에는 '고통'이었습니다. 뭐, 다들 아시겠지만 개발자들은 대부분 문서 쓰는 것을 싫어합니다. 게다가 초기에는 문서의 '구조' 자체를 잡아가면서 써야 했기 때문에, 더 불확실한 상태로 문서를 작성해야만 했습니다. (이 자리를 빌려 팀원들에게 다시 한번 감사함을 표합니다.)

하지만 그렇게 고통의 한 사이클을 이겨내고 끝내고 나니, 저희는 회고를 통해 '확신'을 가지게 되었습니다. 세 가지 변화가 있었습니다.

개발 안정성 상승
개발 속도 상승
언어 프레임워크 제약 사라짐

가장 인상 깊었던 변화는 첫 번째로 '안정감'이었습니다. 과거 스타트업 특성상 속도가 중요했기에, 저희는 설계의 완벽함보다는 일단 코드에 손이 먼저 갔습니다. 그러다 보면 개발 도중에야 논리적 허점, 엣지 케이스, 설계 미스, 심지어 기획 미스까지 발견되곤 했습니다. 이런 문제들이 오히려 개발 일정을 딜레이시켰고, QA를 진행하면서도 불안감이 컸습니다. 하지만 이제는 정반대가 되었습니다. 오히려 개발 시간은 줄어들고 설계 시간이 늘어나면서, 심리적으로나 논리적으로 훨씬 큰 안정감이 생겼습니다.

두 번째로는 실제로 '속도'도 빨라졌습니다. 내부적으로 두 명이 2~3주 정도 걸리던 작업을, 지금은 비슷한 규모의 작업을 혼자서 1주일이면 끝낼 수 있게 되었습니다. 심지어 이 1주일조차 대부분이 문서 작성 시간이라, 앞으로 이 시간은 더 단축할 수 있겠다고 팀 내부에서 보고 있습니다.

세 번째로는 팀 내 '업무 허들'이 많이 무너졌습니다. 물론 백엔드의 디테일한 ERD나 캐시 레이어, 프론트엔드의 상태 관리 로직 등은 담당자가 전문성을 가지고 봐줘야 합니다. 하지만 API의 논리 흐름, 컴포넌트의 논리 흐름 자체는 이제 프론트엔드/백엔드 개발자 구분 없이 누구나 이해하고 작성할 수 있게 되었습니다. 모두가 '풀스택'처럼 문서를 작성할 수 있게 된 것입니다.

결과적으로 저희는 이 SDD 방식에 대해 큰 확신을 얻었고, 앞으로 이 프로세스를 더욱 가속화하기 위해 노력하고 있습니다.

앞으로의 방향과 상상하는 미래

마지막으로, 현재 저희의 시스템은 아주 극초기 버전입니다. 앞으로 이 방식을 어떻게 개선해 나갈지, 그 대략적인 방향성을 공유해 드리고자 합니다.

첫째, 스펙 문서의 구조화 및 작성 자동화입니다. 개발 시간은 줄었지만, 보신 것처럼 그만큼 설계 시간이 늘어났습니다. 저희는 이제 이 '설계' 과정 자체도 피드백 루프를 기반으로 고도화할 계획입니다. 단순히 AI와 대화하며 문서를 작성하는 것을 넘어, '스펙 에이전트'가 이 문서를 스스로 고도화하도록 만들려 합니다. 어, 나아가서는 GPT, Gemini, Claude가 삼자대화를 통해 최종 결론을 도출하는 구조로 시스템을 만들어 가려고 생각하고 있습니다.

둘째, 프론트엔드(Front) E2E 자동화입니다. 백엔드의 경우 E2E 피드백 루프를 통해 스스로 코드를 완성시켜 나가고 있어 API 완성도가 매우 높습니다. 다만 저희 프론트 쪽은 아직 이 E2E가 적용되지 않아, 개발자가 부분적으로 자동화를 돌리고 있습니다. 그래서 이 부분을 고도화하기 위해 E2E 피드백 루프를 도입하려 합니다. 또한, 프론트엔드 아키텍처 역시 어떻게 하면 컨텍스트를 효율적으로 압축하며 관리할 수 있을지 계속 고민하며 고도화할 생각입니다.

마지막은 작업의 병렬 실행입니다. 이 모든 것이 구현됐을 때 저희가 상상하는 미래는 이렇습니다. 업무 시간의 대부분을 (지금처럼) 코딩이 아니라 '문서 작성'과 '설계'에 쏟습니다. 그리고 퇴근할 때, 완성된 스펙을 클로드 코드에게 맡기고 퇴근합니다. 다음 날 아침에 출근하면, 클로드 코드가 밤새 작성한 PR(Pull Request)을 리뷰하고 배포하는 시나리오입니다.

더 나아가서는, 저희가 잘 구축해 둔 'Feature 기반 문서'들을 활용해 비개발자분들도 자연어로 편하게 PR을 요청하는 워크플로우까지 구상하고 있습니다.

그런데 마침 클로드 코드 팀에서 웹 기반으로 이런 병렬 시스템을 돌릴 수 있는 구조를 공개했습니다. 이러한 도구들로 더욱 빠르게 병렬화를 실험해 볼 수 있을것 같습니다.

이상, 히로인스 팀에서 어떻게 클로드 코드로 자동화를 시도하고 있는지 그 도전기를 공유드렸습니다. 부족한 발표 들어주셔서 감사합니다.

Q&A

Q: 클로드 코드 사용할 때 화면을 보지 않으면 작성을 안 하는 경우가 있던데 이럴 때 해결 방법이 있으신가요?

화면을 보지 않을 때 작성이 안 되는 현상은 결국 터미널 세션이 끊어지면서 발생하는 문제입니다. 제가 직접 테스트해보진 않았지만,tmux와 같이 터미널 세션을 유지해주는 도구를 쓰면 좀 나아진다고 들었습니다. 저 같은 경우는 이 부분을git worktree처럼 병렬 실행을 돕는 여러 도구들을 함께 사용해서 해결하고 있습니다.

Q. 4.5로 업데이트되면서 토큰 사용량이 금방 소진되는데, 어떻게 해결을 하시는 편인가요?

두 번째로, 토큰 사용량이 금방 소진되는 문제에 대해서는 저도 공감합니다. 저 역시 토큰을 많이 사용하는데, 많을 때는 하루에 10억 토큰까지도 쓰곤 했습니다.

저는 이 문제를 '어쩔 수 없는 비용'으로 받아들이고, 오히려 고민의 방향을 전환했습니다. '토큰을 어떻게 아낄까'가 아니라, '차라리 토큰을 더 빨리 소모하더라도 생산성을 어떻게 극대화할 수 있을까'에 집중하고 있습니다. 쉽게 말해서 토큰의 소모량보다 더 정확한 결과물에 집중하고 있습니다.

물론, 최근에 4.5 하이쿠(Haiku) 모델이 공개되었으니, 이 모델을 활용하시면 토큰을 아끼면서 작업하시는 데 도움이 되지 않을까 생각합니다.

Q: 백앤드에서 바이브 코딩 시 스키마의 변경이나 DML, DDL 의 권한을 제공하나요? 제공한다면 서비스 안정성은 어떻게 확보하나요?

일단 DDL이나 DML 같은 데이터베이스 변경 작업은 AI에게 당연히 권한을 주지 않습니다. 그 부분은 현재 저희 팀 개발자가 주도적으로 설계를 진행하고 있습니다.

설계 과정에서 AI를 '디스커션 파트너'처럼 활용하며 논의를 하기는 하지만, 실제 운영 중인 프로덕션 DB를 직접 건드리게 할 수는 없으니까요. 결국 이 부분은 개발자가 명확히 책임지고 진행하는 구조입니다.

클로드코드팀에서는 리프노드 말고 루트노드에서는 개발자가 운전대를 잡아야한다고 표현하는데, 저희도 DB뿐 아니라 루트노드에 해당하는 인프라 레이어는 개발자가 직접 컨트롤 하고 있습니다.

Q: 규칙을 제공할 때 간헐적으로 컨텍스트 부족등의 이유로 규칙을 무시하고 실행하는 경우가 종종 있던데 이 강제적으로 반드시 지켜야할 규칙을 선언시키는 노하우가 있을까요?

그 문제는 저도 겪어봤는데, 컨텍스트가 부족해서라기보다는 오히려 너무 많은 내용이 한 번에 들어가거나 작업량이 길어질 때 AI가 규칙을 놓치는 것 같습니다. 실제로 AI도 처음부터 모든 컨텍스트를 다 넣어서 “해줘” 하면, 사람처럼 처음과 끝만 기억하고 중간 내용은 잘 잊어버린다고 합니다.

그래서 저는 '반드시 지켜야 하는 규칙'은 '클로드 마크다운'에 넣는 것을 원칙으로 하고 있습니다.

그리고 컨텍스트 유실 문제를 해결하기 위해, 작업을 잘게 쪼개고 각 작업에 맞는 컨텍스트만 그 순간에 제공하려고 노력합니다. 예를 들어 10가지 작업을 시켜야 한다면, 10가지에 필요한 문서를 한 번에 다 주는 것이 아니라 To-do list를 활용해서 각 단계를 진행할 때마다 필요한 문서를 따로 읽도록 지시합니다.

가령, 개발 초기에는 테스트 코드 가이드를 읽게 하지 않고, 마지막에 '테스트 코드를 짜야 할 때' 비로소 테스트 코드 가이드를 읽게 하는 식으로 컨텍스트를 분리하는 거죠.

이렇게 강제적인 규칙은 마크다운에 넣고, 작업별 컨텍스트는 분리해서 제공하는 방식으로 대응했을 때 대부분의 규칙이 잘 지켜졌습니다. 그럼에도 놓친 게 있다면, to-do list 중에 리뷰 단계를 넣어서 그걸 지켰는지를 확인했습니다.

최근에 나온 '클로드 스킬스' 기능과 ‘sub agent’ 기능을 활용하면 context 관리가 더 쉬워질 것 같습니다.

➡️ [참가하기] 클코나잇 딥다이브: AI 에이전트 오케스트레이션부터 DB 마이그레이션까지

Q: 혹시 github에서 나온 spec kit을 현업에서 사용해보신 적이 있나요? 현재 사용하시는 SDD와 비교할 때, 어떤 차이가 있을까요?

저희도 스펙 킷을을 내부적으로 검토해 봤습니다. 그런데 스펙 킷이 저희와 잘 맞지 않는다고 느낀 지점은, 이 방식이 기술을 사용하는 '의도'를 파악하는 데 집중한다는 점이었습니다.

이러한 특징은 저희처럼 이미 운영 중인 제품보다는, 오히려 새로운 프로덕트를 시작하는 단계에 더 유용하다고 판단했습니다. 그래서 킷의 내용을 저희 상황에 맞게 해석하고 참고하여, 저희 팀만의 자체적인 SDD를 개발하는 쪽으로 방향을 잡았습니다.

Q: 코드 컨벤션처럼 문서 작성 컨벤션이 있나요?

기본적으로 컨벤션이 있습니다. 다만 자연어라는 특성상 너무 빡빡한 룰을 두기보다는, AI를 통해 작성하고 리뷰, 수정하는 과정을 거치며 정해진 포맷을 계속 지켜나가는 방식으로 운영하고 있습니다.

Q: 문서가 꼬이면 코드보다 더 이해하기 어려울 것 같은데, 어떻게 보완하시나요?

문서의 복잡성에 대해서는 저도 어느 정도 동의합니다. 하지만 관점을 바꿔보면, 코드는 스니펫 조각들로 여러 파일(많으면 10~20개)에 흩어져 있지만, 문서는Mermaid등을 활용해 그 모든 흐름을 한 장으로 정리할 수 있다는 강력한 장점이 있습니다. 실제로 저희 팀에서는 복잡한 로직도 한 장의 문서로 훨씬 쉽게 이해했습니다.

물론, 이 문서들을 잘 관리해야만 합니다. 그래서 저희는 공유되는 문서들을 코드처럼 관리합니다. 여러 곳에서 쓰이는 공통 스펙은 '공용 문서'로 만들고, 각 문서에서 이 공용 문서를 마크다운 링크로 참조하는 구조로 작업하고 있습니다.

Q. 요청한대로 구현이 되었는지에 대한 검증 노하우가 있으실까요? 테스트 코드가 가장 기본이겠습니다만.

맞습니다. 저희는 '인수 테스트(Acceptance Test)'를 원칙으로 합니다. 클로드 코드 팀에서도 이와 비슷한 답변을 했는데, 결국 E2E 테스트처럼 실제 유저의 행동 시나리오를 기반으로 테스트하는 것을 핵심 원칙으로 삼으라고 조언합니다.

저희 팀 역시 이 접근 방식에 전적으로 동의하며, 스펙 문서를 작성할 때 '테스트 케이스' 항목을 가장 중점적으로 검토하고 있습니다.

Q. 문서 스펙을 Gemini와 GPT, Cladue 가 검토하고 개선하는 것을 좀더 자세하게 설명해주실 수 있으까요?

네, 이 부분은 저희가 현재 구현해 나가고 있는, 아직은 실험 단계에 있는 기능입니다.

어떤 분이 '3개의 LLM이 서로 삼자 합의에 이를 때까지 대화 루프를 돌린다'는 컨셉을 공유해 주셨는데, 저희는 그 아이디어에 기반을 두고 있습니다.

저희가 만들려는 시스템은 이렇습니다. 우선, 기존의 '스펙 규칙(Spec rules)'과 '피처(Feature) 문서'를 LLM에게 베이스 컨텍스트로 제공합니다. 그다음, 새로 작성된 개발/설계 문서를 검토시키며 논리적으로 빠진 부분이나 결함이 없는지 확인하게 합니다.

이 과정에서 Gemini, GPT, Claude가 서로 토론하고 의견을 조율하며, 최종적으로 세 LLM이 모두 '논리적 문제가 없다'고 합의하면, 비로소 해당 설계를 '문제없음'으로 판단하는 시스템을 구현하려고 합니다.

클로드 코드 딥다이브 무료 세미나에 참여해보세요!

자세한 내용은 아래 이미지를 눌러 확인해보세요.