코드 리뷰 중에 물었다.
“이 코드는 뭐예요?”
“AI가 이렇게 하라고 해서요.”
코드가 어디서 왔는지는 알았다. 왜 여기에 있어야 하는지는 여전히 알 수 없었다.
요즘은 프론트엔드 팀을 리드하고 있다. 우리 팀에서는 AI를 쓰고, 바이브코딩도 허용한다. 두 달쯤 팀 단위로 운영해보니, 작성 속도만큼이나 자주 마주치는 문제가 있었다. 코드는 빠르게 도착하는데, 그 코드를 판단한 사람이 보이지 않는 순간이다.
혼자 만든 프로그램은 혼자 판단하고 고치며 이어갈 수 있다. 팀의 코드는 사정이 다르다. 누군가는 리뷰해야 하고, 다른 누군가는 이어서 수정해야 하며, 장애가 나면 작성자가 없는 자리에서도 들여다봐야 한다. 생성이 끝난 자리에서 유지보수가 시작된다.
잠시 둘 곳을 먼저 정했다
진행 중인 프로젝트는 모바일 커머스 웹서비스다. 구조는 DDD를 바탕으로 잡았다. 다만 팀원 모두가 DDD에 익숙하지는 않았다. 처음부터 모두가 도메인을 정확히 나누기를 기다리면, 설계부터 일이 막힐 수 있었다.
그래서 시작점을 이렇게 정했다.
화면은 app/**에 둔다.
화면을 제외한 비즈니스 로직은 우선 Application 레벨에 둔다.
Domain 레벨은 내가 직접 관리한다.
공통 컴포넌트, Store는 미리 제공한다.
반복되는 API 연결 작업은 자동화한다.
Application은 일종의 완충지대다. 도메인으로 옮겨야 할지 아직 판단하기 어려운 로직을 우선 둘 수 있는 곳. 잘 쓰면 버퍼고, 방치하면 잡동사니가 된다. 이름을 근사하게 붙인다고 저절로 정돈되지는 않는다.
이 프로젝트에서는 Domain 판단을 내가 맡았다. 판단이 한 사람에게 모이면 병목이 될 수 있으므로, Application에 쌓인 책임을 정리하고 그 기준을 팀이 이해할 수 있게 만드는 일도 남는다. 우선 둘 곳을 정했다는 말이 영원히 거기 두겠다는 뜻은 아니다.
반복해서 정할 일은 줄인다
API 연결도 마찬가지였다. 사람마다 다른 프롬프트로 요청하면, 같은 API를 다루는 방식부터 달라진다. 그 차이를 매번 리뷰하는 데 시간을 쓰고 싶지는 않았다.
그래서 백엔드 API 문서를 프론트엔드 내부 remote 구조로 변환하는 스크립트를 만들었다.
백엔드 API 문서를 자동으로 읽는다.
내부 remote 구조로 변환해 docs/remote에 저장한다.
remote는 직접 접근하지 못하도록 lint 규칙으로 막는다.
대신 내가 만든 라이브러리가 remote를 읽어 React Query option을 자동 생성한다.
개발자는 생성된 option을 사용한다.
이렇게 하면 query key나 API option, 응답 타입 연결을 매번 손으로 만들 필요가 줄어든다. AI가 생성한 코드도 같은 경로를 따라 데이터를 가져오게 된다.
“이 방식으로 작성해주세요”라는 부탁을 반복하는 대신, 다른 방식으로 들어오는 코드를 규칙이 걸러내게 한 셈이다. AI를 쓰는 사람마다 더 좋은 주문을 외우게 하는 것보다, 프로젝트에 들어오는 길을 정리하는 편이 이 작업에는 맞았다.
출처 다음에 필요한 설명
그런 구조를 마련해도 리뷰에는 빈칸이 남았다. “AI가 이렇게 하라고 해서요”라는 답이 그 빈칸을 보여줬다.
“AI가 이렇게 하라고 해서요”는 그 변경을 받아들일 이유가 되지 못한다. AI가 제안한 이유를 그대로 전달하면, 그 이유가 우리 프로젝트에도 맞는지 판단하는 일은 다음 사람에게 넘어간다. 구현을 맡긴 뒤 판단까지 넘기면, 리뷰에는 코드와 전달자만 남는다.
그래서 코드의 동작과 함께 위치를 묻는다.
이 Hook은 데이터를 가져오는가, 상태를 조합하는가.
이 로직은 Application에 머물러도 되는가, Domain으로 옮겨야 하는가.
이 Adapter는 외부 응답을 어떤 내부 형태로 바꾸는가.
이 상태는 전역 Store에 있어야 하는가, 화면 안에 두어도 되는가.
이 API 호출에는 왜 자동 생성된 option을 쓰는가.
질문마다 정해진 답을 외우라는 뜻은 아니다. “이렇게 이해해서 여기에 뒀고, 이 동작까지 확인했다”는 설명이 있어야 함께 검토할 수 있다. 그 이해가 틀렸다면 고치면 된다. 설명이 비어 있으면 어디부터 고쳐야 할지도 다시 찾아야 한다.
이 기준은 내가 만든 코드에도 같다. 사람이 직접 썼다는 사실 역시, 그 코드가 맞다는 증거는 아니니까.
아직은 누군가가 고쳐야 한다
개발도 결국 요구사항을 코드로 옮기는 통역 아니었느냐는 질문을 종종 본다. AI가 직역을 넘어 의역까지 한다면, 사람이 내부 구현을 얼마나 알아야 하느냐는 질문이다.
나는 그 질문을 가볍게 넘길 수 없다고 생각한다. 언젠가 AI가 서비스를 만들고 운영하고 복구하는 일까지 맡는다면, 지금 개발자가 하는 일과 그 일의 가격도 달라질 것이다.
다만 지금 우리 프로젝트에서는 누군가가 결과를 확인하고 고쳐야 한다. 미래의 AI가 할 수 있을 법한 일과 오늘 팀이 감당할 수 있는 일 사이에는 아직 거리가 있다. 언젠가 완전한 자율주행이 가능하리라는 기대만으로 오늘 핸들을 놓을 수는 없는 것처럼.
AI가 만든 코드라도 프로젝트에 넣기로 했다면, 그 결정은 팀 안에 남는다. 도구의 이름을 붙여 돌려보낼 곳은 없다.
처음에는 생성된 코드를 설명하지 못하는 순간들이 있었다. 지금은 적어도 그 코드가 어디에 속하고 어떤 책임을 갖는지 이야기하려고 한다. 내가 보고 싶은 변화도 거기에 있다.
팀 리드가 할 일은 “AI를 잘 써보자”는 말을 반복하는 데서 끝나지 않는다. 반복할 판단은 규칙으로 만들고, 아직 규칙으로 만들지 못한 판단은 리뷰에서 드러나게 해야 한다. 그래야 빨라진 작성 속도가 다음 사람의 해독 시간으로 청구되지 않는다.
바이브코딩은 감으로 시작할 수 있다. 하지만 팀의 저장소에 들어오는 마지막에는, 그 결과를 보고 판단한 사람이 서 있어야 한다.
Assisted by AI
© uiwwsw · 본인 소유의 글·이미지에 대한 무단 복제·재게시를 허용하지 않습니다. 개인 열람·원문 링크 공유·검색 색인과 제한적인 미리보기는 허용합니다. 법령상 이용 예외, 기존 이용 허락, 코드·제삼자 자료의 기존 라이선스는 유지합니다. 콘텐츠 이용 안내