로지컬랩스

AI가 쓴 문서를 다른 AI에게 점검시켰더니 없는 판례가 나왔습니다

logicallabs — Fri, 21 Aug 2026 16:08:19 +0900

지난 화에서 걸러냈다고만 적은 것

지난 화 마지막에 저는 이렇게 적었습니다. 그때는 변호사 없이도 내가 할 수 있겠다는 자신도 생겼습니다.

같은 화 끝에 한 가지를 남겨뒀습니다. AI가 만들어 준 초안 안에, 실제로는 있지도 않은 것이 섞여 있었다는 이야기였습니다. 그건 보내기 전에 걸러냈다고만 적고 넘어갔습니다.

그 있지도 않은 것은 판례였습니다. AI가 만들어 낸, 세상에 없는 판례였습니다.

이번 화는 그 문서를 만드는 동안 있었던 일입니다.

AI가 쓴 문서를 다른 AI에게 점검시켰습니다

당시 제가 문서를 만들던 방식은 이랬습니다.

먼저 AI에게 문서를 쓰라고 시킵니다. 그렇게 나온 문서를 챗GPT와 제미나이에 각각 넣고, 이 문서를 점검해 보라고 시킵니다.

한 곳에서 나온 결과를 그대로 쓰지 않고 다른 두 곳에 다시 읽혔습니다.

이 순서는 그 문서 하나에만 쓴 방법은 아니었습니다. 그 무렵 문서를 만들 때는 대체로 이렇게 했습니다.

특별한 도구가 필요하지도 않습니다. 문서를 그대로 옮겨 붙이고 점검해 보라고 시키면 됩니다.

"이 판례는 존재하지 않습니다"

돌아온 대답은 에두르지 않았습니다.

이 판례는 존재하지 않는다고 했습니다.

확인이 필요해 보인다거나 출처가 불분명하다는 식의 말이 아니었습니다. 그런 판례 자체가 없다는 지적이었습니다. 두 곳 다 같은 말을 했습니다.

법률 문서에는 판례가 자주 들어갑니다. 같은 쟁점을 법원이 어떻게 판단해 왔는지 보여주는 자료라서 그렇습니다.

그래서 판례는 실제로 있는 것이어야 하고, 있는지 없는지는 찾아보면 바로 드러납니다. 판례가 실제로 있는지는 국가법령정보센터나 대법원 판결서 열람 서비스 같은 공개된 곳에서 확인할 수 있습니다. 다만 모든 판결문이 공개되는 것은 아닙니다.

환각이라는 말을 문서에서 만났습니다

AI가 없는 사실을 있는 것처럼 만들어내는 현상을 환각이라고 부릅니다. 영어로는 할루시네이션이라고 합니다.

AI는 그럴듯한 다음 말을 이어 붙이는 방식으로 문장을 만듭니다. 그래서 실제로 있는 자료와 그럴듯하게 생긴 가짜 자료를 문장 안에서 똑같이 매끄럽게 씁니다.

용어 자체는 AI를 다루는 글에서 어렵지 않게 볼 수 있습니다. 존재하지 않는 논문이나 판례를 지어낸다는 설명도 대개 함께 붙어 다닙니다.

그 설명을 제 문서 안에서 확인한 셈이었습니다.

어떤 판례였는지는 기억나지 않습니다

여기서 솔직히 적어둘 것이 있습니다.

그게 어떤 판례였는지 저는 지금 기억하지 못합니다. 무슨 사건이었는지도, 어떤 내용으로 적혀 있었는지도 남아 있지 않습니다.

기억나지 않는 자리를 그럴듯한 문장으로 채워 넣으면, 이 글도 그때 그 초안과 같아집니다. 그래서 기억나지 않는다고 적습니다.

분명한 것은 하나 있습니다. 그 판례는 보내기 전에 문서에서 빼냈습니다. 실제로 보낸 문서에는 들어가지 않았습니다.

남아 있는 것은 그때 제가 한 생각뿐입니다.

아 이게 환각이구나

그 지적을 읽고 든 생각은 두 개였습니다.

하나는 "아 이게 환각이구나"였습니다.

다른 하나는 "이걸 어떻게 풀지"였습니다.

두 번째 생각에서 다음 이야기가 시작됩니다. 그 이야기는 다음 화에서 하겠습니다.

밝혀둘 점: 이 글은 필자 본인이 직접 겪은 경험을 기록한 것이며, 특정 사건에 대한 법률 자문이나 대리가 아닙니다. 환각과 판례 확인에 관한 서술은 일반적인 설명입니다. 진행 중인 분쟁의 상대·기관·내용은 담지 않았습니다. 개별 사안은 사정에 따라 결론이 크게 달라지므로, 비슷한 상황이라면 변호사 등 전문가의 조력을 받으시기 바랍니다. 본문의 서술은 특정 시점의 개별 경험이며, 언급한 서비스의 현재 성능에 대한 평가가 아닙니다. 본문에 언급한 외부 서비스는 필자가 이용자로서 사용한 것이며, 어떤 대가나 제휴 관계도 없습니다.

대화 기억과 AI 환각을 한 흐름으로 묶어 특허를 출원했습니다

logicallabs — Wed, 19 Aug 2026 17:53:10 +0900

AI와 여러 번 주고받는 대화를 하다 보면, 앞에서 분명히 말해 둔 내용을 AI가 붙들지 못하는 순간이 옵니다.

문제는 거기서 끝나지 않습니다. 기억이 비었다고 말하는 대신, 빈자리를 그럴듯한 내용으로 채워서 대답합니다.

저는 이 둘을 따로 떨어진 문제로 보지 않았습니다. 제대로 기억하지 못한 상태 위에서 추론을 하니까 없는 얘기가 나온다고 봤습니다.

그래서 특허를 하나 출원했습니다. 대화 기억을 관리하는 일과 없는 얘기를 걸러내는 일을 한 줄기로 묶은 설계입니다.

2026년 3월에 출원해 7월에 공개됐고, 아직 등록 전입니다.

오늘은 그 설계가 어떻게 생겼는지 쉬운 말로 적어 두려 합니다.

기억을 관리하는 기술과 환각을 막는 기술은 따로 자랐습니다

용어를 하나 풀어 두겠습니다. 환각은 AI가 사실이 아닌 내용을 사실인 양 말하는 현상을 가리킵니다.

이 글에서 다루는 것은 그중 대화 기억에서 비롯된 환각입니다.

AI가 대화를 오래 이어가지 못하는 이유는 한 번에 볼 수 있는 글의 양에 한계가 있기 때문입니다. 그래서 앞부분의 대화는 시야 밖으로 밀려납니다.

이 한계를 풀려고 대화 내용을 바깥 저장소에 담아 두는 기술이 발전해 왔습니다. 널리 쓰이는 오픈소스 메모리 시스템들이 그 계열입니다.

한편 환각을 줄이려는 기술은 별도의 줄기로 자랐습니다. 모델이 자기 답에 대해 검증 질문을 스스로 만들어 되짚어 보는 방식이나, 미리 준비된 문서를 참조해 사실을 맞춰 보는 방식이 여기 속합니다.

두 줄기는 각자 잘 자랐는데, 제가 출원을 준비하며 살펴본 범위에서는 서로 이어지지 않았습니다. 기억을 쌓는 쪽은 쌓아 둔 기억이 정확한지를 따로 검증하지 않았고, 환각을 막는 쪽은 그 대화에서 실제로 오간 말을 검증의 기준으로 삼지 않았습니다.

제가 명세서에 적은 문제의식이 이 지점입니다. 저장에서 검증까지를 하나의 처리 흐름으로 잇는 기술이 비어 있었습니다.

그래서 다섯 단계로 나눴습니다

단계	하는 일
1. 가르기	사용자가 방금 한 말이 묻는 말인지 알려주는 말인지 판별하고, 그 말의 주제를 뽑습니다
2. 꼬리표	기억을 저장할 때, 그 말을 누가 했는지와 무슨 주제인지를 함께 붙입니다
3. 생애주기	기억을 만들고, 고치고, 지우고, 되살리는 네 가지 상태로 관리합니다
4. 쪼개서 찾기	질문을 갈래별로 나눠 각각 따로 찾은 뒤, 결과를 비율대로 합칩니다
5. 대조	답을 내보내기 전에 원래 기억과 다시 맞춰 봅니다

첫째, 묻는 말과 알려주는 말을 먼저 가릅니다.

같은 사람이 한 말이라도 "내 이메일 주소가 바뀌었어"와 "내 이메일 주소 뭐였지"는 시스템이 해야 할 일이 정반대입니다. 앞의 말은 저장해야 하고, 뒤의 말은 찾아와야 합니다.

그래서 이 출원은 대화가 한 차례 오갈 때마다 사용자의 말을 두 갈래로 먼저 나누고, 나뉜 결과를 뒤 단계가 이어받습니다. 이때 그 말의 주제도 함께 뽑아 둡니다. 뽑아 둔 주제는 다음 단계에서 꼬리표로 쓰입니다.

둘째, 저장할 때 누가 한 말인지를 함께 답니다.

내용만 담지 않고, 그 내용이 누구 입에서 나왔는지를 표식으로 붙입니다. 사용자가 한 말인지, AI가 스스로 만들어 낸 말인지를 구분하는 표식입니다.

이 표식이 있어야 나중에 "사용자님께서 A라고 하셨습니다"라는 답이 나왔을 때, 정말 사용자가 한 말인지 확인할 수 있습니다. 표식이 없으면 AI가 한 번 지어낸 말이 기억 속에서 사실과 같은 무게를 얻게 됩니다. 한 번 그렇게 굳으면 다음 대화에서는 그게 전제가 됩니다.

셋째, 기억에도 생애주기를 둡니다.

기억은 한 번 적고 끝나지 않습니다. 사용자가 이사했다고 하면 예전 주소 기억은 고쳐져야 하고, 앞서 한 말을 거둬들이면 지워져야 하고, 나중에 다시 언급되면 되살아나야 합니다.

이 출원은 그 네 가지를 상태로 정의하고, 상태가 바뀔 때마다 바뀌기 직전의 내용을 사본으로 남깁니다. 그리고 바뀐 정도가 정해 둔 기준선을 넘으면, 그 기억에 기대어 이미 내보냈던 답까지 다시 검토하도록 신호를 보냅니다.

변화가 사소하면 그냥 넘어갑니다. 모든 변경마다 지난 답을 되돌아보면 계산이 너무 무거워지기 때문입니다.

넷째, 질문을 쪼개서 갈래별로 찾습니다.

"지난번에 말한 그 식당 이름이랑 예약 가능한 시간 알려줘" 같은 질문은 사실 두 개의 질문입니다. 이걸 한 덩어리로 던지면 검색 결과가 한쪽 주제로 쏠립니다.

