Hacker News 의견

• 실제로 LLM 도구를 사용해 본 사람이라면 누구나 경험적으로 알고 있는 내용을 확인해 주는 논문을 보게 되어 기쁨. 대화라는 개념이 제품 인터페이스에서 만들어진 것. 컨텍스트를 깨끗하게 유지하는 것이 중요. 컨텍스트가 오염되면 복구되지 않으므로 새로운 대화로 다시 시작해야 함

  • 내 경험도 이런 관찰과는 비슷하지만, 다소 다른 점도 있었음. 2주 동안 Gemini로 IPSEC 문제를 디버깅했음. 처음에는 OPNsense와 pfSense의 IPSEC 문서를 읽어 들이고 전반적 컨텍스트를 제공함. 이후 설정 정보를 공유하고, 질문·답변을 지속함. 마지막에는 LLM이 산만해지는 일이 줄어들었고, 때로 포럼 글이나 SO 포스팅을 넣었지만 LLM이 “이건 지금 보는 현상과 다르다”고 언급하기도 했음. 모든 막다른 길을 논리적으로 배제했고, LLM이 반성은 도와주지만 결정은 인간이 해야 했음. 최종적으로 문제의 원인을 찾았고, 다른 사용자들이 말한 것처럼 LLM은 복잡한 정보를 단순화하는 데 강점이 있지만 단순한 개념을 복잡하게 확장하는 데는 약함. 입력이 출력보다 더 복잡하거나 길 때 결과에 만족스러움. LLM 없이도 할 수 있었지만 맥락을 기억하거나 빠르게 재현하지 못했던 사실을 저장해주는 점이 유용했음. 대량의 로그에서 시간 패턴을 찾는 데에도 도움됨. 여러 설정도 개선함. 문제 해결뿐만 아니라 많은 것을 배움. 상태 파악이 가끔 틀렸지만 직접 바로잡기 쉬웠음. 즉, 목표를 알고 도구로 활용하면 유용하지만, 결정을 넘기거나 잘못된 방향으로 끌려가면 효과 없음. 35만 토큰(약 30만 단어) 사용함. 관련 블로그 포스트 있음. wireguard 추천은 필요 없음
  • 경험이 완전히 일치함. “오염됨”이라는 표현이 딱 맞음. 무언가 잘못되면 이후 모든 답변이 나빠지기 시작함. 그래서 ChatGPT의 memory 기능이 마음에 안 듦. 커다란 문제는 없지만 맥락 오염이 어떻게 일어나는지 완전히 이해하지 못해 불안함
  • 내가 알려주는 최고의 팁은 ChatGPT와 Claude의 아주 작고 숨어 있는 “편집” 버튼을 적극 활용하라는 것. 나쁜 답변이 나오면 그대로 넘어가지 말고, 멈춰서 수정한 뒤 더 나은 답변을 얻으라는 것. 그렇지 않으면 엉망이 계속 증식함
  • 항상 대화를 포크해서 다양한 방향으로 실험해 보고 싶은 마음이 있음. 유망한 흐름에 돌이킬 수 없는 오염이 발생하는 것을 막고 싶음. ChatGPT에서 이 기능을 못 쓰고 있는데, 혹시 이걸 제공하는 서비스가 있는지 궁금함
  • 이 문제의 흥미로운 예시가 바로 초기 프롬프트. 사실상 영구적이고 숨겨진 컨텍스트. 트위터의 Grok 봇이 최근 “White Genocide”를 자주 언급하는데, 이는 누군가 해당 주제에 부합하도록 프롬프트를 변경했기 때문. 완벽한 챗봇이라면 다른 주제에서 영향을 받지 않아야 하는데 실제론 영향을 받음. 결국 맥락이 바뀌었고, 그 주제에 끊임없이 집착함
  • 그래서 FileKitty를 만들었음. 여러 소스코드 파일을 빠르게 마크다운 형식으로 합치는 도구. LLM에 소프트웨어 개발을 지원받을 때 코드베이스 검색을 LLM에 의존하면 오류 가능성이 커짐. 맥락 압축이라는 손실로 인해 결과물이 희석되기도 함. 특정 컨텍스트를 처음부터 명확히 하고 대화 중간중간 갱신해야 가장 좋은 결과를 얻을 수 있음. 그럼에도 대화 길이에 신경 써야 함. 콘텍스트를 잘 캡처하고 새 세션에 전달하는 프롬프트도 있음. 포함해야 할 파일을 골라 새 프롬프트에 넣기도 함. 관련 논의는 HN의 다른 스레드에서도 참고 가능함
  • 이젠 내 작업 흐름 자체에 이런 패턴이 자리 잡음. 가끔 “좋은 진행, 다음 단계로 넘어가고 싶은데, 이 대화에서 계속할 만한지 아니면 새로 시작해야 하는지?”로 LLM에게 요청함. 모델이 새로 시작하는 게 낫다고 하면 좋은 요약 프롬프트를 준비해주고, 계속해도 괜찮다고 답하기도 함. "앞으로 탐색할 초깃값 모음"이라는 노트를 여럿 만들어 둠. RL 기반 post-training 과정 등 챗봇이 계속 대화를 이어가려는 경향이 있음. RL에서 post-training은 실제 RL과 달리 1회 선호 기반 메커니즘만 사용함. 장기 프리퍼런스나 대화는 계산 복잡성이 기하급수로 증가해 연구가 많지 않음
  • 혹시 대화 기록을 “정리”하는 인터페이스가 구현된 사례가 있나 궁금함. 대화 내에서 죽은 경로나 관련 없는 내용을 정리하는 기능. 전체 내역은 유지하지만, 주제 경로에 따라 불필요한 부분만 가지치기/정돈. 요약이라기보단 유기적으로 정돈됨
  • LLM을 자동완성 용도로만 쓰지만, LLM 채팅 UI에 “메시지 삭제” 버튼이나 옵션을 추가하면 이 문제를 해결할 수 있을 거라 생각함. 마지막 LLM 메시지를 삭제하면 새 답변을 얻을 수 있음. 임의성 높은(temperature) LLM에서 특히 유용. 다른 메시지를 삭제했을 때는 이후 답변에 반영될 수 있도록 맥락을 갱신. 이를 통해 사용자가 LLM이 지능적이라고 착각하는 것도 바로잡을 수 있음. 이미 표준인지 익숙하지 않음. 만약 아니면 이 아이디어를 공개 도메인에 둠. 또 한편으론 “서브컨텍스트 LLM”을 두어서 주 맥락을 관리하는 것도 실용적. 즉, 응답이 너무 길거나 방대한 경우 하위 LLM이 요약/정돈해 전체 대화의 맥락을 다듬는 구조. 또는 단순하게 “메시지 편집” 버튼을 두어 사람이 직접 정리해도 됨
  • 맥락이 오염되면 복구가 어려움. LLM에 특정 부분만 주기적으로 리셋하거나 정화할 수 있다면 개선될 수 있음. 다만 어떤 부분을 정리할지, 핵심 정보를 잃지 않을지가 과제. 더 스마트한 맥락 관리가 길어진 대화의 일관성 유지에 도움이 될 수 있으나 균형 잡기가 어려움. 어쩌면 다른 에이전트가 이를 자동화할 수 있음
  • AI 챗봇에서 chain-of-thought 방식 프롬프트도 동일한 이유로 한계가 드러남
  • “대화”가 오직 프로덕트 인터페이스의 산물이라는 점에 대한 의견. RL의 멀티턴 평가 데이터셋 학습으로 이 부분 흐름이 달라졌음. 컨텍스트 창은 매번 새로워지지만 각 프롬프트를 더 긴 대화의 일부로 해석하는 경향이 늘어남. 공개적으로는 멀티턴 포스트트레이닝이 아직 확장되지 않았으나, 장기적으로 더 많은 목표 달성을 위해 도입될 것 같음
  • 코딩을 할 때도 대화 없이 자주 새 대화를 시작하고 현재 코드를 갖고 다시 설명하는 식으로 접근함. 이는 한 대화에서 계속 두드리는 것보다 더 좋은 결과로 이어질 때가 많음. 수동 명령을 통해 요약과 망각을 모델에 명시하면 문제를 풀 수 있을 듯. 이는 인간의 작동 메커니즘(작업 기억 vs 내러티브/일화 기억)과도 일부 일치함
  • ChatGPT의 가장 답답한 기능 중 하나가 “메모리”. 대화 오염이 채팅 간에도 따라다닐 수 있음
  • “오염됨”은 정말 적확한 용어. 대화/API에서 “버전 관리”를 도입해 예전 상태로 롤백하거나 새 대화로 복제하는 기능이 있었으면 함. 심지어 오타나 메시지 수정도 이후 응답 결과에 미묘한 편향을 준다는 점 때문에 더욱 그러함
  • zed의 채팅 UX를 정말 좋아함. 전체 대화 기록을 텍스트 파일처럼 편집할 수 있어 원하지 않는 부분을 정리, 삭제, 수정보완 후 훨씬 깔끔하고 관련 있는 맥락으로 대화를 이어갈 수 있음. 그래서 zed를 프로그래밍 외 일에도 LLM 대화용 주요 인터페이스 중 하나로 씀
  • 오염은 엉뚱한 질문이나 답변, 거듭된 “희석”을 통해서도 발생함. 콘텐츠를 생성할 때도 처음엔 명확했던 지시가 점점 흐트러지는 것을 자주 경험함
  • “대화란 오직 제품 인터페이스의 산물”이라는 점을 늘 염두에 두려 하지만 실전에서는 다양한 “대화체” 단서 때문에 쉽지 않음
  • 메모리를 켜 둔 걸 후회했음. 쓸데없는 정보로 대화가 오염됨
  • 놀라운 점은 모델이 얼마나 초기에 잘못된 가정을 하면서 고착화되는지
  • 사람도 생각해보면 이런 일 많이 벌어짐
  • 이제 ChatGPT가 “메모리”를 통해 예전 대화에도 접근할 수 있기 때문에 오염이 영구적일 수 있음. 한 번 잘못된 아이디어를 잡으면, 사용자 입장에서 절대 다시 언급하지 말라고 몇 번을 강조해도 그걸 계속 답변에 집어넣는 일이 반복됨. 내부 프롬프트(“사용자가 매우 불만임, xyz를 빼야 함”)까지 실수로 출력되어서 결국 xyz만 집중적으로 언급하는 웃긴 상황이 발생함

