개인적으로 테크 하잎Hype에 올라타는 것을 꺼리는 성향이다. 누군가는 홍대병이라고 할 수도 있는데, 항상 하잎은 FOMO를 동반하는 편이고 그 FOMO를 조장하여 사람들을 괴롭게 하고 불안감을 주어 단기적 이득을 챙겨가는 사람들을 싫어하기 때문이다.
그러다가 최근에 우연한 기회로 KAIST 전산과에 가서 가벼운 톡을 하나 하게 되었는데, 처음에는 그냥 내가 지금 어떤 식으로 일하는지를 공유하려고 했다. 그런데 준비하는 과정에서 여러 가지 생각들이 정리가 되었고 또 새로운 생각들도 같이 떠올라서 이런 것들을 한 번 글로 써서 공유해도 괜찮지 않을까 하는 생각이 들었다. 하잎에 올라타는 것이 아닌, ‘무엇이 되고 무엇이 안되나’를 정확히 짚어주는 글이, 인기는 없겠지만 필요하지 않을까 하는 생각에 한 번 이 글을 적어내려가 본다.
사람마다 하네스에 대한 정의가 다를 수 있는데, 내가 정의하는 하네스는 이전 글에서 이야기한 소프트웨어 공장의 컴포넌트이다. Claude Code도 하네스고, 임의의 다른 하네스를 호출하는 Ralph Loop도 그 자체로 하네스라고 생각한다. OpenClaw도 특정한 목적과 형태, 그리고 유저 인터페이스를 가진 하네스다. 또한 Claude Code에 적절한 스킬셋을 내장해서 쓰더라도 역시 그 자체로, 제작사가 의도한 대로 커스터마이징한 하네스라고 생각한다. 그러니까 하네스는 다른 하네스를 내장할 수 있으며, 혹은 여러 하네스가 서로 연결되어 묶여진 공정 역시도 하네스라고 나는 정의한다.
같은 제조업 공장이라도 아이스크림 공장과 자동차 공장은 전혀 다른 공정을 가진다. 즉 목적에 따라 적합한 하네스의 형태는 전부 다르다고 생각한다. 나는 이런 측면에서 Claude Code가 나은가, Codex CLI가 나은가 등의 논쟁이 큰 의미가 없다고 생각한다. 저러한 하네스들의 공통점은 그 목적이 구독자 수를 늘리는 데에 있다. 그리고 구독자를 늘리려면 원래 코딩을 하지 않던 사람들이 구독을 하도록 유도해야 한다. 그렇기 때문에 ‘이런 단일 프롬프트로 여기까지 할 수 있습니다’를 잘 구현하고 보여주는 데에 그 설계의 초점이 맞춰져 있다. 그리고 아쉽게도 이러한 초점은 우리가 LLM을 이용해 큰 규모의 중요한 프로젝트를 하려고 하면 약간은 엇나가게 된다.
결국 나는 기본 하네스(Claude Code 등)를 어떻게 사용할 것인가보다는 이를 둘러싼 자신만의 하네스와 환경, 혹은 코드 생산 공정을 어떻게 구축하냐가 중요하다고 생각한다. 개인적으로는 그것을 Meta-harness라고 부르지만 어떻게 부르든 큰 상관은 없다. 중요한 것은 하네스 자체를 1급 객체로 바라보고 이것을 공장의 부품, 혹은 컴포넌트로 바라보는 멘탈 모델이다.
나는 여러 목적에 따라 필요한 맥락과 작동 방식을 다르게 한 하네스들을 만들었는데, 모두 CC를 Wrapping한 하네스 패턴들이다. 대략 다음과 같은 방식에 자동화를 입혔다.
claude -p "$(cat rendered_prompt.md)" 와 같이 위에서 동적으로 생성된 프롬프트를 넣어 알아서 실행하게 만들 때도 있다claude "$(cat rendered_prompt.md)" 와 같이 인터랙티브 세션의 어떤 진입점으로 사용할 때도 있다LLM을 공장의 코어 엔진이라고 본다면 그 코어 엔진이 돌아가는 시점, 즉 LLM이 실제로 코드를 생산하는 시점이 있을 것이다. 그리고 그 시점을 기준으로 코드를 생산하기 이전, 코드를 생산하는 도중, 코드를 생산하는 이후 각각의 타임라인별로 하네스가 해 줄 수 있는, 해 줘야 하는 역할이 다르다고 생각한다.