그래서 질문을 갈래로 나눠 각각 따로 찾습니다. 찾는 방식은 글자가 같은 것을 고르는 게 아니라 뜻이 가까운 기억을 골라 오는 방식입니다. 그리고 갈래마다 나온 결과의 개수에 비례해 가중치를 매기고, 그 가중치대로 점수를 합쳐 최종 순위를 냅니다.

다섯째, 답을 내보내기 전에 원본과 대조합니다.

마지막 단계는 관문입니다. AI가 만든 답에서 과거 대화를 인용한 부분을 골라내고, 저장소의 원본 기억과 맞춰 봅니다. 이때 내용만 보지 않고 둘째 단계에서 붙인 꼬리표까지 함께 봅니다.

명세서에는 판정을 셋으로 나눈 예를 들어 두었습니다. 내용과 꼬리표가 모두 맞으면 그대로 두고, 세부만 어긋나면 원본대로 바로잡고, 대응하는 기억이 아예 없거나 누가 한 말인지가 어긋나면 그 부분을 빼거나 다시 만들게 합니다.

다시 만들기를 요청하는 횟수에는 상한을 둘 수 있게 해 두었습니다. 무한정 되풀이하지 않기 위해서입니다.

명세서에서는 이렇게 걸러지는 대화 기억 환각을 네 가지로 나눠 두었습니다.

유형	어떤 상황인가
허위 인용	존재하지 않는 대화를 인용함
왜곡 인용	실제 오간 내용을 변형해 인용함
갱신 실패	이미 고쳐진 기억의 옛 버전을 인용함
과잉 추론	기억에 없는 내용을 추론해 놓고 기억인 양 제시함

명세서에는 이 다섯 단계를 외부로 보내지 않고 사용자 쪽 기기 안에서 그대로 돌리는 구성도 함께 적어 두었습니다. 여기서 기기는 스마트폰이나 태블릿뿐 아니라 임베디드 보드, 네트워크가 제한된 로컬 서버까지 포함합니다. 대화가 바깥으로 나가지 않는 환경을 염두에 둔 구성입니다.

기존 방식과 다른 지점 두 가지

먼저 밝혀 둘 것이 있습니다. 어느 쪽이 더 낫다는 이야기가 아니라, 목적이 다른 설계라는 뜻입니다.

하나, 누구 말인지를 저장 단계에서 구분합니다.

널리 쓰이는 오픈소스 메모리 시스템(Mem0)은 대화에서 정보를 뽑아 넣고 고치고 지우는 데 초점이 있습니다. 발화의 역할을 구분하는 기능 자체는 다룹니다. 다만 각 기억 항목의 출처를, 뒤에서 답을 검증할 때 쓸 근거로 계속 추적하지는 않습니다.

이 판단은 2026년 3월 출원 당시 제가 명세서 배경기술에 적어 둔 것이고, 그 뒤로 각 프로젝트의 기능은 계속 바뀌고 있습니다.

이 출원은 저장하는 그 순간에 꼬리표를 답니다. 뒤에서 대조하려면 앞에서 표식이 있어야 하기 때문입니다.

둘, 검증의 기준을 그 대화 자체에 둡니다.

환각을 줄이는 기법 가운데는 모델이 검증 질문을 스스로 만들어 자기 답을 되짚는 방식(Chain-of-Verification)이 있고, 미리 마련해 둔 문서와 맞춰 보는 방식도 있습니다. 제가 확인한 범위에서 이 계열의 기법들은 "이 대화에서 실제로 오간 말"을 대조의 기준으로 삼지는 않습니다.

이것 역시 2026년 3월 출원 당시 제가 명세서 배경기술에 종래 기술로 적어 둔 내용입니다.

이 출원은 저장해 둔 원본 기억을 기준으로 삼습니다. 어느 쪽이 낫다는 이야기가 아니라 목적이 다른 설계입니다.

제가 이 설계를 택한 이유

여기가 이 글에서 가장 개인적인 대목입니다.

출원 계기는 거창하지 않습니다. 제가 AI와 일하면서 계속 겪던 일이 그대로 출발점이었습니다.

지금도 AI는 제가 얘기한 것들을 기억하지 못합니다. 그래서 만들게 됐습니다.

했던 얘기를 제대로 기억하지 못하고, 그걸 토대로 없는 얘기를 지어내고 있었으니까요.

이 두 문장이 설계의 전부입니다.

이 글을 준비하는 동안에도 같은 일이 있었습니다. 전날 AI와 이야기하며 다른 글의 소재를 정리해 뒀는데, 다음 날 이어서 작업하려니 AI가 그 대화를 기억하지 못했습니다. 남아 있는 것은 그때 적어 둔 기록뿐이었습니다.

AI는 그 기록만 보고, 글 안의 몇 대목을 제가 하지 않은 말이라고 판정해 지우려 했습니다. 제가 그거 나랑 얘기하면서 작성한 건데, 하고 짚고 나서야 확인이 됐습니다.

실제로 제가 겪고 말한 내용이었고, 기록에만 남지 않았을 뿐입니다. 그대로 뒀으면 사실인 서술 네 대목이 지워질 뻔했습니다.

기록이 있었는데도, 그 기록에 없는 것은 없던 일이 됐습니다.

그래서 기억 관리와 환각 방지를 따로 두지 않았습니다. 순서를 붙여 하나로 이었습니다. 앞 단계에서 무엇을 어떻게 저장했느냐가, 마지막 단계에서 무엇을 대조할 수 있느냐를 결정하기 때문입니다.

꼬리표를 붙이는 둘째 단계가 없으면, 맞춰 볼 기준이 없어 다섯째 단계의 대조가 헐거워집니다. 반대로 대조하는 단계가 없으면, 잘 정리해 둔 기억이 답에 제대로 반영됐는지 아무도 확인하지 않습니다.

제가 겪은 것은 기억이 새는 문제였고, 동시에 없는 말을 지어내는 문제였습니다. 저는 이걸 원인 하나에서 나온 증상 둘로 봤습니다. 그래서 처방도 한 벌이어야 한다고 판단했습니다.

지금 어디까지 왔는지도 적어 두겠습니다

솔직하게 쓰겠습니다.

위의 다섯 단계는 로지컬랩스 백엔드에 실제로 구현돼 있고, 동작을 확인하는 테스트도 붙어 있습니다. 여기까지는 왔습니다.

다만 아직 사용자가 쓰는 서비스 경로에는 연결하지 않았습니다. 운영에 붙이는 일은 다음 과제로 남아 있습니다.

명세서에 적어 둔 효과를 정량으로 검증하는 실험은 아직 진행 전입니다. 그래서 이 글에도 숫자는 한 개도 넣지 않았습니다. 숫자를 말할 수 있게 되면 그때 다시 적겠습니다.

설계를 마치고 분명해진 것 하나만 남겨 둡니다. 무엇을 어떻게 저장해 두느냐가, 나중에 무엇을 검증할 수 있는지를 미리 정해 버린다는 점입니다.

덧붙임. 이 글에서 언급한 외부 프로젝트와 기법에 관한 서술은, 2026년 3월 출원 당시 명세서 배경기술에 적어 둔 내용과 그때 확인한 공개 자료를 기준으로 한 것입니다. 각 프로젝트의 기능은 그 뒤로 계속 바뀌고 있습니다. 어느 쪽이 더 낫다는 이야기가 아니라, 목적이 다른 설계라는 뜻으로 적었습니다. 이 글에서 다룬 발명은 2026년 3월에 출원해 7월에 공개된 것으로, 이 글을 쓰는 시점에 아직 등록 전입니다.

AI에게 법률 문서를 처음 맡겼을 때 벌어진 일

logicallabs — Wed, 19 Aug 2026 17:30:25 +0900

문서는 결국 제가 써야 했습니다

지난 화에서 저는 변호사 없이 혼자 가보기로 했다고 적었습니다.

그 결심에는 당연한 뒷일이 딸려 있었습니다. 대리인을 두지 않기로 한 이상, 상대에게 보낼 문서도 제가 써야 했습니다.

머리로는 알고 있었습니다. 그런데 막상 빈 화면을 열어놓고 앉으니 첫 문장이 나오지 않았습니다.

난생처음 써 보는 문서였습니다

제가 AI에게 처음 맡긴 법률 문서는 상대측 대리인에게 보낼 내용증명이었습니다.

내용증명은 어떤 내용의 문서를 언제 발송했는지를 우체국이 증명해주는 제도입니다. 등기로 나가기 때문에 상대가 언제 받았는지는 배송조회로 확인할 수 있습니다.

다만 적어 보낸 내용이 진실이라는 것까지 증명해주지는 않습니다. 제도 설명 자체는 검색하면 금방 나옵니다.

문제는 그 안에 무슨 말을 어떤 순서로 담느냐였습니다.

게다가 내용증명은 한 번 보내면 그대로 남습니다. 내가 어떤 주장을 했는지가 기록으로 고정된다는 뜻입니다.

가볍게 쓸 수 있는 문서가 아니었습니다. 저는 이 종류의 문서를 그날 처음 써 보는 비전문가였습니다.

AI가 처음 뱉은 초안은 엉뚱했습니다

그래서 AI에게 시켰습니다. 상황을 설명하고, 이런 문서를 써 달라고 했습니다.

돌아온 초안은 엉뚱했습니다.

형식은 그럴듯했습니다. 문장도 매끄러웠습니다. 그런데 제가 하려던 이야기가 아니었습니다.

제 사정에서 가장 중요한 대목은 한 줄로 스쳐 지나갔고, 크게 중요하지 않은 부분이 길게 늘어나 있었습니다.

읽으면서 든 생각은 하나였습니다. "이건 내 문서가 아닌데."

몇 번인지 세지 않았을 만큼 되돌렸습니다

거기서부터 되돌리기가 시작됐습니다.

여기는 이렇게 가야 한다고 말하면 그쪽으로 문서가 다시 나왔습니다. 읽어보면 또 다른 데가 어긋나 있었습니다. 고치라고 하면 고쳐졌고, 고쳐진 걸 읽으면 앞에서 맞던 대목이 흐트러져 있었습니다.

그 왕복을 몇 번 했는지는 세지 않았습니다. 세어볼 생각도 못 할 만큼 되돌렸다는 것만 기억합니다.

방향은 제가 쥐고 있었습니다

그 반복 속에서 한 가지는 분명했습니다.

방향을 정한 쪽은 저였습니다. AI가 먼저 "이렇게 가시죠"라며 길을 제시한 적은 없었습니다.

제가 계속 지적하고, 아니라고 말하고, 이쪽이라고 짚어주는 동안 문서가 조금씩 제자리를 찾아갔습니다.

