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

> Clean Markdown view of GeekNews topic #26522. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26522](https://news.hada.io/topic?id=26522)
- GeekNews Markdown: [https://news.hada.io/topic/26522.md](https://news.hada.io/topic/26522.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-02-09T09:47:49+09:00
- Updated: 2026-02-09T09:47:49+09:00
- Original source: [abhinavomprakash.com](https://www.abhinavomprakash.com/posts/i-am-happier-writing-code-by-hand/)
- Points: 15
- Comments: 14

## Summary

**LLM 코드 생성 도구**가 개발자의 사고 방식에 어떤 변화를 가져오는지에 대한 성찰을 담은 글입니다. 자동 생성 코드는 생산성을 높이지만, 문제를 깊이 이해하고 사고를 정제하는 과정—즉 코딩 과정에서 느끼는 몰입과 성취감—을 약화시킬 수 있다는 지적인데요. 작성자는 LLM을 전면 배제하기보다, **맥락은 직접 설계하고 일부 수정·테스트 생성에만 활용**하는 방식으로 사고의 주도권을 유지하려는 접근을 제안하며, 생산성 극대화가 아니라 사고의 깊이와 작업 만족도를 함께 고려해야 한다는 관점을 하나의 균형점으로 제시합니다.

## Topic Body

- **LLM 기반 코드 생성 도구**를 반복적으로 사용한 후, 직접 코드를 작성할 때 느끼는 **몰입감과 즐거움**을 다시 발견함  
- 코드 작성은 단순한 생산 행위가 아니라 **문제 공간을 이해하고 사고를 정제하는 과정**으로, 자동 생성은 이를 방해함  
- **자신이 작성하지 않은 코드의 정확성 검증**이 어렵고, 직접 작성할 때만 맥락을 내면화할 수 있음  
- LLM을 제한적으로 활용해 **맥락을 수동으로 제공하고 코드 일부만 수정·테스트 생성**에 사용함으로써 사고의 주도권을 유지함  
- 생산성보다 **사고의 깊이와 행복감**을 우선시하며, 도구가 사고를 방해한다면 경계해야 함을 강조함  
  
---  
  
### LLM 코드 생성 사용 경험과 회의감  
- 여러 차례 **claude-code**를 사용했지만, 매번 **우울감과 무기력감**을 느끼고 결국 삭제함  
  - 자동 생성된 코드가 “그럴듯해 보이지만” 자신이 할 일의 의미를 잃게 만듦  
  - 도구 사용을 중단할 때마다 다시 **코딩의 즐거움**을 되찾았음  
- 코딩은 단순한 구현이 아니라 **문제 공간을 탐색하고 실패를 통해 배우는 과정**임  
  - API를 진정으로 이해하려면 직접 사용해봐야 하며, 문서만 읽어서는 부족함  
  - 코드 작성 행위 자체가 **사고를 구체화하는 수단**  
  
### 사고와 정확성의 관계  
> "글을 쓰지 않고 생각만 한다면, 그저 생각하고 있다고 착각할 뿐입니다." - Leslie Lamport  
- 자신이 작성하지 않은 코드의 **정확성 검증이 훨씬 어려움**  
- 직접 작성 과정에서 문제 맥락을 내면화하게 되며, 이는 코드 품질 이해에 필수적임  
- LLM에 의존하면 이 과정을 건너뛰게 되어 **문제 도메인 이해가 약화**됨  
  
### ‘Vibe coding’의 중독성과 부작용  
- LLM 코드 생성은 **즉각적인 도파민 보상**을 주는 중독적 특성을 가짐  
  - “조금만 더 프롬프트를 수정하면 맞을 것”이라는 착각을 유발함  
- 이러한 방식은 **사고의 관성**을 키워 두뇌를 수동적으로 만들고, 단순 작업조차 LLM에 의존하게 함  
  - 예로, 단순한 find-and-replace 작업조차 LLM에 맡겨 시간이 더 걸렸음  
- 생성된 코드가 많더라도 결국 **검토와 이해의 책임은 인간에게 있음**, 이는 오히려 병목을 초래함  
  
### 도구가 사고를 형성하는 방식  
- “도구는 중립적이지 않다”는 관점에서, **사고를 방해하는 도구는 나쁜 도구**임   
  - 지식 노동자의 핵심 역량은 **깊이 생각하는 능력**이며, 이를 방해하는 기술은 경계해야 함  
- 물론, LLM을 완전히 배제하지 않고, **의도적이고 제한된 방식으로 활용**함  
  - 필요한 파일만 복사해 맥락을 제공하고, 코드 일부 수정이나 테스트 작성에만 사용  
  - 이렇게 하면 생성된 변경 범위가 작고, 코드베이스 전체 구조를 스스로 파악할 수 있음  
  - **수동적 생성이 아닌 ‘사려 깊은 생성’** 으로 전환되어 두뇌의 활동성과 **flow 상태** 유지 가능  
  
### 행복과 생산성의 균형  
- 인생은 짧으며, **행복을 우선시해야 함**  
  - 전체 기능을 자동 생성하면 생산성이 높아질 수는 있지만, **존재적 불안과 우울감**을 초래한다면 장기적으로 비생산적임  
- 자신의 감정에 공감할 수도, 그렇지 않을 수도 있음을 인정하지만,  
  **“다르게 선택하는 것을 두려워하지 마세요”**

## Comments



### Comment 50902

- Author: nimgnos
- Created: 2026-02-09T17:30:44+09:00
- Points: 2

계산기가 있지만, 손으로 계산하거나 암산하는 것을 좋아하는 사람도 있는 것이죠.

### Comment 50889

- Author: su79eu7k
- Created: 2026-02-09T14:43:11+09:00
- Points: 2

굉장히 복잡도가 높고, 비즈니스 로직에 핵심적인 부분을 직접 손으로 써보면서 고민해보고 이를 AI 엔지니어들에게 주입하고 그런 과정은 어쩌면 생산성에 도움이 될 수도 있다는 생각을 조심스럽게 해봅니다. 수학자들도 계산기 같은 도구는 쓰지만 핵심 아이디어를 고민할 땐 메모도 많이 하잖아요.

### Comment 50921

- Author: naruchingu
- Created: 2026-02-10T09:33:29+09:00
- Points: 1

휴대폰 한컷으로 사진을 찍을 수 있는 세상이지만 여전히 누군가는 몇시간 씩 그림을 그릴수도 있는 세상이죠. 과정과 방향성이 다름일 뿐 옳고 그름에 문제는 아닌 것 같네요.

### Comment 50886

- Author: wkdehf555
- Created: 2026-02-09T14:15:34+09:00
- Points: 1

기업들이 추구하는 방향성과 정면으로 충돌하겠다는 이야기로밖에 안들립니다만..

### Comment 50883

- Author: dolsangodkimchi
- Created: 2026-02-09T14:04:35+09:00
- Points: 1

개인의 행복과 만족감 이상향은 존중하지만 노동을 제공하고 돈을 받는 직업의 관점에서는 부적절한 마인드 같아요.

### Comment 50892

- Author: foriequal0
- Created: 2026-02-09T15:22:07+09:00
- Points: 2
- Parent comment: 50883
- Depth: 1

누군가 장기적 메트릭을 무시하고 단기적인 메트릭만을 추종하고 있으면 아무리 아무 관계가 없는 사람이라도 지나가며 "그렇게 하는 거 아닌데 ㅉㅉ" 라며 훈수를 두고 싶은 마음이 들 것 같습니다.  
그런데 본인이 기업과 동고동락 하고 큰 기여를 하며 회사에서 중요한 역할을 해내고 있다고 생각하는 프로그래머라면 그런 생각이 얼마나 더 들겠습니까.

### Comment 50881

- Author: geeksk553
- Created: 2026-02-09T13:45:44+09:00
- Points: 1

정작 정말 잘 개발하는 실력있는 개발자들은 바이브코딩을 즐긴다는거죠...  
  
제 얘기가 아니라 (리누스토발즈나 로버트 마틴같은)

### Comment 50916

- Author: dieafterwork
- Created: 2026-02-10T02:57:34+09:00
- Points: 1
- Parent comment: 50881
- Depth: 1

파이썬 스크립트에만 썼었죠. 즐겼다고 보긴 어렵지 않을까 합니다.

### Comment 50914

- Author: cocofather
- Created: 2026-02-10T00:45:31+09:00
- Points: 1
- Parent comment: 50881
- Depth: 1

리누스토발즈 기사 찾아보니까 취미용으로 썼고 리눅스 개발엔 아직 안쓴다는것 같아요

### Comment 50855

- Author: neo
- Created: 2026-02-09T09:47:49+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46934344) 
- 코딩을 목공예에 비유함. 기계가 가구를 만들 수 있어도 여전히 손으로 만드는 사람은 있음. **손코딩**도 마찬가지로 즐거움을 위해 할 수는 있지만, 앞으로는 직업적으로는 어려워질 것임  
  - 이 비유는 잘 맞지 않다고 느낌. 전동톱은 인간이 주도하는 **센타우르 기술**이지만, 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**가 되어버린 현실을 꼬집음

### Comment 50876

- Author: redline2151
- Created: 2026-02-09T12:59:11+09:00
- Points: -1

요새 자꾸 정신승리 도태개발자 글이 자꾸 올라오네요. 어차피 시대흐름은 못막을텐데

### Comment 50884

- Author: cjm01115
- Created: 2026-02-09T14:05:13+09:00
- Points: 1
- Parent comment: 50876
- Depth: 1

이건 너무 선을 넘었네요

### Comment 50880

- Author: geeksk553
- Created: 2026-02-09T13:43:09+09:00
- Points: 1
- Parent comment: 50876
- Depth: 1

저도 의견에 동의하는게 본인이 손코딩을 고집한다고 하더라도 혼자 사업하지 않는 이상  
대체될수밖에 없는데 이걸 모르는것 같아요.

### Comment 50877

- Author: hmmhmmhm
- Created: 2026-02-09T13:04:19+09:00
- Points: 1
- Parent comment: 50876
- Depth: 1

헉 말넘심 ㅠ