모두가 "AI 엔지니어링 (AI engineering)"을 지칭하는 새로운 용어를 쫓고 있습니다. 하지만 그 용어가 넘어야 할 기준선은 실제로 움직인 적이 없습니다.

AI의 "엔지니어링"에는 지난 약 3년 동안 세 가지 이름이 있었습니다.

처음에는 프롬프트 엔지니어링 (prompt engineering)이었습니다. 마법의 문장을 쓰는 법을 배우는 것이었죠. 그러다 2025년 중반쯤, 모두가 컨텍스트 엔지니어링 (context engineering)으로 전환했습니다. 문구에 집착하는 것을 멈추고, 컨텍스트 윈도우 (context window)를 적절한 내용으로 채우기 시작한 것입니다. 이제 2026년 초, 용어는 하네스 엔지니어링 (harness engineering)이 되었습니다. 모델을 감싸는 계층인 도구, 메모리, 상태, 오류 복구, 검증, 권한 등을 의미합니다.

용어가 바뀔 때마다, 많은 사람이 뒤처졌다는 공포에 빠집니다. 저는 더 이상 이에 반응하지 않습니다. 왜냐하면 더 많이 구축할수록 한 가지 사실이 명확해지기 때문입니다: 용어는 계속 바뀌지만, 그 밑에 있는 본질은 바뀌지 않습니다.

그 밑에 있는 본질은 이것입니다. 도구화를 무엇이라 부르든, 당신은 항상 동일한 간극을 건너고 있습니다. 바로 "AI가 실행 가능한 무언가를 생성했다"에서 "내 이름을 이 코드에 걸겠다. 만약 운영 환경 (production)에서 문제가 발생한다면, 그것은 내 책임이다"로 넘어가는 간극 말입니다. 그 간극을 건너는 것이 업무의 전부입니다. 새로운 용어들은 그저 업계가 동일한 횡단 과정을 반복해서 이름을 바꾸고 있는 것뿐입니다.

그러니 어휘에 대해 논쟁하는 대신, 저희가 그 간극을 건너기 위해 사용하는 실제 규칙 네 가지를 보여드리겠습니다. 그중 영리한 것은 거의 없습니다. 그것이 바로 핵심입니다.

규칙 1: 종료 지점 없이는 시작도 없다

시작하기 전에 "완료"가 어떤 모습인지 말할 수 없다면, 우리는 시작하지 않습니다. 그런 다음 각 조각이 스스로 검증될 수 있을 만큼 작아질 때까지 작업을 계속해서 쪼갭니다. 그리고 커밋 (commit) 시점에 후크 (hook)가 자동으로 실행되어 정보성 확인 (informedness check) — 우리는 임계값 $\tau$ 라고 부릅니다 — 을 수행합니다. 이는 사람이 해당 커밋의 모든 필요한 변경 사항을 실제로 이해하고 있는지 확인하는 과정입니다. 모든 줄이 아니라, '필요한' 변경 사항입니다. 우리는 누구에게도 AI의 코드를 한 줄씩 다시 읽게 하지 않습니다. 그것은 도구를 불신하는 것이며 확장성 (scale)도 없습니다. 핵심은 변경 사항을 사람이 소유해야 할 하나의 추상화 계층 (layer of abstraction)으로 끌어올리고, 그 계층에서 진정으로 명확하게 만드는 것입니다.

규칙 2: 영향 범위(blast radius)에 따라 임계값이 변한다

위험도가 낮고 쉽게 되돌릴 수 있는 변경 사항에는 가벼운 조치를 취합니다. 빠른 롤백(rollback)에 의존하며 그대로 진행하도록 둡니다. 하지만 데이터, 결제, 권한, 마이그레이션(migration)과 같이 되돌릴 수 없거나 영향력이 큰 요소가 등장하는 순간, 임계값은 천장까지 높아집니다. 더 높은 수준의 정보 숙지(informedness)가 요구되며, 다른 베이스(base)를 가진 두 번째 모델을 통해 교차 검증(cross-check)을 수행합니다. 여기서 속도와 안전은 서로 다른 두 개의 설정이 아닙니다. 그것들은 동일한 노브(knob)의 양 끝단이며, 우리는 이를 완전히 "느리게" 혹은 완전히 "도박"으로 돌리는 대신, 결과에 따라 조절합니다.

규칙 3, 가장 어려운 것: 검증은 독립적이어야 한다

