LLM 코드 생성이 신뢰 약화로 이어질 수 있음

• 최근 LLM 기반 코드 생성이 개발자 사이에서 점점 더 사용되는 현상임
• 자동 생성된 코드로 인해 코드 품질 및 신뢰성에 대한 우려 증대 현상임
• 개발자들은 코드 이해 부족 및 검증 미흡으로 인해 프로젝트 유지보수 난이도 상승을 경험함
• 신뢰할 수 없는 코드의 사용 확산이 전체 소프트웨어 생태계에 영향 미침
• 기술 발전과 함께 신뢰성 확보 방안 마련 필요성 강조됨

---

개요

Jay는 자신의 블로그에서 최근 등장한 LLM(대형 언어 모델) 기반 코드 생성 기술이 소프트웨어 개발 현장에 미치는 영향을 다룸. 이러한 도구의 발전으로 개발 효율성이 향상되고 있지만 동시에 코드의 신뢰성과 품질 문제가 대두됨.

LLM 코드 생성 기술의 부상

• 개발 현장에서 LLM을 활용한 코드 자동 생성 도구가 빠르게 확산 중임
• 복잡한 기능 구현이나 반복적 코딩 작업에서 높은 생산성 제공 현상임
• 신속한 프로토타입 제작 및 신규 언어 학습 부담 완화 장점 보유함

신뢰성 문제

• LLM이 생성한 코드가 의도한 대로 항상 동작하지 않음 현상 발생함
• 코드 내부의 의도, 설계 논리가 불분명해 이해와 검증 과정이 어려워짐
• 리뷰 및 테스트 과정이 부족할 경우 예기치 못한 버그나 취약점 발생 가능성 존재함

프로젝트 유지보수 및 생태계 영향

• 자동 생성 코드에 대한 문서화 부족과 설명 미흡 문제가 발생함
• 개발자가 코드의 동작 원리 파악에 어려움을 겪어 유지보수 복잡성이 증가함
• 신뢰성 있는 소프트웨어 개발 문화가 훼손될 위험이 있음

결론 및 제언

• LLM 기반 코드 생성 기술은 혁신적이지만, 신뢰성 확보가 필수 과제임
• 자동 생성 코드 도입 시 검증 강화와 체계적 코드 리뷰 필요성 강조됨
• 장기적으로 컴퓨팅 생태계의 신뢰 보호를 위한 기준 마련이 중요함

[GN⁺]

Hacker News 의견들

• https://archive.is/5I9sB
  구형 브라우저에서도 동작하고, CloudSnare를 지나갈 때 말고는 JavaScript가 필요 없음

• 친구가 늘 “혁신은 신뢰의 속도로 일어난다”고 말하는데, GPT-3 이후로 이 문장이 계속 떠오름
  검증에는 비용이 많이 들고, 그 비용을 낮추는 핵심 수단이 신뢰임. LLM을 어떻게 신뢰하게 만들 수 있을지 모르겠음. 코드와 자연어 모두에서 매우 유창하지만, 동시에 프랙털처럼 끝없이 파고드는 토끼굴로 기꺼이 들어가고, 사람이라면 악의적이라고 볼 행동도 보임

  • 작성자로서, 그 문장이 마음에 듦. 내가 몇 단락에 걸쳐 말한 내용을 아주 간결하게 표현함
    모든 것을 항상 검증해야 하는 이 새 세상은 꽤 지치고, 솔직히 매우 느림
  • LLM 출력물을 완전히 신뢰할 수는 없지만, 정화하고 파괴 범위를 제한할 수는 있음. 사용자 입력을 정화하고, 침투 테스트로 방어하고, 비밀값을 dotfile에 숨기는 것처럼 결국 “모범 사례”와 일종의 “SOC-AI 준수” 표준으로 수렴할 것임
    너무 유용해서 무시할 수 없고, 신뢰는 늘 벽돌을 하나씩 쌓듯 만들어짐. 인간도 애초에 그다지 신뢰할 만하지 않다는 점을 잊으면 안 됨. 자동차 운전처럼, 사전에 정의된 도로 위에서 버그가 적은 코드를 만들어내는 능력은 곧 인간을 앞지를 것 같고, 그다음은 복잡도를 개선하기 위한 기본기 싸움일 뿐임
  • “혁신은 신뢰의 속도로 일어난다”는 말은 더 설명이 필요함. 전기, 비행, 방사능을 발견했을 때 거기에 얼마나 신뢰가 있었나?
    과학에서는 진행하면서 신뢰를 쌓아감

