코딩이 해결됐다면 왜 소프트웨어는 계속 나빠지는가?

 (ptrchm.com)
10P by GN⁺ | ★ favorite | 댓글 1개
  • AI 도구가 개발 생산성과 팀 역량을 높였지만, 소프트웨어 품질과 안정성은 그만큼 개선되지 않아 사용자는 업데이트 후 더 나쁜 경험부터 예상하게 됨
  • 은행 앱의 반복 FaceID 인증, Slack의 포커스 탈취, LG 보증 신청 실패, 자동차 인포테인먼트 오류 등 일상적인 버그가 금융·업무·고객 지원·운전 전반을 방해함
  • 단순했던 과거와 달리 새로운 추상화, 프런트엔드 프레임워크, 인프라 복잡성이 누적됐고, 높아진 사용자 경험 기준과 맞물려 시스템은 점점 취약해짐
  • 최신 모델과 충분한 토큰 예산이 있어도 안정성 개선은 KPI나 발표 자료에서 돋보이기 어려워, 기업은 버그 수정 대신 새 기능과 재설계를 우선함
  • 기업이 AI 부채를 쌓는 사이 개인 개발자는 과거에 만들기 어려웠던 소프트웨어에 도전할 수 있으며, macOS와 Windows에 대한 반발이 일상 소프트웨어 개선으로 확산될 여지가 있음

AI 시대에도 나빠지는 사용자 경험

  • AI 열풍 속에서 사람들은 모든 것이 자동화되기 전에 시장 가치를 확보하려고 과도하게 토큰을 소비함
    • 모델 성능 향상과 잇따른 프로그래머 해고, 연말까지 AI가 코드의 100%를 작성하리라는 전망이 불안을 키움
  • 에이전트 시대는 더 높은 생산성과 품질을 약속함
    • 새로운 도구는 소프트웨어를 만들고 사용하는 방식을 이미 바꿈
    • 경영진이 팀에 요구하는 산출량이 늘었으며, 소프트웨어 팀의 평균 역량도 이전과 다른 수준으로 올라갔을 가능성이 있음
  • 그러나 실제 제품은 기본적인 안정성조차 확보하지 못한 경우가 많음
    • 은행 앱은 3D Secure 확인 화면이 나타날 때까지 평균 세 번의 FaceID 로그인을 요구함
    • macOS용 Slack은 뒤늦게 열린 뒤 Ghostty의 포커스를 빼앗아, 터미널에 입력하던 git pull 명령을 단체 채팅으로 전송함
    • LG 냉장고 보증 신청은 수많은 필드가 포함된 다단계 양식의 마지막 제출 단계에서 실패했으며, JavaScript 콘솔을 확인해야 오류를 알 수 있었음
    • 자동차 인포테인먼트는 업데이트 후 운전할 때마다 재부팅됐고, 방향지시등 소리가 사라지거나 Google Maps 대신 라디오가 열렸으며 화면 입력도 1~2초씩 지연됨
    • 자동차 오류는 단순한 UX 불편을 넘어 운전 집중력까지 떨어뜨림
  • 자동차 OS 재설계 팀의 PM은 LinkedIn에서 결과물을 자축했지만, 실제 사용자는 계속 제품과 씨름해야 했음
  • 해당 팀들은 최신 모델과 넉넉한 토큰 예산을 이용할 가능성이 있고, LLM 역시 기회가 주어지면 버그 수정에서 뛰어난 성능을 낼 수 있음

