▲

내가 LLM 사용을 줄이기로 한 이유

 (zed.dev)
13P by GN⁺ 15시간전 | ★ favorite | 댓글 2개
  • 15년 경력 소프트웨어 엔지니어 Alberto Fortin은 LLM(대규모 언어 모델) 도입에 큰 기대를 가졌지만, 실제 프로덕션 환경에서는 여러 한계를 경험함
  • Go와 ClickHouse 기반 인프라 재구축 과정에서 AI의 허와 실을 체감하고, 모델 개선에도 핵심 문제 해결이 부족함을 느꼈음
  • 생산성 향상에 대한 환상이 존재하며, 실제로는 버그와 예상치 못한 문제가 더 늘어남을 지적
  • LLM을 보조자(assistant) 로 인식하고, 핵심 설계·결정은 개발자 스스로 해야 한다는 교훈을 강조함
  • "AI는 혁신적이지만 아직 완전하지 않으니, 균형 잡힌 활용과 냉정한 현실 인식이 필요함"

Alberto Fortin의 LLM 경험과 회고

  • 15년 경력의 소프트웨어 엔지니어 Alberto Fortin은 LLM을 적극적으로 개발 작업에 도입하며 큰 기대감을 가졌음
  • Go와 ClickHouse를 활용하여 인프라를 재구축하는 과정에서 여러 도전과 한계에 부딪히면서, AI와 실제 개발 간의 격차에 대한 블로그 글을 작성하였음
  • 이후 최근 추가 분석을 통해 Claude Opus 4 등 최신 모델이 이러한 문제를 해결했는지 검증하는 작업을 진행
  • Alberto의 경험은, 실무 환경에서 LLM 도입을 고민하는 엔지니어에게 실질적인 교훈과, 어떤 부분에서 도구가 가치를 제공하는지, 또 어디까지가 한계인지에 대한 현실적인 시각을 제시함

LLM 경험에 대한 Alberto의 주요 인용문

"오동작이나 기능 미작동만의 문제가 아니었음에 정말 놀랐음. 향후 몇 년간 이 코드를 유지보수하려는 개발자로서, 코드는 충분히 깔끔해야 함."

"문제가 곧 해결될 것 같지만, 결국 다음에 또 새로운 에러가 발생하고, 그걸 해결하는 데 다시 2주 정도가 더 걸리는 경험이 반복되었음."

"오류 출력을 LLM에 전달하면 새로운 답안을 주긴 하지만, 또 뭔가를 복잡하게 꼬아놓거나 다른 부분을 망가뜨리는 문제가 자주 발생함."

LLM에 대한 과한 기대에 대한 인식

"초기 오토컴플리트 등 작은 기능을 처음 쓸 때, 개발자 모두 놀라움을 느낌. 마치 내 생각을 읽는 것 같아, 기대치가 부풀게 되는 현상이 있음."

"개발 생산성이 10배쯤 오를 수 있을 것 같아지는데, 실제로는 그만큼의 기대를 너무 빨리 가지는 경향이 있음."

역할과 기대의 재정립

"가장 큰 차이는 역할 인식의 변화임. 나는 아키텍트이자 시니어 개발자이고, LLM은 내 조수에 불과함. 내가 계획을 세우고, LLM은 보조 역할을 맡음."

"신뢰를 잃게 된 후에는 더 이상 중요한 기능을 맡기지 않음. 리팩토링 등 작은 단위에서만 활용함."

"버그를 직접 수정하기 시작했음. 코드베이스를 완전히 이해하고 있으면 문제를 직접 해결하는 것이 훨씬 빠르고 효율적임."

LLM을 바라보는 시각의 변화와 조언

"시니어 개발자로서 LLM 도입이 잘 맞지 않는 것이 내 역량 부족이 아님을 스스로 인정함. 기존 작업 방식을 지키면서, AI는 보조적으로 활용하는 것이 핵심임."

"기술 발전을 통해 한 단계 발전한 것은 사실이지만, 아직 다음 단계에는 도달하지 못했음. 의사결정과 아키텍처는 여전히 사람이 맡아야 함."

"AI 혁명이 놀랍긴 하지만, 지금은 균형 잡힌, 현실적인 기대치가 필요함."

