한 줄씩 따지던 AI 코드를 맡길 수 있게 되기까지

3월에 공통 라이브러리 레포에 제가 올린 커밋 제목은 이랬어요.

✨ 코드 정리

✨ 코드 정리

✨ 코드 정리

✨ 코드 정리

같은 날 네 번. 그 무렵 저는 AI가 내놓은 코드를 한 줄씩 붙잡고 따졌어요. 이 변수는 왜 여기 있는지, 이 분기는 왜 필요한지 하나하나 태클을 걸었어요. 맡긴다기보다 같이 타이핑하는 쪽에 가까웠죠.

10월에 같은 레포에 올라간 커밋 중에는 이런 게 있어요.

✨ app-updater: 받는 동안 진행률을 보이고, 재시작하면 다시 켜질 때까지 「업데이트 적용 중」 창을 띄운다

그 사이 이 레포 커밋 중 Claude가 공동 작성자로 들어간 비율은 이렇게 바뀌었어요.

공동 작성자 줄은 Claude Code로 커밋하면 붙는 표시라, 이 숫자가 "AI가 다 했다"는 뜻은 아니에요. 무엇을 만들고 무엇을 버릴지는 여전히 사람이 정했어요. 다만 맡기는 양이 달라진 건 분명해요.

이 글은 그 사이에 무엇이 바뀌었는지에 대한 이야기예요. 모델이 좋아진 건 맞아요. 그런데 그것만으로는 설명이 안 되는 부분이 있었어요.

맡길 수 있겠다는 판단은 구조가 잡힌 뒤에 섰어요

같은 시기 어드민 프로젝트에서는 AI한테 일을 맡기기보다 맡길 바닥을 까는 데 몇 달을 썼어요.

timeline
  title 맡기기 전까지
  2월 : push 할 때 타입 오류 검사
  3월 중순 : 파일 299개를 계층대로 옮김 : AI가 읽는 지침에 상위 계층은 하위 계층만 참조한다는 규칙
  3월 말 : 화면마다 E2E 테스트
  4월 1일 : E2E가 API 응답까지 검증 : 커밋부터 Slack 공유까지 맡기는 ship 스킬
  4월 : 이제 맡겨도 되겠다는 판단

구조를 정리한 이야기는 폴더 구조 규칙을 문서가 아니라 코드로 지키기로 했어요에 따로 썼어요.

돌아보면 이 순서가 중요했어요. 구조가 없을 때 AI한테 일을 맡기면, AI는 그럴듯한 위치에 그럴듯한 파일을 만들어요. 틀렸다고 말할 기준이 없으니 저도 반박을 못 하고요. 계층이 정해지고 나서야 "이건 여기 있으면 안 돼"라고 말할 수 있게 됐어요. 그 말을 할 수 있어야 맡길 수 있어요.

그달부터 일을 통째로 맡기는 스킬을 만들기 시작했어요. 첫 번째가 변경 사항 커밋, GitLab 이슈 생성, MR 열기, Slack 공유를 한 번에 하는 ship이었어요. Claude 공동 작성 비율이 70%로 뛴 것도 이달이에요.

그 무렵 한 줄씩 태클 걸던 일을 덜어 준 게 superpowers 스킬이에요. 일을 시작하기 전에 브레인스토밍을 하고, 계획 문서를 쓰고, 테스트부터 쓰게 강제하는 스킬 묶음이에요. 4월 1일부터 공통 라이브러리 레포에 계획 문서가 쌓이기 시작해요.

모델이 혼자서는 건너뛰던 단계를, 스킬이 순서를 박아서 건너뛰지 못하게 했어요. 제가 걸던 태클을 스킬이 대신 걸어 준 셈이에요.

스킬을 팀에 내놓고 보니 제 컴퓨터 기준이었어요

