하네스 엔지니어링은 사이버네틱스다
게시일: 2026년 3월 28일 | 원문 작성일: 2026년 3월 8일 | 저자: George (@odysseus0z) | 원문 보기
핵심 요약
OpenAI의 하네스 엔지니어링 포스트를 읽고 떠오른 생각 — 이건 새로운 게 아니라, 248년 전부터 반복되어 온 패턴이에요.
- 같은 패턴의 세 번째 반복 — 제임스 와트의 원심 조속기, Kubernetes, 그리고 이제 AI 에이전트. 밸브를 직접 돌리는 대신 시스템을 조종하는 쪽으로 역할이 바뀌어요.
- 코드베이스가 마지막 보루였던 이유 — 컴파일러와 테스트는 낮은 수준의 피드백 루프만 닫을 수 있었어요. LLM이 처음으로 아키텍처 수준에서 루프를 닫을 수 있게 됐어요.
- ”에이전트가 이해를 못 해”는 오진 — 에이전트가 실패하는 건 능력 부족이 아니라, “좋은 코드”가 뭔지를 머릿속에만 갖고 있기 때문이에요.
- 무시의 대가가 감당할 수 없는 수준이 됐어요 — 문서화, 테스트, 아키텍처 명문화 — 항상 옳은 관행이었지만, 이제 안 하면 기계 속도로 기술 부채가 쌓여요.
• • •
OpenAI의 하네스 엔지니어링 포스트를 읽으면서 뭔지 모를 익숙한 느낌이 계속 들었어요. 그러다 딱 떠올랐어요. 이 패턴을 전에 본 적이 있었거든요. 한 번도 아니고, 세 번이나.
첫 번째는 1780년대 제임스 와트의 원심 조속기(centrifugal governor)1였어요. 조속기가 나오기 전에는 작업자가 증기기관 옆에 서서 손으로 밸브를 조절했어요. 이후에는 추(錘)가 달린 플라이볼 메커니즘이 회전 속도를 감지하고 자동으로 밸브를 조절했죠. 작업자가 사라진 건 아니에요. 일이 바뀐 거예요 — 밸브를 돌리는 일에서 조속기를 설계하는 일로.
두 번째는 Kubernetes였어요. 원하는 상태를 선언하면 — 레플리카 3개, 이 이미지, 이 리소스 제한 — 컨트롤러가 실제 상태를 지속적으로 관찰해요. 둘이 어긋나면 컨트롤러가 조정하죠: 크래시된 파드를 재시작하고, 레플리카를 스케일링하고, 잘못된 배포를 롤백해요. 엔지니어의 역할이 서비스를 직접 재시작하는 것에서, 시스템이 맞춰갈 spec을 작성하는 것으로 바뀌었어요.
세 번째가 지금이에요. OpenAI가 설명한 엔지니어들은 더 이상 코드를 직접 쓰지 않아요. 대신 환경을 설계하고, 피드백 루프를 구축하고, 아키텍처 제약을 명문화해요 — 그러면 에이전트가 코드를 써요. 5개월 동안 코드 100만 줄, 손으로 작성한 건 0줄. 이걸 “하네스 엔지니어링”이라고 불러요.
매번 같은 패턴이에요. 노버트 위너가 1948년에 이름을 붙였죠: 사이버네틱스(cybernetics)2, 그리스어 κυβερνήτης — 조타수 — 에서 온 말이에요. Kubernetes라는 이름도 같은 어근에서 나왔어요. 밸브를 직접 돌리는 걸 멈추고, 방향을 조종하는 거예요.
이 패턴이 등장하는 건, 누군가가 해당 레이어에서 루프를 닫을 수 있을 만큼 강력한 센서와 액추에이터를 만들었기 때문이에요.
• • •
코드베이스가 마지막 보루였던 이유
코드베이스에도 피드백 루프는 있었어요. 하지만 하위 레벨에서만 작동했죠.
컴파일러는 구문(syntax)에 대한 루프를 닫아요. 테스트 스위트는 동작(behavior)에 대한 루프를 닫아요. 린터는 스타일에 대한 루프를 닫아요. 이것들도 엄연한 사이버네틱 제어예요 — 하지만 기계적으로 확인할 수 있는 속성에서만 작동해요. 컴파일되나? 통과하나? 규칙을 따르나?
그 위의 모든 것 — 이 변경이 시스템 아키텍처에 맞는가? 이게 올바른 접근법인가? 이 추상화가 코드베이스가 커지면서 문제를 일으킬 건가? — 에는 센서도 없고 액추에이터도 없었어요. 품질을 판단하는 것도, 수정을 작성하는 것도 — 그 수준에서는 오직 인간만이 할 수 있었어요.
LLM이 두 가지를 동시에 바꿨어요. 인간의 영역이었던 수준에서 감지할 수 있게 됐고 — 같은 수준에서 행동할 수도 있게 됐어요: 모듈을 재구조화하고, 일관성 없는 인터페이스를 재설계하고, 실제로 중요한 계약(contract)을 중심으로 테스트 스위트를 재작성하는 것까지. 처음으로, 중요한 결정이 이루어지는 곳에서 피드백 루프가 닫힐 수 있게 된 거예요.
하지만 루프를 닫는 건 필요조건이지, 충분조건은 아니에요. 와트의 조속기도 튜닝이 필요했어요. Kubernetes 컨트롤러도 올바른 spec이 필요해요. 그리고 코드베이스에서 작업하는 LLM에는 제공하기 훨씬 더 어려운 무언가가 필요해요.
• • •
센서와 액추에이터 캘리브레이션
기본적인 피드백 루프를 작동시키는 것 — 에이전트가 실행할 수 있는 테스트, 파싱 가능한 출력을 내는 CI, 수정 방향을 알려주는 에러 메시지 — 은 테이블 스테이크(기본 중의 기본)예요.
Carlini3가 이걸 보여줬어요. 16개의 병렬 에이전트로 C 컴파일러를 만들었을 때 — 프롬프트는 놀라울 정도로 단순했지만, 테스트 인프라는 치밀하게 설계했죠.
“내 노력의 대부분은 Claude 주변 환경을 설계하는 데 들어갔어요 — 테스트, 환경, 피드백.” — Nicholas Carlini
더 어려운 문제는 여러분의 시스템에 맞게 센서와 액추에이터를 캘리브레이션하는 거예요. 대부분의 사람들이 여기서 막히고, 에이전트를 탓해요.
“계속 엉뚱한 짓을 해. 우리 코드베이스를 이해 못 하잖아.”
이 진단은 거의 항상 틀려요. 에이전트가 실패하는 건 능력이 부족해서가 아니에요. 에이전트에게 필요한 지식 — 여러분의 시스템에서 “좋은 것”이 뭔지, 아키텍처가 어떤 패턴을 보상하고 어떤 걸 피하는지 — 이 여러분의 머릿속에 갇혀 있고, 외부화하지 않았기 때문이에요.
에이전트는 삼투압으로 배우지 않아요. 적어놓지 않으면, 에이전트는 100번째 실행에서도 첫 번째와 똑같은 실수를 해요.
해야 할 일은 여러분의 판단을 기계가 읽을 수 있게 만드는 것이에요. 실제 레이어링과 의존성 방향을 설명하는 아키텍처 문서. 수정 지침이 내장된 커스텀 린터. 팀의 취향을 담은 핵심 원칙들.
OpenAI가 정확히 이걸 발견했어요. 매주 금요일의 20%를 “AI 슬롭(AI slop)“4 정리에 쓰고 있었는데 — 자신들의 기준을 하네스 자체에 인코딩한 후에야 이 문제가 해결됐어요.
• • •
유일한 전진 방향
이것이 요구하는 실천들 — 문서화, 자동화된 테스트, 아키텍처 결정의 명문화, 빠른 피드백 루프 — 은 원래부터 올바른 것들이었어요. 지난 30년간 쓰인 모든 엔지니어링 서적이 이걸 권장해요. 대부분의 사람들이 건너뛴 이유는, 그 대가가 서서히, 흩어져서 나타났기 때문이에요: 점진적인 품질 하락, 고통스러운 온보딩, 조용히 누적되는 기술 부채.
에이전틱 엔지니어링이 그 비용을 극단적으로 만들었어요.
문서화를 건너뛰면? 에이전트가 여러분의 컨벤션을 무시해요 — PR 하나가 아니라, 모든 PR에서, 기계 속도로, 24시간 내내. 테스트를 건너뛰면? 피드백 루프가 아예 닫히지 않아요. 아키텍처 제약을 건너뛰면? 드리프트가 고칠 수 있는 속도보다 빠르게 누적돼요.
그리고 여기에 함정이 있어요: 에이전트가 “깨끗한 상태”가 뭔지 모르면, 에이전트를 써서 엉망진창을 정리할 수도 없어요. 캘리브레이션 없이는, 문제를 만든 그 기계가 문제를 해결할 수도 없어요.
관행은 바뀌지 않았어요. 무시했을 때의 패널티가 감당할 수 없는 수준이 된 거예요.
생성-검증 비대칭5 — P vs NP의 핵심 직관이자, Cobbe 등이 LLM으로 경험적으로 입증한 것 — 이 앞으로의 방향을 가리켜요. 올바른 솔루션을 생성하는 것은 검증하는 것보다 어려워요. 기계보다 더 잘 구현할 필요는 없어요. 기계보다 더 잘 평가해야 해요: “올바른 것”이 어떤 모습인지 명세하고, 출력이 빗나갈 때 알아차리고, 방향이 맞는지 판단하는 것.
와트의 조속기를 설계한 작업자들은 다시 밸브를 돌리러 돌아가지 않았어요. 능력이 없어서가 아니에요. 더 이상 그럴 이유가 없었으니까요.
역자 주
- 원심 조속기(centrifugal governor): 회전하는 축에 달린 두 개의 금속 추가 원심력으로 벌어지면서 밸브를 자동 조절하는 장치. 증기기관의 속도가 빨라지면 추가 벌어져 증기 유입을 줄이고, 느려지면 추가 모이면서 증기를 더 공급해요. 자동 제어의 상징적 발명품으로, 이후 제어 이론(control theory)의 출발점이 됐어요. ↩
- 사이버네틱스(cybernetics): 미국 수학자 노버트 위너(Norbert Wiener)가 1948년 저서 Cybernetics: Or Control and Communication in the Animal and the Machine에서 제시한 학문. 그리스어 κυβερνήτης(키베르네테스, “조타수”)에서 이름을 따왔는데, 같은 어근에서 영어 governor(“조속기”이자 “통치자”)와 Kubernetes가 나왔어요. 세 단어가 모두 “조종하다”라는 뜻을 공유하는 셈이에요. ↩
- Carlini: Google DeepMind 소속 보안 연구자 Nicholas Carlini. 2025년 초 AI 코딩 에이전트 16개를 병렬로 돌려 C 컴파일러를 구축한 실험으로 화제가 됐어요. 에이전트의 프롬프트보다 테스트 인프라 설계에 훨씬 더 많은 노력을 들인 것이 핵심 교훈이었어요. ↩
- AI 슬롭(AI slop): AI가 생성한 저품질 결과물을 가리키는 속어. 원래 “slop”은 찌꺼기나 잔반을 뜻하는데, AI가 맥락 없이 찍어내는 코드·텍스트·이미지 등에 대한 경멸적 표현으로 쓰여요. ↩
- 생성-검증 비대칭(generation-verification asymmetry): 올바른 답을 처음부터 만들어내는 것(생성)이 주어진 답이 맞는지 확인하는 것(검증)보다 어렵다는 원리. 컴퓨터 과학의 P vs NP 문제의 핵심 직관이에요. Cobbe 등의 2021년 논문 “Training Verifiers to Solve Math Word Problems”는 LLM이 여러 답을 생성한 뒤 별도의 검증 모델이 골라내는 방식이 단일 생성보다 성능이 높다는 걸 보여줬어요. ↩
저자: George (@odysseus0z)
원문: Harness Engineering Is Cybernetics — X/Twitter (2026년 3월 8일)
생성: Claude (Anthropic)