코딩 에이전트가 화면을 버렸습니다

Jina AI 창업자 한 샤오가 자기 pi 사용법을 공개했습니다. 6시간 넘는 장기 과제에 pi를 훨씬 많이 쓰고, pi TUI는 거의 안 쓴다고요. 대신 더 큰 시스템과 컨테이너, 자체 UI 안에 pi를 심어서 돌린다고 적었습니다.

이 트윗은 조회 12,069에 북마크 214를 받았어요. 조회 규모에 비해 북마크가 많이 붙었죠. 스쳐 읽는 글이 아니라 저장해 두고 따라 하려는 글이라는 뜻이에요. 발표도, 홍보도 아니고 그저 자기 작업 방식을 적은 글이 이렇게 저장되는 경우는 드물어요.

창업자가 밝힌 이유는 한 줄입니다. "설계가 단순해서 프로그래매틱하게 다루기 쉽다." 이 한 줄을 풀면, 코딩 에이전트라는 물건이 지금 어디로 가는지 보입니다.

TUI를 버리면 무엇이 남을까요?

pi는 터미널에서 쓰는 코딩 에이전트예요. 화면을 띄우고, 명령을 넣고, 응답을 읽는 앱이죠. 대부분은 그 화면을 쓰려고 에이전트를 깔아요. 한 샤오는 그 화면을 거의 안 씁니다. 앱을 앱답게 만드는 부분을 통째로 건너뛰는 사용법이죠.

화면을 걷어내면 남는 건 루프입니다. 모델을 부르고, 도구를 실행하고, 결과를 다시 모델에 넣는 순환 구조요. 이 루프는 사람이 지켜보지 않아도 돕니다. 그래서 컨테이너에 넣을 수 있고, 더 큰 시스템 한 칸에 끼울 수 있고, 그 위에 자체 UI를 씌울 수도 있어요.

한 샤오가 말한 사용법이 정확히 이겁니다. pi를 앱으로 띄우는 게 아니라, 자기 시스템 안에 엔진으로 심는 것. 앱은 사람이 씁니다. 엔진은 시스템이 쓰죠. 브라우저와 브라우저 엔진 관계를 떠올리면 가깝습니다. 사람은 브라우저를 쓰지만, 수많은 제품은 그 안쪽 엔진만 떼어다 쓰거든요.

프로그래매틱하게 다룬다는 말을 풀면 이런 그림입니다. 스크립트가 에이전트를 띄우고, 과제를 넣고, 산출물을 받아서 다음 단계로 넘깁니다. 실패하면 다시 띄우고, 필요하면 여러 개를 나란히 굴려요. 사람은 그 위에 올라앉은 자기 UI에서 결과만 확인합니다. 조작 대상이 화면이 아니라 코드라서 가능한 운용이에요.

왜 6시간 넘는 과제일수록 pi일까요?

증언에서 눈에 걸리는 대목은 시간입니다. 6시간 넘는 장기 과제에 pi를 "훨씬 많이" 쓴다고 했어요.

장기 과제는 사람이 화면 앞을 지키는 방식과 상극입니다. 여섯 시간짜리 작업을 터미널 앞에 앉아 지켜볼 사람은 없어요. 결국 장기 과제는 사람 없이 도는 구조를 요구합니다. 앞 절에서 본 바로 그 운용이요.

여기서 단순한 설계가 무기가 됩니다. 구조가 단순하면 바깥 코드가 잡을 지점이 분명해요. 어디서 시작하고 어디서 끝나는지, 무엇을 넣으면 무엇이 나오는지 예측이 섭니다. 반대로 기능이 많고 상태가 복잡한 앱은 사람 손에는 편해도 코드 손에는 미끄럽습니다. 숨은 상태가 많을수록, 감싸는 코드는 그 상태를 전부 흉내 내야 하거든요.

장기 과제는 실패도 깁니다. 다섯 시간째에 죽은 작업을 사람이 처음부터 다시 지켜볼 수는 없어요. 감싸는 코드가 단순한 물건은 죽은 지점에서 다시 띄우는 것도 코드 몇 줄 문제가 됩니다. 시간이 길어질수록 단순함이 내는 이자가 커지는 구조예요.

