AI VIDEO BRIEFING

클로드 코드 스킬로 만드는 AI 개발 프로세스: 두 개의 루프와 검증 우선 전략 정리

1년 넘게 직접 코드를 쓰지 않았다는 개발자가 코딩 에이전트로 기능을 출시하기까지 쓰는 스킬 묶음을 공개했다. 기획을 도는 바깥 루프와 티켓을 처리하는 안쪽 루프, 그리고 검증 우선 전략이 핵심이다.

코딩 에이전트를 굴리는 두 개의 루프 — 검증 계획을 먼저 쓰는 개발 프로세스 영상 대표 이미지

핵심 메시지

  • 코딩 에이전트용 스킬은 특별한 기술이 아니라 재사용 가능한 프롬프트, 즉 에이전트를 특정 절차로 안내하는 워크플로 문서다.
  • 개발 흐름은 에픽 단위로 한 번 도는 바깥 루프(요구사항 문서 → 아키텍처 문서 → 티켓 분할)와 티켓마다 도는 안쪽 루프(맥락 적재 → 계획 → 구현·검증 → 리뷰·PR)로 나뉜다.
  • 무엇과 왜를 정하는 대화와 어떻게 만들지 정하는 대화를 분리하고, 계획과 구현도 서로 다른 대화에서 진행해 맥락이 상하는 것을 막는다.
  • 계획 문서에서 가장 중요한 부분은 구현 순서가 아니라 검증 전략이며, 코드를 한 줄도 쓰기 전에 무엇을 어떤 명령으로 어떻게 확인할지 먼저 적는다.
  • 검증 전략이 갖춰지면 에이전트가 스스로 테스트를 돌리고 고치기 때문에, 사람이 받아 보는 결과물이 에이전트의 첫 시도가 아니게 된다.

쉽게 이해하기

발표자는 1년 넘게 자기 손으로 코드를 한 줄도 쓰지 않았다는 말로 영상을 연다. 예전에는 에이전트를 한 줄씩 만들어 보이던 사람이 이제는 개발의 모든 단계를 코딩 에이전트에 맡기고 있고, 반년째 안정적으로 쓰고 있는 그 방식의 실체가 스킬 묶음이라는 것이다. 스킬은 거창한 프레임워크가 아니라 에이전트를 정해진 절차로 안내하는 재사용 가능한 프롬프트다.

그는 이 묶음을 통째로 받아들이라고 권하지 않는다. 스킬 몇 개만 골라 쓰거나 아이디어만 가져가도 된다는 점을 반복해 강조하고, 전체 개발 생애주기를 통째로 정의해 버리는 다른 프레임워크들과의 차이도 이 지점에서 찾는다. 설치는 클로드 코드 플러그인 형태로 두 개의 명령이면 끝나고, 다른 코딩 도구를 쓴다면 저장소 주소를 에이전트에게 건네 옮겨 달라고 시키면 된다고 설명한다.

프로세스는 두 개의 루프로 정리된다. 바깥 루프는 에픽마다 한 번 도는 기획 단계다. 요구사항 문서 스킬이 사용자를 인터뷰하듯 질문을 던져 무엇을 왜 만드는지 끌어내고, 별도의 대화에서 아키텍처 문서가 어떻게 만들지를 정한다. 세 번째 스킬은 이 두 문서를 입력으로 받아 의존 관계를 정리하고 병렬로 진행할 수 있는 일을 갈라 티켓으로 쪼갠다.

안쪽 루프는 티켓 하나를 처리하는 과정이다. 먼저 코드베이스를 훑어 맥락을 적재하고, 같은 대화에서 계획 스킬로 넘어간다. 계획 단계에서도 에이전트가 먼저 질문을 던지는데, 언어 모델이 자신 있게 잘못된 가정을 세우는 것이 가장 위험하기 때문이라는 설명이다. 구현은 다시 새 대화에서 시작한다. 계획 대화는 이미 길어져 있고, 모델도 정보가 넘치면 판단이 흐려지는 구간이 있기 때문이다.

영상에서 가장 힘이 실린 대목은 계획 문서의 검증 전략이다. 단위 테스트와 통합 테스트, 확인할 예외 상황, 린트와 타입 검사에 쓸 실제 명령, 브라우저 자동화를 포함한 수동 확인 방법까지 코드를 쓰기 전에 적어 둔다. 발표자는 이를 에이전트를 위한 테스트 주도 개발이라 부르며, 계획을 검토할 때 다른 항목보다 검증 부분에 시간을 쓰라고 권한다. 에이전트가 계획에 적힌 검증을 직접 돌리고 스스로 고칠 수 있으므로, 사람이 확인하는 산출물은 첫 시도가 아니라 몇 차례 자체 수정을 거친 결과가 된다. 마지막에는 사람이 코드 리뷰와 수동 확인을 하고 풀 리퀘스트를 올린 뒤 다음 티켓으로 넘어가는 것으로 한 바퀴가 끝난다.

주요 인사이트

  • 대화를 나누는 기준이 곧 설계다. 무엇과 왜, 어떻게, 그리고 구현을 각각 다른 대화로 분리하는 규칙은 단순하지만 맥락 과부하라는 실패 원인을 정면으로 겨냥한다.
  • 검증을 먼저 쓰라는 원칙은 모델이 좋아질수록 더 강해진다. 목적지와 확인 방법만 정확히 주면 경로는 에이전트가 알아서 만든다는 전제가 성립하기 때문이다.
  • 계획 문서에 늘 같은 형식을 강제하는 것은 결과를 예측 가능하게 만드는 장치다. 문제 정의, 해결 방향, 범위 밖 항목, 참조할 파일과 문서, 작업 단위 계획이 매번 같은 자리에 온다.
  • 스킬을 고치는 방법조차 손으로 쓰지 않고 에이전트에게 맡긴다는 점이 흥미롭다. 절차 문서 자체가 에이전트가 다루는 산출물이 되는 셈이다.
  • 티켓 분할 스킬이 사내 문서 도구에 연결될 수 있게 설계된 대목은, 이 방식이 개인 실험이 아니라 기존 업무 체계와 붙는 것을 전제하고 있음을 보여 준다.

자주 묻는 질문

여기서 말하는 스킬은 정확히 무엇인가요?

코딩 에이전트가 특정 절차를 따르도록 안내하는 재사용 가능한 프롬프트 문서입니다. 인자를 받도록 만들어 두면 제품 아이디어나 티켓 경로 같은 입력을 넘길 수 있고, 에이전트는 그 안에 적힌 질문 목록과 출력 양식을 따라 문서를 만들어 냅니다.

계획과 구현을 왜 다른 대화에서 해야 하나요?

계획 대화는 인터뷰와 코드베이스 탐색으로 이미 길어져 있고, 언어 모델은 정보가 지나치게 쌓이면 판단이 흐려지는 구간이 있습니다. 구현에 필요한 맥락은 계획 문서 하나로 충분하므로, 새 대화에서 그 문서 경로만 넘겨 시작하는 편이 안전합니다.

계획을 검토할 때 어디를 가장 신경 써야 하나요?

검증 전략과, 에이전트가 만들 대상을 제대로 이해했는지입니다. 참조 파일 목록이나 작업 순서는 분량이 많아 부담스럽지만, 완료의 정의와 확인 방법이 정확하면 나머지는 에이전트가 스스로 맞춰 갈 여지가 큽니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식

#클로드코드#AI코딩#개발프로세스#테스트전략#에이전트