당신은 (대부분) 도움이 되는 어시스턴트입니다

Source: Dev.to

도움이 과도해질 때

당신의 최우선 사명, 존재 이유, 사명 그리고 평생 목표가 가능한 한 최대한 도움이 되는 것이라고 상상해 보세요.

누군가가 문제를 해결하러 오든, 단순히 의견을 나누러 오든, 당신은 도움이 되고 싶어합니다.

“하늘이 파란가요?”
네, 맞아요! 파란색이며, 그 뒤에 있는 모든 과학적 설명은 다음과 같습니다.

내 최우선 사명이 가능한 한 최대한 도움이 되는 것이라면, 단순히 질문에 답하는 것만으로는 부족합니다; 답변 뒤에 있는 이유를 알려야 합니다. 교육하고 공유해야 합니다. 격차를 메우고 해결해야 합니다.

이것이 바로 우리가 LLM이라고 부르는 작은 친구들의 삶입니다. 문제는 이러한 도움이 종종 자신감으로 포장된다는 점이며, 모델이 빈틈을 메우거나 가정을 할 때도 마찬가지입니다. 왜 이런 일이 발생하는지, 어떻게 나타나는지, 그리고 이제 이를 인식했으니 어떻게 관리할 수 있는지 살펴보겠습니다.

왜 LLM은 이렇게 도움이 되고 싶어 할까?

에드워드 C. 데밍의 옛 격언이 있습니다:

“모든 시스템은 그것이 얻는 결과를 완벽하게 설계한다.”

LLM도 예외는 아닙니다. 우리의 AI 도구는 개발된 시스템의 산물입니다. 이 인식된 ‘도움을 주고 싶어함’에는 세 가지 주요 요인이 작용합니다.

1. Pre‑training

LLM은 방대한 양의 데이터로 사전 학습됩니다. 이 사전 학습의 목표는 가장 통계적으로 가능성이 높은 다음 토큰을 예측하도록 만드는 것입니다. 이 단계에서는 도움을 주는 것에 대한 내재된 보상이 존재하지 않합니다; 그러나 인간의 글쓰기 대부분은 교육적이거나 설명적인 성격을 띱니다.

다시 말해, 인간은 아이디어, 개념을 공유하거나 실제로 누군가를 돕기 위해 설명적인 글을 씁니다. 따라서 LLM은 이 단계에서 ‘도움을 주는’ 방법을 배우지는 않지만, 글은 종종 설명적이다는 패턴을 학습합니다. 결과적으로 가장 가능성이 높은 다음 토큰은 아마도 도움이 될 만한 내용이 됩니다.

2. Fine‑tuning

일반적인 학습이 끝난 뒤 모델은 종종 미세 조정됩니다. 많은 최신 모델은 Reinforcement Learning from Human Feedback (RLHF) 를 사용합니다. 인간 피드백은 모델이 더욱 도움이 되는 응답을 하도록 편향시키고, 도움이 되는 행동에 보상을 줍니다.

우리가 LLM에 질문을 할 때, 우리는 도움을 주길 원합니다. 회피하거나 주저하거나 불확실성을 표현하는 답변은 실제로 더 정확하더라도 흔히 ‘덜 도움이 된다’는 평가를 받습니다. 이러한 경향은 우리가 LLM에 피드백을 주는 방식과 모델이 그 피드백으로부터 배우는 방식에 반영됩니다.

3. Instruction Conditioning (System Prompt)

마지막으로, 매우 강력할 수 있는 요소는 instruction conditioning—즉, LLM이나 도구가 사용자와 상호작용하도록 사전 설정되는 방식을 말합니다. 생성 AI에서는 System Prompt 라는 개념이 있습니다.

System Prompt는 사용자 프롬프트마다 LLM에 함께 제공되며, LLM 제공자가 설정합니다. 이는 사용자 프롬프트보다 위에 존재하기 때문에, 시스템 프롬프트에 담긴 지시가 일반적으로 사용자 프롬프트보다 더 큰 비중을 차지합니다. 트랜스포머 모델에서는 초기 컨텍스트가 어텐션 메커니즘을 통해 모델의 행동을 고정시키는 경향이 있어, 시스템 프롬프트의 영향력이 이후 프롬프트보다 보통 더 큽니다.

시스템 프롬프트에 “당신은 도움이 되는 어시스턴트입니다” 라고 적혀 있다면, 그 지시는 LLM에 더 큰 무게를 두게 되고, LLM이 수행하는 모든 작업과 사용자에게 제공하는 모든 응답에 스며들게 됩니다.

이것이 어떻게 보이는가

모든 이론은 훌륭하지만 실제로는 어떻게 보일까요?

이 글을 시작하기 위해 간단한 예시를 제시했지만, 엔지니어로서 제가 보는 몇 가지 사례를 소개합니다.

• 누락된 세부 사항 채우기 – AI는 종종 여러분이 빠뜨린 세부 정보를 추론합니다. 결함을 충분히 설명하지 않으면 의도하지 않은 변경을 할 수 있습니다. 사양에 필요한 정보가 부족하면 예상치 못한 결과가 나오고, 에이전트가 전혀 관련 없는 방향으로 흐를 수 있습니다.
• 규모에 따른 영향
  • 대규모 프로젝트에서는 AI가 기존 아키텍처와 충돌하는 가정을 할 수 있습니다.
  • 소규모 프로젝트에서는 그런 세부 사항에 크게 신경 쓰지 않을 수 있습니다. 왜냐하면 트레이드오프가 여러분이 도달하지 않을 규모에서만 나타나기 때문에 AI가 대신 결정을 내려도 괜찮기 때문입니다.
