프론티어노트 thefutureisnowhere
ESSAY · Issue issue-03 · 2026. 06. 04.

완주, 가벼움, 명확함, 경계

네 명의 한국 AI 빌더는 LLM의 한계를 어떻게 다른 런타임으로 바꾸고 있나

Feature Note · 공개 자료 기반 편집 노트

AI 코딩 에이전트의 차이는 이제 모델 이름만으로 설명되지 않는다.

같은 모델을 써도 어떤 빌더는 완주를 만든다. 어떤 빌더는 가벼움을 만든다. 어떤 빌더는 명확함을 만든다. 어떤 빌더는 경계를 만든다.

프론티어노트는 이 차이를 기능 차이로만 보지 않는다. 하네스는 모델 위에 붙는 도구 묶음이 아니라, 빌더가 LLM의 한계를 어떻게 읽는지 드러내는 작업 방식에 가깝다.

여기서 하네스는 모델이 실제 일을 하도록 감싸는 실행 구조를 뜻한다. 프롬프트, 도구 호출, 파일 수정, 검증, 기억, 이어 달리기 같은 것들이 여기에 들어간다. 런타임은 그 구조가 실제로 돌아가는 바닥이다. 모델이 한 번 답하고 끝나는 것이 아니라, 작업이 여러 단계로 이어지게 만드는 환경이다.

이 글은 완성된 인터뷰가 아니다. 공개 저장소, 공개 문서, 공개 계정, 그리고 현장에서 받은 인상을 바탕으로 쓴 첫 편집 노트다. 당사자의 의도를 확정하려는 글이 아니라, 프론티어노트가 지금 이 흐름을 어떻게 읽고 있는지 먼저 꺼내는 글이다.

왜 지금 하네스인가

모델이 좋아지면 하네스도 사라질까.

프론티어노트는 그렇게 단순하게 보지 않는다. 모델이 약할 때의 하네스는 모델이 못 하는 일을 보완한다. 하지만 모델이 강해질수록 질문은 달라진다. 무엇을 더 붙일 것인가가 아니라, 무엇을 남길 것인가가 중요해진다.

어제의 보완 장치는 오늘의 과한 구조가 될 수 있다. 반대로 모델이 아무리 좋아져도 사라지지 않는 문제가 있다. 긴 작업을 끝까지 밀고 가는 일. 모호한 요청을 명확한 목표로 바꾸는 일. 도구 호출의 경계를 안정적으로 잡는 일. 작업의 증거를 남기는 일.

그래서 좋은 하네스는 더 많은 기능을 붙이는 경쟁이 아닐 수 있다. 좋은 하네스는 어떤 실패를 반복해서 보았는지, 그 실패를 어떤 루프로 바꾸었는지에 대한 대답일 수 있다.

정구봉님의 최근 포스팅에서 받은 질문도 여기에 닿아 있었다. 그는 lazycodex, gajae-code, roach-pi를 단순한 도구 묶음이 아니라, 모델이 좋아질수록 하네스의 역할이 다시 조정되는 흐름으로 읽어냈다. 프론티어노트는 그 질문을 이어받아, 각 빌더가 LLM의 한계를 어떻게 다르게 해석하고 있는지 따라가보려 한다.

김연규님, 완주

김연규님의 작업은 OmO와 LazyCodex를 중심으로 보인다. 공개 문서에서 OmO는 여러 에이전트, 모델 라우팅, 스킬, 훅, 검증을 묶는 에이전트 하네스로 설명된다. LazyCodex는 그 OmO를 Codex 환경에서 쓰기 위한 패키징에 가깝다.

프론티어노트는 이 작업을 완주라는 단어로 읽었다.

긴 작업에서 에이전트가 흐트러지는 순간은 자주 온다. 처음 계획은 좋지만 중간에 길을 잃는다. 검증 전에 완료를 선언한다. 앞서 얻은 맥락을 잊고 같은 실수를 반복한다. 김연규님의 작업은 이런 문제를 모델 하나의 성능 문제가 아니라, 계획, 실행, 검증, 기억의 루프 문제로 다루는 듯하다.