AI가 잘한 것은 문장이었습니다. 제가 어렴풋이 붙들고 있던 방향을 문서의 언어로 옮겨주는 일은 분명히 빨랐습니다. 제가 한 일은 그 방향을 고집하는 쪽이었습니다.

그 시기의 작업은 그런 형태로 굴러갔습니다.

그렇게 나온 문서를 보냈습니다

보내기 전에 처음부터 끝까지 다시 읽었습니다. 문장 하나하나를 제 판단으로 확정한 뒤에 보냈습니다.

완성된 문서는 실제로 보냈습니다. 봉투에 넣어 우체국 창구에 낸 것이 아니라, 인터넷으로 접수하는 내용증명이었습니다.

보내고 나니 뿌듯했습니다.

그때는 변호사 없이도 내가 할 수 있겠다는 자신도 생겼습니다.

다만, 그 안에는

여기까지가 그날의 이야기입니다.

그런데 AI가 만들어 준 초안 안에는, 실제로는 있지도 않은 것이 섞여 있었습니다.

그건 보내기 전에 걸러냈습니다.

그 이야기는 다음 화에서 하겠습니다.

밝혀둘 점: 이 글은 필자 본인이 직접 겪은 경험을 기록한 것이며, 특정 사건에 대한 법률 자문이나 대리가 아닙니다. 내용증명에 관한 서술은 일반적인 제도 설명입니다. 진행 중인 분쟁의 상대·기관·내용은 담지 않았습니다. 개별 사안은 사정에 따라 결론이 크게 달라지므로, 비슷한 상황이라면 변호사 등 전문가의 조력을 받으시기 바랍니다.

여러 AI 세션을 굴리면 '미해결 장부'가 필요해집니다

logicallabs — Tue, 18 Aug 2026 18:40:15 +0900

AI 세션을 여러 개 띄워 놓고 일하면, 각 세션은 자기 앞의 일만 봅니다.

그래서 사고는 대개 세션 안이 아니라 세션과 세션 사이에서 납니다. 앞 세션이 무엇을 결정했는지, 무엇을 하다 말았는지 뒤 세션은 알지 못합니다.

저는 그 틈에 떨어지는 것들을 모으는 장부를 하나 두고 있습니다. 넉 달쯤 굴렸고 지금은 1,600줄이 넘습니다.

오늘은 그 장부가 어떻게 생겼는지, 그리고 처음 적어 둔 규칙이 넉 달 뒤에 실제로 어디까지 지켜져 있었는지를 세어 본 이야기를 적어 두려 합니다.

제품 사이에 걸친 문제는 어느 문서에도 안 들어갑니다

혼자 AI로 여러 제품을 만들다 보면 세션이 자연스럽게 쪼개집니다. 제품마다, 작업 성격마다 따로 엽니다.

문제는 각 세션이 자기 창문만 본다는 데 있습니다. 한 제품을 손보던 세션이 다른 세션의 흔적을 우연히 밟는 일이 생깁니다.

실제로 제 장부에는 그런 항목이 여러 건 있습니다. 작업은 해 놓고 저장 이력에는 정식으로 남기지 않은 변경을 다른 세션이 발견해 등록한 경우입니다.

이런 항목은 어느 한 제품의 문서에 넣기가 애매합니다. 두 프로젝트에 걸쳐 있기 때문입니다. 그래서 저는 제품별 문서에 흩어 두지 않고 한 파일로 모으기로 했습니다.

처음 정한 규칙: 발견하면 즉시 등록, 끝나면 옮긴다

장부의 첫 줄에 저는 이렇게 적어 두었습니다. 프로젝트 사이의 정합성 문제나 아직 결정하지 못한 사안을 모아 두는 자리이고, 결정이 나면 그 항목을 "해결됨" 쪽으로 옮기면서 영향받는 문서를 함께 고친다는 내용입니다.

옮긴다는 그 한 줄이 나중에 이 글의 주인공이 됩니다.

항목 하나는 제목 한 줄과 그 아래 몇 줄로 이루어집니다. 제목 밑에 굵은 글씨로 네 가지를 답니다.

트랙 아이디는 이 사안을 부를 고유 이름입니다. 다른 문서에서도 같은 이름으로 가리킬 수 있어야 해서 붙였습니다.

나머지 셋은 상태와 발생 시점, 그리고 관련 영역입니다. 마지막 것은 이 사안이 어느 제품, 어느 작업에 물려 있는지를 적는 자리입니다.

그 아래에는 무엇이 어긋나 있는지를 문장으로 쓰고, 필요하면 진입 시점을 덧붙입니다. 진입 시점은 언제 이걸 다시 손대느냐를 적는 칸입니다.

이 마지막 칸이 은근히 중요했습니다. "나중에 하자"로 닫아 두면 그 항목은 영영 나중이 됩니다. 무엇이 갖춰지면 다시 연다고 적어 두어야, 그때가 왔을 때 항목이 되살아납니다.

상태는 제목 줄 맨 앞에 작은 기호로 붙입니다. 본문을 읽지 않고 제목만 훑어도 지금 어느 단계인지 보이게 하려는 장치입니다.

지금 실제로 쓰이고 있는 기호는 다섯 가지입니다. 기호가 아예 안 붙은 항목도 하나 있는데, 양식을 정해 둬도 전부 지켜지지는 않는다는 증거로 남겨 두고 있습니다.

넉 달 뒤에 세어 봤습니다: 규칙은 살아 있고, 지켜지는 비율이 갈립니다

여기서부터가 이 글을 쓰게 된 이유입니다.

넉 달이 지난 지금 장부는 1,669줄이 되었고 항목은 예순한 개가 되었습니다. 미해결 구역에 쉰한 개, "해결됨" 쪽에 열 개입니다.

"해결됨" 쪽은 실제로 만들어져 있었고, 그 아래에 항목 열 개가 옮겨져 있었습니다. 규칙을 적어만 두고 방치한 게 아니었습니다.

그런데 끝났다는 표시가 붙은 항목을 전부 세어 보니 열두 개였습니다. 그중 아홉 개는 "해결됨" 쪽에 있었고, 나머지 세 개는 제목의 표시만 끝난 것으로 바꾼 채 미해결 구역에 그대로 남아 있었습니다.

옮겨진 열 개 중 하나는 상태 표시가 아예 없기도 했습니다. 옮기긴 옮겼는데 표시는 안 붙인 항목입니다.

솔직히 이 숫자를 보고 나서야 제 장부를 제대로 이해했습니다.

규칙은 무너지지 않았습니다. 열두 건 중 아홉 건은 끝까지 따라갔습니다. 다만 나머지 세 건에서 손이 한 걸음 앞에서 멈췄습니다.

왜 그 셋만 남았는지는 기록에 없어서 저도 모릅니다. 확실한 건 옮기는 손이 매번 같은 강도로 움직이지는 않는다는 사실뿐입니다.

여기서 제가 얻은 문장은 이렇습니다. 장부는 지켜지는 만큼만 정확합니다.

그래서 지금은 숫자를 셀 때 항목이 어느 구역에 놓여 있는지만 보지 않습니다. 미해결 구역의 쉰한 개를 그대로 미해결 건수로 읽으면 세 건이 어긋나기 때문입니다.

한 가지 더 눈에 띈 게 있습니다. 파일 맨 위 갱신 기록 칸 하나에 넉 달치 변경 경위가 줄줄이 이어져 있었습니다. 문서에 대한 기록도 본문과 같은 자리에서 함께 자란 셈입니다. 장부는 살아 있으면 반드시 두꺼워집니다.

그리고 최근에는, 성격이 다른 쪽지를 하나 더 뒀습니다

장부와 별개로 최근에 가벼운 장치를 하나 더 두었습니다. 다음 세션이 모르면 순서를 틀리거나 손해를 보는 상황을 막으려고 만든 것입니다.

세션이 끝날 때, 그런 것만 골라 그 작업 폴더의 목차 맨 위에 짧게 남깁니다. 큰 장부와 달리 이건 문 앞에 붙이는 쪽지에 가깝습니다.

아무거나 붙이면 쪽지가 벽이 되므로 조건을 셋으로 못 박았습니다.

조건	언제 걸리나
순서 의존	뒤에 할 일이 앞의 결정에 좌우될 때. 축을 먼저 정해야 그다음이 한 기준으로 굴러가는 경우
낡은 근거	판정이나 수치가 뒤집혔는데 그걸 인용한 문서는 아직 안 고쳤을 때
미실시 잔여	전부 훑기로 한 작업을 일부만 했을 때. 이때는 몇 건 중 몇 건인지 숫자로 적는다

셋 중 어디에도 안 걸리면 남기지 않습니다. 인계 블록은 다음 세션이 매번 읽는 자리라, 여기가 부풀면 정작 급한 항목이 묻힙니다.

세 번째 조건에서 "몇 건 중 몇 건"을 숫자로 적게 한 이유는 단순합니다. "일부 남음"이라고만 적힌 항목은 다음 세션이 얼마나 남았는지 몰라서 처음부터 다시 세게 됩니다.

등록 전에 한 번 더 거릅니다: 물어보면 끝날 일인가

여기서 제가 겪은 시행착오를 하나 적어 두겠습니다.

당사자 본인만 아는 사실을 확인해야 한다는 항목이 장부에 올라간 적이 있습니다. 조건에는 정확히 걸리는 항목이었습니다.

다음 세션은 그 항목을 물려받아 성실하게 실행했습니다. 횟수가 정해진 유료 조회 한도를 써 가며 외부 데이터베이스를 뒤졌습니다.

그리고 나온 결과는, 당사자가 이미 알고 있던 내용이었습니다. 물었으면 한 줄로 끝날 일이었습니다.

이 일이 알려 준 건 등록 비용보다 잔존 비용이 크다는 사실이었습니다. 장부에 올라간 항목은 올리는 순간 끝나지 않고, 읽히고 판단되고 실행될 때까지 세션마다 계속 비용을 먹습니다.

그래서 지금은 등록 전에 질문을 하나 통과시킵니다. 이 답을 사람이 이미 갖고 있는가.

갖고 있으면 장부에 올리지 않고 그 자리에서 묻습니다. 도구로 재야만 알 수 있는 것, 코드나 파일을 직접 열어 봐야 아는 것만 장부에 남깁니다.

판별 기준은 하나입니다. 답을 쥐고 있는 쪽이 사람인지 도구인지.

남기는 장치와 읽는 장치는 한 쌍입니다

마지막으로, 저를 가장 허무하게 만든 실수를 적어 두겠습니다.

"이 폴더에 들어오면 맨 위 인계 블록을 먼저 읽으라"는 지시를, 저는 그 파일 안에만 적어 두었습니다.

