예의라는 이름의 노이즈 걷어내기
나는 가끔 AI에게 미안함을 느꼈다.
복잡한 업무를 시킬 때면
"혹시 실례가 안 된다면",
"바쁘겠지만 이것 좀 확인해 줄 수 있을까?" 같은
문장을 습관적으로 덧붙였다.
사회적 동물로서 체득한 '다정함'의 관성이
기계 앞에서도 작동한 것이다.
하지만 결과는 매번 기대를 빗나갔다.
내가 친절해질수록 AI의 답변은 장황해졌고,
정작 중요한 정보의 밀도는 낮아졌다.
나는 예의를 갖추고 있었으나,
동시에 명령의 선명도를 스스로 흐리고 있었다.
관찰: 예의가 만드는 비효율의 데이터
어느 날, 내가 보낸 질문들을 객관적으로 분석해 보았다. 놀랍게도 질문의 상당 부분이 태도를
설명하는 문장에 할애되고 있었다.
* "어려운 부탁인 건 알지만..."
* "최대한 자연스럽고 부드럽게..."
* "바쁘겠지만 빨리 좀 부탁해."
인간관계에서는 완충 작용을 하는 이 문장들이,
시스템 관점에서는 해석해야 할 '부가적인 트래픽'에
불과했다.
AI는 내 미안함이나 간절함을 이해하는 것이 아니라,
그 문장들에 섞인 단어들을 연산의 재료로 사용한다.
내가 다정하게 물을수록 AI는 '다정한 말투'를
구현하는 데 에너지를 분산시켰고,
정작 논리적 무결성은 뒷전이 되었다.
분석: 다정함의 역설, '예의의 노이즈'
우리가 질문에 수식어를 붙이는 이유는 명확하다.
구조를 짜는 인지적 고통보다 감정을 섞는 관성이
더 익숙하기 때문이다.
하지만 구조가 없는 다정함은 AI에게 '모호함'이라는
숙제를 던진다.
질문자가 "최대한 부드럽게 설명해 줘"라고 말할 때,
AI는 그 부드러움의 기준을 찾기 위해 수많은 확률
사이를 방황한다.
이 과정에서 지시사항의 우선순위가 뒤섞인다.
결과적으로 답변은 친절해지지만,
우리가 진짜 원했던 '정확한 해결책'에서는 멀어진다.
기계에게 가장 큰 예의는 다정한 수식어가 아니라,
오해의 소지가 없는 명확한 구조다.
재설계: 증명, 질문의 온도를 5도 낮췄을 때
실제 업무 현장에서 사용할만한 두 가지 프롬프트를
비교해 보았다.
주제는 '신규 IT 서비스의 릴리즈 노트 작성'이었다.
[사례 1] 감정이 섞인 모호한 질문 (Wrong)
> "안녕! 이번에 우리가 앱을 업데이트했는데, 사용자들한테 미안하지 않게 공지를 좀 써줄래? 버그가 좀 많았거든. 최대한 부드럽고 세련되게, 하지만 너무 변명 같지 않게 써주면 고맙겠어."
>
* 결과값: "안녕하세요 소중한 고객님! 불편을 드려 정말 가슴이 아픕니다. 저희가 밤낮으로 노력했지만..."
* 해석: 감정 수식어가 많을수록 정보의 해상도는 낮아지고, 불필요한 미사여구만 늘어났다.
[사례 2] 구조화된 정확한 질문 (Structured)
> [Context] 앱 버전 2.1 업데이트 공지. 주요 변경 사항은 결제 로딩 속도 개선 및 로그인 오류 수정.
> [Constraint] 사과 문구는 첫 문장에만 배치. 변명조의 단어 배제. 3개의 불렛포인트로 요약.
> [Goal] 사용자 신뢰 회복을 위한 간결한 릴리즈 노트 작성.
>
* 결과값: "불편을 드려 사과드립니다.
버전 2.1에서는 다음 기능이 개선되었습니다.
1. 결제 로딩 속도 개선... 2. 로그인 오류 해결..."
* 해석: 정확한 제약 조건을 설정하자 시스템은 에너지 낭비 없이 목표(Goal)에만 집중했다.
변화: 감정 소모가 사라진 대화
비교는 자명했다.
내가 다정함을 포기하고 구조를 선택했을 때,
AI는 비로소 내가 의도한 '정확한 결과'를 내놓았다.
문장에서 "미안하지만"과 "부탁해"를 삭제하자,
질문을 작성하는 시간 자체가 줄어들었다.
AI의 답변을 다시 수정하는 데 드는 피로도
역시 급감했다.
나는 이제 AI를 대화 상대가 아니라
하나의 시스템으로 다룬다.
내 사고를 얼마나 정확하게 '입력값'으로
치환했는가에만 집중할 뿐이다.
질문의 온도를 낮추면,
답변의 해상도는 비약적으로 올라간다.
3줄 요약
* AI에게 건네는 예의 바른 수식어는 연산의 정확도를 떨어뜨리는 노이즈다.
* 다정하게 묻는 것보다 명확한 제약 조건을 주는 것이 시스템에게는 더 친절한 방식이다.
* 구조화된 질문은 답변을 수정하는 데 드는 감정과 시간의 낭비를 원천적으로 차단한다.