AI 코드의 의미 검증 질문 설계

1. 통과한 변경이 남기는 착시

AI가 만든 코드를 받아들일 때 가장 강한 신호는 눈앞에 있다. 컴파일 오류가 사라지고, 화면이 원하는 값을 보여 주며, 기존 테스트가 녹색으로 바뀐다. 이 신호들은 분명 유용하다. 그러나 이 관찰을 곧바로 “변경의 의미를 이해했다”는 판단으로 바꾸면, 검토의 범위가 너무 빨리 닫힌다. 특정 입력에서 결과가 나온 일과, 어떤 상태 전이·권한 조건·실패 경로 때문에 그 결과가 나오는지를 설명할 수 있는 일은 같은 질문이 아니다.

여기서 말하는 의미는 코드가 아름답게 작성됐는지, 리뷰어가 모든 줄을 암기했는지와 다르다. 이번 변경이 어떤 입력을 받는지, 이전 상태를 어떻게 바꾸는지, 다른 함수나 저장소 값에 무엇을 의존하는지, 실패하면 어디로 돌아가는지를 현재 근거로 연결할 수 있는지를 뜻한다. AI의 제안은 이 연결을 아주 매끄러운 문장과 익숙한 패턴으로 포장할 수 있다. 그래서 사람은 코드의 문법적 자연스러움과 동작의 범위를 혼동하기 쉽다.

기본 테스트도 과소평가할 필요는 없다. 테스트는 실제로 확인한 계약을 남기고, 회귀를 막으며, 리뷰 대화를 구체화한다. 다만 테스트가 보지 않는 입력, 아직 구성하지 않은 상태, 외부 시스템의 실패, 동시성, 권한 차이까지 자동으로 확인했다는 뜻은 아니다. 테스트 통과는 확인한 범위의 근거이고, 의미 이해는 그 근거가 닿는 경계를 설명하는 일이다. 두 가지를 분리하면 테스트를 늘리라는 압박 대신, 무엇을 이미 확인했고 무엇이 아직 질문인지를 더 정확히 말할 수 있다.

AI 보조 코딩의 속도가 빨라질수록 이 구분은 실무적인 문제가 된다. 긴 변경을 빠르게 얻었을 때 리뷰어는 결과 화면과 요약 설명에 먼저 끌린다. 반대로 생성 과정 전체를 다시 읽는 것은 현실적이지 않을 수 있다. 필요한 것은 모든 대화를 재현하는 절차가 아니라, 현재 변경의 의미를 좁혀 읽을 질문과 그 답의 근거 위치다. 이 글의 제안은 AI 사용을 제한하거나 개인에게 이해를 시험 보게 하려는 규칙이 아니다. 사람이 독립적으로 확인할 수 있는 지점을 남기려는 운영 메모다.

2. 최근 연구가 보여 주는 간격과 적용 범위

2026년 공개된 SemBench 연구는 실제 C 프로그램을 바탕으로 죽은 코드, 데이터 의존성, 함수 도달 가능성, 지배 관계, 루프, 라이브니스처럼 정적 분석에서 다루는 성질을 질문 형태로 구성했다. 연구진은 여러 모델 계열을 코드 생성 벤치마크와 함께 평가하며, 높은 코드 생성 성과가 이런 정적 의미 질문에 대한 같은 수준의 정확성을 뜻하지는 않는다고 보고한다. 특히 생성 성과와 의미 이해 성과가 과제별로 다르게 관계된다는 점이 핵심이다.

이 결과는 “AI는 코드를 이해하지 못한다”라는 단정이 아니다. 연구가 다루는 대상은 특정 언어·문제 구성·평가 방식에서의 모델 출력이며, 실제 제품 저장소의 품질이나 특정 도구의 안전성을 종합 판정하지 않는다. 또한 이 연구는 사람 개발자의 인지 과정이나 코드 리뷰의 효과를 측정하지 않았다. 따라서 이 글은 연구 결과를 근거로 “사람은 반드시 세 질문을 써야 한다”거나 “AI 코드가 항상 위험하다”고 말하지 않는다.