• 직장에서 예상과는 다른 방식으로 이런 일을 겪었음. 동료와 나는 진행 상황을 보여줘야 한다는 압박을 받았고, 내가 작업하던 꽤 큰 리팩터링을 서둘러 병합하기로 했음. 초안 PR이었지만 추진력을 위해 병합했고, 다음 주에 테스트되지 않은 코드 영역에서 버그가 몇 개 나왔음
  디버깅 중 동료가 내가 AI로 작성했을 거라고 가정했다는 걸 드러냈고, 사후에 AI 생성물을 이해하려 하니 답답하다고 했음. 하지만 이 코드는 AI를 쓰지 않았음. 물론 코드 작성에 AI를 쓰긴 하지만, 이 코드는 전체 설계를 신중히 생각하며 손으로 작성한 것이었음. 버그는 리팩터링의 근본 결함이 아니라, 변경된 API에 맞춰 기존 코드를 조정하다 생긴 작은 누락들이었음
  결과적으로는 동료와 긴장을 명시적으로 이야기할 수 있어서 신뢰를 쌓는 경험이 되었음. 지금 벌어지는 일의 힘을 꽤 부드럽게 마주한 셈임. 돌아보면 이렇게 풀려서 다행이고, 다른 업무 환경이었다면 훨씬 더 지저분해질 수도 있었겠다고 상상됨. 조심해야 함

  • 꽤 심각하고 모욕적인 비난이 될 수 있음. 게임 개발자가 자기 캐릭터 목소리를 직접 녹음했는데 무표정하거나 어색한 말투라면 누군가는 AI라고 부르기 마련임. 이해하거나 좋아하지 못하는 예술? 아마 AI일 거라고 함. Eurovision 출품작이 별로라고 느껴지면 AI라고 부름. 어떤 사람들은 이 말을 가볍게 던지지만, 나는 그러지 않을 것임
    약 4년 전 스스로 크게 바보짓을 한 적이 있음. 지역 신문이 어떤 인물에 대해 사진을 주된 증거로 삼아 터무니없는 주장을 담은 기사를 냈고, 나는 편집자에게 직접 이메일을 보내 이미지가 조작됐다고 확신하는 이유를 설명했음. 내 논리는 내 오해에 기대고 있었고, 문제의 인물이 meet-and-greet에서 여러 사람과 포즈를 취하면서 위치와 자세가 거의 변하지 않았다는 점을 잘못 해석한 것이었음. 편집자는 기분이 상해 나를 놀리듯 답했고, 내가 물러서지 않자 선동가가 아니라 그냥 멍청이라는 걸 깨닫고 사진이 나온 미공개 전체 영상을 공유해 줬음. 그때 깊이 사과하고 기부도 했고, 그 뒤 1년 동안 내 자존심은 적절히 작아져 있었음
    이메일을 보내기 전에도 거짓 비난을 하고 싶지 않아서 침착한 친구들에게 사진을 공유하고 의견을 물었는데, 그들도 이미지가 조작됐을 가능성이 크다는 결론을 냈기 때문에 상당히 자신만만했음. 지금은 그 신문과 관계자들을 암묵적으로 신뢰하지만, 단 한 사람을 납득시키는 데도 일이 정말 많았음

