AI와 개발한 1년 — 사라진 건 없고, 달라진 건 많다

AI 에이전트와 1년여간 혼자 개발하며, 코드 작성보다 에이전트의 진행과 결과를 통제하고 개선하는 개발 과정을 만드는 데 집중한 경험을 공유해봅니다. 시리즈로 여러편 써보려는데 그 첫번째 편입니다. 하네스 엔지니어링을 에이전트 설정과 도구 조합을 넘어, 코드 생산성이 급증한 조건에서 품질을 유지하도록 개발 과정 전체를 다시 디자인한 경험, 그리고 설계 → 구현 → 검증의 결과가 다시 설계와 규칙의 개선으로 돌아오는 닫힌 피드백 루프를 설명합니다.

설계와 규칙을 구현 컨텍스트 밖에서 검토

• 구현 과정의 맥락을 공유한 리뷰어는 전제와 사각지대도 공유하기 쉬우므로, 고정된 코드 스냅샷을 독립된 세션에서 검토
• 검토자는 코드뿐 아니라 외부 사례와 공식 문서도 확인하고, 별도의 검증자가 지적의 근거를 재확인
• 구현 중 쌓인 규칙 위반 기록을 외부 감사에 활용해 규칙을 신설·개정·폐지하고, 다음 감사에서 반영 여부를 추적
• 규칙 작성에도 원칙을 적용: 규범과 현황 분리, 예외 목록 대신 판정 기준 작성, 다수의 관행을 근거로 삼지 않기, 위반 코드에서도 규칙이 호출되는지 확인

리뷰는 수렴하게 만들고, 머지 뒤에도 관찰

• PR별 지적 장부를 유지해 이전 지적의 해결 여부를 먼저 확인하고, 작성자의 해명을 읽기 전에 코드로 판정
• 수정하지 않은 코드에 대한 새 지적은 심각한 문제로 제한해 리뷰가 끝없이 반복되는 현상을 줄임
• 머지 이후에는 코드 생존율과 디렉터리·파일·함수의 복잡도 추이를 관찰
• 반복 재구현이나 중복의 징후가 보이면 해당 버전의 diff로 내려가 실제 변경을 조사
• 에이전트의 완료 보고 대신 실행 기록과 코드 변경을 확인하며, 판단은 에이전트에 맡기되 계수와 비교는 실행 도구가 담당

사람의 일은 스펙과 이해를 쌓는 쪽으로 이동

• 대량 코드 생성보다 생성 스펙을 다듬는 데 훨씬 긴 시행착오가 필요했으며, 사람의 시간은 코드 작성에서 스펙 정의로 이동
• 설계 검토·리뷰·감사에서 패턴과 기술 지식을 추출하고, 서로 다른 해법을 비교하며 위임으로 생기는 이해 격차를 메움
• 특정 도구보다 각자의 제품과 조직에 맞는 개발 체계를 만드는 관점을 공유
• 사람이 코드를 거의 직접 작성하지 않는다면, 코드 구조도 기계가 유지보수하기 좋은 방향으로 바뀌어야 하는가라는 질문을 남김