코딩을 목공예에 비유함. 기계가 가구를 만들 수 있어도 여전히 손으로 만드는 사람은 있음. 손코딩도 마찬가지로 즐거움을 위해 할 수는 있지만, 앞으로는 직업적으로는 어려워질 것임
이 비유는 잘 맞지 않다고 느낌. 전동톱은 인간이 주도하는 센타우르 기술이지만, 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은 모든 문제를 망치로 보는 도구가 되어버림
현대 사회가 버튼 클릭으로 도파민을 얻는 구조로 변하고 있음. 그래서 모든 게 엉망처럼 느껴짐
Hacker News 의견들
코딩을 목공예에 비유함. 기계가 가구를 만들 수 있어도 여전히 손으로 만드는 사람은 있음. 손코딩도 마찬가지로 즐거움을 위해 할 수는 있지만, 앞으로는 직업적으로는 어려워질 것임
나는 장기적으로 가장 빠르고 좋은 결과를 주는 방식을 택함. 지금은 neovim과 손코딩이 그 역할을 함. 직접 타이핑하며 프로젝트를 깊이 이해하면 장기적으로 더 빠르게 기능을 낼 수 있음. 학습에 도움이 안 되는 일은 LLM에 맡기지만, 그런 일이 많아서 LLM 사용률은 높음
vibecoding의 문제는 ‘기분이 좋다’는 감정이 실제 성과를 흐리게 만든다는 점임
“행복하다고 해서 코드 생산량이 200배 늘어나는가?”라는 냉소적 질문을 던짐
AI의 가치는 분명 있음. 예를 들어 300컬럼짜리 DB 테이블을 Rust struct로 변환할 때, 15단어 프롬프트로 900줄 코드를 생성함. 이런 반복 작업엔 AI가 완벽함. 하지만 모든 걸 맡기고 싶진 않음. 행복한 사용 수준에서만 씀
“LLM이 코드를 대신 써주는 동안 나는 무엇을 하나?”라는 질문이 핵심임. LLM은 완전히 맡길 수 없고, 옆에서 돌보는 느낌임. 주니어 개발자는 성장하지만, LLM은 학습하지 않음. 그래서 멘토링의 보람이 사라진 느낌임
요즘 개발자 채용이 어떻게 변했는지 궁금함. LLM 사용이 허용되는지, 여전히 손코딩을 요구하는지 의문임
나는 LLM 이전부터 모델 기반 개발(MDD) 로 vibecoding 수준의 속도로 개발해왔음. 데이터 모델이 곧 애플리케이션이며, LLM은 그 위에서 절차를 조금 더 빨리 써줄 뿐임. 데이터 모델의 방향성은 여전히 내가 결정함
AI 코딩은 세 가지로 나뉨
현대 사회가 버튼 클릭으로 도파민을 얻는 구조로 변하고 있음. 그래서 모든 게 엉망처럼 느껴짐