• 전제를 이해하기 어려움. 누군가가 좋은 코드를 쓴다고 신뢰한다면, 그 신뢰는 그 사람의 코드가 잘 동작했기 때문에 배운 것이지, 그 사람의 마음속에 “좋은 코드를 생산하는” 어떤 선험적 정신 모델이 있어서가 아님
  누군가 LLM을 써서 버그 없는 코드를 만들면 신뢰할 것임. 누군가 LLM을 써서 버그 많은 코드를 만들면 신뢰하지 않을 것임. 그 사람이 오직 자기 머리만 써서 코드를 만들던 때와 무엇이 다른가?

  • 작성자로서, 핵심 전제는 매우 큰 팀 같은 중간 신뢰 환경이나 오픈소스 프로젝트 같은 낮은 신뢰 환경에 있음
    LLM 때문에 제출된 코드만 보고 패치를 낸 개발자의 품질을 즉각적으로 판단하기가 매우 어려워짐. 상대가 어떤 유형의 사람인지 가늠할 수 없으면 “무신뢰”로 돌아가 모든 것을 아주 촘촘히 검토해야 함. 즉 더 이상 안전한 “리뷰 지름길”이 없고, 그런 신호에 의존해 일을 굴리던 곳에서는 고통스러울 수 있음. 이미 역량 있고 신뢰 높은 팀이라면 이 문제는 적용되지 않고, 개념 자체가 낯설게 느껴질 가능성이 큼
  • “코드가 잘 동작하기 때문에 신뢰를 배웠다”고 했지만, 잘 동작함보다 훨씬 많은 것이 있음. 코드에 가깝지만 코드 자체는 아닌 단서들이 많음
    기여자가 변경 내용을 잘 설명하면 더 신뢰함. 과거에 훌륭한 일을 했으면 더 신뢰함. 합리적인 커밋처럼 변경 단위를 잘 관리하면 더 신뢰함. 새 기능을 추가하기 전에 버그를 고치는 식으로 올바른 문제를 고르면 더 신뢰함. 기존 코드를 유지보수할 수 있음을 보이면, 단순히 위에 덧붙이는 것보다 더 신뢰함. 정기적으로 기여하면 더 신뢰함
  • LLM 코드가 몇 번 연속으로 잘 동작하면 과신해서 충분히 테스트하지 않기 쉽고, 그러다 무언가를 놓침
    문제는 흔히 의사소통 오류임. 작업자에게는 과제가 명확할 수 있지만, 잦은 문맥 초기화 때문에 LLM도 전체 그림을 알고 있는지 보장하기 어렵고, 애매함이 있으면 멍청한 가정을 하기 쉬움. 4o의 deep research가 뭔가 하기 전에 추가 정보를 물어보는 방식은 코드 생성에서도 표준이 되어야 한다고 봄. 그러면 산더미 같은 문제를 막을 수 있음
  • “누군가 LLM을 써서 버그 없는 코드를 만들면 신뢰할 것”이라고 했지만, 그 코드가 정말 버그 없다는 걸 안다고 이미 그 사람을 신뢰하기 때문에 가능한 일임
    어떤 경우는 단순함. 이 루틴이 원하는 값을 반환하느냐 아니냐의 문제임. 하지만 다른 상황은 시스템의 다른 부분과 어떻게 상호작용할지, 눈에 잘 띄지 않는 경계 사례가 무엇인지 예상해야 해서 훨씬 복잡함. 그런 상황에서 “버그 없는” 코드를 쓰려면 작성자가 코드의 함의를 이해해야 하고, 개발자가 LLM이 쓴 코드가 정확히 무엇을 하는지 이해하지 못한다면 그 함의도 이해할 수 없음. 그러면 그 부담은 리뷰어에게 넘어가고, 리뷰어의 작업량이 늘어남. 그게 전제였음
  • 사람들이 LLM을 쓸 때는 도구를 사용해 일을 하는 것이 아니라, 도구에게 일을 시키는 것임. LLM은 계산기도 아니고 인터넷도 아님
    좋은 경험칙은 LLM이 관여한 작업은 그냥 거절하고, LLM이 쓴 커뮤니케이션도 무시하는 것임. 영어를 외국어로 쓰는 사람이라도 ChatGPT가 대신 말해주는 것보다 그 사람의 “서툰” 영어가 훨씬 낫다고 봄. LLM의 심각한 문제들이 더 명확해질수록 이런 정책이 전반적인 표준이 될 것 같고, 그렇게 되길 바람

