▲

AI: 가속된 무능력

 (slater.dev)
3P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • 소프트웨어 엔지니어링에서 LLM에 대한 과도한 의존은 무능력함을 빠르게 촉진함
  • LLM은 비판적 사고와 문제 해결 능력을 대체할 수 없는 한계가 존재함
  • LLM의 사용은 잘못된 출력, 입력 오류, 코드 품질 저하, 개발자 능력 저하, 창작의 즐거움 상실 등 여러 위험성을 동반함
  • LLM은 프로그램 이론과 프로그램 엔트로피 같은 본질적인 개발 역량을 제공할 수 없음
  • 장기적으로 기술력과 깊은 사고 능력이 그 어느 때보다 중요함

서론

2022년 말 대중적 관심을 받은 AI와 LLM의 등장 이후, 많은 논의가 이어짐
경험 많은 소프트웨어 엔지니어로서 LLM에서 관찰한 주요 문제점 두 가지를 이야기함

"LLM은 나의 친구"라는 관점

LLM을 최고의 도구로 여기는 엔지니어들은 속도를 최우선 가치를 두게 됨
LLM으로 빠르게 많은 코드를 생성할 수 있지만, 이는 장기적 위험을 내포함

LLM 사용의 위험성

  • 잘못된 출력 위험: LLM이 명백히 잘못된 코드(컴파일 불가) 및 미묘하게 오류가 있는 코드(로직 버그 등)를 생성함
    • 평가 역량이 없는 인력이 소스코드를 요청할 때 적합하지 않은 답변 가능성 높음
  • 잘못된 입력 위험: LLM은 오류 있는 가정이나 맥락이 부족한 프롬프트를 비판하지 않음
    • 올바른 질문을 구분하지 못하고 XY 문제(근본 원인 파악 실패)도 공감하지 못함
  • 미래 개발 속도 저하: LLM 도입이 기술 부채를 빠르게 증가시키며, 내부적으로 혼란스럽고 유지보수 곤란한 코드베이스로 변질됨
  • 사용자 미성숙화 위험: 문제 해결과 사고력 발달 기회가 사라지면서 개발 인재의 능력 퇴화가 가속함
    • 시니어 개발자는 더 깊이 있는 문제 해결 경험을 얻지 못하고, 주니어 개발자는 아예 실력을 쌓지 못하게 됨
  • 창작의 기쁨 상실: LLM 기반 코드 작성은 몰입(flow) 상태와 창작의 즐거움을 빼앗고, AI가 만든 코드를 읽고 변경하는 일은 고통스러움이 많음

"AI 때문에 직업을 잃을 것인가?"라는 우려

그럴 가능성은 매우 낮음
LLM이 대체할 수 없는 두 가지 개발 역량이 존재함: 프로그램 이론과 프로그램 엔트로피

프로그램 이론

  • Peter Naur가 주장한 대로, “프로그래밍은 설계 이론을 구축하는 활동” 임
    • 소스코드는 실질적 산출물이 아니며, 집단적 이해(이론) 가 더 중요함
    • 똑같은 실력을 가진 두 팀에게 같은 문제를 주고 코드만 넘겨줄 경우, 직접 만든 팀이 훨씬 효과적으로 기능 추가 수행 가능
    • 익숙하지 않은 코드베이스에선 생산성이 낮다가, 내부적 설계이론을 이해할수록 점차 생산성이 오름

LLM과 프로그램 이론

  • LLM은 문맥 내 기억만 갖추고 있어, 진정한 프로그램 이론이나 심층적 설계를 내재화할 수 없음
    • 실제로 코딩의 진정한 본질(설계와 이론 구성)은 인간만이 획득함

프로그램 엔트로피

  • Fred Brooks는 복잡성(엔트로피) 이 프로그래밍의 근본적 난제라고 명명함
    • 프로그램 유지보수는 복잡성을 증가시키며, 심지어 최고의 실행도 시스템을 불가역적 노후화로 몰고 감

