대시보드 7장 · 좌우로 넘겨 보세요. 이미지를 누르면 크게 볼 수 있습니다.
커밋 779개·코드 약 7만 3천 줄, 구현부터 독립 검증·인계·비용 통제까지
14시간 동안 코드 약 7만 3천 줄. 숫자를 처음 받아 들면 ‘미리 만들어 둔 코드를 복붙한 건 아닐까’ 하는 의심이 들 정도다. 김대운 대표 한 사람이 수십 개의 AI 에이전트를 동시에 조율해 검색·분석·검증·내보내기가 연결된 서비스를 구현하고, 커밋 779개와 테스트 기록을 남겼다. 투입 시간에 비해 놀라운 규모다.
그런데 데이웨이가 제공한 개발 기록을 시간대별로 펼쳐 보면, 커밋은 한꺼번에 들어오지 않았다. 저녁 7시 한 시간에 205개로 정점을 찍은 뒤에도 자정을 넘겨 새벽까지 시간마다 수십 개씩 이어졌다. 그 사이에 병합 커밋 164개가 끼어 있고, 새벽에 발견된 결함도 같은 밤 안에 수정됐다. 숫자를 보고 생긴 의심이 ‘어떻게 이 많은 작업을 끊기지 않게 이어 갔을까’라는 질문으로 바뀌는 대목이다.
2026 NAIS AI 해커톤에서 대상을 받은 데이웨이 김대운 대표의 Project Neumann 개발 사례다. 짧은 시간에 이 정도의 결과를 만들어 낸 병렬 작업 방식과, 그 결과를 하나의 서비스로 합치기 위한 검증·인계·비용 관리가 함께 눈길을 끈다. 다른 개발자가 자신의 작업에 적용할 수 있는 운영 경험을 살펴보자.
Project Neumann은 논문 리뷰에서 드러난 실패 요인을 체크리스트로 정리해 연구의 사전기획을 돕고, 여러 AI 에이전트가 수정·검증을 이어가며 계획서를 완성하는 서비스다. 로컬에서 BGE-M3 임베딩 모델을 돌려 관련 근거를 찾고, GPT-6.1 솔 기반 다중 에이전트에 API·MCP와 분석·검증 도구를 연결한다.
개발에 적용한 GPT-6.1 솔은 개발을 시작하기 전날인 9월 29일 공개된 모델이다. 갓 나온 모델을 곧바로 기획·구현·검증 흐름에 연결한 점에서도, 새로운 기술을 실제 작업에 받아들이는 김대운 대표의 유연성이 드러난다. OpenAI 공식 공개 기록
이런 서비스를 운영하려면 구현뿐 아니라 성능평가, 테스트 범위, 실제 API 호출과 토큰 사용량을 함께 관리해야 한다. 사람이 실행 범위와 예산, 중단 기준을 정하지 않으면 반복 호출로 비용이 빠르게 불어날 수 있다. 한 번의 지시로 끝내기보다 작은 단위로 만들고 검증하며 다음 실행을 승인하는 과정이 필요하다.
데이웨이가 제공한 원고와 개발 기록에 따르면, 2026 NAIS AI 해커톤에서 대상을 받은 김대운 대표의 ‘Project Neumann’ GitHub main 브랜치에는 9월 30일 저녁 6시 6분부터 이튿날 아침 8시까지, 약 14시간 동안 커밋 779개가 쌓였다. 병합 커밋을 빼도 615개다. main에 합쳐지지 않은 작업 브랜치까지 세면 1,122개가 된다. 제품 코드는 파이썬 약 3만 줄(함수 1,371개)이고, 테스트 코드는 그보다 많은 4만 3천 줄이다. 최종 테스트 2,979건이 통과했다.
개발 기록에는 구현과 병합, 결함 수정이 시간대별로 이어진 과정이 남아 있다. 이 글은 그 과정에서 쓰인 작업 분담과 검증, 인계 방식을 공유한다.
연결된 기능만큼 관리할 지점도 늘어난다
검색과 LLM 분석, 수정안 작성, 수학·단위·구조 검증, 결과 서명과 내보내기가 한 흐름으로 연결됐다. 각 기능이 따로 동작하는 것에 더해, 입력과 출력이 다음 단계로 제대로 넘어가는지 확인해야 했다.
데이웨이가 제공한 설명에 따르면, 이 작업을 조율한 장비는 인텔 i7·RAM 32GB·RTX 4050을 갖춘 랩탑 한 대였다. 그 장비에서 BGE-M3 임베딩 모델을 로컬로 실행하면서, 클라우드 AI를 활용하는 수십 개 에이전트의 병렬 작업을 함께 조율했다. 로컬의 근거 검색과 클라우드의 추론을 역할에 맞게 나누고, 에이전트별 작업 분담과 병합 순서, 사용량을 관리한 것이다. 랩탑 한 대를 개발 관제소로 삼아 약 14시간 만에 이 정도의 생산량을 낸 점은, 최신 모델을 활용하는 능력과 함께 컴퓨팅 자원을 배분하고 운용하는 역량을 보여주는 인상적인 대목이다.
출발점은 코딩이 아니라 기획이었다
김대운 대표는 북스코프로 받은 2026 도서관 데이터 활용 공모전 대상(문화체육관광부장관상)을 비롯해 수십 개의 AI·데이터 경진대회·공모전에서 수상하였으며, 올해 범정부 공공데이터·AI 활용 창업경진대회와 ‘올해의 K-스타트업 2026’의 통합 본선에도 동시에 진출해 있다. 이러한 수상과 본선 진출은 이미 상당한 기술력과 서비스 구현 역량을 인정받아 왔음을 보여준다. 이번 사례에서는 그 기획·개발 경험을 작업 분해와 완료 기준, 여러 AI 에이전트의 운영에 어떻게 적용했는지 살펴볼 수 있다.
기본적으로는 수십 개 에이전트를 동시에 굴리려면 먼저 해야 할 일이 있다.
- 일을 서로 겹치지 않는 단위로 쪼갠다.
- 각 단위의 완료 기준과 마감을 정한다.
- 누가 만들고, 누가 검증하고, 누가 합치는지 경계를 긋는다.
이 설계 없이 AI를 늘리면 혼란만 커진다. 이번 프로젝트에서는 작업 계획(WBS)과 완료 기준을 먼저 세운 뒤 그 틀 안에서 에이전트를 배치했다. 같은 파일을 두 에이전트가 동시에 고치지 않도록 범위를 나눴고, 병합 순서를 미리 정했다.
역할을 나눈 AI 에이전트들
개발에 참여한 AI 에이전트들은 구현과 검증, 운영 등의 역할을 나눠 맡았다. 역할과 책임을 정리하면 다음과 같다.
| 역할 | 맡은 AI | 하는 일 |
|---|---|---|
| 최종 결정권자 | 사람(대표) | 방향·범위 결정, 비용·공개·다운로드 승인 |
| PM | Claude 세션 | 병합 순서, 판정, 배포의 단일 창구, 결정 기록 |
| 총괄 지휘관 | Claude 세션 | 작업 분해, 에이전트 배치, 결과 수거, 서버 운영 |
| 설계·구현 빌더 | Claude 에이전트 | 분석 엔진, 검증 도구, 화면, 보안 결합 |
| 작가 | Claude 에이전트 | 발표자료 전면 재작성. 샘플 연구계획서는 3명이 동시에 한 편씩 집필 |
| 현장 인력 | Codex 작업 94개 | 결함 수정, 기능 구현 |
| 검증관 | Codex | 남이 만든 결과를 적대적 반례로 판정. 통과 못 하면 병합 불가 |
| 실전 시험관 | Codex | 승인된 범위에서 실제 서비스를 한 건씩 끝까지 돌려 봄 |
| 퍼저·부하 시험관 | Codex | 비정상 입력과 동시 접속으로 서버를 두드림 |
| 보안관 | Codex | 공개 전 보안 점검 |
| 촬영 담당 | Codex | 발표용 화면 캡처, 시연 영상 녹화 |
| 수거반 | 자동 장치 | 끝난 작업을 1분마다 자동 커밋 |
| 브레이크 | 자동 장치 | 사용 한도에 닿으면 전체 정지 |
| 경비 | 자동 장치 | 대시보드가 죽으면 다시 띄움 |
그리고 이런 작업을 모아 보는 곳이 개발 대시보드였다. 김대운 대표는 AI에게 맡겨 둔 채 기다리는 대신, 대시보드로 전 과정을 직접 눈으로 확인하며 자신의 통제 범위 안에서 관제했다. 한 화면에 다음이 실시간으로 올라왔기에 작은 랩탑 화면 하나만 가지고도 컨트롤을 할 수 있었다.
- 작업 계획과 진행 상황
- 사람과 AI들이 주고받은 메시지 262건
- 사람이 결정해야 할 일만 추린 ‘확인 필요’ 목록
- AI 서비스별 사용량
226개 작업 공간이 동시에 움직이는데도 메인 코드가 무너지지 않은 것은 “합치는 창구는 하나”라는 규칙 덕분이었다.
특히 AI가 AI를 부리는 장면이 인상적이다. 사람이 Codex 창을 하나씩 연 것이 아니라, 지휘를 맡은 Claude가 지시문을 쓰고 작업 공간을 만들어 Codex를 직접 띄웠다. 한때는 30개 넘게 동시에 돌았다.
통제 장치도 함께 붙였다.
- 키 차단: Codex가 실행되는 환경에서는 API 키와 실제 호출 허가를 처음부터 지웠다.
- 브라우저 조작 차단: 밤사이 한 작업이 개발자 브라우저의 탭 목록을 읽은 일이 있었고, 그 뒤로 브라우저·화면 조작 기능은 전부 막았다.
- 병합 대행: Codex가 샌드박스 권한 때문에 병합을 못 하고 멈추면 Claude가 병합을 대신 해 두고 다시 일을 맡겼다.
사람은 승인하고, Claude는 지휘하고, Codex는 실행하는 3층 구조였다.
맥락이 쌓인 에이전트는 ‘해고’한다
새벽 4시 무렵 대시보드에 경고가 떴다. Claude의 5시간 사용 한도가 10분 만에 10%씩 줄고 있는 상황이 감지된 것이었다. 이 속도면 시연 준비가 한창일 시간에 바닥날 상황이었다.
원인은 에이전트의 수가 아니라 문맥이었다. 한 시간 넘게 일한 에이전트 몇 개의 대화 문맥이 50만 토큰을 넘어서 있었다. 이런 에이전트는 도구를 한 번 부를 때마다 그 50만 토큰을 다시 읽는다. 일은 조금 하면서 비용과 시간은 가장 많이 먹는 상태였다.
그래서 김대운 대표는 진행 중인 작업을 커밋과 인계 문서로 남긴 뒤, 문맥이 무거워진 에이전트를 ‘해고’하고 새 에이전트를 ‘채용’했다.
- 하던 일을 커밋하게 한다.
- 끝낸 것, 남은 것, 조심할 것을 15줄짜리 인계 문서로 남기게 한다.
- 기존 에이전트를 ‘해고’한다. 진행 중인 세션을 종료하는 것이다.
- 남은 일은 새로 ‘채용’한 에이전트에게 맡긴다. 새 에이전트는 인계 문서부터 읽고 시작한다.
이 ‘해고와 재채용’은 개발 속도와 비용을 함께 관리하기 위한 운영 기능이었다. 필요한 기록을 짧은 인계서로 넘기면 새 에이전트가 이미 끝낸 작업의 긴 대화를 계속 처리하는 부담을 줄일 수 있다. 교체하지 않았다면 과거 문맥을 처리하는 데 시간과 AI 사용량을 더 쓰면서 개발 속도가 떨어지고, 시연 준비나 최종 검증을 마치기 전에 사용 한도가 먼저 소진돼 작업이 멈출 위험이 컸다. 유료 API를 쓰는 환경에서는 이런 반복 처리가 호출 비용을 키울 수도 있다.
경험이 쌓인 에이전트를 해고해도 개발이 끊기지 않는 이유
에이전트를 여러 번 교체했는데도 개발이 끊기지 않은 이유는 단순하다. 기억을 에이전트 머릿속이 아니라 저장소에 두었기 때문이다.
- 커밋: 모든 진행은 작은 단위로 커밋됐다. 에이전트가 사라져도 그때까지 한 일은 저장소에 남는다.
- 작업 공간: 작업마다 독립된 작업 공간과 브랜치가 있어서, 새 에이전트는 그 자리에서 바로 이어받는다.
- 인계 문서: 각 작업은 보고서와 ‘남은 일’ 목록을 남겼다. 프로젝트 전체로는 의사결정 기록 99건, 인수인계 문서, 작업 대기열이 계속 갱신됐다.
- 테스트: 테스트 2,979건이 “제대로 동작한다”의 기준을 대신 기억했다. 새 에이전트가 무언가를 깨뜨리면 테스트가 바로 알려 준다.
- 계약 문서: 데이터 형식을 정한 문서(JSON 스키마)가 모듈 사이의 약속을 붙잡아 두었다.
- 메시지함: 대시보드 메시지함이 누가 무엇을 지시하고 보고했는지를 남겼다. Claude 사용 한도가 차서 Codex가 통째로 넘겨받았다가 다시 돌려줄 때도 이 기록으로 이어 갔다.
사람으로 치면 퇴사자가 나와도 인수인계서, 업무 매뉴얼, 품질 기준이 남아 있어 신입이 바로 일을 이어받는 조직이다. 작업을 이어 갈 수 있었던 것은 필요한 기록과 기준을 시스템에 남긴 덕분이다.
만든 AI가 아니라 다른 AI가 검증한다
기능을 만든 AI는 그 기능을 검증하지 않았다. 별도의 검증관이 일부러 공격적인 반례를 던져 판정했고, 통과하지 못하면 병합하지 않았다. 이 과정에서 잡힌 결함은 다음과 같다.
- 두 요청이 동시에 들어오면 서버가 멈추는 결함
- 내보내기 기능에서 300번 중 40번 나던 오류
- 서명된 결과물을 섞어 위조하는 허점
개발은 비용이 들지 않는 가짜 응답(mock)으로 하고, 실제 AI 모델은 승인된 몇 번의 시험에만 썼다. 그 실전 시험이 가짜 응답에서는 보이지 않던 결함 다섯 가지를 찾아냈고, 모두 그날 밤 안에 고쳐졌다. 새벽에는 테스트 출력에 API 키가 찍히는 사고도 있었다. 팀은 재발 방지 코드를 곧바로 넣고, 저장소 전체 이력을 검사해 외부 유출이 없음을 확인했다.
실제 운영에서 챙겨야 할 세 가지
에이전트를 늘리면 동시에 처리할 일은 많아지지만, 성능과 비용이 그만큼 좋아지는지는 별도로 확인해야 한다. 이번 사례에서는 다음 세 가지를 관리 대상으로 삼았다.
- 작업 문맥과 인계: 대화가 길어지면 필요한 기록을 정리하고 작업을 인계한다. 같은 설명을 반복해서 읽는 부담과 앞선 결정이 흐려지는 문제를 줄인다.
- 성능평가와 독립 검증: 코드가 실행되는지와 결과가 쓸 만한지를 구분한다. 만든 쪽과 다른 에이전트가 반례와 테스트로 확인하고, 실제 모델을 사용한 평가도 필요한 범위에서 진행한다.
- API 호출과 비용: 개발·반복 테스트는 가짜 응답(mock)을 활용하고, 실제 API 호출은 승인한 범위에서 실행한다. 토큰 사용량과 반복 호출을 확인하고 예산을 넘기기 전에 중단할 기준을 둔다.
자동화할 일을 늘리더라도 목표와 평가 기준, 예산과 중단 판단은 사람이 챙겨야 한다. 개발 속도와 함께 이런 통제 과정을 공유하는 것이 이 사례의 의미다.
정리하며
Project Neumann의 제품 철학은 이 개발 방식과 닮았다. 이 서비스는 불완전한 연구계획서를 받아 실제 학술 심사 기록을 근거로 위험을 짚고, 수정 계획서를 만든 뒤, 수학 풀이기(Z3), 단위 계산(Pint), 구조 분석(NetworkX) 도구로 계산 오류까지 검증해 최종 초안을 내놓는다. 팀은 그 바탕에 폰 노이만이 1956년 논문에서 던진 질문을 깔았다. “신뢰할 수 없는 부품으로 신뢰할 수 있는 시스템을 만들 수 있는가.” 하나하나는 실수하고 지치고 교체되는 AI 에이전트들을 모아 믿을 만한 결과물을 만든 개발 과정 자체가 그 질문에 대한 답처럼 보인다.
AI를 활용해 개발을 하고자 하는 사람들이 가져갈 만한 것은 특정 도구가 아니다.
- 일을 병렬로 나눌 수 있게 설계하는 기획
- 역할과 책임이 분명한 에이전트 구성
- 기억을 저장소에 두는 습관
- 만든 쪽과 검증하는 쪽의 분리
- 사용량과 사고까지 관리 대상으로 보는 태도
- 자동화한 결과도 직접 평가하고, 실행 범위와 비용을 통제하는 습관
각자의 프로젝트에 맞게 작업 범위와 완료 기준을 먼저 정하고, 검증과 인계, 비용 통제를 함께 설계하는 데 이 사례를 참고할 수 있다.
수상·개발 수치 출처: 데이웨이 제공 원고와 개발 기록. Project Neumann GitHub main 브랜치 기록(첫 커밋 2026년 9월 30일 18:06, 마지막 10월 1일 08:00; main 커밋 779개, 병합 제외 615개, 작업 브랜치 포함 시 1,122개), 개발 대시보드 기록, 검증 보고서. 일부 성능 수치는 가짜 응답(mock) 기준이다. 상단 대시보드는 집계 종료 이후의 상태도 담고 있어 main 커밋 789개, 테스트 2,990건 등 본문의 마감 시점 수치와 다르게 표시될 수 있다.