테스트가 모두 통과해도, 바로 "운영 환경에 배포해도 좋다"라고 말할 수 없다

AI 코딩 에이전트에게 코드를 작성하게 하는 것은 이제 일상이 되었습니다. 구현뿐만 아니라 테스트도, 커밋 메시지(Commit Message)도 그럴싸한 형태로 한 세트 갖춰져 옵니다.

하지만 개발을 진행하며 시간이 걸리는 곳은 언제나 "작성하는" 부분이 아니었습니다. 변경 내용을 이해하고, 영향 범위를 확인하며, 테스트 결과를 평가하고, 마지막으로 "이 상태로 운영 환경에 배포해도 좋다"라고 판단하는 것 —— 무거운 것은 오히려 이 후반부였습니다.

그리고 이것은 AI가 등장하면서 생겨난 문제가 아닙니다. 예를 들어 API 변경에서는 코드 수정 그 자체보다, 그 영향이 어디까지 미치는지 확인하고, 테스트하여 "정말로 배포해도 되는지"를 가늠하는 데 항상 시간이 걸렸습니다. AI가 빠르게 만든 것은 어디까지나 구현 부분입니다. 그 뒤에 있는 확인이나 판단의 무게까지 똑같이 가벼워진 것은 아닙니다. 그래서 원래 무거웠던 후반부는 지금도 그대로 남아 있습니다.

구체적인 상황으로 생각해 보겠습니다. 생성된 변경 사항은 컴파일(Compile)이 통과되고, 단위 테스트(Unit Test)도 모두 통과하며, 정적 분석(Static Analysis)도 통과했습니다. 에이전트도 "대응이 완료되었습니다"라고 보고하고 있습니다. 그럼에도 불구하고 바로 운영 반영을 승인할 수는 없습니다. 다음 사항들을 아직 판단할 수 없기 때문입니다.

• 요청한 범위만 변경했는가
• 건드리지 않았어야 할 전제 조건에 손을 대지는 않았는가
• 테스트가 커버하지 못한 영향은 없는가
• 남은 리스크는 누가 책임지는가

결론부터 말하자면, 테스트를 통과하는 것(=검증할 수 있는 것)과 그 변경에 책임을 지고 "배포해도 좋다"라고 판단하는 것(=승인·Sign-Off 할 수 있는 것)은 별개의 문제입니다. 그리고 AI로 코드 생성이 빨라지고 변경량이 늘어날수록, "검사를 통과한 변경"과 "인간이 내용을 이해하고 책임을 질 수 있는 변경" 사이의 격차는 오히려 두드러지게 됩니다.

한 가지 전제가 있습니다. 이 기사가 주로 대상으로 하는 것은 운영 시스템에 배포하는 코드입니다. 데모나 PoC, 이른바 바이브 코딩(Vibe Coding)이라면 승인 기준을 크게 낮출 수도 있습니다. 반면 누군가가 운영 환경에서 사용하고, 문제가 발생하면 조직으로서 대응해야 하는 코드에서는 검증과 승인이 중요합니다.

「Sign-Off Layer」라는 용어로 위화감이 언어화되었다

지금까지 써온 "검증은 되고 있는데, 승인은 할 수 없다"라는 감각을 잘 언어화해 준 기사가 있습니다. Juan Cruz Martinez 씨의 "The Sign-Off Layer Is Becoming the Real Engineering System"입니다.

읽으면서 특히 인상 깊었던 것은, AI에 의해 생성 비용이 낮아지더라도 생성물을 이해하고, 검증하며, 자신의 판단으로서 받아들이는 비용까지 똑같이 낮아지지는 않는다는 지적이었습니다. 따라서 개발의 병목(Bottleneck)은 생성 그 자체가 아니라 그 다음 단계로 옮겨갑니다. 저자는 그 부분을 "사인오프(Sign-Off)"라고 부르고 있습니다.

출처: Juan Cruz Martinez, "The Sign-Off Layer Is Becoming the Real Engineering System," The Long Commit, 2026-06-09.