이 관점에서 중요한 것은 LLM의 불완전성을 지우는 일이 아니다. 오히려 그 불완전성을 전제로 작업이 계속 굴러가게 만드는 일이다. 모델이 흔들릴 수 있다는 사실을 받아들이고, 흔들린 뒤에도 다시 계획으로 돌아오게 만드는 구조다.

OBA 해커톤 현장에서 김연규님과 나눈 짧은 대화도 이 인상을 강하게 만들었다. 프론티어노트는 그 대화를 공식 입장으로 읽지 않는다. 다만 현장에서 받은 인상은 분명했다. 이 프로젝트는 단순히 기능이 많은 도구라기보다, 작업을 끝까지 굴리는 방식을 고민하는 작업 철학에 가까워 보였다.

허예찬님, 가벼움

허예찬님의 gajae-code는 다른 방향에서 흥미롭다. 공개 README는 이 프로젝트를 작고 선명한 코딩 에이전트 하네스로 설명한다. 핵심 흐름은 deep-interview, ralplan, ultragoal로 이어진다. 필요할 때만 팀 실행을 붙이는 구조다.

프론티어노트는 이 작업을 가벼움이라는 단어로 읽었다.

AI 하네스는 쉽게 무거워진다. 스킬이 늘고, 에이전트가 늘고, 모드가 늘어난다. 처음에는 도움이 되던 구조가 어느 순간 사용자가 기억하기 어려운 표면이 된다. gajae-code는 그 반대쪽 질문을 던지는 프로젝트로 보인다.

더 많은 기능보다 하나의 좋은 루프. 더 넓은 스킬 묶음보다, 모호함을 줄이고 계획을 세우고 목표를 끝까지 추적하는 얇은 길. 이 프로젝트는 그 길을 더 잘 만드는 쪽에 집중하는 듯하다.

이 가벼움은 단순함과 다르다. 단순히 기능이 적다는 뜻이 아니다. 사용자가 실제로 반복해서 쓸 수 있는 루프를 남기고, 나머지는 가능한 한 걷어내려는 태도에 가깝다. 프론티어노트는 여기서 하네스의 또 다른 방향을 본다. 강한 구조는 때로 작게 남는 구조다.

정승현님, 명확함

정승현님의 roach-pi는 pi 코딩 에이전트 위에 올라가는 확장으로 공개되어 있다. 공개 README는 clarifying, goal, verifier가 이어지는 구조를 설명한다. 모호한 요청을 Goal Contract로 바꾸고, 실행 뒤에는 검증 루프를 통과하게 만든다.

프론티어노트는 이 작업을 명확함이라는 단어로 읽었다.

AI 에이전트에게 더 많은 자유를 주면 결과가 좋아질까. roach-pi는 그 질문에 다른 쪽으로 답하는 프로젝트처럼 보인다. 에이전트에게 필요한 것은 더 큰 자유가 아니라, 더 명확한 목표와 검증 기준일 수 있다는 쪽이다.

모호한 요청은 모호한 코드가 되기 쉽다. 사용자는 대략 말하고, 모델은 그 대략을 성급히 구현한다. 결과는 돌아가 보일 수 있지만, 무엇을 성공으로 봐야 하는지 흐려진다. roach-pi는 이 흐림을 먼저 작업 계약으로 바꾸려 한다.

여기서 Goal Contract는 문서 양식 이상의 의미를 갖는다. 목표, 범위, 제약, 성공 기준, 필요한 증거, 리스크를 먼저 세우는 작업 방식이다. 프론티어노트는 이 지점에서 명확함을 본다. 코딩 능력보다, 요청이 검증 가능한 작업으로 바뀌는 과정에 더 집중하는 태도다.

민웅기님, 경계

민웅기님의 작업은 앞의 세 사람과 같은 층위에만 놓기 어렵다. pss-next, plugsuits, ai-sdk-tool-call-middleware, pss-mgba는 코딩 워크플로우 하나의 사용법보다 더 아래 레이어를 향한다.

