나에게 LLM 기반 개발은 마치 크립토나 VR처럼 과장된 유행 hype 라는 생각 듦. 최근 vibe coding으로 작성된 코드베이스의 버그를 고치는 경험을 하며, 이 방식은 체계 없는 비즈니스 문제들이 구조화 없이 코드로 옮겨지는 일종의 혼란 덩어리임을 느낌. 개선이 필요한 부분은 좁은 패치로 때우다보니 결과적으로 복잡하고 비조직적 코드 생성. 맥락 창 context window의 한계에 부딪히면 LLM이 자체 패치도 기억 못함. 영어(또는 인간 언어)는 내가 원하는 코드를 정확히 설명하기엔 애매하고, 시니어 개발자가 코드에 녹여둔 수많은 경험과 시행착오의 총집합을 프롬프트로 다 풀어내는 건 극도로 무거운 작업. "왜 이렇게 짰는지"와는 반대로 "이런 상황에선 이렇게 하지 말고, 저렇게 해라"라는 엄청 구체적이고 끝도 없는 리스트가 필요한 차이점 존재
내가 지난 30년 동안 봐온 대부분(딱 하나 제외한)의 코드베이스 설명이랑 딱 맞아떨어지는 관찰
반론 제기—AI가 구조를 추출해야 할 30여 곳에서 코드 패턴을 찾아내게 도와준 일도 있었음. vibe coding의 문제는 태도라고 봄. 직접 코딩을 피하려는 사람이 장기적 구조나 품질보단 지금의 편함에만 집중하는 경향, 일종의 게으름 증폭기라는 생각
실상 많은 프로덕션 코드가 패치 떼기 하며 작동되는 코드 스니펫 조각들의 집합임. 현실적으로 CPU가 너무 빨라서 이런 코드도 그냥 돌아가는 슬픈 상황
인간 언어가 명확하지 않다는 지적에 동감. 결국 자연어로 명확하게 소프트웨어를 다루겠다는 시도가 몇 번이나 반복된 적 있으며, 결국 법률과 마찬가지로 회색지대 해석이 끊이지 않음. 미래엔 개발자들이 컴파일 전에 프로그램 의미를 논쟁해야 한다면 그 미래는 암울
AI도 크립토나 VR만큼 과장된 hype로 보이는 게 맞음. 하지만 소프트웨어 엔지니어처럼 고도로 테크니컬한 직업에도 결국 자동화가 영향을 줄 것. 최근 10년간 테크 업계 사람들이 다른 노동자 문제와는 무관하다고 착각했지만, 리먼트/감원 문화로 인해 이제 임금 억제가 본격화됨. AI가 전체를 즉시 대체하지 않아도, 5명이 하던 일을 4명이 AI와 함께 하게 되면서 1명 감원, 잔류 인원도 임금 인상 요구 엄두 못 내는 구조 반복. 테크 직군도 결국 노동자임을 깨달아야 한다는 주장
Harper Reed가 “코드에 대해 깊이 이해할 필요가 없다”는 의견에 대해, 이런 발언이 오히려 “컴파일만 되면 배포하자”라는 급조 논리로 느껴짐. 자동화라인에서 끊임없이 품질을 측정하면서도, 실제 기계는 각도 착각이나 엉뚱한 용접 등 환각을 일으키지는 않는데, LLM 기반 소프트웨어는 이런 사소한 오차가 반복
LLM 기반 툴이 정말 개발자 생산성을 극적으로 올렸는지, 아니면 조직이 더 적은—그리고 이전보다 덜 특권화된—개발자만으로도 되는 걸 알아낸 것뿐인지 의문. 대형 테크 기업 내 ‘혁신적 생산성 제고’ 사례도 별로 못 보겠고, 지금까지는 투자를 상쇄할 정도의 약간의 생산성 향상만 있는 실정
상당 부분은 인식의 문제. 예전엔 개발이 어려운 일이었지만 AI 툴 등장으로 코딩의 진입장벽이 낮아진 걸로 인식. 소프트웨어 개발이 점점 공장 일처럼 느껴지고, 지적 보람이 줄어든 현상
코드베이스 장기 유지보수성에 의구심. vibe coding이 점진적으로 복잡성과 미묘한 버그, 추상화 문제를 쌓아 결국 유지보수, 신규 기능 개발 난이도를 올림. 단기적 생산성 상승에 갇혀 장기적 품질 하락 가능성
조직들은 예전부터 관료적 절차로 ‘기술 탈피’, 즉 숙련도 낮은 인력을 표준화로 대체해왔음. 장기적으로 독이 될 수 있는 전략이지만, 일관성만 있으면 ‘평범하게 쓸만한 솔루션’에 안주
이런 논리가 설득력을 가지려면, Amazon 경영진이 단기 이익을 장기 품질보다 더 중시한다고 가정해야 하지만 이에 대한 확신 없음
곧 은퇴하는 입장에서 최근 변화에 허탈함. 90년대 운명을 시작할 당시에는 긴 시간 실험과 창의성에 몰입하는 여유가 있었음. 요즘은 단위작업과 상태보고, 끊임없는 정당화가 필수. 앞으로도 흥미로운 개발자들은 있겠지만, 그런 기회가 줄고 있음. 사실 자동화로 삶이 힘들어진 다른 직업들과 똑같은 길을 걷는 거라 공정한 결과
일상적 상태보고 스탠드업(stand-up) 등은 시간이 걸리는 데다, 내 업무를 이해 못 하는 이들로부터 하루 더 자유로워지기 위한 형식적 대응일 뿐, 일의 가치를 떨어뜨림
나도 90년대 입사자고 JIRA 기반으로 세밀하게 통제되는 현상에 공감. 다만 예전만이 무조건 황금기라고 생각하지는 않음. 과거의 좋은 경험만 기억하려는 향수 버프도 있는 듯. 하지만 요즘도 충분히 도전적이고 좋은 일, 배울 거리 존재
엔지니어 일자리 자동화보다, 사실상 관리직을 AI 중심 감시로 대체하는 방향성
소프트웨어 개발을 획기적으로 빠르게 하려면, 누군가의 오픈소스 코드를 그대로 복사해 사용하고 저작권/라이선스 흔적을 제거해 적용하는 방식도 있음. 직접 들키는 게 걱정이라면 외주 업체를 써서 세탁하거나, 요즘은 AI로 저렴하고 빠르게 세탁 가능. Google은 예전엔 이런 행동을 자제했고, 담대함이 부족했다. 하지만 소규모 신생업체들은 저작권 위반 리스크를 무시한 AI 활용으로 빠른 성공을 노림
내가 속한 산업에서는 오히려 코드의 부재보다 “무엇을 어떻게 짜야 하는지” 정의가 더 큰 문제. Stackoverflow나 Github로 해결 안되는 고유 문제도 많음
Google도 사실 예전부터 사이트 콘텐츠를 긁어다 검색결과에 직접 노출, 트래픽 없이 남의 콘텐츠 활용. 이번에도 단순히 늦었을 뿐
아이러니하게도, 어떤 이들은 대기업이 오픈소스 코드를 표절이라도 해주길 바란다는 의견. 그들이 직접 만든 냉정하고 비효율적인 방식을 이용자 입장에서 강요받는 게 더 낫지 않기 때문
오픈소스에 코드를 올리는 것의 한계에 공감. 대기업은 무료 노동력을 얻기 위한 수단으로 오픈소스를 장려하는 경향. 단기적으로 기여가 줄더라도 장기적으로 업계가 건강해질 거란 생각
ChatGPT 등장과 Sam Altman의 리더십에 대한 무책임함 지적
코드 작성보다 읽기가 더 어렵고 재미없다는 Simon Willison의 발언과, AI가 문서 작성 및 테스팅 등 부수적 작업을 많이 도와주고 있다는 아마존 개발자 사례 인상적. 이제 코딩보다는 기존 코드 리뷰, 버그 수정 중심으로 역할 변화
초기에 코드 짜는 게 즐거웠던 지난 시절 생각. 이제는 버그 수정이 더 재밌고, LLM이 단순한 반복 코딩을 대신해줘서 도전 과제에 집중할 수 있음. LLM 덕분에 개발의 일부 재미가 살아남
이 글에서 느껴지는 분위기는 꽤 부정적
생산성 신기술이 나오면 기업은 빨리 효과를 가져가 표준화함. 계속 따라잡으려면 끊임없이 공부해야 하고, 언젠가는 자기만의 성장 이득을 직접 챙기는 환경(자영업 등)으로 전환도 고려해야 함. 하지만 혼자 일한다는 건 AI에 숙련된 이들과 경쟁해야 한다는 뜻이라, 쉬운 해결은 아님
세 가지 미래 시나리오 예상. 1) 코드베이스가 점점 혼란과 불안정 속으로 무너지고, 결국 경험 많은 개발자를 비싼 값에 재투입해야 할 수도 있음. 2) AI가 그럭저럭 쓸 만큼의 코드를 만들고, 품질이나 신뢰성은 낮지만 큰 사고는 없는 상태 낙관. 3) AI가 급격히 똑똑해져 코드베이스 개념 자체가 사라지고, 필요할 때마다 동적으로 생성 및 진화되는 소프트웨어 시대. 현재 LLM은 여기에 한참 미치지 못함. 기업 임원들은 3번을 믿지만 아직은 1~2번이 현실. 관리가 잘 된다면 2번의 균형적 관점으로도 이행 가능
생산성 향상이 더 공정하게 분배되는 모델도 있음. 예전 유럽처럼 근무시간 단축 등. 요즘은 심지어 노동자들조차 바빠보이는 정체불명의 잡일에 매달리는 듯한 모습
네가 사실상 마르크스주의자 관점을 말하고 있는데, 이상하게 결론이 자기 소외로 귀결되는 점이 재미있음. 조금만 힘을 합치면 개선 가능인데 그러지를 않음
계속 끊임없이 자기계발하며 살아야 된다고 받아들이지 말고, 사회 구성원과 힘을 합쳐 고용주에 함께 요구하는 방법도 있음. 주 5일제, 8시간 근무, 아동 노동 금지도 집단 행동으로 얻은 결과임. 내 일만 열심히 하고 남 잘되는 거에만 집중할 필요 없음
우리 업계가 유치하게 변하는 모습에 항상 놀람. 대기업, 대규모 코드베이스 경험자라면 신규 코드 생성이 개발의 작은 부분이라는 걸 아는 현실
실제로 신규 코드 이외의 일, 즉 다른 부수적인 부분들도 대기업에서 비효율적임. AI가 이런 점도 바꿔서 끊임없는 회의나 추상적인 논의 감소 전망
지금 열광하는 사람들 중 상당수는 사실 최신 패러다임에 얽매여 코드 작성 자체가 어려워진 사람들임. Copilot 등 LLM 도구로 빠르게 POC를 만들어 프로덕션까지 보내면서 품질, 확장성 등은 깊이 생각 못하는 경우 많음. 그리고 이런 이들이 AI 도입의 생산성 상승 사례를 무조건적으로 광고하며, 대기업 이익과 맞물린 주장만 반복. 정작 실무에선 아쉬운 점도 많다는 걸 실제로 써보는 사람들은 다 앎
나도 전체 시간의 20% 정도만 코딩, 나머지는 요구사항 수집, 설계, 테스트, 일정 관리. 그 20% 코드 작업이 절반으로 줄면, 남는 시간에 테스트나 문서화 작업 더 할 수 있을 것 같음
LLM 도움으로 개발 효율이 대폭 증가할 거란 착각이 있음. 사실 기본 실력이 있을 때만 품질 손실 없이 생산성 상승 가능. 즉, 숙련자에게 생산성 증폭 효과지만, 규모만 키운 초보 군단에 LLM을 쥐어주면 품질 좋은 소프트웨어는 어려움
이런 주장 반복하는데, "품질"의 커트라인이 어디냐가 중요. 실제로 젊은 개발 스터디 팀에 SRE 친구가 주간 리뷰하면서 LLM 적극 활용 중인데, 코드 품질이나 확장성도 충분. 속도가 느릴 뿐 완성도는 나쁘지 않음
"좋은" 소프트웨어가 필요한 곳은 일부일 뿐이고, 실제로 Deloitte, Accenture 같은 곳의 수익 구조를 보면 대부분의 기업은 품질에 신경조차 쓰지 않음. 대다수는 "그럴듯한" 소프트웨어면 충분
Hacker News 의견