코딩이 아니라 정의를 컴파일한다: AI 시대의 개발 루프

예전에 개발이 갑자기 쉬워졌던 순간

개발을 처음 시작했을 때, 나는 이런 걸 깨달았다.

머릿속에 있는 걸 바로 코드로 못 옮긴다.
단계를 쪼개서 생각해야 구현이 된다.

그때부터 일이 달라졌다.
“한 번에 완성”이 아니라 “단계별로 조립”하는 방식으로 바꿨기 때문이다.

AI와 일하면서, 같은 깨달음이 다시 떠올랐다

AI와 협업을 하다 보면 이런 경험을 하게 된다.

• 이제는 구현만 하는 게 아니라
• 기획부터 디자인 감각, 개발 명세까지
• AI가 실행할 수 있는 정의를 먼저 만들어야 한다

그리고 이런 관점이 생긴다.

구현 로직을 쪼개는 게 아니라,
상위 정의(일 전체)를 단계적으로 쪼개서 전달해야 한다.

나는 “정의를 넣고 → 컴파일된 결과를 보고 → 정의를 수정”하는 루프를 앞으로 더 의식적으로 써볼 생각이다.

정의를 컴파일한다는 게 무슨 뜻인가

AI에게는 내가 주는 입력이 곧 “소스”다.
그 소스가 애매하면, 컴파일은 되더라도 결과가 흔들린다.

그래서 나는 앞으로 “코드 고치기” 이전에 이 질문을 먼저 던져보려 한다.

• 결과가 이상한 이유가 구현 문제인가?
• 아니면 내가 준 정의(명세) 문제인가?

많은 “비슷하지만 다름”은 구현자의 문제가 아니라 정의의 누락일 수 있다.

내 루프를 이렇게 바꿔볼 계획이다

1) 정의 레이어를 만든다(최소 파일 세트)

• GO.md: 목표/성공 기준/하지 않는 것
• PRD.md: 플로우/요구/비요구/엣지(로딩·에러·빈)
• IA.md: 화면 구조/이동/섹션
• BACKLOG.md: 작업 단위/우선순위/Done

이게 “대화”를 대신하는 기억 장치가 된다.

2) 작업마다 ‘스위치’로 모드를 고정한다

작업이 바뀌면 기준도 바뀐다(실험/운영/리팩터).
AI는 이걸 자동으로 못 따라올 수 있으니, 스위치로 잠가보려 한다.

• mode: build | ops
• level: patch | feature | prod
• priority: speed | quality
• scope: minimal | normal

스위치를 잠그면, 내가 길게 말하지 않아도 결과가 덜 흔들릴 수 있다.

3) 컴파일 결과를 보고 “정의”를 업데이트한다

수정의 1순위를 “대화”가 아니라 문서로 두는 연습을 해보려 한다.

• 동일성 규칙이 빠졌다면 → PRD에 1줄 추가
• 완료 기준이 빠졌다면 → DoD에 체크 추가
• 운영 제약이 빠졌다면 → RUNBOOK에 규칙 추가

이렇게 하면 다음 반복에서 비용이 내려갈지 확인해볼 수 있다.

에이전트 매니저 vs 개발 에이전트: 역할을 분리해보려 한다

AI와 일할 때 가장 유효해 보이는 접근은 역할 분리다.

• 에이전트 매니저(정의/조율)

  • “무엇을/왜/어디까지/끝 기준” 확정
  • 작업 분해, 질문/가정 강제, 리스크 관리
  • 문서(GO/PRD/IA/Backlog) 업데이트

• 개발 에이전트(구현)

  • 정해진 스펙대로 코드/컴포넌트/테스트 생산
  • 회귀/엣지케이스 반영(명세 범위 내)

디테일 수정은 직접 붙는 게 빠를 때도 있다.
하지만 구조가 커지는 순간(관리자 기능/권한/데이터)에는 매니저가 더 필요해질 가능성이 크다.

마무리: 나는 ‘코더’가 아니라 ‘정의 컴파일러’가 되어가려 한다

AI 시대의 개발은 “코드를 쓰는 일”이 줄어든다기보다,
“정의를 컴파일 가능하게 만드는 일”이 전면으로 올라오는 느낌이 있다.

• 정의를 넣고
• 컴파일 결과를 보고
• 틀린 부분을 정의에 반영하고
• 다시 컴파일한다

나는 앞으로 이 루프를 의식적으로 반복해볼 계획이다.
그리고 이 방식이 실제로 얼마나 효율적인지(어디서 막히는지)는, 직접 해보고 판단하려 한다.
해보고 잘 되는지는, 다음에 공유할 기회가 있으면 공유하겠다.