200K에서 1M까지: Claude Opus 4.6이 내 AI 개발 워크플로우를 하룻밤에 바꾼 방법

Source: Dev.to

A follow‑up to The AI Development Workflow I Actually Use

몇 주 전, 내 AI 개발 워크플로에 대해 글을 썼었습니다. 구조화된 작업을 위한 Task Master, 현재 문서를 위한 Context7, 새로운 채팅 간에 문서를 넘겨주는 방식, 코딩 전에 여러 AI 관점을 검토하는 흐름. 그 워크플로는 실제 작동하는 소프트웨어를 배포했습니다.

하지만 오늘, 그 워크플로의 중요한 부분이 선택 사항이 되었습니다.

Claude Opus 4.6이 2026년 2월 5일에 Cursor에 출시되었으며, 1 백만 토큰 컨텍스트 창을 제공합니다. 저는 몇 달 동안 200 K 토큰 제한을 가진 Opus 4.5를 사용해 왔습니다. 1 M 토큰으로의 도약은 단순한 단계적 개선이 아니라, 단일 대화에서 가능한 범위를 완전히 바꾸어 놓았습니다.

아래는 실제 프로젝트에 이를 테스트했을 때 일어난 일입니다.

프로젝트: ironPad

ironPad는 AI와 함께 만들고 있는 로컬‑우선, 파일‑기반 프로젝트‑관리 시스템입니다. 데모가 아니라 실제 애플리케이션입니다.

코드베이스는 ≈ 80개의 파일로 구성되어 있으며, 백엔드와 프론트엔드 모두 포함합니다—200 K‑토큰 컨텍스트를 초과할 정도로 규모가 큽니다.

옛 방식: 200 K 컨텍스트

Opus 4.5 (200 K 토큰) 를 사용할 때 내 작업 흐름은 다음과 같았습니다:

1. 큰 기능을 3‑5개의 작업으로 나누기 – AI는 한 번에 몇 개의 파일만 기억할 수 있습니다.
2. 각 채팅 사이에 인수인계 문서 작성 – 다음 세션이 무슨 일이 있었는지 알 수 있도록.
3. 보여줄 파일을 신중히 선택 – 모든 파일을 로드할 수 없으므로 가장 관련성이 높은 3‑5개의 파일을 골라야 했습니다.
4. 매 세션마다 컨텍스트 설정을 반복 – 인수인계 문서를 붙여넣고, 아키텍처를 다시 설명하고, 올바른 파일을 가리킵니다.

잘 작동했고, 기능도 출시했습니다. 하지만 인수인계 시스템은 마찰을 추가했습니다—컨텍스트 제한 때문에 강제로 도입된 우회 방법이었습니다.

이미지: AI 컨텍스트

새로운 방법: 1 M 컨텍스트

오늘 나는 Opus 4.6과 새 대화를 시작하고 이렇게 말했습니다:

“전체 코드베이스를 컨텍스트에 로드하고 분석해 주세요.”

그게 전부였습니다—선택적인 파일도, 인수인계도, 서두도 없이. AI는 다음을 수행했습니다:

• 전체 프로젝트 구조 나열 – 모든 디렉터리와 파일.
• 모든 소스 파일 읽기 – 모든 Rust 백엔드 코드, 모든 Vue 컴포넌트, 스토어, 설정, 문서.
• 전체를 동시에 보유 – 약 80개의 파일, 수천 줄, 두 언어, 여러 프레임워크.

그런 다음 나는 물었습니다:

“버그나 개선해야 할 점이 있나요?”

발견된 내용

AI는 전체 코드베이스에서 16개의 이슈를 찾아냈습니다—여러 파일에 걸쳐 상호 작용을 이해해야 하는 깊은 버그들.

실제 버그

아키텍처 개선점

