새롭고 좋은 소프트웨어는 어디에 있을까요?

AI 요약

AI 코딩 도구가 정말 효과적이라면 새롭고 좋은 소프트웨어가 더 많이 나와야 한다는 질문에 글쓴이는 잠정적인 답을 여럿 내놓습니다. 일부는 실제로 소프트웨어가 나아졌지만 변화가 버그 감소나 성능, 기존 제품의 기능 개선으로 나타나 새 제품처럼 보이지 않는다고 봅니다. 새 소프트웨어를 자주 찾아 쓰는 사람은 적고, 개발 프로세스에서 AI 도구를 도입하지 않은 승인 절차 같은 부분도 속도를 제한할 수 있습니다.

눈에 잘 띄지 않는 변화

AI가 오래 쓰이는 제품 대신 일회성 도구나 개인별 사용 방식을 늘릴 수도 있습니다. 세금 신고를 Claude에 맡기면 TurboTax보다 나은 새 제품을 쓰는 경험은 생기지 않지만, 소프트웨어 이용 방식은 달라집니다. 분야 전문가가 자기 도구를 만들거나 임원이 사내 대시보드를 만드는 식으로, 도구가 늘어도 외부 이용자에게 공개되지 않을 수 있습니다. 기존 제품을 개선하기보다 새 소프트웨어를 더 많이 만드는 쪽으로 개발이 늘어날 가능성도 있습니다.

생산성 향상이 제품 개선으로 이어진다는 보장도 없습니다. 팀이 빨라진 만큼 휴식 시간을 늘릴 수 있고, AI가 어떤 프로젝트를 만들지 않는 편이 낫다고 판단하도록 돕거나 소프트웨어 사용 시간을 줄이는 경우도 있습니다. 글쓴이는 이런 설명을 검증된 결론이 아니라 가설로 제시하며, 일부에는 낮은 비중을 둬야 한다고 덧붙입니다.

Lobsters 반응

• @elliotmorris — 이 가설들이 시간이 지나며 사실이 될 수도 있습니다. 하지만 질문 자체가 잘못됐다고 생각합니다. "좋은 새 소프트웨어는 어디에 있나?"라는 말에는 소프트웨어 경제의 목적이 소비자에게 효용을 제공하는 데 있다는 전제가 깔려 있습니다. AI는 기존 기업의 인건비를 줄이는 방식으로 정당화될 수도 있습니다. 그 기업들이 만드는 제품의 효용은 부차적일 수 있고, 시장 지위가 버텨 준다면 제품이 나빠져도 괜찮을 수 있습니다. AI 코딩이 효과적이어도 소프트웨어 전반과 사회적 결과는 나빠질 수 있습니다. 사실이라면 시장에 맡기는 것 말고 다른 방식으로 풀어야 할 이해 충돌입니다.
• @tinthedev — 이 생산성 향상에는 실제 정신적 부담이라는 반대편이 있습니다. 대충 만들지 않으려면 코드를 생각해야 합니다. 고용주를 위해 직접 코드를 다루는 일에서는 2~3배 정도의 속도 향상이 인지 능력의 한계일 수도 있습니다. 커피를 마시며 쉬는 시간은 필요하고 때로는 필수입니다. 나머지 내용은 대체로 맞는 말입니다. 저는 더 작고 개인적인 소프트웨어가 늘고 특별히 뛰어나지 않은 SaaS가 사라질 거라고 추측해 왔습니다. 저도 LLM의 도움으로 개인용 서비스를 몇 개 만들었습니다. 널리 공개하거나 마케팅과 영업에 돈을 쓸 생각은 없지만 재미있고 매일 쓸모가 있습니다. 제가 매일 쓰는 서비스는 바라던 만큼 나아지지 않았습니다.
• @greysonp — LLM 이전에도 회사 직원 수가 늘었는데 왜 새 기능이 없느냐는 질문이 있었습니다. 당시에는 코드가 새 기능보다 인프라 유지와 운영 등에 더 많이 들어간다고 답했습니다. 회사가 처리량을 크게 늘렸어도 같은 설명이 적용될 수 있습니다. LLM으로 생긴 멋진 소프트웨어도 있습니다. 게임을 재구현하거나 분해해 모드 지원이 있는 독립 실행 파일로 만드는 작업이 그 사례이며, 거의 전적으로 LLM의 도움으로 진행됩니다. 저는 새 기능을 빠르게 만드는 것보다 같은 시간에 더 견고하고 신뢰할 수 있는 기능을 만드는 데 LLM을 쓰는 편이 낫다고 봅니다.
• @yshui — AI는 미리 정한 목표를 달성하는 코드를 대량으로 만드는 데 능합니다. 게임 이식이나 디컴파일 프로젝트가 그 예입니다. 하지만 코드가 끔찍하고 사람이 읽거나 유지하기 어렵습니다. 코드 검토가 따라잡지 못해 기존 소프트웨어 개발 과정에 통합하기도 어렵습니다. AI가 사람이 원하는 바를 이해하지 못하는 문제가 근본에 있습니다. 수백 개 기업의 실제 코딩 관행을 살핀 연구에서도 인간 코드 검토가 AI 코딩 도구의 병목으로 나타났고, 기업의 소프트웨어 생산량 증가나 고용 감소를 뒷받침하는 증거는 거의 없었다고 합니다.
• @Dielan — AI로 만든 소프트웨어 중 상당수는 요청한 사람만 쓰는 맞춤형 도구일 것 같습니다. 데이터 대시보드나 업무에 딱 맞는 작은 위젯 같은 것들입니다. 다른 사람과 공유하지 않으니 낭비처럼 보일 수 있지만, 모두를 위한 도구를 만들 때 드는 수고와 부담보다 혼자 쓸 도구를 만드는 편이 훨씬 적게 듭니다.
• @loldot — "추측에 불과하다"는 말은 그럴듯하게 돌려 말한 표현입니다. 데이터가 없다면 이 글은 아무 의미가 없습니다.
  • @splitbrain — 글의 주장과 맞는 경험담을 보태겠습니다. 사람들이 자기 불편을 해결하려고 소프트웨어를 더 많이 만듭니다. 제가 만든 도구 중 하나는 Claude가 프로토콜을 역공학해 Rust로 구현한 Linux용 Sony 헤드셋 배터리 및 마이크 상태 표시기입니다. Kubernetes 파드 파일을 복사하거나 편집하는 TUI 도구와 코딩 에이전트에 결과를 전달하는 파일 검토 도구도 만들었습니다. 이용자와 노출 규모는 5명 미만이지만 실제 문제를 해결합니다. 제게 좋은 소프트웨어란 그런 것입니다.
• @schneems — 저는 요즘 버그가 더 많다고 느낍니다. 소프트웨어가 불안정하게 동작하거나 미묘하게 잘못되는 경우가 늘었습니다. LLM이 수정 과정에서 테스트 부족 등을 이유로 회귀를 만들었을 수 있다고 추측합니다. 고장났다고 알리면 "Claude가 고쳐 줄 수 있다"는 답을 듣곤 합니다. 임시방편을 거듭하는 문화가 자리 잡으면 근본 원인을 찾아 고치기가 점점 더 어려워집니다. LLM은 버그를 찾는 데 능하지만 사소한 문제와 중요한 문제의 우선순위를 항상 잘 가리지는 못합니다.

원문: Nate Meyvis / 번역·요약: Trawling