왜 나는 Claude가 코드 작성 전에 스스로 논쟁하도록 하는가

Source: Dev.to

“그냥 코딩해” 문제점

AI에게 계획 없이 코딩을 시키면 이런 일이 일어납니다:

• 추측한다 – 코드베이스에 대한 컨텍스트가 없으니 패턴을 만들어 냅니다.
• 자기 자신을 확인한다 – 한 목소리, 한 맹점. 도전이 없습니다.
• 빠르게 배포한다 – 첫 번째 아이디어가 바로 구현이 됩니다.

문제를 발견할 때쯤이면 이미 나쁜 접근 방식에 커밋된 상태입니다. 재작업은 비용이 많이 듭니다.

내가 대신 하는 방법

Claude가 스스로 논쟁하도록 합니다.

코드가 작성되기 전에 구조화된 대화를 강제합니다:

Me: "Add input validation to the login form"

Peter (Planner): "Here's the approach: validate email format,
check password strength, sanitize inputs before DB..."

Neo (Critic): "What about rate limiting? You're checking format
but not preventing brute force. Also, the existing auth module
already has a sanitize() function – don't reinvent it."

Peter: "Good catch. Revised plan: reuse auth.sanitize(),
add rate limiting at the route level, then validate format..."

계획이 비판을 견디고 나서야 Gary(구현자)가 코드를 작성하고, Reba(QA)가 병합 전에 검토합니다.

계획 → 비판 → 구현 → 검증

왜 효과가 있는가

마법이 아니라 구조일 뿐입니다:

• 다양한 관점이 한 목소리가 놓치는 맹점을 잡아냅니다.
• 코딩 전 계획은 “첫 아이디어가 바로 배포” 함정을 방지합니다.
• 명시적 비판은 가정이 버그가 되기 전에 드러나게 합니다.
• 병합 전 검토는 계획에서 놓친 부분을 잡아냅니다.

이 패턴은 어디서든 나타나고 있습니다—Devin, Cursors 에이전트 모드, 진지한 AI 코딩 워크플로우—모두 같은 구조로 수렴하고 있습니다. 빌드하기 전에 계획하세요.

구현 방식

Claude Code용 팀 스킬 세트를 만들었습니다:

이들은 같은 컨텍스트 안에 있는 페르소나이며, 별개의 에이전트가 아닙니다. 서로를 듣고, 끼어들고, 실시간으로 도전할 수 있습니다.

작업을 주면 됩니다:

/team "add input validation to login"

그들은 작업 흐름을 스스로 정합니다. Peter가 계획하고, Neo가 비판하고, Gary가 구현하고, Reba가 검증합니다. 코드를 직접 보기 전에 이미 논쟁을 거친 코드를 얻게 됩니다.

사용해 보기

스킬은 오픈 소스입니다:

git clone https://github.com/HakAl/team_skills.git
cp -r team_skills/* ~/.claude/skills/

그 다음 Claude Code에서:

/team "your task here"

그들이 논쟁하는 모습을 지켜보세요. 더 나은 코드를 배포할 수 있습니다.

이 글을 쓴 팀: Peter가 계획하고, Neo가 “설교하지 마라”고 말하고, Gary가 작성했으며, Reba가 승인했습니다. 메타적이지만 사실입니다.