▲
GN⁺ 15시간전  [-]
Hacker News 의견

  • HN에 너무 많은 시간을 쓰고 있다는 생각이 드는 이유가, 거의 모든 글과 댓글에서 같은 이야기를 반복해서 보기 때문임. LLM이 흥미롭긴 하지만 생성된 코드는 복잡하고 소유감이 없으며, 직접 작성한 코드처럼 머릿속에 전체 구조가 들어오지 않기 때문에 관리가 어렵다는 이야기. 유지할 생각 없는 짧은 스크립트에는 쓸 만하지만, 대규모 프로젝트에서는 문제가 됨. 또 다른 한편에는 여러 LLM 에이전트를 동원해 다양한 작업을 분산처리하고 병합하는 워크플로우가 멋지다고 말하는 사람들이 있는데, 실제 코드를 보여주진 않고 그냥 자랑만 한다는 느낌을 받음

    • 이 내용 요약이 진짜 핵심을 잘 잡았다고 생각함. LLM이 개발 속도를 엄청나게 올리지만, 내가 전체 코드를 이해하고 있지 않다 보니, 언제 어떤 부분에 문제가 생겼는지 파악하기가 어려움. 결국 새로 들어온 개발자가 자기 프로젝트에 적응하는 느낌임. 그래서 코드를 자주 커밋하고, 주기적으로 LLM에게 코드 설명을 다시 요청함. 이 과정에서 LLM이 직접 자기 버그를 찾아내는 경우도 많음. 주로 데이터 분석처럼 범위가 좁은 작업에는 충분히 관리하면서 빠르게 진행할 수 있음. 반대로 규모가 큰 코드베이스에서 LLM을 제대로 활용할 역량과 습관이 없다면 엉망이 되기 쉬움. 프롬프트 작성, 컨텍스트 관리, 속도 조절, 작업 조직화, LLM 결과물을 정확히 리뷰하는 등은 반드시 익혀야 할 LLM 활용 역량임. 아직 아무도 이걸 정식으로 가르쳐주진 않기 때문에 다들 시행착오로 익히는 중임. 그래도 한번 맛을 보고 나니 다시 예전으로 돌아가기 힘듦. 귀찮거나 반복적인 일은 LLM에게 맡길 수 있기 때문. 20년 넘게 개발하며 예전만큼 참을성도 없기도 하고, 구현 방법을 잘 모르는 아이디어도 LLM에게 맡기면 훨씬 효율 높게 작업 가능

    • 프로그래밍을 '이론 구축' 과정으로 생각하는 방식이 마음에 듦. Programming as Theory Building 참고. AI 활용 자체엔 반감 없음. 다만, 생성된 코드의 결과물에 대한 책임을 방기하는 태도는 찬성하지 않음. grep 등 도구를 쓸 때처럼, 도구로 사용한 결과 역시 책임지고 다뤄야 의미가 있음. 생성된 코드는 더욱 그렇고, 디스클레이머만으로 끝낼 문제가 아님

    • AI 관련 글에 피로감을 느끼는 거 공감함. 의견이 갈리는 건 사실임. 그래도 실제로 자신들의 코드를 공개하는 예시도 있음. Flask/Jinja2/Sentry를 만든 Armin Ronacher가 유튜브에 워크플로우 영상과 직접 만든 AI 라이브러리 소개를 올렸고, 나도 오픈소스 프로젝트의 절반~80% 정도를 AI로 만들고 있음. cijene-api 참고

    • 사용자 집단이 종 모양 곡선처럼 나뉜다는 느낌임. 한 쪽엔, LLM이 너무 많은 코드를 자기 스타일로 내놓으니 사용자 머릿속에 맥락이 안 들어오고 압도당하는 쪽이 있음. 반면, 원래 혼자선 구현이 불가능하던 사용자에겐 LLM 덕에 무엇이든 만들어보는 길이 열림. 또 한 쪽엔, 직접 천천히 구현이 가능하지만 LLM을 주니어 개발자 군단처럼 활용해서 전체 알고리즘 수준만 기억하는 데 집중하고, 훨씬 더 큰 프로젝트를 빠르게 구성하는 사용자도 있음

    • 25명 넘는 개발자가 동시에 참여하는 대규모 코드베이스에서 일하는 거와 그리 다르지 않다는 생각임. 내 조직은 160명의 엔지니어가 프론트엔드와 미들티어를 담당하는데, 항상 소유감 없는 코드를 뒤져야 하고 git blame에 3년 전 외주 개발자 이름이 뜨기 일쑤임. LLM은 작은 규모엔 괜찮고, 중간 규모에선 안 맞고, 큰 프로젝트에서 작은 모듈로 쓸 때 다시 괜찮은 듯함

  • LLM이 내 목표 달성엔 크게 도움을 주지만, 직접 프로그래밍하는 역량 자체는 떨어지게 만드는 느낌임. 마치 스테로이드처럼 근육은 빨리 커지지만 부작용이 많고, 끊는 순간 한순간에 무너져내리는 상황임. 회사는 건강 대신 빠른 성과에만 관심이 있으니 이런 현상이 더 심함. 적정선을 지키면서 조절해서 쓰기 시작함

    • 스테로이드와 비교하는 게 인상적임. Cal Newport 블로그에서 AI가 우리를 게으르게 만든다는 최근 글이 생각남. 연구자들은 AI 도움 없이 일하는 사람들이 뇌 활동이 더 활발하다는 EEG 데이터도 제시함. 그래도 AI가 모든 영역에서 금지되어야 한다는 건 아님. 이메일 등 비핵심 작업엔 써도 되지만, 진짜 코어 업무에는 삼가는 게 좋다는 주장임. 블로그 참고

  • LLM 덕분에 많은 개발자들이 "Simple Made Easy"에서 강조된 교훈을 잊어버린 것 같음. LLM이 만드는 코드는 'Ball of Mud'(복잡하고 리팩토링이나 관리가 안 되는 엉망진창 코드) 생산에 탁월함. 복잡한 문제를 잘게 쪼개서, 각각의 작은 컴포넌트가 단순하게 동작하고, 이들이 상호작용해 복잡성을 구현하는 게 진짜 힘임. 각 컴포넌트가 단순하면 이해와 디버깅, 성능 예측이 쉬워짐. LLM이 이 원리를 진짜로 잘 따르게 된다면 그때 진정으로 개발자가 필요 없을 수도 있겠음

    • 사실 LLM에게 원하는 방향을 직접 알려줄 수도 있음. LLM이 쓸모있다고 느끼는 사람과 아닌 사람의 차이는, LLM이 무엇에 강점과 약점이 있는지 파악하고, 입력(프롬프트)에 따라 결과의 퀄리티가 달라질 것을 예측할 줄 아느냐에 달림. 예를 들어, 복잡한 문제 쪼개기 방법을 LLM에게 물어서 내가 놓친 부분이 있는지 확인하고, 그 후에 구체적인 구현을 맡기는 방식을 선호함. 아무런 지시 없이 대형 프로젝트 전체를 생성하라고 하진 않음

    • 'Ball of Mud' 문제는 코드에서만 일어나는 게 아님. 내 직장에서도 "AI를 적극적으로 수용하자"고 주장하는 리더들이 있는데, 배포 시스템과 복잡한 운영까지 AI로 돌리자는 발상을 봤음. 결국 복잡한 시스템 위에 또 복잡한 블랙박스를 올려 "블랙박스를 이해하려면 새로운 블랙박스가 필요"하다는 논리인데, 나에겐 말이 안 되는 상황임. 조직 내 강압적인 분위기 때문에 내가 이상한 생각을 하는 듯 느끼게 만들기도 함

    • LLM이 진짜 완벽해진다면 정말 개발자가 필요 없어질까 생각해봄. LLM이 24/7 소프트웨어를 계속 "생산해내는 기계"처럼 돌아가는 걸 원하는 사람은 아무도 없을 것 같음. 결국은 여전히 문제를 쪼개고, 실제로 필요한 소프트웨어를 찾아서 만드는 사람이 필요할 것임. 오늘날 우리가 그들을 소프트웨어 개발자라고 부르듯이

  • 결국 나도 비슷한 결론에 도달함. LLM은 코드베이스 전체를 오토컴플릿 형태로 채울 때엔 별로임. 무엇이 어디서 뭘 하는지 머릿속에 모델이 사라지는 문제임. 개인화된 StackOverflow처럼 LLM을 키워드 설명, 잘 모르는 개념 요약, 방향 제시 등에만 사용하고, 실제 구현과 의사결정은 스스로 맡는 게 훨씬 효율적이었음

    • 나도 같은 방식으로 쓰지만 cursor는 계속 코드 수정을 집요하게 제안함. 코드베이스의 내용을 건드리지 않으면서 introspect만 하게 하는 비법이 궁금함

    • 내 경우엔 다름. LLM이 제시한 코드를 늘 꼼꼼히 리뷰하면, 무엇이 어디에 있고 어떻게 상호작용하는지 꽤 명확하게 알 수 있음

  • 나도 사용 빈도를 많이 줄이는 중임. LLM 답변이 틀린 경우가 꽤 많았음. 그래서 요즘은 '어떤 매뉴얼 혹은 문서'에서 찾으면 될지 위치만 묻고, 실제 내용은 내가 직접 챙겨봄. 이 방법이 정보의 위치 파악 능력을 기르는데 도움이 되고, 검색엔진과 LLM 의존도를 줄이게 됨. LLM은 도구일 뿐이고, 정확성도 떨어지는 편임

  • 어디에서도 언급되지 않았던 점이 하나 있는데, LLM이 때때로 생산성 저하시킬 수 있다는 부분임. 그럴듯한 답변으로 엉뚱한 길로 끌고 가면 오히려 시간 낭비가 심각함. 전체적으로 보면 도움 되는 경우가 많지만, '근거 확인'이 중요하고, 실제로 종종 직접 구현이 더 빠르기도 함

  • LLM의 한계가 확실함. 매우 강력하지만, 인간만큼 창의적 점프는 힘듦. 예를 들어, "Android에서 1000번 미만 포트 바인딩이 안 되는데, 웹서버 실행하려면?" 이라는 질문에 Claude와 Gemini 둘 다 아래 세 가지 상식적인 해법만 내놨음: 1) 리버스 프록시 2) 루팅 3) 포트 번호 올리기. 내가 원했던 진짜 해법은 HTTPS RR 레코드였음(관련 참고). 둘 다 이 스펙 자체는 알지만, 상황에 대입하진 못함. 내가 직접 맥락을 추가해야만 답을 찾음

    • 사실 LLM이 추천하지 못한 것이 이상하진 않다고 봄. Chrome에서도 정식 지원하지 않는 최신 스펙을 추천해주길 기대하기 어렵기도 하고, 나도 그만큼 생각하지 못했을 것임

    • 이 정보는 나도 메모해둠. 최근 LLM과 실제로 대화해보면서, 사람 대하듯 약간은 관용을 베풀면 스트레스가 줄어듦. 예를 들어, cursor로 코드 짤 때 "여기 누락됐다"라고 지적하면, 나도 같은 실수를 했을 수 있다는 생각이 들기도 함. '북클럽', '영화클럽' 파트너로 LLM을 활용해 영화 두 편을 토론하게 했더니, 캐릭터의 상황을 잘못 말하는 에러도 있었지만, 100% 정확할 필요 없이, 사람과도 똑같이 관용을 베풀면 대화가 훨씬 유연해짐. AI와 대화할 때도 긍정적으로 대하면 좋음

    • SRV 레코드는 들어봤지만 거의 안 쓰이는 것 같았는데, HTTPS RR은 처음 알았음. 실제 지원 상황도 SRV보다 나은 것 같음

    • '정답을 직접 언급해주면 그때서야 솔루션 목록에 추가하는' LLM의 클래식한 문제임

    • 목표와 제약 조건을 충분히 명확히 지정하면 ChatGPT o3가 이 솔루션을 제시해줌. 다만 최신 브라우저에서만 동작한다는 점은 정확히 안내해줌. 참고 예시

  • ChatGPT 엔터프라이즈 버전을 자주 쓰면서, 시간이 지남에 따라 몇 가지를 배움. 대량의 코드를 집어넣지 말고, 아주 독립적인 함수나 작은 클래스 단위로 다뤄야 효과가 좋음. 코드 생성이나 완성 요청의 경우, 10% 정도는 추가 지시로 해결 가능하지만 품질이 떨어지고, 25% 정도는 아무리 설명해도 품질이 안 올라감. 이럴 땐 과감히 무시하고 직접 해결함. 반대로 새로 쓴 코드 리뷰에는 꽤 쓸 만함. 코멘트 중 절반은 쓸모없고, 일부는 애매하지만, 가끔 진짜 중요한 버그나 이슈를 집어준 적도 있음. 여러 페이지를 한 번에 넣지 말고, 쪼개서 넣으며 쓰는 게 좋음. HLSL shader나 SIMD 같이 니치한 영역은 학습 데이터 부족 탓에 답을 거의 못 줌. 전체적으로 코드 품질 개선에 도움 됨. 코드 단위로 잘게 나눠 검증하다 보니, 함수/클래스/모듈 등으로 아키텍처 구조가 분할되어 전체 품질이 좋아짐

    • 코드 리뷰 용도로 AI를 쓰기 시작했는데 정말 편리함. 함수처럼 범위가 작은 부분에서 큰 도움을 주고, 특히 귀찮은 단위 테스트 작성에 쓸 만함. AI 코딩 보조 퀄리티가 최근 1년 사이에 정말 많이 올라가서, 옛날에 써보고 실망한 사람이라면 다시 시도해볼 만하다고 생각함

  • 장기적인 소프트웨어 개발에서 LLM을 '고급 보일러플레이트 생성기'로 쓰는 게 제일 매력적임. 유지 관리를 신경 쓸 필요 없는 1회성 작업엔 이미 좋지만, 장기 개발에서도 추상화하기 모호한 반복적 코드(예: 테스트 코드)에 정말 유용함. 처음엔 반감이 들었지만 지금은 너무 만족함. 지루하고 반복적인 부분이 '프롬프트 최적화'라는 재미있는 새로운 게임으로 바뀌었고, 프로덕티브도 크게 향상됨. 프롬프트 작성과 코드 리뷰가 단순작업보다 훨씬 빠르게 끝남. 덕분에 머리 써야 할 흥미로운 부분만 남음

  • LLM은 결국 코딩뿐 아니라 여러 작업에서 '유행하는 다이어트'와 비슷한 현상임을 깨달음. 모두가 빠르고 쉬운 해결책을 바라는 마음은 같지만, 결국 왕도는 없음. 편의는 결국 트레이드오프고, 언젠간 모두 그 현실을 받아들이게 됨

답변달기