2026.05.13 코드 공장의 구성요소

tl; dr

• 하네스는 소프트웨어 공장의 모든 컴포넌트이다. 하네스는 다른 하네스를 내장하거나 호출할 수 있는 1급 객체로 바라보는 멘탈 모델이 필요하다

• 모두가 처한 환경이 다르기 때문에 모든 사람이 각기 다른 하네스를 각기 다른 방식으로 엮어야 하며, 이것이 소프트웨어 엔지니어에게 요구되는 새로운 능력이다

• 좋은 결과물을 내기 위해서는 코드 생산 시점을 기준으로, 그 전과 후에 필요한 공정이 존재한다. 코드 생산 이전에는 기획과 설계를 아주 자세하게 명확화 하는 것이 필요하고, 코드 생산 이후에는 정적인 검증과 미리 세워둔 기준에 따른 E2E 검증을 하는 것이 중요하다

들어가며

개인적으로 테크 하잎Hype에 올라타는 것을 꺼리는 성향이다. 누군가는 홍대병이라고 할 수도 있는데, 항상 하잎은 FOMO를 동반하는 편이고 그 FOMO를 조장하여 사람들을 괴롭게 하고 불안감을 주어 단기적 이득을 챙겨가는 사람들을 싫어하기 때문이다.

그러다가 최근에 우연한 기회로 KAIST 전산과에 가서 가벼운 톡을 하나 하게 되었는데, 처음에는 그냥 내가 지금 어떤 식으로 일하는지를 공유하려고 했다. 그런데 준비하는 과정에서 여러 가지 생각들이 정리가 되었고 또 새로운 생각들도 같이 떠올라서 이런 것들을 한 번 글로 써서 공유해도 괜찮지 않을까 하는 생각이 들었다. 하잎에 올라타는 것이 아닌, ‘무엇이 되고 무엇이 안되나’를 정확히 짚어주는 글이, 인기는 없겠지만 필요하지 않을까 하는 생각에 한 번 이 글을 적어내려가 본다.

하네스에 관하여

사람마다 하네스에 대한 정의가 다를 수 있는데, 내가 정의하는 하네스는 이전 글에서 이야기한 소프트웨어 공장의 컴포넌트이다. Claude Code도 하네스고, 임의의 다른 하네스를 호출하는 Ralph Loop도 그 자체로 하네스라고 생각한다. OpenClaw도 특정한 목적과 형태, 그리고 유저 인터페이스를 가진 하네스다. 또한 Claude Code에 적절한 스킬셋을 내장해서 쓰더라도 역시 그 자체로, 제작사가 의도한 대로 커스터마이징한 하네스라고 생각한다. 그러니까 하네스는 다른 하네스를 내장할 수 있으며, 혹은 여러 하네스가 서로 연결되어 묶여진 공정 역시도 하네스라고 나는 정의한다.

같은 제조업 공장이라도 아이스크림 공장과 자동차 공장은 전혀 다른 공정을 가진다. 즉 목적에 따라 적합한 하네스의 형태는 전부 다르다고 생각한다. 나는 이런 측면에서 Claude Code가 나은가, Codex CLI가 나은가 등의 논쟁이 큰 의미가 없다고 생각한다. 저러한 하네스들의 공통점은 그 목적이 구독자 수를 늘리는 데에 있다. 그리고 구독자를 늘리려면 원래 코딩을 하지 않던 사람들이 구독을 하도록 유도해야 한다. 그렇기 때문에 ‘이런 단일 프롬프트로 여기까지 할 수 있습니다’를 잘 구현하고 보여주는 데에 그 설계의 초점이 맞춰져 있다. 그리고 아쉽게도 이러한 초점은 우리가 LLM을 이용해 큰 규모의 중요한 프로젝트를 하려고 하면 약간은 엇나가게 된다.

결국 나는 기본 하네스(Claude Code 등)를 어떻게 사용할 것인가보다는 이를 둘러싼 자신만의 하네스와 환경, 혹은 코드 생산 공정을 어떻게 구축하냐가 중요하다고 생각한다. 개인적으로는 그것을 Meta-harness라고 부르지만 어떻게 부르든 큰 상관은 없다. 중요한 것은 하네스 자체를 1급 객체로 바라보고 이것을 공장의 부품, 혹은 컴포넌트로 바라보는 멘탈 모델이다.

코드 생산 전후에 일어나는 일

나는 여러 목적에 따라 필요한 맥락과 작동 방식을 다르게 한 하네스들을 만들었는데, 모두 CC를 Wrapping한 하네스 패턴들이다. 대략 다음과 같은 방식에 자동화를 입혔다.

1. 필요한 일에 따라 충분한 맥락과 지시사항을 담은 프롬프트의 템플릿(handlebar 등의 엔진을 써서)을 만들고, 이를 바탕으로 동적으로 프롬프트를 생성하는 스크립트를 만든다

2. 이 프롬프트를 claude -p "$(cat rendered_prompt.md)" 와 같이 위에서 동적으로 생성된 프롬프트를 넣어 알아서 실행하게 만들 때도 있다

3. 혹은 이 프롬프트를 그냥 claude "$(cat rendered_prompt.md)" 와 같이 인터랙티브 세션의 어떤 진입점으로 사용할 때도 있다

LLM을 공장의 코어 엔진이라고 본다면 그 코어 엔진이 돌아가는 시점, 즉 LLM이 실제로 코드를 생산하는 시점이 있을 것이다. 그리고 그 시점을 기준으로 코드를 생산하기 이전, 코드를 생산하는 도중, 코드를 생산하는 이후 각각의 타임라인별로 하네스가 해 줄 수 있는, 해 줘야 하는 역할이 다르다고 생각한다.

코딩 이전

보통의 소프트웨어 공정에서는 코딩 이전에 기획과 설계가 들어간다. 이것이 확정되지 않은 상태에서 LLM에 의해 생산되는 코드는 거의 대부분 실패한다. 그렇기 때문에 코드를 생산하기 전에 정말 많은 부분을 확정하는 것이 필요한데, 나는 Claude Code(이하 CC라 줄임)의 AskUserQuestion 툴을 적극적으로 활용하게 만든다.

새로운 코드를 생산해야 한다면 가장 먼저 위의 인터랙티브 세션 진입점을 활용한다. 그리고 수많은 토론을 통해 기획의 방향을 잡아나간다. 이런 역할을 하는 하네스에 나는 consult라는 이름을 붙였다....