pss-next는 작은 에이전트 런타임 작업장으로 공개되어 있다. 런타임, 세션, 모델 루프를 나누고, 실행 중인 run의 이벤트를 소비하면서 세션을 이어가거나 조향하는 구조를 드러낸다. plugsuits는 Vercel AI SDK 위에 얇은 타입스크립트 하네스를 만든다. ai-sdk-tool-call-middleware는 네이티브 도구 호출을 지원하지 않는 모델에서도 도구 호출을 파싱할 수 있게 하는 미들웨어다. pss-mgba는 이미 실행 중인 mGBA 인스턴스를 대상으로, 포켓몬 플레이 하네스를 별도 흐름으로 다룬다.

프론티어노트는 이 작업을 경계라는 단어로 읽었다.

여기서 흥미로운 질문은 무엇을 더 만들 것인가가 아니다. 무엇을 범용 런타임으로 올리고, 무엇을 특정 하네스에 남길 것인가다. 모델과 도구 사이의 최소 인터페이스는 어디까지 얇아질 수 있는가. 특정 게임, 특정 작업, 특정 코딩 루프에만 필요한 지식은 어디에 머물러야 하는가.

pss-mgba의 공개 설명은 이 경계를 잘 보여준다. 포켓몬 램 읽기, 이동 감독, 막힘 기억, 진행 점수, 스크린샷 처리는 별도 하네스에 남긴다. 별도의 근거 없이 범용 런타임 요구로 올리지 않는다는 태도다. 프론티어노트는 이 구분이 중요하다고 본다. 모든 것을 프레임워크로 끌어올리면 런타임은 무거워진다. 반대로 모든 것을 개별 하네스에 남기면 반복 가능한 인터페이스가 사라진다.

민웅기님의 작업은 그 사이의 선을 계속 만지는 것으로 보인다. 하네스는 무거운 프레임워크가 아니라, 모델과 도구를 잇는 얇은 착용감일 수 있다는 질문이다.

네 단어가 남기는 것

이 네 사람은 같은 도구를 만드는 사람들이 아니다.

각자 LLM의 다른 실패를 보고 있다. 김연규님은 완주를 본다. 긴 작업이 끝까지 굴러가지 않는 실패다. 허예찬님은 가벼움을 본다. 하네스가 계속 무거워지는 실패다. 정승현님은 명확함을 본다. 모호한 요청이 모호한 코드로 바뀌는 실패다. 민웅기님은 경계를 본다. 런타임과 하네스 사이의 선이 흐려지는 실패다.

프론티어노트는 이 네 단어가 지금 AI 빌더들이 보고 있는 작업 방식의 변화를 보여준다고 본다.

AI 빌더들은 더 강한 모델을 기다리는 대신, 자신이 믿는 작업 방식을 런타임으로 만들고 있다. 누군가는 완주를 위해 루프를 만든다. 누군가는 가벼움을 위해 표면을 줄인다. 누군가는 명확함을 위해 계약과 검증을 앞세운다. 누군가는 경계를 위해 인터페이스를 얇게 다듬는다.

이 흐름은 도구 비교표로는 잘 보이지 않는다. 기능을 나열하면 네 프로젝트는 비슷해 보일 수 있다. 하지만 어떤 실패를 먼저 보았는지 따라가면, 전혀 다른 작업 철학이 드러난다.

다음 단계

이 글은 공개 자료와 레포를 기반으로 한 1차 편집 노트다. 공개 자료만으로는 각 빌더가 어떤 실패를 겪었고, 어떤 판단으로 지금의 구조를 선택했는지 충분히 알 수 없다.

다음 단계에서는 각 빌더와의 인터뷰를 통해 이 관점을 더 정확하고 깊게 확인하고 확장할 예정이다. 프론티어노트는 도구의 기능보다, 그 도구에 담긴 작업 철학을 기록한다.

이 글은 각 프로젝트의 공개 저장소와 공개 발언을 바탕으로 작성한 1차 편집 노트입니다. 이후 각 빌더와의 인터뷰를 통해 내용을 보완할 예정입니다.

이 글은 특집의 시작입니다. 다음 글에서는 각 빌더의 관점을 개별 인터뷰로 더 깊게 따라갑니다.

참고 링크

관련 글