4월 30일에는 스킬 24개를 공통 라이브러리 레포에서 떼어 별도 레포로 옮겼어요. 다른 팀도 쓰게 하려고요. 그런데 석 달 뒤인 7월 말에 이런 커밋을 줄줄이 올려야 했어요.

🐛 fe-weekly-report: 멤버 수 하드코딩 제거 (team-config 파생)

🐛 절대경로 하드코딩 제거 (남의 홈 디렉토리 포함)

제 컴퓨터, 제 팀 기준으로 쓴 스킬이었던 거예요. 저한테만 맞는 조건은 남한테는 조건이 아니었어요.

스킬 자체가 없어지기도 했어요. 9월에는 동료가 번역 리소스 스킬을 지우면서 이렇게 남겼어요. "지식이 MCP 스키마와 instructions 에 있다." 스킬로 적어 두던 설명을 MCP 서버가 직접 들고 있게 되자, 스킬은 할 일이 없어졌어요.

맡기니까 같은 패치가 반복됐어요

여름에 저희 팀은 레거시 어드민 화면을 새 어드민으로 옮기는 일을 하고 있었어요. 7월과 8월에 이관 작업이 몰렸고, 거의 기계적으로 AI한테 맡겼어요. 화면 하나를 주면 새 구조에 맞춰 옮겨 오는 식이었죠.

처음엔 잘 되는 것 같았어요. 그러다 7월 21일에 이런 커밋을 올렸어요.

🐛 page-annotation 무한 렌더 루프로 전체 페이지 로딩 멈춤 수정

브라우저가 멈췄어요. 8월 5일에 React Compiler를 켜고 나서는 더 심해졌어요. 다음 날 동료가 렌더 중에 호출된 watch() 122건을 걷어 냈는데, 컴파일러가 결과를 캐시해 버려서 폼 값이 갱신되지 않던 버그였어요. 타입 검사도 린트도 통과한 코드였고요.

원인을 따라가 보면 두 갈래였어요. 하나는 최신 기술이 전제하는 규칙을 AI가 모른다는 것. React Compiler는 렌더가 순수하다고 믿고 캐시하는데, AI는 렌더 중에 값을 읽고 매번 새 객체를 만드는 코드를 아무렇지 않게 써요. 다른 하나는 복붙이었어요. AI가 제가 합류하기 전 코드를 참고하거나, 자기가 방금 만든 코드를 다른 화면에 복사하면서 같은 문제를 퍼뜨렸어요.

React Compiler를 켜고 나서 어떤 회귀가 나왔고 어떻게 잡았는지는 React Compiler를 켜고 나서 — 회귀 4건을 잡은 기록에 자세히 썼어요.

같은 지적을 두세 번 하고 나면 린트로 옮겼어요. 말로 하는 지적은 대화가 끝나면 사라지거든요. 8월 11일에 넣은 규칙이 그런 예예요. 테스트용 가짜 훅이 매번 새 객체를 돌려주면 에러를 내는 규칙인데, 그런 객체는 렌더할 때마다 "값이 바뀌었다"로 읽혀서 렌더가 끝없이 돌거든요. 커밋 메시지에 이렇게 적었어요.

런타임 가드는 테이블 경로만, 그것도 실행해야 잡는다. 이 규칙은 작성 시점에 막는다.

규칙은 6월부터 하나씩 생기고 있었어요. 이관을 맡기면서 그 속도가 붙었고요.

timeline
  title 말로 하던 지적이 규칙이 되기까지
  6월 : 3월에 글로 정한 계층 규칙을 기계가 검사 : 파일끼리 서로 물고 도는 참조 금지
  7월 말 : 파일 이름 규칙
  8월 초 : 렌더 중에 폼 값 읽기 금지 : 테스트용 가짜 훅이 매번 새 객체를 돌려주는 것 금지
  8월 중순 : 레포마다 흩어진 규칙을 공용 패키지 하나로 묶음 : 폼 객체를 effect 의존성에 넣는 것 금지
  10월 : 이미 있는 테이블 셀 모양을 손으로 다시 그리는 것 금지 : 어드민도 공용 패키지에서 규칙 4개를 받아 씀

