AI와 함께 일하는 법을 만들다 — SEMO 오케스트레이션 프레임워크 구축기

개발자의 78%가 AI 코딩 도구를 쓴다, 하지만 팀은?

2026년 현재, AI 코딩 도구를 사용하는 개발자는 전체의 78%에 달합니다. GitHub Copilot, Claude Code, Cursor 같은 도구들이 개인 개발자의 생산성을 2~3배 끌어올렸다는 보고가 쏟아지고 있죠.

하지만 한 가지 질문이 남습니다. "우리 팀 전체가 AI를 잘 활용하고 있나요?" 같은 프로젝트에서 개발자마다 AI가 생성하는 코드 스타일이 다르고, AI가 프로젝트 컨텍스트를 모르고, 코드 리뷰는 오히려 더 복잡해졌다면—그건 도구의 문제가 아니라 팀 차원의 AI 오케스트레이션 전략이 없기 때문입니다.

세미콜론 팀은 이 문제와 11개월간 싸우며 SEMO(Semicolon Orchestrate)라는 AI 에이전트 오케스트레이션 프레임워크를 만들었습니다. 이 글은 그 여정의 전체 지도입니다.

AI 코딩 도구, 개인에게는 마법 팀에게는 혼란

2024년 초, 세미콜론 팀에 Claude Code가 도입되었을 때 모두가 흥분했습니다. 반복적인 보일러플레이트는 10초 만에 생성되고, 복잡한 정규표현식도 설명만 하면 완성되었으니까요. 개인 생산성은 체감상 2~3배 뛰었습니다.

그런데 3개월이 지나자 다른 종류의 회의가 시작되었습니다.

"A가 만든 코드랑 B가 만든 코드가 스타일이 완전히 다른데요." "같은 요청인데 왜 결과가 다르죠?" "AI가 우리 프로젝트 구조를 전혀 모르네요."

핵심 문제는 세 가지였습니다. 첫째, 프롬프트의 개인차—같은 '버튼 만들어줘'라는 요청에 누군가는 클래스 컴포넌트를, 누군가는 함수형 컴포넌트를 받았습니다. 둘째, 프로젝트 컨텍스트 누락—AI는 우리가 Tailwind를 쓰는지, App Router를 쓰는지 몰랐습니다. 셋째, 품질 관리의 불가능—AI가 생성한 코드에 deprecated 패턴이나 보안 취약점이 섞여도 발견이 늦었습니다.

이 문제들이 왜 발생하는지 더 깊이 살펴보면, AI 코딩 도구는 태생적으로 개인 도구로 설계되어 있기 때문입니다. 개인 도구는 사용자의 선호를 기억하지만 팀의 규칙을 모르고, 한 세션의 맥락은 유지하지만 프로젝트 전체의 아키텍처를 파악하지 못합니다. 자세한 분석은 팀마다 AI 활용법이 달라야 하는 이유에서 다룹니다.

SAX에서 SEMO로: 11개월의 진화

AI를 팀 도구로 만들겠다는 결심에서 SEMO가 탄생하기까지, 우리는 설계→실패→재설계를 반복했습니다. 그 여정을 시간순으로 따라가 보겠습니다.

Phase 1: SAX — 역할 기반 AI 에이전트의 탄생 (2024.03~06)

첫 번째 시도의 이름은 SAX(Semicolon AI Transformation)였습니다. 핵심 아이디어는 단순했습니다. "팀의 코딩 규칙을 문서화하고, AI에게 매번 자동으로 전달하자." Claude Code의 CLAUDE.md 파일에 팀 규칙, 프로젝트 구조, 금지 사항을 적어두면 모든 AI 요청에 컨텍스트가 주입되니까요.

여기서 우리는 더 나아가 역할별로 전문화된 AI를 만들기로 했습니다. 프론트엔드 개발자에게는 React/Next.js에 특화된 sax-next를, 백엔드 개발자에게는 Spring에 특화된 sax-backend를, QA에게는 테스트에 특화된 sax-qa를 제공하는 식이었죠. 총 11개의 역할 기반 패키지가 만들어졌고, 모든 요청은 Orchestrator를 거쳐 적절한 패키지로 라우팅되었습니다.

