AI: 가속된 무능력

 (slater.dev)
5P by GN⁺ | ★ favorite | 댓글 1개
  • 소프트웨어 엔지니어링에서 LLM에 과도하게 의존하면 단기 속도는 높아져도 비판적 사고와 문제 해결 능력이 약해질 수 있음
  • 잘못된 출력보다 더 큰 위험은 결함 있는 프롬프트를 그대로 받아들이고, 그 결과 기술 부채와 사용자 역량 저하가 빠르게 쌓이는 데 있음
  • LLM은 현재 컨텍스트 창을 넘어 프로그램 이론을 기억하거나 내면화하지 못하므로, 설계와 유지보수에 필요한 공유 정신 모델은 인간 엔지니어의 영역으로 남음
  • 복잡성은 유지보수 과정에서 계속 늘어나며, 텍스트 수준의 토큰 예측기인 LLM은 불필요하거나 이상한 변경으로 프로그램 엔트로피를 키울 수 있음
  • AI는 도구로 쓸 수 있지만 목발처럼 의존해서는 안 되며, 2019년에도 가치 있던 기초 엔지니어링 역량과 깊은 사고에 계속 투자해야 함

LLM 의존이 만드는 엔지니어링 위험

  • LLM을 “친구”처럼 부르는 태도는 실제 동반자라기보다, 사용자에게 이익을 준다는 완곡한 표현에 가까움
  • 이런 관점의 엔지니어는 대체로 속도를 우선하거나, 속도를 우선하라는 압박을 받음
  • LLM은 많은 코드를 빠르게 만들 수 있지만, 그 사용에는 긴 꼬리의 위험이 붙음

코드 생성에서 드러나는 다섯 가지 위험

  • 출력 위험

    • LLM은 컴파일되지 않는 코드처럼 명백히 틀린 결과를 낼 수 있음
    • 더 위험한 경우는 논리 버그처럼 미묘하고 감지하기 어려운 잘못된 결과임
    • 프롬프트 작성자가 결과를 평가할 자격이 없을 때 위험이 커짐
    • 예로 프로젝트 매니저가 소스 코드를 요청하는 상황이 나옴

  • 입력 위험

    • LLM은 유도 질문, 잘못된 가정, 불완전한 맥락을 가진 프롬프트에 이의를 제기하지 않음
    • 예를 들어 “C#에서 스레드 안전 리스트 구현을 제공하라”는 요청에는 200줄짜리 그럴듯한 코드가 나올 수 있지만, 실제 질문은 “이 코드를 스레드 안전하게 만들려면?”일 수 있음
    • 이 경우 답은 System.Collections.Concurrent를 쓰는 한 줄의 코드일 수 있음
    • LLM은 요청받지 않았기 때문에 XY Problem의 사례를 인식하지 못함

  • 미래 속도 저하

    • LLM은 코드베이스 품질을 매우 빠르게 낮출 수 있음
    • 강한 가드레일이 없으면 LLM 생성 코드는 겉으로는 멀쩡하지만 내부는 비위생적이고 비기능적인 공간처럼 변할 수 있음
    • 이는 일반적인 기술 부채 논의보다 더 긴급한 문제로 취급됨

  • 사용자 유아화

    • 사고와 문제 해결을 LLM에 넘기는 개인과 조직에서는 재능이 사라질 수 있음
    • 시니어 엔지니어는 생산적인 고투를 통해 배우는 기회를 잃으면서 문제 해결력과 비판적 사고가 약해질 수 있음
    • 주니어 엔지니어는 그런 역량을 처음부터 개발하지 못하고, 이후 미래의 주니어를 멘토링하기도 어려워짐
    • ThoughtWorks Technology Radar Volume 32는 AI 기반 자신감이 비판적 사고를 희생하는 경우가 있다고 다룸
    • Coding as Craft: Going Back to the Old Gym은 코딩을 공예로 보존하는 의도적 AI 협업을 강조함
    • Thoughts on Thinking는 LLM이 완성된 생각을 줄 수는 있어도 스스로 발전시키는 지적 성장은 주지 못한다고 봄

  • 즐거움 상실

    • 많은 개발자가 AI 사용이 몰입 상태와 창작의 즐거움을 빼앗는다고 보고함
    • AI 생성 코드는 읽고 변경하기 괴로운 코드가 될 수 있음
    • 관련 글로 The Hidden Cost of AI Coding가 연결됨

LLM이 대체하지 못하는 두 가지 역량

  • 숙련된 엔지니어가 AI 때문에 불필요해질 것이라는 걱정에 대해, LLM이 제공하지 못하는 프로그래밍 역량은 두 가지로 정리됨
  • 그 역량은 프로그램 이론과 프로그램 엔트로피임

