복잡한 변경에서 AI의 판단을 검토하는 법

AI 에이전트가 만든 변경은 코드가 그럴듯해 보여도 충분하지 않을 때가 있습니다. 예를 들어 인증 상태를 바꾸는 수정이라면, 로그인 성공 경로만 통과하는지보다 실패한 요청이 기존 세션을 바꾸지 않는지가 더 중요할 수 있습니다. 파일 목록과 테스트 명령만으로는 이 조건이 왜 필요했고 어떤 결과로 확인됐는지 놓치기 쉽습니다.

이럴 때 FTM(Functional Thinking MCP)은 AI의 답을 더 길게 만들기 위한 도구가 아니라, 판단의 조건을 검토 가능한 구조로 정리하는 방법입니다. 목표·제약·상태 전이·검증을 분리하면, 다음 행동을 고르는 근거가 코드 밖에서도 분명해집니다.

그럴듯한 코드만으로는 부족한 변경

다음 요청을 생각해 보겠습니다.

만료된 세션으로 API를 호출하면 새 세션을 만들지 말고 인증 오류를 반환해 주세요.

수정해야 할 파일을 찾고 조건문을 추가하는 일만 보면 간단해 보입니다. 하지만 실제 판단에는 적어도 다음 질문이 있습니다.

• 현재 세션이 만료됐다는 사실은 어디에서 확인하는가?
• 만료된 요청에서 반드시 보존해야 하는 상태는 무엇인가?
• 새 세션을 만들지 않았다는 사실을 어떤 테스트로 확인하는가?
• 네트워크 호출이나 DB 쓰기가 실패하면 어떤 결과를 사용자에게 돌려주는가?

FTM은 이 질문을 한 문단의 설명으로 섞지 않습니다. 현재 상태와 입력, 적용할 변환, 기대하는 다음 상태를 연결합니다.

현재 상태 + 입력
  → 판단 규칙과 변환
    → 다음 상태 + 필요한 검증

이 구조는 정답을 보장하지 않습니다. 대신 전제가 빠진 채 구현으로 넘어가는 일을 줄이고, 리뷰어가 "무엇을 바꾸었는가"뿐 아니라 "어떤 조건을 지켜야 했는가"를 확인하게 합니다.

상태·입력·변환·결과를 먼저 분리하기

FTM의 기본 관점은 다음과 같습니다.

RelevantState × TransitionInput → RelevantState'

인증 예시를 이 형태로 바꾸면 판단의 경계가 드러납니다.

여기서 중요한 것은 상태를 세밀하게 이름 붙이는 일이 아닙니다. 다음 행동을 달리해야 하는 실제 차이가 있을 때만 상태를 구분하는 일입니다. expired와 valid에서 같은 함수를 같은 방식으로 실행한다면 굳이 별도 상태로 만들 필요가 없습니다. 반대로 한쪽에서만 외부 쓰기를 막아야 한다면, 그 경계는 분명히 남겨야 합니다.

불변조건과 Effect: 바뀌지 않아야 할 것과 바깥에 미치는 일

**불변조건(invariant)**은 어떤 경로를 거쳐도 깨지면 안 되는 조건입니다. 위 사례의 불변조건은 "검증 실패는 기존 세션 상태를 바꾸지 않는다"가 될 수 있습니다.

Effect는 파일 수정, 명령 실행, 네트워크 요청, 데이터베이스 쓰기처럼 판단 바깥의 상태에 영향을 주는 행동입니다. 예를 들어 createSession() 호출은 Effect입니다. 이 호출을 실행하기 전에 조건을 검토하면, 만료된 토큰에서 새 세션이 생기는 조용한 회귀를 막을 수 있습니다.

불변조건은 희망사항이 아닙니다. 테스트, 재현 스크립트, 코드 리뷰처럼 실제 근거와 연결할 수 있어야 합니다. 근거가 아직 없다면 "지켜졌다"고 선언하지 않고, 검증해야 할 조건으로 남기는 편이 정확합니다.

structure_reasoning으로 판단 경계 만들기

FTM MCP의 structure_reasoning은 현재 상태, 새 입력, 변환 규칙, 결과 상태를 한 번의 판단 전이로 기록합니다. 다음은 원리를 보여 주는 축약 예시입니다. 실제 프로젝트에서는 상태와 검증 이름을 해당 도메인에 맞춰 바꿔야 합니다.

inputState: 세션을 아직 변경하지 않은 인증 요청
transitionInput: 토큰 검증 결과는 expired
transformation: 세션 생성 Effect를 실행하지 않고 재인증 응답을 만든다
outputState: 기존 세션은 유지되고, 재인증 필요 상태가 된다
invariant: 검증 실패는 기존 세션 상태를 바꾸지 않는다

이 기록은 AI의 비공개 추론 전문을 공개하는 장치가 아닙니다. 리뷰 가능한 입력, 제약, 외부 실행 효과, 검증 근거만 드러내는 인터페이스입니다. 따라서 "왜 이 파일을 수정했는가"와 "어떤 조건에서 테스트를 멈춰야 하는가"를 함께 설명할 수 있습니다.

실제 도구 호출에서는 목표와 제약을 먼저 고정하고, 파일 쓰기·명령 실행·네트워크 요청 같은 Effect는 실행 전제와 되돌림 방법을 함께 둡니다. 테스트를 아직 실행하지 않았다면 불변조건은 미검증 상태로 남습니다. 이 구분이 있어야 계획을 완료 결과처럼 오해하지 않습니다.

FTM이 특히 유용한 경우

다음처럼 여러 입력이 하나의 상태를 바꾸거나, 실패가 눈에 잘 띄지 않는 변경에는 FTM의 구조가 도움이 됩니다.

• 인증·권한·결제처럼 잘못된 성공이 위험한 흐름
• UI와 서버, 큐 작업이 같은 상태를 갱신하는 기능
• 재시도·중복 요청·부분 실패를 처리하는 비동기 작업
• 테스트가 통과해도 데이터나 권한 경계를 별도로 확인해야 하는 변경

반대로 오탈자 수정, 확정된 문구 교체, 독립된 CSS 값 조정처럼 상태 전이와 제약이 거의 없는 일에는 적용하지 않아도 됩니다. 작은 일에 구조를 강제하면 판단을 돕는 기록이 오히려 작업을 가립니다.

기준은 도구의 존재가 아니라 질문의 수입니다. "이 변경이 실패했을 때 무엇이 남아야 하는가?"와 "어떤 외부 행동을 막아야 하는가?"를 명확히 답해야 한다면 FTM을 고려할 가치가 있습니다.

WGM과 Git의 역할은 다릅니다

FTM은 현재 변경의 판단 조건과 검증 근거를 정리합니다. WGM은 그 판단이 속한 Task, 이전 결정, 확정 지점을 이어서 보존합니다. Git은 실제 파일 변경을 commit으로 남깁니다.

셋을 같은 기록으로 취급하면 각각의 질문에 답하기 어려워집니다.

다음 글에서는 세션이 끊기거나 담당자가 바뀐 뒤에도, WGM의 Task context·Note·chat search로 이 관계와 근거를 다시 찾는 방법을 다룹니다.