소프트웨어 엔지니어링 분야만 유독 "10배(10x) 생산성" 신화를 집착하는 이유가 이해되지 않음, 기계, 전기, 건설, 화학 엔지니어에서는 이 개념이 없음
훌륭한 엔지니어란 위험을 줄이고 다양한 제약 조건 안에서 시스템을 설계할 수 있는 능력임
설계란 모델을 통해 도메인을 이해하고, 모델이 유효한 범위와 한계를 파악하는 과정임
"10x"라는 건 없고, 좋은 시스템을 책임지는 것만 있을 뿐임
만약 "10x" 소프트웨어 엔지니어가 있다면, 데이터 유출과 같은 사고를 막는 사람이 될 것이고, 오히려 그런 사건이 10배 줄어드는 것을 보고 싶음
나도 이 글의 상당 부분에 동의함
나는 AI 도구를 활용한 개발의 엄청난 팬이지만 10x 생산성 주장은 설득력이 없었음
LLM 덕분에 코드 타이핑 같은 일부 업무가 2~5배 빨라졌지만, 이건 전체 업무의 일부임
실제로 많은 엔지니어가 20~50% 특정 작업이 빨라질 수 있다고 생각하지만, 그게 전체 생산성 20% 상승이나 10x 증가로 이어지지 않는다는 점에 동의함
물론 AI를 정말 잘 쓰는 사람은 0.2배보다 더 많은 생산성 향상을 체감할 수도 있지만, 소프트웨어 개발의 본질적 복잡성 때문에 10x는 대부분 비현실적임
AI를 쓸 때 내가 계속 옆에서 돌봐줘야 해서 효율이 높다는 생각이 들지 않음
copilot의 제안이 때로는 내 생각과 완벽히 맞아 떨어져 감탄하지만 전체적으로는 매우 숙련된 주니어 개발자라기보다는 "술 취한 시니어 개발자"처럼 말을 잘 안 듣는 느낌임
생성된 코드가 절반은 컴파일조차 안 되고, 컴파일이 되어도 제대로 작동하지 않음
내 경험상 AI는 새로 만드는 영역(creation)에서는 엄청난 생산성 향상을 주진 않지만, 탐색(discovery), 학습, 막힌 부분 해결, 반복적인 코드 작성 등에는 큰 도움이 됨
하지만 진정한 변화는 사이드 프로젝트에서 발생함
예전엔 피곤해서 부업에 시간을 잘 못 썼는데, 이제는 완벽한 코드는 아니더라도 빠르고 적은 정신력으로 아이디어를 현실로 구현할 수 있음
AI 엔지니어링 스킬도 마감, 개인정보, 도구 같은 제약 없이 자유롭게 실험할 수 있음
"10x 엔지니어"라고 불리는 사람들도 AI로 인한 생산성 향상은 미미할 것으로 생각함
내가 아는 최고 개발자는 두 가지 능력이 핵심임: 어마어마한 기억력과 모든 언어/라이브러리의 세세한 부분을 외우고 있음, 그리고 기적 같은 창의력과 문제 해결력
수식·이론 따위는 몰라도 그 문제에 가장 적합한 독창적이고 깔끔한 해법에 도달하는 점이 인상적임
AI와 페어프로그래밍하면 비슷한 솔루션에 도달하기까지 AI는 끝없이 시도와 반복이 필요하고, 오히려 천재 인간의 속도를 늦추는 결과임
하지만 역량 스펙트럼이 워낙 다양해서 내 입장에서는 AI 덕에 10배 생산성 향상이 가능하기도 함
내 전공은 소프트웨어가 아니고 완벽주의 성향 때문에 아주 느리게 개발하는데, AI 덕분에 형편없는 첫 버전을 빠르게 만들어 볼 수 있어 아이디어 실현에 유용함
나도 AI 어시스턴트 개발에 찬성하며, 2~10배 속도 향상이 일부 상황에서는 존재할 수 있다고 생각함
하지만 대부분 "10x" 생산성이란, 처음부터 끝까지 기능을 구현하는 전체 개발 과정이 10배 빨라졌다는 의미로 과장되어 사용됨
현실적으로 전체 개발 프로세스의 많은 부분(코딩 외)은 10배 빨라지지 않음
그렇다고 정말 소규모 혹은 혼자 일하는 환경에서는 번거로운 절차를 많이 건너뛰게 되어서 실질적으로 큰 속도 향상이 있음
이런 맥락에서 소규모 팀, 단독 개발이 갑자기 경쟁력을 가지는 시대가 됨
Simon의 댓글에 고마움을 전함
이 댓글이야말로 실제로 글을 읽은 느낌이 듦
언어나 도구에 특화된 일부 직무에서는 실제로 2배 생산성 향상이 일어나고 있다는 점을 인정함
수십 년간 소프트웨어 개발 자동화의 꿈을 꿨는데, LLM이 완전히 다른 방식으로 그 꿈을 실현했음을 느낌
기존의 CASE 툴, UML, IDE 등은 "진짜 로직에 집중하게 하겠다"고 약속했으나, LLM은 그냥 자연어에서 즉시 실행 가능한 코드를 생성함
많은 개발자들이 기존의 통과의례가 무너지고, 새로운 세상에서 뒤처질까 불안함(임포스터 증후군)
이제 소프트웨어 엔지니어링이란 게 무엇인지 다시 묻게 됨
LLM은 이전 CASE 툴의 궁극의 형태이지만, 이 과정이 너무 빨랐고, 혼란스럽고, 파괴적임
소프트웨어 엔지니어라는 "성스러운 언어"를 모르는 사람도 힘을 가지게 되었고, 많은 엔지니어가 "내가 지금 무슨 일을 하고 있는지?"라는 근본적인 고민을 하게 됨
나는 이제야 예술가들이 stable diffusion을 봤을 때의 기분을 이해함
AI가 만든 코드는 결과적으로 자주 틀리고, 버그가 많고, 이상한 관습이나 쓸데없는 것들이 넘침
이런 문제를 다 고치는데 오히려 직접 만드는 것만큼 시간이 걸림
다양한 모델을 시도하거나 프롬프트를 다듬어도, 진짜로 내가 원하는 고품질 코드는 아직 손에 닿지 않는 느낌임
마치 stable diffusion에서 신경 쓰지 않는 사람은 뭔가 이상한지 모르는 것처럼, AI 코드를 잘 모르는 사람도 그것이 문제가 있다는 걸 알지 못함
최근에 회사 동료가 쓴 코드가 이상해서 봤더니, 디버거도 안 되고 온갖 문제가 가득했으며, 동료가 "그냥 느낌으로 코딩했다"고 고백함
최근 세상을 보면 자본이 노동을 계속 파괴하고 있음을 느낌
낮은 임금, 열악한 근무 환경, 감시, 지표 압박, 비윤리적 기업, 단기 계약 등 대부분의 노동자가 처한 현실이 점점 악화되고 있음
우리는 그동안 너무 보호받아서 이런 현실을 제대로 느끼지 못했으나, 이제 우리 역시 불안정한 미래와 마주하고 있음
"소프트웨어 엔지니어링"은 결국 vibe(감) 고치는 작업으로 바뀔 것임
많은 직업이 소프트웨어로 대체 가능하지만, 관리자들이 검증된 가치를 입증하지 못하면 SWE를 고용하지 않으려는 현실이 있었음
AI 도입으로 인해 관리자들은 이해할 수 없는 코드를 대량 만들고, 3년 후 그게 다 망가지면 SWE를 다시 불러 고치게 될 것임
오히려 이런 "AI가 해결 못하는 문제"를 고치는 고난이도/고가치 일자리가 더 많아질 가능성이 높음
LLM은 공식 모델이나 다이어그램 없이 바로 코드를 만듦
난 오히려 AI가 이런 공식 설계나 다이어그램을 만들어주길 바람
이런 도구는 코드 이해와 설계 명확화에 도움이 되기 때문임
AI가 이런 부분까지 지원해줬으면 좋겠음
소프트웨어 개발의 병목은 타이핑 속도나 생성이 아니라 검증과 이해임
LLM이 헛소리(환상, hallucination) 없이 완벽하게 작동해도, 양심적인 개발자는 코드를 하나씩 검토해야 함
사람이 10배 빠르게 코드를 이해할 수 없기 때문에, 실제로 자동 생성 코드를 되짚고 숨은 의도까지 해독하느라 시간이 더 오래 걸릴 수 있음
"10x 생산성"이란 말은 코드 검증 없이 출력물을 그대로 넘기는 경우나, 오류가 중요하지 않은 아주 단순 코드를 다룰 때만 해당함
실제로 오류가 곧 재앙인 프로덕션 소프트웨어는 여전히 인간의 인지 역량이 병목이며, LLM은 작성에서 검토로 부담을 옮겼기에 오히려 전반 생산성에 마이너스임
이 논의는 평균적 개발자들이 스스로의 생산성을 드러내는 느낌임
프로젝트의 기술을 이해하고, 작업을 잘 분할한다면 코드 복잡도를 미리 예측해서 AI에게 적절한 단위로 일을 시킬 수 있음
AI는 마법이 아니고, 작성 가능한 복잡도의 상한선이 있음
그 한계와 내가 만드는 프로젝트의 기술을 잘 이해하면, 컴포넌트를 해당 한계 아래로 쪼개 AI에게 지시할 수 있음
이 방식이 상당히 잘 작동함
이건 거의 동어반복임
AI가 잘 작동하도록 지시를 단순하게 하면, 당연히 잘 작동함
하지만 실제론 AI에게 지침을 지나치게 세세하게 떠먹여줘야 하고, 그래도 결과물을 꼼꼼히 재확인하며 신뢰할 수 없음
오히려 잘게 쪼개서 AI에게 설명하는 일 자체가 코드를 직접 작성하는 것보다 더 번거로울 수 있음
AI가 운 좋게 단번에 정답을 주면 효율이 있지만, 현실적으로는 반복적으로 수정하거나 결국 다시 다 만들면서 시간과 노력이 낭비됨
AI의 구조화된 보기 좋은 코드가 실제로는 잘못된 경우가 많아 위험함
진짜 어렵고 시간이 걸리는 부분은 복잡한 부분 설계임
사소한 부분은 입력만 하면 되지만, 복잡한 부분을 해결하는 것이 진짜 시간 소모임
이 댓글의 이면에 "나는 평균 이상 개발자라고 생각함?"이라는 뉘앙스를 느낄 수 있음
오히려 반대일 수도 있음
실력 없는 개발자들이 무의미하게 오토 PR만 제출하면서 AI가 만든 결과물에 감탄하는 반면, 눈높이가 높은 개발자는 그 결과물에 감탄하지 않을 수 있음
실제로 직접 같이 일해보지 않으면 신뢰할 수 있는 사람을 구분하기 어렵기에 나는 중립을 유지함
AI도, 인간도 한계가 있음
결국 필요한 건 지루한 프로젝트 관리임
제대로 된 요구사항, 설계, 그리고 충분한 정보를 담아 작은 작업 단위로 쪼개면, AI에게 "깃헙 이슈 #42를 구현해"라고 시키고 TV 보면서 지켜볼 수도 있음
하지만 "facebook 만들어줘"하면 당연히 망하는 흐름임
AI가 또 하나 큰 도움 준 분야는 버그 찾기임
나는 주로 수치 시뮬레이션 작업을 하는데, 며칠이나 묶여있던 문제(몇 개 괄호가 빠진 걸로 인한 식의 스케일 오류)를 chatgpt에 파일과 현상을 설명하니, 금방 원인을 알아냄
AI는 때론 내가 놓친 부분을 명쾌하게 집어주는 역할
이게 10x 개발자를 만들어 주는 건 아니지만, 잘 쓰면 커다란 긍정 효과를 체감함
나도 비슷함
AI로 코드 만들기는 그저 그런 수준이지만, 디버깅은 정말 큰 생산성 도약임
일종의 매우 똑똑한 "러버덕"임
(취미 개발자 관점) LLM 덕분에 밤늦게 머리 안 돌아갈 때 개발이 훨씬 쉬워짐
나도 무수히 많은 시간을 AI 덕에 아꼈음
내겐 10배와 무한대의 중간 어딘가인 느낌임
나는 10x 엔지니어라 생각하지 않음
회사 동료보다 내가 더 생산적인 이유는 시스템 설계와 사업적 요구를 불분명한 티켓 그대로 따르지 않는 것임
AI가 내 동료들을 단순화 못하는 이유는, 애초에 복잡하게 만드는 습관을 바꾸지 못해서임
AI는 이 문제까지 해결해주지 않음
나는 2x 엔지니어도 아닌 것 같음
회사에서 내 연봉이 동료와 2배 차이가 안 나니 그렇게 여김
AI 도구 도입한다고 이런 현실은 안 바뀜
이 글은 "10x"라는 너무 높은 기준을 세운 다음, 저자가 그걸 넘으려 한 사적 시도 기록임
그래서 AI 지지자들을 세 부류(착각하는 사람, 판매하는 사람, 불안 심리를 공략하는 악덕 관리자)로 나눴다고 생각함
개인적으로 "환각(hallucination)"에 대한 불평은 약간 "신호"라 여김
환각(hallucination)에 대한 이야기가 꼭 필요하다고 생각함
LLM에 대한 논의가 너무 극단적으로 흘러감(아예 쓸모없다는 쪽 vs 개발자 대체라는 쪽)
예로 Claude 4 Sonnet이 clang 컴파일 관련 내용을 Godbolt가 틀렸다고 잘못 답변한 적 있음
그럼에도 이 세션 전체적으로 큰 도움을 받았으므로, 결과에 비판적이어야 한다는 점만 명심하면 됨
환각은 실제로 존재하고, 결과에 대해 항상 경계해야 함
댓글을 남겨줘서 고맙고, 네가 쓴 AI 관련 글 덕에 임포스터 증후군을 극복하는 데 도움을 받았음
글에서는 "10x 잇달아 성공했다" 주장하는 사람에 한해서 분류한 건데, 모든 AI 지지자를 싸잡아 말한 게 아님
실제로 환각이 아예 없는 방법을 찾았는지 궁금함
특히 Terraform 등에서는 존재하지 않는 프로퍼티를 LLM이 만들어내고, JS 등에서도 드문 라이브러리 사용할 땐 여전히 착각이 잦음
웹앱을 만들 줄 모르는 사람이 6주 동안 하루 4시간씩(120시간) 배우며 겨우 하나를 만든다고 가정
대신 Claude code 등 AI를 활용해 주말 이틀(12시간)에 같은 웹앱을 만든다면 생산성이 10배 상승
이게 실제로 나에게 일어난 일과 비슷함
예전엔 동기부여나 에너지가 부족해 못 하던 일을 AI 덕에 주말동안 해낼 수 있게 됨
하지만 첫 번째 방법은 배우는 과정이 있어서 다음에 뭔가 바꿀 때 도움이 될 수 있음
사실 Claude Code 같은 AI에게 리액트 외로 웹앱 스캐폴딩 시키면 엉망임
앱 개발 경험이 없는 사람이 주말에 완성도 높은 앱을 쉽게 만들진 못함
첫 사용자 로그인만 해도 바로 망가질 수 있음
장기적으로 보면 저 산술이 말이 되지 않는다고 생각함
LLM으로 처음엔 앱을 빠르게 만들지만 점점 유지보수 능력이 떨어지고, 어느 순간 복잡해진 시스템을 더는 “컨텍스트 윈도우”에 담고 관리하지 못함
결과적으로 생산성은 오히려 0에 가까워질 수도 있음
뇌와 학습 경험을 아예 아웃소싱한 거라서, 앱은 생겼지만 성장이나 배움은 거의 없었음
그걸 바로 배포할 생각임?
현실적으로 동일 선상이 아님
1x 개발자 산출물도 측정하기 어렵고, 그걸 곱하는 건 더더욱 무의미함
나는 AI가 "사이드 퀘스트 생산성"을 크게 올려준다고 느낌
그동안 귀찮아서 미뤄두던 일(목업 제작, 테스트 작성, 라이브러리 추출, 문서화 등)에 AI가 최적임
기능을 만드는 시간을 단축시키지는 못해도 부가 작업까지 포함하면 결과물이 조금 더 완벽에 가까워짐
이 부가 작업 덕에 미래에 버그 찾기 시간이 줄었으면 좋겠음
(개인 경험)
내 케이스에 한정된 이야기지만, 우리 회사에선 LLM으로 만든 테스트 코드가 구현 코드와 너무 밀접하게 엮이는 게 일반적임
테스트 스파이 같은 패턴 남용이 심함
그 결과, 사용자 입장에서의 동작 대신 내부 구현 세부사항만 검사하는 애매한 테스트가 많아짐
테스트가 구현 변경에 따라 너무 자주 깨져, 오히려 테스트가 생산성이 아니라 부담임
이는 LLM의 문제만은 아니고, 원래부터 테스트 제대로 못 하는 개발자들이 LLM으로 인해 문제가 더 심해지는 것임
TDD, 잘 설계된 테스트 코드 경험이 부족한 개발자에게 LLM이 이런 안티패턴을 증폭시킴
"사이드 퀘스트 생산성" 표현이 좋음
AI는 "죽음의 천 스침"이 아니라, "천 개의 반창고로 만들어진 새 삶" 느낌임
"사이드 퀘스트" 개념에 찬성함
사실 내가 AI 없이 만들지 않았을 툴이나 기능을, AI 덕에 만들 수 있게 된 게 큰 변화임
단순히 2주를 아끼는 게 아니라, 없던 결과물이 생긴 거임
LLM에 대한 기대가 현실보다 높지만, 실제로 다양한 상황에서 매우 유용함
"줌 레벨"로 보면, "vibe coding"처럼 대충 만드는 수준부터, "이 함수 만들어 줘"까지 단계별로 쪼갤수록 결과가 훨씬 좋았음
코드 생성 외에도 새로운 기술 학습 등 여러 용도에서 효과적임
내 역할이 미팅이 많거나 관리자 업무가 많으면 LLM의 도움은 감소함
앞으로는 PR 워크플로우, 커밋 정리, 순서 재조정 등에도 LLM이 활용될 수 있으리라 생각함
Hacker News 의견
소프트웨어 엔지니어링 분야만 유독 "10배(10x) 생산성" 신화를 집착하는 이유가 이해되지 않음, 기계, 전기, 건설, 화학 엔지니어에서는 이 개념이 없음
훌륭한 엔지니어란 위험을 줄이고 다양한 제약 조건 안에서 시스템을 설계할 수 있는 능력임
설계란 모델을 통해 도메인을 이해하고, 모델이 유효한 범위와 한계를 파악하는 과정임
"10x"라는 건 없고, 좋은 시스템을 책임지는 것만 있을 뿐임
만약 "10x" 소프트웨어 엔지니어가 있다면, 데이터 유출과 같은 사고를 막는 사람이 될 것이고, 오히려 그런 사건이 10배 줄어드는 것을 보고 싶음
나도 이 글의 상당 부분에 동의함
나는 AI 도구를 활용한 개발의 엄청난 팬이지만 10x 생산성 주장은 설득력이 없었음
LLM 덕분에 코드 타이핑 같은 일부 업무가 2~5배 빨라졌지만, 이건 전체 업무의 일부임
실제로 많은 엔지니어가 20~50% 특정 작업이 빨라질 수 있다고 생각하지만, 그게 전체 생산성 20% 상승이나 10x 증가로 이어지지 않는다는 점에 동의함
물론 AI를 정말 잘 쓰는 사람은 0.2배보다 더 많은 생산성 향상을 체감할 수도 있지만, 소프트웨어 개발의 본질적 복잡성 때문에 10x는 대부분 비현실적임
AI를 쓸 때 내가 계속 옆에서 돌봐줘야 해서 효율이 높다는 생각이 들지 않음
copilot의 제안이 때로는 내 생각과 완벽히 맞아 떨어져 감탄하지만 전체적으로는 매우 숙련된 주니어 개발자라기보다는 "술 취한 시니어 개발자"처럼 말을 잘 안 듣는 느낌임
생성된 코드가 절반은 컴파일조차 안 되고, 컴파일이 되어도 제대로 작동하지 않음
내 경험상 AI는 새로 만드는 영역(creation)에서는 엄청난 생산성 향상을 주진 않지만, 탐색(discovery), 학습, 막힌 부분 해결, 반복적인 코드 작성 등에는 큰 도움이 됨
하지만 진정한 변화는 사이드 프로젝트에서 발생함
예전엔 피곤해서 부업에 시간을 잘 못 썼는데, 이제는 완벽한 코드는 아니더라도 빠르고 적은 정신력으로 아이디어를 현실로 구현할 수 있음
AI 엔지니어링 스킬도 마감, 개인정보, 도구 같은 제약 없이 자유롭게 실험할 수 있음
"10x 엔지니어"라고 불리는 사람들도 AI로 인한 생산성 향상은 미미할 것으로 생각함
내가 아는 최고 개발자는 두 가지 능력이 핵심임: 어마어마한 기억력과 모든 언어/라이브러리의 세세한 부분을 외우고 있음, 그리고 기적 같은 창의력과 문제 해결력
수식·이론 따위는 몰라도 그 문제에 가장 적합한 독창적이고 깔끔한 해법에 도달하는 점이 인상적임
AI와 페어프로그래밍하면 비슷한 솔루션에 도달하기까지 AI는 끝없이 시도와 반복이 필요하고, 오히려 천재 인간의 속도를 늦추는 결과임
하지만 역량 스펙트럼이 워낙 다양해서 내 입장에서는 AI 덕에 10배 생산성 향상이 가능하기도 함
내 전공은 소프트웨어가 아니고 완벽주의 성향 때문에 아주 느리게 개발하는데, AI 덕분에 형편없는 첫 버전을 빠르게 만들어 볼 수 있어 아이디어 실현에 유용함
나도 AI 어시스턴트 개발에 찬성하며, 2~10배 속도 향상이 일부 상황에서는 존재할 수 있다고 생각함
하지만 대부분 "10x" 생산성이란, 처음부터 끝까지 기능을 구현하는 전체 개발 과정이 10배 빨라졌다는 의미로 과장되어 사용됨
현실적으로 전체 개발 프로세스의 많은 부분(코딩 외)은 10배 빨라지지 않음
그렇다고 정말 소규모 혹은 혼자 일하는 환경에서는 번거로운 절차를 많이 건너뛰게 되어서 실질적으로 큰 속도 향상이 있음
이런 맥락에서 소규모 팀, 단독 개발이 갑자기 경쟁력을 가지는 시대가 됨
Simon의 댓글에 고마움을 전함
이 댓글이야말로 실제로 글을 읽은 느낌이 듦
언어나 도구에 특화된 일부 직무에서는 실제로 2배 생산성 향상이 일어나고 있다는 점을 인정함
수십 년간 소프트웨어 개발 자동화의 꿈을 꿨는데, LLM이 완전히 다른 방식으로 그 꿈을 실현했음을 느낌
기존의 CASE 툴, UML, IDE 등은 "진짜 로직에 집중하게 하겠다"고 약속했으나, LLM은 그냥 자연어에서 즉시 실행 가능한 코드를 생성함
많은 개발자들이 기존의 통과의례가 무너지고, 새로운 세상에서 뒤처질까 불안함(임포스터 증후군)
이제 소프트웨어 엔지니어링이란 게 무엇인지 다시 묻게 됨
LLM은 이전 CASE 툴의 궁극의 형태이지만, 이 과정이 너무 빨랐고, 혼란스럽고, 파괴적임
소프트웨어 엔지니어라는 "성스러운 언어"를 모르는 사람도 힘을 가지게 되었고, 많은 엔지니어가 "내가 지금 무슨 일을 하고 있는지?"라는 근본적인 고민을 하게 됨
나는 이제야 예술가들이 stable diffusion을 봤을 때의 기분을 이해함
AI가 만든 코드는 결과적으로 자주 틀리고, 버그가 많고, 이상한 관습이나 쓸데없는 것들이 넘침
이런 문제를 다 고치는데 오히려 직접 만드는 것만큼 시간이 걸림
다양한 모델을 시도하거나 프롬프트를 다듬어도, 진짜로 내가 원하는 고품질 코드는 아직 손에 닿지 않는 느낌임
마치 stable diffusion에서 신경 쓰지 않는 사람은 뭔가 이상한지 모르는 것처럼, AI 코드를 잘 모르는 사람도 그것이 문제가 있다는 걸 알지 못함
최근에 회사 동료가 쓴 코드가 이상해서 봤더니, 디버거도 안 되고 온갖 문제가 가득했으며, 동료가 "그냥 느낌으로 코딩했다"고 고백함
최근 세상을 보면 자본이 노동을 계속 파괴하고 있음을 느낌
낮은 임금, 열악한 근무 환경, 감시, 지표 압박, 비윤리적 기업, 단기 계약 등 대부분의 노동자가 처한 현실이 점점 악화되고 있음
우리는 그동안 너무 보호받아서 이런 현실을 제대로 느끼지 못했으나, 이제 우리 역시 불안정한 미래와 마주하고 있음
"소프트웨어 엔지니어링"은 결국 vibe(감) 고치는 작업으로 바뀔 것임
많은 직업이 소프트웨어로 대체 가능하지만, 관리자들이 검증된 가치를 입증하지 못하면 SWE를 고용하지 않으려는 현실이 있었음
AI 도입으로 인해 관리자들은 이해할 수 없는 코드를 대량 만들고, 3년 후 그게 다 망가지면 SWE를 다시 불러 고치게 될 것임
오히려 이런 "AI가 해결 못하는 문제"를 고치는 고난이도/고가치 일자리가 더 많아질 가능성이 높음
LLM은 공식 모델이나 다이어그램 없이 바로 코드를 만듦
난 오히려 AI가 이런 공식 설계나 다이어그램을 만들어주길 바람
이런 도구는 코드 이해와 설계 명확화에 도움이 되기 때문임
AI가 이런 부분까지 지원해줬으면 좋겠음
소프트웨어 개발의 병목은 타이핑 속도나 생성이 아니라 검증과 이해임
LLM이 헛소리(환상, hallucination) 없이 완벽하게 작동해도, 양심적인 개발자는 코드를 하나씩 검토해야 함
사람이 10배 빠르게 코드를 이해할 수 없기 때문에, 실제로 자동 생성 코드를 되짚고 숨은 의도까지 해독하느라 시간이 더 오래 걸릴 수 있음
"10x 생산성"이란 말은 코드 검증 없이 출력물을 그대로 넘기는 경우나, 오류가 중요하지 않은 아주 단순 코드를 다룰 때만 해당함
실제로 오류가 곧 재앙인 프로덕션 소프트웨어는 여전히 인간의 인지 역량이 병목이며, LLM은 작성에서 검토로 부담을 옮겼기에 오히려 전반 생산성에 마이너스임
이 논의는 평균적 개발자들이 스스로의 생산성을 드러내는 느낌임
프로젝트의 기술을 이해하고, 작업을 잘 분할한다면 코드 복잡도를 미리 예측해서 AI에게 적절한 단위로 일을 시킬 수 있음
AI는 마법이 아니고, 작성 가능한 복잡도의 상한선이 있음
그 한계와 내가 만드는 프로젝트의 기술을 잘 이해하면, 컴포넌트를 해당 한계 아래로 쪼개 AI에게 지시할 수 있음
이 방식이 상당히 잘 작동함
이건 거의 동어반복임
AI가 잘 작동하도록 지시를 단순하게 하면, 당연히 잘 작동함
하지만 실제론 AI에게 지침을 지나치게 세세하게 떠먹여줘야 하고, 그래도 결과물을 꼼꼼히 재확인하며 신뢰할 수 없음
오히려 잘게 쪼개서 AI에게 설명하는 일 자체가 코드를 직접 작성하는 것보다 더 번거로울 수 있음
AI가 운 좋게 단번에 정답을 주면 효율이 있지만, 현실적으로는 반복적으로 수정하거나 결국 다시 다 만들면서 시간과 노력이 낭비됨
AI의 구조화된 보기 좋은 코드가 실제로는 잘못된 경우가 많아 위험함
진짜 어렵고 시간이 걸리는 부분은 복잡한 부분 설계임
사소한 부분은 입력만 하면 되지만, 복잡한 부분을 해결하는 것이 진짜 시간 소모임
이 댓글의 이면에 "나는 평균 이상 개발자라고 생각함?"이라는 뉘앙스를 느낄 수 있음
오히려 반대일 수도 있음
실력 없는 개발자들이 무의미하게 오토 PR만 제출하면서 AI가 만든 결과물에 감탄하는 반면, 눈높이가 높은 개발자는 그 결과물에 감탄하지 않을 수 있음
실제로 직접 같이 일해보지 않으면 신뢰할 수 있는 사람을 구분하기 어렵기에 나는 중립을 유지함
AI도, 인간도 한계가 있음
결국 필요한 건 지루한 프로젝트 관리임
제대로 된 요구사항, 설계, 그리고 충분한 정보를 담아 작은 작업 단위로 쪼개면, AI에게 "깃헙 이슈 #42를 구현해"라고 시키고 TV 보면서 지켜볼 수도 있음
하지만 "facebook 만들어줘"하면 당연히 망하는 흐름임
AI가 또 하나 큰 도움 준 분야는 버그 찾기임
나는 주로 수치 시뮬레이션 작업을 하는데, 며칠이나 묶여있던 문제(몇 개 괄호가 빠진 걸로 인한 식의 스케일 오류)를 chatgpt에 파일과 현상을 설명하니, 금방 원인을 알아냄
AI는 때론 내가 놓친 부분을 명쾌하게 집어주는 역할
이게 10x 개발자를 만들어 주는 건 아니지만, 잘 쓰면 커다란 긍정 효과를 체감함
나도 비슷함
AI로 코드 만들기는 그저 그런 수준이지만, 디버깅은 정말 큰 생산성 도약임
일종의 매우 똑똑한 "러버덕"임
(취미 개발자 관점) LLM 덕분에 밤늦게 머리 안 돌아갈 때 개발이 훨씬 쉬워짐
나도 무수히 많은 시간을 AI 덕에 아꼈음
내겐 10배와 무한대의 중간 어딘가인 느낌임
나는 10x 엔지니어라 생각하지 않음
회사 동료보다 내가 더 생산적인 이유는 시스템 설계와 사업적 요구를 불분명한 티켓 그대로 따르지 않는 것임
AI가 내 동료들을 단순화 못하는 이유는, 애초에 복잡하게 만드는 습관을 바꾸지 못해서임
AI는 이 문제까지 해결해주지 않음
회사에서 내 연봉이 동료와 2배 차이가 안 나니 그렇게 여김
AI 도구 도입한다고 이런 현실은 안 바뀜
이 글은 "10x"라는 너무 높은 기준을 세운 다음, 저자가 그걸 넘으려 한 사적 시도 기록임
그래서 AI 지지자들을 세 부류(착각하는 사람, 판매하는 사람, 불안 심리를 공략하는 악덕 관리자)로 나눴다고 생각함
개인적으로 "환각(hallucination)"에 대한 불평은 약간 "신호"라 여김
환각(hallucination)에 대한 이야기가 꼭 필요하다고 생각함
LLM에 대한 논의가 너무 극단적으로 흘러감(아예 쓸모없다는 쪽 vs 개발자 대체라는 쪽)
예로 Claude 4 Sonnet이 clang 컴파일 관련 내용을 Godbolt가 틀렸다고 잘못 답변한 적 있음
그럼에도 이 세션 전체적으로 큰 도움을 받았으므로, 결과에 비판적이어야 한다는 점만 명심하면 됨
환각은 실제로 존재하고, 결과에 대해 항상 경계해야 함
댓글을 남겨줘서 고맙고, 네가 쓴 AI 관련 글 덕에 임포스터 증후군을 극복하는 데 도움을 받았음
글에서는 "10x 잇달아 성공했다" 주장하는 사람에 한해서 분류한 건데, 모든 AI 지지자를 싸잡아 말한 게 아님
실제로 환각이 아예 없는 방법을 찾았는지 궁금함
특히 Terraform 등에서는 존재하지 않는 프로퍼티를 LLM이 만들어내고, JS 등에서도 드문 라이브러리 사용할 땐 여전히 착각이 잦음
"환각"에 대한 불평이 신호라면, 그런 생각 자체도 신호임…
(짧은 반박)
이 10x 기준은 산업계 공통의 과장 마케팅임
예: Sam Altman의 10x 주장
Cursor AI 생산성 홍보
AI-augmented 10x 개발자
웹앱을 만들 줄 모르는 사람이 6주 동안 하루 4시간씩(120시간) 배우며 겨우 하나를 만든다고 가정
대신 Claude code 등 AI를 활용해 주말 이틀(12시간)에 같은 웹앱을 만든다면 생산성이 10배 상승
이게 실제로 나에게 일어난 일과 비슷함
예전엔 동기부여나 에너지가 부족해 못 하던 일을 AI 덕에 주말동안 해낼 수 있게 됨
하지만 첫 번째 방법은 배우는 과정이 있어서 다음에 뭔가 바꿀 때 도움이 될 수 있음
사실 Claude Code 같은 AI에게 리액트 외로 웹앱 스캐폴딩 시키면 엉망임
앱 개발 경험이 없는 사람이 주말에 완성도 높은 앱을 쉽게 만들진 못함
첫 사용자 로그인만 해도 바로 망가질 수 있음
장기적으로 보면 저 산술이 말이 되지 않는다고 생각함
LLM으로 처음엔 앱을 빠르게 만들지만 점점 유지보수 능력이 떨어지고, 어느 순간 복잡해진 시스템을 더는 “컨텍스트 윈도우”에 담고 관리하지 못함
결과적으로 생산성은 오히려 0에 가까워질 수도 있음
뇌와 학습 경험을 아예 아웃소싱한 거라서, 앱은 생겼지만 성장이나 배움은 거의 없었음
그걸 바로 배포할 생각임?
현실적으로 동일 선상이 아님
1x 개발자 산출물도 측정하기 어렵고, 그걸 곱하는 건 더더욱 무의미함
나는 AI가 "사이드 퀘스트 생산성"을 크게 올려준다고 느낌
그동안 귀찮아서 미뤄두던 일(목업 제작, 테스트 작성, 라이브러리 추출, 문서화 등)에 AI가 최적임
기능을 만드는 시간을 단축시키지는 못해도 부가 작업까지 포함하면 결과물이 조금 더 완벽에 가까워짐
이 부가 작업 덕에 미래에 버그 찾기 시간이 줄었으면 좋겠음
(개인 경험)
내 케이스에 한정된 이야기지만, 우리 회사에선 LLM으로 만든 테스트 코드가 구현 코드와 너무 밀접하게 엮이는 게 일반적임
테스트 스파이 같은 패턴 남용이 심함
그 결과, 사용자 입장에서의 동작 대신 내부 구현 세부사항만 검사하는 애매한 테스트가 많아짐
테스트가 구현 변경에 따라 너무 자주 깨져, 오히려 테스트가 생산성이 아니라 부담임
이는 LLM의 문제만은 아니고, 원래부터 테스트 제대로 못 하는 개발자들이 LLM으로 인해 문제가 더 심해지는 것임
TDD, 잘 설계된 테스트 코드 경험이 부족한 개발자에게 LLM이 이런 안티패턴을 증폭시킴
"사이드 퀘스트 생산성" 표현이 좋음
AI는 "죽음의 천 스침"이 아니라, "천 개의 반창고로 만들어진 새 삶" 느낌임
"사이드 퀘스트" 개념에 찬성함
사실 내가 AI 없이 만들지 않았을 툴이나 기능을, AI 덕에 만들 수 있게 된 게 큰 변화임
단순히 2주를 아끼는 게 아니라, 없던 결과물이 생긴 거임
LLM에 대한 기대가 현실보다 높지만, 실제로 다양한 상황에서 매우 유용함
"줌 레벨"로 보면, "vibe coding"처럼 대충 만드는 수준부터, "이 함수 만들어 줘"까지 단계별로 쪼갤수록 결과가 훨씬 좋았음
코드 생성 외에도 새로운 기술 학습 등 여러 용도에서 효과적임
내 역할이 미팅이 많거나 관리자 업무가 많으면 LLM의 도움은 감소함
앞으로는 PR 워크플로우, 커밋 정리, 순서 재조정 등에도 LLM이 활용될 수 있으리라 생각함