• LLM은 어떤 종류의 나쁜 작업이든 그럴듯하게 좋은 작업처럼 보이게 만듦. 그래서 AI를 사용한 사람의 산출물을 자동으로 할인해서 보는 것은 합리적임
  예전에 친척 중 한 명이 사기꾼으로 드러난 적이 있음. 들킨 뒤 나는 연락을 끊으며 그 사람을 모른다고 했고, 그는 “나는 네가 10년간 알아온 바로 그 사람”이라고 말했음. 나는 “그럴지도 모른다. 그런데 이제야 내가 그 사람이 누구인지 전혀 몰랐고, 앞으로도 알 수 없다는 걸 깨달았다”고 답했음
  우리 모두는 삶 속의 사람들이 적극적으로 우리를 해치려 하지 않는다고 가정함. 그 신뢰가 깨지면 아주 세게 깨짐. AI를 쓰는 사람은 누구도 “이건 내 작업”이라고 주장할 수 없음. 그게 당신의 작업인지 알 수 없기 때문임. AI를 쓴 사람은 그것을 철저히 이해하지 않는 한 좋은 작업이라고 주장할 수도 없고, 아마 철저히 이해하지 못할 것임. 내 학생들 상당수가 내가 쓴 글을 읽고 이해했다고 주장했지만, 실제로는 그렇지 않다는 걸 발견했음. 내가 AI이고, 그들이 내 작업을 받아 자기 이름을 저자로 올렸다면 어떨까? 그들은 아무것도 설명하거나 방어하거나 후속 작업을 할 수 없을 것임. 이런 문제는 AI 이전에도 있었지만, 이제 열 배는 더 나빠졌음

  • 그 관점이 어디서 오는지 이해하고 존중함. 이 기술이 만들어내는 비진정성에 대한 두려움에는 “사기꾼” 비유가 그럴듯함. 다만 풀스택 소프트웨어 개발의 깊은 참호 속에 있던 사람으로서 다른 관점을 제시하고 싶음
    유용한 LLM이 나오기 전에 복잡한 애플리케이션 프로그래밍에 “1만 시간 이상”을 쏟은 사람임. 수년 동안 매일 밤 문서와 다른 사람의 소스 코드를 파고들며 풀스택 숙련에 완전히 몰두했음. 결국 그 몰입은 심각한 번아웃으로 이어졌고, 건강도 나빠지고 결혼생활도 흔들렸음. 애플리케이션을 출시한 직후 회복을 위해 3년 동안 완전히 손을 놓아야 했고, 다시는 집어 들지 못할 거라고 확신했음
    LLM이 코드에 꽤 좋아졌다는 많은 이야기를 듣고 조심스럽게 컴퓨터 앞으로 돌아왔고, 그 지점에서 내 경험은 우려와 크게 갈라짐. “AI를 쓰는 사람은 ‘이건 내 작업’이라고 주장할 수 없다”는 말에는 동의할 수 없음. 내가 LLM을 사용할 때 나는 설계자이자 최종 검수자임. 비전을 지시하고, 시스템을 설계하며, diff 도구로 LLM이 생성한 모든 줄을 검토함. 최근에는 사업의 견적 엔진을 위한 복잡한 최적화 모델을 LLM과 함께 만들었음. 진짜 최적화 모델을 쓰는 것이 늘 “올바른” 방법이었지만, 예전이라면 라이브러리의 모든 세부를 배우고 다른 사람 코드를 읽느라 몇 달의 고된 작업이 필요했을 것임. 이번에는 일주일에 끝냈음. 이것이 내 작업처럼 느껴지느냐? 전적으로 그렇다. 지치지 않고 뛰어나지만 때때로 결함이 있는 조수가 있었을 뿐임
    사용자가 “철저히 이해하지 못할 것”이라는 말도 내 경험은 반대임. 사소하지 않은 일에 LLM을 효과적으로 쓰려면, LLM을 이끌고 자주 발생하는 미묘한 실수를 잡아내기 위해 기본에 대한 더 깊은 이해가 필요함. 내 수년의 경험이 없었다면 복잡한 다중 모듈 개발을 이끌거나, 출력물을 디버그하거나, 그럴듯하게 좋아 보이는 작업이 실제로는 N+1 문제 같은 방식으로 틀렸다는 걸 알 수 없었을 것임
    교사로서의 경험에는 공감함. 학생들이 이런 도구로 이해한 척하는 문제는 실제이고 어렵다. 학계에서는 학습 과정, 즉 1만 시간의 어떤 실질적 부분을 얻는 것이 목표임. 하지만 전문 세계에서는 결과가 목표이고, 이것은 더 나은 결과를 얻기 위한 새롭고 강력한 도구임. 교사가 이 새 현실에서 학생을 어떻게 가르쳐야 할지는 모르겠지만, LLM 사용을 악마화하는 것은 아마 최선이 아님
    내게 이것은 나쁜 작업을 좋아 보이게 만든 게 아니었음. 훌륭한 작업을 다시 가능하게 해줬고, 동시에 내 삶을 되찾게 해줬음. 나와 가족을 망가뜨리지 않고도 소프트웨어 개발이라는 craft의 즐거움을 되돌려줬고, 지금 삶은 훨씬 균형 잡혀 있어서 감사함

