▲

전 손으로 코드를 작성할 때 더 행복해요

 (abhinavomprakash.com)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • LLM 기반 코드 생성 도구를 반복적으로 사용한 후, 직접 코드를 작성할 때 느끼는 몰입감과 즐거움을 다시 발견함
  • 코드 작성은 단순한 생산 행위가 아니라 문제 공간을 이해하고 사고를 정제하는 과정으로, 자동 생성은 이를 방해함
  • 자신이 작성하지 않은 코드의 정확성 검증이 어렵고, 직접 작성할 때만 맥락을 내면화할 수 있음
  • LLM을 제한적으로 활용해 맥락을 수동으로 제공하고 코드 일부만 수정·테스트 생성에 사용함으로써 사고의 주도권을 유지함
  • 생산성보다 사고의 깊이와 행복감을 우선시하며, 도구가 사고를 방해한다면 경계해야 함을 강조함

LLM 코드 생성 사용 경험과 회의감

  • 여러 차례 claude-code를 사용했지만, 매번 우울감과 무기력감을 느끼고 결국 삭제함
    • 자동 생성된 코드가 “그럴듯해 보이지만” 자신이 할 일의 의미를 잃게 만듦
    • 도구 사용을 중단할 때마다 다시 코딩의 즐거움을 되찾았음
  • 코딩은 단순한 구현이 아니라 문제 공간을 탐색하고 실패를 통해 배우는 과정임
    • API를 진정으로 이해하려면 직접 사용해봐야 하며, 문서만 읽어서는 부족함
    • 코드 작성 행위 자체가 사고를 구체화하는 수단

사고와 정확성의 관계

"글을 쓰지 않고 생각만 한다면, 그저 생각하고 있다고 착각할 뿐입니다." - Leslie Lamport

  • 자신이 작성하지 않은 코드의 정확성 검증이 훨씬 어려움
  • 직접 작성 과정에서 문제 맥락을 내면화하게 되며, 이는 코드 품질 이해에 필수적임
  • LLM에 의존하면 이 과정을 건너뛰게 되어 문제 도메인 이해가 약화됨

‘Vibe coding’의 중독성과 부작용

  • LLM 코드 생성은 즉각적인 도파민 보상을 주는 중독적 특성을 가짐
    • “조금만 더 프롬프트를 수정하면 맞을 것”이라는 착각을 유발함
  • 이러한 방식은 사고의 관성을 키워 두뇌를 수동적으로 만들고, 단순 작업조차 LLM에 의존하게 함
    • 예로, 단순한 find-and-replace 작업조차 LLM에 맡겨 시간이 더 걸렸음
  • 생성된 코드가 많더라도 결국 검토와 이해의 책임은 인간에게 있음, 이는 오히려 병목을 초래함

도구가 사고를 형성하는 방식

  • “도구는 중립적이지 않다”는 관점에서, 사고를 방해하는 도구는 나쁜 도구임
    • 지식 노동자의 핵심 역량은 깊이 생각하는 능력이며, 이를 방해하는 기술은 경계해야 함
  • 물론, LLM을 완전히 배제하지 않고, 의도적이고 제한된 방식으로 활용함
    • 필요한 파일만 복사해 맥락을 제공하고, 코드 일부 수정이나 테스트 작성에만 사용
    • 이렇게 하면 생성된 변경 범위가 작고, 코드베이스 전체 구조를 스스로 파악할 수 있음
    • 수동적 생성이 아닌 ‘사려 깊은 생성’ 으로 전환되어 두뇌의 활동성과 flow 상태 유지 가능

행복과 생산성의 균형

  • 인생은 짧으며, 행복을 우선시해야 함
    • 전체 기능을 자동 생성하면 생산성이 높아질 수는 있지만, 존재적 불안과 우울감을 초래한다면 장기적으로 비생산적임
  • 자신의 감정에 공감할 수도, 그렇지 않을 수도 있음을 인정하지만,
    “다르게 선택하는 것을 두려워하지 마세요”
▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 코딩을 목공예에 비유함. 기계가 가구를 만들 수 있어도 여전히 손으로 만드는 사람은 있음. 손코딩도 마찬가지로 즐거움을 위해 할 수는 있지만, 앞으로는 직업적으로는 어려워질 것임

    • 이 비유는 잘 맞지 않다고 느낌. 전동톱은 인간이 주도하는 센타우르 기술이지만, GenAI는 반대로 인간이 보조하는 역센타우르 기술임. 전동톱은 사람을 대체하지 않지만, AI는 팀 절반을 줄일 수도 있음
    • 목공예는 동일한 제품을 반복 생산하지만, 코드는 반복되지 않음. 대부분의 프로젝트는 요구사항 수집이나 설계가 병목이므로 손코딩과 AI코딩의 생산성 차이는 제한적임
    • 자연어→코드 전환이 고급 언어→어셈블리 전환과 비슷한지 질문함. Brooks의 ‘본질적 복잡성’ 이 사라지고, 표준화된 패턴 덕분에 AI가 모호한 의도를 실행 가능한 코드로 바꾸는 시대가 오고 있음. 결국 전문가의 가치는 높아지지만, 표준 엔지니어의 수요는 줄어듦
    • “손코딩을 더 이상 직업적으로 못 한다면, 우리는 무엇을 위해 급여를 받는가?”라는 질문을 던짐. 고객 응대나 LLM 프롬프트 작성자로 전락하는 것인지 의문을 제기함
    • 손코딩이 더 이상 가치 있게 평가되지 않는다면 슬플 것임. 여전히 즐겁지만, 가치 하락이 마음 아픔

  • 나는 장기적으로 가장 빠르고 좋은 결과를 주는 방식을 택함. 지금은 neovim과 손코딩이 그 역할을 함. 직접 타이핑하며 프로젝트를 깊이 이해하면 장기적으로 더 빠르게 기능을 낼 수 있음. 학습에 도움이 안 되는 일은 LLM에 맡기지만, 그런 일이 많아서 LLM 사용률은 높음

    • “깊은 이해가 장기적으로 속도를 높인다”는 관점이 인상적임
    • 나도 같은 방식으로 일하고 있음. 6개월이 아니라 2년 후를 최적화해야 한다고 팀에 조언함
    • 배움이 있는 영역만 직접 하고, 나머지는 최대한 자동화하려 함
    • 여러 에이전트를 쓰면 맥락 전환이 많아지고, 오히려 전체 맥락을 잃는 느낌임

  • vibecoding의 문제는 ‘기분이 좋다’는 감정이 실제 성과를 흐리게 만든다는 점임

    • 어떤 사람에게만 기분이 좋을 뿐, 나는 문제와 코드의 깊은 이해에서 즐거움을 느낌
    • “vibe doc 읽기”는 좋지만, vibe coding은 코드가 장황하고 추상화가 과도해 이해하기 어렵고, 내 이름을 걸기 꺼려짐
    • 계획을 세워도 결국 다시 처음부터 해야 하는 경우가 많아 허무함
    • 실제로 생산성이 높아졌는지, 단지 그렇게 느끼는지 구분하기 어려움
    • Windows Copilot으로 실험했지만 느리고 품질이 낮아 즐거움이 없었음

  • “행복하다고 해서 코드 생산량이 200배 늘어나는가?”라는 냉소적 질문을 던짐

  • AI의 가치는 분명 있음. 예를 들어 300컬럼짜리 DB 테이블을 Rust struct로 변환할 때, 15단어 프롬프트로 900줄 코드를 생성함. 이런 반복 작업엔 AI가 완벽함. 하지만 모든 걸 맡기고 싶진 않음. 행복한 사용 수준에서만 씀

    • 이런 접근은 나쁜 스키마나 설계를 개선하지 못하게 만들 수 있음
    • Python으로 코드 생성 스크립트를 짜는 게 더 낫다고 느낌. AI가 미묘하게 필드명을 바꾸는 등 신뢰성 문제 있음
    • 인간이 커피를 마시며 코딩하는 데 드는 에너지 비용이 AI보다 훨씬 큼
    • AI 사용이 도파민 중독처럼 느껴짐

  • “LLM이 코드를 대신 써주는 동안 나는 무엇을 하나?”라는 질문이 핵심임. LLM은 완전히 맡길 수 없고, 옆에서 돌보는 느낌임. 주니어 개발자는 성장하지만, LLM은 학습하지 않음. 그래서 멘토링의 보람이 사라진 느낌임

    • 나는 동시에 여러 에이전트를 돌리며 기능 개발, 버그 수정, 문서 업데이트를 병행함. 할 일은 여전히 많음, doomscroll은 아님

  • 요즘 개발자 채용이 어떻게 변했는지 궁금함. LLM 사용이 허용되는지, 여전히 손코딩을 요구하는지 의문임

    • 대기업은 아직 변화가 느림. 법적 소유권 문제 때문에 AI 코드 사용을 주저함
    • 앞으로는 손코딩과 AI코딩 둘 다 요구될 것임. 채용은 늘 그래왔듯 또 하나의 관문이 추가될 뿐임
    • 중견기업은 채용을 멈추거나 AI를 쓰는 개발자만 뽑음. 대기업은 여전히 Leetcode와 시스템 설계를 요구함
    • 대부분의 회사는 아직 LLM 부정행위의 범위를 인식하지 못함

  • 나는 LLM 이전부터 모델 기반 개발(MDD) 로 vibecoding 수준의 속도로 개발해왔음. 데이터 모델이 곧 애플리케이션이며, LLM은 그 위에서 절차를 조금 더 빨리 써줄 뿐임. 데이터 모델의 방향성은 여전히 내가 결정함

  • AI 코딩은 세 가지로 나뉨

    1. 이미 온라인에 있는 코드 검색
    2. 완전히 새로운 코드로, AI는 단순 타이핑 보조
    3. 반복적이고 보일러플레이트가 많은 코드 생성 — 이건 프레임워크의 실패임
    • AI가 잘하는 일은 사실 하지 말아야 할 일일 수도 있음. 진짜 도전은 우리가 원하는 일을 아름답게 표현하는 언어를 찾는 것임
    • 프레임워크가 발전하지 못했고, LLM은 모든 문제를 망치로 보는 도구가 되어버림

  • 현대 사회가 버튼 클릭으로 도파민을 얻는 구조로 변하고 있음. 그래서 모든 게 엉망처럼 느껴짐

    • 슬롯머신이 궁극의 UX가 되어버린 현실을 꼬집음
답변달기