▲

소프트웨어 개발의 미래는 소프트웨어 개발자들이다

 (codemanship.wordpress.com)
10P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 수십 년간 반복된 “프로그래머의 종말” 예언은 매번 틀렸으며, 기술 발전은 오히려 더 많은 개발자와 프로그램의 증가로 이어져 왔음
  • WYSIWYG, 4GL, No-Code, LLM 등 다양한 자동화 기술이 등장했지만, 실제로는 개발자의 필요성을 줄이지 못했음
  • LLM 기반 도구는 과거 기술보다 신뢰성과 유지보수성이 떨어지며, 대부분의 팀에서 생산성 저하와 품질 악화를 초래함
  • 프로그래밍의 본질적 어려움은 코드 작성이 아니라 인간의 모호한 사고를 논리적으로 변환하는 능력에 있으며, 이는 여전히 인간의 영역임
  • 따라서 AI가 개발자를 대체할 가능성은 낮고, 오히려 숙련된 개발자에 대한 수요가 더 커질 전망임

반복되는 “프로그래머의 종말” 주기

  • 지난 43년간 Visual Basic, Delphi, Executable UML, No-Code, Low-Code 등 다양한 기술이 프로그래머의 필요성을 없앨 것이라 주장되어 왔음
    • 1970~80년대에는 4GL, 5GL, 그 이전에는 Fortran, COBOL, 더 거슬러 올라가면 컴파일러 A-0조차 같은 예언을 받았음
    • 초기 전자식 컴퓨터 COLOSSUS는 물리적 배선으로 프로그래밍되었으며, 이후 세대가 “진짜 프로그래머가 아니다”라 조롱받기도 했음
  • 그러나 결과적으로는 프로그래머 수가 줄지 않고 오히려 증가, 이는 Jevons Paradox의 대표적 사례로 언급됨

LLM과 과거 기술의 차이

  • 과거 기술은 실제로 소프트웨어 생산 속도를 높이고 신뢰성도 확보했지만, LLM은 대부분의 팀에서 반대 효과를 보임
    • LLM은 코드 품질을 낮추고 유지보수를 어렵게 만들어 “LOSE-LOSE” 상황을 초래함
    • 동일한 프롬프트로도 동일한 결과를 내지 못하며, 생성된 코드에는 인간 개발자의 검증과 수정이 필수적임
  • AI가 개발자를 대체한다는 증거는 없음, 최근 인력 감축은 팬데믹 시기 과잉 채용, 금리 상승, 데이터센터 투자 집중 등 경제 요인 때문임

프로그래밍의 본질적 난제

  • 프로그래밍의 핵심은 인간의 모호한 사고를 논리적으로 정밀한 계산 사고로 전환하는 과정임
    • 이는 천공카드 시절부터 COBOL, Visual Basic, Python에 이르기까지 변하지 않은 어려움임
  • 자연어는 본질적으로 모호하고 비정확하기 때문에, 영어나 프랑스어로 프로그래밍하는 시대는 오지 않을 것이라 Dijkstra의 예언을 인용함
  • 이러한 사고방식을 배우는 것은 가능하지만, 모두가 즐기거나 잘할 수 있는 일은 아니며, 숙련된 인력의 공급은 항상 부족함

AI의 한계와 지속 가능성

  • AGI(범용 인공지능) 은 여전히 멀리 있으며, 인간 수준의 이해·추론·학습 능력이 필요함
  • 대규모 LLM은 막대한 비용과 손실을 초래하고 있어 장기적으로 지속 가능하지 않음
    • 시간이 지나면 모델이 학습한 언어·라이브러리 버전의 제약으로 인해 활용성이 떨어질 가능성 있음
    • 이러한 이유로 초대형 LLM은 ‘Apollo 달 탐사’처럼 비경제적 실험으로 남을 수 있음

