이재규 결국엔 AI가 혼자 뭘 추측하게 두지 않았다는 게 핵심입니다.

바이브코딩이 왜 자주 헛도냐면, AI가 인간의 암묵지를 자기 멋대로 추측하거든요. 그때 저 혼자 인터뷰 질문만 115개 정도 문답했던 거 같아요. 좀 오바해서, 이미 만든 seed를 인터뷰에 다시 넣고 한 번 더 문답하고, 또 넣고 문답하고… 모호함을 계속 깎았거든요. 소크라테스식으로 "왜?", "진짜 본질 맞아?", "숨겨둔 가정 있지 않아?" 이런 걸 계속 던지면서, 제 머릿속에만 있던 걸 전부 타이핑으로 내려 받았어요. ambiguity score가 0.2 밑으로 떨어질 때까지요. 그렇게 깎은 seed랑 .env, 딱 이 두 개만 AI한테 넘겼어요. 그 외엔 아무것도 안 줬어요.

근데 명세가 명확해지면 꼭 길어지죠. 문제는 LLM이 이 긴 명세를 다 못 읽는다는 거예요. primacy랑 recency bias 때문에 중간은 그냥 흘려 넘깁니다. 그래서 자연어로 쓰인 명세를 YAML로 crystalize했어요. 문서가 아니라 데이터 구조로 보는 거죠. 그 다음엔 맥킨지식 MECE, AC Tree로 쪼갰고요. 원자 단위가 될 때까지 계속 쪼개면, 각 에이전트는 긴 명세를 이해할 필요가 없어져요. 작고 확실한 태스크 하나만 받거든요.

그래도 남는 문제가 있어요. AI가 아무리 스펙을 잘 읽어도, 결국 그건 플라톤의 동굴 벽에 비친 그림자거든요. 인간의 진짜 골은 이데아고, AI가 붙잡은 온톨로지는 그림자일 뿐이에요. 그래서 한 세대가 끝날 때마다 소크라테스를 다시 부릅니다. Wonder 에이전트가 "우리 뭐 놓쳤지?" 묻고, Reflect가 다음 세대 온톨로지를 제안해요. 결과가 다음 입력이 되고, 세대를 거치면서 그림자가 점점 이데아에 가까워져요. 우로보로스(Ouroboros), 자기 꼬리를 먹는 뱀이라는 이름이 여기서 왔어요.

이 세 층이 합쳐지면 AI의 비결정적 추론이 결정론적 궤도 안에 갇혀요. Seed라는 결정화된 데이터 구조, AC Tree의 분할정복, Ralph 루프의 온톨로지 재정의. 이 셋 덕분에 AI가 추측 대신 인간의 골로 수렴합니다. 7시간에 10만 줄이 나온 건 제가 빨리 친 게 아니라, 추측할 여지가 없는 궤도를 AI가 달렸기 때문이에요.

이번에는 비전문가들을 위한 질문을 좀 드려볼게요. 하네스라는 용어가 일반 대중에겐 아직 생소할 수도 있는데요. AI 시대에 하네스 엔지니어링이 왜 필수적인지 쉽게 설명해 주신다면요?

이재규 하네스라는 게 원래 말한테 채우는 고삐 같은 거예요.

말은 힘이 엄청 세지만, 고삐 없이 풀어놓으면 어디로 갈지 모르잖아요. AI도 똑같아요. LLM이 가진 힘은 엄청나지만, 그냥 "코드 좀 짜줘" 하고 맡기면 AI가 모호한 부분을 스스로 추측하다 보니 발산할 때가 있거든요. 오버엔지니어링을 할 때도 있고요.

이게 왜 그러냐면, LLM은 attention window 안의 문맥을 보고 다음 토큰을 확률적으로 찍어내는 구조거든요. 명세가 또렷하면 다음 토큰의 후보가 좁아져서 엔트로피가 낮아지고, 출력이 수렴합니다. 근데 모호한 자리가 하나라도 있으면, 그 빈자리를 "통계적으로 그럴듯한 것"으로 메워요. 이게 우리가 말하는 환각이고, 발산이고, 오버엔지니어링의 정체예요. AI가 "가장 흔한 답"으로 빈자리를 채우고 있는 거거든요.

