Jev로 효율화를 시험하는 나이아 ADK의 문서 기반 다중 AI 개발 프로세스

안녕하세요. Naia를 만드는 루크입니다.

Naia는 일반 사용자들이 사용하는 캐릭터 에이전트의 상품처럼 보이지만, 제가 하는 일의 상당수는 SW개발 일을 하고 있다 보니 이를 위한 개발 인프라 구축과 기업 고객의 SW개발을 Naia의 개발 인프라를 이용하여 진행하고 있습니다. 이전에 "하네스 엔지니어링: Re:제로부터 시작하는 AI 소프트웨어 공학"(한국어판, 영어판)이라는 책을 발간한 적이 있었는데요. 이 후로도 계속 AI에이전트 기반의 개발 프로세스를 보다 더 잘 갖추기 위해 많은 노력을 하고 있습니다.

오늘은 Naia의 개발을 위해 만들었던 SW개발 프로세스와 산출물을 공개하고, 최근 핫 한 모델인 Jev를 어떻게 이 개발프로세스에 도입을 시도하고 있는지에 대해 공유를 합니다.

제가 이 개발 프로세스에서 쫓고자 했던 것은 3가지로 가시성, 병렬화, 비용 최적화 입니다.

• 가시성 : 제대로 개발하고 있는지, 모델의 드리프트가 일어났다면 어느 단계에서 문제가 났는지를 알고 싶다.
• 병렬화 : 멀티 에이전트를 병렬로 일을 나누어 주어 개발 속도를 높입니다.
• 비용 최적화 : 비용 최적화된 모델을 이용합니다. Jev도 여기에 좋은 대안이 됩니다.

작업 규칙 체계(하네스)의 기본 틀은 아래 오픈소스로 공개되어 있습니다.

• 개인 작업공간의 기본 틀과 작업 규칙 체계(하네스): nextain/naia-adk
• 팀·프로젝트 협업용 기본 틀: nextain/naia-pj-adk
• 커뮤니티 참여 안내: nextain/naia-comm-public
• Jev는 TypeSafe AI가 공개한 결정 모델입니다.

이 글에서 설명하는 작업큐, 보드, 러너, 기획문서는 아직 내부에서 개발 중이라 비공개입니다. 현재 이 프로세스도 검증 단계로서 나이아의 웹에서 선보일 새로운 기능으로, 립싱크와 노래가 가능한 비디오 아바타, 나이아 비쥬얼 에이전트 스튜디오개발에 사용해보고 있습니다. 공개하지 않는 것은 팀 프로젝트로 함께 쓰기에는 아직 다듬어지지 않은 상태이기 때문이며, 정리되는 대로 추가 공개하겠습니다.

이 글과 우리 개발 문서에서 쓰는 약어

먼저 우리 개발 문서와 이슈·작업 큐는 아래 약어를 이렇게 쓰며 프로젝트의 표준 단어사전이 있습니다. AI에게 뭔가 지시할때 길게 치는게 싫었고 용어가 헷갈릴 우려가 있었기 때문입니다.

1. 도입 배경과 문제 인식

AI 에이전트에게 개발을 넓게 맡기면 백엔드 없이 사용자 화면(UI, User Interface)부터 만들거나, 모의 객체로 돌린 시험을 통과로 보고합니다. 그래서 기획은 위에서 아래로(Top-down), 개발은 아래에서 위로(Bottom-up) 진행합니다. 기획은 전체 사용자 경험에서 내려오고, 개발은 동작하는 최소 단위부터 쌓되 백엔드가 실제로 관통한 뒤에야 화면을 붙입니다. 화면 부터 만들면 통합 때 또 수정 사항이 클 가능성이 높기 때문입니다.

2. 문서 기반 작업 흐름과 개발 프로세스

문서를 먼저 쓰는 것은 만들 범위와 수용 기준을 먼저 확정하기 위해서입니다. 시키는 것을 단순 프롬프트가 아닌 문서화 함으로서, 문제 발생시 문제의 원인을 추적하기 위함입니다.

개발 프로세스의 문서들을 모두 목록으로 펼치고 사람이 확인 후에 이슈와 작업 큐 항목을 만듭니다. AI는 새 이슈를 만들기 전에 이슈가 어느 문서에 걸쳐 관계가 있는지를 살피고, 이전에 열린 이슈들도 찾아봅니다. 그래야 이슈·큐·시험 영수증이 모두 제대로 있어야 임무 완료를 판단할 수 있습니다.

문서 뷰어의 개발 절차 페이지입니다.

문서는 도식 순서대로 왜 만드는가(PC)에서 만들 기능 단위(FE)까지 내려가며, 설계(PL)는 모델·엔진의 한계를 먼저 실측한 뒤 세웁니다. 이슈는 기술 계층별로 쪼개지 않고 사용자 가치 하나에 하나만 두며, 여러 저장소에 걸쳐도 하나로 정합니다. 백엔드부터 검수까지의 공정은 그 이슈 안에서 체크리스트로 지정하여 빠뜨리지 않게 하며 완료는 문서로 고정한 범위 전체가 증거를 갖췄을 때만 판정합니다.