• 세 개 라우트 파일에서 원자성 없는 쓰기로 인한 데이터 손상 위험.
• confirm()이 UI 스레드를 차단.
• 고정 지연을 사용하는 WebSocket 재연결 대신 지수 백오프 적용 필요.
• 중복된 작업 파싱 로직 120줄.
• CORS 미들웨어 누락.
• 자산 엔드포인트에 경로 탐색 검증 없음.
• 프로덕션 코드에 남아 있는 console.log 디버그 출력.

해결 내용

나는 요청했습니다:

“이 모든 것을 고쳐 주세요.”

단일 세션에서 AI는 다음을 수행했습니다:

• 기존 commit_all()이 “변경 사항 없음”을 정상 처리하므로, 자동 커밋 시스템을 60초마다 커밋을 시도하도록 단순화했습니다.
• 포트 바인딩을 TcpListener를 바로 반환하도록 수정해 드롭하고 다시 바인딩하는 과정을 없앴습니다.
• atomic_write()를 공개 함수로 만들고 모든 쓰기 경로가 이를 사용하도록 전환했습니다(이로 인해 mark_file_saved() 문제도 자동으로 해결).
• 프론트‑머터 헬퍼 함수를 추가하고 작업 파싱 코드를 중복 제거했습니다.
• 차단되는 confirm()을 비차단 알림 배너로 교체했습니다.
• CORS, 경로 검증, WebSocket 재연결을 위한 지수 백오프를 추가했습니다.
• 연산자 우선순위 버그를 수정했습니다.

Image: Bug‑fixes graph

결과: cargo check가 통과되었습니다. 프론트엔드에서 린트 오류가 0개. 14개의 이슈가 해결됐으며, 2개는 의도적으로 보류되었습니다(대규모 라이브러리 마이그레이션 및 파일 간 사소한 상수 중복).

이 모든 작업이 단일 대화 안에서 이루어졌으며, 기존 200 K‑토큰 제한으로는 수십 차례의 인수인계가 필요했을 것입니다.

실제로 바뀐 점

이전: 인수인계 비용

200 K 토큰 컨텍스트에서는 더 큰 작업이나 변경마다 오버헤드가 발생했으며, 이를 별도의 작업으로 나누어야 했습니다. 그 오버헤드는 제약 조건의 비용이었습니다. 좋은 인수인계 시스템이 이를 관리 가능하게 만들었지만, 절대 무료는 아니었습니다.

이후: 직접 작업

1 M 토큰 컨텍스트에서는 전체 코드베이스 감사를 다음과 같이 수행했습니다:

Time for entire audit + fixes:
  Loading codebase:     ~2 min (AI reads all files)
  Analysis:            ~3 min (AI identifies 16 issues)
  Fixing all issues:   ~15 min (AI applies all fixes)
  Verification:        ~1 min (cargo check + lint)

  Total:               ~20 min
  Overhead:            ~0 min

200 K 컨텍스트로 같은 작업을 수행하려면 5회 이상의 별도 세션이 필요했으며, 각 세션마다 자체 인수인계가 필요하고 한 번에 볼 수 있는 파일이 제한되었습니다. 일부 파일 간 버그(예: 자동 커밋 문제)는 main.rs와 git.rs, 그리고 모든 라우트 핸들러가 동시에 컨텍스트에 포함되지 않으면 발견되지 않을 수도 있었습니다.

이것이 인수인계 워크플로우를 죽이는가?

아니오. 필요할 때만 바뀔 뿐입니다.

여전히 가치 있는 것

• 당신이 한 일을 이해해야 하는 사람과 협업하기
• 미래의 자신을 위한 결정 문서화
• 1 M 토큰을 초과하는 프로젝트

더 이상 필요하지 않은 것

• 컨텍스트에 맞추기 위해 기능을 인위적인 마이크로 작업으로 나누기
• 밀접하게 관련된 작업 사이에 인수인계 문서 작성
• AI가 볼 수 있는 파일을 신중히 선택하기
• 매 세션마다 아키텍처를 다시 설명하기