LLM과 프로그램 엔트로피

  • LLM은 텍스트 수준의 토큰 예측만 수행하며, 아이디어, 설계도, 요구사항 수준에서 의미적 사고가 불가함
    • 긴 대화나 큰 코드 덩어리를 다룰수록 불필요하거나 기묘한 변화를 반복해서 복잡성만 가중함
    • 복잡성을 감소시키거나 저항하는 작업은 오직 인간만 가능함

결론

두 선구자의 통찰을 바탕으로 소프트웨어 설계와 복잡성의 본질을 재확인함
AI가 개발 경력을 향상시켜줄 것이라고 기대한다면, 오히려 무능함이 가속될 수 있음을 주의해야 함
풍부한 경험과 숙련된 실력을 가진 개발자로서, LLM은 인간 엔지니어를 대체할 수 없음을 인식해야 함
AI 도입의 사업적 매력은 비용 절감이지만, 실제로는 새로운 위험을 초래하며, 과도한 이용 시 장기적 추가 비용과 조직 리스크가 쌓임
기술력과 깊이 있는 사고 능력의 중요성은 장기적으로 변하지 않으며, AI는 도구로 활용하고 2019년에도 중요했던 본질적 역량에 계속 투자해야 함

다음 글 예고

이후 포스트에서 각 위험성에 대한 구체적 해결책을 다룰 예정임

참고문헌