Phase 2: 토큰 위기와 네이밍 사고 (2024.06~12)

11개 패키지의 CLAUDE.md를 합치면 총 1,800줄. LLM의 컨텍스트 윈도우를 잡아먹는 토큰 폭탄이었습니다. 중복 코드를 줄이고 Progressive Disclosure 전략을 적용해 토큰 사용량을 55% 절감했지만, 더 근본적인 문제가 터졌습니다. 토큰 최적화에 대한 기술적 고민은 토큰 이코노미와 AI 프레임워크 설계 원칙에서 자세히 다룹니다.

"SAX"라는 이름이 문제였습니다. 웹 개발에서 SAX는 Simple API for XML이라는 기존 기술을 의미합니다. LLM에게 "SAX의 Orchestrator를 설명해줘"라고 하면 XML 파서 이야기를 시작했죠. LLM 할루시네이션을 유발하는 네이밍이라는 예상치 못한 문제에 부딪힌 겁니다. 이 에피소드는 LLM 네이밍 충돌에서 배운 것에서 상세히 공유합니다.

Phase 3: 기능 기반 아키텍처로의 대전환 (2024.12~2025.01)

SAX를 SEMO(Semicolon Orchestrate)로 리브랜딩하면서 아키텍처도 완전히 바꿨습니다. '풀스택 개발자인데 sax-next랑 sax-backend 둘 다 써야 하나요?'라는 피드백이 계기였죠. 현대 개발 환경에서 역할 경계는 점점 흐려지고 있었습니다.

11개 역할 기반 패키지를 5개 기능 기반 스킬(coder, tester, planner, writer, deployer)로 통합하고, 명시적 플랫폼 지정 대신 설정 파일 기반의 자동 감지를 도입했습니다. 11개의 분산된 Orchestrator도 단일 통합 Orchestrator로 합쳤죠. 이 과정에서의 설계 결정과 트레이드오프는 역할 기반에서 기능 기반으로 — AI 에이전트 아키텍처 전환기에서 깊이 있게 다룹니다.

Phase 4: 기억하는 AI, 자율 실행하는 AI (2025.01~현재)

아키텍처가 안정된 후 우리는 더 깊은 영역으로 들어갔습니다. AI 에이전트에게 대화가 끝나도 유지되는 영속 메모리(Persistent Memory)를 부여하고, 사용자 피드백을 학습하게 만들었습니다. '내가 어제 한 말 기억해?'에 AI가 답할 수 있게 된 겁니다. 이 시스템의 설계는 AI 에이전트에게 기억을 주다에서 다룹니다.

14개의 페르소나 기반 봇 팀(PM, 코드 리뷰어, 인프라 전문가 등)을 구성하고, KB(Knowledge Base)를 Single Source of Truth로 확립하며, Cron과 Commitment 시스템으로 자율 실행 능력을 갖추게 했습니다. 한 명의 PM이 7개의 AI 봇을 관리하며 40개 서비스를 오케스트레이션하는 체제가 완성된 것이죠.

SEMO의 5가지 핵심 설계 원칙

11개월간의 시행착오에서 추출한, AI 오케스트레이션 프레임워크를 만들 때 꼭 지켜야 할 원칙들입니다.

1. 투명성 — AI가 무엇을 했는지 항상 보여야 한다

모든 AI 작업에 태그를 붙여 추적 가능하게 만들었습니다. '[SEMO] Orchestrator: 의도 분석 완료 → 코드 구현 요청'처럼 어떤 판단이 내려졌는지 투명하게 표시합니다. 마법의 블랙박스는 팀 도구로 살아남을 수 없습니다.

2. 기능 중심 — 역할이 아니라 기능으로 분류한다

