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

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