규칙을 한 패키지로 모으니까, 한 레포에서 AI가 저지른 실수를 막는 규칙이 다른 레포에도 그대로 가요.

마지막으로 끝의 기준을 바꿨어요. 린트를 통과하고, 테스트를 먼저 쓰고, E2E까지 통과해야 끝난 걸로 쳐요. AI한테 "잘 만들어 줘"라고 하는 대신 "이걸 통과해야 끝이야"라고 말하게 된 거죠.

자동 리뷰는 걷어 냈어요

만든 것 중에는 버린 것도 많아요. 가장 아팠던 게 자동 리뷰예요. MR이 올라오면 AI가 읽고 리뷰 코멘트를 다는 스킬이었어요. 정말로 매 MR마다 돌렸어요. 그런데 코멘트가 맥락을 전혀 따라오지 못했어요. 이 화면이 왜 이렇게 생겼는지, 이 예외가 어디서 왔는지 모르니까 기계적인 지적만 남았어요. 읽을 게 없는 리뷰가 MR마다 쌓였죠.

그래서 8월 13일에 통째로 지웠어요. 리뷰 스크립트 678줄을 포함해 872줄이었어요.

솔직히 그때 든 생각은, 리뷰라는 행위 자체가 무쓸모하다는 거였어요. AI한테 판단 기준이 없으니 리뷰를 아무리 시켜도 같은 결과가 나와요. 기준을 먼저 만들어야 했어요. 아키텍처를 빨리 세우고, 지적할 거리를 규칙으로 바꾸는 쪽이 맞겠다고 봤어요.

그 뒤에 다시 만든 리뷰 스킬들은 모양이 달라요. 9월에 만든 디자인 리뷰 스킬의 커밋 제목은 DESIGN.md 기준으로 검사하고 직접 고친다예요. 일반적인 리뷰가 아니라 적어 둔 규칙과 대조하는 리뷰예요.

10월부터는 리뷰보다 앞에서 AI를 써요. MR을 만들 때 AI가 "이 MR을 사람이 얼마나 봐야 하는지"부터 매겨서 본문 맨 위에 붙여요. 등급은 네 단계예요.

여기서 3단계를 가르는 기준이 이 방식의 핵심이에요. 규칙 문서에 이렇게 적어 뒀어요.

단방향은 "코드를 revert 할 수 있나"로 가르지 않는다. 코드는 거의 다 revert 된다.

나간 돈이나 발송된 알림, 기기에 써진 값, 구버전 앱이 쥐고 있는 계약처럼 코드를 되돌려도 남는 게 있느냐로 갈라요. 이건 AI가 스스로 알 수 없는 맥락이라 사람이 규칙으로 적어 줬어요. 경로와 diff 패턴으로 하한을 정하고, 경로만으로는 위험한지 모르는 파일에는 AI가 diff를 읽고 답할 질문을 달아 뒀어요. 등급은 올릴 수만 있고 내리지는 못해요.

자동 리뷰 때와 다른 점은 AI한테 판단을 통째로 맡기지 않았다는 거예요. 기준은 사람이 정하고, AI는 그 기준에 MR을 대 보는 일을 해요. 그리고 사람은 등급이 높은 MR에 시간을 써요.

지금은 쌓인 것들 위에서 맡겨요

지금은 Claude Code가 어지간한 건 알아서 해요. 여러 에이전트를 각자의 작업 폴더에서 동시에 돌리는 데는 Orca라는 도구를 쓰고, 그동안 쌓은 린트·테스트·스킬이 그 아래를 받치고 있어요.