복잡성과 KPI가 품질을 밀어내는 구조

  • 소프트웨어에는 언제나 버그가 있었으며, macOS Snow Leopard 시절이 완전히 안정적이었다는 향수에는 선택적 기억이 섞여 있음
    • 과거 소프트웨어가 더 나았다면 주된 이유는 지금보다 훨씬 단순했기 때문임
    • 이후 새로운 추상화와 프런트엔드 프레임워크, 더 많은 인프라 복잡성이 추가됨
    • 사용자 경험의 기준은 계속 높아졌지만 전체 시스템은 오히려 더욱 취약해짐
  • macOS와 이에 의존하는 앱의 업데이트는 기대보다 걱정의 대상이 됐고, 사용자는 새 버전이 이전보다 나쁠 가능성부터 예상함
  • 문제는 AI 자체보다 AI를 어디에 우선 활용하는가에 있음
    • GPU 인프라는 개발자에게 강력한 능력을 제공했지만 더 좋은 소프트웨어를 만드는 데 충분히 쓰이지 않음
    • 소프트웨어 업체는 오랫동안 KPI를 중심으로 움직였고, 안정성 향상은 수치에 직접 반영되지 않을 수 있음
    • 한 분기 동안 새 기능과 재설계를 멈추고 버그 수정에만 집중하는 계획은 발표 자료에서 돋보이기 어려움
  • 이런 우선순위가 바뀌지 않으면 소프트웨어 품질 저하도 계속될 수밖에 없음

