컨텍스트 전쟁: 엔터프라이즈 프로젝트에서 AI 코딩을 구현한 방법

Source: Dev.to

번역을 진행하려면 번역하고자 하는 본문 텍스트를 제공해 주시겠어요? 현재는 링크만 포함되어 있어 실제 내용이 없으므로, 번역이 가능한 텍스트를 알려주시면 바로 한국어로 번역해 드리겠습니다.

소개: 아무도 해결하지 못한 과제

이 상황을 상상해 보세요: 분석가에게 코딩 능력을 부여해야 합니다. “ChatGPT에 프롬프트를 작성한다”는 것이 아니라, 3년의 역사를 가진 기업용 제품을 실제로 수정하고, 수백만 줄의 코드를 다루는 것입니다.

개발자는 옆에 앉아 매 줄을 지시하지 않습니다. 환경을 설정하고, 품질을 관리하며, 문제가 발생했을 때만 개입합니다.

과학 소설 같은 이야기인가요? 우리도 그렇게 생각했지만, 직접 시도해 보기 전까지는 몰랐습니다.

이것이 겉보기보다 어려운 이유

프로그래머가 AI 어시스턴트를 사용할 때는 모든 단계를 직접 제어합니다. 그들은 under the hood에서 무슨 일이 일어나고 있는지 보고, 코드에서 이상 현상을 즉시 발견합니다.

분석가와 함께라면 모든 것이 다릅니다. 그들은 결과만을 봅니다: “the form appeared” 혹은 “the form doesn’t work.” 코드 품질, 아키텍처 결정, 잠재적인 버그—이 모든 것은 뒤에서 숨겨져 있습니다.

우리는 이 눈먼 상황을 보완하는 시스템을 만들기로 했습니다—AI가 정말 원한다 하더라도 “cause trouble”을 할 수 없는 시스템 말이죠.

도구 선택: 왜 Cursor

우리는 여러 옵션(GitHub Copilot, Claude Code, 다양한 API 래퍼)을 시도해 본 뒤 Cursor를 여러 이유로 최종 선택했습니다.

멀티‑모델 지원

Cursor를 사용하면 작업마다 다른 모델을 활용할 수 있습니다:

flowchart LR
    A[Task] --> B{Type?}
    B -->|Planning| C[Claude Opus 4.5]
    B -->|Implementation| D[Gemini 3 Flash]
    C --> E[200K tokens]
    D --> F[1M tokens]

• Claude Opus 4.5 – 아키텍처 설계 (똑똑하지만 토큰 비용이 “비쌈”)
• Gemini 3 Flash – 구현 (빠르고 저렴하며, 무엇보다도 — 1 백만 토큰의 컨텍스트 제공)

MCP 통합

Model Context Protocol (MCP)은 외부 도구를 AI와 연결하는 방법입니다.

유연한 규칙

Cursor는 상황에 따라 자동으로 로드되는 규칙을 담은 .mdc 파일을 만들 수 있게 해줍니다.
React 컴포넌트를 작업 중 → React 규칙 로드
스크립트를 작성 중 → Node.js 규칙 로드

보안 요구사항: 로컬 작업

보안 팀은 다음과 같은 엄격한 요구사항을 부과했습니다: 개발 중 기업 네트워크에 접근 금지 및 프로덕션 데이터베이스 복제 금지.
우리는 MSW (Mock Service Worker) 기반의 전체 모킹 시스템을 구축했습니다:

flowchart TD
    A[Frontend App] --> B[MSW Interceptor]
    B --> C{Request Type}
    C -->|API Call| D[Mock Handlers]
    C -->|Static| E[Pass‑Through]
    D --> F[Fake Data Generators]
    F --> G[@faker-js]
    D --> H[Response]

• 모든 API 엔드포인트에 대해 50개 이상의 핸들러
• @faker-js를 활용한 현실적인 데이터 생성기
• 전체 비즈니스 로직 에뮬레이션

품질 게이트: 더 엄격할수록, 더 좋다

핵심 인사이트: AI는 엄격한 제약이 필요합니다. 제약이 없으면 AI는 “창조”하기 시작합니다: 오래된 코드를 보면 → 리팩터링하고; 잠재적인 취약점을 발견하면 → “수정”하고; 스타일 불일치를 찾으면 → 재포맷합니다. 실제로 “폼에 필드 추가”와 같은 간단한 작업도 100 000줄에 달하는 PR이 될 수 있습니다.

우리의 품질‑게이트 파이프라인

flowchart TD
    A[Commit] --> B[commitlint]
    B -->|Pass| C[ESLint]
    B -->|Fail| X[❌ Rejected]
    C -->|Pass| D[TypeScript]
    C -->|Fail| X
    D -->|Pass| E[Vitest]
    D -->|Fail| X
    E -->|Pass| F[Secretlint]
    E -->|Fail| X
    F -->|Pass| G[✅ Push]
    F -->|Fail| X