이후 내용은 이 기사를 읽고 생각한 것을 자신의 실무에서의 실감과 대조하여 다시 정리한 내용입니다. 원문은 유료이며 논점도 구체적인 예시도 원문 쪽이 더 풍부하므로, 관심이 있다면 원문을 찾아보시기 바랍니다. 이 기사는 요약이 아니라, 거기서 받은 문제의식을 자신의 실무 관점에서 "사인오프를 설계 대상으로 생각한다"라고 재정의한 것입니다.

검증할 수 있어도, 승인할 수 있는 것은 아니다

"검증"과 "승인(Sign-Off)"은 자칫 같은 것으로 취급되기 쉽습니다. 테스트가 통과하고, 리뷰에서 Approve를 누르는 일련의 흐름 속에 있기 때문입니다. 하지만 이 두 가지가 답하고 있는 질문은 다릅니다.

한 문장으로 정리하면 다음과 같습니다.

검증은 정해진 조건에 비추어 대상을 확인하고, 판단 재료가 될 증거를 갖추는 것. 승인은 그 증거로 진행해도 좋을지를 남은 불확실성까지 포함하여 가늠하고, 다음 공정으로 통과시키는 것.

여기서 짚고 넘어가야 할 점은 승인(Sign-Off)은 "확인 버튼을 누르는 것" 그 자체가 아니라는 점입니다. 판단의 근거와 남은 리스크를 이해한 상태에서, 그 변경을 다음 공정으로 진행할 판단을 정해진 역할과 권한 아래에서 책임지는 것까지를 가리킵니다.

또 하나, AI 에이전트(AI Agent)를 사용하다 보면 간과하기 쉬운 점이 있습니다. AI가 구현과 테스트를 동시에 생성하여 그 테스트가 모두 통과하더라도, 그것이 반드시 '독립적인 검증'을 의미하는 것은 아니라는 점입니다.

구현과 테스트가 동일한 전제로부터 만들어졌다면, 양쪽이 일치하더라도 이상할 것이 없습니다. 그것은 '구현이 설정한 전제에 부합한다'는 증거는 될 수 있어도, '그 전제 자체가 올바르다'는 것까지는 보장하지 않습니다. 테스트가 존재하고 통과했다는 사실과, 그 테스트가 타당하며 시스템으로서 문제가 없음을 확인했다는 것은 분리해서 생각해야 합니다.

AI 코딩에서 「무거워지는」 것들을 3가지로 나누어 생각하기

AI 코딩으로 개발이 편해졌다는 목소리도 있지만, 오히려 더 힘들어졌다는 목소리도 있습니다. 이 두 가지가 서로 맞물리지 않는 이유는 「힘들어짐」을 하나로 뭉뚱그려 말하고 있기 때문입니다. 한마디로 「무거워졌다」고 해도, 그 내용은 적어도 다음의 3가지로 나눌 수 있습니다.

• 작업 시간 (양): 코드 생성 속도가 빨라지면 리뷰해야 할 대상 자체가 늘어납니다. 건당 작업은 빨라지더라도, 건수가 늘어나면 전체 확인량이 반드시 줄어든다고 볼 수는 없습니다.
• 인지 부하 (Cognitive Load): 리뷰 대상이 「사람이 의도를 추적하며 작성한 코드」에서 「AI가 고속으로 생성하여 성립 과정을 사람이 충분히 추적하지 못한 코드」로 변합니다. 전제, 의존 관계, 왜 이렇게 작성했는지에 대한 내용을 나중에 인간이 다시 이해해야 하는 비용이 발생합니다. 다만 인지 부하가 반드시 늘어나는 것은 아니며, AI가 변경 사항의 요약이나 영향 범위 후보를 제시해 준다면 반대로 낮아지는 경우도 있습니다.
• 책임: 최종적으로 「내보내도 좋다」라고 판단하는 주체는 인간이며 조직입니다. 코드 생성 비용이 낮아지더라도, 그 책임을 떠안는 주체가 필요하다는 사실은 변하지 않습니다. AI가 10건의 변경 사항을 제안할 수 있게 되면, 승인자는 10건 분량의 판단을 떠안게 됩니다. 변경을 만드는 한계는 확장되어도, 책임을 지고 이해할 수 있는 한계가 똑같이 확장되지는 않습니다.