인수인계 시스템이 “모든 작업에 필수”에서 “세션 경계에 유용”으로 이동합니다. 이는 큰 변화입니다.

The Broader Pattern

제가 ironPad를 만들면서 눈에 띈 점은, AI 능력의 각 도약이 기존 작업을 단순히 더 빠르게 만드는 것이 아니라, 이전에는 실현 가능하지 않았던 작업들을 가능하게 만든다는 것입니다.

• Full code‑base audit는 200 K에서는 실현 가능하지 않았습니다. 개별 파일을 감사할 수는 있었지만, 시스템 전체에 걸친 버그를 찾으려면 사람이 파일 간 연결을 수동으로 추적하고 이를 AI에 설명해야 했습니다. 이제 AI는 모든 것을 볼 수 있습니다.
• Cross‑cutting refactors는 200 K에서는 실현 가능하지 않았습니다. 원자적 쓰기 방식을 여섯 파일에 걸쳐 변경하고, 파일‑워처 통합을 업데이트하며, 프론트‑매터 헬퍼가 모든 곳에서 사용 가능하도록 보장하는 작업은 모든 파일을 한눈에 볼 수 있을 때 하나의 일관된 변경이 됩니다. 200 K에서는 3‑4번의 세션이 필요하고 일관성 위험이 있었습니다.
• Architecture‑level reasoning은 200 K에서는 실현 가능하지 않았습니다. 자동 커밋 버그가 좋은 예입니다: AutoCommitState는 main.rs에서 생성되었고, mark_changed() 메서드는 git.rs에 존재했지만, 어떤 라우트 핸들러도 이를 접근할 수 없었습니다. 전체 코드‑베이스가 로드된 상태에서는 HTTP 핸들러에서 서비스 레이어까지의 전체 요청 흐름을 이해하는 것이 쉬워집니다.

ironPad의 다음 단계

프로젝트는 오픈 소스이며, 저는 30 minutes ago에 GitHub에 공개했습니다.

우리는 open method도 진행하고 있습니다—코드뿐만 아니라 프로세스도: 모든 기능이 AI로 어떻게 구축되었는지, 어떤 프롬프트가 효과적이었고, 어떤 것이 효과가 없었는지, 그리고 워크플로우가 200 K에서 1 M 컨텍스트로 어떻게 진화했는지.

도구는 계속 개선되고 있지만, 이를 잘 활용하는 과정도 여전히 중요합니다. 1 M 컨텍스트 윈도우는 무엇을 물어봐야 할지 모르면 도움이 되지 않습니다.

직접 해보기

오늘 성공한 핵심:

1. 모든 것을 로드하세요. 파일을 따로 고르지 마세요. AI가 전체 그림을 볼 수 있게 하세요.
2. 먼저 열린 질문을 하세요. “무엇이 잘못됐나요?”를 “이 특정한 것을 고쳐라”보다 먼저 물어보세요. AI가 내가 몰랐던 버그를 찾아냈습니다.
3. 배치로 작업하게 하세요. AI가 그들 사이의 모든 의존성을 볼 수 있었기 때문에 한 세션에서 14개의 문제를 해결했습니다.
4. 기계적으로 검증하세요. cargo check와 린트 도구가 모든 라인을 읽는 것보다 더 빠르게 정확성을 확인합니다.
5. 세션 경계에 대한 구조화된 워크플로를 유지하세요. 인수인계와 PRD는 작은 작업이나 큰 프로젝트에 여전히 중요하지만, 이제는 모든 마이크로 작업 사이에 필요하지 않습니다.

컨텍스트 윈도우가 회피해야 할 제한에서 전체 프로젝트를 채우는 공간으로 바뀌었습니다. 이것이 게임을 바꿉니다.

ironPad는 오픈으로 구축되고 있습니다. GitHub에서 프로젝트를 팔로우하세요:

https://github.com/OlaProeis/ironPad