• 이건 LLM이 잘 알려진 과신 경향, 자기반성의 부재, 더 많은 정보를 요청해야 할 때 그걸 인식하지 못하는 것에서 비롯된 현상. 추론 모델 결과를 보면, 혼란스러운 경우 LLM이 추가 설명을 요청하지 않고 사용자가 무슨 뜻을 원했는지 추측만 반복함. 이것은 인간 프로그래머를 대체하자는 발상의 현실적 한계를 보여줌. 진짜 어려운 부분은 모호한 요구를 명확하게 바꿔가는 “이해관계자와의 상호작용”이기 때문

  • 자기반성 불가 능력 관련, LLM엔 실제 주체가 없으며 사용자는 일종의 “믿음유지 스토리”에 빠지는 것. 대부분 영화 대본의 사용자 역할로 텍스트 입력을 남기면, LLM은 챗봇 역할로 불완전한 줄거리를 자동완성할 뿐. 예를 들어 드라큘라봇과의 인터뷰는 자기반성을 “피를 갈구”하거나 “박쥐 구름이 되는 것”처럼 표면적으로만 흉내냄
  • LLM이 정보가 애매한 오픈엔드 문제 상황(특히 패러독스)에서 명확하게 추가 설명을 요청하지 못하는 점에 동일하게 실망함. DeepSeek-R1과 Claude-3.7-Sonnet에서 테스트했고, 관련 실험 블로그도 있음
  • Gemini 2.5 Pro와 ChatGPT-o3는 종종 작업을 실행하기 전에 추가 정보를 요청함. Gemini는 여러 옵션도 제시하면서 내 입력을 요구하기도 함
  • 진짜 프로그래머들은 실제로 대부분의 시간을 요구 사항을 명확히 파악하는 데 씀. LLM은 아직도 추측 그 자체를 하나의 기능으로 취급함
  • 아이러니하게도 초보 개발자와 일할 때도 비슷함. 작업을 맡기면, 오로지 직진하며 가정만 하고 아무 질문 없이, 결국 구조대가 가서 꺼내야 할 만큼 깊은 숲에 스스로 빠지는 일이 다반사
  • 이것은 꽤 쉽게 바꿀 수 있다고 생각함. chain of thought 프롬프트 방식이 마지막 토큰을 “흠”으로 바꾸듯이, LLM이 “아마도 ~일 것 같다”는 식으로 말 나오면 “먼저 추가적으로 설명을 요청하겠다”로 토큰을 바꾸면 됨
  • 추가 정보 요청이나 자기반성도 요청만 하면 충분히 잘할 수 있음