여기서 중요한 점은 이 3가지가 동일하게 움직이지 않는다는 점입니다. 코드 생성에 걸리는 시간은 확실히 단축되는 반면, 이해·판단·책임의 부하는 같은 비율로 가벼워지지 않으며, 생성량이 늘어나면 오히려 전체적으로 늘어날 수도 있습니다.

코드 생성 속도가 빨라져도 이해·판단·책임의 부하는 그대로 남아 있습니다. 따라서 「AI로 개발 전체가 빨라진다」라는 말은 절반은 맞고, 절반은 오해를 불러일으킬 수 있다고 생각합니다.

사인오프(Sign-off)를 「설계 대상」으로 생각하기 위한 5가지 질문

최근에는 에이전트의 하네스(Harness)나 루프(Loop) — 어떻게 자동으로 돌리고 어디까지 맡길 것인가 — 를 구축하는 것에 관심이 집중되고 있습니다. 그것도 중요합니다. 하지만 그 부분을 아무리 잘 정비하더라도, 마지막에 「인간이 어떻게 책임을 맡을 것인가」는 별도로 설계해야 합니다. 「사인오프는 중요하다」라고 끝내면 단순한 감상에 그치게 되므로, 이를 설계 대상으로 재정의하여 다음의 5가지 질문으로 나누어 보겠습니다. 이는 완성된 절차가 아니라, 자신의 시스템을 재검토하기 위한 관점입니다 (구현 순서가 아닙니다).

무엇을 보여주어야 판단할 수 있는가 (Evidence)

「승인하시겠습니까? Yes / No」만 제시된다면 책임 있는 승인을 할 수 없습니다. 판단하는 사람에게는 판단할 수 있는 충분한 재료가 필요합니다. 변경 차이점(Diff), 테스트 결과, 참조한 정보, 실행 예정인 액션, 영향 범위, 탐지된 리스크, AI가 설정한 전제, 그리고 미결 상태로 남아 있는 사항들. 이것들을 판단 가능한 형태로 보여줄 수 있는가. 사인오프의 질은 여기서 거의 결정됩니다.

누가 그 판단을 떠안을 수 있는가 (Authority)

사인오프는 화면의 버튼을 누르는 일처럼 보이지만, 그 이전에 「누가 승인할 수 있는가」라는 인가 (Authorization) 문제입니다.

• 누구나 승인해도 되는가
• 업무 담당자와 시스템 담당자, 양쪽의 승인이 모두 필요한가
• 리스크의 크기에 따라 승인자를 변경하는가
• 생성한 본인이 스스로 승인해도 되는가 (인간 간의 리뷰와 동일한 논점입니다)
• 대리 승인이나 승인 만료를 어떻게 처리할 것인가

이러한 부분은 AI가 등장하기 전부터 기업 시스템이 직면해 온 직무 분리(Separation of Duties)나 권한 관리의 이야기와 본질적으로 같습니다. 새로운 문제처럼 보이지만, 고전적인 설계 원칙이 그대로 유지됩니다.

어디에서 인간의 판단을 개입시킬 것인가 (Boundary)

모든 처리를 인간의 승인 대기 상태로 만들면 업무가 돌아가지 않습니다. 따라서 「어디를 승인의 경계로 할 것인가」를 결정해야 합니다. 소프트웨어 개발이라면 예를 들어 다음과 같은 상황입니다.

• main

• main 브랜치에 머지하기 전 - 운영 환경(Production)에 배포하기 전

• 운영 설정을 변경하기 전

• 데이터베이스 마이그레이션 (Database Migration)을 실행하기 전

• 새로운 의존성 (Dependency)이나 외부 통신을 추가하기 전

• 권한, 인증, 결제 등 중요한 영역을 다루기 전

동일한 사고방식은 코드 생성뿐만 아니라, 외부 시스템을 조작하는 AI 에이전트 (AI Agent)에게도 확장될 수 있습니다.