timeline
  title 에이전트한테 넘긴 것들
  5월 : 에이전트가 기능 화면을 캡처해 공유
  6~7월 : 병렬로 돌릴 일을 하나하나 지정 : 이관 화면을 작업 폴더마다 나눠 돌림
  8~9월 : 의존성에 따라 순서 정하는 일까지 에이전트에게 : 컴퓨터가 꺼지고 메모리 규칙이 생김
  10월 : 디자인이 바뀐 MR엔 화면 캡처 필수 : 기획 자료부터 피그마 조립까지 단계마다 Claude를 부름

병렬도 처음엔 제가 다 정해 줬어요. "이거랑 이거랑 이거를 병렬로 해 줘." 어떤 일을 나눌지, 어느 작업 폴더에서 돌릴지 하나하나 지정했어요. 이관 화면 여러 개를 나눠 돌리기도 했고요.

모델이 좋아지면서 작업 순서를 정하는 일도 에이전트에게 넘겼어요. 권한을 주고, 작업 사이의 의존성을 판단해 실행 순서를 정하게 했어요. 먼저 끝나야 하는 건 먼저, 서로 상관없는 건 동시에. 이걸 매번 말로 지시하는 대신 기능으로 만들어 알아서 돌아가게 했어요.

그랬더니 컴퓨터가 꺼졌어요. 에이전트마다 빌드를 돌리고 브라우저를 띄우니 메모리가 버티지 못했어요. 결국 메모리 사용에 대한 규칙도 추가했어요. 맡길 수 있는 일이 늘어날수록, 일을 맡기기 위해 정해야 할 조건도 함께 늘어난 거예요.

그럼 사람은 뭘 보느냐. 코드 검토는 여전히 해요. 다만 프론트엔드는 코드만 보고 판단하기 어려운 부분이 많아요. 그래서 에이전트가 MR에 화면 캡처를 첨부하게 했어요. 캡처만으로 확인하기 어려운 사용성 문제는 화면을 녹화해 올리게 한 적도 있어요. 에이전트가 가져오는 결과물이 코드에서 끝나지 않고, 실제로 어떻게 보이고 동작하는지 확인할 수 있는 증거까지 포함하게 된 거죠.

10월에는 그 범위가 피그마까지 넓어졌어요. 최근 개발하고 있는 제품에서는 기획 자료를 바탕으로 구성안을 만들고, React로 화면을 구현하고, 코드로 검증한 뒤 피그마에 조립하고 컨벤션을 검사하는 과정까지 단계별로 Claude를 활용하고 있어요. 처음에는 코드 작성을 도와주던 도구가 이제는 개발 과정의 여러 단계를 함께 수행하는 셈이에요.

3월의 저와 지금의 저를 비교하면, 코드를 덜 읽게 된 건 아니에요. 읽는 자리가 바뀌었어요. 예전에는 AI가 작성한 코드가 맞는지 확인하는 데 집중했다면, 지금은 AI가 어떤 조건을 만족해야 하는지 정의하고 그 결과를 검증하는 데 더 많은 시간을 써요. 조건이 잘못되면 아무리 좋은 모델도 엉뚱한 결과를 만들고, 조건이 명확하면 생각보다 많은 일을 믿고 맡길 수 있어요.

물론 모델이 좋아진 덕도 커요. 3월에 지금과 같은 환경을 갖춰 놓았더라도 이만큼 맡기지는 못했을 거예요. 다만 모델이 좋아질 때마다 맡기는 일을 늘리고, 그에 필요한 규칙을 만들어 왔어요.

돌아보면 지난 몇 달은 AI로 코드를 더 잘 작성하는 방법을 찾는 시간이라기보다, 어디까지 맡길 수 있고 무엇을 직접 판단해야 하는지 알아가는 과정이었던 것 같아요. 그 경계는 앞으로도 계속 달라지겠죠. 중요한 건 더 많은 일을 맡기는 것 자체가 아니라, 무엇을 맡기고 무엇을 책임질지 스스로 결정할 수 있는 것이라고 생각해요.