• LLM에게 지금까지 논의 내용을 간결한 프롬프트 형식으로 요약하게 한 뒤 직접 수정·편집해서 새로운 대화를 시작하는 기법을 즐겨 사용함. 이 방법이 꽤 효과적이었는데, 머지 않아 자동화될 거라 생각함

  • Cursor는 이걸 자동으로 시도했는데, (대형 맥락 모델을 쓰지 않는 한) 요약된 내용이 디테일을 너무 많이 놓쳐 실전엔 별로였음
  • Claude Code엔 /compact 명령이 있어 대화를 요약해 토큰 사용량을 줄여줌

• TSCE(Two-Step Contextual Enrichment)를 직접 고안함. GPT-35-turbo에서 300개의 과제에 활용 시 성능이 +30pp 향상됨. 오픈 프레임워크로 자유 이용 가능함. gpt-4.1로 300회 추가 실험했음. baseline은 em-dash 제거를 149/300번 실패, TSCE는 18/300번 실패. 전체 데이터와 스크립트도 공개함

  • 단순한 find and replace 작업에 킬로와트시가 낭비됨. text.replace("—", "-") 같은 걸 써봤는지 궁금함
  • baseline 프롬프트를 조금만 바꿔도 GPT-4.1에서 100% 성공률을 얻었음. 추가 호출이나 토큰 지출, 복잡한 테크닉 없이도 가능함

