지시 준수·장기 맥락·자체 계획 능력이 모델 안으로 들어오면서, 모델 바깥에 세워 둔 통제 장치는 도움이 아니라 비용이 되었다. 무엇을 지우고 무엇을 남겨야 하는지 가르는 기준을 정리한다.
지난 2년 동안 대규모 언어 모델(LLM, Large Language Model)을 업무에 붙여 온 팀들은 대체로 같은 경로를 밟았다. 모델의 출력이 미덥지 않으니 모델 바깥에 통제 장치를 세운다. 순서를 강제하고, 형식을 못박고, 금지어를 나열하고, 단계마다 검사기를 붙인다. 이 장치 일체를 흔히 하네스(harness)라 부른다. 그리고 2026년 중반의 모델 세대에서, 이 장치의 상당 부분은 성능을 지키는 울타리가 아니라 성능을 깎는 마찰로 바뀌었다.
이 글의 논지는 하네스를 만들지 말라는 것이 아니다. 하네스를 세우는 자리가 이동했다는 것이다. 실행을 통제하던 자리에서는 걷어내야 하고, 무엇을 왜 만들지를 고정하는 자리에서는 오히려 더 촘촘하게 세워야 한다. 앞의 것을 실행 하네스, 뒤의 것을 기획 하네스라 부르기로 한다.
하네스는 본래 마구(馬具)를 뜻한다. 굴레와 고삐, 안장처럼 말이 아무 데로나 가지 못하게 잡아 주는 장비다. 인공지능 작업에서도 뜻은 같다. 모델이 말이라면 하네스는 그 말에 채우는 장비다. 이 순서로만 진행하라, 이 단계가 끝나면 반드시 검사를 받아라, 정해진 형식으로만 답하라, 벗어나면 처음부터 다시 하라.
2025년과 2026년 초의 모델을 떠올리면 이 장치들이 왜 필요했는지가 분명해진다. 지시를 다섯 개 주면 두세 개만 지켰다. 긴 문서를 넣으면 중간을 잊었다. 없는 사실을 확신에 찬 어조로 지어냈다. JSON으로 달라고 하면 앞뒤에 인사말을 붙였다. 그래서 지시를 잘게 쪼개 한 번에 하나씩 주고, 긴 문서는 조각내어 순서대로 밀어 넣고, 답변은 정해진 틀에 억지로 담고, 마지막에 검사기를 달았다. 그 시절의 모델 수준에서는 합리적인 대응이었다.
하네스는 모델을 믿지 못해서 만드는 장치다. 그러므로 모든 하네스는 그것이 만들어진 시점의 ‘모델 약점 지도’다.
지도는 지형이 바뀌면 쓸모를 잃는다. 문제는 쓸모를 잃은 지도가 저절로 사라지지 않는다는 점이다. 규칙 파일에, 파이프라인 설정에, 프레임워크 기본값에 남아서 계속 작동한다. 그리고 지금 세대의 모델은 지시를 워낙 성실하게 따르기 때문에, 낡은 규칙일수록 더 충실하게 지켜진다.
2026년 6월과 7월에 프런티어 모델이 연달아 공개되면서 전제가 한 번에 바뀌었다.
Anthropic은 6월 9일 Claude Fable 5를 공개했다. Opus 위에 새로 놓인 Mythos 계열의 일반 공개 모델로, 100만 토큰 입력 맥락과 12만 8000 토큰 출력, 상시 적응형 사고를 갖췄다. 가격은 100만 토큰당 입력 10달러·출력 50달러로 직전 Opus 계열의 두 배였다. 이 모델은 사이버보안·생물학 등 특정 영역의 요청을 감지하면 자동으로 하위 모델로 응답을 넘기는 안전 분류기를 달고 나왔고, 공개 사흘 뒤 미국 정부의 수출통제 지시로 접근이 중단되었다가 6월 말 복구되는 소동을 겪었다. 7월 24일에는 Claude Opus 5가 나왔다. Anthropic은 이 모델을 Fable 5에 근접한 성능을 절반 가격에 제공하는 상시 사용용 모델로 소개하면서, 노력 수준을 낮음·보통·높음으로 조절하는 기능과 함께 모델이 스스로 자기 작업을 검증하고 오류에서 복구하므로 사람의 개입이 덜 필요하다는 점을 전면에 내세웠다.
OpenAI는 7월 9일 GPT-5.6 계열을 일반 공개했다. 최상위 Sol, 일상 업무용 Terra, 저비용 Luna의 세 갈래이며, 회사는 Sol이 에이전트형 코딩 작업에서 이전 세대보다 토큰 효율이 54% 높다고 밝혔다. 주목할 것은 Sol의 최고 성능 설정인 ‘ultra’ 모드다. 복수의 에이전트를 병렬 작업 흐름으로 조율해 복잡한 과제를 처리하는 기능인데, 이는 그동안 사용자가 모델 바깥에서 손으로 짜 오던 오케스트레이션이 모델 제공자 쪽 기본 기능으로 흡수되었다는 뜻이다.
지시 준수. 예전에는 지시 다섯 개 중 세 개를 지켰다면 지금은 열다섯 개를 줘도 대체로 지킨다. 실행 하네스의 절반가량이 ‘지시를 지키게 만드는 장치’였으므로, 그 절반이 통째로 무의미해졌다.
장기 맥락. 100만 토큰 규모의 입력이 표준이 되면서, 문서를 조각내 순서대로 주입하던 파이프라인의 존재 이유가 대부분 사라졌다.
자체 계획. 과제를 주면 스스로 단계를 나눈다. 사람이 짜 넣은 순서보다 나은 순서를 만드는 경우가 흔하다.
불확실성 표시. 모르는 것을 모른다고 말하는 빈도가 크게 늘었다. 사실 확인 장치를 겹겹이 두던 이유의 상당 부분이 여기서 해소된다.
이 네 가지가 겹치면 결과는 하나다. 바깥에 세워 둔 울타리 대부분이 허공에 서게 된다. 말이 알아서 길을 찾는데 고삐를 그대로 쥐고 있으면, 말은 느려진다.
쓰는 모델에 따라 먼저 지울 대상도 갈린다. 장기 작업 유지력이 강해진 모델에서는 중간중간 앞의 내용을 다시 넣어 주던 맥락 재주입 장치가 헛일이 된다. 문체와 톤을 잡는 능력이 붙은 모델에서는 예시 스무 개를 붙여 주던 방식이 맥락만 잡아먹는다. 오히려 예시가 많으면 모델이 새로운 상황에서도 그 예시 문장을 억지로 흉내 내기 때문에, 적게 주는 편이 더 자유롭고 정확하다. 도구 사용 판단이 좋아진 모델에서는 ‘질문에 최신이라는 단어가 있으면 검색하라’ 같은 규칙을 지우는 편이 낫다. 그런 규칙은 언제나 예외에서 터진다. 공통으로는, 순서를 강제하는 장치가 어떤 모델을 쓰든 가장 먼저 지울 후보다.
필요 없어진 장치라면 그냥 안 쓰면 되지 않느냐는 반문이 자연스럽다. 그렇지 않다. 쓰지 않는 것과 켜져 있는 것은 완전히 다르다. 켜져 있는 낡은 하네스는 가만히 있지 않고 적극적으로 개입한다. 대표적인 네 가지를 본다.
한 번에 시키면 못 하니까 잘게 쪼개 순서대로 호출하는 방식이다. 먼저 요약하고, 요약본으로 분류하고, 분류 결과로 초안을 쓰고, 초안을 다듬는다. 네 번의 호출이 필요하다. 20년 경력의 요리사에게 양파부터 썰어 보이라고 단계마다 확인하는 것과 같다. 이때 세 가지가 망가진다. 호출 수만큼 느려지고, 단계를 넘길 때마다 정보가 깎이고, 모델이 찾아냈을 더 나은 경로가 막힌다. 같은 과제를 한 번에 통째로 맡겼을 때 속도·품질·비용 모두에서 나은 결과가 나오는 경우가 흔하다.
규칙 파일은 모델에게 미리 주는 사규 같은 것이다. 우리 팀은 이렇게 일한다, 이런 표현은 쓰지 마라, 이 형식을 지켜라. 프로젝트 지침란에 넣어 두는 지시도 같은 성격이다. 이 장치 자체는 지금도 유효하다. 문제는 쌓이는 방식에 있다.
규칙은 대개 사고 뒤에 추가된다. 모델이 실수하면 규칙을 한 줄 더한다. 한 달 뒤 다른 실수를 하면 또 한 줄 더한다. 1년이면 200줄이 된다. 그중 절반은 이제 일어나지 않는 실수를 막는 규칙이다. 아무도 팩스를 쓰지 않는데 사규에는 팩스 표지 규정이 남아 있는 상태와 같다.
예전에는 규칙을 지키지 않아서 문제였다. 지금은 낡은 규칙을 너무 잘 지켜서 문제다.
이 역전이 핵심이다. 지금 세대 모델은 지시 준수도가 높기 때문에, 3년 전 짧은 답변만 내놓던 모델을 상대로 만든 ‘짧게 쓰라’는 규칙 하나 때문에 자세히 써야 할 자리에서 답을 잘라 낸다. 정리 방법은 단순하다. 한 줄씩 읽으면서 왜 넣었는지 묻고, 기억나지 않으면 지운다. 과거 모델의 실수를 막으려던 것이면 지운다. 우리 팀만의 판단 기준이면 남긴다.
기획자·작성자·검토자·관리자 역할을 각각의 에이전트에 나눠 팀처럼 굴리는 구조다. 유행한 이유는 명확하다. 모델 하나가 여러 역할을 동시에 못 했기 때문이다. 쓰면서 검토하면 자기 글에 후해졌고, 계획을 세우면서 실행하면 계획을 잊었다. 지금은 모델 하나가 계획하고, 쓰고, 자기 결과를 비판하고, 고친다. 필요하면 스스로 하위 작업을 분기한다. 바깥에서 그린 조직도가 이미 안쪽에 들어와 있는 셈이고, GPT-5.6의 ultra 설정은 그 내재화를 제품 기능으로 공식화한 사례다.
바깥의 조직도를 남겨 두면 비용이 곱으로 붙는다. 에이전트끼리 주고받는 대화가 전부 토큰이고, 같은 맥락이 참여자 수만큼 반복 입력된다. Anthropic이 자사 멀티 에이전트 연구 시스템을 계측한 바에 따르면, 에이전트형 작업은 일반 대화 대비 약 4배, 멀티 에이전트 구성은 약 15배의 토큰을 썼다. 같은 계측에서 BrowseComp 성능 변량의 80%가 토큰 사용량으로 설명되었다는 점도 함께 봐야 한다. 성능이 오르지 않는 것이 아니라, 오르는 만큼 정직하게 비싸다는 뜻이다.
비용보다 덜 보이는 손실은 정보 감쇠다. 기획자가 이해한 바를 100이라 하면 작성자에게 넘어갈 때 80, 검토자에게 넘어갈 때 60이 된다. 전언 게임과 구조가 같다. 하나의 맥락 안에서 처리하면 그 100이 그대로 남는다. 탐색 과정의 잡음이 본 작업의 맥락을 오염시키는 상황처럼 분리가 실익을 내는 자리는 여전히 있지만, 기본값으로 에이전트를 여러 개 붙이는 방식은 대체로 손해다.
모델의 답을 다시 모델에게 보여 주고 검사시키는 방식이다. 문제가 있다고 하면 다시 시키고, 괜찮다고 할 때까지 돌린다. 옛 모델이 자기 답을 되짚지 않았기 때문에 억지로 되짚게 만든 장치였다. 지금 모델은 답을 내놓기 전에 내부에서 이미 검토한다. 그 위에 외부 검사를 얹으면 세 가지 문제가 생긴다.
첫째, 멀쩡한 답이 나빠진다. ‘검사해 보라’는 지시 자체가 ‘문제가 있을 것’이라는 신호로 작동하기 때문에, 모델은 무엇이든 찾아내려 한다. 외부 정답 신호 없이 스스로 답을 고치게 하는 이른바 내재적 자기 교정에 대해서는 실증 연구가 축적되어 있다. 대표적인 연구에서 GSM8K 수학 추론 정확도는 초기 95.5%에서 1회 자기 교정 뒤 91.5%, 2회 뒤 89.0%로 내려갔다. 반복할수록 뾰족한 것이 깎여 나가는 현상은 문장 품질에서도 같은 방향으로 나타난다.
둘째, 검사 한 번이 호출 한 번이다. 세 번 돌면 비용은 네 배다. 셋째, 종료 조건이 없다. 만족할 때까지 돌리도록 걸어 두면 끝나지 않는 경우가 생긴다.
다만 예외가 분명하다. 표에 빈칸이 있는지, 필수 필드가 채워졌는지, 코드가 컴파일되는지처럼 외부에서 참·거짓을 판정할 수 있는 검사는 여전히 유효하다. 자기 판단만으로 ‘잘됐는지’를 묻는 흐릿한 검사가 손해다. 판정 기준이 모델 밖에 있는가, 이것이 유일한 분기점이다.
네 장치의 공통점은 하나다. 모두 모델이 못 하던 일을 대신해 주던 손이었다. 모델이 그 일을 하게 된 순간, 대신해 주던 손은 방해하는 손이 된다.
직접 만든 규칙보다 더 다루기 까다로운 것은 남이 만든 프레임워크다. 에이전트 프레임워크, 평가 자동화 도구, 검색 파이프라인은 각각 데모에서 훌륭해 보이지만, 붙이는 순간 세 종류의 청구서가 따라온다.
모델이 읽는 것은 사용자의 질문만이 아니다. 프레임워크가 앞뒤로 붙이는 역할 설명, 도구 목록, 출력 형식 지시, 예시, 안전 문구가 함께 들어간다. 실제로 전송 내용을 열어 보면 사용자가 쓴 문장이 전체의 1%에도 못 미치는 경우가 드물지 않다. 두 장짜리 요청서가 100쪽 서류 뭉치 맨 뒤에 끼어 있는 형국이다.
이것이 단순한 낭비에 그치지 않는 이유는 어텐션 예산 때문이다. 맥락 창의 토큰 수가 늘수록 모델이 그 안의 정보를 정확히 회수하는 능력이 떨어지는 현상을 맥락 부패(context rot)라 부르며, 정도의 차이는 있어도 모든 모델에서 관찰된다. 맥락은 무한한 저장소가 아니라 수확 체감이 있는 유한 자원이다. 넣는 토큰마다 예산이 깎인다.
더 나쁜 것은 충돌이다. 프레임워크는 간결하게 답하라고 넣어 두었는데 사용자는 자세히 설명해 달라고 한다. 모델은 둘을 다 지키려다 어중간한 결과를 낸다. 사용자는 이유를 알 수 없다. 자기가 쓰지 않은 지시가 자기 결과물을 망치는데, 그 지시를 볼 수 없기 때문이다.
프레임워크를 붙이는 순간 그 프로젝트의 일정에 묶인다. 새 모델은 두세 달에 한 번씩 나오고, 그때마다 프레임워크가 따라와야 한다. 무보수 유지보수에 의존하는 프로젝트는 대응이 늦거나, 대응하더라도 검증 없이 얹히는 경우가 많다. 별 수를 늘리기 위한 얕은 구현도 적지 않다. 실무에서 오래 쓸 만한 것은 손에 꼽는다는 평가가 나오는 배경이다.
세 번째가 가장 심각하다. 결과가 이상한데 왜 이상한지 찾을 수 없다. 질문에서 최종 답까지 가는 경로에 남의 코드가 열 겹쯤 끼어 있기 때문이다. 프레임워크가 질문을 변형했을 수도 있고, 중간 단계에서 정보가 잘렸을 수도 있고, 검증기가 멀쩡한 답을 반려했을 수도 있고, 캐시가 옛 답을 돌려줬을 수도 있다. 원인을 짚으려면 남의 프로젝트 코드를 읽어야 한다. 그러자고 인공지능을 쓰는 것은 아니다.
문제는 프레임워크가 오류를 만든다는 것이 아니다. 오류를 보이지 않게 만든다는 것이다.
대화 내용을 저장해 두었다가 관련 있는 것을 꺼내 넣어 주는 기억 도구는 아이디어가 좋다. 문제는 무엇을 꺼내 오느냐에 있다. 이런 도구는 대개 의미가 비슷한 것을 찾아온다. 그런데 비슷한 것이 관련 있는 것은 아니다. 회의에서 내년 인력 예산을 논의하는데 작년 회식비 정산 서류를 꺼내 오는 일이 하루에 열 번씩 일어난다. 그렇게 붙은 엉뚱한 맥락을 모델은 중요한 자료로 받아들인다. 사용자가 붙였기 때문이다. 그리고 사용자는 그것이 붙은 줄 모른다.
검색 증강 생성(RAG, Retrieval-Augmented Generation)도 구조가 같다. 문서를 잘게 잘라 저장해 두고 질문이 오면 조각 몇 개를 찾아 넣는다. 문서 전체를 넣을 수 없던 시절에는 필수였다. 조각내기의 대가는 조각 사이의 연결이 사라진다는 것이다. 계약서 제3조를 꺼내 왔는데 ‘제5조의 경우는 예외로 한다’는 단서가 제5조에 있다면, 모델은 그 예외를 보지 못한 채 답한다. 틀린 답인데 근거 조항까지 인용하며 확신에 차 있다. 이것이 실제로 위험한 지점이다.
그렇지는 않다. 맥락 창이 커진 것과 긴 맥락에서 추론이 잘되는 것은 다른 문제다. 필요한 정보를 완벽하게 회수하더라도 입력 길이 자체가 성능을 떨어뜨린다는 보고가 있고, 자동 버그 수정처럼 긴 맥락 추론이 요구되는 과제에서 한계가 관찰된다는 연구도 나와 있다.
판단 기준은 문서 크기다. 감당 못 할 만큼 크면 검색 장치는 여전히 필요하다. 그냥 넣어도 되는 크기인데 습관적으로 조각내고 있다면, 그것은 지금 성능을 깎고 있는 것이다. 한 번 재 보는 것 말고는 확인할 방법이 없다.
하네스가 모델을 믿지 못해서 만드는 장치라면, 질문은 하나로 좁혀진다. 지금도 믿을 수 없는 영역이 어디인가.
실행은 믿을 만해졌다. 계획 수립도 상당히 믿을 만하다. 형식 준수는 믿는다. 사실 확인도 크게 나아졌다. 남는 것은 무엇을 왜 만들지를 정하는 일이다. 이것이 남은 이유는 모델이 못 해서가 아니다. 모델이 그 결정의 주체가 아니기 때문이다. 이 차이가 결정적이다. 실행 하네스는 모델이 좋아지면 사라지지만, 기획 하네스는 모델이 아무리 좋아져도 사라지지 않는다. 성능 문제가 아니라 입장 문제이기 때문이다.
아무리 뛰어난 목수도 의뢰인 어머니의 무릎 상태는 모른다. 모델이 아무리 똑똑해져도 사용자 머릿속에만 있는 것은 알 수 없고, 나쁜 결과물의 상당수는 모델이 부족해서가 아니라 이것을 주지 않아서 나온다. 기획 하네스는 세 조각으로 이뤄진다.
이것이 하네스인 이유는 흔들리지 못하게 고정하는 장치이기 때문이다. 대화가 길어지면 목적이 슬금슬금 옮겨 간다. 처음에는 결제 중도 이탈을 줄이자는 문제였는데 30분 뒤에는 결제 화면을 예쁘게 만들자가 되어 있다. 모델이 잘못한 것이 아니다. 매 순간 합리적으로 답했을 뿐이고, 합리적인 답을 수십 번 이으면 처음과 다른 곳에 도착한다.
문제 정의는 이렇게 쓴다. 누가, 언제, 무엇을 못 해서, 무엇을 포기하는가. ‘결제 경험을 개선한다’는 문제 정의가 아니라 소원이다. ‘모바일에서 처음 구매하는 사용자가 카드 정보 입력 화면에서 할인코드 입력란을 찾지 못해 장바구니를 두고 나간다’가 문제 정의다. 이렇게 쓰면 모델이 내놓는 모든 제안을 여기에 대 볼 수 있다. 아무리 훌륭해 보여도 그 사용자가 입력란을 찾는 데 도움이 되지 않으면 버린다. 이 한 문단이 규칙 200줄보다 결과물을 더 많이 바꾼다.
가장 저평가된 조각이다. 모든 결정에는 맞바꿈이 있다. 빠르게 하면 거칠어지고, 꼼꼼히 하면 느려진다. 모델은 그 축의 어디로 가야 할지 모르고, 모르면 중간을 고른다. 적당히 빠르고 적당히 꼼꼼한 결과가 나온다. 그런데 필요한 것이 중간이 아닐 수 있다.
기준은 이유와 함께 쓴다. ‘속도와 정확도 중에서는 정확도. 이 데이터가 회계로 들어가 틀리면 되돌리기 어렵기 때문이다.’ ‘기능 추가와 단순함 중에서는 단순함. 사용자 평균 연령이 높아 화면이 복잡하면 쓰지 않기 때문이다.’ 이유가 붙어 있으면 모델이 응용한다. 지정한 적 없는 새로운 갈림길에서도 같은 이유로 같은 방향을 고른다. 결론만 주면 그 상황에서만 지키고 끝난다. 여기에 절대 넘으면 안 되는 선, 즉 제약을 함께 적는다.
이미 정한 것과 그 이유를 적어 두는 일이다. 대화가 끝나면 모델은 잊는다. 기억 기능이 있어도 충분하지 않다. 그런데 프로젝트는 백지가 아니다. 지난달에 세 가지 방식을 놓고 고민하다 하나를 골랐고, 나머지 둘을 버린 이유가 있었다. 적어 두지 않으면 다음 달에 버린 방식이 다시 제안된다. 그리고 이 일은 반복된다.
기억력이 하루짜리인 유능한 컨설턴트를 상상하면 된다. 실력은 뛰어나지만 매일 아침 처음부터 시작한다. 해법은 노트다. 이 컨설턴트는 기억하지 못하지만 읽을 줄은 안다. 형식은 이미 소프트웨어 업계에 있다. 2011년 마이클 나이가드가 제안한 아키텍처 결정 기록(ADR, Architecture Decision Record)은 제목·상태·맥락·결정·결과의 다섯 항목으로 된 짧은 텍스트 파일이며, 한 번 채택된 결정은 수정하지 않고 새 기록으로 대체한다는 규칙을 둔다. 날짜, 무엇을 정했는가, 무엇을 대신 버렸는가, 왜 그랬는가. 네 줄이면 충분하다.
실행 하네스가 그렇게 사라졌으니 같은 일이 반복되리라 보는 것은 자연스러운 추론이다. 그러나 성격이 다르다. 세 가지 이유가 있다.
첫째, 능력 문제가 아니라 정보 소유 문제다. 실행 하네스가 사라진 것은 모델이 그 능력을 갖게 되었기 때문이다. 능력은 좋아지면 넘어온다. 기획은 능력이 아니라 정보이고, 그것도 공개된 정보가 아니라 사람 머릿속에만 있는 정보다. 회사가 작년에 그 사업을 왜 접었는지, 어떤 고객이 실제로 돈을 내는지, 결재권자가 무엇을 가장 싫어하는지는 모델이 커진다고 알아낼 수 있는 것이 아니다. 어디에도 적혀 있지 않기 때문이다.
둘째, 선호는 성능으로 풀리지 않는다. 두 안이 모두 훌륭한데 하나는 안전하고 하나는 과감하다면, 무엇을 고를지는 더 똑똑해진다고 답이 나오는 문제가 아니다. 입장이 정해져야 답이 나오고, 그 입장은 사람의 것이다. 모델이 대신 골라 줄 수는 있지만 원한 것이 아니면 결국 다시 하게 된다.
셋째, 책임은 위임되지 않는다. 결과가 잘못되었을 때 책임지는 쪽은 사람이다. 책임지는 쪽이 방향을 정하는 것이 순리다.
구조로 보면 이렇다. 예전에는 사람이 하네스를 만들고, 하네스가 모델을 조종하고, 모델이 결과를 냈다. 사람은 조종 장치의 정비공이었다. 지금은 사람이 기획을 정하고, 그 기획을 모델에게 그대로 주고, 모델이 실행한다. 사람은 의뢰인이다. 바뀐 것은 시간의 행선지다. 정비공일 때 시간의 70%가 장치를 고치는 데 갔다면, 의뢰인일 때는 무엇을 만들지 정하는 데 간다. 뒤의 것이 더 어렵다.
한 번에 전부 지우는 것은 권할 만하지 않다. 순서가 있다.
혼자 쓴다면 여기까지로 족하다. 팀이라면 어려운 쪽은 기술이 아니라 사람이다. 그 하네스를 누군가 밤새워 만들었고, 발표했고, 칭찬받았다. 지우자는 말은 그 사람의 일을 부정하는 것처럼 들린다. 그래서 표현이 중요하다. 틀렸다가 아니라 끝났다고 말한다. 만든 사람에게 실험을 맡기고, 지운 것을 성과로 기록하고, 한 사람이 먼저 해 본 뒤 확산한다.
지금 쓰고 있는 하네스 가운데 가장 오래된 것은 무엇이고, 언제 왜 만들었는가. 이 두 질문에 바로 답할 수 없다면, 그 장치는 이미 정비 대상이다. 여기 정리한 것은 정답이 아니라 재 보는 방법에 가깝다. 팀마다 사정이 다르고, 무엇을 지울지는 결국 각자의 계측으로 정해진다.