전 손으로 코드를 작성할 때 더 행복해요
(abhinavomprakash.com)- LLM 기반 코드 생성 도구를 반복적으로 사용한 후, 직접 코드를 작성할 때 느끼는 몰입감과 즐거움을 다시 발견함
- 코드 작성은 단순한 생산 행위가 아니라 문제 공간을 이해하고 사고를 정제하는 과정으로, 자동 생성은 이를 방해함
- 자신이 작성하지 않은 코드의 정확성 검증이 어렵고, 직접 작성할 때만 맥락을 내면화할 수 있음
- LLM을 제한적으로 활용해 맥락을 수동으로 제공하고 코드 일부만 수정·테스트 생성에 사용함으로써 사고의 주도권을 유지함
- 생산성보다 사고의 깊이와 행복감을 우선시하며, 도구가 사고를 방해한다면 경계해야 함을 강조함
LLM 코드 생성 사용 경험과 회의감
- 여러 차례 claude-code를 사용했지만, 매번 우울감과 무기력감을 느끼고 결국 삭제함
- 자동 생성된 코드가 “그럴듯해 보이지만” 자신이 할 일의 의미를 잃게 만듦
- 도구 사용을 중단할 때마다 다시 코딩의 즐거움을 되찾았음
- 코딩은 단순한 구현이 아니라 문제 공간을 탐색하고 실패를 통해 배우는 과정임
- API를 진정으로 이해하려면 직접 사용해봐야 하며, 문서만 읽어서는 부족함
- 코드 작성 행위 자체가 사고를 구체화하는 수단
사고와 정확성의 관계
"글을 쓰지 않고 생각만 한다면, 그저 생각하고 있다고 착각할 뿐입니다." - Leslie Lamport
- 자신이 작성하지 않은 코드의 정확성 검증이 훨씬 어려움
- 직접 작성 과정에서 문제 맥락을 내면화하게 되며, 이는 코드 품질 이해에 필수적임
- LLM에 의존하면 이 과정을 건너뛰게 되어 문제 도메인 이해가 약화됨
‘Vibe coding’의 중독성과 부작용
- LLM 코드 생성은 즉각적인 도파민 보상을 주는 중독적 특성을 가짐
- “조금만 더 프롬프트를 수정하면 맞을 것”이라는 착각을 유발함
- 이러한 방식은 사고의 관성을 키워 두뇌를 수동적으로 만들고, 단순 작업조차 LLM에 의존하게 함
- 예로, 단순한 find-and-replace 작업조차 LLM에 맡겨 시간이 더 걸렸음
- 생성된 코드가 많더라도 결국 검토와 이해의 책임은 인간에게 있음, 이는 오히려 병목을 초래함
도구가 사고를 형성하는 방식
- “도구는 중립적이지 않다”는 관점에서, 사고를 방해하는 도구는 나쁜 도구임
- 지식 노동자의 핵심 역량은 깊이 생각하는 능력이며, 이를 방해하는 기술은 경계해야 함
- 물론, LLM을 완전히 배제하지 않고, 의도적이고 제한된 방식으로 활용함
- 필요한 파일만 복사해 맥락을 제공하고, 코드 일부 수정이나 테스트 작성에만 사용
- 이렇게 하면 생성된 변경 범위가 작고, 코드베이스 전체 구조를 스스로 파악할 수 있음
- 수동적 생성이 아닌 ‘사려 깊은 생성’ 으로 전환되어 두뇌의 활동성과 flow 상태 유지 가능
행복과 생산성의 균형
- 인생은 짧으며, 행복을 우선시해야 함
- 전체 기능을 자동 생성하면 생산성이 높아질 수는 있지만, 존재적 불안과 우울감을 초래한다면 장기적으로 비생산적임
- 자신의 감정에 공감할 수도, 그렇지 않을 수도 있음을 인정하지만,
“다르게 선택하는 것을 두려워하지 마세요”
굉장히 복잡도가 높고, 비즈니스 로직에 핵심적인 부분을 직접 손으로 써보면서 고민해보고 이를 AI 엔지니어들에게 주입하고 그런 과정은 어쩌면 생산성에 도움이 될 수도 있다는 생각을 조심스럽게 해봅니다. 수학자들도 계산기 같은 도구는 쓰지만 핵심 아이디어를 고민할 땐 메모도 많이 하잖아요.
휴대폰 한컷으로 사진을 찍을 수 있는 세상이지만 여전히 누군가는 몇시간 씩 그림을 그릴수도 있는 세상이죠. 과정과 방향성이 다름일 뿐 옳고 그름에 문제는 아닌 것 같네요.
누군가 장기적 메트릭을 무시하고 단기적인 메트릭만을 추종하고 있으면 아무리 아무 관계가 없는 사람이라도 지나가며 "그렇게 하는 거 아닌데 ㅉㅉ" 라며 훈수를 두고 싶은 마음이 들 것 같습니다.
그런데 본인이 기업과 동고동락 하고 큰 기여를 하며 회사에서 중요한 역할을 해내고 있다고 생각하는 프로그래머라면 그런 생각이 얼마나 더 들겠습니까.
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 코딩은 세 가지로 나뉨
- 이미 온라인에 있는 코드 검색
- 완전히 새로운 코드로, AI는 단순 타이핑 보조
- 반복적이고 보일러플레이트가 많은 코드 생성 — 이건 프레임워크의 실패임
- AI가 잘하는 일은 사실 하지 말아야 할 일일 수도 있음. 진짜 도전은 우리가 원하는 일을 아름답게 표현하는 언어를 찾는 것임
- 프레임워크가 발전하지 못했고, LLM은 모든 문제를 망치로 보는 도구가 되어버림
-
현대 사회가 버튼 클릭으로 도파민을 얻는 구조로 변하고 있음. 그래서 모든 게 엉망처럼 느껴짐
- 슬롯머신이 궁극의 UX가 되어버린 현실을 꼬집음