기획 문서의 구간마다 이슈와 구현 위치, 판정 상태를 한 곳에서 보는 Studio 통합 색인입니다.

3. 시험의 3층 구조와 순서 규칙

시험은 업계 표준 명칭대로 세 층으로 나눕니다.

• 단위 시험(UT): 기능 단위(FE)가 명세대로 동작하는지 봅니다.
• 통합 시험(IT): 화면 없이 실제 백엔드 구성요소를 끝까지 관통합니다. 모의 객체만 거친 시험은 인정하지 않습니다.
• 사용자 여정 관통 시험(E2E): 실제 브라우저 화면에서 실제 백엔드까지 사용자 여정 하나를 관통합니다. SP에 화면이 없는 단위만 E2E 없이 통합 시험으로 닫고, 화면이 있으면 이번 변경이 백엔드뿐이어도 E2E가 필요합니다. 기준은 구현자의 변경분이 아니라 SP입니다.

핵심은 순서입니다. 백엔드가 통합 시험(IT)을 통과한 뒤에 프론트(화면)를 개발합니다. 지금은 하네스로 이 순서를 막지 않고 있고, 단순히 작업 지시서와 독립 리뷰가 영수증으로 확인 중으로, 개선할 여지가 있습니다.

독립 검수(QC)는 구현자의 시험과 따로, UC와 FE를 보지 않고 PC와 SP만으로 억지 입력과 예외 상황에서 제품 약속이 지켜지는지를 확인합니다. UC와 FE를 보면, 그 범위만 확인하려 할 수 있기 때문입니다. 개발 단계에서는 뒷쪽 작업 단계라 아직 실증 검증을 못해봤습니다.

4. Git 기반 작업 큐와 작업보드

누가 언제 무엇을 했는지 믿을 수 있도록 작업은 Git 저장소(naia-comm)의 작업 큐로 관리합니다. 공유 서버는 아직 없고, 검증 후에 개발 서버를 만들고, 여러 기기와 여러 개발자들이 협업을 할 수 있게하는 것이 목표입니다.

참여 기기마다 저장소를 복제해 주기적으로 당겨 새 작업을 찾고, 작업 기록을 보고합니다. 실행은 기기 소유자가 로컬에 등록한 러너(큐에서 작업을 받아 AI를 대신 돌려 주는 프로그램)만 하며, 큐에는 러너의 이름만 적히고 실행할 명령은 담기지 않습니다.

작업의 각 단계는 새 JSON 파일로 작성됩니다. 결과 영수증에는 실행 증거와 종료 코드를 쓰고, 취소도 더하는 방식으로 모든 작업을 로깅하여 추적성을 강화했습니다. 작업보드는 이 기록을 요청할 때마다 다시 읽어 보여 주기만 하는 화면입니다.

작업보드 화면입니다(내부 주소는 가렸습니다). 상단 지표는 naia-comm main 브랜치의 큐 기록을 집계한 것으로, 캡처 시점에 작업 항목 228개 가운데 가용 10건, 실행 중 1건, 현재 성공 결과 65건이었고, 등록되지 않은 러너 이름으로 성공한 기록 4건에 경고가 붙었습니다.

5. 작업 규칙 체계와 다중 에이전트 협업 구조

작업 규칙 체계는 문서로 정한 규칙과 그 확인 절차입니다. 자동 점검 장치는 지금 복구 모드로 꺼 두었고(보드 화면의 "하네스 OFF"), 규칙을 코드로 막는 관문도 아직 없어서, 조정자의 작업 지시서와 감시 스크립트, 독립 리뷰가 규칙을 지키게 합니다.

상위 모델만 쓰면 비용이 크게 증가하고, 경량 모델만 쓰면 설계와 검증에 실패하여 프로젝트가 망가집니다. 그래서 작업 성격에 따라 모델을 나눠 배치하고 서로 검증하게 했습니다.

※ 모델 배치는 시험 중이며 바뀔 수 있습니다.

비용 효율과 권한 분리를 통해, 양이 많은 구현과 시험 반복은 Gemini 3.8 Flash에 맡겨 상위 모델 한도를 아끼고, 역할별 적합한 모델은 계속 바꿔가며 찾아보고 있습니다. 작업자는 스스로의 권한을 스스로 넓힐 수 없어 에이전트가 스스로 권한을 주고 문제를 일으킬 가능성을 줄였습니다. 대신 이 기능의 버그로 인해 진행 불가 상태로 고립 되서 멈추는 상황이 많아서 지속 테스트 개선 하고 있습니다.

예를 들어 "선언된 저장소 체크아웃 일치" 같은 위치 점검은 러너를 거칠 때만 동작하고, 작업 지시서로 바로 띄운 실행에는 적용되지 않습니다.

6. 독립 조사 기반의 적대적 리뷰