그 파일을 열어야 그 지시가 보인다는 게 문제였습니다. 읽으라는 말이 읽어야 보이는 자리에 있으니 아무도 읽지 않습니다.

그래서 지금은 규칙을 하나 더 두고 있습니다. 인계 블록을 만들면, 세션이 시작할 때 그 폴더를 열어 보게 만드는 장치를 반드시 같이 겁니다.

블록을 남기는 일과 그걸 읽게 만드는 일은 한 쌍입니다. 한쪽만 만든 것은 만들지 않은 것과 같습니다.

비슷한 장부를 만드신다면

☐ 세션 사이에 걸친 문제를 모을 자리를 한 곳으로 정했는가
☐ 항목마다 고유한 아이디와 상태를 붙여 제목 줄만 훑어도 단계가 보이는가
☐ 언제 다시 손댈지를 적는 칸이 있는가 (없으면 나중은 영원한 나중이 된다)
☐ 등록 전에 "이 답을 사람이 갖고 있나"를 한 번 묻는가
☐ 남은 작업은 몇 건 중 몇 건인지 숫자로 적는가
☐ 규칙이 실제로 어디까지 지켜졌는지 눈대중이 아니라 한 번 세어 봤는가
☐ 인계 블록을 읽게 만드는 장치를 같이 걸어 두었는가

넉 달을 굴려 보고 제 손에 남은 건 판단 기준 하나였습니다.

무엇을 올리지 않을지 정할 수 있게 된 쪽이 쌓인 줄 수보다 컸습니다. 올리지 않은 항목은 다음 세션의 시간을 먹지 않으니까요.

AI 개발팀을 위한 '에러 매뉴얼' 만드는 법

logicallabs — Fri, 14 Aug 2026 17:20:53 +0900

혼자서 AI에게 개발을 맡기면 코드는 제 손보다 훨씬 빠르게 늘어납니다.

문제는 그 다음입니다. 어느 날 화면에 에러가 뜨면, 저도 AI도 어디부터 열어야 할지 모르는 상태가 됩니다.

그래서 저는 AI 코딩 에러 대응 문서화를 따로 설계했습니다. 사고가 났을 때 AI가 스스로 원인이 있을 만한 자리를 찾아가도록 만든 문서입니다. 지금은 프로젝트 다섯 개 중 네 개, 모듈 마흔 개 남짓이 이 방식으로 정리되어 있습니다.

전에 병합 전 품질 게이트를 다룬 글을 쓴 적이 있습니다. 그 글은 코드가 합쳐지기 전에 거르는 장치였고, 오늘 글은 이미 돌아가는 코드에서 사고가 난 뒤를 다룹니다. 시점이 정확히 반대편입니다.

사고가 났을 때, AI도 어디부터 봐야 할지 모릅니다

사람으로 이루어진 개발팀이라면 "그건 결제 쪽이니 담당자에게 물어보라"는 한마디가 나옵니다. AI에게는 그 한마디를 해 줄 동료가 없습니다.

에러 메시지 하나만 던져 주면 AI는 코드 전체를 뒤지기 시작합니다. 운이 좋으면 맞히고, 아니면 엉뚱한 파일을 고쳐 놓습니다.

그래서 저는 코드를 설명하는 문서보다 찾아가는 길을 설명하는 문서를 먼저 만들기로 했습니다.

첫 번째, 라우팅부터 정합니다

가장 먼저 문서로 못 박은 것은 "어디부터 볼지"의 순서였습니다.

단계	하는 일
1	에러가 발생한다
2	어느 프로젝트, 어느 모듈 소관인지 라우팅한다
3	그 모듈의 목차에서 의심 파일을 짚는다
4	뒤에 나올 8개 항목 중 알려진 함정·흔한 에러·응급 대응을 맞춰 본다 (1차 단계라 뒤 두 칸은 비어 있을 수 있다)

이 순서를 1차로 밟고, 그래도 안 잡히면 2차로 코드를 직접 읽힙니다. 거기서도 남으면 작업계획서와 결정 기록, 사양서에서 맥락을 찾습니다.

별것 아닌 것 같지만, 이 네 줄이 있고 없고에 따라 AI가 처음 여는 파일이 달라집니다.

두 번째, 무엇을 적을지 여덟 가지로 고정합니다

문서를 쓰다 보면 매번 "이번엔 뭘 적어야 하지"에서 막힙니다. 그래서 모듈마다 채울 항목을 여덟 개로 고정했습니다.

번호	항목	담는 내용
①	함수별 책임	이 함수가 무엇을 책임지는가
②	의존관계	무엇을 부르고, 무엇에게 불리는가
③	알려진 함정	여기서 자주 밟는 지뢰
④	디버깅 진입점	문제가 생기면 먼저 여는 자리
⑤	흔한 에러와 원인	증상별 원인 매칭
⑥	응급 대응 절차	지금 당장 뭘 하면 되는가
⑦	로그로 찾는 법	어떤 로그를 어떻게 보는가
⑧	재현 방법과 환경	어떤 설정값으로 어떻게 다시 일으켜 보는가

항목을 미리 정해 두면 문서 작성이 판단에서 채우기로 바뀝니다. 빈칸이 보이니 무엇이 없는지도 한눈에 드러납니다.

세 번째, 처음부터 다 채우지 않습니다

여덟 칸을 처음부터 다 채우려 하면, 벌어지지도 않은 사고를 상상해서 적게 됩니다. 그건 문서가 아니라 소설에 가깝습니다.

그래서 기준을 하나 두고 두 번에 나눠 채우기로 했습니다. 코드를 읽고 판단하면 알 수 있는 것은 지금 채우고, 실제로 한 번 굴려 봐야만 아는 것은 뒤로 미룹니다.

층	해당 항목	채우는 시점
구조층	①②③⑧ (여기에 ④ 일부)	개발하면서
실전층	⑤⑥⑦	실제 사고가 난 뒤에 한 줄씩 (단, ⑤는 코드로 읽히는 자리에 한해 미리 씨앗을 깝니다)

실전층은 완성을 목표로 하지 않습니다. 운영하는 내내 누적되고, 실제 연동과 실제 비용이 붙으면서 생기는 코드 변경까지 계속 흡수합니다. 그래서 이 문서는 동결하지 않습니다.

이 원칙은 언뜻 게으르게 보일 수 있습니다. 그런데 코드에서 근거를 짚을 수 없는 칸은, 미리 채워 넣어 봐야 정작 사고가 났을 때 기댈 수가 없습니다.

갱신 책임도 같이 정해 두었습니다. 실제 에러에 대응할 때마다 그 모듈의 ⑤⑥⑦에 한 줄씩 쌓고, 코드 변경을 병합할 때 ①②⑧을 함께 손봅니다.

네 번째, 코드가 답할 수 있는 건 적지 않습니다

문서를 만들다 보면 함수 시그니처와 데이터베이스 구조와 API 경로까지 다 적고 싶어집니다. 저는 이걸 의도적으로 뺐습니다.

이런 항목은 검색 한 번이면 값이 그대로 튀어나옵니다. AI에게 찾아보라고 시키면 몇 초면 끝납니다. 그런데 문서에 또 적어 두면 코드가 바뀔 때마다 두 곳을 고쳐야 하고, 언젠가 반드시 한쪽이 낡습니다.

그래서 이 문서가 담당하는 것은 코드가 답하지 못하는 영역, 즉 운영하며 얻은 경험과 대응 절차입니다.

같은 이유로 규모를 적는 방식에도 선을 그었습니다. 파일 줄 수는 어느 모듈을 먼저 깊게 파야 할지 가늠하는 스냅샷으로만 남기고, 검색하면 바로 나오는 메서드나 함수 개수는 문서에 박지 않습니다.

한 가지 더 있습니다. 실험용으로 만들어 둔 코드 경로는 운영 파이프라인이 호출하지 않으므로, 에러 라우팅 후보에서 아예 제외한다고 문서에 명시해 두었습니다. AI가 엉뚱한 곳을 뒤지는 시간을 줄이는 장치입니다.

다섯 번째, 사고가 몰릴 곳부터 먼저 깊게

모든 모듈을 같은 깊이로 채우지는 않습니다.

상태가 단계별로 넘어가는 지점이나 비동기 처리의 경계처럼, 사고가 몰릴 것으로 예상되는 자리를 먼저 지목해 그곳만 깊게 팠습니다.

실제로 그렇게 먼저 판 한 곳에는 지금 다섯 줄이 들어가 있습니다. 코드를 읽으면서 "여기서는 이런 식으로 터진다"를 미리 뽑아 둔 씨앗 목록입니다.

그중 네 줄을 옮겨 보면 이런 모양입니다.

증상	원인
409 Conflict, 확정 요청이 거부됨	이전 단계가 끝나지 않은 상태에서 확정을 호출
404 Not Found	상태 레코드가 아직 만들어지지 않음
작업이 실패 응답으로 돌아옴	필요한 데이터 재조회에 실패(예외를 던지지 않고 결과값으로 반환)
작업 요청은 보냈는데 실행이 안 됨	작업 지시를 대신 받아 두는 중간 서버(메시지 브로커)가 연결되지 않았거나, 그 지시를 꺼내 처리할 프로세스가 떠 있지 않거나, 실행 방식 설정이 어긋남

다섯 줄 모두 코드에서 근거를 짚어 적었기 때문에, 증상과 원인이 특정 파일까지 이어집니다. 근거 없이 머릿속에서 지어낸 목록과는 쓸모가 다릅니다.

여기서 한 걸음 더 나간 응급 대응과 로그 항목은, 실제로 한 번 겪어야 채워집니다.

시행착오 하나, 같은 문서를 두 곳에 뒀습니다

처음 이 문서를 만들 때 실수가 하나 있었습니다.

코드 저장소 안에도 경로를 안내하는 문서가 하나 있었고, 운영 문서 쪽에도 비슷한 성격의 것이 따로 자라고 있었습니다. 성격이 같은 정보가 두 군데로 나뉘면, 정작 급할 때 어느 쪽이 맞는지부터 헷갈립니다.

결국 코드 저장소 쪽 문서를 운영 문서 쪽으로 흡수해 하나로 합쳤습니다. 그 뒤로는 같은 성격의 문서를 두 곳에서 각각 키우지 않기로 했습니다.

지금은 절반만 채워져 있습니다

정직하게 현재 상태를 적어 둡니다.

구조층은 네 프로젝트의 모듈에 1차 골격까지 들어차 있지만, 실전층에 해당하는 ⑤⑥⑦은 대부분의 모듈에서 아직 "미기재"로 남아 있습니다. 앞서 말한, 사고가 몰릴 것으로 본 한 곳의 '흔한 에러' 칸에만 코드에서 뽑은 씨앗이 들어가 있습니다.

