AI 개발 워크플로우의 분절화와 산출물 정의
AI 코딩의 작업 방식이 단일 요청에서 단계별 산출물 분리 구조로 바뀐다. LLM(대규모 언어 모델)은 한 번의 응답에서 처리할 수 있는 출력량과 사고 범위에 제한이 있어, 테스트 작성과 구현을 동시에 지시할 경우 코드 완성도에 자원이 집중되어 테스트 품질이 낮아지는 현상이 발생한다.
이를 해결하기 위해 TDD(테스트 주도 개발) 방식을 AI 작업에 적용하여 산출물을 다음과 같이 분리한다.
- `/red`: 실패하는 테스트 코드만 작성
- `/green`: 테스트를 통과하는 최소한의 기능 구현
- `/refactor`: 테스트를 유지하며 코드 구조 개선
전체 개발 파이프라인은 '명세 작성 $\rightarrow$ 실패 테스트 생성 $\rightarrow$ 기능 구현 $\rightarrow$ 리팩터링 $\rightarrow$ 검증 $\rightarrow$ 커밋'의 순서로 구성된다. 각 단계는 독립적인 입력, 출력, 제약 조건을 가지며 함수처럼 작동한다. 이 과정에서 사용되는 마크다운(Markdown) 문서는 단순한 설명서가 아니라 AI의 행동과 출력 형식을 결정하는 실행 규칙이자 새로운 코드 계층으로 기능한다. 이는 하나의 스킬에 하나의 책임만 부여하는 단일 책임 원칙과 지식-규칙을 분리하는 모듈화 원칙을 AI 프롬프트 설계에 적용한 결과다.
비결정성 제어를 위한 결정적 하네스(Harness) 구조
LLM의 가장 큰 기술적 제약은 동일한 입력에도 결과가 달라지는 비결정성이다. AI가 대규모 리팩터링을 수행할 때 기능이 작동하더라도, 삭제된 코드가 정말 불필요했는지 또는 새로운 부작용이 발생했는지를 AI 스스로 완벽하게 판단하기 어렵다. AI에게 검증을 다시 맡기는 방식은 검증 기준 자체를 왜곡할 위험이 있어 신뢰성을 확보할 수 없다.
따라서 비결정적인 AI 출력을 안정적인 시스템으로 묶기 위해 '하네스(Harness)'라는 결정적 검증 장치가 필요하다. 하네스는 AI가 작업 범위 내에서 오류를 누적하지 않도록 단계별로 배치하는 검증 게이트를 의미하며, 다음과 같은 결정적 도구(Deterministic Tools)로 구성된다.
- 컴파일러 및 타입 검사기: 구문 오류 및 타입 불일치 즉시 확인
- 자동화된 테스트: 정의된 오라클(Oracle, 정답 기준)에 따른 기능 검증
- 린터(Linter) 및 정적 분석: 코드 스타일 및 잠재적 결함 탐지
- 스키마 검사: 데이터 구조 및 인터페이스 준수 여부 확인
- 승인 절차 및 변경 범위 제한: 사람이 직접 개입하여 변경 범위 통제
하네스는 AI가 생성한 결과물이 재현 가능한 기준을 통과했는지 판단하는 최종 필터 역할을 하며, 한 단계의 작은 오류가 다음 단계로 전이되는 것을 방지하는 인프라로 작동한다.
구현 위임 전략과 추상화 계층의 변화
개발자가 AI에게 구체적인 구현 방법을 지시할 때 발생하는 문제는 '앵커링(Anchoring)' 현상이다. 사용자가 제시한 초기 구현 방식에 AI가 고착되면, 더 적절한 표준 방식이 있더라도 예외 처리를 반복적으로 추가하는 식으로 코드가 복잡해지는 부작용이 나타난다.
이를 방지하기 위해 개발자는 '어떻게(How)' 구현할지가 아니라 '왜(Why)' 필요하고 '무엇(What)'을 달성해야 하는지 목표와 맥락을 위임하는 방식으로 전환해야 한다. 효과적인 위임 구조는 다음과 같은 순서로 진행된다.
1. 요청 의도 분석
2. 부족한 정보에 대한 질문
3. 해결 계획 제시
4. 사용자 승인 후 실행
이러한 변화는 개발자가 다루는 추상화 계층의 이동을 의미한다. 과거의 개발자가 기계어에서 고수준 언어로, 다시 프레임워크로 추상화 계층을 높여왔다면, 이제는 AI 자체가 하나의 추상화 계층이 되었다. 이제 개발자의 전문성은 단순한 코드 타이핑이 아니라, AI가 잘못된 목표에 고착되지 않도록 작업 범위를 설정하고, 비결정적인 출력을 결정적인 제품으로 전환하는 통제 능력에서 결정된다. 특히 요구사항이 불완전하거나 복잡한 도메인 규칙, 대규모 시스템 상호작용과 같이 '천장이 높은 문제'에서는 여전히 인간의 기술적 깊이를 바탕으로 한 판단과 책임이 필수적이다.
