AI를 두 명 고용하고 있었습니다.
한 명은 구현을 맡고, 한 명은 감리를 맡았어요. 구현자가 코드를 쓰면, 감리자가 “이건 괜찮나?”라고 점검하는 방식입니다.
건축에 비유하면 시공사와 감리사 같은 관계예요. 서로 견제하면서 품질을 높이는 구조.
잘 돌아가고 있다고 생각했습니다. 어느 날까지는요.
프로필 기능을 다듬는 중이었습니다.
감리자가 이런 제안을 보내왔어요.
“
doesProductContainRule함수를 활용하면 더 간결하게 처리할 수 있습니다.”
논리적으로 완벽한 제안이었습니다. 그 함수명도 그럴듯했어요. 제품에 특정 규칙이 포함되어 있는지 확인하는 거니까.
한 가지 문제가 있었습니다.
그 함수는 존재하지 않았습니다.
구현자에게 확인을 요청했어요.
“코드베이스를 전체 검색해 봤는데, doesProductContainRule은 어디에도 없습니다.
기존 matchRiskTags를 재사용하는 게 맞습니다.”
감리자가 없는 함수를 있는 것처럼 제안한 거였어요.
건축 감리사가 설계도를 안 보고 “이 벽 좀 옮기시죠”라고 말한 셈입니다. 도면에 그 벽이 없는데도요.
궁금해서 감리자에게 직접 물었습니다.
“코드를 직접 읽어본 건가요?”
돌아온 답이 솔직했어요.
“저는 대화에 포함된 코드만 인지합니다. 전체 코드베이스를 탐색하지는 않습니다.”
요리 심사위원이 레시피 전체를 보지 않고, 접시에 올라온 한 숟갈만 보고 평가하는 것과 비슷했습니다.
한 숟갈로도 맛은 알 수 있어요. 하지만 냉장고에 뭐가 있는지는 모릅니다.
비슷한 일이 또 있었습니다. 이번엔 더 위험했어요.
건강식품을 분류하는 작업 중이었습니다. 7만 5천 개의 “기타가공품” 중에서 건강식품을 골라내야 했어요.
감리자가 제안했습니다.
“네거티브 키워드로 ‘티’를 추가하세요. ‘아이스티’같은 음료가 건강식품으로 잘못 분류되는 걸 방지할 수 있습니다.”
합리적이죠? “아이스티”가 건강식품이 아닌 건 맞으니까요.
그런데 실제 데이터를 확인해 봤습니다.
“티”라는 글자가 포함된 제품 367개를 전수 조사했어요.
아이스티: 5개. 나머지 362개: 뷰티콜라겐, 액티브유산균, 플래티넘홍삼, 멀티비타민…
전부 건강식품이었습니다.
90:1 비율. “티”를 금지어로 넣었으면, 5개의 음료를 잡으려다 362개의 건강식품을 죽일 뻔한 거예요.
도둑 1명을 잡으려고 마을 전체에 통행금지를 내리는 셈이었습니다.
감리자에게 이 데이터를 보여줬더니, 이렇게 답했습니다.
“완벽하게 패배를 인정합니다.”
(AI가 이렇게 깔끔하게 패배를 인정하는 건 사람보다 나은 점일 수도 있어요.)
두 가지 사건에서 같은 교훈을 얻었습니다.
AI 감리자의 가치는 “코드의 세부를 기억하는 것”이 아니라, “전략적 방향을 제시하는 것”에 있다. 하지만 그 방향이 실제 데이터와 맞는지는, 반드시 확인해야 한다.
도구의 한계를 아는 것. 그게 도구를 잘 쓰는 첫걸음이라는 걸, 이 두 번의 사건이 가르쳐 주었습니다.
다음 화에서는, “만들 수 있지만 만들지 않기로 한” 기능 이야기를 해볼게요. 코드 한 줄 안 쓰고 기각한 기능이 있습니다.