이 빈칸은 밀린 숙제라기보다 원칙이 눈에 보이는 상태에 가깝습니다. 코드를 읽어 판단할 수 있는 것은 미리 채우고, 겪어야만 아는 것은 뒤로 미룬다는 그 원칙 말입니다. 채워진 칸과 빈칸이 나란히 있는 모습 자체가 이 문서가 살아 있다는 신호이기도 합니다.

혹시 비슷한 문서를 만들어 보실 생각이라면, 아래 순서로 시작해 보시길 권합니다.

에러가 났을 때 어느 프로젝트, 어느 모듈로 갈지 라우팅 순서를 먼저 적었는가
모듈마다 채울 항목을 미리 고정했는가 (많아도 열 개 안쪽)
코드를 읽고 판단해 지금 적을 수 있는 항목과, 겪어야만 채워지는 항목을 나눠 두었는가
검색하면 값이 그대로 나오는 정보를 문서에 중복해 적고 있지는 않은가
사고가 몰릴 것 같은 지점을 한 곳 이상 지목했는가
같은 성격의 문서가 두 군데에서 각각 자라고 있지는 않은가
에러를 한 번 처리할 때마다 문서에 한 줄 남기는 습관이 있는가

AI에게 개발을 맡긴다는 건 코드를 대신 짜 준다는 뜻만은 아니었습니다. 사고가 났을 때 어디부터 보라고 알려 줄 문서를 제가 대신 써 둬야 한다는 뜻이기도 했습니다.

그 문서는 사고가 한 번 날 때마다 한 줄씩 늘어납니다.

Next.js 16에서 middleware가 proxy로 바뀌었습니다: 마이그레이션과 조용히 빠지는 인증 주의점

logicallabs — Sat, 1 Aug 2026 19:23:38 +0900

프레임워크가 어느 날 파일 이름을 바꾸면, 혼자 제품을 만드는 사람은 그걸 어떻게 따라가야 할까요.

저는 제품 프론트엔드를 Next.js로 만들고 있습니다. 그래서 Next.js 16이 나오면서 나온 여러 변경 중에서도 middleware를 proxy로 바꾼 개편은 그냥 지나칠 수가 없었습니다.

이름만 바뀐 사소한 변경처럼 보이지만, 마이그레이션을 어중간하게 끝내면 인증이 소리 없이 비어 버릴 수 있습니다. 오늘은 공식 문서를 직접 확인하며 정리한 내용을 남깁니다.

무엇이 바뀌었나

Next.js 16(정식 릴리스 2025년 10월 21일)부터 middleware.ts 파일 컨벤션이 지원 중단(deprecated)되고 proxy.ts로 이름이 바뀌었습니다. 기존 이름이 곧바로 없어진 것은 아니고 하위 호환으로 당분간 남지만, 새 표준은 proxy.ts입니다.

파일 이름만이 아니라 export 하는 함수 이름과 설정 플래그까지 함께 바뀌었습니다.

항목	변경 전 (v15)	변경 후 (v16)
파일명	middleware.ts / .js	proxy.ts / .js
export 함수명	export function middleware()	export function proxy()
설정 플래그	skipMiddlewareUrlNormalize	skipProxyUrlNormalize
런타임	기본 Edge Runtime	Node.js 런타임 고정 (변경 불가)

로직 자체는 그대로입니다. 파일과 함수의 이름, 그리고 실행 런타임이 달라졌을 뿐입니다.

코드는 이렇게 바뀝니다.

// 변경 전: middleware.ts
export function middleware(request) {
  // 인증, 리다이렉트, 헤더 조작 등
}

// 변경 후: proxy.ts
export function proxy(request) {
  // 동일한 로직, 이름만 proxy
}

한 가지 눈여겨볼 점은 런타임입니다. proxy는 Node.js 런타임으로 고정되어 있고 Edge Runtime을 지원하지 않습니다.

Edge에서 돌려야 하는 로직이 있다면 (지원 중단으로 표시된) 기존 middleware를 당분간 유지해야 합니다. 다만 middleware는 현재 지원 중단(deprecated) 상태라, 이후 나올 공식 안내를 지켜봐야 합니다.

왜 이름을 proxy로 바꿨을까

이름 하나 바꾸자고 이렇게까지 한 데는 이유가 있습니다. 공식 문서가 밝힌 배경은 크게 두 가지입니다.

첫째, "middleware"라는 단어가 Express.js의 미들웨어와 자주 혼동을 일으켰습니다. 이름 때문에 사람들이 이 기능의 용도를 오해하곤 했습니다.

둘째, middleware가 너무 강력해서 남용을 부추기는 면이 있었습니다. Next.js 팀은 이 기능을 최후의 수단으로만 쓰기를 권장해 왔고, 더 나은 API로 목표를 달성하도록 방향을 틀고 있습니다.

"proxy"라는 이름은 앱 앞단의 네트워크 경계(요청이 앱에 닿기 전 거치는 지점)를 분명히 드러냅니다. 실제 기능의 본질에 더 가까운 이름인 셈입니다.

즉 이 개명은 단순한 취향의 문제가 아니라, 이 기능을 어떻게 써야 하는지에 대한 설계 신호를 담고 있습니다.

마이그레이션: 자동이 편하지만 눈으로 확인하세요

옮기는 방법은 두 가지입니다.

자동으로는 코드모드(codemod, 코드를 기계적으로 일괄 변환해 주는 도구) 한 줄이면 됩니다.

npx @next/codemod@canary middleware-to-proxy .

파일명과 함수명을 알아서 바꿔 줍니다. 통합 업그레이드 코드모드(npx @next/codemod@canary upgrade latest)를 쓰면 이 변환에 더해 설정 플래그까지 함께 정리됩니다.

수동으로 하려면 middleware.ts를 proxy.ts로 옮기고, 함수 이름을 middleware에서 proxy로 바꾸고, skipMiddlewareUrlNormalize 같은 설정 플래그도 새 이름으로 고치면 됩니다. default export를 쓰더라도 함수 이름은 proxy로 두기를 권장합니다.

자동 변환이 편하긴 하지만, 저는 변환 뒤 바뀐 파일을 눈으로 한 번 훑어보길 권합니다. 다음에 이야기할 함정 때문입니다.

가장 위험한 함정: 조용히 빠지는 인증 커버리지

먼저 오해 하나를 풀어야 합니다. Next.js 16으로 올린 뒤에 옛 middleware.ts 파일을 그대로 두면 그 파일이 갑자기 무시되는 건 아닙니다.

하위 호환이 유지되어 계속 동작하고, 대신 지원 중단(deprecated)으로 표시되니 정리해 두길 권합니다. 공식 문서도 Edge 런타임이 필요하면 당분간 middleware를 계속 쓰라고 안내합니다.

그러니 파일을 남겨 뒀다는 이유만으로 인증이 소리 없이 죽지는 않습니다.

진짜 조심할 지점은 다른 데 있습니다. 마이그레이션이 어중간하게 끝났을 때입니다.

파일만 proxy.ts로 옮기고 export 하는 함수 이름을 middleware인 채로 두면, proxy.ts는 그 함수를 인식하지 못합니다. proxy 파일은 default export이거나 이름이 정확히 proxy인 named export만 인식하기 때문입니다.

이 경우 빌드는 통과하는데 정작 인증 로직이 실행되지 않을 수 있습니다.

또 하나는 커버리지 누락입니다. 공식 문서가 직접 "silently(소리 없이)"라는 단어로 경고하는 부분입니다.

config.matcher를 손봤거나 Server Function을 다른 경로로 옮기는 리팩터링을 하면, Proxy가 걸려 있던 보호 범위가 조용히 빠질 수 있습니다. 그래서 공식 문서는 Proxy 하나만 믿지 말고 각 Server Function 안에서 인증과 인가를 직접 확인하라고 권합니다.

에러가 나면 오히려 다행인데, 이 두 경우 모두 아무 신호 없이 지나갈 수 있다는 점이 위험합니다.

그래서 업그레이드 뒤에는 아래를 체크리스트로 점검하시길 권합니다.

proxy.ts로 옮긴 파일 안의 export 함수 이름이 proxy로 바뀌어 있는가 (middleware인 채면 인식 안 됨. default export나 이름이 proxy인 named export만 인식)
skipMiddlewareUrlNormalize 등 옛 설정 플래그가 새 이름으로 교체되었는가
config.matcher를 바꿨거나 Server Function을 옮겼다면, Proxy 보호가 빠진 경로가 없는지 확인했는가
인증이 필요한 경로에 로그인 없이 접근해 보고, 정말 막히는지 실제로 확인했는가
옛 middleware.ts를 남겨 뒀다면, 지원 중단(deprecated) 상태임을 인지하고 정리 계획을 세웠는가
Edge 런타임에 의존하던 로직이 있었다면, Node.js 고정으로 바뀐 뒤에도 문제없이 동작하는가

특히 실제로 로그인 없이 보호 경로를 눌러 보는 확인은 빼먹지 마세요. 파일과 함수가 옮겨졌는지가 아니라, 인증이 실제로 작동하는지를 봐야 합니다.

혼자 만드는 사람에게 프레임워크 변화란

메이저 업그레이드는 부담입니다. 특히 팀 없이 혼자 제품을 붙들고 있으면 더 그렇습니다.

그럴 때 저는 두 가지를 기준으로 삼습니다.

하나는 변경이 왜 일어났는지를 먼저 읽는 것입니다. 이번처럼 이름만 바뀐 것처럼 보이는 변경에도 대개 설계 의도가 깔려 있고, 그 의도를 알면 다음 방향도 짐작할 수 있습니다.

다른 하나는 자동 도구를 믿되 결과를 눈으로 확인하는 것입니다. 코드모드는 시간을 아껴 주지만, 함수 이름이나 커버리지처럼 조용히 빠지는 함정까지 대신 잡아 주지는 않습니다.

결국 마지막 확인은 사람 몫으로 남습니다.

Next.js 16은 이 proxy 개명 말고도 Turbopack 기본화, 비동기 요청 API 강제, React 19.2 같은 큰 변화를 함께 담고 있습니다. proxy 이야기는 그중 한 조각일 뿐입니다.

나머지 조각들도 하나씩 정리해 남겨 두려 합니다.

Meta-Harness: AI 에이전트가 자기 하네스를 스스로 다시 짜기 시작했습니다

logicallabs — Sat, 1 Aug 2026 19:18:28 +0900

저는 그동안 하네스를 손으로 다뤄 왔습니다. 여기서 하네스(harness)란 AI 모델을 실제로 굴리는 바깥 구조물을 말합니다.

