🚀 만약 당신이 실제 소프트웨어 프로젝트를 구축하기 위해 AI를 사용해 보았다면, 아마 이런 경험을 해보았을 것입니다.

당신은 깨끗한 상태의 대화로 시작합니다.

AI는 당신의 아키텍처를 이해하고, 요구사항을 기억하며, 놀라울 정도로 좋은 코드를 작성합니다.

몇 시간 후, 모든 것이 변합니다.

대화 내용이 거대해집니다. 모델은 이전의 결정 사항들을 잊기 시작합니다. 이미 수정해 놓은 코드를 다시 작성하고, 이전 구현 사항과 모순되는 내용을 내놓으며, 불과 한 시간 전에는 완벽하게 이해했던 프로젝트의 부분들에 대해 갑자기 다시 설명해 주기를 요구합니다.

결국, 유일한 해결책은 완전히 새로운 채팅을 열고 프로젝트를 처음부터 다시 설명하는 데 15분을 더 쓰는 것뿐입니다.

이 사이클을 충분히 반복한 후, 나는 스스로에게 질문하는 것을 멈췄습니다.

"어떻게 하면 AI가 더 많이 기억하게 만들 수 있을까?"

대신, 나는 완전히 다른 질문을 던졌습니다.

"왜 나는 하나의 AI 대화가 전체 소프트웨어 프로젝트를 구축하도록 만들려고 애쓰고 있는 걸까?"

그 질문은 AI 보조 개발(AI-assisted development)에 대한 나의 생각을 완전히 바꾸어 놓았습니다.

💡 문제는 AI가 아닙니다

AI 코딩에 관한 대부분의 논의는 다음 사항에 집중합니다:

• 더 큰 컨텍스트 윈도우 (Context windows)
• 더 많은 토큰 (Tokens)
• 더 나은 모델 (Models)
• 더 긴 대화 (Conversations)

하지만 나는 그것이 진정한 해결책이라고 생각하지 않습니다.

대규모 소프트웨어 프로젝트는 자연스럽게 수천 개의 구현 결정 사항을 생성합니다.

모델들이 컨텍스트 윈도우를 계속해서 늘려 나간다 하더라도, 지속적으로 커지는 하나의 대화 안에 전체 프로젝트를 유지하는 것은 확장 가능한 아키텍처처럼 느껴지지 않습니다.

대화가 길어질수록 다음과 같은 문제가 발생합니다:

• 💰 비용이 비싸짐 (Expensive)
• 🐢 속도가 느려짐 (Slower)
• 😵 관리가 어려워짐 (Harder to manage)

**더 나은 프롬프트 (Prompts)**를 만드는 대신, 나는 워크플로우 (Workflow) 자체를 재설계해야 하는 것은 아닌지 고민했습니다.

🧠 모든 작업이 각자의 두뇌를 가지고 있다면 어떨까?

하나의 AI 대화에 전체 프로젝트를 완료하도록 요청하는 대신, 나는 프로젝트를 **독립적인 작업 (Independent tasks)**들로 나누었습니다.

예를 들어:

• 인증 (Authentication) 구현
• 로깅 (Logging) 추가
• API 엔드포인트 (API endpoints) 생성
• 단위 테스트 (Unit tests) 작성
• 문서 (Documentation) 업데이트

각 작업은 **완전히 격리된 AI 세션 (AI session)**이 됩니다.

한 작업이 끝나면, 해당 세션은 영원히 사라집니다.

다음 작업은 수행해야 할 작업에만 집중하는 완전히 새로운 AI 세션과 함께 시작됩니다.

이는 다음을 의미합니다:

• ✅ 점점 길어지는 대화 (No growing conversation)
• ✅ 누적되는 컨텍스트 (No accumulated context)
• ✅ 3시간 전의 구현 세부 사항을 잊어버리는 문제 없음 (No forgotten implementation details from three hours ago)

모든 작업은 **백지 상태 (clean slate)**에서 시작됩니다.

⚙️ 이 아이디어가 AI 작업 오케스트레이터 (AI Task Orchestrator)가 되었습니다

저는 이 개념을 바탕으로 **오픈 소스 AI 작업 오케스트레이터 (open-source AI Task Orchestrator)**를 구축했습니다.

AI와 지속적으로 채팅하는 대신, 오케스트레이터는 tasks.md 파일을 통해 한 번에 한 항목씩 작업을 수행합니다.

모든 작업에 대해 오케스트레이터는 다음을 수행합니다:

