경험 많은 LLM 사용자지만, 실제로는 자주 사용하지 않는 이유
(minimaxir.com)- 저자는 10년 넘게 LLM과 텍스트 생성 기술을 연구했지만, 예상 외로 실생활에서는 LLM을 자주 사용하지 않는다고 밝힘
- LLM 사용 시에는 프롬프트 엔지니어링, 시스템 프롬프트 설정, 온도 조절 등 세심한 제어를 중시하며, 일반 프론트엔드 대신 API 기반 접근을 선호함
- 데이터 라벨링, 기사 클러스터 요약, 스타일 가이드 검토 등 BuzzFeed 업무에서 구체적인 문제 해결에 LLM을 활용했으며, 큰 시간 절약 효과를 입증함
- 글쓰기에는 LLM을 사용하지 않지만, 가상의 Hacker News 댓글을 통해 비판 관점 테스트 방식으로 글의 논리 검증에 활용함
- LLM은 코딩 보조에 유용하지만, 복잡하거나 신뢰성 필요한 작업에는 직접 구현을 선호하며, 에이전트와 바이브 코딩에 대해서는 회의적인 입장을 유지함
나와 LLM의 거리
- 저자는 오랫동안 RNN 기반 텍스트 생성, GPT-2 튜닝, GPT-3/ChatGPT 실험 등 생성형 AI 도구 활용 경험이 풍부한 데이터 사이언티스트임
- 하지만 직접적으로 자주 사용하는 경우는 드물며, 사용 여부는 작업의 성격과 필요에 따라 결정하는 도구적 접근임
LLM을 제어하는 방식
- 프롬프트 엔지니어링을 통해 원하는 출력을 유도하는 것이 LLM 사용의 핵심임
- 일반 프론트엔드(ChatGPT.com) 대신 직접 API를 호출하거나 백엔드 UI를 통해 사용, 특히 Claude Sonnet API를 선호함
- 시스템 프롬프트와 온도(temperature) 조절을 통해 창의성과 결정성의 균형 조절, 보통
0.0 ~ 0.3으로 설정하여 출력 예측 가능성 확보 - Hallucination 문제(사실이 아닌 내용 생성) 는 온도가 높을수록 심해지는 경향이 있어 주의함
업무 활용 사례
-
BuzzFeed 기사 분류 자동화: Claude API와 JSON 기반 분류 체계,
temperature 0.0설정으로 정확한 카테고리 할당 수행 - 기사 클러스터 요약: 유사 기사 5개를 제공하고 공통 제목과 설명 반환, 효율적 클러스터 요약 자동화 구현
- 문장 부호 및 스타일 가이드 검토: 스타일 가이드 전체를 시스템 프롬프트로 넣고 정책에 근거한 문법 판단 수행
- 각 작업은 수시간 내로 POC 완성 가능, 기존 방식 대비 수일 이상의 시간 절감 효과 입증
글쓰기는 직접, 비판은 LLM으로
- 블로그 글은 직접 작성하며, 스타일상 LLM이 재현하기 어려운 특이성 있음
- 그러나 LLM에게 Hacker News 유저처럼 비판적인 댓글 작성 요청을 하여 논리적 허점 탐색 도구로 사용
- 이 방식은 글의 퀄리티 향상에 기여하나, LLM이 글을 대체하는 것은 아님
코딩에 있어서의 LLM 활용
- 정규표현식 작성, Pillow 이미지 합성 등 복잡하지만 반복적인 작업에서 LLM은 생산성 향상에 크게 기여함
- 반면에 Polars 같은 최신 라이브러리 사용 시 LLM이 pandas 함수로 착각하는 등 문제가 발생함
- Copilot 같은 실시간 코드 추천은 정신적 컨텍스트 전환이 잦아 오히려 집중을 방해한다는 이유로 비선호함
- LLM이 제안한 아이디어에서 "아이디어 차용 + 직접 수정"이 더 낫다는 입장을 견지함
Agents, MCP, Vibe Coding에 대한 견해
- MCP와 Agents는 개념적으로는 개선되었지만, 실질적으로 새로운 유즈케이스를 제공하지 못함
- Vibe Coding은 취미성 프로젝트에는 유용할 수 있으나, 정식 제품에는 부적절하며 책임 회피 수단으로 사용해선 안됨
- 신뢰할 수 있는 코드만이 프로답다는 입장을 강조함
LLM 산업과 윤리에 대한 생각
- "LLM이 무용하다"는 주장은 실사용 측면에서 현실을 반영하지 못함, 오히려 단기 ROI와 산업구조 문제가 핵심임
- 오픈소스 모델과 대안 인프라(Cerebras, Groq 등)는 OpenAI가 사라지더라도 LLM 수요를 충족시킬 수 있음
- 결국 LLM은 목적에 맞게 적절히 사용하는 도구이며, 무조건적인 찬양도, 부정도 모두 위험함
마무리
- LLM은 둥근 구멍에 정사각형 못을 억지로 밀어 넣는 도구, 즉 비효율적일 수도 있고, 혁신적일 수도 있음
- 중요한 건 언제, 어디서, 어떻게 쓸지 판단하는 기술자의 판단력이며, 그것이 LLM 시대의 진짜 역량임
Hacker News 의견
-
경험 많은 프로그래머들이 LLMs와 작업할 때의 혼란스러운 점에 대한 의견이 있음
- pandas는 Python에서 표 형식 데이터를 조작하는 표준 라이브러리로 2008년부터 사용되어 왔음
- 최근에는 새로운 polars 라이브러리를 사용하고 있으며, LLMs가 polars 함수를 pandas 함수로 착각하는 경우가 많아 문서 확인이 필요해짐
- 코딩 에이전트를 사용하지 않는 이유는 "산만하다"는 것인데, 이는 자동 완성을 싫어하는 사람으로서 공감할 수 있는 입장임
- "순수한" LLMs는 코딩 작업에서 코드 오류를 발생시키지만, 에이전트 LLM 구성은 LLM 상호작용을 구조화하는 코드도 포함함
- LLM이 함수 오류를 발생시키면 프로그램이 컴파일되지 않고, 에이전트가 이를 감지하여 LLM이 반복적으로 수정함
-
UI나 웹사이트를 모의로 제작할 때 vibe coding을 사용함
- 프론트엔드 경험이 없지만, 80% 완성된 라이브 데모를 만들어 다른 사람에게 보여주는 것이 가치가 있음
- 실제 제품에는 아직 준비가 되지 않았지만, 내부 논의를 위한 모의 제작에는 유용함
-
LLMs에서 최상의 결과를 얻기 위한 다양한 방법을 사용해왔음
- LLMs를 "속이는" 시나리오를 생각해내는 것은 비효율적이며, 모델 버전에 따라 효과가 크게 달라질 수 있음
-
덜 인기 있는 라이브러리에 대한 복잡한 코드 질문에서는 LLM의 출력에 더 신중함
- 최근 몇 달 동안 ChatGPT 인터페이스를 사용하여 최신 라이브러리에 대한 코드 질문을 해결하는 데 효과적임
- 새로운 JavaScript 라이브러리로 코드를 업그레이드하는 작업이 성공적으로 이루어짐
-
새로운 라이브러리의 문서나 전체 코드베이스를 긴 컨텍스트 모델에 직접 붙여넣는 방법을 사용함
- 50,000 토큰 이하의 라이브러리에는 효과적이며, Gemini 2.5 Pro는 수십만 토큰도 잘 처리함
-
저자가 채팅 로그를 포함한 점이 좋음
- 많은 사람들이 정보를 노출할 수 없어서 공유하지 못하는 경우가 많지만, LLM의 성과를 주장할 때 이를 뒷받침하는 것이 중요함
-
ChatGPT.com이나 일반 사용자 인터페이스를 사용하지 않음
- 각 LLM 서비스의 백엔드 UI를 사용하여 더 나은 결과를 얻음
- OpenAI는 ChatGPT UI에서 모델을 제한하는 경향이 있음
-
시스템 프롬프트를 명시적으로 설정할 수 없는 현대 LLM 인터페이스는 자체 시스템 프롬프트를 사용함
- ChatGPT는 시스템 프롬프트를 가지고 있지만 Claude는 그렇지 않음
- 새로운 모델에서는 시스템 프롬프트의 유용성이 감소하고 있음
-
생성된 텍스트에 대한 특정 제약을 설정하는 것이 사용자 프롬프트보다 시스템 프롬프트에서 더 효과적임
- LLMs는 30단어의 개념을 이해하지만, 이러한 작업에서 항상 잘 수행하지는 않음
-
각 LLM 서비스의 백엔드 UI를 사용함
- API와 인터페이스하기 위한 맞춤형 래퍼를 사용하는지, 아니면 이미 확립된 클라이언트를 사용하는지 궁금함
-
JSON 응답이 항상 예상대로 작동하지 않음
- 일관된 JSON을 반환하려면 JSON 스키마를 정의하여 항상 동일한 구조를 반환하도록 함
-
LLM을 사용하여 새로운 것을 배우거나 짧은 스크립트를 작성하는 데 사용함
- 블로그 게시물의 텍스트를 LLM에 입력하고, LLM이 냉소적인 Hacker News 댓글러인 척하며 다섯 가지 댓글을 작성하도록 요청하는 기법이 흥미로움