팀마다 AI 활용법이 달라야 하는 이유

이 글은 SEMO 구축기 시리즈의 첫 번째 글입니다.

"내 프롬프트는 잘 되는데, 왜 팀은 안 되지?"

2024년 초, Claude Code가 출시되고 몇 주 지나지 않아 세미콜론 팀 전원이 AI 코딩 도구를 사용하기 시작했습니다. 반복적인 보일러플레이트는 10초 만에 생성되고, 복잡한 정규표현식도 설명만 하면 완성되었죠. 개인 생산성은 체감상 2~3배 향상되었습니다.

그로부터 3개월 후, 우리는 전혀 다른 종류의 회의를 하고 있었습니다. 코드 스타일이 천차만별이고, AI가 프로젝트 구조를 모르고, 코드 리뷰는 오히려 더 어려워진 상황. 무엇이 잘못된 걸까요?

AI 코딩 도구의 빛과 그림자

빛: 개인 생산성의 폭발

AI 코딩 도구가 개인 생산성에 미치는 영향은 의심의 여지가 없었습니다. 보일러플레이트 코드 자동 생성, 복잡한 로직의 자연어 설명만으로 구현, 테스트 코드 자동 생성까지. 개발자 한 명이 처리할 수 있는 작업량이 비약적으로 늘었습니다.

그림자: 팀 생산성의 혼란

하지만 팀 단위로 보면 이야기가 달랐습니다. 우리가 직면한 세 가지 핵심 문제를 공유합니다.

문제 1: 프롬프트의 개인차. 같은 "React로 버튼 컴포넌트 만들어줘"라는 요청에 개발자 A는 클래스 컴포넌트와 CSS 파일 분리, PropTypes를 받았고, 개발자 B는 함수형 컴포넌트와 styled-components, TypeScript를 받았습니다. AI는 사용자의 선호를 모르기 때문에 매번 다른 결과를 내놓았죠.

문제 2: 프로젝트 컨텍스트 누락. 우리 프로젝트는 Next.js 14 App Router에 Tailwind CSS를 쓰고 특정 폴더 구조를 따릅니다. 하지만 AI는 이걸 모릅니다. CSS Modules로 스타일링된 코드를 생성하거나, Pages Router 구조로 파일을 만드는 일이 반복되었습니다.

문제 3: 코드 리뷰의 지옥. AI가 생성한 코드의 품질이 천차만별이었습니다. 어떤 건 베스트 프랙티스를 완벽히 따르고, 어떤 건 deprecated 패턴을 사용하고, 어떤 건 보안 취약점을 포함했죠. 코드 리뷰어는 AI가 짠 건지 사람이 짠 건지 구분할 수 없어 매번 처음부터 꼼꼼히 봐야 했습니다.

개인 도구와 팀 도구는 근본적으로 다르다

이 문제들의 근본 원인을 추적하면 한 가지 결론에 도달합니다.

AI 코딩 도구는 태생적으로 '개인 도구'로 설계되어 있다. 하지만 우리에게 필요한 건 '팀 도구'다.

개인 도구와 팀 도구의 차이를 정리하면 명확해집니다.

• 컨텍스트: 개인 도구는 사용자 선호를 따르지만, 팀 도구는 팀 규칙과 프로젝트 설정을 따라야 합니다.

• 일관성: 개인 도구에서는 불필요하지만, 팀 도구에서는 필수입니다. 누가 요청하든 같은 스타일의 결과물이 나와야 합니다.

• 품질 관리: 개인 도구는 개인 책임이지만, 팀 도구는 시스템이 품질을 보장해야 합니다.

• 온보딩: 개인 도구는 각자 알아서 배우지만, 팀 도구는 표준화된 프로세스로 누구나 동일하게 시작할 수 있어야 합니다.

이 간극을 메우지 않으면, AI 도구를 도입할수록 팀의 코드베이스는 더 혼란스러워집니다. 개인 생산성은 올라가는데 팀 생산성은 제자리—심지어 코드 리뷰 부담이 커지면서 오히려 떨어질 수도 있죠.

해결의 실마리: AI에게 팀의 규칙을 가르치다

세미콜론 팀의 접근은 단순했습니다. "AI에게 우리 팀의 규칙을 매번 자동으로 전달하자." Claude Code의 CLAUDE.md 파일에 팀의 코딩 규칙, 프로젝트 구조, 금지 사항을 체계적으로 정리하면 모든 AI 요청에 이 컨텍스트가 자동으로 주입됩니다.

하지만 단순히 프롬프트 템플릿을 공유하는 것만으로는 부족했습니다. 세 가지 이유가 있었죠.

1. 프롬프트는 쉽게 무시된다 — "나는 내 방식이 더 좋아"라며 개인 프롬프트를 쓰는 개발자가 생깁니다.

2. 버전 관리가 어렵다 — 누가 최신 프롬프트를 쓰는지 추적할 수 없습니다.

3. 강제성이 없다 — 규칙을 어겨도 티가 나지 않습니다.

그래서 우리에게 필요했던 건 단순한 템플릿이 아니라 프레임워크였습니다. 모든 AI 요청이 특정 경로를 통과하도록 강제하고(강제성), AI가 무엇을 했는지 태그로 표시하며(투명성), 새로운 규칙을 쉽게 추가할 수 있는(확장성) 구조. 이것이 SEMO 오케스트레이션 프레임워크의 출발점이었습니다.

당신의 팀은 어떤가요?

지금 당장 팀에 AI 오케스트레이션 프레임워크를 도입하지 않더라도, 한 가지만 시작해보세요. 프로젝트 루트에 CLAUDE.md 파일을 만들고, 팀의 핵심 규칙 5가지를 적어보는 겁니다. 사용하는 프레임워크, 스타일링 방식, 폴더 구조, 네이밍 컨벤션, 금지 패턴. 이것만으로도 AI가 생성하는 코드의 일관성이 눈에 띄게 달라집니다.

다음 글에서는 이 접근을 확장할 때 마주치는 토큰 경제학 문제와 설계 원칙을 다룹니다. 규칙을 많이 적을수록 AI의 컨텍스트 윈도우를 얼마나 잡아먹는지, 그리고 그 해법은 무엇인지 공유할 예정입니다.