• 🚀 새로운 AI 세션 시작
• 📄 관련된 지침(instructions)만 전송
• ⏳ 구현이 완료될 때까지 대기
• 🔍 소스 코드(source code)가 실제로 변경되었는지 확인
• 🛠️ 복구(restore), 빌드(build), 테스트(tests) 실행
• ✅ 작업을 완료로 표시

그 후 다음 작업으로 넘어갑니다.

항상 단 하나의 AI 세션만 활성화되어 있습니다.

**병렬 실행 (parallel execution)**은 없습니다.

영원히 계속해서 커지는 **거대한 대화 (giant conversation)**도 없습니다.

✅ 신뢰하되, 검증하라 (Trust, But Verify)

AI 코딩 어시스턴트(AI coding assistants)를 사용하며 항상 신경 쓰였던 점이 하나 있습니다.

그들은 종종 이렇게 말합니다:

"완료되었습니다."

하지만...

정말로 완료된 것이 맞을까요?

저는 오케스트레이터가 AI의 응답을 그대로 믿는 대신, **모든 구현을 검증(verify)**하기를 원했습니다.

작업은 다음 조건이 충족될 때만 완료된 것으로 간주됩니다:

• ✅ 실제 소스 파일이 변경됨
• ✅ 변경 사항이 유의미함
• ✅ 프로젝트가 성공적으로 빌드됨
• ✅ 테스트 통과
• ✅ 완료 표시(completion markers)가 존재함

어떠한 검증 단계라도 실패하면, 해당 작업은 완료로 표시되지 않습니다.

대신, AI는 실패 상세 내용을 전달받고 더 나은 컨텍스트와 함께 다시 시도합니다.

이 단순한 변화가 워크플로우를 훨씬 더 신뢰할 수 있게 만들어 주었습니다.

🔄 AI가 한계에 부딪히면 어떻게 될까요?

AI와 충분히 오래 작업해 본 사람이라면 누구나 결국 다음과 같은 상황을 마주하게 됩니다:

• Rate limits (속도 제한)
• Token limits (토큰 제한)
• Network failures (네트워크 오류)
• Crashes (충돌)
• Interrupted sessions (중단된 세션)

보통 이런 상황은 처음부터 다시 시작해야 함을 의미합니다.

저는 다른 것을 원했습니다.

오케스트레이터(Orchestrator)는 다음과 같이 동작합니다:

• 💾 진행 상황을 체크포인트(Checkpoint)로 저장합니다
• ⏸️ 필요할 때 실행을 일시 중지합니다
• ▶️ 멈췄던 바로 그 지점에서 재개합니다

이는 다음을 의미합니다:

• ❌ 중복된 작업이 발생하지 않음
• ❌ 단 하나의 세션이 실패했다고 해서 프로젝트 전체를 다시 시작할 필요가 없음

🎯 제가 이것을 만든 이유

저는 **또 다른 AI 래퍼 (AI wrapper)**를 만들려고 했던 것이 아닙니다.

저는 **실행 엔진 (execution engine)**을 원했습니다.

소프트웨어 작업 백로그(backlog)를 가져와서 지속적인 감독 없이도 이를 계속해서 처리해 나갈 수 있는 무언가를 말이죠.

**대화 (conversations)**에 대해 생각하는 대신, 저는 **오케스트레이션 (orchestration)**에 대해 생각하기 시작했습니다.

다음과 같이 질문하는 대신 말입니다:

"어떻게 하면 하나의 AI가 모든 것을 기억하게 만들 수 있을까?"

저는 이렇게 질문했습니다:

"어떻게 하면 AI가 수행 중인 작업 외에는 모든 것을 잊게 만들 수 있을까?"

아이러니하게도...

그것이 훨씬 더 나은 결과를 만들어냈습니다.

💬 여러분의 피드백을 기다립니다

이 아키텍처는 개선될 수 있다고 확신하며, 바로 그 이유로 저는 이것을 **오픈 소스 (open-sourced)**로 공개했습니다.

만약 여러분이 AI로 소프트웨어를 구축해 오셨다면, 다음 사항들이 궁금합니다:

• 🤔 모든 작업이 완전히 격리된 세션에서 실행된다면 AI를 더 신뢰하시겠습니까?
• ⚡ 이 워크플로우를 어떻게 개선하시겠습니까?
• 🚀 어떤 기능이 추가되어야 여러분의 프로젝트에 진정으로 유용할까요?

여러분의 생각을 진심으로 듣고 싶습니다.