단순함이 취향 문제가 아니라는 얘기입니다. 단순함은 인터페이스예요. 단순해야 코드가 붙잡을 수 있습니다.

에어갭에서 미니멀 툴셋은 어떻게 살아남을까요?

증언 마지막 대목이 제일 셉니다. 미니멀 툴셋만으로 에어갭 과제에 충분하다고 했어요.

에어갭은 외부망이 끊긴 환경이에요. 플러그인 마켓도, 외부 API도, 원격 도구 서버도 없죠. 망 밖으로 한 발짝도 못 나가는 곳에서도 일은 돌아가야 하는 현장이 있어요. 이런 환경에서는 도구를 쌓아 올린 에이전트일수록 무너질 곳이 많아요. 연결 하나하나가 전부 단절 지점이거든요. 밖에 기대는 게 적을수록, 망을 끊어도 잃는 게 적죠.

도구가 적으면 끊길 것도 적습니다. 미니멀 툴셋은 폐쇄망에 그대로 들고 들어가도 돌아간다는 증언이에요. 덜어낸 설계가 제약이 아니라 생존 조건이 되는 장면입니다.

이 증언은 어느 흐름 위에 놓일까요?

이 계정이 추적해온 미니멀 하네스 축과 정확히 겹칩니다.

허깅페이스 tau는 README 첫 줄에 "inspired by Pi"를 적고 나왔습니다. 버셀 fx는 아예 7.8메가바이트짜리 바이너리 하나로 같은 방향을 밀었죠. 학계 실측 논문에서는 pi가 과제당 중간값 1만 4천 토큰으로, 26만 토큰을 태우는 에이전트와 같은 과제를 완주했어요. Yuj 실험은 하네스 배선 두 가닥만 바꿔 같은 모델에서 과제 29개를 더 풀었고요.

따로 보면 흩어진 뉴스입니다. 겹쳐 보면 한 문장이에요. 하네스는 작을수록 셉니다. 작아야 토큰이 덜 들고, 작아야 옮겨 심기 쉽고, 작아야 폐쇄망에서도 돌아요.

지금까지는 레포와 논문이 말했습니다. 이번엔 창업자가 실전 사용법으로 말했어요. 미니멀 하네스가 벤치마크용 장난감이 아니라, 6시간짜리 실무를 도는 부품이라는 증언입니다.

방향이 같은 증언이 서로 다른 자리에서 나오는 게 요점이에요. 레포는 설계로, 논문은 숫자로, 창업자는 운용으로 같은 결론을 가리킵니다. 한 축을 세 방향에서 때려도 같은 소리가 나면, 그건 유행이 아니라 구조죠.

그래서 하네스는 무엇이 될까요?

저는 이 트윗을 하네스 시장이 갈라지는 신호로 읽습니다.

한쪽은 앱으로 갑니다. 화면을 다듬고, 기능을 쌓고, 사람 손에 맞춥니다. 다른 쪽은 부품으로 갑니다. 화면을 버리고, 기능을 덜어내고, 코드 손에 맞춰요.

창업자급 사용자가 두 번째 길을 골랐습니다. 그것도 제일 무거운 과제, 제일 험한 환경에서요.

앱은 쓰는 사람 수만큼 팔립니다. 부품은 그 위에 세워지는 시스템 수만큼 퍼지죠. 지금 코딩 에이전트 경쟁은 전부 앱 화면에서 벌어지는 것처럼 보입니다. 그런데 정작 무거운 실무는 화면 밖에서, 컨테이너 안에서 돌기 시작했어요.

저는 코딩 에이전트 다음 판이 화면이 아니라 부품 자리에서 갈린다고 봅니다. 단순함이 곧 프로그래머빌리티고, 프로그래머빌리티가 곧 부품 자격이에요. 이 트윗은 그 판이 이미 열렸다는 창업자 쪽 답안지입니다.

---

원문·소스

• 한 샤오 pi 사용기 트윗 (@hxiao): https://x.com/hxiao/status/2094519020531994639