• 두 시스템(LMM + 자동 curator)으로 고민을 푼 경험이 있음. 하나는 LLM 자체, 다른 하나는 ‘사고의 큐레이터’로 맥락 일부분을 유동적으로 교체 관리함. 명확한 규칙이 아닌 LLM의 채우기 능력에 기반. 문제를 작게 분할해 처리하도록 돕고, 이 결과가 모여 최종 목표를 달성함

  • 멋진 아이디어. 현재 하는 일은 대화 RAG와 유사해 보임. 미래엔 메모리 계층 구분(트레이닝 데이터 / 현재 컨텍스트 / RAG)이 더 명확해질 것
  • 흥미로운 아이디어라 생각. 간단하게라도 세계에 공유하면 많은 사람들이 개선하면서 커뮤니티가 스스로 키워나갈 수 있음
  • 이는 Emotion Machine에서 말하는 내적 비평 시스템과 유사함
  • 만드는 프로젝트에 대해 더 많은 정보를 알 수 있으면 좋겠음. 흥미로워 보임
  • 그래서 결과적으로 Map-Reduce-of-Thought라고 할 만함

• 메인 챗도구에서 브랜칭/포킹이 기본이 아니라는 게 신기함. 답변을 편집할 순 있긴 한데, 이 경우 다른 맥락이 많이 사라짐. 내 작업 흐름은 1. 계획 2. 빌드 3. 브랜치 4. 반복. 프롬프트 가지치기/브랜칭이 LLM 활용의 핵심 도구가 되어야 한다고 생각함

  • Google AI Studio에는 적어도 이 기능이 있음. 하지만 구현이 혼란스러웠고, 이게 더 많이 보급되지 않은 이유일 수도 있다고 생각함
  • 예전부터 직접 이런 걸 만들고 싶었음. BetterChatGPT는 최소한 이력 삭제 인터페이스가 좋지만 나도 브랜칭이 다음 단계라고 봄

• LLM 인터페이스가 단일 턴 대화 중심으로 설계되면 문제가 생김. 대부분의 사용자는 선형 대화를 기대함. 그래서 Telegram 봇 experai_bot을 만들어 LLM의 유니버설 UI로 삼았고 “답장이 아니면 새 대화”라는 접근을 사용함. 맥락을 유지하려면 꼭 답장 트리 구조로 이어나가야 함. 비전문가들은 이 방식을 이해하는 데 어려움을 느낌. 또 OpenAI 모델(3.5, 4o 기준)이 같은 질문을 반복할수록 공백이나 옵션이 짧아지면서 점점 결과가 부정확해짐. 시스템 메시지를 최소화해야 비교적 결과가 유지됨. 필요하면 옵션으로 시스템 메시지 추가 가능

• promptdown을 만든 주 이유가 전체 채팅 이력을 턴마다 완전히 편집할 수 있게 하려는 것. 표준 인터페이스의 ‘append-only’ 구조는 이런 것을 어렵게 함

• 현 시점 LLM 분야는 모두가 똑같은 문제를 반복해서 풀고 있는 느낌

  • 멀티턴 대화에서의 LLM처럼 모두가 같은 문제를 반복하고 있음
  • “학습”이 아닌 “고양이 몰이” 현상이지만 일부 작업 흐름엔 이게 적합함
  • 모두가 자신만의 프롬프트 엔지니어링 실력을 뽐내고 싶어함

• LLM은 정말 병 속의 지니 같음. 세 번 질문엔 답해 주지만 그 이후부턴 엉뚱한 소리만 하는 현상