▲
GN⁺ 7일전  [-]
Hacker News 의견
  • 가끔 AI 코딩에 대한 논의가 소프트웨어 엔지니어와 데이터 사이언티스트/머신러닝 엔지니어 사이의 차이를 반영한다고 느끼는 경험 공유
    소프트웨어 엔지니어는 항상 예측 가능하고 테스트를 통과하는 소프트웨어를 만드는 기대를 받으며, 툴링도 훨씬 발전되어 있음
    반면, 머신러닝 엔지니어에게는 확률적 모델로 작업하는 것이 당연한 일상이며, 평소 테스트도 특정 출력보다는 지표 중심 평가가 많음
    그래서 AI가 항상 신뢰할 수 없다는 점에 더 익숙함
    코딩 어시스턴트 역시 80%만 정답을 주더라도 나머지 20%는 내가 잡아내면 된다는 사고방식으로 접근
  • 내 경험으로도 약 절반은 비슷하게 느낀 경험 공유
    Amazon에서 근무할 때는 고전적 접근법이 없는 문제에 ML 기반 솔루션이 아주 유용하게 쓰였음
    하지만 한 스타트업에서는 기본적인 필터링이나 매핑 이해 없이, 학습 기반 접근만 고집하다가 정지된 비행기의 자세 추정에 어이없는 결과를 반복
    ML과 SW 엔지니어 간의 이 간극이 뚜렷하며, 채용 과정에서 더 잘 드러내는 방법이 있으면 좋겠다는 바람
  • 지금 분위기에서는 MLE 마인드셋이 다른 그룹에도 무리하게 적용된다는 느낌
    정확성과 올바름이 핵심인 상품을 판매하는 회사에서 ML 쪽 팀은 80~90%면 충분하다고 주장, 그에 대한 아키텍트의 불만 목격
    팬데믹에서 1% 치명률 논의 예시처럼, 작은 퍼센트도 큰 영향을 끼칠 수 있음을 상기
  • 결정적(Deterministic) 동작 대 확률적(Probabilistic) 동작 차이 언급
    이 글은 AI와 소프트웨어 엔지니어링의 메타 고민, 즉 프로그램 엔트로피(Entropy) 관리에 초점
    엔트로피 관리가 소프트웨어 제품 구축의 아주 큰 부분이며, AI가 언젠가 이 부분을 쉽게 할 수 있겠지만 지금은 오히려 엔트로피를 더 악화시키는 경우가 많음
  • 현재 AI(특히 ML) 석사 과정 중 SWE로서 새로운 근육을 키우는 중
    MLE를 SWE의 더 넓은 관점에서 보고, robust 파이프라인 구축, 모델 통합, 배포 등 전체 이해 필요
    그러나 대부분의 MLE 순수 전공자는 SWE 시각이 부족하며, 컴퓨터적 감각 없이 ML만 이해하는 경우가 많음
    진정한 풀스택이 되려면 저수준 시스템, 구조, 배포에 MLE까지 이해하는 것이 필수
    그런데 시장 채용은 대부분 SWE 혹은 MLE 박사만 찾음, 이 모든 걸 아는 나에게 보상을 제안해 달라는 의욕
  • 소프트웨어 엔지니어들도 실제로 확률적 사고를 많이 적용
    예를 들어 레이스 컨디션을 재설계하거나, DB 호출의 p99 예측, A/B 테스트 등
  • 기사 주장에 전반적으로 공감하지만, LLM을 사용하면서 생긴 긍정적인 변화도 발견
    30년 경력의 시니어 개발자로서, AI로 생성된 코드를 읽어야 한다는 것은 코드 리뷰 중심 흐름으로 개발이 전환됨을 의미
    이는 개인 개발자에게도 팀 단위 책임감과 코드 읽기 경험 학습에 도움이 됨
    또한 LLM을 제대로 사용하려면 문제의 계층적 구조 이해력이 필수
    섹션별로 상세히 설계해서 구현하는 것이 자연스레 인터페이스와 경계 정의에 도움이 됨
    LLM은 주니어가 시니어로 성장하는 속도를 가속화하는 촉매이며 경험 많은 개발자의 배움을 체험할 수 있도록 도와줌
    AI가 개발자를 대체하진 않을 것이며 결국 도구로 스며들 것
    • 항상 쓰는 코드보다 읽는 코드 양이 많아야 한다고 생각
      LLM 생성 코드는 단조로울 수 있으나, 그 역시 학습 기회
      LLM 생성 코드에서 새로운 관용구/라이브러리 호출 등을 많이 알게 됨
      시니어일수록 더 나은 프롬프트를 줄 수 있어 LLM이 더 강력한 촉매로 작용
    • AI가 코드를 일단 프로토타입 수준으로 만들어주는 복붙 용도로는 아주 좋으나, 검토와 커밋은 불가
    • 기업 입장에서는 AI가 주니어를 도와주는 것이 아니라 주니어 채용을 없애고 시니어에게 AI로 10배 생산성을 요구할 계기가 됨
      빅테크-미드테크-스몰테크 할 것 없이 감원 지속
  • 3D 프린팅이 모든 제조를 대체할까라는 예전 생각과 비슷한 맥락에 AI 논쟁을 비유
    AI는 싱귤래리티보다는 이와 같은 현실적 변화에 더 가깝다는 주장
    • 3D 프린팅은 정말 멋지고 혁신적인 기술이지만 인젝션 몰딩(사출)은 여전히 남아 있음
    • 3D 프린팅이 싱귤래리티를 부르진 않지만, 대학 교육 등 지식노동 현장에서는 AI가 이미 큰 영향을 주고 있음
      예전부터 당연했던 강의/과제/수업 방식이 LLM의 등장으로 전 세계적으로 빠르게 바뀌는 현실 공유
    • 3D 프린팅은 항공우주, 우주 등 여러 산업에서 엄청난 변화와 혁신을 가져온 예시
      SpaceX가 아니었다면 실제로 불가능한 영역이 많았음
    • 비트코인이 은행을 대체할 것이라는 기대와도 유사
      결국 은행이 비트코인 기반 금융 상품 판매로 나온 결과
    • 3D 프린팅과 AI는 완전히 다른 성장 곡선을 갖고 있음
      3D 프린팅은 기존 제조 대체로 여겨지지 않고, 프로토타입/목업/PoC 용도에 머물러 있음
  • LLM은 코드 작성엔 뛰어나지만 '책임' 주체가 되지는 못함
    이해하지 않고 받아들이는 코드는 나중에 유지보수 시 큰 대가(기술부채)를 치르게 됨
    마치 공짜 속도의 착각, 실제로는 40% 수준의 연이율로 기술부채가 쌓이는 효과
    AI로 타이핑만 자동화하고 사고는 인간이 해야 함
    • LLM이 진짜 '이해'한 것이 아니니, 인간이 코드베이스 맥락과 시스템을 이해할 때만 진정한 comprehension
    • 테스팅, 격리된 서브시스템 구조화(tdd, 마이크로서비스 등)로 이자율(기술부채) 줄이는 방법 제안
      일부에서는 전통적 개발에 불필요했던 tdd, 마이크로서비스가 LLM 시대에 더 가치 생김
    • 과업에 따라 AI는 코드 작성까지도 매우 못한 경우가 있음
  • 입력 리스크(Input Risk)가 가장 큰 고통 포인트였다는 경험
    프롬프트의 작은 모호성만으로도 결과가 완전히 어긋날 수 있으며, 이를 눈치채면 뒤늦게 수습하기가 어려움
    인간 언어의 모호함 때문에 결국 명확한 형식 언어가 탄생
    개인적으로 AI 툴링 사용하며 실력이 급격히 저하되는 것 같다는 느낌, 오히려 시간과 에너지를 더 많이 소비한 사례
    AI는 유용하지만, 하나는 복잡한 문제에서 작은 실수가 누적되는 진영, 다른 하나는 결과만 보고 '역할 대체'라 주장하는 매니저/비기술자 진영으로 나뉘는듯
    [자세한 경험: 이전 댓글]
    • AI를 내 조수로서, 내가 품질/유지보수를 직접 책임지는 구조 추천
      계산기가 사람들 암산 능력을 떨어지게 만든 것처럼, AI 역시 글쓰기, 소통, 문제해결 능력 저하를 불러올 수 있음
    • 모호한 단어 입력이 LLM의 비논리적인 결과로 이어지는 경험 공유
      그래서 작고 명확한 과제, StackOverflow에서 찾는 문제에만 LLM을 쓰는 방식
      답변을 절대적 정답이 아닌, 가이드용으로 삼음
    • AI가 어떤 문제는 더 빠르게 해결하게 해 주지만, 필요 이상 복잡하게 만드는 문제도 해결하지 못함
      사람이 전체 설계도를 이해하는 능력이 엔트로피 저항의 핵심
    • 자신이 자주 쓰는 방법: "3라운드, 5개씩 명확한 질문을 해 달라"고 먼저 LLM에 주문
      이렇게 하면 주제/맥락을 더 명확히 다듬을 수 있음
      이 꿀팁이 다른 분들에게도 도움 되길
    • 이 하이프(hype) 시대 이후, 결국 품질 관리의 중요성이 재발견될 것이라는 예감
      예시: 오래된 Coke vs Pepsi 전쟁
  • LLM은 아이디어, 다이어그램, 명세를 개념적으로 다루지 않는다는 주장에는 동의하기 어렵다는 의견
    LLM에 '단순화된 코드 달라'는 식으로 설계 의도로 질의하면 충분히 좋은 두 번째 의견도 얻을 수 있음
    질의하지 않으면 아예 답이 없는 것이고, 디폴트 설정도 우리의 선택이므로 배경 기술 본질과 관련 없는 주장이라고 봄
    • LLM의 개념적 작업이 실증적으로 여러 방법으로 이미 보여진 사례 있음
      현실에선 어느 누구도 거대한 프로그램을 머릿속에서 다 파악할 수 없어, 도구와 언어가 대부분 부분적 이해 기반으로 발전
      LLM도 그같은 한계를 공유하므로, 이 틀에서 인간과 LLM 모두 비슷한 한계
    • 주니어 코드 리뷰 시, 코드 자체의 질보다 방향성 문제 더 많다고 느낌
      LLM이 그 방향에 '왜 그렇게 하냐'고 질문하는 능력을 갖기 어렵다는 점이 아쉬움
    • 코드→다이어그램 전환 자동화 도구 사용하는지 궁금, 직접 만드는지 물어봄
  • 구글/애플맵 등 지도 소프트웨어가 사람의 길찾기 능력을 퇴화시킨다는 주장과의 유사성 언급
    맞는 점도 있지만, 대다수는 원래부터 길을 잘 찾지 못했고 오히려 맵 기술로 A→B 이동 능력이 평균적으로 올라갔다고 생각
    소수의 능숙한 사람도, 기술이 자신 능력을 대체하기보다 보조해 주는 역할
    AI 역시 더 큰 단위에서 유사한 변화를 가져올 것이고, 능력이 줄어들고 손실되는 포인트 있지만 얻는 것도 많을 것
    • 지도는 신뢰성 측면에서 LLM과 비교 불가
      지도는 거의 항상 기대한 값을 주지만, LLM은 같은 프롬프트에도 결과가 바뀌어 신뢰 어렵다고 느낌
      맵 덕분에 호수에 빠지는 사람도 있듯, LLM 맹신은 더 큰 문제 초래 가능성
    • 개인적으로 지도 소프트웨어 사용이 오히려 공간 기억에 도움
      맘껏 헤매고 필요한 순간 경로를 잡을 수 있어 오히려 경험이 증폭됨
    • 구글맵이 택시 기사보다 90% 이상 정확
      AI는 해당 분야 며칠 해 본 일반인보다도 못한 케이스
    • '평균 실력 향상' 주장에 증거가 있는지 의문
  • '[AI]는 개념적 수준에서 일할 수 없다'는 저자 주장에 공감 못함
    최근 LLM은 명확히 개념적 수준에서 작업할 수 있음(예: 컨셉 번역/적용)
    인간이 개인적으로 경험하지 못한 개념도 이해한다고 주장
    • LLM은 토큰 클러스터를 통해 개념을 모델링
      예: 'dog' 근처에 연관된 단어들이 모여 있음
      하지만 조합/의도/반사실논리 등은 모델링 못함
      훈련 데이터와 유사한 질문에서는 힘을 발휘
      소프트웨어 엔지니어처럼 개념화가 잘 정의된 영역에선 쓸모 있음
    • 인간도 직접 경험하지 못한 개념을 이해할 수 있다는 추가 예시
  • 현실적으로 70%의 직원이 업무를 대충 하며, AI가 오히려 더 나을 때도 많음
    결국 일 열심히 안 하는 사람은 AI 써도 변함없고, 진짜 배우는 사람만 AI와 함께 성장
    • 본인이 30%에 속한다는 자기중심적 내러티브의 한계 지적
    • AI로 일 대충 넘기려는 사람은 오히려 해고 위험을 자초
      AI가 일을 더 잘하면 주체를 대체하는 명분 만들 뿐
    • 대기업 기준에선 이 주장이 가장 현실적이라 동의
      FSD(자율주행)도 전문가가 아닌 평범한 운전자보다는 훨씬 나음
  • 최근 90s.dev를 비AI 커뮤니티, 소프트웨어 장인정신의 공간으로 재구성해야 할 필요성 느낀 상황 공유
    포럼, 메일링리스트, 멀티 블로그 형태 등 고민 중
    임시 메일링 리스트
    • 누구나 가입 가능한 구조보다는, 초대 기반, 추천인 신뢰 트리 구조가 지속력 높은 커뮤니티에 더 적합하다고 생각
      특정 커뮤니티에서 이미 성공적인 사례 있음
    • 당시 고전 포럼 소프트웨어를 복고 감성 디자인으로 사용하는 것도 좋은 아이디어
답변달기