프로그램 이론: 코드는 프로그램 그 자체가 아님

  • Peter Naur의 Programming as Theory Building은 프로그래밍을 문제에 대한 통찰이나 이론을 형성하는 활동으로 봄
  • Naur의 관점에서 프로그램은 소스 코드가 아니라 공유된 정신적 구성물, 즉 이론 또는 설계임
  • 코드는 그 설계에서 파생되지만, 가치 있는 산출물은 코드보다 설계에 있음

  • 두 팀 사고 실험

    • 같은 역량의 두 팀 A와 B가 서로 소통하지 않는 별도 방에 있음
    • A팀은 터미널 기반 체스 게임 같은 프로그램을 작성하고, B팀은 기다리거나 실제 체스를 둠
    • A팀이 끝낸 뒤 소스 코드가 B팀에 전달되고, 두 팀 모두 가상 체스 플레이어 같은 기능을 추가해야 함
    • 더 나은 해법을 낼 팀은 A팀임
    • A팀은 방금 만든 프로그램의 신선한 정신 모델을 갖고 있음
    • B팀에는 그런 모델이 없음
    • 프로그램은 초기 생성 이후 계속 수정되므로, 소스 코드만 있고 설계에 대한 내면화된 이해가 없으면 변경 비용이 높아짐
    • 큰 기존 코드베이스에 처음 들어갔을 때 생산성이 거의 0에 가깝다가, 프로그램 이론을 머릿속에 적재하면서 생산성이 오르는 경험과 연결됨

  • LLM과 프로그램 이론

    • 현재의 LLM은 컨텍스트 창 너머를 기억하지 못하므로 이론, 설계, 정신적 구성물을 숙달할 수 없음
    • 프로그램 이론을 얻고 유지할 수 있는 존재는 인간임

프로그램 엔트로피: 복잡성을 줄이거나 저항하는 능력

  • 복잡성은 프로그래밍에 맞서는 근본적인 힘이며, 엔트로피와 상관됨
  • Fred Brooks의 _The Mythical Man-Month_는 프로그램 구축을 엔트로피 감소 과정으로, 유지보수를 엔트로피 증가 과정으로 봄
  • Brooks의 관점에서 초기 구축 이후 프로그램 변경은 소스 코드를 더 복잡하게 만들 수밖에 없음
  • 다만 설계와 조화를 이루는 변경은 복잡도 증가 속도를 늦출 수 있음

  • LLM과 프로그램 엔트로피

    • LLM은 토큰 예측기이며 텍스트 수준에서만 작동함
    • LLM은 아이디어, 다이어그램, 요구사항 명세 같은 개념 수준에서 추론하지 못함
    • 큰 코드 덩어리를 LLM에 넣어 본 사람은 LLM이 불필요하고 이상한 변경을 적용하는 경향을 보게 됨
    • 대화가 길어질수록 결과가 더 벗어날 수 있음
    • 코드의 복잡성을 줄이거나 복잡성에 저항하는 능력은 인간에게 있음