개인 개발자에게 열린 기회

  • 기업들이 집단적으로 AI 부채에 빠지는 동안 개인 개발자는 과거라면 역량 밖이었던 소프트웨어를 만들 기회를 얻음
  • 자동차 Android Auto나 LG 웹사이트에 대한 기대는 낮지만, 현재 상태에 쌓인 불만은 일상 소프트웨어를 개선하는 동력이 될 수 있음
    • macOS와 Windows의 현 상황에 맞서는 반발 움직임이 이미 나타나고 있음
    • 이러한 흐름이 소프트웨어 스택 전반으로 확산될 가능성에 기대를 걸고 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 예전에는 무료로 어떤 새 기능이 생길지 기대하며 업데이트했고 Fedora Workstation 45의 변화도 찾아봤지만, 이제 휴대폰·TV·자동차·비 Linux 운영체제의 업데이트는 두려움부터 듦
    원치 않는 기능과 외부 연결이 또 추가될까 걱정되며, macOS는 작은 투명 경계를 찾아 창 크기를 조절하게 만드는 등 이미 오래전부터 기대감을 잃게 했음
    Windows 11은 보안 업데이트 뒤 원치 않는 연결 기능이나 AI 기능을 다시 권하는 식의 다크 패턴을 쓰는 것으로 보였음

    • 이제 ‘업데이트 대기 중’ 아이콘을 보면 새로 무엇을 망가뜨릴지부터 걱정함
      비디오 게임을 제외하면 거의 모든 소프트웨어 업데이트가 싫고, Dead By Daylight조차 개발사 Behaviour의 무능이 게임 내부에만 갇혀 있다는 정도가 위안임
    • 업데이트가 두렵지 않은 소프트웨어는 자유·오픈소스 소프트웨어(FOSS) 임
      독점 소프트웨어는 더 이상 사용자를 위해 만들어지지 않지만 일부 FOSS는 여전히 사용자를 우선함
    • Windows의 누적 보안 업데이트 자체에는 새 운영체제 기능이 포함되지 않고, Pro 에디션에서는 적어도 예전에는 품질·기능 업데이트를 건너뛸 수 있었음
      대신 자동 갱신되는 Store/AppX 패키지로 ‘연결된 환경’을 배포하고, 패치 후 재부팅 시 OOBE를 실행해 기능을 다시 권하거나 활성화함
      보안 업데이트에 기술적으로 묶은 것은 아니지만 사용자를 무시하는 다크 패턴인 건 마찬가지임

  • 이런 도구와 Silicon Valley의 ‘빠르게 움직이고 망가뜨리기’ 문화가 결합해 팀 생산량에 대한 경영진의 기대치를 끌어올렸고, 그 기대를 감당하는 일이 가장 괴로움

  • 소프트웨어는 빠르게 만들 수 있지만, 정확하다는 확신을 얻으려면 시간이 더 필요함
    AI 코드 생성으로 숙련된 엔지니어가 과거 일주일 걸리던 일을 한 시간 만에 만들 수도 있지만, 정확성 검증 시간까지 줄여주지는 않음
    많은 개발자가 생성 속도의 이점만 취하고 안정성·성능·무결점을 확인하는 비용은 외면하며, 다만 대중용 소프트웨어 품질 저하는 AI 이전부터 이어져 왔음

    • 같은 품질을 전제로 하면 1주일을 1시간으로 단축한다는 건 극단적인 최선의 경우에 가까우며, 보통은 두세 시간 걸릴 일을 한 시간에 하는 정도로 보임
      작업에 따라 효과가 크게 달라지고 장기 프로젝트에서는 선형으로 확장되지 않으며, 때로는 AI가 오히려 더 큰 지연을 만듦
      품질을 무시하면 엄청난 속도를 낼 수 있지만, AI 없이도 품질을 신경 쓰지 않으면 훨씬 빨라짐
    • 확신을 주는 것은 개발 기간보다 실전에서 작동한 기간임
      아무리 오래 개발해도 현장에서 3개월간 제대로 작동한 결과가 더 신뢰할 만하므로 일찍, 자주 출시해야 함

  • 소프트웨어 품질은 언제나 시장 유인에 좌우됐으며 AI가 견고한 소프트웨어를 만들 동기를 저절로 주지는 않음
    시장은 업데이트마다 망가지지 않는 앱이나 여러 독립 솔루션의 조합보다 Microsoft 원스톱 제품을 선택하도록 보상함
    과거에는 컴퓨터 성능과 지식이 부족해 그렇게 하지 못했을 뿐이며, 이제 업계는 소프트웨어가 간신히 서 있을 최소 조건과 사용자가 감수할 자잘한 불편의 한계를 찾아낸 셈임

    • 모두를 떠나거나 피해를 보기 직전 상태에 계속 붙잡아 두는 것이 사회가 안착할 만한 지점인지는 의문임
    • 완전성과 정확성이 90~99% 구간에 이르면 비용 곡선이 점근적으로 치솟아 수익 관점에서는 투자할 가치가 없어짐
      결함에 따른 법적 책임 위험이 클 때만 완전하고 정확한 소프트웨어가 만들어짐
    • 품질 저하를 감수하며 계속 소비하다가 “이제 충분하다”고 멈추게 될 실질적 한계점이 어디인지 궁금함

  • KDE Plasma의 Wayland에는 어떤 창이 포커스를 빼앗을 수 있는지 제어하는 전역 설정이 있으며 매우 잘 작동함
    업무용 Mac이나 Windows PC를 사용할 때마다 이 기능이 그리우며, 문서는 ‘Focus stealing prevention’ 항목에서 볼 수 있음: https://docs.kde.org/trunk_kf6/en/kwin/kcontrol/windowbehavi...

    • 악화되는 소프트웨어를 피하는 확실한 방법은 FOSS와 Linux/KDE로 전환하는 것임
      Windows 7이 계속 천천히 개선되며 유용한 완성도를 더한 듯한 환경임
      NixOS는 라이브러리 로딩이 n²이라 GUI 프로그램 시작이 느려지는 오랜 문제가 있지만, N100 미니 PC에서도 모두 약 1초 안에 실행되고 4K 240Hz HDR 모니터도 매끄럽게 처리함
      무엇보다 컴퓨터가 명령한 그대로만 수행함
    • macOS에 포커스 도용 방지 기능이 없다기보다, 앱 실행이 지연되는 상황 자체를 설계자가 상상하지 못한 듯함
      사용자가 기다리다 다른 입력을 하면 더 이상 그 앱에 포커스를 주길 원하지 않는다는 신호일 수 있지만, 앱이 즉시 열린다는 낙관적 상황만 가정한 설계로 보임
    • 오늘날 기술에서 가장 괴로운 것은 사용자가 누르려는 순간 인터페이스가 바뀌는 예측 불가능성임
      터치 키보드의 추천 단어가 손가락이 닿기 직전 바뀌고, iOS Liquid Glass나 불안정한 웹 앱에서는 버튼까지 움직임
      팝업과 “이 앱이 마음에 드나요?” 같은 참여 유도도 넘쳐남
      Windows의 포커스 도용은 1995년에도 문제였고, 100ms 단위로 반복되는 돌발 변화는 근육의 놀람 반응과 변연계를 계속 자극해 몇 시간 뒤에는 몸이 떨릴 정도임
      슬롯머신 같은 자극과 클릭 수를 노리는 참여 지표를 멈추고 작업에 집중할 수 있게 해야 함
    • 훌륭한 기능이지만 현재 ‘Low’보다 높은 방지 수준에서는 지나치게 적극적으로 차단하는 버그가 있음: https://bugs.kde.org/show_bug.cgi?id=509990
    • Windows에서는 Slack이 백그라운드에서 로드되고 준비되면 작업 표시줄 아이콘만 깜박이므로, 사용자가 직접 전환하기 전에는 현재 앱의 포커스를 빼앗지 않음

  • 사용자가 입력하거나 UI와 상호작용하는 동안에는 다른 앱이 절대로 포커스를 가져가지 못하도록 포커스 도용 디바운스가 기본이어야 함
    팝업·소리·아이콘 점멸을 쓰더라도 지금 하는 일과 무관한 앱이 입력을 가로채게 해서는 안 됨
    Cisco AnyConnect처럼 연결 버튼을 누른 뒤 연결됐다는 이유로 예외를 요구할 일도 아니며, 터미널 앱이 STDIN을 빼앗는 행위를 용납하지 않듯 GUI에서도 허용하지 말아야 함

    • 자동으로 포커스를 빼앗기길 원하는 상황은 사실상 없는데도 이 동작이 기본이고 수시로 발생한다는 점이 이해되지 않음
    • macOS도 새로 연 앱을 포커스 밖에 둘 수 있으며, 노트북을 오래 재부팅하지 않았을 때 일관되게 발생함
      버그일 수 있지만 앱 실행이 끝나기 전에 사용자가 다른 창을 클릭했다면 오히려 적절한 기능일 수 있음
    • 운영체제의 이벤트 큐가 프로세스와 창에 걸쳐 작동하므로 이를 간단히 디바운스하기는 어려움
      X11처럼 새 창에 포커스를 주지 않을 수는 있지만 대다수 사용자가 원하는 동작은 아닐 수 있음
    • 팝업·경고음·아이콘 점멸도 충분히 나쁜 방해이며, 사용자의 집중력은 그보다 더 소중함

  • 문제는 원래부터 코드를 쓰는 행위가 아니라 무언가를 세심하고 엄밀하게 만드는 과정이었음
    소프트웨어 개발은 오랜 기간 습관, 안전장치, 검증된 구조를 축적해 발전했지만 이제는 문제만 묘사하고 너무 빠르게 생성된 결과를 제대로 검토하지 못한 채 무엇을 배포했는지도 모르게 됨
    수공예 가구가 공장 생산품으로 바뀌며 누가 어느 부분을 만들었는지 모르고 오래가지 않게 된 것처럼, 소프트웨어도 이해 없는 조립과 배포 단계에 도달함
    부실함은 누적되겠지만 다시 잘 만드는 방법을 진지하게 고민하는 순환의 시작일 수도 있음

    • NPM left-pad 사태는 이미 10년 전이며 공급망 공격과 SBOM 논의도 오래됐고, SourceForge는 배포 파일에 광고 프로그램을 끼워 넣기도 했음
      코드 검토를 하지 않는다면 AI에 코드를 맡기는 것이 PIP나 NPM install을 무검토로 실행하는 것보다 특별히 더 나쁘지는 않음

  • 코딩이 해결됐다는 전제 자체가 틀렸기 때문에 소프트웨어가 계속 나빠지는 것임

    • 코딩은 해결됐을지 몰라도 애초에 병목이 아니었음
      코딩은 오래전부터 저렴했고 회사들은 가장 싼 인력에게 외주를 줬지만, 문제를 식별하고 해결책을 설계하는 능력은 별개임
      코드는 자산보다 부채이므로 실제 문제를 해결하는 최소한만 작성해야 하며 여기에는 엔지니어가 필요함
      AI 출력물을 검토하고 오류를 고치고 나면 직접 작성하는 것과 시간이 비슷해 업무에 큰 도움이 되지 않음
    • 진짜 문제는 코딩이 해결됐다는 사실이 아니라 그렇게 믿는 것임

  • 소프트웨어가 나빠지고 있다는 데는 동의하지만 AI만 탓할 수는 없음
    스트리밍의 TV 전송 실패, 브라우저의 500 오류, 공공 터치스크린의 블루스크린은 이전부터 존재했음
    프로그래머 수가 기하급수적으로 늘어 절반이 경력 수년 이하라는 점에 더해, 단일 스레드 알고리즘 연습만으로는 분산 시스템·CQRS·이벤트 소싱·감사 가능성·멱등성을 다룰 수 없음
    또한 비기술직 제품 책임자(PO)가 생명주기를 장악해 MVP의 정상 경로만 구현하도록 만들면 버그와 향후 재작성이 보장됨
    언어는 C++에서 Java, JavaScript, Python으로 초보자 친화적으로 변했지만 업무는 기업 간 분산 시스템, 24시간 가동, 수백만 사용자, 보안, 기계학습 등으로 더 복잡해짐

    • MVP가 끝나면 마법처럼 출시 제품으로 간주되고, 팀이 개선 방법을 파악할 즈음 경영진이 조직을 다시 섞어 버림
      임원 승진과 부서 통합을 ‘신나는 소식’으로 포장하는 동안 제품 개선의 연속성은 사라짐
    • 제품 관리자 중심주의와 MVP 집착이 품질 저하의 큰 원인임
      애자일을 문자 그대로 어리석게 적용할 필요는 없으며, 인프라나 사용자용 앱도 선행 제품·경쟁사·팀의 경험을 토대로 3·6·12개월 뒤 필요한 기능을 계획할 수 있음
      GPS를 따라갈 때도 전체 경로와 다음 세 단계를 확인하듯, 애자일은 한 걸음을 끝낸 뒤에야 다음 걸음을 처음 고민한다는 뜻이 아님
    • 프로그래밍을 누구나 할 수 있을 만큼 단순하게 만들자 실제로 아무나 하게 됨
    • Uncle Bob도 이제 AI를 전적으로 받아들여 문제의 일부가 될 위험이 있음
    • AI가 품질 저하의 원인은 아닐 수 있지만 쇠퇴를 가속하고 있음
      기계가 침대를 150% 빠르게 만들지만 불량률이 70%라면 불량 제품 증가, 목공 전문성의 소멸, 장인의 의욕과 효용 저하가 동시에 발생함
      언젠가 기계가 개선되더라도 그동안 수많은 사람이 형편없는 침대에서 자야 하는 것과 같음

  • LLM은 전체 코드베이스를 한꺼번에 읽고 이해한 뒤 그 이해를 바탕으로 결정할 수 없음
    프로그래밍의 어려운 부분은 함수나 클래스 하나가 아니라 거대한 시스템 안에서 서로 상호작용하는 방식이며, 소프트웨어 규모는 LLM 문맥 창보다 근본적으로 큼
    문맥 창이 커져도 사람처럼 이해를 축적하는 것은 아니므로 AI가 코딩을 해결했다고 볼 수 없음
    신규 프로젝트에서는 유용하지만, 새 소프트웨어를 빠르게 만드는 일은 원래도 오래된 코드에서 작업하는 것보다 쉬웠음

답변달기