▲

나의 AI 회의론자 친구들은 모두 미쳤음

 (fly.io)
19P by GN⁺ 4일전 | ★ favorite | 댓글 4개
  • AI 기반 프로그래밍 도구인 LLM은 이미 소프트웨어 개발 현장에서 필수적 위치를 차지함
  • 많은 지인들은 AI가 일시적 유행이라 믿지만, 글쓴이는 개발 영역에서는 이미 생각을 바꿀 때임을 강조함
  • 코딩 에이전트는 반복적이고 지루한 작업을 자동화해 개발자를 더 의미 있는 일에 집중하게 해줌
  • AI로 생성된 코드의 품질, 소유권, 도구 지원 등 논란이 있지만, 대부분 기존 개발 환경의 문제를 답습하는 수준임
  • LLM 도입에 대한 소극적 태도는 올바르지 않으며, 앞으로 더욱 중요한 기술 변화가 다가옴을 시사함

서론: AI와 프로그래밍, 그리고 회의론

  • 최근 테크 기업 경영진들이 LLM 도구의 도입을 강제하는 경향이 있으나, 이는 잘못된 전략임
  • 글쓴이 주변의 똑똑한 개발자 중 일부는 AI가 NFT와 같은 일시적 유행이라 여기며 이를 진지하게 받아들이지 않음
  • 그러나 실제로는 이미 LLM이 도입됨으로써 개발 영역에 큰 변화가 일어난 상황임
  • 본문에서는 소프트웨어 개발 내에서의 LLM 의미에 집중하고, 예술·음악·글쓰기 등 타 분야에 대해서는 언급하지 않음

LLM 에이전트와 현대적 사용 방식

수준 맞추기: 과거의 LLM vs. 현재의 에이전트

  • 6개월~2년 전 ChatGPT나 Copilot을 단순 활용하던 때와는 다른, 진화된 LLM 에이전트 환경이 확산 중임
  • 오늘날의 개발자들은 에이전트가 코드베이스를 자유롭게 탐색·수정하게 하며, 이를 통해 파일 생성, 컴파일, 테스트, 반복 수행을 자동화함
    • 코드 트리 및 외부 소스의 코드 제공, Unix 도구 기반 정보 추출, Git 상호작용, 각종 개발 툴 실행 등을 지원함
  • 실제 코드 조작 로직 자체는 단순한 시스템 코드임
  • 과거처럼 ChatGPT에서 코드를 복붙하는 것은 본질적 변화를 경험하지 못하는 것과 같음

LLM의 긍정적 효과

  • 대부분의 프로젝트에서 발생하는 단순 반복 코드는 LLM이 쉽게 생성할 수 있음
  • LLM은 검색·문서 확인 없이 정보 챙기기에 능하며, 피로 누적으로 인한 비효율에서 자유로움
  • 원하는 기능 개발 시작이 어려웠던 이유가 새로운 언어·환경의 진입장벽 탓일 때, LLM은 이를 크게 완화해줌
  • 유지보수적 테스트 코드 리팩터링, 의존성 처리 등 개발에서 귀찮은 일은 LLM이 대신 처리할 수 있음
  • 개발자는 중요하고 창의적인 영역에 더 많은 에너지를 쏟을 수 있음

“LLM이 생성한 코드를 이해 못 한다”는 주장에 대한 반론

  • 팀에서 병합하는 코드는 직접 읽고 스타일에 맞게 수정하는 것이 당연함
  • LLM이 만들어내는 코드는 "알고리듬적으로" 예측 가능하며, 결과물을 이해하고 검토할 수 있음
  • 반복적인 코드 리뷰 능력이 부족하다면, 인간 개발자가 만든 난잡한 코드 역시 소화하지 못할 가능성이 큼

“AI의 환각(hallucination) 문제”에 대한 시각

  • LLM 에이전트는 코드 린트, 컴파일, 테스트까지 수행해 허위 정보를 바로잡으며 신뢰성을 확보함
  • 환각 문제는 대부분 환경에서 이미 어느 정도 해결됨
  • 효과적으로 활용하려면 세밀한 감시보다는 자동화 프로세스 신뢰가 필요함