코드가 이러한 검사를 통과하지 못하면 커밋은 이루어지지 않습니다.

컨텍스트 문제: 주요 고통점

Context는 거의 전체 프로젝트를 망하게 만든 요소입니다.

• 간단한 10파일 앱에서는 AI가 전체 프로젝트를 보고 완벽하게 작동합니다.
• 백만 라인에 3년 된 코드베이스에서는 AI가 조각만 보게 됩니다—빙산의 일각에 불과합니다.

약 30분 정도 지나면 AI가 “잊어버리기” 시작하고, 실수를 반복하며, 이미 거부된 해결책을 제안하고, 방금 작동하던 것을 깨뜨립니다.

우리가 밟은 네 가지 함정

함정 #1: “간단한 예제에서는 작동했다”

실험: 분석가에게 깨끗한 보일러플레이트(최소 React 프로젝트, 레퍼런스 규칙, 10개 파일)에서 회원가입 양식을 만들게 한다.

결과: 15 분, 모든 것이 완벽히 작동한다.

실제 프로젝트에서 같은 작업: 전혀 작동하지 않는다. AI가 의존성을 혼동하고, 오래된 패턴을 사용하며, 기존 코드와 충돌한다.

교훈: AI가 “멍청한” 것이 아니라, 맥락이 부족하기 때문이다.

함정 #2: AI가 “전체 프로젝트를” 고쳤다

작업: 하나의 기능을 추가한다. AI는 이를 완료했을 뿐 아니라:

• 모든 any를 구체적인 타입으로 교체
• “잠재적 취약점”을 “수정”
• 프로젝트 절반을 재포맷
• 오래된 의존성을 업데이트

결과: 100 000+ 라인의 PR; GitLab조차 차이를 표시할 수 없었다. 우리는 2주 동안 이를 정리했으며, 제품은 망가졌다.

교훈: AI 작업의 범위를 규칙으로 명시적으로 제한하라.

함정 #3: 토큰 제한

대부분의 모델은 컨텍스트 창이 약 100 K 토큰으로 제한된다는 사실을 처음엔 인식하지 못했다. 코드베이스가 이를 초과하면 모델이 전체 그림을 볼 수 없어 위에서 언급한 문제들이 발생한다.

함정 #4: 의사결정에 대한 AI 과신

우리는 모델이 제안하는 아키텍처 변경을 인간 검토 없이 받아들였다. 모델의 “최적화”가 오랫동안 유지돼 온 설계 결정과 충돌해 회귀가 발생했다.

교훈: 고위험 의사결정에는 반드시 인간을 참여시켜라.

Takeaways

1. Context is king. 대규모 코드베이스에서는 문제를 명확히 정의된, 컨텍스트가 제한된 작업으로 나눕니다.
2. Strict quality gates는 절대 타협할 수 없으며, AI가 검증되지 않은 변경을 저장소에 반영하는 것을 방지합니다.
3. Model selection matters. 구현 단계에서는 저렴하고 토큰 수가 많은 모델을 사용하고, 계획 단계에서는 더 강력하지만 비용이 높은 모델을 사용합니다.
4. Security‑first mocking을 통해 프로덕션 데이터를 노출하지 않고 로컬에서 개발할 수 있습니다.
5. Human oversight는 특히 아키텍처나 보안에 중요한 변경 사항에 대해 여전히 필수적입니다.

이러한 원칙을 받아들임으로써, 우리는 잠재적으로 혼란스러울 수 있는 AI 지원 워크플로우를 신뢰할 수 있고 반복 가능한 프로세스로 전환했으며, 이는 엔터프라이즈 규모의 코드베이스에도 확장됩니다.

200K 토큰 – 엔터프라이즈에 부족

• 엔터프라이즈 프로젝트에서는 200 K 토큰으로 3‑5번 정도의 반복만 가능합니다.
• 그 이후에는 AI가 대화 초반을 “잊어버리고”, 이미 거절한 해결책을 제안하며, 실수를 반복합니다.

교훈: 엔터프라이즈 작업을 위해서는 최소 1 백만 토큰의 컨텍스트를 가진 모델이 필요합니다.

Rake #4 – Auto‑Mode Is a Trap

Cursor는 모델을 자동으로 선택할 수 있습니다. 편리해 보이지만 실제로는 종종 작은 컨텍스트 윈도우를 가진 저가 모델을 선택합니다.

우리는 진지한 작업을 위해서는 모델을 수동으로 선택해야 한다는 것을 이해하기 전까지 많은 시간을 낭비했습니다.

Lesson: 계획 단계에서는 Claude Opus를, 구현 단계에서는 Gemini Flash를 사용하세요. 자동 모드에 절대 의존하지 마세요.

컨텍스트 문제를 해결한 방법

모든 “레키”를 거친 뒤, 완벽하지는 않지만 작동하는 시스템을 구축했습니다.

2단계 작업 추적

