고치라는 지시부터, 다시 봐야 했다 2편에서 가설 세 겹(사용자의 가설, 지시문, 검증 스크립트)을 각각 확인해야 한다는 결론으로 끝냈다. 이번 편은 그중 지시문 쪽에서 또 한 겹이 나온 이야기다.
방금 합친 걸 다시 쪼개라는 제안
/refactor가 두 노트를 병합하라고 제안했다. 하나는 “심리적 안전감”이라는
조직심리학 개념을 설명하는 노트, 다른 하나는 그 개념을 실제로
현장에 심기 위한 구체적 실천 방법(“리더의 툴킷”)을 다루는 노트였다.
병합을 실행했는데, 사용자가 결과물을 보고 “이게 진짜 하나의 원자적
노트가 맞나” 싶어서 같은 노트를 다시 /refactor에 돌렸다. 돌아온
제안은 분할이었다 — 그것도 방금 합쳤던 바로 그 두 조각으로, 거의
그대로. 시스템이 같은 내용을 두고 정반대 결론을 낸 셈이다.
이미 있던 반례를 다시 읽었다 — few-shot 반례의 함정
병합 판단 기준을 다루는 프롬프트에는 이미 정확히 이 관계에 대한 반례가 있었다. “모델 기반 엔지니어링(MBE)“이라는 상위 패러다임과 그 아래 구체적 방법론(“MBSE”, “MBD”)은 서로 다른 실체이니 병합하지 말고 연결만 하라는 내용이었다. 상위 개념과 그걸 구현하는 구체적 방법론이라는 구조가, 이번 사건(심리적 안전감과 그 실천 툴킷)과 정확히 같았다. 반례가 이미 있는데 왜 안 걸렸을까.
도메인만 바꿔서 재실측
실제 API를 여러 번 호출해 확인했다. 반례가 원래 쓰인 그 도메인(공학, MBE/MBSE)으로 실험하면 여덟 번 중 여덟 번 다 잘못 합치지 않았다. 같은 관계 구조를 도메인만 리더십으로 바꿔서(심리적 안전감과 리더의 툴킷) 실험하면, 여덟 번 중 네 번이 잘못 합쳐졌다. 정확히 반반이었다.
결론은 하나였다. 반례 하나로 모델이 배운 건 “그 밑에 있는 일반 원칙”이 아니라 “그 반례에 쓰인 정확한 단어들”이었다. MBE와 MBSE라는 표면적 어휘를 피하는 법은 배웠지만, “상위 개념과 그걸 구현하는 구체적 방법론은 별개”라는 추상적 관계 자체는 다른 단어로 바뀌는 순간 못 알아봤다.
원칙을 따로 적고, 반례를 하나 더 얹었다
고치는 방법은 두 가지를 같이 하는 것이었다. 먼저 그 추상적 원칙을 도메인과 무관한 문장으로 따로 명시했다 — “공학이든 경영이든 리더십이든 조직론이든, 상위 개념/패러다임과 그것을 구현하는 구체적 방법론은 서로 다른 실체다”라는 식으로. 그리고 원래 있던 MBE/MBSE 반례는 한 글자도 안 건드리고 그대로 둔 채, 이번에 실제로 겪은 리더십 도메인 사례를 두 번째 반례로 그 뒤에 이어붙였다. 이미 검증된 반례를 지우고 새로 쓰는 대신, 새 반례를 하나 더 곁에 세우는 쪽을 택한 것이다.
다시 실측했다. 리더십 도메인의 오판 비율이 여덟 번 중 네 번에서 여덟 번 중 영 번으로 떨어졌다. 원래 반례가 지키던 공학 도메인 쪽도 여전히 영 번 그대로였다 — 새로 추가한 문구가 기존에 잘 작동하던 부분을 흔들지는 않았다는 뜻이다.
여덟 번이 전부는 아니다
여기서 끝내지 않고 하나는 그대로 남겨뒀다. 여덟 번이라는 표본은 작다. 이번에 고친 건 “리더십 도메인에서 확인된 실패”였지, “모든 도메인에서 다시는 안 일어날 실패”가 아니다. 세 번째, 아직 안 본 도메인에서 똑같은 패턴이 또 나올 가능성은 원칙적으로 남아있다. 지금은 그 가능성을 미리 다 막으려 들지 않고, 실제로 다시 관찰되면 그때 반례를 하나 더 추가하는 쪽으로 남겨뒀다.
남는 생각
반례 하나를 프롬프트에 넣는 건 “이 정확한 사례를 피하라”는 지시에 가깝지, “이 사례가 보여주는 일반 원칙을 이해하라”는 지시가 아니었다. 사람이 예시 하나를 보고 그 뒤의 규칙을 유추하는 건 자연스러운 일이라 착각하기 쉽지만, 이번 실측은 그 유추가 공짜로 따라오지 않는다는 걸 숫자로 보여줬다. 원칙을 원칙대로 명시하고, 반례는 반례대로 여러 개 곁에 두는 것 — 결국 한쪽만으로는 안 되고 둘 다 있어야 했다.