AI 코딩은 도박이다
(notes.visaint.space)- AI 코딩 도구의 즉각적 결과 생성 능력은 인상적이지만, 세부 구현과 시스템 구성 요소의 완성도는 여전히 부족함
- 개발 과정이 ‘생각과 작성’의 균형에서 벗어나, AI에 사고를 위임하고 최소한의 코드만 작성하는 형태로 변함
- 이러한 행위는 ‘슬롯머신을 당기는 도박’ 과 유사하며, 기술 산업 전반의 중독적 메커니즘과 닮아 있음
- AI는 영감을 얻고 코드를 재활용하기 쉽게 만들지만, 창의적 연결과 문제 해결의 즐거움을 빼앗음
- 결과적으로 개발자는 효율보다 자기 성찰과 코드와의 직접적 상호작용 회복이 필요함
AI 코딩의 표면적 효율과 한계
- AI는 즉시 그럴듯한 코드 결과물을 생성하지만, 세부 구현의 정확성과 완성도는 부족함
- 겉보기에는 완성된 코드처럼 보여도, 실제로는 오류나 불완전한 부분이 많음
- AI가 코드를 ‘처리하는 척’만 해도 결과가 나오는 경우가 많아, 개발자의 사고 과정이 생략되는 구조로 변함
- 이러한 방식은 기존의 ‘깊은 사고와 세밀한 작성’이 필요한 코딩과는 다른 행위로, 표면적 생산성 중심의 작업 형태로 전환됨
도박으로서의 AI 코딩
- AI 코딩은 ‘슬롯머신을 당기는 행위’ 처럼 반복적이고 즉각적 보상을 추구하는 구조와 유사함
- 사용자는 명령을 입력하고 결과를 기다리는 과정에서 도박적 기대감을 경험함
- 기술 산업 전반이 이미 ‘새로고침’과 같은 반복적 보상 구조를 내재화하고 있으며, AI는 이를 극대화한 형태로 작동함
- 이러한 중독성은 AI 코딩이 단순히 효율적 도구를 넘어 심리적 의존성을 유발하는 메커니즘으로 작용함
창의성과 만족감의 상실
- 개발자는 작업을 ‘영혼에 좋은 일’과 ‘그렇지 않은 일’ 로 구분하며, 코딩은 전통적으로 전자에 속함
- AI는 무한한 참고 자료와 영감을 제공하지만, 직접 문제를 해결하고 구조를 이해하는 과정의 즐거움을 빼앗음
- 결과적으로 개발자는 AI가 만든 불완전한 연결을 보완하는 역할로 전락하며, 작업의 만족감이 감소함
- 이 문제의 해결은 개발자의 태도 변화와 적극적 코드 참여에 달려 있음
개인적 맥락과 직업적 정체성
- 작성자는 소규모 팀 또는 단독 개발 환경에서 일하며, 코드 재사용과 최적화에 익숙한 개발자이자 디자이너임
- AI는 새로운 프레임워크를 시도하고 자신감을 높이는 계기가 되었지만, 실제로 더 나은 개발자로 만들었는지는 의문임
- AI 사용이 효율 향상 때문인지, 아니면 ‘잭팟을 기다리는 도박적 반복’ 때문인지를 스스로 되묻는 구조임
결론: AI 시대의 개발자 역할
- AI 코딩은 생산성을 높이지만, 창의적 사고와 자기 주도적 문제 해결 능력을 약화시킬 위험이 있음
- 개발자는 AI의 편의성에 의존하기보다, 직접 사고하고 코드를 다루는 과정의 가치를 회복해야 함
- 기술적 진보보다 중요한 것은 ‘코딩이 영혼에 좋은 일’로 남게 하는 자기 통제와 성찰임
통계적으로 일정 이상의 확률이고, 기대값이 양수이고, 기댓값을 높이기 위한 공학적인 방법들이 쉴새없이 나오고 있다면 이걸 도박이라고 불러야 할까요? 사회적으로 우린 이걸 투자라고 부르기로 약속한것 같은데요.
Hacker News 의견들
-
최근 AI 코딩 도구 덕분에 내가 프로그래밍을 좋아하는 이유가 예전과 다르다는 걸 깨달았음
예전엔 깊이 이해하고 문제를 파헤치는 과정이 즐거웠는데, 지금은 생각한 걸 바로 현실로 만드는 능력이 더 매력적임
직접 코드를 쓰지 않아도 아이디어 속도를 따라올 수 있는 도구가 생긴 게 정말 짜릿함- 만약 모든 앱의 코드를 즉시 제공하는 ‘InfiniteAppStore’가 있다면, 그건 코딩이라기보다 쇼핑에 가까울 것 같음
지금의 Claude Code도 사실상 그 미완성 버전임. 우리가 직접 만드는 것처럼 느껴지는 건 과정이 불완전하기 때문임 - 지금 당신은 AI 도입 여정의 흥분 단계에 있음
아이디어가 즉시 구현되는 건 짜릿하지만, 언젠가 완벽히 원하는 걸 만들고 나면 공허함이 찾아올 수도 있음
그때는 ‘내가 직접 만든 게 아니다’는 감정이 생길 수도 있고, 결국 다음 아이디어를 찾아야 함
그래도 이건 가치 있는 경험이며, 우리가 전통적인 의미의 프로그래머가 아니게 되는 시점이 올 수도 있음 - 당신은 ‘창조’를 사랑하는 사람이지 ‘프로그래밍’ 자체를 사랑하는 건 아닐지도 모름
나는 오히려 문제를 직접 해결하는 과정에서 더 큰 만족을 느낌
AI가 문제를 대신 풀어주면, StackOverflow에서 답을 복붙한 기분처럼 성취감이 줄어듦
그래도 회사는 생산성을 위해 AI 사용을 요구하겠지 - 예전에 스프레드시트(VisiCalc) 가 PC를 대중화시켰듯, AI도 프로그래밍을 대중화할 것이라 생각함
복잡한 앱을 만드는 진입 장벽이 낮아지고, 프로토타입 제작이 쉬워질 것임
다만 레거시 시스템이나 프로덕션 코드는 여전히 전문가의 영역임 - 나도 AI를 많이 쓰지만, 이해 과정을 건너뛸 수는 없음
결국 시스템이 무너질 때는 구조와 상호작용을 이해한 사람이 필요함
- 만약 모든 앱의 코드를 즉시 제공하는 ‘InfiniteAppStore’가 있다면, 그건 코딩이라기보다 쇼핑에 가까울 것 같음
-
AI 코딩이 도박이라면, 여러 개발자를 관리하는 프로젝트 매니징도 일종의 도박일 수 있음
사람도 모델도 비결정적이라 같은 일을 맡겨도 결과가 다름- 하지만 AI 코딩은 중독성 때문에 도박과 더 닮았음
일부는 새벽에 일어나 에이전트를 확인하거나, 심지어 은행 계좌 접근권을 주기도 함 - AI 코딩이 슬롯머신이라면, 개발자 관리자는 경마 베팅에 가까움
- 팀의 품질은 어느 정도 통제 가능하지만, 모델 품질은 그렇지 않음
AI는 빠르지만 품질은 낮고, 그래서 즉각적 보상 루프가 더 강하게 작동함 - 인간의 사고도 사실 블랙박스라 AI의 불투명성과 크게 다르지 않음
다만 AI가 상위 개발자 수준에 도달하는 건 아직 시간이 필요함 - 대중적 중독은 즉각적 보상에서 오는데, 개발자 관리에는 그게 없음
그래서 그건 도박이 아님
- 하지만 AI 코딩은 중독성 때문에 도박과 더 닮았음
-
LLM으로 코드를 생성하는 건 단순한 ‘위험 감수’ 이상의 행동 중독을 유발함
마치 슬롯머신과 친구 챗봇이 합쳐진 사이버펑크 장치처럼 느껴짐- AI는 틀려도 뭔가 한 것 같은 착각을 줌, 그게 중독의 핵심임
- 나도 써보면 ‘도파민 루프’에 빠지는 느낌이 강함
비판적 사고보다 ‘다시 돌려보기’에 집중하게 되고, 그걸 끊으려면 의식적인 노력이 필요함
-
일본의 평균적인 개발자들은 아직 Claude Code를 일상적으로 쓰지 않음
회사는 장려하지만, 기존 방식을 고수함
오히려 그 덕분에 정신적으로 소모되지 않은 풍경을 보고 있음- 테스트가 있는 코드 변환 작업은 AI가 꽤 잘하지만, 테스트가 없으면 슬롯머신처럼 운에 의존하게 됨
대규모 코드베이스 통합에는 여전히 불안함이 있음
기업 입장에선 ROI가 불분명하지만, 개인은 도구의 가능성을 이해할 필요가 있음
- 테스트가 있는 코드 변환 작업은 AI가 꽤 잘하지만, 테스트가 없으면 슬롯머신처럼 운에 의존하게 됨
-
AI 코딩의 가변적 보상 구조가 도박성을 만듦
같은 질문에도 결과가 달라지고, 그 차이가 통제 illusion을 줌
반응 속도가 빨라질수록 뇌는 더 강하게 중독됨- 반응 지연(latency)이 꼭 핵심은 아닐 수도 있음
도박 중에도 긴 대기 시간이 있는 경우가 많음 - “AI가 우리의 이익을 생각하길 바란다”는 말보다, 그걸 만든 사람들이 그렇게 하길 바라는 게 맞음
- 결국 우리는 먹이 펠릿을 기다리는 쥐처럼 행동하게 됨
결과가 일정하지 않으면, 더 오래 버튼을 누르게 됨
- 반응 지연(latency)이 꼭 핵심은 아닐 수도 있음
-
결국 중요한 건 명세(spec) 를 명확히 정의하고, 구현이 그걸 충족하는지 확인하는 것임
- 하지만 실제로는 “좀 더 읽기 쉽게 바꿔줘” 같은 요청을 여러 번 반복해야 함
완벽한 명세가 있다면 직접 코드를 쓰는 게 더 빠름 - 요즘 ‘AI가 스펙을 따르게 하자’는 말이 많지만, 현실에서 완전한 스펙 문서를 받는 경우는 거의 없음
시장 변화와 반복적 실험이 필요한 현실과는 맞지 않음 - 같은 스펙을 만족하는 프로그램이라도 표현하는 이론이 다르기 때문에, 어떤 코드를 선택하느냐는 사회적·경제적 의미가 있음
관련 참고: Efficient cause, Naur 논문 - “그건 워터폴 개발 아닌가요?”라는 농담도 나옴
- 15년 전 CIO가 “Agile 시대에 스펙 문서는 시간 낭비”라고 했던 기억이 남음
- 하지만 실제로는 “좀 더 읽기 쉽게 바꿔줘” 같은 요청을 여러 번 반복해야 함
-
‘Vibecoding’을 두고 HN이 여전히 갈라져 있음
일부는 효과를 인정하지만, 여전히 양극화된 논쟁이 반복됨- 인터넷 토론이란 게 원래 그렇고, HN만의 문제는 아님
- /r/SelfHosted 커뮤니티도 최근 AI 관련 논쟁으로 혼란 상태임
- 어떤 사람들은 AI 성공 경험을 말하면 AI 찬양자로 몰림
- 나도 이분법적 사고에 가장 반발심이 큼
- 결국 VIM vs Emacs, Tabs vs Spaces 같은 영원한 성전이 반복되는 셈임
정작 중요한 요구사항·개발자 경험 논의는 묻힘
-
“얼마나 자주 이기면 도박이 아니게 될까?”라는 질문이 흥미로움
- 너무 자주 이기면 결국 한계를 넘게 되는 순간이 옴
- 대부분 이기면 그건 도박이 아니라 위험이 있는 활동일 뿐임
- “우린 너무 많이 이겨서 이제 불평 중”이라는 농담도 나옴