리뷰어는 제출물을 열기 전에 원래 지시, 저장소, 커밋, 작업 큐 기록을 먼저 직접 조사해 자기 결론을 적고, 그다음 제출물과 대조합니다. 제출물만 보면 잘못된 전제나 엉뚱한 저장소를 놓치기 때문입니다. 매번 새 리뷰어가 보고, 결론을 바꾸는 지적이 두 번 연속 없으면 통과입니다. 사소한 지적루프가 반복되면 멈추고 사람에게 넘겨 결정을 묻습니다.

7. 관측된 성과와 한계

관측된 성과

저비용 모델(Gemini 3.8 Flash)이 비대화 명령줄 세션으로 구현하고, 조정자가 작업 지시서와 감시 스크립트로 경계를 보고, 상위 모델이 매 회차 새 세션에서 독립 조사 후 대조하는 구도가 돌아갑니다. 감시 스크립트는 작업자가 실행한 명령을 사후에 보여 주고, 리뷰어는 작업자가 적은 틀린 사실을 잡아낼 수 있는 구조가 되었습니다.

관측된 한계와 취약점

저렴하고 성능이 낮은 모델은 지시를 지키지 않고 진행하는 경우가 많았습니다. 만들어지지 않은 큐 ID를 적고 완료로 보고하거나, 지시에 없는 면제 조항을 절차 문서에 넣거나, 요약하면서 원문 조건을 슬쩍 바꿉니다. 시험 세션은 스크립트가 통과하는지만 보고, 그 시험이 실제 백엔드를 도는지는 가리지 못합니다.

이런 결함은 독립 리뷰가 걸러 내지만 검증 비용이 큽니다. 상위 리뷰 모델의 품이 기계적 사실 확인에 많이 들어가기 때문입니다. 적합한 모델 구성을 역할마다 계속 시험하는 이유이기도 합니다.

8. Jev를 통한 검증 효율화와 향후 과제

리뷰 부담을 줄이려고 검증을 세 층으로 나누어봤습니다. 그중 두번째 층에 최근 비용이 낮고, 빠른 속도가 장점인 Jev도입을 검토하려고 기술 검증 중에 있습니다.

• 첫째 층, 기계적 확인(스크립트): 시험 영수증의 통과·실패(실패 0건, 종료 코드 0), 주소 응답, 파일 존재처럼 대조만 하면 되는 것.
• 둘째 층, 유형 판정(Jev): 통합 시험(IT)과 E2E 영수증이 "통과"라고 할 때, 그 시험이 실제 백엔드를 거쳤는지 가짜만 돌고 통과했는지를 가립니다. 단위 시험(UT)은 원래 가짜를 써도 되므로 대상이 아닙니다.
• 셋째 층, 방향 판단(상위 모델과 사람): 범위와 의도가 맞는지.

Jev는 TypeSafe AI의 결정 모델로, 정해진 선택지와 확률로만 빠르게 답하는 저비용 모델로 SW개발은 선택 문제가 많고, 지속적인 측정을 통해 적절한 경계값(Threshold)를 찾아 비용과 속도 효율을 달성할 수 있습니다. 이는 LLM이전의 전통적인 AI SW개발에서 많이 쓰던 최적화 방식으로 검증 결과는 아래와 같습니다.

검증 결과

확신도 0.85 이상이면서 다른 문구로 물어도 같은 답일 때만 Jev 판정을 쓰고 나머지는 대형 언어 모델(LLM)에 넘기는 방식으로, 시험 파일 871개(최종 평가 257개)에서 시간은 약 66%, 비용은 약 60~70% 줄일 수 있는 것으로 측정·추정했습니다 (시간은 Gemini 3.8 Flash 기준, 비용은 Opus·Luna 같은 모델의 단가로 계산한 추정치).

Jev 호출 971번의 비용은 0.22달러였고, 판정 한 건에 Jev는 약 0.7초, LLM은 약 12초가 걸렸습니다.

최적 값은 실험을 넓혀 계속 찾고 있습니다. 가능성은 확인했지만, 아직 실제 개발 프로세스에 붙이지는 않았습니다. 정답은 두 AI가 같은 답을 낸 것만 썼기 때문에 쉬운 파일 쪽으로 치우쳤을 수 있습니다.

향후 과제

이 절차로 스튜디오의 첫 기능(대본을 넣으면 음성을 만들어 듣고 내려받기)을 백엔드부터 사용자 여정 관통 시험까지 끝냈습니다. 남은 과제는 검증을 더 자동화하고, 지금 사람과 지시서가 지키게 하는 규칙을 도구가 지키게 만드는 일입니다. 또 Jev를 검증 표시뿐 아니라, 작업 하나가 끝났을 때 다음에 할 일을 고르는 흐름 통제에도 쓸 수 있는지 따로 실험할 계획입니다. 이러한 흐름 판단은 작업마다 상위 모델을 불러야 해서 비용이 들고 시간 지연이 큰 부분이기 때문입니다.

공유한 내용이 도움들이 되셨으면 좋겠습니다. 나이아의 제품에도 관심 많이 부탁드립니다. 제품을 빨리 내서 성과를 보여야 다음 단계로 갈 텐데, 까다로운 AI의 통제와 개발 방법에 대해 계속해서 많은 시간을 더 쓰고 있는 것만 같습니다.