• 나에게는 이미 그런 상태임. “간과해서 죄송합니다, 당신 말이 완전히 맞습니다”를 읽은 횟수가 엄청남. 10번 중 8~9번쯤 됨
  한편으로는 사람들이 유료 LLM 생성 코드를 아무 생각 없이 복사해 놓고, 기대한 대로 동작하지 않으면 격분하는 걸 계속 봄. 참고로 그게 더 나은 선택지임. 겉으로는 동작하는 것처럼 보이는 것보다 명백히 망가진 것이 차라리 낫기 때문임

  • 내 경험상 LLM은 요구사항을 만족하기보다 테스트를 통과하기 위해 코드를 수정하려는 경향이 매우 강함
  • 브라우저 챗봇으로 LLM을 쓰는 건가? 우리가 직접 코드 접근 권한을 주고 쓰는 AI 에이전트들은 그다지 말이 많지 않음. 또한 적어도 이 주변에서는 많은 주니어 프로그래머보다 더 유능하다고도 보임. 짧고 구체적인 작업을 에이전트에 주면, 코드 리뷰 외에는 별다른 것이 필요 없을 정도로 잘 수행하는 지점에 거의 와 있음
    그렇다고 해도 예측 엔진은 아직 진짜 공학을 할 수 없음. Python generator 같은 것을 쓰라고 구체적으로 지시하지 않으면, 엄청난 메모리를 먹는 코드가 나올 가능성이 큼. 안타깝게도 내가 아는 많은 Python 프로그래머와도 크게 다르지 않지만, LLM이 말한 만큼 정확히 나쁘다는 예시이기도 함. 긍정적인 면은 사람들이 “기능 추가” 한 줄보다 더 자세한 명세 작업을 실제로 쓰게 만든다는 점임
    우리에게 AI 에이전트가 가장 유용한 곳은 아무도 우선순위에 두지 않는 레거시 코드임. 이전 천년에 작성된 데이터 추출기가 있는데, 팩스로 들어오는 특정 문서 유형에서 데이터를 추출하기 위해 하드코딩된 좌표 약 200개를 씀. 문서가 30년쯤 바뀌지 않아 잘 동작했지만 최근에 바뀌었고, Copilot은 좌표를 고치는 데 30초 정도 걸렸음. 사람이라면 극도로 지루한 하루 종일 작업이었을 가능성이 큼. 다만 바이브 코딩 시대에 우리 업계가 어떻게 전문가를 길러낼 생각인지는 전혀 모르겠음
  • “10번 중 8~9번”은 아님. 100% 지어낸 통계임