독립적이라는 것은 검증하는 주체가 작성한 주체와 달라야 함을 의미합니다. 우리는 두 개의 계층을 쌓습니다. 첫 번째는 당신입니다. 하지만 이는 당신이 해당 부분에 대해 진정으로 충분한 정보를 알고 있을 때만 해당하며, 이는 정확히 앞선 규칙에서 언급한 임계값과 일치합니다. 변경 사항을 실제로 이해하고 있는 인간이 첫 번째 독립적 검증자입니다. 두 번째 계층은 첫 번째 모델의 작업을 확인하는, 다른 베이스를 가진 모델입니다. 현재 업계가 정착하고 있는 패턴은 대략 이렇습니다: Claude Code가 작성하고, Codex가 검토합니다. 서로 다른 학습(training)과 서로 다른 사각지대(blind spots)를 가지고 있기에, 사각지대가 일치하지 않아 실제로 무언가를 잡아낼 수 있게 됩니다.

우리가 절대 하지 않는 단 한 가지는 AI가 자신의 작업물을 스스로 검토하게 하는 것입니다. 프롬프트(prompt)를 아무리 바꿔보아도, 그것은 버그를 작성했을 때와 동일한 방식으로 추론하기 때문에 사각지대는 그대로 남아 있게 됩니다.

우리가 절대 넘기지 않는 부분

이 모든 과정 중에서 우리가 절대 넘기지 않는 부분이 하나 있습니다. 언제 AI에게 작성을 맡기고, 언제 기술적 세부 사항을 직접 지정해야 하는지 아는 것 — 그 판단력은 학습 가능한 것입니다. 하지만 문제의 실제 로직(logic), 즉 문제를 관통하는 명확한 추론의 선(line of reasoning) — 그것은 모델에 위임할 수 없습니다. 그것은 언제나 당신의 몫입니다.

그리고 그 간극을 메우는 정직한 방법은 한 가지만이 아닙니다. 우리 네 명만 보더라도 스타일이 극명하게 갈립니다. 우리 중 한 명은 아키텍트 우선(architect-first) 방식으로 일합니다. 에이전트가 무엇인가를 건드리기 전에, 그는 이미 머릿속에서 구조를 계층별로 나누어 놓았고 모든 조각이 어디에 들어갈지 알고 있습니다. 즉, 첫 번째 검증자인 '정보를 가진 인간(informed human)'의 역할에 비중을 많이 둡니다. 또 다른 한 명은 더 대담합니다. 에이전트가 구축하게 두고, 실행되는 것을 본 다음, 여러 가지 서로 다른 모델을 투입해 검토하게 합니다. 즉, 두 번째 검증자인 '독립적인 모델(independent model)'의 역할에 비중을 많이 둡니다. 저는 예전에 이 두 방식이 정반대라고 생각했습니다. 하지만 그렇지 않습니다. 이들은 단지 동일한 두 가지 독립적인 체크 항목에 대해 서로 다른 가중치를 두는 것뿐입니다. 우리는 두 가지를 모두 유지합니다. 요구 사항을 안전하게 충족하는 것이 무엇이든, 그것이 바로 훌륭한 AI 엔지니어링입니다. 끝.

그렇다면 실제 해자(moat)는 무엇인가?

어휘력이 아닙니다. 여러분은 제가 방금 설명한 이 모든 과정이 사람들이 현재 '하네스 엔지니어링 (harness engineering)'이라고 부르는 것이라는 점을 이미 눈치채셨을지도 모릅니다. 이 명칭은 2026년에야 비로소 불붙기 시작했으며, 솔직히 우리조차 이제 막 그 정체를 파악하기 시작한 단계입니다. 우리가 처음부터 이 모든 것을 해왔던 것처럼 가장하지 않겠습니다. 프롬프트(prompt), 컨텍스트(context), 하네스(harness) — 그리고 이 단어들 이후에도 더 많은 용어가 등장할 것입니다. 해자는 각각의 새로운 도구와 새로운 명칭을 받아들여, 실제로 출시(ship)할 수 있는 무언가로 가장 빠르게 내재화할 수 있는 능력을 가진 사람입니다. 새로운 것을 실행 가능한 작업으로 전환하는 속도, 바로 '그것'을 따라잡는다면 여러분은 전체 흐름을 따라잡게 될 것입니다.

만약 여러분도 같은 문제로 씨름하고 있다면 — 즉, 실제로 신뢰할 수 있는 AI를 출시하려고 노력 중이거나, 자신만의 전달 프로세스를 구축하며 의견을 나누고 싶다면 — 저는 그런 분들과 대화하는 것을 가장 좋아합니다. 인사해 주세요: lingchong@iterant-ai.com.