실행 모델
실행은 고정된 절차가 아니다. 가능한 경로 중 하나가 선택될 뿐이다.
이 문서는 절차적 어긋남을 다룬다. 같은 요청이 들어와도 어떤 절차를 통해 실행되는지가 매번 재결정될 때, 왜 구조가 빠르게 흔들리는지 본다.
같은 요청, 다른 실행
요청을 하나 준다. “태그 기능을 추가하라.”
첫 번째 작업에서는 기존 구조를 따른다. 이미 있는 TagService를 사용하고, 상태는 store를 통해 흐른다. 검증도 service 레이어에서 처리된다. 일관성 있게.
며칠 뒤 비슷한 요청이 또 들어온다. “태그에 색상 옵션을 추가하라.”
이번에는 다르게 나온다. 일부 로직이 컴포넌트 안에 직접 들어간다. 상태가 store를 거치지 않고 local state로 처리된다. 검증이 UI 레벨에서만 이루어진다.
기능은 동작한다. 화면도 정상이다.
하지만 내부 구조는 이미 두 갈래로 나뉘어 있다.
과정은 보이지 않는다
결과는 보인다. 화면, 동작, 에러 여부.
하지만 과정은 보이지 않는다.
이번 작업이 TagService를 거쳤는지, 아니면 컴포넌트에서 직접 처리했는지. store를 통해 상태가 흘렀는지, 아니면 local state로 처리됐는지. 이전과 같은 경로를 따랐는지, 아니면 새로운 경로를 만들었는지.
이 정보는 결과에 남지 않는다. 로그에도, 테스트 결과에도.
그래서 문제가 드러나지 않는다. 한참 후에 다른 작업을 하다가, 태그 관련 버그가 두 군데서 다르게 나타날 때가 되어서야 알게 된다. 그 시점에는 이미 여러 겹이 쌓여 있다.
고정되지 않는 실행
이 구조에서는 실행이 고정되지 않는다.
같은 기능 영역에서 작업하더라도, 어떤 경로를 선택할지는 매번 결정된다. 이전에 어떤 경로를 썼는지는 기억되지 않는다. 컨텍스트에 명시하지 않으면, 그냥 가능한 경로 중 하나가 선택된다.
프롬프트로 “기존 service를 사용하라"고 지시할 수 있다. 하지만 그 지시가 모든 경우에, 모든 작업에서, 정확하게 같은 방식으로 해석될 거라는 보장은 없다.
경로는 선언된 적이 없다. 그래서 매번 재결정된다.
왜 반복되는가
이 상태에서는 특정 경로를 막아도 효과가 제한적이다.
한 경로를 막으면, 그 경로 대신 다른 경로가 사용된다. “컴포넌트에서 직접 상태를 바꾸지 마라"고 했더니, 이번엔 util 함수를 만들어서 그 안에서 상태를 바꾼다.
문제가 사라지지 않는다. 이동한다.
그래서 이런 일이 반복된다.
- 특정 패턴을 금지한다 → 비슷하지만 다른 패턴이 나타난다
- 구조를 정리한다 → 다음 기능에서 정리 전 방식이 다시 등장한다
- 경로를 하나로 맞춘다 → 새로운 작업이 새로운 경로를 만든다
여기서 정리된다
지금까지 본 세 가지는 결국 같은 곳을 가리킨다.
프롬프트는 방향만 준다. 컨텍스트는 상태를 유지하지 못한다. 실행은 경로를 고정하지 않는다.
경로가 열려 있다.
이 세 가지 접근 모두 경로를 다루지 않는다. 결과를 더 잘 만들려고 하지만, 결과가 어떤 경로를 통해 만들어지는지는 건드리지 않는다.
그래서 같은 문제가 계속 돌아온다.