불필요한 과정을 거치며 AI를 검색 엔진처럼 사용하는 것을 멈추세요

저는 한 개발자가 데이터베이스 스키마 (database schema) 문제로 Claude와 40분 동안 대화를 주고받는 것을 지켜보았습니다. 모든 메시지는 질문이었고, 모든 답변은 응답이었습니다. 40분이 지난 후, 그들은 기술적으로는 작동하지만 설명할 수 없는 방식으로 잘못된 느낌이 드는 스키마를 갖게 되었습니다.

문제는 모델이 아니었습니다. 문제는 방식이었습니다. 그들은 사고 세션 (thinking session)이 필요한 상황에서 대화를 질의응답 (Q&A) 세션으로 사용하고 있었습니다. 이 둘은 서로 다른 것입니다.

검색 엔진 습관이 형성되는 방식

Google은 한 세대의 개발자들이 쿼리 (queries)를 통해 컴퓨터와 상호작용하도록 훈련시켰습니다. 질문이 있으면 간결한 검색어를 만들고, 결과를 얻고, 탭을 닫습니다. 전체 상호작용은 당신이 이미 어떻게 물어봐야 할지 알고 있는 질문을 중심으로 구축되어 있습니다.

그 습관은 AI에 적용될 때 좋지 않은 영향을 미칩니다. 언어 모델 (language model)을 검색 엔진처럼 다룰 때, 당신은 상호작용을 당신이 이미 구성할 수 있는 질문들로 제한하게 됩니다. 당신은 통찰 (insights)이 아닌 답변을 얻게 됩니다. 아키텍처 (architecture)가 아닌 구문 (syntax)을 얻게 됩니다. 당신이 요청한 것을 얻게 되지만, 그것은 종종 당신에게 실제로 필요한 것이 아닙니다.

검색 엔진은 어딘가에 이미 존재하는 정보를 검색합니다. 이는 사실이 필요할 때 유용합니다. 하지만 정해진 답이 없는 문제를 깊이 생각해야 할 때는 무용지물입니다.

추론 엔진 (reasoning engine)이 실제로 할 수 있는 일

검색 (retrieval)과 추론 (reasoning)의 차이는 도서관과 동료의 차이와 같습니다. 도서관은 이미 기록된 것을 제공합니다. 동료는 당신과 함께 새로운 것을 함께 고민하고, 당신의 가정에 반론을 제기하며, 당신의 계획에 허점이 있을 때 그것을 말해줄 수 있습니다.

언어 모델은 올바른 방식으로 상호작용할 때만 두 번째 일을 할 수 있습니다. 그리고 올바른 방식은 검색 쿼리와는 전혀 다릅니다.

실제 사례로 제가 의미하는 바는 다음과 같습니다. 다음은 동일한 근본 질문에 대한 두 가지 서로 다른 상호작용 방식입니다:

검색 엔진 모드: "Python 마이크로서비스 (microservice)를 구조화하는 가장 좋은 방법은 무엇인가요?"

사고 파트너 (Thinking partner) 모드: "저는 세 개의 외부 API로부터 웹훅 (webhook) 이벤트를 처리하는 Python 마이크로서비스 (microservice)를 구축하고 있습니다. 각 API는 서로 다른 재시도 (retry) 동작과 페이로드 (payload) 형태를 가지고 있습니다. 저는 앞에 큐 (queue)를 둔 단일 FastAPI 앱을 사용하는 방안과 세 개의 별도 경량 컨슈머 (consumer)를 사용하는 방안을 고려 중입니다. 이 시스템을 유지보수할 엔지니어는 두 명입니다. 제가 놓치고 있는 트레이드오프 (tradeoffs)는 무엇인가요?"

첫 번째 상호작용은 블로그 포스트를 얻어다 주지만, 두 번째 상호작용은 스스로 생각할 때보다 더 깊게 고민하게 만드는 대화를 이끌어냅니다.

맥락 (context)이 곧 업무입니다

이러한 도구들을 가장 잘 활용하는 엔지니어는 가장 영리한 프롬프트 (prompt)를 사용하는 사람들이 아닙니다. 그들은 질문을 던지기 전에 가장 많은 맥락 (context)을 제공하는 사람들입니다. 그들은 무엇을 만들고 있는지, 어떤 제약 조건 (constraints) 하에서 작업하고 있는지, 이미 무엇을 시도해 보았는지, 그리고 왜 그런지는 설명할 수 없지만 무엇이 잘못된 것처럼 느껴지는지를 설명합니다.

마지막 부분이 중요합니다. "이것이 잘못된 것 같은데 이유는 모르겠습니다"라는 문장은 프롬프트에 넣을 수 있는 가장 생산적인 내용 중 하나입니다. 이는 모델에게 단순히 질문에 답하는 것을 넘어, 당신의 가정을 조사할 수 있는 권한을 부여합니다. 열 번 중 아홉 번은 당신이 직감하고 있었지만 이름 붙이지 못했던 문제를 수면 위로 끌어올려 줄 것입니다.

왜 대부분의 AI 상호작용이 피상적으로 느껴지는가

질문이 너무 깔끔할 때 피상적인 상호작용이 발생합니다. 실제 엔지니어링 문제는 지저분합니다. 그 안에는 상충하는 제약 조건, 레거시 (legacy) 결정, 팀 역학, 그리고 마감 기한이 녹아 있습니다. 이 모든 것을 제거하고 깔끔한 질문을 던지면, 그 어떤 것도 고려하지 않은 깔끔한 답변을 얻게 됩니다.

그 지저분함은 노이즈 (noise)가 아닙니다. 그 지저분함이 바로 실제 문제입니다. 지저분함을 알지 못하는 모델은 그 지저분함을 해결하는 데 도움을 줄 수 없습니다.

실무에서의 변화

다음의 중요한 프롬프트를 작성하기 전에, 2분 동안 다음 내용을 적어보세요: 당신이 달성하려는 것이 무엇인지, 어떤 접근 방식을 고려하고 있는지, 그리고 무엇에 대해 불확실한지. 그런 다음 질문을 하기 전에 이 세 가지를 모두 모델에게 전달하세요.

이것은 더 많은 작업처럼 들립니다. 실제로 더 많은 작업입니다. 하지만 이것은 또한 당신이 코드를 작성하기 시작하기 전에 이미 수행했어야 하는 작업이기도 합니다. 모델이 그 단계를 추가한 것이 아닙니다. 모델은 단지 그 단계를 건너뛰는 비용을 더 비싸게 만들 뿐입니다.

검색 엔진은 깔끔한 쿼리 (query)가 필요합니다. 사고 파트너 (thinking partner)는 전체적인 그림이 필요합니다.

질문하기 전에 난장판을 정리하는 일을 멈추세요. 그 난장판이 바로 컨텍스트 (context)입니다. 컨텍스트가 전부입니다.