미래의 개발 환경 전망

  • 가까운 미래의 소프트웨어 개발은 소규모 언어 모델 기반의 보조 도구가 프로토타입 생성이나 코드 자동완성 등 보조 역할을 수행하는 형태로 예상됨
  • 그러나 중요한 결정과 품질 확보는 인간 개발자가 주도하며, Jevons의 법칙에 따라 개발자 수요는 오히려 증가할 가능성 있음
  • 기업은 지금부터 숙련된 개발자 채용과 교육에 투자해야 하며, 이는 AI 유무와 관계없이 생산성과 신뢰성을 높이는 핵심 전략임
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • 여러 해 동안 agent-LLM을 다뤄본 결과, 실제 프로그래밍에는 전혀 쓸모가 없었음
    복잡한 저수준 라이브러리 문제나 비직관적인 버그를 해결하지 못하고, 추상화된 계층의 논리를 이해하지 못함
    단, 단순한 웹사이트 구축처럼 이미 수천 번 반복된 보일러플레이트 작업에는 탁월했음. 이런 단순 작업에서는 하루치 시간을 절약했음
    하지만 LLM이 단순 작업 영역을 넘어 복잡한 문제를 이해하는 단계로 갈 가능성은 보이지 않음

    • “진짜 프로그래밍”의 정의가 다르다고 생각함
      저수준 코딩이나 레거시 버그 해결만이 프로그래밍은 아님. LLM이 해결한 웹사이트 구축도 분명 프로그래밍의 한 형태임
    • 나도 비슷한 경력을 가지고 있지만, LLM이 무용지물이라는 주장에는 동의하지 않음
      대규모 코드베이스 이해, 기능 브레인스토밍, 구현상의 갭 파악 등에서 엄청난 시간을 절약했음
      완전한 대체는 불가능하지만, 엔지니어의 강력한 도구로서 가치는 분명함
    • 아마도 당신은 매우 저수준의 일을 하는 듯함
      하지만 대부분의 개발자는 프레임워크와 라이브러리를 조합하는 일을 함.
      전기차가 대형 화물 운송에는 부적합하지만 일반 운전자에게는 충분히 유용한 것처럼, LLM도 그런 위치에 있음
    • 최근 Codex 5.2가 CTF 대회에서 암호 문제를 풀었다는 이야기를 들었음
      몇 달 전까지만 해도 동의했겠지만, 이제는 기술이 그 경계를 넘은 듯함
    • 내 경험은 완전히 다름. 사용하는 언어와 아키텍처에 따라 차이가 큼
      나는 ERP 분야에서 일하는데, 에이전트들이 생산성을 비약적으로 높여줌
      구독료가 월 500달러로 올라도 계속 쓸 만큼 가치가 있음

  • AI가 프로그래머의 필요성을 줄인다는 예측이 현실이 될까 두려움
    이미 AI가 설계, 코드 리뷰, 버그 탐지, 프로젝트 계획 등에서 나보다 낫다고 느낌
    나는 단지 그 과정을 지휘하는 지휘자 역할만 하는 듯함
    예전엔 20명이 하던 일을 혼자 하는 기분이라 무섭기도 함

    • LLM이 인간에게 학습된 무기력감을 심는다고 생각함
      인간만이 장기 계획과 의사결정을 잘함. 우리는 걱정, 자부심, 감정을 가지며, 그것이 진짜 강점임
      AI는 단지 단어의 가방일 뿐, 사랑도 지속성도 없음
    • AI가 그런 수준의 일을 잘한다는 건 사실이 아님
      기본적인 역량만 있어도 인간이 훨씬 낫다고 생각함
    • 이건 광고처럼 들림. 실제로는 AI가 복잡한 문제에서 엉터리 결과를 내고, 테스트도 부실함
      20명이 하던 일을 혼자 한다면, 그 20명은 원래 생산성이 낮았을 것임
    • 나는 11년간 미슐랭 레스토랑 셰프로 일했음
      설거지 기계를 계속 돌리는 게 핵심이었는데, AI 코딩 에이전트도 그 기계와 같음
      나는 프롬프트를 넣고, 결과를 검수하고 정리하는 역할을 함. 결국 인간의 손이 여전히 필요함
    • 자동차가 인간보다 빠르고 오래가지만, 여전히 운전자는 필요함
      AI 덕분에 20명이 하던 일을 한 명이 한다면, 그것은 생산성 향상이며 더 큰 부를 창출함

  • 지금의 LLM 열풍은 대규모 Eliza 효과라고 생각함
    관련 개념은 ELIZA effect와 Weizenbaum의 저서 Computer Power and Human Reason에서 볼 수 있음

    • 나도 Eliza 효과가 강하다고 느낌
      LLM은 영향력 있는 사람들(CEO, 투자자) 을 감동시키도록 진화한 듯함
      실제 전문가 수준이 될 필요는 없고, 단지 “충분히 괜찮아 보이는” 수준이면 채택됨

  • 미국 개발자에게 진짜 위협은 AI가 아니라 아웃소싱임
    나는 이민자로, 뉴욕의 금융회사에서 일함. 직원의 95%가 외국 출신이고, 신규 채용도 대부분 H1B 비자 소지자임

    • 맞음, 이런 흐름은 이미 수십 년 전부터 계속되어 왔음

  • Dijkstra가 50년 전 이미 말했듯, 인간 언어로 프로그래밍하는 일은 불가능함
    자연어는 본질적으로 모호하고 비정확하기 때문임
    “프롬프트가 새로운 소스코드다”라고 주장하는 사람들은 마치 Excel로 앱을 만드는 사람들과 같음

  • “Blood in the Machine”이라는 책을 읽고 러다이트 운동의 역사를 알게 되었음
    산업혁명 전에는 가족 단위로 옷을 만들었지만, 기계가 등장하면서 수공업 산업이 붕괴됨
    지금 개발자들도 같은 길을 걷고 있는 듯함

    • 러다이트는 직조기에 대한 반발이었음. 옷을 만드는 과정 중 가장 시간이 많이 걸리는 부분이었음
      하지만 소프트웨어 개발에서 코딩은 전체 과정의 일부일 뿐임
    • 자동차 산업 비유가 더 적절함
      Toyota가 장인들을 대체했듯, LLM이 유지보수까지 자동화한다면 개발자도 같은 운명을 맞을 것임
    • 하지만 의류 산업은 여전히 존재함
      값싼 옷이 넘쳐나도 디자이너와 고급 브랜드는 남아 있음. 소프트웨어도 그렇게 변할 것임

  • 과거 Visual Basic과 Delphi 같은 WYSIWYG 도구가 프로그래머를 대체할 거라 했지만, 결국 아니었음
    AI도 비슷함. 취약하고 불안정한 코드를 생성할 수는 있지만, 여전히 진짜 프로그래머가 안정화해야 함

  • 1980년대에도 정부와 업계가 4GL에 막대한 투자를 했지만, 결국 실패했음
    일본의 MITI Fourth Generation Project도 비슷했음. 당시의 “소프트웨어 위기”는 지금의 AI 열풍과 닮아 있음

  • 이 글은 AI 찬양 기사처럼 느껴짐. 마지막에 교육 서비스를 홍보하는 부분이 특히 그랬음
    그래도 실제로 내 생산성이 높아진 건 사실이라, 결국 개발자 수요 감소는 불가피할 듯함

    • 나도 같은 인상을 받음. 저자는 뛰어난 교사지만, 새로운 통찰은 없었음
      오히려 여러 의견을 짜깁기한 LLM이 쓴 글처럼 느껴졌음
    • 석탄 기관이 효율적일수록 석탄 수요가 늘었던 것처럼, Jevons의 역설이 소프트웨어에도 적용될 수 있음
      개발 비용이 절반으로 줄면 더 많은 분야에서 소프트웨어를 활용하게 될 것임
      Jevons paradox 참고

  • 항공 안전에서 말하는 Swiss cheese 모델처럼, LLM도 소프트웨어 개발의 한 층으로 볼 수 있음
    각 층이 완벽하지 않아도 서로의 결함을 보완해 전체 품질을 높이는 개념임

    • 흥미로운 비유지만, 아직 우리는 LLM을 그런 보조 레이어로 활용하지 못하고 있음
      코드 검증이나 테스트 분석에 지능적으로 적용하는 단계는 아님
      하지만 언젠가 제대로 된 사용 사례가 나올 것이라 확신함
    • LLM은 Kraft Singles 같은 가짜 치즈에 가까움
      안전을 보장하려면 결국 사람이 전체를 검수해야 함
    • 항공 산업의 안전 패러다임을 LLM에 적용하는 건 무리임
      항공 소프트웨어의 신뢰성과 LLM의 불안정성은 비교조차 불가능함
답변달기