“AI 코드는 실력이 낮다”는 비판

  • LLM 서비스 비용은 인턴 급여보다 저렴함 (예: Cursor.ai 월 $20)
  • 시니어 개발자는 능력이 부족한 인턴 혹은 LLM 코드의 생산성을 높여주는 역할을 함
  • 코딩 에이전트 활용 역량, 툴링, 프롬프트 설계도 새로운 기술적 숙련도 영역임
  • “누가 무슨 작업을 분담하느냐”에 대한 혼란이 있으며, 근본적으로 개발자는 방향성과 검증, 판단을 책임짐

“Rust에서 AI 성능이 낮다” 논란

  • 특정 언어나 도구와의 호환성 한계는 특정 생태계의 숙제임
  • Go와 같이 LLM 친화적 언어에서는 AI 활용도가 매우 높음
  • Rust와의 궁합 문제가 LLM 전체의 한계는 아니며, 언어별 맞춤 전략이 필요함

장인정신(Craft)과 실무 프로그래밍

  • 소프트웨어 개발은 실용적 문제 해결이 목적임
  • 불필요하게 코드 품질에 집착하는 활동은 "야크쉐이빙(yak-shaving)"으로, 현실적 업무에 비효율로 작용함
  • 반복적·귀찮은 작업들은 LLM에 위임하고, 개발자는 가치 창출 구간에 역량 초점을 맞춰야 함

AI 코드의 평범함(“mediocrity”) 수용

  • 대부분 코드가 대단하지 않은 수준이어도 실제로는 문제 없음
  • 중요한 부분은 품질을 높이고, 그렇지 않은 부분은 LLM을 통한 비용 절감을 역으로 이득으로 삼아야 함
  • LLM 코드는 반복적인 부분에서 더 안전하며, 알고리듬 영역에서는 인간보다 폭넓은 접근이 가능함

“AGI(범용인공지능)까지는 멀었다”는 관점에 대한 의견

  • AGI 논란 자체에 무관심하며, 실제 동작 여부만 중요함
  • 현실적 성능과 생산성 증대가 당장의 판단 기준임

일자리 대체 논란

  • 오픈 소스의 도입처럼, LLM도 직업군 변화·소멸을 초래하는 기술임
  • SW 개발자 역시 다른 산업과 마찬가지로 자동화 대상임을 자각해야 함
  • 이러한 변화가 최종적으로 유익할지 해로울지는 불확실하지만, 변화 자체는 불가피함

표절/저작권 이슈

  • AI는 시각 예술계에 커다란 위협이 되고 있음
  • 실제로도 LLM은 산업적 품질을 충족하는 결과물을 대량으로 생성할 수 있음
  • 소프트웨어 개발자들이 표절 문제를 문제 삼기는 어려움
    • 기존에도 개발자는 저작권에 무감각하며, 지적재산권 보호보다는 공유와 재생산을 선호해 옴
    • 코드 일부의 재사용 논쟁은 일종의 특수적 변명에 불과함

최신 LLM 활용과 변화 속도

  • LLM 기반 비동기 에이전트 활용, 병렬적 작업 등으로 생산성이 크게 향상됨
  • 뛰어난 개발자 역시 LLM으로 코드 리뷰와 보완을 진행하며, 정적이지 않은 환경에서 실질적 효용을 경험 중임
  • 중요한 인프라 접근 등 신뢰 문제 영역은 여전히 조심스럽게 다뤄야 함

결론: 기술 변화, 그리고 회의론 극복

  • 기존 AI 회의론자와 달리, 글쓴이는 보수적 관점을 유지하면서도 실제 변화를 체감하고 있음
  • 소프트웨어 개발자들이 낡은 반론에서 벗어나 현실적 변화를 수용해야 할 시점임
  • LLM과 AI 기반 프로그래밍은 스마트폰, 인터넷이 그랬던 것처럼 업계 근본 구조 변화를 이끌 것으로 전망됨
▲
qpolsa95 1일전  [-]

일회용으로 쓸 간단한 스크립트를 짤때는 확실히 유용함. 시간이 매우 절약됨
해결은 해야하지만 시간을 많이 투자할 수 없는 경우에도 유용함. 다만 아직은 대체로 유용하지만 사람을 완전히 대체하지는 못함. 추후 얼마나 발전할지 모르겠지만 지금은 어시로서는 그럭저럭 쓸만한 수준.