그래서 하네스가 필요한 거예요. 하네스는 AI한테 채우는 고삐이자, 달릴 레일이에요. 어디서 출발해서 어디까지 갈지, 도중에 뭘 확인해야 하는지, 실패하면 어디로 돌아와야 하는지 이걸 전부 구조로 만들어 둡니다. 모호한 자리가 남지 않게 미리 깎아둬야 AI가 추측할 필요가 없어지거든요. AI 없던 시절엔 개발자 한 명이 병목이었어요. 지금은 AI 에이전트 열 개를 동시에 돌릴 수도 있죠. 근데 하네스가 없으면 그 열 개가 전부 제각각 튀어나갑니다. 말 열 마리가 수레 하나를 같이 끌려면 고삐가 있어야 하잖아요. 하네스가 있어야 비로소 AI의 양적 폭발이 쓸모 있는 결과물로 수렴해요.

그래서 요즘 바이브코딩 하다 보면 코덱스나 클로드코드 같은 좋은 하네스가 있다 보니 오래 돌긴 하는데, 결국 마음에 안 들 때가 많은 것도 이 때문이고요.

하네스가 요즘 핫한 키워드라 좀 더 질문을 드리고 싶은데요, 그렇다면 하네스 엔지니어링을 구축할 때 가장 중요한 것은 무엇이라고 생각하시나요?

이재규 사람의 암묵지를 어떻게 끄집어내느냐, 그리고 그걸 어떻게 결정론적으로 묶어내느냐 결국 두 가지예요.

요즘 하네스 씬에서 주류는 thin harness, fat skill이에요. 하네스는 얇게, 스킬은 두껍게 가자는 거죠. 모델 IQ가 계속 오르니까 맥락은 스킬에 담고 하네스는 모델에 덜 묶이도록 가볍게 유지하자는 흐름이에요. 합리적이긴 해요. 근데 저는 이 논쟁에 살짝 반대예요. 이 질문들이 대부분 "하나의 모델 × 하나의 스킬"이라는 수직축 안에서만 이뤄지고 있거든요. 실제로 제품을 돌려보면 이 수직축만으로는 안 풀리는 문제가 훨씬 많아요.

하네스의 본질은 결국 비결정적인 모델을 결정적인 실행으로 묶어내는 장치라고 봐요. 모델은 같은 입력을 줘도 매번 다른 출력을 내거든요. 하네스는 그 흔들림을 재현 가능한 실행으로 감싸기 위해 존재합니다. 스킬을 두껍게 가져가는 것도 중요하긴 한데, 그건 context engineering 영역이지 하네스의 존재 이유 자체는 아니에요.

우로보로스(Ouroboros) 안에는 그래서 세 축이 같이 들어가 있어요. 첫째, 모호함 제거. 인간의 암묵지를 Socratic Interview로 뽑아내는 거요. 둘째, 결정론적 실행. ooo run, ooo evaluate, ooo evolve가 Seed를 정해진 궤도 위에서 돌리고 검증하고 진화시킵니다. 셋째, 관측과 재현 가능성. 어떤 세대가 어떤 결정을 했는지 event store에 전부 남고, rewind까지 돼요.

이재규 우로보로스(Ouroboros)도 최근에 한 발 더 나갔어요. 에이전트한테 tool이랑 MCP의 의미를 semantic하게 전달하는 구조에 집중했거든요. 그 결과로 opencode, hermes 같은 다른 하네스들이 Ouroboros 위에 올라오기 시작했어요. Ouroboros가 또 하나의 하네스로 경쟁하는 게 아니라, 여러 하네스가 같은 결정론적 실행 위에 얹힐 수 있는 Agent OS 역할을 하기 시작한 거죠. 운영체제가 프로세스의 비결정성을 관리하고 여러 프로그램을 같은 추상화 위에 공존시키는 것처럼요.

그래서 정리하면, 하네스 구축에서 진짜 중요한 건 하네스의 두께가 아니라 층위예요. 사람의 암묵지를 뽑는 층, 결정론적으로 실행하는 층, 그리고 여러 하네스를 얹을 수 있는 Agent OS 층. 이 세 층을 같이 보는 게 다음 시대 하네스 엔지니어링이라고 저는 봅니다.

강사님의 하네스 철학 중 가장 울림이 큰 문장이 "노트북을 닫고 자도 될 정도로 믿을 수 있는가" 라는 대목이었어요. 단순히 결과물을 내놓는 것을 넘어, 믿을 수 있는 워크플로우를 만든다는 것은 강사님께 구체적으로 어떤 의미인지 듣고 싶습니다.

이재규 이 문장, 사실 제가 랄프톤 2기에서 유일한 한국인 스피커로 나갔을 때 무대에서 직접 한 말이에요. 하네스 엔지니어링의 기준을 한 문장으로 압축하면 저에겐 딱 이거였거든요.