그럼에도 심리적·협업적 시사점은 있다. 사람이 유창한 산출물을 볼 때, 산출물의 설득력과 근거의 충분성을 같은 것으로 느낄 수 있다는 점이다. 모델의 생성 결과가 정답처럼 보이는 순간, 리뷰어는 이미 확인한 한 경로를 전체 의미로 넓히거나, 설명하기 어려운 부분을 질문하지 않고 넘길 수 있다. 이 글은 그 틈을 ‘AI의 결함’으로 몰아가지 않고, 검토자가 자신의 판단 범위를 명확히 적을 수 있는 작은 문서 구조로 바꾼다.

3. 의미를 좁혀 읽는 세 장의 질문

첫째는 입력과 출력이다. 이 변경은 무엇을 받아 어떤 관찰 가능한 결과를 내는가. 입력값만이 아니라 인증된 사용자, 환경 변수, 기능 플래그, 외부 응답처럼 결과를 바꿀 수 있는 계약을 함께 적는다. 이 질문은 “함수가 무엇을 하나요”보다 구체적이어야 한다. 예를 들어 주문 상태를 갱신하는 변경이라면, 요청 본문이 아니라 이전 주문 상태와 호출 권한, 이미 처리된 요청의 재시도가 입력 조건이 될 수 있다.

둘째는 상태와 흐름이다. 정상 경로에서 어떤 값이나 권한이 바뀌고, 어떤 호출 관계를 거쳐 결과가 나오는가. 이때 모든 호출 그래프를 문서화할 필요는 없다. 이번 변경의 판단에 영향을 주는 상태 하나와, 그 상태가 다음 단계에 전달되는 길 하나를 고르면 된다. AI가 제안한 캐시, 기본값, 비동기 작업, 데이터 변환은 소스 한 파일 안에서 자연스러워 보여도 다른 컴포넌트의 전제와 충돌할 수 있다.

셋째는 예외와 복구다. 실패가 나면 사용자와 시스템은 어떤 상태에 남는가. 오류를 반환한다는 한 줄만으로는 충분하지 않을 수 있다. 재시도는 중복 동작을 만들지 않는지, 일부 성공 뒤에는 무엇을 되돌리는지, 관찰과 알림은 어디에 남는지, 권한 오류와 일시적 장애를 같은 방식으로 처리해도 되는지를 살핀다. 모든 예외를 미리 상상할 수 없으므로, 가장 영향이 크거나 아직 설명할 수 없는 하나를 보류 질문으로 두는 편이 낫다.

▲ 실제 코드 분석 도구나 제품 UI가 아니라, 확인한 근거와 보류할 질문을 분리하는 리뷰 흐름을 보여줍니다.

아래 양식은 진단 도구나 품질 점수표가 아니다. 또한 세 칸을 모두 채우면 안전·정확성·성능이 보장된다는 뜻도 아니다. 변경을 병합할지, 더 조사할지, 기존 소유자에게 넘길지 판단할 때 서로 다른 사람이 같은 범위를 다시 찾을 수 있게 하는 편집부 제안이다.

# AI 보조 변경의 의미 검증 메모

- **관찰한 입력과 출력**: [누가·무엇을 넣었고, 어떤 결과를 실제로 확인했는가]
- **상태와 흐름**: [바뀌는 상태, 관련 호출 또는 데이터 경로, 확인한 근거]
- **예외와 복구**: [가장 중요한 실패 조건 하나와 현재 알고 있는 처리]
- **보류 질문**: [아직 설명하지 못한 전제 또는 확인할 담당자·자료]
- **근거 위치**: [테스트, 코드 위치, 문서, ADR, 운영 기록 중 실제로 대조한 것]

4. 질문을 리뷰 흐름에 넣는 방법