답변달기
▲
kimjoin2 2일전  [-]

AI 신봉자든 회의론자든 극단적이면 피하고싶어져요.

답변달기
▲
forgotdonkey456 2일전  [-]

"특이점이 온다" 라고 외쳐대는거 볼때마다 참 피곤하죠.

답변달기
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • 6개월 전에 LLM으로 코드 작성을 시도했다가 실패했다면, 진지하게 LLM을 활용하는 대부분의 개발자들이 하는 방식과 다르다는 이야기. 하지만 나는 지금까지 계속 기술이 혁신적이라고 주장하는 목소리에 회의감을 느껴온 입장. 6개월 전에도 최신 LLM을 사용하지 않으면 구식이고, 적절히 사용하지 못한다고 했지만, 결국 예전 LLM은 별로였다는 걸 모두 인정하는 분위기. 계속 변명만 반복되는 'AI 소년이 나타났다' 현상 같다. 이번에도 작업 생산성이 획기적으로 올라간다고 하지만, 어떤 근거로 지금의 주장이 진짜라고 믿을 수 있는지 의문. 앞으로 6개월 후에는 또 지금껏 썼던 LLM 제품들이 별로였다고 할 거라고 예측.

    • 지수 함수 그래프는 모든 시점에서 비슷한 곡선을 그린다. 한동안 컴퓨터는 매년 엄청 발전했는데, 이것이 새로 산 컴퓨터가 쓰레기라서가 아니라 진짜 빠르게 기술이 발전해왔기 때문. 당신이 느끼는 이 현상, 즉 계속 나아지고 있다는 피로감 자체가 정말 혁신적인 진보의 결과라고 보는 관점 제시

    • 0세부터 30살까지 6개월마다 한 인간에게 도움을 요청하면 언제쯤 감탄할까. 질문 대상이나 작업에 따라 놀라움의 시점이 달라질 수 있지만, 시간이 지날수록 점점 더 많은 사람이 그 능력에 감탄하기 마련. LLM의 발전도 마치 아이가 성장하는 걸 보는 듯한 속도. 나 역시 이전에는 LLM을 안 썼지만 o3, Gemini 2.5 Pro 이후 항상 활용 중. 최신 모델을 직접 써보고 아직 놀라지 않았다면, 3년 이내에는 꼭 감탄하게 될 거라고 자신

    • tptacek가 6개월 전에는 이런 주장을 하지 않았음. LLM은 시간이 지나면서 점점 더 발전하고, 가끔씩은 작동하지 않던 것까지도 돌파구를 맞이하게 됨. 최근 6개월간 '에이전트 기반 코드 작성'이 실제로 동작하기 시작한 지점. "6개월마다 좋아졌다고 하니까 진지하게 안 보겠다"는 마인드는 기술을 제대로 평가하는 능력을 떨어뜨릴 위험

    • 문제의 본질은 '변곡점'에 있다는 의견. 어떤 사람들은 단순히 ChatGPT에 코드 붙여넣고 만족하지 못하지만, 또 어떤 사람들은 코드 컨텍스트를 다 볼 수 있는 에이전트로 훨씬 더 뛰어난 효과 봄. 결국 특정 LLM뿐만 아니라 워크플로우 차이가 중요

  • Thomas의 주장을 좋아하지만, 그 안에도 타인들이 자주 범하는 본질적인 실수가 들어 있다고 생각. 실력 있는 프로그래머는 LLM을 잘 쓰려면 오랜 경험을 쌓아야 하고, Thomas 역시 시간이 쌓이며 전문성을 확보함. 하지만 LLM 지원 없이 성장한 마지막 세대일지도 모름. 이제 막 학교 나온 초보자가 어떻게 '분위기 따라 흉내내기(vibe coding)'에서 벗어나 진짜 실력을 키울 수 있을지 의문. 과거엔 손으로 직접 만들며 성장했지만, 이제는 그냥 전체 설계와 조립을 전적으로 로봇에게 맡기고 실제 도구나 소재가 어떻게 작동하는지 배우지 못할 위기. 지붕의 하중조차 '감'으로 밖에 파악하지 못하게 되는 문제 지적

  • 전문가가 LLM 코드를 읽고, 이해하고, 코드베이스에 통합할 수 있을 때 AI 에이전트의 장점이 확실히 드러난다는 의견. 하지만 모두가 AI로 코딩한다면, 점점 더 복잡한 코드를 읽고, 위험요소를 파악하며, 어디를 어떻게 테스트할지 알고, 코드베이스 전체 구조를 머릿속에 그릴 수 있는 진짜 '에디터'는 어떻게 양성할 수 있냐는 의문. 현재 에디터에게 필요한 이런 능력들은 오랜 기간 코드를 직접 써야 익혀지는 영역. 초보자가 사고를 아웃소싱하면 이런 역량을 키울 기회가 없음. 숙련자는 어디서 나올지 모르겠다는 걱정도 함께. 교수라는 입장에서 숙제나 과제가 이미 LLM으로 아무 생각 없이 통과되는 상황이 되어버려 씁쓸함. 새로운 역량 발전 방법이 필요할 것 같은데 아직 떠오르지 않고, 이런 세상에서 초보자들이 어떻게 전문가로 성장할지 의문

    • 모두가 계산기만 쓰면 수학은 어떻게 배우냐는 반론. 학생들에게 충분히 손으로 연습시키고, 그 본질을 익힌 뒤에야 계산기처럼 LLM을 도입하게 해야 한다는 주장

    • Isaac Asimov의 단편소설 "Profession"이 떠오른다는 경험 공유. 대부분 사람들이 능력과 직업을 컴퓨터로부터 바로 받게 되고, 덕분에 일은 잘하지만 혁신이나 창의성은 전혀 발전시키지 못함. 오히려 이 기술과 맞지 않는 일부만이 진짜 배워가며, 예술계를 발전시킬 수 있는 유일한 집단이 됨

    • 내 경험 기준 LLM은 페어 프로그래머에 가깝고, 초보자에게는 마치 시니어 엔지니어 같은 역할. 코드만이 아니라 원리나 과정을 잘 설명해 주는 튜터 기능도 탁월. 시니어에게는 코드 리뷰, 아이디어 브레인스토밍, 보일러플레이트 처리 등 다양한 이점을 제공. 전문가 입장에서는 10% 어려운 작업만 직접 집중하고, 나머지 단순 업무는 LLM에 위임할 수 있기에 시간 절약. 초보자가 관심이나 호기심 없이 그냥 코드만 받아쓰면 그건 개발자의 문제이고, 적극적으로 배우려는 사람에게 LLM은 최고 수준의 학습 리소스. 그 점에서 초보자는 지금이 가장 유리한 시대

    • 이 스레드 전체가 "문제는 존재하지 않는다 – 있네, 근데 별거 아니다 – 오, 진짜 있긴 하네, 적응하자" 식 고전적 심리 단계를 보여주는 듯. 진짜 핵심 문제 중 하나를 건드렸다는 생각

    • 나 역시 초보자가 LLM에 사고를 완전히 의존하면 실력이 자라기 어렵다는 의견에 공감. 다만, LLM을 통해 늘 새로운 것을 배우는 입장. 내가 막연하게 아는 API에 문제를 내보내고 그 결과를 읽으며 개념을 익히고, 대체로 코드를 뜯어고치고 리팩터링함. 며칠 전에도 시그널의 내부 동작이 궁금해서 LLM이 예제를 내주고, 그걸 같이 분석함. 호기심만 있다면 믿을 수 없는 튜터 역할 가능. 주니어는 무조건 '분위기 따라 코딩'만 할 게 아니라, 적극적으로 배우려는 자세가 중요. 그렇지 않으면 자기 책임이고, 이미 돌이킬 수 없는 현실에서 호기심만 있다면 성장할 길은 충분

  • 실제로 최근 Claude 4 에이전트 같은 걸 써서 큰 C 코드베이스(신기능, 버그픽스), 작은 Rust 프로젝트, 작은 프론트엔드, 기본 API 문서화된 신규 프론트엔드 등 다양한 경우 시도. 모든 케이스에서 완전히 실패 경험. diff도 잘못 받고, 툴에 잘못된 인수 전달, 기본 기능도 실패, 수백줄씩 엉뚱하게 리팩터링, 미완성 refactor가 모두 남아 코드베이스를 엉망으로 만듦. Svelte, solidJS처럼 데이터가 많은 JS 프레임워크에서도 결과는 별로. 진짜 사람들이 극찬하는 에이전트의 실제 강점이 뭔지 모르겠고, 오히려 마케팅 과장 같은 분위기

    • 프롬프트 작성 방식을 묻는 의견. 보통 하나의 기능을 더 세밀한 작은 작업 단위로 쪼개서 LLM에 요청하면 훨씬 잘 작동. 개별 작업(10~200라인 이내)은 실행 잘하지만, 그 이상은 후속 작업, 실망이 계속됨. 지금 수준은 똑똑하지만 경력 없는 인턴 같은 자율성. 고난도의 전체 설계, 계획은 여전히 사람이 해야 하는 상황

    • 에이전트를 홍보하는 사람들도 사실 스파게티 코드만 내놓고, 본인들이 생산성만 높아졌다며 신경 안쓴다는 가설. 실제 성공사례를 구체적으로 툴과 방법까지 공개하는 사례는 별로 없으며, 이 역시 AI가 대신 문서화해줄 수 있을 텐데 그러지도 않음

    • 많은 에이전트 관련 글이 마치 홍보글 같다는 주장. AI 시장에 돈이 너무 많이 몰려있고, 이전 마케팅 사례들도 생각나 더 신뢰 안감. 직접 여러 에이전트 제품을 다 써봤지만 실질적 개선은 적음. HN은 오히려 AI를 두려워하는 비관론자들이 많으니, 논쟁이 많으면 오히려 문제는 사용자 탓이라는 분위기까지 형성됨. 한 유저는 "AI를 진짜 1000달러씩 써봐야 제대로 체험 가능"이라 주장, 광고냄새가 난다고 지적

    • 소규모 코드나 단일 파일, 50줄 이하 단위 등으로 LLM이 변경을 제한적으로 시키게 하면 관리가 더 용이

  • 90년대부터 코딩을 배운 사람으로서, 이제 컴퓨터에게 애매하고 모호한 입력을 줘도 유의미한 결과를 받는다는 사실만으로 경이로움 느낌. 인간 수준의 모호함만으로 명확하고 쓸만한 출력을 받는 세상이 SF처럼 느껴짐

    • 반대로, 아주 명확한 입력을 줘도 그것마저 컴퓨터가 더 쉽게 풀만한 문제로 애매하게 해석할 때가 많음

    • 나는 LLM의 애매함이 바로 문서 대화 용도로 매력적이라 생각. 굳이 검색어를 여러 번 바꿔가며 원하는 정보를 찾지 않아도 되어, 전체적으로 시간 절약이 큼

    • 지금이 실로 놀라운 시대라는 놀라움, 주 1~2회씩 현실감에 감탄하는 경험

    • Star Trek: The Next Generation의 팬이었는데, 엔터프라이즈호의 컴퓨터와 Data의 차이를 상상하며 놀라왔던 기억. 엔터프라이즈 컴퓨터는 오늘날의 AI와 유사하게 지식 정리, 요약, 작업 실행 등이 가능했고, Data는 개인기를 가진 로봇이라는 설정. Data가 유머, 예술 등 인간 감성 영역에서 한계가 있다는 점은 오늘날 AI 아트와 흡사. 극 초반 미묘한 설정과 전개도 떠오르는 추억

    • 나는 기계에게 명확한 지시를 내려 정확히 원하는 걸 얻는다는 점 때문에 이 업계에 들어왔음. Dijkstra가 예전부터 이미 인간 언어의 애매함, 그리고 이를 극복하기 위해 생긴 '형식 언어'의 중요성을 강조. 결국 2025년에는 컴퓨터와 논쟁하며 폼을 교정해야 하는 '프롬프트 엔지니어링/분위기 코딩' 시대가 열렸다는 자조적 조망도 함께. EWD667: The Humble Programmer 읽어볼 가치 추천

  • 생성형 AI의 무한한 능력을 주장하는 사람들은 실제 증거를 보여줄 수 있는지 궁금. GAI나 에이전트가 정말 강력하다면, AI만으로 회사를 차리고 짧은 기간에 엄청난 완성도 높은 코드를 생산하는 결과로 입증할 수 있을 것. 하지만 실제론 그런 징후 없음. 지금까지 가장 쓸모있는 용도는 그래도 인간이 의미 있다고 착각할 만한 텍스트, 아트 생성. 스타트업들이 실무에 활용해본 경험으론, 아주 가끔 API 탐색이나 편리한 정보 찾기 정도에만 쓸모 있음. 전체적으로 보면 시간 낭비가 더 컸던 편. 이제는 정말 '좋다'는 주장 대신, AI가 순수하게 만들어낸 결과를 직접 보여줘야 할 시점

    • 서로 관점이 엇갈린다고 봄. 항상 실현 가능한 변경(노력 대비 효과가 있는 일)과 백로그에서 방치되는 일 사이 임계치가 있었는데, AI 도구는 그 임계 비용을 낮춰 더 많은 작업이 시도 가능함. 그래서 "생산성 5배" 주장하는 쪽은 실제로 처리 코드량이 늘어난 점을 부각, 반면 회의론자는 비즈니스 본질 가치는 크게 바뀌지 않았다고 보는 점. AI 생산성의 역설도 참고 추천

    • 구체적으로 어떤 증거를 보고 싶은지 질문. 무한한 능력을 원하는 건지, 현실적 유용함을 증명하라는 건지 명확히 해달라는 의견. 실질적으로 누구도 완전한 만능은 아니라고 인정하고, 제대로 한계와 강점을 이해하는 사람이 활용할 때 유용하다는 점 강조. 최근 cloudflare/workers-oauth-provider 같은 커밋 히스토리도 예시로 제시하며, '조금이라도 쓸모 있음'에는 동의할 수 있지 않겠냐는 질문

    • 다들 이미 실제로 LLM이 만든 코드를 자체적으로 쓰는 중. LLM 활용 PR이 실제 프로덕션에 수개월째 들어가는 경험 공유. 만약 당신이 아직 효용성을 못 찾았다면, 제대로 활용하는 방법을 배우지 않은 것일 수도 있다는 조언도 함께

    • LLM을 별로 효과 없다고 광고하는 이들을 보면, 뭔가 마케팅이 작동하는 현장을 보는 느낌. 예전엔 믿었던 회사들도 최근엔 AI 홍보에 치우쳐 아쉽다는 생각. 진짜 혜택이 있다면 직접 써보라는 분위기

    • "골드러시에 곡괭이 파는 상인" 비유. 직접 도구 효능을 증명하기보다, 사람들에게 금광이 있다고만 설득하는 마케팅 구조 꼬집음

  • Github 코드 라이선스 문제를 무시하는 태도에 대한 비판. 어떤 개발자는 "저작권 따지지 말라"고 하는데, 프로그래머 모두가 저작권 침해를 일삼는 범죄자라는 전제는 잘못된 일반화. 나를 포함한 많은 개발자는 대규모 불법복제와 무관하고, 오히려 copyleft나 오픈소스 정신을 지키려 노력함. SciHub를 공공선으로 보면서도, 개별 개발자가 의도한 copyleft 역시 존중해야 한다는 입장. 저작권은 단순 찬성/반대 식으로 나뉘는 게 아님. 이런 다양성과 맥락을 무시한 채 싸잡아 비난하거나, 라이선스 무시를 정당화하는 논리야말로 게으른 지적 태도

    • 프로그래머가 법, 특히 미국식 커먼로(civil law)에 대해 잘 이해 못하는 경우가 많음. 법의 전통은 오랜 기간 인간이 합리적으로 해석할 것을 전제로 기술되어 있고, AI도구가 책임을 분산하거나 회피하도록 설계되었더라도 결국 법은 책임질 사람을 찾아내 징벌할 것. AI 붐이 지나간 후의 현실은 1) 기업과 국가가 책임 분산 시도, 2) 부작용 사건 발생(자동차 사고, 차별적 알고리즘, 데이터 유출 등), 3) 법원은 책임을 인간에게 돌리고 벌금 혹은 처벌, 4) 다른 기업들이 위험감을 느끼고 AI를 제한하는 방식. 이런 흐름 속에서 AI 도구는 인간 책임의 범주 내에서 살아남게 될 운명

    • 25년 넘게 자유 소프트웨어 개발자로 활동해왔고, 다양한 라이선스를 즐김. 감독, 시각예술가 배우자도 있지만, 나는 AI 관련 콘텐츠엔 손도 대지 않으며 쓰레기로 봄. 접하고 싶지 않은 입장 명확히 표명

  • Konwinski Prize 처럼 오픈소스 LLM이 novel Github issue 90% 이상 해결하면 100만불 지급하는 챌린지가 흥미로움. Konwinski Prize 대회 참고. 아직 최고의 모델도 0.9가 아닌 0.09 점수에 불과, 실전용으로는 한참 멀었다고 봄. 오픈소스가 상용보다 약간 성능이 낮더라도, 여전히 LLM이 독립적으로 코드 작성하는 건 아직 불가능에 가까움. 쓰레기 양산도 많지만, 평가·관리 필요성 때문에라도 쓸모는 있음

    • LLM은 사실상 탭 자동완성에 인지 부담만 늘어난 버전

  • 반복적인 보일러플레이트 코딩 업무를 AI가 대신해도, 이제는 그 지루한 AI 코드 리뷰가 반복되어 더 재미없어지고 시간도 비슷하게 소요, 이해도도 떨어지는 상황

    • AI 개발을 옹호하는 이들은 결국 코딩보다는 코드 리뷰를 더 좋아하는 듯. 개인 취향일 수 있지만, 그 자체로 괴로운 일로 느껴짐

    • 정확히 말하면, 대량 코드 리뷰는 보통 직접 작성하는 것보다 시간이 덜 걸림. 특히 코드가 테스트를 통과할 때 그렇고, 테스트 코드 역시 LLM으로 생성 가능하므로 부담 경감

    • Claude, Gemini 등은 내가 직접 코딩하는 것보다 훨씬 빠르고, 두 번 이상 살펴봐도 직접 쓰는 시간보다 적게 듦

    • 예전에는 '야크 털 밀기'식 반복 작업에 코드를 썼다면, 이제는 성의 없는 '야크' 면도질을 리뷰하는 현실

    • 전체적으로 더 큰 에너지/탄소 배출이 불가피

  • 기계 번역 및 음성 인식 분야 대화. 청각장애에 가까운 입장에서 하루종일 이 기술을 활용 중. 80년대 드라마를 자막 없이 즐길 수 없었는데, Whisper 같은 LLM을 사용해 영상에서 자막을 얻고, 과거엔 상상만 하던 일이 현실이 된 기적을 실감

    • 최신 음성인식과 번역 SOTA는 여전히 단일 임무용 특화모델이 우세하지만, 격차는 빠르게 줄어들고 있고, LLM이 훨씬 더 다양한 작업 가능. (예시: 음성인식 리더보드 참고), LLM은 넓은 가능성을 열어줌

    • 여러 해 동안 다양한 음성인식 시도(Dragon 등)는 다 놀랍지만 실사용엔 불편했음. Whisper와 LLM 조합이 실제 효용을 가져온 첫 시점. 여전히 완벽하진 않지만 직접 손보는 일이 10분의 1로 줄어, 개인 노트용으로는 이제 검증도 안 할 만큼 편함

    • 아직은 정말 고위험(예: 해외국가 근로계약, 경찰 진술 등) 업무에 LLM 번역만 의존하지 않을 듯. 과거에도 음성-텍스트는 있긴 했지만, 기술 발전은 체감되나 일상적이며 저위험 사용에 그칠 뿐, SF 소설처럼 우주간 협상 등에 쓸 수준까진 한참 남았다고 판단

    • 나 역시 최근 기술 발전이 정말 어린 시절 SF 장르에서 봤던 약속을 실현 중이라 느낌. 며칠 전 낯선 도시에서 음식점 메뉴판 사진을 찍어 중국어 손글씨를 추출, 영어로 바로 번역 후 원하는 메뉴 발음까지 배워 주문. 2년 전까지는 불가능하던 일이라 확신

    • 번역이야말로 LLM의 완벽한 활용 분야라 생각. LLM은 사회적 개념, 문화 맥락, 대중문화, 희귀 레퍼런스 등까지 두루 반영하며 여러 언어·문화권에 맞춰 다양한 버전 번역까지 가능. 전통 번역보다 이미 한참 앞서고 있다고 확신

답변달기