'이거 만들어줘'라고 하면 왜 에이전트가 헤맬까요
Claude Code나 Codex 같은 코딩 에이전트를 써보신 분들은 공감하실 텐데요. 작은 일은 정말 잘하는데, '결제 기능 추가해줘'처럼 큰 목표를 던지면 갑자기 엉뚱한 파일을 건드리거나, 절반쯤 하다가 방향을 잃거나, 앞서 만든 걸 뒤에서 다시 깨먹는 일이 생기거든요. 이유는 단순해요. 에이전트는 한 번에 볼 수 있는 맥락(컨텍스트)이 한정되어 있고, 큰 작업은 그 안에 다 안 들어가요. 그래서 실무자들은 결국 큰 목표를 작은 작업으로 손수 쪼개고, 순서를 정하고, 하나씩 던져주는 일을 반복하고 있죠.
GitHub에 공개된 Ordewell은 정확히 이 '쪼개고 순서 정하는' 일을 도구로 만든 프로젝트예요. 이름 그대로 order(순서)를 well(잘) 잡아주겠다는 거죠. 목표 하나를 입력하면, 코딩 에이전트가 하나씩 처리할 수 있는 작업 목록을 의존 관계에 맞춰 정렬해서 내놓아요.
어떤 흐름으로 동작하나요
핵심 아이디어를 단계별로 풀어볼게요.
1단계, 목표 입력: 사용자는 자연어로 목표를 하나 적어요. 예를 들어 '사용자 인증에 OAuth 로그인을 추가하고 기존 세션 방식과 공존하게 만들기' 같은 식이죠.
2단계, 작업 분해: 도구가 이 목표를 여러 개의 작은 작업으로 나눠요. 각 작업은 '에이전트가 한 번의 세션에서 끝낼 수 있을 만큼 작은 단위'를 목표로 해요. 이게 뭐냐면, 마치 프로젝트 매니저가 에픽(큰 요구사항)을 스토리와 태스크로 쪼개는 것과 같은 일이에요. 다만 사람이 아니라 LLM이 하는 거죠.
3단계, 의존 관계 정렬: 여기가 이 도구의 진짜 핵심이에요. 작업들 사이에는 순서가 있어요. DB 스키마를 바꾸기 전에 API를 만들 수는 없고, API 없이 프론트엔드 화면을 붙일 수는 없죠. Ordewell은 작업 간 의존성을 파악해서 '이걸 먼저 하고, 그다음에 이걸' 하는 순서를 정해요. 컴퓨터 과학에서 위상 정렬(topological sort)이라고 부르는 그 개념인데, 쉽게 말하면 '선행 조건이 있는 일들을 앞뒤 안 꼬이게 줄 세우기'예요.
4단계, 에이전트에게 전달: 정렬된 작업은 코딩 에이전트가 읽을 수 있는 형태로 나와요. 사용자는 이걸 순서대로 Claude Code나 Codex 같은 에이전트에 넘기면 되죠. 각 작업이 독립적이면서 앞 단계의 결과 위에 쌓이도록 설계되어 있으니까, 에이전트가 매번 전체 그림을 다시 파악할 필요가 없어요.
즉 Ordewell은 '실행'이 아니라 '계획'에 집중하는 도구예요. 코드를 직접 쓰는 게 아니라, 코드를 쓸 에이전트가 헤매지 않도록 지도를 그려주는 역할이죠.
왜 계획을 따로 떼어냈을까요
이 설계에는 분명한 철학이 있어요. 하나의 에이전트가 계획과 실행을 동시에 하면 컨텍스트가 뒤섞이면서 품질이 떨어지거든요. 계획을 먼저 확정하고, 실행은 깨끗한 컨텍스트에서 작업 하나씩 하면 결과가 훨씬 안정적이에요. 사람으로 치면 '설계 회의 따로, 코딩 따로'인 셈이죠.
또 하나 장점은 사람이 중간에 검토할 수 있다는 점이에요. 에이전트가 알아서 스무 가지 일을 저지른 뒤에 '뭘 했는지' 파악하는 것보다, 미리 작업 목록을 보고 '3번은 빼고, 5번은 이렇게 바꿔' 하고 수정하는 게 훨씬 통제하기 쉽거든요.
비슷한 도구들과 비교하면
이 흐름 자체는 새로운 건 아니에요. Claude Code에는 플랜 모드가 있어서 실행 전에 계획을 먼저 보여주고, 서브에이전트로 작업을 나눠 돌리는 것도 가능하죠. Cursor나 Windsurf 같은 에디터에도 비슷한 기능이 있고, Taskmaster 같은 도구는 PRD(요구사항 문서)를 태스크로 쪼개주는 걸 전문으로 해요. Aider의 아키텍트 모드도 '설계 모델과 편집 모델을 분리'한다는 점에서 같은 맥락이고요.
Ordewell이 다른 점은 특정 에이전트에 묶이지 않고, 계획 단계만 독립된 도구로 뽑아냈다는 거예요. 어떤 에이전트를 쓰든 앞단에 붙일 수 있는 '계획 레이어'인 셈이죠. 아직 초기 프로젝트라 기능은 단순한 편이지만, 이런 방향의 도구가 늘어나는 흐름 자체가 의미 있어요. 에이전트 시대의 개발 워크플로우가 '프롬프트 한 방'에서 '계획, 실행, 검증의 파이프라인'으로 옮겨가고 있다는 신호거든요.
실무에서는 어떻게 활용할 수 있을까요
당장 이 도구를 팀에 도입하지 않더라도, 이 사고방식은 바로 써먹을 수 있어요. 에이전트에게 큰일을 시키기 전에 '먼저 작업 목록과 순서만 뽑아줘'라고 요청하고, 그 목록을 검토한 뒤 하나씩 실행시키는 습관만 들여도 결과 품질이 눈에 띄게 달라지거든요. 특히 레거시 코드가 많은 프로젝트에서 대규모 리팩터링을 할 때 효과가 커요.
주니어 개발자분들께는 다른 의미로도 좋아요. 도구가 뽑아준 작업 분해 결과를 보면서 '선배들은 이런 일을 어떤 순서로 나누는구나'를 배울 수 있거든요. 작업 분해 능력은 시니어로 가는 핵심 역량인데, 그걸 눈으로 보면서 익힐 수 있는 거죠.
정리하면
Ordewell은 '에이전트에게 큰 목표를 던지지 말고, 잘 정렬된 작은 작업을 던져라'는 실무 지혜를 도구로 만든 프로젝트예요. 코드를 쓰는 AI보다 일을 나누는 AI가 더 중요해지는 시점이 오고 있는지도 몰라요.
여러분은 코딩 에이전트에게 큰 작업을 시킬 때 어떻게 쪼개서 주시나요? 직접 손으로 나누시는지, 아니면 에이전트에게 먼저 계획을 시키시는지 궁금해요.
🔗 출처: Hacker News