프롬프트를 어떻게 조립할지, 컨텍스트에 무엇을 넣고 뺄지, 과거 기록을 어떻게 기억하게 할지 같은 것들입니다. 같은 모델이라도 이 구조물을 어떻게 짜느냐에 따라 성능이 크게 갈립니다.

이 블로그의 하네스 시리즈는 줄곧 "그래서 하네스를 어떻게 잘 설계하느냐"를 다뤄 왔습니다.

그런데 최근에 읽은 논문 한 편이 그 전제를 흔들었습니다. 하네스를 잘 설계하는 법이 아니라, 하네스를 설계하는 일 자체를 에이전트에게 맡기는 연구였습니다.

오늘 글은 제가 이 논문을 직접 돌려 본 결과가 아니라, 공개된 논문과 자료를 바탕으로 정리한 해설입니다. 다만 손으로 하네스를 튜닝해 온 사람으로서 이게 무슨 의미인지는 제 나름의 관점으로 붙여 보려 합니다.

먼저, 이건 예전에 다룬 그 "메타하네스"가 아닙니다

이름이 비슷해서 헷갈리실 수 있어 먼저 정리하겠습니다. 예전에 이 블로그에서 다룬 "메타하네스"는 Anthropic이 에이전트의 세션을 통째로 저장하고 다시 이어 붙이는, 플랫폼 차원의 가상화 이야기였습니다.

오늘 이야기하는 Meta-Harness는 그것과 이름만 겹칠 뿐 전혀 다른 연구입니다. 이쪽은 하네스의 성능을 에이전트가 스스로 다시 프로그래밍해서 끌어올리는 자동 최적화에 관한 것입니다.

Meta-Harness는 무엇을 하나

논문 제목은 "Meta-Harness: End-to-End Optimization of Model Harnesses"이고, arXiv 번호는 2603.28052입니다. 저자에는 DSPy를 만든 Omar Khattab과 Chelsea Finn이 포함돼 있고, 소속은 Stanford, MIT, 그리고 한국 게임사 KRAFTON입니다.

국내 회사가 공저로 들어간 점이 개인적으로 반가웠습니다.

핵심 아이디어는 이렇습니다. 보통은 하네스를 개선하는 로직을 사람이 바깥에 따로 짜 둡니다.

이 논문은 그 개선 작업 자체를 코딩 에이전트에게 넘깁니다. 에이전트에게 과거 시도의 원본 실행 기록에 자유롭게 접근할 권한을 주고, grep이나 cat 같은 도구로 필요한 부분을 스스로 골라 읽게 합니다.

그렇게 읽은 내용을 근거로 검색 로직과 메모리 관리, 프롬프트 조립 구조를 반복해서 다시 짜 나갑니다. 사람이 손대던 튜닝을 에이전트가 대신 하는 셈입니다.

숫자로 본 결과

논문이 보고한 대표적인 결과를 표로 정리했습니다.

과제	결과
온라인 텍스트 분류	기존 최고 성능 시스템(ACE) 대비 +7.7점, 동시에 컨텍스트 토큰 약 4배 절약
검색증강 수학추론	자동으로 찾아낸 단일 하네스가 학습에 안 쓴 모델 5종에서 평균 +4.7점
코딩 에이전트 벤치마크	자동 최적화 하네스가 사람이 수동으로 설계한 하네스들을 넘어섬

더 좋은 성능을 더 적은 연산으로 냈다는 점이 눈에 띕니다. 그리고 한 모델에 맞춰 찾은 하네스가 처음 보는 다른 모델에서도 성능을 올렸다는 점은, 이 방식이 특정 모델에만 통하는 요령을 넘어선다는 신호로 읽힙니다.

가장 인상적이었던 교훈: 원본 기록을 버리지 마라

개인적으로 가장 오래 곱씹은 대목은 성능 숫자가 아니었습니다. 이 방식이 통하려면 과거 실행의 원본 기록이 그대로 남아 있어야 한다는 점이었습니다.

논문에 따르면 그 기록을 요약본으로 갈아 끼우면 성능이 무너집니다. 압축되지 않은 실제 실행 디테일 안에 개선의 실마리가 들어 있다는 뜻입니다.

이건 제가 평소에 작업 기록과 실패 로그를 요약하지 않고 원본 그대로 보존해 온 습관과 정확히 맞닿습니다. 당장 사람이 다시 읽지 않더라도, 나중에 무언가가 그 기록을 뒤져 개선의 단서를 찾을 수 있기 때문입니다.

실패의 흔적을 깔끔하게 지우는 대신 지저분한 채로 남겨 두는 편이 낫다는 것을, 이 논문이 실험으로 보여 준 셈입니다.

하네스가 "설정"에서 "컴파일러"로

한 업계 관찰자는 이 흐름을 두고 하네스가 고정된 설정값에서 컴파일러에 가까운 무언가로 변하는 지점이라고 표현했습니다. 사람이 한 번 정해 두는 값이 아니라, 목표에 맞춰 알아서 코드를 다시 뽑아내는 도구로 바뀐다는 이야기입니다.

실제로 이 방식에서는 개선을 제안하는 쪽이 한 번 돌 때마다 수십 개의 파일을 읽어 가며 진단을 내립니다. 사람이 눈으로 훑기 어려운 규모입니다.

그래서 손으로 하네스를 짜 온 사람에게 무슨 의미인가

솔직히 처음엔 마음이 복잡했습니다. 하네스를 잘 짜는 감각이 1인 개발자에게는 나름의 차별화 지점이었는데, 그 감각마저 자동화된다면 남는 자리가 어디인가 싶었습니다.

며칠 생각해 보니 답은 한 칸 위로 옮겨 가 있었습니다. 에이전트가 하네스를 다시 짜 준다 해도, "무엇을 잘하게 만들 것인가"와 "무엇으로 잘함을 판정할 것인가"는 여전히 사람이 정해야 합니다.

문제를 정의하고 평가 기준을 세우는 일입니다. 튜닝의 손이 자동화될수록, 오히려 이 위층의 판단이 더 중요해집니다.

마지막으로 한 가지만 덧붙이겠습니다. 이 논문은 아직 동료 심사를 거치지 않은 arXiv 프리프린트입니다.

수치와 결론은 앞으로 검증 과정에서 다듬어질 수 있으니, 방향의 신호로 읽으시길 권합니다. 그래도 하네스를 짜는 일 자체가 자동화되는 프론티어가 이미 열렸다는 사실만큼은, 손으로 하네스를 다뤄 온 저에게 분명한 전환점으로 다가왔습니다.

AI 에이전트로 1인이 5명 몫을 한다는 말, 실제로는 편성 문제였습니다

logicallabs — Wed, 29 Jul 2026 14:28:36 +0900

"에이전트 18개"라는 숫자부터 의심했습니다

요즘 1인 창업 이야기에는 숫자가 따라다닙니다.

맥미니 한 대에 AI 에이전트 18개를 붙여 월 50~100달러로 반복 업무의 70~80%를 처리한다는 사례(markcijo.ai), 에이전트 14개를 월 100~780달러로 굴리면서 60~80%는 무료 로컬 모델에 넘긴다는 사례(Stakh)가 자주 인용됩니다.

숫자만 보면 대단합니다. 그런데 자료를 찾아보면서 제가 가장 먼저 확인한 것은 출처였습니다. 두 사례 모두 개인 블로그와 링크드인 글에 근거하고 있고, 제가 찾아본 범위에서는 제3자가 독립적으로 검증한 기록을 확인하지 못했습니다.

참고로 볼 수는 있어도 목표치로 삼기에는 근거가 얇았습니다.

제 실제 숫자를 먼저 말씀드리겠습니다. 지금 동시에 굴리는 에이전트는 4개입니다. 평소에도 3~5개 사이를 오갑니다.

18개와 4개. 이 격차가 이 글의 출발점입니다.

미리 밝혀둘 것도 하나 있습니다. 이 글에 나오는 해외 사례와 업계 지형은 공개된 자료를 찾아 정리한 내용입니다. 제가 현장을 직접 관찰하거나 관계자를 인터뷰해서 얻은 정보는 없습니다.

배수가 나오는 네 개의 층

"AI가 1인을 5~10인으로 만든다"는 말은 하나의 도구 이야기로 뭉뚱그려지곤 합니다. 실제로 자료를 뜯어보면 성격이 다른 네 개의 층이 섞여 있습니다.

층	하는 일	공개 사례	제 경우
① AI 코딩 도구	제품을 직접 만든다	Claude Code, Cursor(직원 약 230명, ARR 5억 달러 규모로 보도)	코드 작성과 실행, 검증을 AI 세션에 태워 진행
② 노코드 + AI	개발 없이 만든다	Lovable(창업 2년, 기업가치 18억 달러·직원 45명)	해당 없음. 저는 이 층을 쓰지 않습니다
③ 워크플로우 자동화	반복 절차를 잇는다	n8n(솔로파운더 창업, 기업가치 25억 달러)	운영 기록의 원본은 SQLite 데이터베이스 한 곳에 두고, 사람이 읽는 현황판은 거기서 자동 생성
④ AI 에이전트	사업을 운영한다	OpenClaw(공개 두 달 만에 GitHub 최다 스타 저장소, 2026년 상반기 30만 개 이상)	역할별 페르소나 프롬프트 정본 35종, 실제로 호출되어 도는 서브 에이전트 24종

※ 위 표의 Cursor·Lovable·n8n 관련 수치는 2025년 보도 기준입니다.

네 번째 층이 제 하루의 대부분입니다.

24종은 제가 직접 불러 의견을 듣는 자문 역할 10종과, 파이프라인에서 실제 작업을 처리하는 워커 14종으로 나뉩니다. 편성표에 올라 있는 역할을 직군으로 묶어 보면 이렇습니다.

직군	등록된 역할(예)
법무·특허·세무·노무	변호사AI, 변리사AI, 세무 담당 2종, 노무사AI
개발	CTO AI, 개발실장AI
마케팅·브랜드	마케팅 디렉터AI와 과장 4종(주제리서치·콘텐츠작성·규제검토·발행), 브랜드디렉터AI, 디자인 담당
조사·사업	리서치AI, 엑셀러레이터AI, 보험설계사AI
게임	게임 총괄 1종과 창작 담당 3종(이야기·아트·사운드)

혼자 회사를 굴리면서 이 직군의 검토와 정리를 외부에 맡기지 않고 안에서 처리하고 있으니, 역할 수로만 따지면 전문직 열 사람 몫 이상의 범위를 덮고 있는 셈입니다. 물론 자격이 필요한 일 자체는 자격자에게 맡깁니다. 안에서 하는 것은 그 앞단의 자료 정리와 1차 검토입니다.