• LLM에 맞서 싸우는 건 바람을 향해 오줌 누는 일임
  현재 방식의 LLM은 개발자를 더 생산적으로 만드는 것으로 보임. 경험이 적은 개발자에게는 숙련 개발자보다 더 큰 이득을 줄 가능성도 있음. 생산성 향상, 어쩌면 매우 큰 배수의 생산성 향상은 어떤 이유로 기술에 반대하는 사람들이 세운 장애물 때문에 포기되지 않을 것임
  새 생산성 도구가 엄청난 피해를 낸 예시, 예컨대 대형 서비스를 상당 시간 중단시키는 버그가 나와도 그 기술이 상당한 생산성을 제공한다면 멈추지 않을 것임. 기술과 함께 일하고 약점을 완화하는 것이 유일하게 합리적인 길임. 그리고 그 완화책은 새 기술의 생산성 이득을 완전히 제거하는 규칙 집합이어서는 안 됨. 완화책은 기술 채택을 늘리는 방향으로 기술과 함께 작동해야 하며, 그렇지 않으면 우회될 것임

  • “현재 방식의 LLM은 개발자를 더 생산적으로 만든다”는 말은 개발자와 그들이 이루려는 것에 따라 크게 달라진다고 봄
    내 경험상 LLM 덕분에 생산성이 10배가 됐다고 강하게 말하는 사람들은 대체로 비교적 주니어인 프런트엔드 개발자이거나, 계속 새 앱을 처음부터 만드는 연쇄 스타트업 개발자들임. 물론 완전히 타당한 사용 사례지만, 그래서 주니어 프런트엔드 개발자와 시니어 임베디드 C 개발자는 AI 생산성 향상을 이야기할 때 서로 엇갈리기 쉬움
    기술과 함께 일하고 약점을 완화하는 것만이 합리적이라는 말 대신, 그냥 더 분별 있게 쓰면 됨. 예를 들어 AI “에이전트”라는 발상 자체가 좋은가? 최근 Copilot 사건[0]은 MS와 AI를 웃음거리처럼 보이게 만들었음. AI가 자율적으로 작업하게 하려는 시도 자체가 별로 현명하지 않을 가능성이 있음
    최근 비유로는 블록체인과 암호화폐가 있음. 좋아하든 싫어하든 Coinbase 등의 성공을 보면 블록체인은 실제지만 좁은 사용 사례를 찾은 게 분명함. 하지만 암호화폐 과열기에는 “커피 원두 공급망을 블록체인으로 추적하겠다” 같은 말을 하는 사람들이 있었음. 2025년에는 Twitter 과장 농담처럼 들리지만, 2020년에는 IBM이 실제로 이런 걸 팔려고 했음[1]. 언젠가 돌아보면 AI 에이전트나 현재의 생성형 AI 응용 중 일부가 이 거품의 커피 블록체인이었다고 보게 될지도 모름
    [0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
    [1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
  • 또 “더 생산적”이라는 말이 나왔음
    하지만 이것은 모델/인간 조합이 사용자의 필요를 더 효과적으로 충족한다는 뜻이 아님. “더 많은 코드”를 생산한다는 뜻임. 코드 2000줄을 삭제하는 변경 묶음을 내보내는 LLM은 없음. 그래서 “엔지니어를 더 생산적으로 만든다”는 말이 생성되는 코드 양에 관한 말이라는 걸 알 수 있음
  • 저자가 실제로 하지 않은 말에 반박하고 있는 것 같음
    마치 LLM을 쓰느냐 마느냐의 이분법으로 주장하는 듯하지만, 저자는 주로 위험 완화를 말하고 있음. 비유하자면, 저자가 자동차 몇 대가 폭발했다고 지적하고 예전의 말은 폭발하지 않았으니 접착제 공장을 가동하기 전에 자동차가 덜 폭발하게 만들어야 한다고 말했을 뿐인데, 당신은 저자가 자동차 개발 자체에 근본적으로 반대한다고 보는 것 같음
  • 글은 바람에 오줌 누는 것이라기보다, 특히 팀에서 LLM으로 코딩할 때의 여러 주의점과 이를 완화할 아이디어를 짚은 것으로 보였음
  • 웃긴 일이지만, React가 새로 나왔을 때 배우기를 거부했던 기억이 있음. 더 일찍 배웠다면 아마 시장에 몇 년은 더 빨리 들어갔을 것임
    지금도 GPT를 쓰기 싫어하는 마음이 있는데, 최근 동료들은 “ChatGPT가 말하길”이라거나 “이 코드는 ChatGPT가 만들었다”고 말함. 나는 직접 코드를 쓰고 GPT를 쓰지 않는 데 자부심을 느끼지만, 동시에 Google과 Stack Overflow는 쓰고 있음. 그것도 더 느린 버전의 GPT라고 말할 수는 있겠음

• 불완전하고 확률적인 행위자도 신뢰할 수 있는 결정적 시스템을 만들 수 있다는 점을 저자가 놓친 것 같음
  가비지 컬렉션 도구를 저자의 신뢰성으로 믿지는 않을 것이고, 광범위한 테스트 뒤 의도한 일을 해낸다는 것이 입증되는지를 보고 믿을 것임. 앞으로 신뢰가 약화되는 모습은 충분히 상상할 수 있고, 그 결과 테스트 주도 개발이 더 탄력을 받을 것 같음. 신뢰하지 말고, 검증해야 함

  • 자동 테스트가 모든 문제를 찾아낼 것이라고 기대하는 건 순진함. 자동으로 찾기 어려운 문제 유형이 여럿 있음. 동시성 문제, 자원 관리 오류, 보안 취약점 등이 그렇다
    더 중요한 질문은 테스트 자체는 누가 테스트하느냐임. 전통적인 개발에서는 모든 논리가 두 번 구현됨. 한 번은 코드에, 한 번은 테스트에 구현됨. 테스트는 코드를 검사하고, 반대로 코드는 암묵적으로 테스트를 검사함. 버그가 애플리케이션 코드가 아니라 테스트에 있었던 경우는 꽤 흔함. 테스트를 맹목적으로 신뢰한 채 에이전트가 테스트 버그를 코드에 복제할 방법을 찾을 때까지 기다릴 수는 없음
  • 작성자로서, 여기서는 특정 도구의 출력이 얼마나 효과적인지보다 도구 자체에 대해 말하려던 것임
    가비지 컬렉션 예시를 들면, 물론 언젠가 에이전트형 시스템이 뭔가를 띄워 테스트 하네스와 버그 수정 등으로 두들겨 맞춰낼 수는 있을지 모름. 하지만 모델을 가비지 컬렉터/도구 그 자체로 쓴다고 상상해 보라. 예를 들어 매번 sweep 때 프로그램 메모리를 모델에 던져 넣고 필요 없는 블록을 해제하라고 지시하는 식임. 모델이 올바른 메모리 블록을 정확히 식별한다고 절대 신뢰할 수 없고, 어떤 “패치”나 “미세 조정”으로도 거기에 도달하지 못할 것임
    JVM 같은 과거의 추상화에서는 결정적 출력, 이 경우 JIT가 내보내는 어셈블리가 잘못되면 그 버그가 패치되고 그 추상화는 다시는 같은 결함을 갖지 않음. LLM은 그렇지 않음. 산업의 성격 전체를 바꾼 과거 개발 도구들을 말할 때, 내게 이 차이는 매우 중요함. LLM이 미래의 작동 방식에 깊은 영향을 주지 않을 것이라고 말하는 건 아님. 다만 역사적 선례가 거의 없는 완전히 미지의 영역에 들어와 있다고 봄
  • “불완전하고 확률적인 행위자가 신뢰할 수 있는 결정적 시스템을 만들 수 있다”는 건 상당히 큰 말임. 본질적으로 엔트로피 기계인 시스템이 어떻게든 질서를 만든다는 얘기인가?
    테스트 주도 개발이 더 탄력을 받을 거라는 말도, 왜 TDD가 소프트웨어 구축의 모든 문제를 고치는 만능탄처럼 늘 제시되는지 모르겠음. 잘못된 테스트에서 출발해 TDD가 잘못된 소프트웨어를 만든 경우를 본 횟수는 사실 민망할 정도임

• 산출물을 명시해야지, 과정을 명시해서는 안 됨. 기여자가 패치를 이해해야 한다고 기대하는 것은 좋은 생각임
  하지만 온보딩 기간에 주니어가 LLM 보조 도구를 한동안 피하도록 권장하거나 요구하는 것은 끔찍한 생각임. 온보딩은 무작위적인 환경 설정 문제가 많고, LLM은 이런 데 꽤 강한 경우가 많음. 코드와 문서를 따라잡는 일이기도 하고, 공유하고 싶은 훌륭한 텍스트 검색/요약 도구들도 있음

  • 그런 문제를 헤쳐 나가는 법을 배우는 과정은 정말 중요함
    삶에서 모든 어려움과 복잡성을 매끄럽게 제거해 버리면, 머지않아 어려움이나 복잡성을 마주쳤을 때 무엇을 해야 할지 전혀 모르게 될 것이라는 건 아주 명백해 보임. 나만 그렇게 생각하나?

• LLM이 “일정 시간 동안 정답에 가까운 것을 근사하다가 시간이 지나면 정확도가 급락한다”는, 저자가 AI 절벽이라고 부르는 현상은 처음 들어봄. 다른 사람들도 겪어봤나?

  • 꽤 자주 겪음. 코드 복잡도가 어떤 임계값을 넘으면 LLM이 모든 것을 머릿속에 담지 못하고 허둥대기 시작함. LLM과 함께 일하는 내 역할 중 하나가 LLM이 보게 되는 복잡도를 관리하는 것임
    현재 생성기들은 시간이 지날수록 단순하게 만들기보다 더 복잡하게 만드는 경향이 있음. LLM에게 더 단순하게 리팩터링하라고 프롬프트를 주거나, LLM이 감당하기에 너무 복잡해졌을 때 내가 직접 리팩터링하는 쪽은 늘 나임. 그래서 적어도 현재 세대 LLM에서는 그냥 “LLM에게 고삐를 풀어주고” 마음대로 하게 두면 결국 거대한 루브 골드버그식 엉망진창을 만들어내고, 당신이 그걸 치우려 하게 되는 건 꽤 필연적으로 보임
    글의 요지와 연결하자면, 노련한 사람이라면 LLM이 당신을 먼바다로 끌고 가기 시작하는 걸 일찍 알아차리고, 조금 멀리 나가더라도 얕은 물로 돌아올 길을 찾을 수 있음. 초보자는 무슨 일이 벌어졌는지 알기도 전에 자기 깊이를 벗어나 바다에서 길을 잃게 됨
  • 이걸 문맥 취함이라고 부르는 걸 본 적 있음
    문맥 입력으로 99% 맞는 1만 토큰이 있다고 상상해 보라. LLM이 답할 때마다 90% 맞는 1000토큰을 추가함. 몇 번 주고받으며 LLM을 수정하고 나면, 문맥 창은 대부분 LLM 자신의 찌꺼기 출력으로 채워짐. 더 나쁜 건 오류가 누적된다는 점임. 맞는 90%조차도 잘못된 코드에 관한 논의를 올바르게 외삽한 것일 뿐이고, LLM은 더 최근 토큰을 더 중요하게 평가하기 때문임. 같은 문제는 산문에서도 나타남
  • 나는 이것을 문맥 부패라고 부름. 문맥이 차오를수록 출력 품질도 함께 침식됨. 문맥에 쓸데없거나 곁가지 논의가 많을수록 부패는 더 나빠지거나 더 빨라짐
    사고 모델에서는 이 문제가 더 악화될 수 있음. 사고 과정이 모두 문맥 안에 있고, 생각이 정말로 샛길로 빠지면 부패를 먹이는 독 씨앗을 심기 때문임. 어떤 형태로든 문맥 가지치기를 구현해서 무관한 문맥이 생길 때 잘라낼 수 있으면 좋겠음. 지금은 부패가 생기는 걸 느끼면 요약을 만들고 새 인스턴스로 옮김
  • 채팅 인터페이스로 바이브 코딩할 때, 즉 피드백 루프가 완전히 없을 때만 이런 일을 겪었음
    claude code, codex, gemini cli 같은 에이전트형 도구에서는 훨씬 덜한 문제임. 이들은 자기 문맥 창을 관리하고 개발 도구를 실행해가며 스스로 sanity check를 할 수 있기 때문임
  • 문맥이 너무 커지거나 오염되면 채팅/에이전트를 다시 시작해야 함. 예전 Windows와 비슷함
    이 과정은 새 에이전트가 따라잡을 수 있도록 현재 작업 상태를 문서화하는 습관을 훈련시켜 줌