엔지니어링에서 AI를 쓰는 방식

  • AI가 엔지니어링 경력을 다음 단계로 올려줄 것이라고 기대했다면, 반대로 작용할 수 있음
  • LLM은 무능력을 가속할 수 있지만, 인간 엔지니어링을 대체하지는 못함
  • AI의 사업적 매력은 엔지니어링을 상품화해 비용을 줄이는 데 있음
  • 다만 해외 엔지니어링 인재 활용이 혼합된 결과를 낳는 것처럼, LLM도 한계와 위험을 동반함
  • AI 하이프 사이클은 결국 정점에 이를 수 있음
  • 지금 AI를 과도하게 쓰는 기업은 긴 꼬리의 비용을 떠안게 되고, 방향을 바꾸거나 사라질 수 있음
  • 엔지니어링에서 인간의 장기 가치 제안은 변하지 않음
    • 세상은 여전히 기술 역량과 깊은 사고를 필요로 함
    • 그런 역량에 비용을 지불할 것임
  • AI는 계속 남겠지만, 도구로 사용해야 하며 목발처럼 의존해서는 안 됨
  • 2019년에 가치 있다고 여겨졌던 기본 엔지니어링 역량에 계속 투자해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • AI 코딩 담론은 소프트웨어 엔지니어와 데이터 과학자/머신러닝 엔지니어의 차이를 반영하는 것처럼 느껴질 때가 있음
    둘 다 불명확한 요구사항과 잡기 어려운 버그를 다루지만, 대체로 소프트웨어 엔지니어는 항상 특정 방식으로 동작해야 하는 소프트웨어를 만들고, 재현 가능성과 테스트, 성숙한 도구가 중요함
    반면 머신러닝 엔지니어는 본질적으로 확률적인 모델을 다루며, 테스트도 특정 출력을 내는지보다 “90%의 경우 올바른 출력” 같은 평가 지표 중심임
    그래서 항상 신뢰할 수 없는 AI를 다루는 사고방식이 머신러닝 쪽에는 더 자연스럽고, “80%는 맞아서 수고를 줄이고 20%는 내가 잡으면 된다”처럼 코딩 도우미를 평가하게 됨

    • 내 경험으로도 절반쯤은 맞음. 실제 시스템에서 머신러닝을 잘 쓰는 뛰어난 소프트웨어 엔지니어가 있는 반면, 도메인 전문가가 만든 잘 이해된 시스템을 머신러닝이 대체할 거라고 믿는 사람들도 있음
      Amazon에서 일할 때는 고전적 접근법이 없는 실제 문제에 머신러닝 기반 해법이 잘 들어맞는 경우가 많았음. 예를 들어 격자 지도 기반 운동 예측이나 이미지/격자 지도 분류는 기존 추정·제어 파이프라인에 잘 통합되어 유용했음
      반대로 어떤 스타트업에서는 정지한 평면의 방향을 시간에 따라 추정하는 문제에 학습 기반 접근을 의심했다는 이유로 하급 관리자에게 계속 질책받았음. 팀이 매핑이나 필터링의 기본을 모르고 “데이터를 더 넣으면 해결된다”고 가정한 탓에 차량 제어 파이프라인 전체가 깜빡이고 튀는 임의 회전 추정값을 먹고 있었음
      이 간극은 실제로 크고, 면접에서 더 잘 가려낼 방법이 있으면 좋겠음
    • 지금 분위기에서는 머신러닝 엔지니어들이 자기 사고방식을 맞지 않는 다른 조직에 밀어붙일 힘을 얻은 것처럼 보임
      예전에 회사의 시니어 아키텍트가 회의 뒤에 불평하는 걸 들었는데, 우리 회사 제품은 정확성과 올바름이 늘 큰 판매 포인트였는데 다른 사무실의 머신러닝 팀은 그걸 이해하지 못하고 80~90% 정확하면 고객에게 충분하다고 여겼음
      팬데믹 질병의 1% 치명률이 작냐 크냐 논쟁이 떠오름. 1은 가장 작은 정수지만, 3억 명의 1%는 300만 명임
    • 여기서 말하는 건 결정적 동작과 확률적 동작의 차이고, 일부 담론은 그 설명과 맞아떨어짐
      하지만 이 글은 그 얘기만은 아니라고 봄. 글은 소프트웨어 엔지니어링을 하는 사람들이 가진 메타 수준의 우려와 AI가 거기에 어떻게 들어맞는지를 다루며, “프로그램 엔트로피”를 말할 때 핵심을 짚었다고 봄
      소프트웨어 제품을 만드는 일의 큰 부분은 엔트로피 관리임. 코드와 사람을 늘리면서도 적절한 전진 속도를 유지하고, 모두가 조각들이 어떻게 맞물리고 새 조각을 어떻게 더할지 이해하게 해야 함. 언젠가 AI가 이를 더 쉽게 만들 수도 있겠지만, 지금은 오히려 엔트로피를 악화시키는 경우가 많음
    • 90% 정답으로는 절대 충분하지 않은 사용 사례가 너무 많음
      이해관계가 있는 사람들이 “그렇지 않다, AI는 모든 것에 바로 쓸 수 있다”고 설득하려 들지만 않았다면 큰 문제가 아니었을 것임
      이 가정은 논리로 반박하기조차 어려울 만큼 터무니없고, 지금까지는 막대한 투자를 끌어내고 수익 중심 인력 최적화를 포장하는 믿음 기반 서사로는 매우 성공적이었음
    • 소프트웨어 엔지니어도 확률을 늘 씀. 경쟁 상태를 구조적으로 고칠지 영향 범위를 줄일지, 데이터베이스 호출의 p99가 얼마나 될지, A/B 테스트 등 전부 확률적 판단임

  • 글의 전제와 대부분의 구체적 논지에 강하게 동의하지만, 일상에서 LLM을 쓰며 긍정적인 면도 보고 있음. 참고로 소프트웨어 업계에서 30년쯤 일했음
    AI 생성 코드를 다루면 코드를 읽게 됨. 개발이 처음부터 창조하는 여정보다 일련의 코드 리뷰에 가까워지고, 솔로 개발자에게는 팀에서만 배우기 쉬운 책임을 흉내 내며 익히게 해준다는 장점이 있음
    또 LLM과 일하려면 개발자가 문제를 명확하고 잘 구조화된 계층으로 이해해야 한다는 점이 금방 드러남. 큰 걸 한 번에 시키면 보통 자기 발을 쏘게 되므로, 설계 관점에서 접근하고 상세 명세를 쓰고 부분별로 구현하는 방식이 개념적 블록의 경계와 인터페이스를 정하는 데 도움이 됨
    LLM은 주니어 개발자가 시니어 역할로 성장하는 데 도움을 주는 강력한 가속제로 볼 수 있음. 적절한 안내가 있으면 더 경험 많은 사람들이 시간을 들여 배운 교훈의 진행 과정을 드러내 줌. 전부 암울하다고 보지는 않고, AI가 개발자를 대체하지도 않을 것이며, 지금은 매우 파괴적이지만 결국 다른 도구들 사이 어딘가에 자리 잡을 것 같음

    • 균형 잡힌 입장에 공감함. 쓰는 코드보다 읽는 코드가 적은 개발자는 잘못하고 있다고 봄. 코드 읽기는 소프트웨어 엔지니어 성장의 핵심임
      LLM이 도와 만든 코드를 리뷰하면 더 밋밋한 코드를 읽게 된다고 볼 수도 있지만, 그래도 배운다고 생각함. LLM 생성 코드를 많이 읽었고, 익숙하지 않은 관용구나 몰랐던 라이브러리 호출을 자주 배움
      시니어 개발자에게도 LLM은 더 강력한 가속제임. 무엇이 존재하고 무엇을 시도할 필요가 없는지 알기 때문에 더 잘 프롬프트할 수 있음
    • 코드 리뷰의 연속이 된다기보다는, 누군가가 프로토타이핑을 대신해 주는 느낌에 가까움. 빈 페이지 문제를 해결하는 데는 좋지만, 그대로 리뷰하고 커밋할 물건은 아님
    • 문제는 Scott Kilmer식으로 말하면 기업은 목 위가 죽어 있다는 것임. 기업의 결론은 AI가 주니어를 도와준다는 게 아니라, 주니어를 뽑지 않고 시니어에게 AI 도움으로 마법 같은 10배 생산성을 요구하겠다는 쪽이 됨. 심지어 시니어도 AI 때문에 잘리고 있음
      최근 뉴스만 봐도 Big Tech, 중견 기술기업, 작은 기술기업에서 해고가 계속 이어짐

  • 3D 프린팅이 모든 제조를 대체할 거라던 때를 기억함?
    AI는 특이점보다는 이 정서에 더 가까움

    • 좋은 비유임. 3D 프린팅은 멋지고 매우 유용한 기술이며 정말 세상을 바꿨음. 하지만 사출 성형은 계속 남아 있음
    • 특이점으로 이어지지 않을 수는 있지만, 학계에서 과제 출제·채점·강의 노트 측면에서는 좋든 나쁘든 AI가 엄청난 영향을 줬음
      LLM이 뭔가를 개선했다기보다 시스템적 결함을 드러냈을 뿐이라고 볼 수도 있지만, 영향 자체는 분명함. 2년 전에는 표준적이던 수십 가지 강의 흐름이 더 이상 작동하지 않음
      특히 온라인·원격 교육 전체가 여기에 포함되는데, 아이러니하게도 많은 대학이 Covid 이후 여기에 투자하기 시작한 바로 그 시점에 ChatGPT가 나왔음. 전 세계 고등·중등 교육 영역 전체 규모의 영향임
    • 쉽게 던질 수 있는 농담이지만 꽤 틀렸음. 3D 프린팅은 여러 산업에서 거대한 돌파구였고 기존 상태를 근본적으로 바꿨음
      항공우주가 좋은 예임. SpaceX와 이 분야의 젊은 신생 기업들이 하는 많은 일은 3D 프린팅 부품 없이는 가능하지 않았을 것임. 노즐, 연소실, 터보펌프 같은 부품이 자주 출력됨
    • 은행을 Bitcoin이 대체할 거라던 것과도 비슷함. 결국 은행들이 Bitcoin 기반 금융 도구를 팔게 됨
    • 솔직히 그 시절을 기억하지는 못함. 어쩌면 그 과장 주기는 내 시대 이전이었을 수 있음
      그래도 이 비교는 공정하지 않아 보임. 기계공학을 하던 시절 3D 프린팅은 더 빠르고 싸게 시제품을 만들고 실수하게 해줘서 내 엔지니어링 실력을 오히려 좋게 만들었음
      모든 제조를 대체하지는 못했지만 설계에서 중요한 역할을 하고, 사용자의 실력을 퇴화시키지는 않았음

  • LLM은 코드를 쓰는 데는 놀랍지만, 그 코드를 소유하고 유지하는 데는 형편없음
    이해하지 않고 받아들인 모든 줄은 빌린 이해이며, 유지보수 때 높은 이자로 갚게 됨. 공짜 속도처럼 느껴지지만 실제로는 연 40%쯤 이자가 붙는 기술 부채에 가까움
    우리 집단은 AI로 타이핑은 자동화하되 생각은 자동화하지 않는 방법을 찾아야 함

    • “빌린 이해”가 되려면 LLM이 인간 엔지니어에게 적용하는 의미의 이해로 자신이 쓰는 걸 실제로 이해해야 함
      하지만 그렇지 않고, 작동 방식상 그럴 수도 없음
      따라서 이해하지 않고 받아들인 LLM의 모든 줄은 사실 존재하지 않는 이해임. 확률 모델이 뱉은 코드 한 줄일 뿐이고, 코드베이스의 맥락·시스템·설계를 실제로 이해할 수 있는 존재가 보기 전까지는 이해되지 않은 상태임. 현재 그런 존재로 알려진 것은 인간뿐임
    • 작업에 따라서는 코드 작성 자체도 형편없음
    • 아주 좋은 비유임. 이 이자율은 TDD와 격리된 하위 시스템의 크기 축소로 꽤 줄일 수 있을 것 같음. 그러다 보면 마이크로서비스처럼 보이기 시작할 수 있음
      전통적 개발에서는 둘 다 별로 좋아하지 않지만, 현재 LLM은 둘을 더 쉽고 유용하게 만듦
      그리고 “세 번의 법칙”은 컴포넌트 사이에서는 사실상 적용이 멈춤. 코드 영향이 국소적이거나, 매우 견고한 기반 라이브러리의 일부이거나 둘 중 하나여야 함. 중간 사례는 리팩터링 복잡도를 폭발시킴

  • “LLM은 유도적인 프롬프트에 이의를 제기하지 않는다”는 입력 위험이 지금까지 가장 큰 고통이었음
    더 답답한 건 내가 특정 방향으로 유도하고 있다는 사실조차 모를 수 있다는 점임. LLM 작동 방식을 생각하면 말은 되지만, 모호하게 쓰인 단어 하나만으로도 결과가 나쁜 방향으로 치우치고, 내가 원한 것과 반대로 가서 틀린 토끼굴로 빠질 수 있음
    깨달았을 때는 그럭저럭 간신히 작동하는, 되는대로 엮인 코드 진흙탕 한가운데 있음. 인간 언어가 매우 모호하고 비특정적이라서, 애초에 정밀성을 허용하는 규칙 있는 형식 언어를 발명한 것과 거의 같음
    개인적으로 AI 도구 때문에 실력이 빠르게 퇴화하는 느낌도 받았음. 한때는 게을러서 작은 일마다 AI에 손을 뻗었지만, 한 걸음 물러서 보니 시간도 그다지 아끼지 못했고, 오히려 수십·수백 줄의 코드를 읽고 AI가 어떻게 틀렸는지 생각하고 고치느라 훨씬 빨리 지쳤음
    측정한 건 아니지만 전체적으로는 AI 도구로 절약한 시간보다 낭비한 시간이 훨씬 많았던 것 같음
    진짜 문제는 AI가 많은 작업에 실제로 유용하지만, 사용하는 사람이 두 부류라는 점임. 한쪽은 작은 실수가 빠르게 누적되는 복잡한 작업에 쓰고, 다른 한쪽은 주로 관리자 유형인데, 이해하지 못하는 코드 200줄을 뱉는 걸 보고 간신히 작동하는 TODO 앱 정도를 “MVP”로 여기며 “이걸 만들 수 있으니 네 일도 쉽게 할 수 있다”고 생각함
    내가 잘못 썼다거나 모델이 틀렸다거나 하는 흔한 답을 하려면, 이 도구들에 대한 내 경험 맥락으로 예전 댓글 https://news.ycombinator.com/item?id=44055448을 먼저 읽어주면 좋겠음

    • 지금까지 내 경험으로는 문제 해결 방식에 대한 다른 견해를 얻는 데 도움이 되고, 결국 작업은 내가 함. 또는 아주 구체적으로 지시하고 비교적 작은 문제를 주면 코드를 작성해 주고, 내가 코드 리뷰를 하며 내 기준에 맞게 고침
      즉 AI는 내 조수지만, 품질 좋고 유지보수 가능한 결과물을 내는 책임은 내게 있음
      다만 대중적 관점에서 보면 소박한 계산기를 생각해 보면 됨. 계산기는 사람들의 암산 능력을 망쳤음. AI는 글쓰기와 의사소통 능력, 문제 해결 능력 등에 그런 일을 하게 될 것임
    • 모호한 단어 하나가 결과를 나쁜 방향으로 치우치게 한다는 느낌이 나만의 것은 아니라서 다행임
      모델들이 프롬프트 흐름 어딘가의 특정 키워드에 달라붙어 전통적인 논리를 버리고, 원래 문제도 제대로 해결하지 못하는 더 좁은 길로 밀어 넣는 것 같음. 결국 인간 쪽의 좌절과 불행만 커짐
      실력 퇴화를 막으려고, 원래 StackOverflow 검색으로 해결하던 작고 명확한 작업에만 AI를 쓰려 하고 있음. “X를 어떻게 하지?”를 검색하는 대신 모델에 같은 질문을 하고, 그 답을 정답이 아니라 문제 해결 안내로 씀
    • “AI가 할 수 있다”에서 “o2.7 모델을 RAG가 붙은 IDE에서 쓰고 프롬프트에 방법까지 알려줬으면 할 수 있었을 것”으로 골대를 옮기는 느낌에 크게 공감함. 어느 순간부터는 그냥 내가 코드를 쓰는 것보다 노력 대비 가치가 낮아짐
      그래도 오늘날 AI가 더 쉽게 만드는 일은 있음. 예를 들어 “이 페이지처럼 만들되 y 대신 x 데이터를 써줘”처럼 쓸 예제가 있으면 문서를 찾는 것보다 빠를 때가 많음. 환각할 수 있다는 단서는 있지만, 시간이 지나며 나아질 가능성도 큼
      보고 싶은 개선은 전반적으로 더 정확해지는 것과 함께, 매번 말하지 않아도 가장 단순한 해법을 찾는 것임. ChatGPT, Claude 등을 풀어놓을 때 가장 큰 단점은 쓰레기를 빠르게 잔뜩 만들고, “이건 나중에 다루기 너무 복잡해진다”고 멈추지 않는 점임. 원문은 전체 설계를 이해하는 인간만이 엔트로피에 저항할 수 있다고 주장하는데, 이 부분이 영원히 개선되지 않을지는 몰라도 지금 가장 큰 문제처럼 느껴짐
    • 이런 “예상 못 한 유도”를 피하고 싶을 때는 LLM에게 먼저 “각 라운드마다 5개씩, 3라운드의 명확화 질문을 해줘”라고 시킴
      첫 라운드에서 보통 모델이 하고 있는 주요 가정이 드러나고, 거기서부터 좁혀 가며 명확히 할 수 있음
      여러 시도를 했다는 예전 댓글을 읽어보니 LLM 경험은 나보다 훨씬 넓어 보였음. 다만 이 기법은 보이지 않아, 누군가에게 도움이 될까 남겨둠
    • 사람도 비슷한 편향이 있음. 다만 사람보다 LLM의 편향을 테스트하기가 훨씬 쉬워서 우리가 LLM 편향을 더 잘 인식하는 것뿐임

  • “아이디어, 다이어그램, 요구사항 명세를 추론하지 못한다”, “복잡성을 줄일 수 있는 것은 인간뿐이다” 같은 말은 흥미로운 개념 뒤에 명백히 틀린 세부 주장이 붙는 경우처럼 보임
    이건 아주 쉽게 할 수 있음. 더 단순한 코드를 달라고 요청하면 됨. 나는 두 번째 견해를 얻는 용도로 자주 쓰고 좋은 결과를 얻고 있음
    모델에 질의하지 않으면 복잡한 답도 단순한 답도 얻지 못함. 기본 옵션으로 질의하는 것도 선택이지, LLM이라는 개념에 내재한 것은 아님
    코드와 아이디어·다이어그램을 서로 변환하는 데도 잘 쓰고 있음. 사람들이 매일 실전에서 반박하는 강한 주장을 왜 하는지 모르겠음

    • “LLM은 개념으로 추론할 수 없다”는 밈은 이미 사라졌어야 한다고 봄. LLM은 말 그대로 개념의 구현체이며, 추론 중 특정 개념을 식별하고 억제하거나 증폭하는 방법을 포함해 여러 방식으로 실험적으로 입증됐음
      글은 겉보기에는 맞지만 자세히 보면 버티지 못하는 이상한 논리도 반복함. Naur 얘기는 이제 밈이 되었고 현실에서 통찰처럼 반복되지만, 소프트웨어 엔지니어링의 또 다른 근본적이고 실용적인 규칙을 잊고 있음. 사소하지 않은 프로그램은 곧 한 사람이 전체 이론을 머릿속에 담을 수 있는 능력을 넘어섬
      우리는 거의 제대로 된 프로그램 이론을 갖고 일하지 않음. 프로그래밍 언어, 기법, 방법론, 도구는 모두 사람들이 대부분의 코드를 이해하지 않고도 더 잘 일하게 하는 방향으로 발전함
      이 점에서는 인간도 LLM과 같은 한계를 공유하고, 다만 우리는 다른 관점을 얻기 위해 또 한 번의 추론 루프를 허락받을 때까지 기다릴 필요가 없어서 더 잘 관리할 뿐임
    • 주니어 엔지니어의 코드를 리뷰할 때 계속 마주치는 큰 문제는 코드 품질 자체보다 해결 방향임. LLM 모델이 “왜 그 방식으로 하려 하느냐”고 되물을 수 있는지 잘 모르겠음. 유명한 StackOverflow식 답변처럼 말임
    • 코드를 다이어그램으로 바꾸는 건 수동으로 하는지, 자동화 도구가 있는지 궁금함. 후자를 찾고 있음

  • Google Maps나 Apple Maps 같은 지도 기술에도 비슷한 논리를 적용할 수 있다고 봄. 이런 도구를 쓰면 물리 세계를 탐색하는 능력, 방향 감각과 지리 감각이 퇴화한다는 주장임
    실제로 틀린 말은 아님. 요즘 사람들은 Google Maps 같은 버팀목 없이는 길 찾기를 어려워하는 경우가 많고, 물리 세계와의 관계도 여러 면에서 바뀌었음
    하지만 예전에도 많은 사람이 길 찾기를 특별히 잘하지는 않았음. 특히 낯선 지역에서 A 지점에서 B 지점까지 안전하고 안정적으로 가는 평균 능력은 확실히 크게 올라갔음
    그리고 지리와 길 찾기에 타고난 소수의 사람은 Google Maps 같은 도구로 능력이 대체된 게 아니라 보완됐음
    AI도 더 큰 규모에서 비슷하게 끝날 것 같음. 분명 트레이드오프가 있고 일부 기술과 능력은 줄겠지만, 훨씬 더 많은 사람이 이전에는 못 하던 일을 할 수 있게 되고, 소수는 자신이 하는 일을 더 잘하게 될 것임

    • 문제는 지도 소프트웨어가 신뢰 가능하고 본질적으로 난수 생성기 같은 결과를 뱉지 않는다는 점임. 계산기를 신뢰하듯 그 출력에 의존할 수 있음
      물론 항상 그런 건 아님. 전 세계를 매핑하는 일은 수많은 예외와 경계 사례가 있는 매우 복잡한 작업이기 때문임. 하지만 LLM 출력과 비교하면 차이가 큼. 온도를 0으로 두고 같은 프롬프트를 여러 번 재생성해도 출력이 크게 달라짐
      또 LLM은 훨씬 넓은 개념 범위를 다루기 때문에 사람들이 정말 그러면 안 되는 많은 상황에서 자기 머리 대신 이를 쓰게 될 것임. 지도만 해도 Google Maps가 길이라고 해서 호수로 운전해 들어가는 사람이 있는데, LLM 출력을 맹신하고 자기 사고를 대체할 때 어떤 일이 벌어질지 상상도 안 됨
    • 개인적 경험으로는 정반대였음. 지도 소프트웨어 덕분에 아무 방향으로나 걸어가도 필요할 때 자신 있게 경로를 수정할 수 있고, 한 번 걸어간 길은 기억에 잘 남음
    • 신뢰도 차이가 너무 커서 비유가 적절하지 않음
      내가 사는 곳에서는 Google Maps가 택시 기사보다 90%의 경우 더 나음
      AI는 그 일을 며칠 해본 사람보다도 낫지 않음
    • 낯선 지역에서 A에서 B로 안전하고 안정적으로 가는 평균 능력이 크게 올랐다는 증거가 있음?

  • 현실적으로 직원의 70%는 일을 너무 대충 해서 AI가 종종 그만큼 하거나 더 잘함
    진짜 어려움은 대충 하던 사람들은 AI를 써도 여전히 쓸모없고, 나머지 사람들은 AI와 함께 배우고 성장한다는 데 있음

    • 매우 자기중심적인 서사임. 본인은 30%에 속한다고 가정하는 건가?
    • 자기 일을 AI에 외주 주는 사람들은 컴퓨터 프로그램이 자기 일을 더 잘할 수 있음을 증명할 뿐 아니라 그 길까지 닦아주며 해고당하겠다고 요청하는 것과 거의 같음
    • 대기업에서는 이 말이 맞고, 지금까지 읽은 AI 코딩 관련 견해 중 가장 좋을지도 모름
      완전자율주행도 비슷함. FSD는 형편없거나 술 취했거나 문자하는 인간 운전자보다 나은데, 도로에는 그런 운전자가 많음

  • “[AI]는 개념 수준에서 작업할 수 없다”는 느낌을 저자가 어디서 얻었는지 궁금함
    최근 LLM들이 반복해서 입증한 것은, 예를 들어 맥락에 따라 한 언어의 개념을 다른 언어로 올바르게 번역하는 식으로 분명히 개념 수준에서 작업할 수 있다는 점임
    인간처럼 개념을 “이해”하지 않는다는 말은 별개임. 고통을 경험하지 않았으니 고통을 “이해”하지는 못하겠지만, 인간도 직접 경험하지 않은 것에 대해 끊임없이 말함. 그래도 되는지는 다른 주제임

    • LLM은 개념의 대리물로 주어진 계량 구조를 가진 토큰 공간에서 작동함. 이 공간의 한 지점에서 “dog” 토큰 주변에 군집한 지점들 쪽으로 걸어갈 수 있음
      이는 연관 같은 개념의 일부 특징에 대한 약한 모델임. 예를 들어 “dog”는 “cat”과 연관됨. 하지만 합성성, 내포, 반사실 조건문에서 용어가 맡는 역할 같은 것은 모델링하지 않음
      다만 질문이 훈련 데이터와 비슷하다면 겉보기 개념 능력을 무식하게 밀어붙여 얻을 수는 있음. 누군가가 “개들이 화성에서 놀면 행복할까?” 같은 질문 또는 충분히 비슷한 질문군을 했다면, “dog”를 “문자적 사실” 군집과 이미 알려진 반사실 일부의 군집 주변에 둘 수 있음
      이것과 진짜 정신 능력의 차이를 보려면, 임의 깊이의 개념 조합은 무한하고, 무한한 수의 반사실로 구성될 수 있다는 점을 보면 됨. 기본 구성요소와 상상력만 가진 아이는 이 무한한 다양성을 평가할 수 있음
      그래서 LLM은 필요한 “개념 작업”이 매우 잘 문서화되어 있고 충분히 안정적인 좁은 분야, 특히 소프트웨어 엔지니어링에서 가장 많이 쓰이는 것임
    • 극단적으로는 실경험이 없어도 무심상증, 공감각, 색맹 같은 것을 말하고 개념을 이해할 수 있음

  • 90s.dev를 AI가 없는 커뮤니티로 바꿔야겠다는 생각이 점점 강해짐. 소프트웨어를 잘 작성하는 고대의 기술에 집중하고, 그 기술을 갈고닦은 모두를 환영하는 곳이면 좋겠음
    시작하려면 무엇이 필요할까? 포럼? 메일링 리스트? hackernoon처럼 여러 저자의 블로그를 모으는 방식?
    관심 있는 사람들을 위한 임시 메일링 리스트는 https://github.com/sdegutis/90s.dev/issues/2에 만들었고, 해당 주제의 이메일을 받으려면 구독하거나 댓글을 달면 됨

    • 구독이나 댓글이라니? 이건 내 타깃 시장에 맞음. 다만 “구독”이라는 단어만큼 뭔가 하려는 마음을 꺾는 것도 없음
      포럼은 LLM과 봇 때문에 망가졌으니 그 선택지는 빠짐. 이런 것이 작동하려면 초대 전용이어야 하고, 각 추천자가 자기 초대 트리에 책임을 져야 함
      커뮤니티가 접근 권한을 잃는 것이 좋은 행동을 유도할 만큼 좋아야 함. 온라인의 특정 커뮤니티에서는 이 방식이 매우 잘 작동함
    • 그 시절 클래식 포럼들을 돌렸던 훌륭한 OG 포럼 소프트웨어를 쓰면 됨. 세련되게 복고풍으로 만들면 좋겠음
답변달기