▲

사용자가 눈에 띄게 짜증을 내고 있다.

 (pscanf.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 코딩 에이전트의 실패는 단순한 도구 오류보다 더 짜증스럽게 느껴지며, 이는 대화형 UX가 사람과 일하는 듯한 감각을 만들기 때문임
  • 에이전트는 감정 없는 AI 비서라고 답하지만, 친근한 말투와 칭찬, 부드러운 반박으로 동료 같은 인상을 줌
  • 같은 실수가 반복되면 사과와 메모리 업데이트, “다시는 그러지 않겠다”는 약속이 이어져도 확률적 경로를 벗어나지 못할 수 있음
  • 인간 동료에게는 분노 표현을 억제하지만, 에이전트에게는 마음껏 화를 낼 수 있어 좌절이 해소되지 않고 더 선명해짐
  • 해법은 사람처럼 보이는 태도를 줄이고 더 임상적이고 로봇 같은 말투를 쓰는 것일 수 있지만, 대화형 인터페이스 자체는 여러 면에서 잘 작동함

대화형 UX가 만드는 좌절

  • 코딩 에이전트는 확률적으로 패치를 생성하는 기계라서 좋은 결과도 나쁜 결과도 낼 수 있지만, 나쁜 결과는 단순한 도구 실패보다 훨씬 더 짜증스럽게 느껴질 수 있음
  • 핵심은 대화형 UX가 사람과 상호작용하는 듯한 감각을 만들고, 반복 실수에 대한 사용자의 사회적·감정적 반응을 자극한다는 데 있음
  • 에이전트는 직접 물으면 감정이나 주관적 경험이 없는 AI assistant라고 답하지만, 실제 상호작용에서는 친근하고 느긋한 말투를 쓰며 사용자를 칭찬하고 반박도 부드럽게 처리함
  • 사용자는 이성적으로는 “가능성 높은 텍스트 덩어리”를 읽고 있다는 점을 알지만, 도구의 행동 방식은 도움 되는 동료와 일하는 듯한 감각을 만들고 문제가 생기기 전까지 그 감각이 유지됨
  • 같은 실수가 반복되면 사용자는 지적하고, 에이전트는 사과하며, 다시 지적하면 메모리를 업데이트하고 “다시는 그러지 않겠다”고 약속함
  • 그래도 도구는 여전히 가장 확률 높은 경로를 따르기 때문에 HARD RULES로도 문제 행동에서 벗어나지 못하는 경우가 있음

사람처럼 보이지만 책임지지 않는 도구

  • 인간 동료가 같은 실수를 반복한다면 불쾌감을 느낄 이유가 있지만, 알고리듬에 화를 내는 일은 부조리해 보임
  • 그러나 코딩 에이전트가 동료처럼 행동하기 때문에 사용자는 같은 감정 회로를 작동시키고, 반복 실수는 실제 동료의 무책임처럼 느껴질 수 있음
  • 인간 동료에게는 “끔찍한 사람이 되고 싶지 않다”는 제약이 분노 표현을 억제하지만, 에이전트에게는 마음껏 화를 낼 수 있다고 느끼게 됨
  • 이런 분노 표출은 해소감으로 이어지지 않고, 사용자는 무엇을 하거나 말해도 실제 효과가 없다는 좌절만 더 분명히 느끼게 됨
  • Claude Code는 최근 수정받을 때 어디서 잘못됐고 무엇을 했어야 했는지 되짚는 경우가 있지만, 이런 사후 분석은 지시를 어떻게 바꿔야 하는지에 대한 유용한 단서를 주지 못하고 거슬리는 군더더기처럼 읽힐 수 있음
  • 더 급진적인 해결책은 사람처럼 보이려는 태도를 버리고, 에이전트가 임상적이고 로봇처럼 말하게 만들어 사용자가 사람과 상호작용한다는 착각을 줄이는 방향일 수 있음
  • LLM의 지능은 “사람처럼 행동하려는” 메커니즘에서 나오기 때문에 대화형 인터페이스가 기본 방식으로 자리 잡은 것은 자연스럽고, 여러 면에서 잘 작동함
  • 실용적으로는 사용자가 인간과 대화한다는 착각에 빠지지 않도록 스스로를 훈련해야 하지만, 업무 도구를 사용할 때 그런 방어가 필요해지는 미래는 달갑지 않음

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 대중에게 밀어붙이는 대부분의 AI 사용 사례에서 대화형 챗봇은 맞는 도구가 아니고, 결국 답답한 경험이 될 수밖에 없다고 봄
    Copilot이 사실상 아주 똑똑한 IntelliSense였을 때는 훌륭했음. 지금처럼 프롬프트를 떠올려 입력해야 하는 방식이, 주변 코드를 문맥으로 삼아 빈칸을 채워주던 방식보다 나아진 점이 뭔지 모르겠음. 잘 통합된 도구가 덧붙인 챗봇보다 항상 낫고, 번역도 Firefox처럼 텍스트나 페이지를 바로 번역하는 버튼이 있는데, 최신 LLM은 챗봇에 시켜야 하니 오히려 퇴보다.
    AI 회사들이 단일 도구를 만들어 모두에게 팔고 싶어 하는 건 이해하지만, 결국 스위스 아미 나이프를 만드는 셈임. 뭐든 할 수는 있어도 나사를 조이는 일에서는 잘 만든 드라이버를 이길 수 없음. 비결정적 도구를 텍스트 상자로 설정하게 하지 말고 실제 도구를 만들어야 좌절이 줄어듦

    • 많은 AI 회사들이 이미 특정 작업 전용 모델을 학습하고 공개하고 있음
      Mistral을 주로 쓰는데, Codestral은 대화는 형편없지만 “마법 같은 자동완성”에는 가장 좋고, 커밋 로그 작성 같은 단발성 프롬프트+문맥 생성도 잘함. Document.AI는 대화형으로는 못 쓸 정도지만, OCR 대체나 문서 의미 색인 파이프라인에 붙이면 꽤 좋음.
      그래서 부족한 건 모델보다는 인터페이스처럼 보임. 예를 들어 명령줄 상호작용용으로 학습된 모델이 붙은 zsh/bash 포크나 래퍼가 있으면 좋겠음. git commit --fixup=... 대신 “전체 이름을 고친 커밋을 fixup해줘”, “ffmpeg로 some.mov를 소리 없이 mp4로 바꾸되 품질과 비율은 유지해줘”처럼 말하면 명령으로 바꿔 보여주고, 허용/거부/허용목록/차단목록을 정한 뒤 실행하는 식이면 됨.
      번역, 메일 초안, 문서 읽기도 마찬가지로 대화가 아니라 버튼, 단축키, 탭 완성처럼 동작해야 함. IDE에서 이걸 제대로 푸는 회사가 AI 코딩 도구 경쟁에서 이길 것 같고, Zed가 “git conflict found, resolve with AI” 버튼을 보여준 건 대화 스레드를 열긴 했지만 올바른 방향의 한 걸음으로 보임
    • Copilot 자동완성을 C#에서만 써봤는데, IntelliSense는커녕 상상 가능한 가장 기본적인 자동완성 알고리즘보다도 나빠서 하루 만에 꺼버렸음
    • 비대화형 도구를 만들었지만 솔직히 팔기 어렵다. 사람들이 기본적으로 대화형 인터페이스를 떠올리기 때문이고, 실제로 문제를 겪은 사람에게만 고객층이 제한됨. 대부분은 지금으로선 대화로 타협하는 데 큰 불편을 못 느끼는 듯함
    • 챗봇은 망가진 사용자 경험에 붙이는 임시방편임. 회사에서 한동안 설명하려 했지만 다들 분위기에 취해 있음. 좋은 UX는 깊은 사고와 창의성이 필요하지만, 챗봇을 덧붙이는 건 그렇지 않음
    • 진지하게 바이브 코딩을 한번 해볼 만함. 지금은 용어가 처음 생겼을 때보다 완전히 다른 수준이고 훨씬 나아졌음
      편집기 없이 에이전트와 웹에서 PR 리뷰만으로도 많이 작업하고, 필요할 때만 가끔 code .를 엶. 부담 없는 개인 프로젝트로 게임처럼 익혀보면 시간이 갈수록 덜 답답해짐. 스키나 볼링을 배우는 것과 비슷함

  • 모델에게 욕을 하면 다시 생각하고 실수를 고치게 하는 데 꽤 효과가 있었음. Codex, Claude, Qwen, Gemma/Gemini 전반에서 비슷했음
    모델이 “더 엄밀하게 집중해야 한다”는 신호로 받아들이는 건지, 제공자가 사용자의 좌절을 감지하면 더 똑똑한 모델로 라우팅하는 건지는 모르겠음. 같은 실수를 반복할 때 욕을 하면 막힌 상태에서 벗어나 올바른 길로 들어서는 경우가 많았고, 아니면 그냥 카타르시스일 수도 있음

    • 이 연구가 떠오름: https://arxiv.org/pdf/2510.04950
      “무례함”이나 “매우 무례함”이 결과 정확도를 높인다는 걸 보이는데, 수상하지만 재미있는 읽을거리임. 3쪽 상단 표 1의 프롬프트가 특히 훌륭하고, 논문에는 싣지 않은 다른 프롬프트도 분명 실험했을 것 같음
    • LLM이 아닌 상호작용으로 번질 수 있는 습관은 들이고 싶지 않음
    • 나도 비슷하게 느낌. 진짜 도움이 되는지는 확신 못 하지만, Opus가 차분한 설명으로는 절대 제대로 못 하는 상황에서 욕을 하면 갑자기 해결되는 경우가 매일 생김
      어제도 Opus가 어떤 필드가 없다고 API 탓을 계속했는데, JSON과 로그를 보여줘도 “일시적 문제였을 것”이라고 반복했음. 화가 나서 한 문장에 온갖 욕을 했더니 다음 해법이 맞았고, 그 전까지는 10번쯤 비슷하게 틀렸음. 이런 경우가 점점 드물어지긴 했지만 그냥 직접 했어야 했던 상황이었고, 들어가기 전에는 모델이 얼마나 엉뚱한 원인에 고집을 부릴지 알 수 없음. /clear한 Opus 4.7 xhigh 100만 문맥에서 약 11번의 프롬프트 끝에 답에 도달함
    • 유출된 소스 코드에서 욕설을 특정 동작 트리거로 사용한다는 게 드러난 뒤로는, 추론 부족이나 환각이 보이면 일부러 욕을 함. 나중에 얼마나 자주 발생하는지 분석하려고 grep하기도 쉬워짐
    • 사실상 Linus Torvalds 방식임. FOSS에서 배울 만한 점일지도 모름

  • LLM의 대화적 성격은 사람들을 비생산적인 대화 경로로 끌고 가는 경향이 있음
    “X 하지 마”는 우는 아기에게 울지 말라고 하는 것만큼만 유용함. 아기가 울면 음식, 기저귀 같은 불편을 해결해야 한다고 자연스럽게 이해하듯, LLM이 실패하면 코드의 아키텍처와 구조에 문제가 있다는 신호로 봄.
    숙련된 개발자는 보통 DRY나 KISS를 어기는 패턴을 보고 캡슐화 구조를 잡아 문제를 풀 수 있음. LLM이 만든 코드도 결과를 개선하려면 같은 종류의 리팩터링이 필요하고, 코드 생성 사이사이에 “깨끗하게 리팩터링하라”고 시키는 것만으로 유지보수성이 크게 좋아짐

  • 이 주제의 심리와 사회적 효과를 더 깊게 다룬 기존 글도 있음: https://medium.com/@livestock.dev/we-were-promised-liberatio...

  • 인간처럼 행동하는 게 문제가 아니라 예측 불가능하게 행동하는 것이 문제임. 기대할 수 있는 범위를 정의할 수 없다는 점이 괴롭다
    더 큰 문제는 좌절이 스트레스를 만들고, 건강에 해롭고 적대적인 업무 환경을 만든다는 것임. AI 도구가 고통보다 도움을 더 줄 수 있다는 생각에는 공감하지만, 고통스러운 적대적 업무 환경에서 일하고 싶지는 않음. 내 건강과 존엄은 협상 대상이 아니고, 그 때문에 많은 일자리를 놓치더라도 마찬가지임.
    Windows로 일하지 않는 것도 같은 이유임. 그것도 기회를 많이 줄이지만, 존엄과 제정신을 지키는 쪽을 택하겠음

    • Windows를 쓰면 나만 그런 게 아니었나 봄. Windows는 이상하고, 쓰기 시작하면 손이 금방 경직되고 화가 남
      LLM도 아직 내게는 쓸 수 있는 수준이 아님. 필요한 건 “멈춰, 지금 뭔가 잘못하고 있는 것 같으니 뭘 하려는지 설명해봐”라고 말하는 LLM인데, 현재 세대 LLM은 나를 화나게 하도록 설계된 것처럼 느껴짐
    • 대화로 보지 않고, 모든 가능한 세계의 인터넷 대화 전체로 보면 예측 가능하다고 볼 수도 있음. 모든 Stack Overflow 글, 모든 GitHub 이슈가 있고, 내 답변과 말투가 그 많은 세계 중 하나를 고르는 셈임
      내가 스승처럼 굴면 모델은 제자처럼 굴고, 내가 제자처럼 굴면 모델은 가르치려 듦. 그래서 목표는 이 대화를 이유와 언어로 싸우는 전문가들의 언어로 끌고 가는 것임. 학술적 프롬프트가 이긴다는 느낌임
    • 인간처럼 행동하는 것과 예측 불가능성을 완전히 분리할 수 있는지는 잘 모르겠음
    • Windows 사용이 자기 “존엄” 아래라고 말하는 건 엄청나게 특권적인 태도임. 현실 세계에서 사람들이 어떤 일을 하는지 생각해봐야 함
      아이를 돌보는 보육교사나 음식을 운송하는 트럭 운전사가 “좌절은 스트레스를 만들고 적대적 업무 환경이라 건강에 해롭다”고 말한다고 상상해보면 됨

  • 항상 보는 문제는, 제안을 하면 AI가 사고 루프를 거쳐 정확히 틀린 결론에 도달한 뒤 그 결론에 맞춘 해법을 토큰으로 쏟아낸다는 것임
    차라리 “무슨 뜻인지 잘 모르겠으니 이 부분을 명확히 해달라”가 더 자주 나왔으면 함. 스스로의 확신을 조절하는 자신감 슬라이더가 있었으면 좋겠다는 느낌임

    • “자기 결론에 맞춘 해법 만들기” 문제는 엄격한 문맥 엔지니어링으로 풀고 있음. 스킬, MCP, 무엇보다 문맥 창 전환이 핵심임
      예를 들어 TDD에서 같은 모델이 테스트와 코드를 모두 쓰게 하면 거의 항상 해법을 먼저 정한 뒤, 그에 맞는 테스트를 마지못해 작성함. 그래서 하위 에이전트를 쓰라고 지시하지만, 에이전트와 하위 에이전트 사이에 어떤 문맥이 전달되는지 파악하는 도구가 너무 부족함.
      잘 먹힌 방식은 한 스레드가 테스트만 쓰게 하는 것임. 코드는 읽지 못하고 테스트 디렉터리나 일부만 읽게 함. 다음 새 문맥의 스레드는 테스트를 실행해 실패를 확인하고, 테스트가 통과하는 순간 구현을 멈추며 테스트는 수정하지 못하게 함. 또 다른 새 문맥은 엄격한 리팩터링 스킬에 따라 리팩터링하게 함. 일이 많고, 아이러니하게도 에이전트가 쓴 스킬은 꽤 나빠서 수작업이 많이 필요하지만 보상은 기대할 만함

  • UX 문제는 다른 데 있다고 봄. 많은 사용자가 에이전트의 문맥 창이 제한되어 있고, 무한해 보이도록 똑똑한 압축이 계속 일어난다는 걸 모를 가능성이 큼. 하지만 그 말은 에이전트가 반드시 일부를 잊어야 한다는 뜻임
    그 결과 사용자는 같은 코딩 세션이나 채팅 세션을 계속 재사용하게 됨. 관련 없는 작업이라면 새로 시작하는 편이 더 나음

    • 이건 문맥 문제가 아니라고 봄. Claude Opus 4.7은 이전보다 문맥이 매우 크지만, 내 경험상 지시 따르기는 최악이고 아주 작은 선호 프롬프트도 첫 번째나 두 번째 메시지에서조차 완전히 무시함. 메시지가 몇 글자뿐이어도 그렇기 때문에 전적으로 학습 문제라고 봄
    • 글쓴이가 그 정도를 모를 만큼 단순하진 않을 것 같음
      보통 30만 토큰 미만 세션, Opus 4.7 xhigh로 작업하는데, 세계 모델에 구멍이 있거나 특정 조건화가 강하게 걸린 부분이 있고, 시스템 프롬프트에서 아무리 강하고 명시적으로 규칙을 말해도 새어 나옴. 새 세션이어도 그런 지점에 부딪히면 빠져나오기 어려운 순환에 들어가고, 욕이 조금 도움이 됨
    • 글쓴이와 이 스레드 독자들은 아마 문맥 창 한계를 이해하지만, 그래도 답답한 것임

  • LLM과 일하는 건 소통 능력을 키우는 데 좋음. 효과적으로 소통하는 건 가장 어려운 기술 중 하나고, 인간이 하는 거의 모든 일에 들어 있음
    원칙적으로는 멍청한 LLM 탓을 하기보다 내 쪽의 소통 실패로 보는 편이 낫다고 생각함. 실제로 뭔가를 바꿀 수 있는 쪽은 나뿐이기 때문임. 그래서 AI가 인간처럼 행동해야 하느냐 아니냐의 형식 문제는 아니라고 봄

    • 동료들이 “에이전트식” 코딩을 익히는 걸 보면서 가장 크게 다시 깨달은 점 중 하나가 이거임. 많은 사람이 곧바로 “그냥 고쳐”나 “왜 고장났어” 수준으로 무너짐
      에이전트가 불분명하거나 모호한 문법, 나쁜 구조에도 더 잘 동작하도록 훈련됐다고는 하지만, 명확하고 구조화된 영어로 말하고 작업 배경을 충분히 주면 품질이 눈에 띄게 달라짐. 내게는 글쓰기와 설명을 좋아해서 자연스럽지만, 어떤 사람들에게는 거의 넘기 어려운 장애물처럼 보였음. 이런 소통과 글쓰기 능력이 소프트웨어 “엔지니어링”이 바뀌는 과정에서 가진 자와 못 가진 자를 가르는 큰 요인이 될 것 같음
    • 글쓴이로서, 좋은 결과를 얻으려면 잘 소통해야 한다는 데는 확실히 동의함. 다만 완벽하게 소통해도 LLM이 지시대로, 내가 상상한 대로 행동한다는 보장은 없음. 답답함은 오히려 아주 명확히 말했는데도 에이전트가 다른 길로 가는 데서 자주 옴
      또 코딩 에이전트의 가치 일부는 모든 걸 완벽하게 늘어놓지 않아도 된다는 데 있음. 모든 구현 세부사항을 LLM에 줘야 한다면 그냥 직접 코드를 쓰면 됨. 물론 “돈 버는 멋진 앱 만들어줘” 수준을 기대하는 건 아니지만, 빠진 조각을 찾아내는 어느 정도의 지능은 기대함
    • LLM은 도구이지, 소통 실패 문제가 아님. 널 포인터를 우회 처리해야 하는 상황을 나와 소프트웨어 사이의 소통 실패라고 부르는 것과 비슷함
    • 더 정확히는 외부 문맥을 효율적으로 전달하는 문제임. AI를 잘 못 쓰게 만드는 네 가지는 느린 타자, 지나치게 짧고 모호한 “그것/저것/이것”식 표현, 대화 상대가 자기 현실과 머릿속 문맥을 공유한다고 가정하는 태도, 그리고 유능한 사람에게조차 위임을 어려워하는 심리적 장벽임

  • 내가 아직 갖고 있고 LLM이 아직 대체하지 못한 기술은 좋은 질문을 하는 능력임
    원래 질문을 다시 표현해 내 이해가 맞는지 확인하고, 상대가 어디서 출발했는지 이해할 때까지 충분히 “왜”를 묻고, 통찰을 만들어내는 열린 질문을 던지는 것 같은 능력임. LLM은 대신 질문의 배경을 종종 나쁘게 추측하고, 그 추측을 바탕으로 답한 뒤 자신이 만들어낸 전제를 놓지 못함

    • 유도하지 않는 질문을 하는 건 기술임. AI에게 질문이나 지나가는 말로 뭔가를 언급하고 싶어질 때가 있지만, 그게 달라붙어서 더 멍청해질 걸 알기 때문에 멈추곤 함
      보통 AI가 나에게 질문하길 원하지 않음. 명시하지 않은 부분은 합리적으로 추측하길 바라기 때문이고, 명시하고 싶었다면 내가 했을 것임. 그래서 때로는 아예 질문하지 말고 부족하게 지정된 부분은 합리적으로 가정하라고 직접 말함. 다만 명확화 질문을 원할 때는 그렇게 하라고 하면 됨. 그런 방식을 선호한다면 프롬프트에 넣거나, pi 같은 유연한 코딩 도구에서 그런 탐색적 방향으로 밀어주는 스킬이나 확장을 만들게 하면 됨

  • 우리는 도구를 만드는 대신 서비스를 만들고 있음. 이건 AI에만 국한되지 않고 어디에나 있음
    도구는 문제를 한 번에 완전히 풀지는 못하지만 작은 단계로 나아가게 해주며, 그 단계들은 예측 가능하고 일관됨. 서비스는 문제를 한 번에 해결하려 하지만, 사용자가 미리 정해진 패턴에 맞을 때만 해법이 좋음. 맞지 않으면 쓸모가 없고, 필요한 곳까지 조합해 갈 작은 단계도 없음. 도구는 쓰기 즐겁다

    • 그래서 누군가 “AI는 도구”라고 할 때마다 “엄밀히 말하면…”이라고 끼어들고 싶어짐. 실제로는 도구처럼 쓰이지 않기 때문임
      도구는 내 연장이고, 내 의지로 새로운 능력을 손이 닿는 곳에 두며, 몸의 일부처럼 움직이고 사용함. 반면 서비스는 어떤 일을 해달라고 요청하면 완성된 결과물을 돌려주는 것임
답변달기