다만 이건 커버하는 범위의 이야기이지, 제 생산량이 열 사람과 같다는 뜻은 아닙니다. 그 수치는 저도 재본 적이 없습니다.

여기서 짚고 싶은 대비가 있습니다. 편성표에는 35종이 올라 있고 실동작 역할만 24종인데, 동시에 굴리는 것은 3~5개입니다. 편성표는 크고, 동시 가동은 절제돼 있습니다.

그 절제의 기준이 다음 이야기입니다.

a16z Speedrun의 앤드류 챈은 2026년 3월 'Agentic'이라는 팟캐스트에서, AI 에이전트가 디지털 팀메이트가 되면서 전통적인 직함과 역할의 경계가 흐려진다는 취지의 이야기를 했습니다. 이걸 제 일로 옮겨 보면, 한 번에 한 부서만 붙잡고 있던 데서 여러 역할을 나란히 돌리는 쪽으로 옮겨 온 셈입니다. 챈의 말은 개인 견해이지 회사의 공식 정책은 아니지만, 제가 실제로 하고 있는 일과 결이 가까웠습니다.

무엇을 맡기고 무엇을 붙잡을지, 저는 이렇게 나눕니다

여기서부터가 이 글에서 제일 하고 싶은 이야기입니다.

에이전트를 여러 개 띄우면 곧바로 부딪히는 질문이 있습니다. 어디까지 알아서 가게 두고, 어디서 나를 불러야 하는가.

흔한 답은 난이도로 자릅니다. 쉬운 일은 AI, 어려운 일은 사람. 저는 난이도가 아니라 결정의 유무로 자릅니다.

이미 내려진 결정이 있으면 에이전트가 쭉 갑니다. 그 일이 얼마나 복잡한지는 따지지 않습니다. 복잡해도 방향이 확정돼 있으면 끝까지 가게 둡니다.

반대로 다음 세 가지 중 하나에 걸리면 저에게 돌아옵니다.

상황	처리
결정 내역이 없다	진행 중단. 저와 논의한 뒤 재개
이미 결정된 사항과 어긋난다	진행 중단. 결정을 바꿀지 저에게 확인
결정이 있긴 한데 애매하다	진행 중단. 해석을 저에게 확인

간단해 보이지만, 이 기준을 세우고 나서 일의 성격이 달라졌습니다. 제가 하루에 하는 일의 상당 부분은 작업을 처리하는 것에서 결정을 공급하는 쪽으로 옮겨갔습니다.

콘텐츠 한 편만 봐도 그렇습니다. 소재에 따라 사실 검증이 먼저 붙고, 그다음 규제 검토와 법률 검토를 차례로 통과해야 발행 단계로 넘어갑니다.

각 관문에서 판정이 애매하면 그 자리에서 멈추고 저에게 올라옵니다. 판정이 명확하면 저를 거치지 않고 다음 관문으로 갑니다.

그런데 이들은 성실한 신입에 가깝습니다

자랑처럼 들릴까 봐 반대쪽도 적겠습니다.

2026년 3월 보도된 프린스턴 연구진의 AI 에이전트 신뢰도 평가(네 개 차원 열네 개 지표)에 따르면 최고 성능 모델도 신뢰도가 85% 수준이고, 정확도가 올라가는 속도보다 신뢰도가 올라가는 속도가 2분의 1에서 7분의 1 정도로 느립니다. 열 번 중 한 번 이상은 어긋난다는 뜻입니다.

커뮤니티 사용기에는 더 거친 표현도 있습니다. 처음 3~4일은 놀라운 성과가 나오다가 이후로는 고장과 잘못된 정보, 재구축이 반복된다는 후기가 반복적으로 올라옵니다. 다만 실망한 사람이 글을 더 많이 쓰는 경향이 있으니 그대로 받아들이기는 어렵습니다.

제 쪽 사정도 비슷합니다. 서브 에이전트는 격리된 새 세션으로 뜨기 때문에 앞의 맥락이 이어지지 않습니다. 매번 배경을 다시 줘야 하고, 배경을 대충 주면 결과도 대충 나옵니다.

사람이라면 어제 회의를 기억하지만 이쪽은 기억하지 않습니다.

보안 문제도 있습니다. 한 보안업체의 2026년 2월 조사에서는 에이전트 확장 기능을 모아둔 저장소에서 악성 스킬 341개가 확인됐고, 그 뒤로 더 늘었습니다. 편하다고 아무 확장이나 붙이면 그 자체가 구멍이 됩니다.

숨은 비용도 정직하게 적겠습니다. 이런 시스템을 설계하고 세우는 데에는 몇 주의 전업 작업이 들어가고, 세운 뒤에도 주당 서너 시간의 유지보수가 계속 필요하다는 것이 여러 사례가 공통으로 말하는 대목입니다. 공짜로 굴러가는 구조는 없었습니다.

그래서 저는 이들을 시니어 파트너로 대하지 않습니다. 성실하고 빠른 신입 직원 여럿을 데리고 있다고 생각하는 편이 훨씬 정확합니다. 신입에게 필요한 것은 더 좋은 도구보다 명확한 지시와 되물을 수 있는 통로입니다.

그래서 결국 무엇을 늘려야 하는가

제 결론은 이렇습니다. 배수는 도구 개수가 아니라 관리 시스템에서 나옵니다.

같은 모델을 써도 결과는 갈립니다. 갈리는 지점은 띄운 개수에 있지 않았습니다. 역할이 얼마나 또렷하게 정의되어 있는지, 결정이 어디에 기록되어 있는지, 애매할 때 사람에게 돌아오는 길이 열려 있는지였습니다.

많이 띄우되 돌아올 길을 설계하지 않은 구성보다, 네 개를 띄우고 세 가지 회송 조건이 살아 있는 편이 저에게는 훨씬 안전했습니다.

혼자 일하는 사람에게 AI가 만들어 주는 자리는 관리자 자리 하나입니다. 그 자리에 앉을 준비가 되어 있느냐가 배수를 정합니다.

하네스 성능 13.7p, 흔히 뭉뚱그리는 두 숫자를 해부했습니다

logicallabs — Tue, 28 Jul 2026 09:39:56 +0900

이 두 숫자, 사실 다른 실험입니다

먼저 밝혀 둡니다. 아래 이야기는 제가 직접 돌린 실험 결과가 아닙니다. 공개된 기술 블로그와 벤치마크, 리서치 자료를 찾아 읽고 정리한 것입니다.

나오는 수치는 모두 그 자료에 있는 값이고, 제가 지어낸 숫자는 하나도 없습니다.

AI 에이전트 이야기를 하다 보면 ‘하네스만 바꿔도 성능이 크게 달라진다’는 말이 자주 나옵니다. 그 근거로 두 숫자가 거의 항상 짝지어 등장합니다. 하나는 ‘순위가 33위에서 5위로 올랐다’, 다른 하나는 ‘점수가 13.7포인트 올랐다’입니다.

그런데 이 둘은 같은 실험이 아닙니다. 모델도 다르고, 재는 방식도 다르고, 하려는 이야기도 다릅니다. 한 문장에 묶어 인용하면 사실이 뭉개집니다.

여기서 하네스(harness)는 모델 자체를 뺀 나머지 전부를 가리키는 말입니다. 도구, 실행 환경, 검증 규칙, 컨텍스트 관리 같은 것들입니다. 같은 모델이라도 이 주변을 어떻게 설계하느냐에 따라 결과가 달라진다는 게 이 분야의 출발점입니다.

이 ‘모델 주변 설계가 성능을 가른다’는 이야기 자체는 지난 글에 정리해 두었습니다. 오늘은 거기서 한 걸음 더 들어가, 그 숫자가 어디서 나왔고 왜 자주 잘못 인용되는지를 뜯어보려 합니다.

13.7포인트의 정체

먼저 13.7포인트부터 봅니다.

이 숫자는 LangChain이라는 회사의 오픈소스 에이전트(DeepAgents)에서 나왔습니다. Terminal Bench 2.0이라는 코딩 에이전트 성능 시험대(벤치마크)에서, 점수를 52.8퍼센트에서 66.5퍼센트로 끌어올린 폭이 13.7포인트입니다.

여기서 중요한 건, 모델을 더 좋은 걸로 바꾼 게 아니라는 점입니다. 모델은 그대로 두고 하네스만 손봤습니다. 무엇을 손봤는지가 이 글의 핵심입니다.

숫자를 뜯어보면

두 가지가 이 상승을 만들었습니다.

첫째는 리즈닝 샌드위치(reasoning sandwich)입니다. 모델이 생각하는 데 쓰는 예산을 단계마다 다르게 배분하는 방식입니다.

계획을 세울 때는 깊게, 코드를 짤 때는 중간, 마지막 검증에서 다시 깊게 배분합니다. 깊게-중간-깊게로 감싸는 모양이라 샌드위치라고 부릅니다.

추론 예산 배분	점수
계속 깊게(xhigh)만	53.9%
계속 중간(high)만	63.6%
샌드위치(깊게·중간·깊게)	66.5%

흥미로운 건 계속 깊게 생각하게 둔 쪽(53.9퍼센트)이 계속 중간으로 둔 쪽(63.6퍼센트)보다 오히려 낮다는 점입니다. 무조건 깊게 생각한다고 좋은 게 아니라, 단계에 맞게 배분하는 설계가 이겼습니다.

둘째는 하네스 미들웨어입니다. 미들웨어는 모델이 답을 내놓기 전후에 자동으로 끼어들어 검사하는 장치입니다. 여기서는 두 가지가 쓰였습니다.

하나는 ‘끝내기 전 체크리스트’(PreCompletionChecklist)로, 작업을 마쳤다고 선언하기 전에 빠뜨린 게 없는지 확인합니다. 다른 하나는 ‘반복 감지’(LoopDetection)로, 에이전트가 같은 행동을 무한히 되풀이하는 걸 잡아냅니다.

자료에서는 이 미들웨어 두 개를 13.7포인트 상승의 실제 기여원으로 꼽습니다. 화려한 모델 교체가 아니라, 이런 수수한 장치들이 숫자를 만들었다는 이야기입니다.

33위에서 5위는 다른 이야기입니다

이제 다른 숫자입니다.

‘33위에서 5위’는 앞의 실험과 아예 다른 사건입니다. 이건 Claude Opus 4.6이라는 모델을 같은 Terminal Bench 2.0에 올렸을 때 나온 순위입니다. 그 모델을 만든 회사의 기본 하네스(Claude Code)에서는 33위였는데, 다른 하네스에 얹었더니 5위로 올라갔습니다.

