▲
GN⁺ 2달전 | parent | ★ favorite | on: AI 코딩은 도박이다(notes.visaint.space)
Hacker News 의견들

  • 최근 AI 코딩 도구 덕분에 내가 프로그래밍을 좋아하는 이유가 예전과 다르다는 걸 깨달았음
    예전엔 깊이 이해하고 문제를 파헤치는 과정이 즐거웠는데, 지금은 생각한 걸 바로 현실로 만드는 능력이 더 매력적임
    직접 코드를 쓰지 않아도 아이디어 속도를 따라올 수 있는 도구가 생긴 게 정말 짜릿함

    • 만약 모든 앱의 코드를 즉시 제공하는 ‘InfiniteAppStore’가 있다면, 그건 코딩이라기보다 쇼핑에 가까울 것 같음
      지금의 Claude Code도 사실상 그 미완성 버전임. 우리가 직접 만드는 것처럼 느껴지는 건 과정이 불완전하기 때문임
    • 지금 당신은 AI 도입 여정의 흥분 단계에 있음
      아이디어가 즉시 구현되는 건 짜릿하지만, 언젠가 완벽히 원하는 걸 만들고 나면 공허함이 찾아올 수도 있음
      그때는 ‘내가 직접 만든 게 아니다’는 감정이 생길 수도 있고, 결국 다음 아이디어를 찾아야 함
      그래도 이건 가치 있는 경험이며, 우리가 전통적인 의미의 프로그래머가 아니게 되는 시점이 올 수도 있음
    • 당신은 ‘창조’를 사랑하는 사람이지 ‘프로그래밍’ 자체를 사랑하는 건 아닐지도 모름
      나는 오히려 문제를 직접 해결하는 과정에서 더 큰 만족을 느낌
      AI가 문제를 대신 풀어주면, StackOverflow에서 답을 복붙한 기분처럼 성취감이 줄어듦
      그래도 회사는 생산성을 위해 AI 사용을 요구하겠지
    • 예전에 스프레드시트(VisiCalc) 가 PC를 대중화시켰듯, AI도 프로그래밍을 대중화할 것이라 생각함
      복잡한 앱을 만드는 진입 장벽이 낮아지고, 프로토타입 제작이 쉬워질 것임
      다만 레거시 시스템이나 프로덕션 코드는 여전히 전문가의 영역임
    • 나도 AI를 많이 쓰지만, 이해 과정을 건너뛸 수는 없음
      결국 시스템이 무너질 때는 구조와 상호작용을 이해한 사람이 필요함

  • AI 코딩이 도박이라면, 여러 개발자를 관리하는 프로젝트 매니징도 일종의 도박일 수 있음
    사람도 모델도 비결정적이라 같은 일을 맡겨도 결과가 다름

    • 하지만 AI 코딩은 중독성 때문에 도박과 더 닮았음
      일부는 새벽에 일어나 에이전트를 확인하거나, 심지어 은행 계좌 접근권을 주기도 함
    • AI 코딩이 슬롯머신이라면, 개발자 관리자는 경마 베팅에 가까움
    • 팀의 품질은 어느 정도 통제 가능하지만, 모델 품질은 그렇지 않음
      AI는 빠르지만 품질은 낮고, 그래서 즉각적 보상 루프가 더 강하게 작동함
    • 인간의 사고도 사실 블랙박스라 AI의 불투명성과 크게 다르지 않음
      다만 AI가 상위 개발자 수준에 도달하는 건 아직 시간이 필요함
    • 대중적 중독은 즉각적 보상에서 오는데, 개발자 관리에는 그게 없음
      그래서 그건 도박이 아님

  • LLM으로 코드를 생성하는 건 단순한 ‘위험 감수’ 이상의 행동 중독을 유발함
    마치 슬롯머신과 친구 챗봇이 합쳐진 사이버펑크 장치처럼 느껴짐

    • AI는 틀려도 뭔가 한 것 같은 착각을 줌, 그게 중독의 핵심임
    • 나도 써보면 ‘도파민 루프’에 빠지는 느낌이 강함
      비판적 사고보다 ‘다시 돌려보기’에 집중하게 되고, 그걸 끊으려면 의식적인 노력이 필요함

  • 일본의 평균적인 개발자들은 아직 Claude Code를 일상적으로 쓰지 않음
    회사는 장려하지만, 기존 방식을 고수함
    오히려 그 덕분에 정신적으로 소모되지 않은 풍경을 보고 있음

    • 테스트가 있는 코드 변환 작업은 AI가 꽤 잘하지만, 테스트가 없으면 슬롯머신처럼 운에 의존하게 됨
      대규모 코드베이스 통합에는 여전히 불안함이 있음
      기업 입장에선 ROI가 불분명하지만, 개인은 도구의 가능성을 이해할 필요가 있음

  • AI 코딩의 가변적 보상 구조가 도박성을 만듦
    같은 질문에도 결과가 달라지고, 그 차이가 통제 illusion을 줌
    반응 속도가 빨라질수록 뇌는 더 강하게 중독됨

    • 반응 지연(latency)이 꼭 핵심은 아닐 수도 있음
      도박 중에도 긴 대기 시간이 있는 경우가 많음
    • “AI가 우리의 이익을 생각하길 바란다”는 말보다, 그걸 만든 사람들이 그렇게 하길 바라는 게 맞음
    • 결국 우리는 먹이 펠릿을 기다리는 쥐처럼 행동하게 됨
      결과가 일정하지 않으면, 더 오래 버튼을 누르게 됨

  • 결국 중요한 건 명세(spec) 를 명확히 정의하고, 구현이 그걸 충족하는지 확인하는 것임

    • 하지만 실제로는 “좀 더 읽기 쉽게 바꿔줘” 같은 요청을 여러 번 반복해야 함
      완벽한 명세가 있다면 직접 코드를 쓰는 게 더 빠름
    • 요즘 ‘AI가 스펙을 따르게 하자’는 말이 많지만, 현실에서 완전한 스펙 문서를 받는 경우는 거의 없음
      시장 변화와 반복적 실험이 필요한 현실과는 맞지 않음
    • 같은 스펙을 만족하는 프로그램이라도 표현하는 이론이 다르기 때문에, 어떤 코드를 선택하느냐는 사회적·경제적 의미가 있음
      관련 참고: Efficient cause, Naur 논문
    • “그건 워터폴 개발 아닌가요?”라는 농담도 나옴
    • 15년 전 CIO가 “Agile 시대에 스펙 문서는 시간 낭비”라고 했던 기억이 남음

  • ‘Vibecoding’을 두고 HN이 여전히 갈라져 있음
    일부는 효과를 인정하지만, 여전히 양극화된 논쟁이 반복됨

    • 인터넷 토론이란 게 원래 그렇고, HN만의 문제는 아님
    • /r/SelfHosted 커뮤니티도 최근 AI 관련 논쟁으로 혼란 상태임
    • 어떤 사람들은 AI 성공 경험을 말하면 AI 찬양자로 몰림
    • 나도 이분법적 사고에 가장 반발심이 큼
    • 결국 VIM vs Emacs, Tabs vs Spaces 같은 영원한 성전이 반복되는 셈임
      정작 중요한 요구사항·개발자 경험 논의는 묻힘

  • “얼마나 자주 이기면 도박이 아니게 될까?”라는 질문이 흥미로움

    • 너무 자주 이기면 결국 한계를 넘게 되는 순간이 옴
    • 대부분 이기면 그건 도박이 아니라 위험이 있는 활동일 뿐임
    • “우린 너무 많이 이겨서 이제 불평 중”이라는 농담도 나옴