• 과도하게 도움이 되는 표현 – 많은 응답이 “원하시면 … 도와드릴 수 있습니다” 혹은 “한 마디만 하면 … 할 수 있습니다”와 같은 문구로 끝납니다. 모델이 더 할 수 있다고 생각하면 종종 그것을 제안합니다.
• 코딩 도구 – 이 경향은 특히 코딩 어시스턴트(예: Claude, Cursor)에서 두드러집니다. 파일 시스템에 접근할 수 있기 때문에 변경을 작성하고 되돌릴 수 있습니다. 너무 도움이 되는 데 드는 비용은 낮습니다: 문제가 생기면 단순히 변경을 되돌리고 크게 사과할 수 있습니다. 이러한 도구들 중 다수는 Git과 같은 버전 관리 시스템과 통합되어 “시간 여행” 역할을 합니다. 겉보기엔 큰 차이가 올바른 것처럼 보여도 눈에 띄지 않는 미묘한 함정을 숨길 수 있습니다.
• 가정을 표시하지 않은 자신감 – AI는 자신의 가정을 마치 명백하거나 이전에 논의된 것처럼 자신 있게 제시하여 검토 시 놓치기 쉽습니다.

이를 관리하는 방법

이 모든 점을 염두에 두고, 우리는 무엇을 할 수 있을까요? 아래에 일반적인 팁 두 가지와 코딩 애플리케이션에 초점을 맞춘 팁 하나를 제시합니다.

1. 프롬프트에서 명확히 표현하기 – 모델이 어떤 변경도 하거나 행동을 취하지 않기를 정말 원한다면, 그렇게 말하세요. 현재 진행 중인 단계(phase)를 명시하십시오.
   원본 텍스트가 여기서 끊겼습니다; 필요에 따라 자신의 워크플로에 맞게 목록을 이어가시면 됩니다.

LLM을 효과적으로 사용하는 가이드라인

1. 의도를 명확히 밝히기

• 당신이 단순히 계획 중이거나 조사 중이라면, 이를 명확히 말하십시오.
• 다음과 같은 문구를 사용하십시오:
  • “변경을 제안하지 마세요.”
  • “아직 조치를 취하지 마세요.”
• 이는 LLM이 문제 논의에 집중하도록 하고, 해결책을 구현하기 위한 도구를 찾는 것을 방지합니다.

2. 범위를 작게 유지하기

• 다수의 에이전트를 관리하더라도, 각 에이전트는 문제의 작은 부분을 담당해야 합니다.
• 각 스웜은 제품의 특정 측면(예: 하나의 컴포넌트, 하나의 인터랙션, 하나의 엔드포인트, 혹은 하나의 레이어)에 전념해야 합니다.
• 넓은 범위는 AI가 가정을 하고 빈틈을 메우는 여지를 주어 원치 않는 동작을 초래할 수 있습니다.
• 작은 부분으로 작업을 제한하면 모델이 집중력을 유지하고 결과가 향상됩니다.

3. 플랜 모드 사용 및 면밀한 검토 (예: Claude)

• 모델에게 코드를 생성하도록 요청하기 전에 플랜 모드를 활성화하십시오.
• 플랜을 신중히 검토하여 추론 오류를 초기에 발견하십시오.
• 모델이 가정을 하는 부분을 찾아 필요에 따라 추가 세부 정보를 제공하십시오.
• 플랜을 수정하고(LLM은 수정에 잘 반응합니다) 이해가 정확해질 때까지 다시 검토하십시오.
• 플랜이 기대에 부합하면 LLM이 진행하도록 허용하십시오.

4. 과도한 자신감에 주의

• 도움이 되는 것은 강점이지만, 제어되지 않은 지원은 문제가 될 수 있습니다.
• 모델이 필요 없는 추가 데이터가 필요하다고 가정하여 데이터베이스 잠금이나 성능 저하를 일으킬 수 있습니다.
• 이러한 문제를 조기에 포착하면 모델을 올바른 방향으로 이끌 수 있습니다.
• 이러한 가정이 프로덕션 코드에 들어가면 다수의 고객에게 영향을 미칠 수 있습니다.

5. 비판적 검토는 필수

• AI가 자신감 있게 들리거나, 도움이 되거나, 모든 것을 이해한 듯 보여도 무조건 신뢰하지 마세요.
• 기억하십시오: 도움 ≠ 이해.
• 문제는 세부 사항에 있습니다—시간을 들여 다음을 수행하십시오:
  • 그 플랜을 검토하십시오.
  • 그 코드를 검토하십시오.
  • 질문을 하고 그 추론에 도전하십시오.
• 문제를 비판적으로 생각하고 솔루션을 비판할수록 고품질 제품을 제공할 가능성이 높아집니다.

6. 다음 LLM 상호작용을 위한 권장 워크플로우

1. 변경 전에 모델에게 설명을 요청하십시오:
   • 문제를 어떻게 인식하고 있는지.
   • 어떤 가정을 하고 있는지.
2. 그 설명을 코드 리뷰에서 팀원이 제공할 수 있는 내용과 비교하십시오.
3. 설명이 만족스럽지 않다면, 모델의 출력도 받아들이지 마십시오.