요즘은 프론트엔드 팀을 리드하고 있다.
우리 팀에서는 AI를 쓴다. 조금 더 정확히 말하면, 바이브코딩을 허용하고 있다. 두 달 정도 팀 단위로 운영해보니, 이건 생산성 도구를 도입하는 이야기가 아니었다. 책임의 구조를 다시 설계하는 이야기였다.
혼자 하는 것과 팀이 하는 것은 다르다
면접 질문이 하나 떠오른다.
“AI를 써서 만들어본 경험은 있으신가요?”
이제 이 질문에는 많은 사람이 고개를 끄덕인다. 화면을 만들고, API 호출 코드를 붙이고, 반복되는 타입을 생성하는 일은 AI의 도움으로 꽤 빠르게 된다.
그런데 이어지는 질문은 다르다.
“팀 단위로, AI가 만든 코드를 유지보수해본 경험은요?”
여기서 이야기가 달라진다. 혼자 만든 코드는 혼자 감당하면 된다. 하지만 팀의 코드는 누군가 리뷰해야 하고, 누군가 이어서 고쳐야 하고, 누군가 장애 상황에서 들여다봐야 한다.
팀 단위로 AI를 사용하려면 생산성과 함께 생성한 코드를 검토하고 유지할 책임의 기준이 필요하다.
설계 원칙: 자유를 주기 전에 구조를 먼저 만든다
이 프로젝트는 모바일 커머스 웹서비스다. 구조는 DDD를 바탕으로 설계했다.
다만 팀원 모두가 DDD에 익숙한 건 아니었다. 처음부터 모든 사람이 도메인 모델을 나누고, 책임을 분리하고, 비즈니스 규칙을 정확히 계층화하기를 기대하면 설계가 병목이 된다.
그래서 구조를 현실적으로 잡았다.
화면은 app/**에 둔다.
화면을 제외한 비즈니스 로직은 우선 Application 레벨에 둔다.
Domain 레벨은 내가 직접 관리한다.
공통 컴포넌트, Store는 미리 제공한다.
반복되는 API 연결 작업은 자동화한다.
Application 레벨은 일종의 완충지대다. 도메인으로 바로 내려가기 애매한 것들, 아직 책임이 정리되지 않은 것들이 잠시 머무는 공간이다. 잘 쓰면 버퍼고, 방치하면 잡동사니가 될 수도 있다. 하지만 팀 단위로 바이브코딩을 허용하려면 오히려 이런 완충지대가 필요하다.
AI는 기능을 구현할 수 있다. 하지만 우리 팀의 구조와 책임 경계까지 항상 정확히 파악하지는 못한다. 이 프로젝트에서는 Domain 판단을 내가 맡았다. 다만 판단이 한 사람에게 모이면 병목이 될 수 있다. Application 계층이 계속 커지지 않도록 책임을 정리하고, 도메인 판단의 기준도 팀이 이해할 수 있게 공유해야 한다.
자동화: AI가 아무 경로로나 들어오면 안 된다
팀 단위 바이브코딩에서 또 하나의 문제는 API 연결 코드다. 사람마다 다른 프롬프트로 AI에게 맡기면, 같은 API를 다루는 방식이 제각각이 된다.
그래서 백엔드 API 문서를 프론트엔드 내부 remote 구조로 변환하는 자동화 스크립트를 만들었다.
흐름은 이렇다.
백엔드 API 문서를 자동으로 읽는다.
내부 remote 구조로 변환해 docs/remote에 저장한다.
remote는 직접 접근하지 못하도록 lint 규칙으로 막는다.
대신 내가 만든 라이브러리가 remote를 읽어 React Query option을 자동 생성한다.
개발자는 생성된 option을 사용한다.
이 구조 덕분에 개발자는 query key를 고민하거나, API option을 손으로 만들거나, 응답 타입을 반복해서 연결하지 않아도 된다. 그리고 AI가 아무렇게나 API 호출 코드를 만들어내는 것도 막힌다.
AI가 코드를 생성하더라도, 프로젝트 안에서는 정해진 방식으로 데이터를 가져와야 한다.
자유를 주려면 먼저 가드레일이 있어야 한다. 이 자동화들은 편의 기능이 아니라 팀 단위 바이브코딩을 가능하게 만드는 안전장치다.
리뷰에서 확인한 설명의 빈칸
설계를 마치고 운영을 시작하자, 예상보다 선명한 문제가 보였다.
코드 리뷰 중에 물어봤다.
“이 코드는 뭐예요?”
돌아온 답이 이랬다.
“AI가 이렇게 하라고 해서요.”
그 답만으로 작성자의 역량 전체를 판단할 수는 없다. 다만 변경을 반영하려면 구현의 목적과 선택 이유, 확인한 동작에 대한 설명이 더 필요했다.
AI가 제시한 설명과 개발자가 실제 코드를 검토한 결과를 구분해야 했다. 이 기준은 내가 작성하거나 AI로 생성한 코드에도 똑같이 적용된다.
AI 시대의 코드 리뷰는 달라야 한다
코드 리뷰는 원래 “이 코드가 올바른가”를 확인하는 작업이었다. 하지만 AI가 코드를 생성하는 환경에서는 질문이 달라진다.
한 줄이 맞냐 틀리냐보다, 이 코드가 어디에 서 있는가를 봐야 한다.
이 Hook은 데이터를 가져오는 책임인가, 상태를 조합하는 책임인가.
이 로직은 지금 Application에 있는데, 나중에 Domain으로 내려가야 할 성격인가.
이 Adapter는 외부 응답을 내부 형태로 바꾸는 역할인가.
이 상태는 전역 Store에 들어갈 이유가 있는가, 단순 화면 상태인가.
이 API 호출은 왜 직접 만들지 않고 자동 생성된 option을 쓰는가.
코드가 실제로 올바르게 동작하는지 확인하는 일과 함께, 개발자가 그 코드의 위치와 책임을 설명할 수 있느냐가 핵심이다.
“AI가 이렇게 말했습니다”는 리뷰의 답이 될 수 없다. “제가 이렇게 이해했고, 그래서 이 위치에 이 형태로 두었습니다”가 되어야 한다.
AI가 설명해준 맥락을 외우는 것과, 내가 코드를 보고 판단한 맥락을 갖는 것은 다르다. 전자는 AI에게 종속된 상태고, 후자는 책임이 개발자에게 있는 상태다.
개발자의 역할이 사라지는 게 아니라 바뀐다
AI가 통역사를 대체하는 것처럼, 개발도 통역의 영역 아니었냐는 질문이 가끔 나온다. 기획자의 요구사항을 코드로 번역하고, 비즈니스 규칙을 시스템 언어로 바꾸던 일. 이제 AI가 그 직역을 넘어 의역까지 해준다면 사람이 내부 구현을 알아야 하냐는 질문이다.
나는 이 질문이 틀렸다고 생각하지 않는다.
AI가 서비스를 통째로 대신 만들고, 운영하고, 복구하고, 구조를 스스로 바꾸는 시대가 온다면 지금과 같은 의미의 개발자는 필요 없을 수 있다. 그때는 개발자의 인건비도 달라질 것이다. 기술이 어떤 일을 대체하면 그 일을 하던 사람의 시장 가격은 그대로 있지 않는다.
하지만 그 미래가 한순간에 마법처럼 오지는 않는다. 지금의 바이브코딩은 “서비스가 알아서 완성되는 시대”가 아니라, “개발자가 더 빠르게 만들 수 있는 시대”에 가깝다.
그렇다면 개발자의 역할은 사라진 게 아니라 바뀐 것이다. 직접 모든 코드를 치는 사람에서, AI가 만든 코드를 판단하고 구조 안에 배치하고 팀이 유지할 수 있는 형태로 책임지는 사람으로.
자율주행과 비슷하다. 언젠가 차가 모든 상황을 스스로 판단하는 날이 올 수 있다. 하지만 그 미래가 가능하다는 이유로, 오늘 도로 위에서 운전자가 핸들을 놓아도 되는 건 아니다.
AI가 만든 코드라도, 프로젝트에 넣는 순간 그 코드는 개발자의 코드다.
팀 단위 바이브코딩은 구조 싸움이다
구조가 없으면 AI가 만든 코드는 각자 다른 방향으로 퍼진다. 사람마다 다른 프롬프트, 다른 스타일, 다른 판단 기준으로 코드가 쌓인다. 처음에는 빨라 보인다. 시간이 지나면 유지보수 비용으로 돌아온다.
바이브코딩을 팀에서 허용하려면 오히려 더 강한 기준이 필요하다.
레이어 기준이 있어야 한다.
직접 접근하면 안 되는 영역이 있어야 한다.
반복 코드는 자동화되어 있어야 한다.
AI가 생성한 코드도 들어갈 수 있는 위치와 책임이 정해져 있어야 한다.
“AI 써도 됩니다”라고 말하는 것만으로는 부족하다. AI가 만들어낸 코드가 들어올 수 있는 길을 정리하고, 들어오면 안 되는 길은 막아야 한다.
바이브코딩은 “내가 코드를 안 짜도 된다”가 아니다. “내가 더 빠르게 시도할 수 있다”에 가깝다. 그리고 더 빠르게 시도한 만큼 더 빠르게 판단해야 한다. 이 코드가 맞는 위치에 있는지, 이 책임이 적절한지, 이 구조가 팀 안에서 유지될 수 있는지.
처음에는 AI가 만든 코드를 설명하지 못하는 순간들이 있었다. 지금은 적어도 그 코드가 어디에 속하고 어떤 책임을 갖는지 이야기하려고 한다. 그 변화가 중요하다.
팀 리드에게 필요한 것은 “AI를 잘 쓰라고 말하는 것”이 아니다. AI가 만든 코드도 팀의 구조 안으로 흘러가게 만드는 시스템을 준비하는 것이다.
바이브코딩은 감으로 시작할 수 있다. 하지만 팀에서 유지하려면 감으로 끝나면 안 된다.
생성된 코드가 팀이 이해하고 고칠 수 있는 결과로 남을 때, 빨라진 작성 속도가 유지보수에도 도움이 될 수 있다고 생각한다.
Assisted by AI