"r"을 세도록 명령하지 말고, "r"을 세는 함수를 만들도록 하라

최근, AI 활용 방식에 대해 팀 안팎으로 같은 이야기를 반복하고 있다.

"r"을 세도록 명령하지 말고, "r"을 세는 함수를 만들도록 하라

 

벌써 몇 년이나 흘렀지만, 이런 질문이 화제가 되었던 적이 있다.

"Strawberry"에는 "r"이 몇 개 있는가?

 

사람이 보기에는 분명한 답인데도, 당시의 AI는 엉뚱한 개수(2개)를 내놓았다.

지금은 많은 모델이 정답(3개)을 맞히게 되었지만, 이 질문이 남기고 간 인사이트는 여전히 유효하다.

 

AI에게 정답을 말하게 하지 말고, 정답을 계산하는 함수를 만들게하라.

 

왜 이 문장이 중요한가?

1. LLM은 본질적으로 확률적 시스템이다.

2. context-window와 출력 토큰의 한계가 존재한다.

3. 따라서 “전부 찾아서 보고해”는 그럴듯 해 보이는 답을 줄 수 있어도 완전성을 보장하지는 못한다.

관점을 조금 바꿔보자.

- AI에게 결과를 요구하지 않는다.

- AI에게 결과를 계산하는 절차를 만든다.

- 사람은 절차의 신뢰도를 검증한다.

이렇게 바꾸면, AI 활용이 "잘 맞히게 만드는 요령"같은게 아니라 "재현 가능한 시스템"으로 만들 수 있다.

 

P2D: Probabilistic to Deterministic

작업을 다음과 같은 단계로 진행해보자.

1. 질문을 계산 문제로 변환한다.

 - Before: "이 패턴을 사용하는 곳을 전부 찾아줘"

 - After: "이 패턴을 탐지하기 위한 스캐너 스크립트를 작성해줘"

2. 결정적 산출물을 먼저 만든다.

 - 코드 탐지 스크립트

 - AST Transform (w/ jscodeshift)

 - lint rule

3. AI의 역할을 생성/해석으로 제한한다.

 - 탐지와 변환의 실행은 도구(script)가 담당하고, AI는 스크립트의 작성과 결과 요약을 담당한다.

4. 검증 루프를 닫는다.

 - "누락 없음"을 선언하지 않고, "누락 가능성을 구조적으로 낮춘 근거"를 남긴다.

 

실무에서 활용했던 상황들은 다음과 같다.

1. Deprecated 컴포넌트 마이그레이션

AI에게 직접 변경하게 하면, 사람의 검증 비용은 폭증하기 마련이다.

반대로 AST 기반 변환으로 바꾸면, 반복 작업은 "규칙"으로 고정되어 누락 리스크는 급격하게 줄어든다.

2. 특정 패턴 전수 조사

AI에게 자연어 요청만으로는 사례가 누락되기 쉽다.

패턴 스캐너를 먼저 만든 후, 결과를 해석하면 "찾았다"가 아니라 "탐지 규칙에 의해 파악된 것"이 된다.

3. 특정 라우트에서 참고하는 API 전수 파악

요약 보고에 의존하면 불안하다. 스크립트를 통해 사용처를 분석하면 빠짐없이 모두 파악할 수 있다.

 

AI를 활용한 생산성은 다음과 같이 정의할 수 있다.

"얼마나 그럴듯하게 답했는가"가 아니라, "얼마나 재현 가능한 절차를 만들었는가"

이 기준에서 바라보면, 좋은 프롬프트는 화려한 질문이 아니라 검증 가능한 파이프라인으로 연결되는 질문이라고 볼 수 있다.

 

AI와 함께 일하며 수시로 생각한다.

나는 지금 AI에게 "r"을 세게 하고 있는가, 아니면 "r"을 세는 시스템을 만들고 있는가