세 질문은 AI에게 더 긴 프롬프트를 요구하기 위한 장치가 아니다. 생성 직후나 리뷰 시작 전에 사람이 변경을 짧게 해석하는 순서다. 우선 지금 실제로 관찰한 입력과 출력을 쓴다. 그다음 그 결과를 가능하게 한 상태나 호출 경로를 하나만 연결한다. 마지막으로 영향이 큰 예외 하나를 골라, 답을 찾았으면 근거를 붙이고 아직 모르겠으면 보류 질문으로 남긴다. 이 순서라면 ‘모든 것을 이해한 뒤에만 진행한다’는 비현실적인 문턱도 피할 수 있다.

변경의 위험과 되돌릴 수 있는 정도에 따라 깊이는 달라져야 한다. 문구나 내부 도구의 작은 화면 변경에서는 입력·출력 한 줄과 테스트 링크만으로 충분할 수 있다. 반면 결제, 인증, 고객 데이터, 비동기 처리, 공개 API처럼 실패 비용이 큰 영역에서는 기존 보안 검토·승인·운영 절차가 필요하다. 이 메모는 그 절차를 대신하지 않는다. 다만 AI의 설명, 사람이 관찰한 사실, 아직 확인하지 못한 조건을 한 문단에 섞지 않도록 돕는다.

5. ‘모른다’를 검토 실패로 만들지 않기

AI가 있는 환경에서는 빨리 답을 내는 사람이 유능해 보이기 쉽다. 그래서 리뷰어가 의미를 설명하지 못하는 지점을 만나면, 질문을 남기기보다 그럴듯한 요약을 받아들이거나 동료에게 구두로만 넘길 수 있다. 그러나 모르는 조건을 보류 질문으로 적는 것은 작업을 멈추기 위한 방어적 표현만은 아니다. 검토가 끝난 뒤에도 어떤 전제에서 판단했는지, 어떤 자료가 추가되면 결론을 다시 열어야 하는지를 남기는 협업 정보다.

이 기록은 개인 평가나 AI 사용 감시의 자료가 되어서는 안 된다. 생성 도구를 썼다는 사실 자체보다, 현재 병합 판단이 어떤 관찰과 어떤 미확인 조건 위에 있는지가 중요하다. 리뷰어는 작성자의 메모를 정답으로 취급하지 않고 다른 경로·예외를 제시할 수 있어야 한다. 작성자는 새 근거가 나오면 기존 메모를 고치고, 왜 판단이 바뀌었는지를 연결할 수 있어야 한다. 그 과정에서 ‘설명할 수 없음’은 무능의 표시가 아니라 다음 조사의 입력이 된다.

또한 근거 기록은 더 많은 정보를 공개하라는 요구가 아니다. 고객 데이터, 보안 세부, 계약 조건처럼 넓은 PR에 둘 수 없는 내용이 있다면, 공개 메모에는 확인된 범위와 제한된 기록의 참조 위치만 남긴다. 중요한 것은 모든 사람이 민감한 내용을 보는 것이 아니라, 권한이 있는 사람이 같은 판단 근거로 다시 들어갈 수 있는 것이다.

다음 AI 보조 변경에서는 세 질문 전부를 적용하기보다, 가장 불확실한 한 장만 고르는 것으로 시작할 수 있다. 정상 동작은 확인했지만 재시도 경로가 모호하다면 예외와 복구만 남긴다. 외부 API를 바꿨지만 이전 호출자가 무엇을 받는지 불명확하다면 입력과 출력만 먼저 적는다. 이렇게 질문의 크기를 변경의 크기에 맞추면, AI 코드의 속도를 줄이지 않으면서도 유창한 결과와 이해 가능한 근거 사이의 거리를 드러낼 수 있다.

출처와 적용 범위

• Xu 외, How well do LLMs understand code? — Communications AI & Computing — 2026년 8월 공개된 연구에서 실제 C 프로그램 기반의 정적 의미 질문과 코드 생성 성과를 함께 평가한 방식, 그리고 두 성과가 완전히 겹치지 않는다는 결론을 확인했다. 본문의 세 질문, 메모 양식, 흐름도는 이 연구가 전문 개발팀의 리뷰 절차를 검증했다는 뜻이 아니라, 연구의 ‘생성 성과와 의미 이해는 구분해 보아야 한다’는 문제의식을 실무 검토에 맞게 확장한 편집부 제안이다.