'프론트엔드 개발자용 AI' 대신 '코드 작성 AI'로 접근합니다. 현대 개발 환경에서 역할 경계는 흐릿하고, 풀스택 개발자에게 프론트/백 패키지를 따로 쓰라고 하는 건 마찰만 만듭니다.

3. 컨텍스트 자동 주입 — 사용자가 설명하지 않아도 된다

프로젝트의 설정 파일(next.config.js, pom.xml 등)을 분석해 플랫폼을 자동 감지하고, CLAUDE.md에 팀 규칙을 주입합니다. '우리는 Tailwind 써'라고 매번 말하지 않아도 됩니다.

4. 토큰 경제학 — 필요한 것만 필요할 때 로드한다

LLM의 컨텍스트 윈도우는 유한한 자원입니다. Progressive Disclosure 전략으로 기본 원칙만 항상 로드하고, 스킬별 상세 지침은 해당 스킬이 호출될 때만 로드합니다. 이것만으로 토큰 사용량을 55% 줄였습니다.

5. 30초 온보딩 — 설치 마찰은 곧 도입 실패다

Git Submodule 기반의 복잡한 설치를 CLI 한 줄로 바꿨습니다. 'npx @team-semicolon/semo-cli init' 한 번이면 끝. 온보딩에 5분 이상 걸리는 도구는 팀 전체에 퍼지지 않습니다.

숫자로 보는 SEMO의 진화

11개월간 SEMO가 걸어온 길을 숫자로 정리하면 다음과 같습니다.

• 패키지 수: 11개 → 7개 (36% 감소)

• 스킬 파일: 152개(분산) → 14개(통합)

• 토큰 사용량: 55% 절감 (Progressive Disclosure)

• 온보딩 시간: 15분(Git Submodule) → 30초(CLI 원클릭)

• 봇 팀 규모: 7개 전문 페르소나 에이전트 (PM, 코드리뷰, 인프라 등)

• 관리 서비스: 40개 서비스를 1명의 PM이 AI 봇 팀과 함께 오케스트레이션

SEMO 구축기 시리즈 로드맵

이 글은 SEMO 구축기 시리즈의 필러(Pillar) 포스트입니다. 각 단계의 세부 이야기를 담은 클러스터 포스트를 순차적으로 발행할 예정입니다.

1. 팀마다 AI 활용법이 달라야 하는 이유 — 개인 도구 vs 팀 도구의 근본적 차이

2. 토큰 이코노미와 AI 프레임워크 설계 원칙 — 컨텍스트 윈도우 최적화 전략

3. LLM 네이밍 충돌에서 배운 것 — SAX에서 SEMO로의 리브랜딩 스토리

4. 역할 기반에서 기능 기반으로 — AI 에이전트 아키텍처의 대전환

5. AI 에이전트에게 기억을 주다 — 영속 메모리 시스템 구축

6. 7개 페르소나, 하나의 팀 — AI 봇 팀 빌딩 전략

7. KB가 진짜 Single Source of Truth가 되기까지 — AI 지식 관리 시스템

8. 자율 실행의 조건 — Cron과 Commitment 시스템

9. Slack에서 Discord까지 — 멀티채널 오케스트레이션

당신의 팀도 시작할 수 있습니다

AI 오케스트레이션은 거창한 기술이 아닙니다. CLAUDE.md 하나를 팀 규칙으로 채우는 것에서 시작됩니다. 중요한 건 첫 걸음을 내딛는 것이죠.

SEMO의 여정이 당신의 팀에게 영감이 되길 바랍니다. 시리즈의 각 글에서 구체적인 설계 결정, 실패 사례, 그리고 해결 과정을 낱낱이 공유할 예정입니다. AI와 함께 일하는 법, 우리가 먼저 걸어본 그 길을 함께 따라와 주세요.

세미콜론 팀이 AI와 함께 만들어가는 이야기가 궁금하다면, 블로그를 구독하거나 문의 페이지를 통해 이야기를 나눠주세요.