이걸 두고 한 벤치마크 분석(HumanLayer)에서는 ‘과적합’이라고 불렀습니다. 과적합은 특정 환경에만 지나치게 맞춰져 다른 데선 성적이 떨어지는 현상입니다. 모델이 자기 집 하네스에 너무 길들여진 나머지, 오히려 남의 하네스에서 실력이 더 나온 셈입니다.

정리하면 13.7포인트는 ‘gpt-5.2-codex 모델용 하네스를 다듬어 점수를 올린 이야기’이고, 33위에서 5위는 ‘Opus 4.6 모델이 하네스에 따라 순위가 뒤집힌 이야기’입니다. 모델도 다르고, 재는 단위(점수와 순위)도 다르고, 결론도 다릅니다. 그래서 한 근거로 합치면 안 됩니다.

반전, 하네스는 모델마다 다시 튜닝해야 합니다

여기까지 오면 자연스러운 반전이 하나 있습니다.

앞의 13.7포인트를 만든 그 하네스는 gpt-5.2-codex라는 모델에 맞춰 다듬은 것이었습니다. 그런데 똑같은 하네스에 Claude Opus 4.6을 올리면 점수가 66.5퍼센트가 아니라 59.6퍼센트로 내려갑니다.

같은 하네스인데 모델을 갈아 끼우니 성적이 달라진 겁니다. 이게 뜻하는 바는 분명합니다. 하네스는 한 번 잘 만들어 놓고 모델만 최신으로 바꾸면 되는 물건이 아닙니다. 모델이 바뀌면 하네스도 그 모델에 맞게 다시 손봐야 합니다.

이건 꽤 반직관적입니다. 보통은 ‘더 좋은 모델로 갈아타면 다 해결된다’고 기대하니까요. 실제로는 모델을 바꾸는 순간, 그 모델에 맞는 하네스 모델별 최적화라는 숙제가 새로 생깁니다.

참고로 이 방향을 뒷받침하는 관찰이 하나 더 있습니다. 요즘 주요 모델들의 기본 능력은 서로 꽤 비슷해져서 차이는 오히려 하네스에서 난다는 지적입니다(Sebastian Raschka). 하네스만 바꿔 같은 시험대에서 6배 성능 차를 봤다는 연구도 있는데, 이 6배 수치는 아직 정식 심사(peer-review)를 거치지 않은 프리프린트라는 점은 감안해서 읽어야 합니다.

정리 체크리스트

마지막으로, 이 숫자들을 인용할 때 헷갈리지 않도록 정리해 둡니다. 아래는 모두 공개 자료를 읽고 제가 구분한 것이지, 직접 실험한 값이 아닙니다.

13.7포인트(52.8→66.5)는 gpt-5.2-codex용 하네스를 다듬은 결과다. 리즈닝 샌드위치와 미들웨어 두 개가 실제 기여원이다.
33위에서 5위는 Opus 4.6이 하네스에 따라 순위가 뒤집힌, 완전히 다른 실험이다. 두 숫자를 한 사건처럼 묶지 않는다.
같은 하네스도 모델이 바뀌면 성적이 달라진다(66.5%에서 59.6%). 하네스는 모델별로 다시 튜닝해야 한다.

제가 도구를 만들며 붙든 교훈도 여기 있습니다. 모델을 최신으로 바꾸는 일과, 그 모델에 맞는 환경을 다시 설계하는 일은 별개의 숙제입니다. 숫자 하나를 정확히 뜯어보는 것만으로도, 다음에 무엇을 해야 하는지가 조금 더 또렷해졌습니다.

법률 AI Harvey는 왜 110억 달러가 됐을까, 버티컬 AI와 도메인 특화 하네스

logicallabs — Tue, 28 Jul 2026 09:35:12 +0900

같은 하네스 기술인데, 법률 한 분야에서 110억 달러가 됐습니다

먼저 밝혀 둡니다. 아래 이야기는 제가 직접 겪은 일이 아닙니다. 공개된 뉴스와 시장 분석 자료를 찾아 읽고 정리한 것입니다.

Harvey 관계자를 만난 적도, 내부 사정을 들은 적도 없습니다. 시장을 읽고 제가 방향을 정하는 근거로 삼은 자료입니다.

Harvey라는 회사가 있습니다

Harvey는 2022년에 세워진 법률 AI 회사입니다. 창업자는 전직 변호사(Winston Weinberg)와 전직 DeepMind 연구자(Gabe Pereyra) 두 사람입니다.

2026년 3월에 발표된 투자 라운드 기준으로, 이 회사의 몸값(밸류에이션)은 110억 달러로 매겨졌습니다. 이번 라운드에서만 2억 달러를 새로 받았고(GIC와 Sequoia가 공동 주도), 지금까지 모은 돈은 10억 달러가 넘습니다.

투자자 명단에는 Sequoia, a16z, Kleiner Perkins, OpenAI, Coatue, GIC 같은 이름이 있습니다.

숫자로 정리하면 이렇습니다. (아래는 모두 2026년 3월 라운드 발표 시점 기준이며, ARR만 2025년 말 기준입니다.)

항목	값
밸류에이션	110억 달러
신규 펀딩	2억 달러 (GIC·Sequoia 공동 주도)
누적 펀딩	10억 달러 이상
사용 변호사	100,000명 이상
고객사	1,300곳 이상 (60개국 이상)
ARR(연간 반복 매출)	1억 9천만 달러 (2025년 말)
운영 중인 커스텀 에이전트	25,000개 이상

하는 일은 계약서 분석, 실사(듀딜리전스), 규정 준수(컴플라이언스), 소송 업무 흐름 같은 법률 실무입니다. 가격은 변호사 한 명당 월 1,000~1,200달러 선이고, 최소 20~50석을 12개월 단위로 계약하는 구조라고 알려져 있습니다.

그런데 기술만 놓고 보면 특별하지 않습니다

제가 흥미롭게 본 지점은 여기입니다.

Harvey가 쓰는 근본 기술은, 요즘 AI 에이전트를 만드는 회사라면 대부분 쓰는 것과 크게 다르지 않습니다. 좋은 모델을 고르고, 그 주변을 잘 설계해서, 실제 업무를 해내게 만드는 방식입니다.

저는 지난 글에서 이 ‘모델 주변 설계’를 하네스(harness)라고 불렀습니다. 모델이 상향평준화될수록 차이는 하네스에서 난다는 이야기였습니다.

여기서 자연스러운 질문이 생깁니다. 같은 하네스 기술인데, 왜 법률이라는 한 분야에서만 이런 규모가 나왔을까요.

코딩은 레드오션, 버티컬은 아직 블루오션

제가 하네스 분야를 조사하면서 그린 시장 지도는 이렇습니다.

AI 에이전트가 가장 먼저, 가장 치열하게 붙은 곳은 코딩입니다. 개발자를 돕는 코딩 에이전트는 큰 회사부터 작은 팀까지 이미 다 뛰어들어, 과포화된 레드오션에 가깝습니다.

반대로 법률, 금융, 의료, 제조 같은 특정 산업(버티컬)에 특화된 AI는 코딩만큼 붐비지 않습니다. 다만 버티컬이라고 다 같은 단계는 아닙니다. 법률은 이미 Harvey라는 대표주자가 자리를 잡아, 버티컬 중에서도 가장 성숙한 축에 듭니다.

반면 그 안에서도 특허처럼 아직 대표주자가 없는 좁은 갈래(서브버티컬)는 빠르게 크고 있는 빈 땅에 가깝습니다.

왜 이 차이가 날까요. 코딩은 문제의 성격이 산업을 딱히 가리지 않습니다. 코드는 어디서든 코드입니다.

그래서 범용 도구 하나로 넓게 덮을 수 있고, 그만큼 자본이 큰 기업이 밀어붙이기 좋은 땅입니다.

법률은 다릅니다. 계약서 한 줄을 어떻게 읽어야 하는지, 어떤 실수가 나중에 큰 문제가 되는지는 그 분야를 아는 사람만 압니다. 범용 모델에 그냥 물어봐서 나오는 답으로는 부족합니다.

도메인 하네스는 왜 쉽게 무너지지 않나

여기서 한 가지 반론이 있을 수 있습니다. “모델이 더 세지면 이런 특화는 다 필요 없어지지 않나?”

제가 조사하며 얻은 결론은 그 반대였습니다.

모델이 강해져도 하네스는 사라지지 않습니다. 대신 자리를 옮깁니다. 단순한 프롬프트 요령에서 시작해, 실행 환경과 그 분야의 지식, 결과를 걸러내는 품질 게이트 쪽으로 이동합니다.

그리고 뒤쪽으로 갈수록, 그 분야를 실제로 아는 사람이 아니면 만들기 어렵습니다.

법률로 치면 어떤 자료를 근거로 봐야 하는지, 어떤 답은 내보내면 안 되는지, 결과가 맞는지 어떻게 검사하는지 같은 것들입니다. 이건 모델의 능력이 아니라 도메인의 지식입니다. 모델이 아무리 좋아져도 이 층은 그 도메인에 붙어 남습니다.

그래서 저는 도메인 특화 하네스를 쉽게 따라잡히지 않는 해자로 봅니다. 범용 모델의 발전이 오히려 이 층의 값어치를 키운다고 봅니다.

그래서 저는 좁고 깊은 쪽을 택했습니다

이 시장 지도를 그리고 나서, 저는 방향을 정했습니다.

범용은 거대 기업의 몫입니다. 자본과 인력이 훨씬 앞선 곳이 넓은 땅을 가져갑니다.

저는 그 싸움에 낄 처지가 아닙니다. 혼자, 이제 막 시작한 초기 단계니까요.

대신 좁고 깊은 도메인은 다른 논리가 작동합니다. 그 도메인을 아는 사람이 만든 하네스가 이깁니다. Harvey가 법률에서 보여준 게 그 증거라고 저는 읽었습니다.

오해를 막기 위해 덧붙이면, 저는 Harvey와 규모나 성과를 견줄 처지가 전혀 아닙니다. 방향이 같다는 이야기까지입니다.

그래서 제가 붙든 도메인은 특허입니다. 특허 명세서라는, 좁지만 깊은 문서 하나를 다루는 도구를 만들고 있습니다(Logical Patents). 매일 여러 건의 명세서를 다루는 변리사와 특허사무소가 쓸 것을 염두에 둡니다.

넓게 가는 대신, 이 한 분야의 하네스를 깊게 파는 쪽입니다.

그 하네스가 구체적으로 무엇인지, ‘모델보다 주변이 성능을 가른다’는 이야기는 지난 글에 정리해 두었습니다.

같은 기술이라도 어디에 얹느냐에 따라 값이 완전히 달라진다는 것. 시장을 읽으며 제가 가장 오래 붙들었던 생각입니다.