flowchart TD
    subgraph Jira [Jira – Team Level]
        J1[VP‑385: Add Registration Form]
    end

    subgraph Beads [Beads – Atomic Level]
        B1[bd‑1: Review UserForm.tsx]
        B2[bd‑2: Add email field]
        B3[bd‑3: Write test]
    end

    J1 --> B1
    B1 --> B2
    B2 --> B3

• Jira – 팀 차원의 최상위 작업 (예: VP‑385: Add registration form).
• Beads – AI를 위한 원자적 작업:
  • bd‑1: UserForm.tsx 파일 검토
  • bd‑2: 이메일 필드 추가
  • bd‑3: 테스트 작성

Beads는 로컬에 저장되고 Git과 동기화되므로, AI는 언제든지 중단한 단계가 어디인지 알 수 있습니다.

메모리 뱅크

AI를 위한 “외부 메모리”로, 다음을 저장합니다:

• 현재 컨텍스트 – 지금 작업 중인 내용
• 진행 상황 – 이미 완료된 부분
• 연구 자료 – 발견 내용 및 참고 자료
• 아카이브 – 완료된 작업

AI가 무언가를 “잊어버렸을” 때, 메모리 뱅크에서 필요한 정보를 꺼내어 이해를 복원할 수 있습니다.

모델 조합

작업을 두 모델에 나누어 맡겼습니다:

flowchart LR
    A[Task] --> B[Opus: Planning]
    B --> C[Opus: Spec / TZ]
    C --> D[Gemini: Implementation]
    D --> E[Opus: Review]
    E -->|Issues| D
    E -->|OK| F[Done]

사이클: Opus가 계획 → Gemini가 구현 → Opus가 리뷰.

프로젝트 통계 (1.5 주, feature/msw-mocks)

구현된 기능

• ✅ 전체 MSW 모킹 시스템 (50+ 핸들러)
• ✅ 간트 차트가 포함된 일정 타임라인
• ✅ 품질 게이트 (ESLint, TypeScript, Husky)
• ✅ Beads 통합
• ✅ 200+ 단위 테스트

비교: 전통적인 개발 vs. AI 지원 개발

*인프라 설정, 학습 곡선, 그리고 모든 “레이크(rake)”를 포함합니다.

중요한 뉘앙스: 첫 번째 기능은 비용이 많이 듭니다. 우리는 워크플로를 배우고, 규칙을 설정하고, 레이크에 걸리는 데 1.5 주를 사용했습니다. 이후 기능들은 ≈10× 적은 시간이 걸립니다.

Role Evolution

• Analyst – 더 이상 “스펙만 작성”하는 것이 아니다. SQL을 이해하고, Git을 사용하며, 기본 수준의 코드를 읽을 수 있는 주니어 개발자가 된다.
• Developer – 더 이상 “코드만 작성”하는 것이 아니다. 언어 문법보다 설계 패턴에 집중하는 아키텍트가 된다. AI가 Java, Node.js, Python, Go 등으로 코드를 작성할 수 있기 때문에 개발자는 범용 전문가가 된다.

결론 및 권장 사항

잘 작동하는 것

• Opus + Gemini 조합 – 스마트 설계자 + 빠른 실행자
• Quality Gates – 더 엄격한 제약 → 더 나은 결과
• 두 단계 추적 – 팀은 Jira, AI는 Beads
• Memory Bank – 컨텍스트 손실 방지를 위한 외부 메모리
• 데이터 모킹 – 완전한 개발 자율성

잘 작동하지 않는 것

• 모델 선택 자동 모드
• 제약 없는 AI (전체 프로젝트를 “수정”할 수 있음)
• 엔터프라이즈 작업에 < 1 M 토큰 컨텍스트 윈도우를 가진 모델

시작을 위한 체크리스트

• 로컬 개발 환경 설정
• Quality Gates 구현 (ESLint, 엄격한 TypeScript)
• 데이터 모킹 시스템 구축
• MCP 연결 (Jira, Context7, Memory Bank)
• 분석가에게 Git 및 SQL 교육
• 올바른 모델 선택 (Opus + Gemini)

최종 생각

컨텍스트 전쟁은 아직 끝나지 않았습니다. 컨텍스트 윈도우는 계속 커지고 있지만, 엔터프라이즈 프로젝트는 여전히 AI가 전체를 한눈에 볼 수 없을 정도로 방대합니다. 따라서 AI가 집중력을 유지하도록 돕는 시스템이 필요합니다: 작업 추적기, 메모리 뱅크, 그리고 퀄리티 게이트.

우리는 이러한 인사이트를 얻기 위해 15억 토큰을 사용했습니다. 우리의 경험이 여러분이 훨씬 적은 토큰을 사용하도록 도움이 되길 바랍니다.

대규모 프로젝트에서 AI 코딩을 해본 경험은 어떠셨나요? 댓글로 공유해주세요!

저자 소개

React로 UI 작업 중. 사용 도구: Cursor IDE, Claude Opus 4.5, Gemini 3 Flash.

태그: ai cursor enterprise programming devjournal