무엇을 충족해야 「완료」인가 (Criteria)

판단의 기준 자체가 정해져 있지 않다면, 승인자는 분위기에 의존해 판단할 수밖에 없습니다. 목표, 제약, 완료 조건, 해서는 안 되는 일, 허용 가능한 리스크, 인간에게 되돌리는 조건. 이 「무엇을 목표로 하고, 무엇을 충족해야 하는가」를 저는 이전에 Intent Engineering이라는 관점에서 정리했습니다. Intent가 「어디를 목표로 할 것인가」를 결정한다면, 사인오프 (Sign-off)는 「그곳에 도달했다고 무엇을 근거로, 누가 판단할 것인가」를 결정합니다.

왜 승인했는지를 나중에 설명할 수 있는가 (Record)

단순한 실행 로그가 아니라, 「무엇을, 어떤 목적에 대해, 무엇을 근거로, 누가 판단하여, 최종적으로 어떻게 되었는가」를 나중에 추적할 수 있는 기록이 필요합니다. 인시던트 (Incident)가 발생했을 때, 혹은 감사 (Audit) 시에 힘을 발휘하는 것은 바로 이 「왜 승인했는지를 설명할 수 있는 상태」입니다.

이 5가지 질문에 매번 풀 세트로 답할 필요는 없습니다. 행 보완이나 변수명 수정과 같은 경미한 변경에 거창한 확인은 필요하지 않습니다. 기준을 높여야 하는 대상은, 변경의 생성 주체와 관계없이 영향 범위가 넓은 변경, 되돌릴 수 없는 변경, 보안이나 고객과 관련된 변경, 예를 들어 운영 설정이나 마이그레이션 등, 문제가 발생했을 때의 영향이 큰 부분이라고 생각합니다. 판단의 축은 파고들면 하나로 좁혀집니다.

그 변경에 대해, 인간이 책임 있는 판단을 내릴 수 있을 만큼의 정보와 이해가 갖춰져 있는가?

AI를 멈추는 것이 아니라, 책임을 질 수 있는 상태를 설계한다

AI에게 코드를 쓰게 하는 것을 그만두는 것은 현실적이지 않습니다. 그렇다고 생성된 것을 모두 인간이 처음부터 다시 조사한다면, AI를 사용하는 의미가 퇴색됩니다. 요구되는 것은 양쪽의 장점을 취하는 것을 설계로서 구축하는 것입니다.

어떤 증거를 자동으로 갖추고, 어떤 판단을 인간에게 남기며, 누가 판단할 수 있게 하고, 그 결과를 어떻게 기록할 것인가. AI가 생성한 변경을 다음 공정으로 진행하기 직전에 확인 다이얼로그를 하나 추가하는 것만으로는 책임 있는 승인이 되지 않습니다. 보여줄 재료, 판단할 권한, 나중에 설명할 수 있는 기록을 함께 설계해야 비로소 승인은 단순한 버튼 조작이 아닌, 설명 가능한 의사결정이 됩니다.

단, Sign-Off Layer는 갑자기 태어난 새로운 기술이 아닙니다. 품질 보증 (QA), 변경 관리, 권한 관리, 직무 분리, 감사 등 기업 시스템이 이전부터 다루어 온 문제들을, AI 시대의 생성 속도와 자율성에 맞춰 재해석하기 위한 설계 관점입니다. AI가 새로운 책임 문제를 만들어냈다기보다, 이전부터 존재했던 문제를 무시할 수 없는 규모로 현재화시켰다고 생각합니다.

Intent Engineering이 「무엇을 목표로 할 것인가」를 명확히 한다면, Sign-Off Layer는 「그곳에 도달했다고 무엇을 근거로, 누가 판단할 것인가」를 설계하고, 그 결과를 조직이 책임지고 수용할 수 있는 상태로 만듭니다.

AI 코딩 시대에 설계해야 하는 것은 하네스 (Harness)나 루프 (Loop)만이 아닙니다. 인간이 이해하고, 판단하고, 책임을 질 수 있는 상태까지 포함하여 엔지니어링해야 합니다.

Discussion