대부분의 사람이 AI한테 일을 시키고 나서 옆에서 계속 지켜봐요. "얘가 잘 하고 있나?", "지금 뭘 하고 있는 거지?", "이거 끝나고 테스트는 도는 거야?" 근데 이러면 AI를 쓰는 게 아니라 그냥 비싼 타자기를 쓰는 거예요. 오히려 감시 비용이 들어서 생산성은 마이너스예요.

그래서 저는 하네스를 만들 때 기준을 하나 세웠어요. "내가 이거 돌려놓고 노트북 덮고 자러 가도, 아침에 일어났을 때 뒷수습 안 해도 되겠는가?" 이 질문에 yes라고 답할 수 없으면 그 하네스는 아직 완성이 아닌 거예요.

이게 되려면 세 개가 필요해요. 첫째, AI가 모호한 자리에서 헛짓을 안 해야 해요. 앞에서 말한 모호함 제거의 문제고요. 둘째, 실패했을 때 AI가 스스로 알아채야 해요. Ralph 루프가 검증 통과할 때까지 절대 멈추지 않는 이유가 이거예요. 셋째, 아침에 일어나서 제가 뭘 돌아봐야 하는지 추적 가능해야 해요. 어떤 세대가 어떤 결정을 했고, 왜 실패했고, 어디서 수렴했는지 event store에 전부 남아 있어야 하고, rewind로 과거 지점으로 되돌릴 수도 있어야 해요.

이 셋이 갖춰지면 비로소 AI한테 일을 "맡긴다"는 말이 성립해요. 그전까진 그냥 "감시한다"에 가깝거든요. 감시는 사람의 집중력을 갉아먹고 결국 생산성을 죽여요. 믿을 수 있는 워크플로우라는 건, 결국 사람이 AI 옆에 안 붙어 있어도 되는 상태를 구조로 만들어둔 것이에요.

우로보로스(Ouroboros)는 저 문장 하나를 향해 계속 업데이트하고 릴리즈하고 있어요. 1.0.0이 되는 날, 정말 노트북 닫고 자도 되는 하네스를 내놓고 싶거든요. 아직 갈 길이 멀지만, 지금도 매 버전이 그 방향으로 한 걸음씩 가고 있어요.

하네스라는 개념이 강력한 만큼, '내가 과연 따라갈 수 있을까?' 주저하는 분들도 계실 텐데요. 아직 신입이거나 이제 막 바이브코딩을 시작한 사람도 이 강의를 소화할 수 있을까요?

이재규 바이브코딩 오래 한 사람들 보면, 다들 "일단 프롬프트 던져보고 나온 걸 고치는" 루틴이 몸에 배어 있어요. 이걸 깨는 데 시간이 꽤 걸립니다. 근데 이제 막 시작한 분들은 그게 아직 없잖아요. 처음부터 "스펙 먼저, 실행은 그 다음"이라는 순서로 몸을 만들면 훨씬 빠르게 본질로 가요. 커리큘럼도 그 흐름으로 짰어요. 처음부터 Ouroboros 뜯어보라고 안 해요. 작은 하네스 하나부터 같이 만듭니다. 왜 이 구조가 필요했는지, 어떤 문제를 푸는 건지를 한 단계씩 보여드리고요. 16개 실습이 있는데, 각 실습이 "아 이 정도는 되네?" 하는 작은 성공을 만들어주는 단위예요. 그게 쌓이다 보면 어느새 네 개의 시스템을 스스로 빌드하고 있더라고요.

신입 분들한테는 따로 덧붙이고 싶은 게 있어요. 지금이 진짜 타이밍이에요. 시니어들이 자기 손코딩 습관 때문에 AI 전환을 버거워할 때, 신입은 처음부터 AI 네이티브로 일을 배우는 거거든요. 한 2~3년 뒤에 이 차이 엄청나게 벌어질 거예요. 개발에 원래 관심이 있고, 코드를 한 줄도 모르는 정도가 아니라면 괜찮아요. 같이 열심히 하네스 만들어봐요.

개인적으로 이번 강의 커리큘럼을 보고 놀라움을 느꼈는데요. 단순히 이론만 읊는 것이 아니라, 대표 하네스 구조를 뜯어보고, 16개의 실습을 거쳐 최종적으로 4개의 완성된 시스템을 수강생이 직접 빌드하는 과정이더라고요. 이렇게까지 '프로덕션 레벨의 실전 프로젝트'에 집중하신 특별한 이유가 있을까요?