업계 경력 30년 이상으로, 최근에는 명세 기반 개발(spec-driven development) 에 깊이 빠져 있음
Claude Code와 GPT-5.2(CoPilot)를 활용해 요구사항을 생성하고, 여러 차례 자체 리뷰(self-review) 를 반복하며 명세를 다듬음
완성된 명세로부터 Claude Code가 구현 계획과 코드를 작성하면, 20분 내 주요 기능이 완성됨
과거 방위산업 시절의 워터폴 방식을 떠올리게 하지만, AI 덕분에 훨씬 빠르고 정제된 “** 증강된 폭포수(augmented cascade)**” 접근이 가능해졌다고 느낌
워터폴이 잘 작동하려면 장기적 관점과 명세 작성자와 개발자가 동일해야 함
애자일은 이런 조건이 불가능한 회사들이 생존을 위해 빠르게 제품을 내놓기 위한 대응이었음
나도 프로그래밍의 미래가 명세 중심이 될 거라 생각함
혹시 참고할 만한 공개 명세(spec) 사례가 있는지 궁금함. 과거 세대가 John Carmack의 Quake 코드를 존경했듯, 다음 세대는 훌륭한 명세를 찬양할 것 같음
아무리 정교한 명세라도 현실과의 충돌을 피하기 어려움
인간은 모든 복잡성과 예외 상황을 예측할 수 없기 때문임. 실제로 만들어보면 “이건 생각 못 했네” 하는 부분이 반드시 생김
애자일은 요구사항이 변하는 환경에서 점진적으로 올바른 방향을 찾아가는 방법임
이미 요구사항이 명확하다면 굳이 필요하지 않음
“사전 학습(pre-training)은 인류의 집단적 선물”이라는 표현에 동의하지 않음
도둑질된 것이라면 선물이 아님
LLM이 생성한 코드라도 내가 책임지고 관리한다면 그건 내 코드라고 생각함
문제는 작성자가 책임을 회피할 때 생김
“도둑질된 선물”이라는 표현에 본능적으로 거부감이 들었음
지식은 훔칠 수 없는 것임. 수학을 훔쳤다고 말하지 않듯, 지식의 공유 자체가 인간 발전의 본질이라 생각함
Claude Code와 Opus 4.5를 써보며 나도 비슷한 결론에 도달했음
나는 이를 “젠 코딩(zen coding)” 이라 부름. 코드베이스를 선(禪) 정원처럼 다루며, 명세를 세밀히 설계하고 한 줄씩 리뷰함
AI는 설계자가 아니라 도구로서 동작해야 함
명확한 명세를 가진 사람은 AI로부터 훨씬 높은 품질의 코드를 얻을 수 있음 Vibe coding은 직관적 실험이고, Zen coding은 장인의 수련임
“Claude가 줬다”는 식의 표현을 들으면 아직 초안 느낌의 코드일 거라는 예감이 듦
도구를 탓하거나 사과하지 말고, 결과물을 더 좋게 만들면 됨
문제는 이제 아키텍처나 코드 품질을 신경 쓰지 않아도 꽤 멀리 갈 수 있게 된 점임
그렇기에 오히려 기대치를 높이고, 자동화로 vibe-coded 앱의 품질을 끌어올려야 함
“사전 학습은 인류의 선물”이라는 표현이 불편함
많은 오픈소스 개발자들이 자신의 코드가 LLM 학습에 쓰이길 원치 않았음
LLM이 생성한 코드 중 일부는 내가 본 책이나 블로그의 코드를 거의 그대로 베낀 경우도 있었음
최소한 출처를 밝히는 게 도의라고 생각함
모든 개발은 선행자의 어깨 위에 서 있는 것임. 완전한 독립 창작은 없음
오픈소스 라이선스와 공개 도메인은 법적으로 다름
GPL 코드로 LLM을 학습시켰다면, 그 결과물도 GPL로 공개해야 한다는 해석이 가능함
창작자의 의사와 상관없이 작품이 사용된 사례는 역사적으로 많음
예를 들어 카프카는 자신의 원고를 불태워 달라 했지만, 지금은 문학의 고전이 되었음
“퀵소트 구현할 때 Hoare에게 크레딧을 주냐?”는 반문도 있음
지식재산권도 절대적인 것이 아니며, 필요하면 사회적으로 수용(expropriation) 될 수 있음
1950~60년대의 “자동 프로그래밍”은 사실 컴파일러를 의미했음
1980년대의 4GL은 도메인 특화 고수준 언어였고, 지금의 LLM은 자연어 명세로부터 초안을 생성하는 단계임
결국 인간은 여전히 반복적 수정과 설계 변경을 통해 완성도를 높여야 함
지금은 장인급 개발자(artisanal coder) 의 마지막 세대를 보고 있는지도 모름
Antirez 같은 장인은 인간의 한계를 넘어선 개념들을 다루며, Redis처럼 단순하면서도 아름다운 소프트웨어를 만들어냄
AI는 인간이 할 수 없는 속도로 코드를 만들지만, 그건 붓과 캔버스가 아님
새로운 세대는 완전히 다른 방식의 장인이 될 것임
나 역시 두렵지만, 이 새로운 도구들을 받아들이며 새로운 공예의 시대를 실험하고 있음
체스도 인간이 컴퓨터를 이길 수 없지만 여전히 인기가 많음
Antirez는 이제 AI 인플루언서에 가깝지만, 여전히 코딩은 즐거운 행위임
LLM이 코드를 도와주더라도, 여전히 기초 개념과 구조 이해는 필수임
AI를 잘 다루는 능력이 추가될 뿐, 기존 지식이 불필요해지진 않음
Antirez의 글에서 “vibe coding과 automatic programming의 차이”를 명확히 구분한 점이 인상적이었음
이는 건축가가 손으로 도면을 그리던 시대에서 BIM, CAD로 전환된 것과 비슷한 변화임
AI 시대의 개발자는 덜 코딩하는 게 아니라, 가치의 초점이 바뀐 것임
“vibe coding vs automatic coding”은 이분법이 아닌 스펙트럼임
한 프로젝트 안에서도 여러 단계의 접근을 혼합할 수 있음
LLM의 출력은 사용자의 기술 수준과 의도에 따라 달라지므로, 결과물은 결국 사용자에게 귀속됨
중요한 건 도구를 비판적으로 활용하고 지속적으로 개선하는 태도임
AI는 다양한 방식으로 연주할 수 있는 악기와 같음
어떤 이는 이를 “spec strumming”이라 부름
Hacker News 의견들
업계 경력 30년 이상으로, 최근에는 명세 기반 개발(spec-driven development) 에 깊이 빠져 있음
Claude Code와 GPT-5.2(CoPilot)를 활용해 요구사항을 생성하고, 여러 차례 자체 리뷰(self-review) 를 반복하며 명세를 다듬음
완성된 명세로부터 Claude Code가 구현 계획과 코드를 작성하면, 20분 내 주요 기능이 완성됨
과거 방위산업 시절의 워터폴 방식을 떠올리게 하지만, AI 덕분에 훨씬 빠르고 정제된 “** 증강된 폭포수(augmented cascade)**” 접근이 가능해졌다고 느낌
애자일은 이런 조건이 불가능한 회사들이 생존을 위해 빠르게 제품을 내놓기 위한 대응이었음
혹시 참고할 만한 공개 명세(spec) 사례가 있는지 궁금함. 과거 세대가 John Carmack의 Quake 코드를 존경했듯, 다음 세대는 훌륭한 명세를 찬양할 것 같음
인간은 모든 복잡성과 예외 상황을 예측할 수 없기 때문임. 실제로 만들어보면 “이건 생각 못 했네” 하는 부분이 반드시 생김
이미 요구사항이 명확하다면 굳이 필요하지 않음
다만 하위 팀 대신 LLM을 활용한다는 점이 다름
관련 참고 자료: Design by Contract (Goodreads), 원문 PDF
“사전 학습(pre-training)은 인류의 집단적 선물”이라는 표현에 동의하지 않음
도둑질된 것이라면 선물이 아님
LLM이 생성한 코드라도 내가 책임지고 관리한다면 그건 내 코드라고 생각함
문제는 작성자가 책임을 회피할 때 생김
Claude Code와 Opus 4.5를 써보며 나도 비슷한 결론에 도달했음
나는 이를 “젠 코딩(zen coding)” 이라 부름. 코드베이스를 선(禪) 정원처럼 다루며, 명세를 세밀히 설계하고 한 줄씩 리뷰함
AI는 설계자가 아니라 도구로서 동작해야 함
명확한 명세를 가진 사람은 AI로부터 훨씬 높은 품질의 코드를 얻을 수 있음
Vibe coding은 직관적 실험이고, Zen coding은 장인의 수련임
“Claude가 줬다”는 식의 표현을 들으면 아직 초안 느낌의 코드일 거라는 예감이 듦
도구를 탓하거나 사과하지 말고, 결과물을 더 좋게 만들면 됨
“사전 학습은 인류의 선물”이라는 표현이 불편함
많은 오픈소스 개발자들이 자신의 코드가 LLM 학습에 쓰이길 원치 않았음
LLM이 생성한 코드 중 일부는 내가 본 책이나 블로그의 코드를 거의 그대로 베낀 경우도 있었음
최소한 출처를 밝히는 게 도의라고 생각함
GPL 코드로 LLM을 학습시켰다면, 그 결과물도 GPL로 공개해야 한다는 해석이 가능함
예를 들어 카프카는 자신의 원고를 불태워 달라 했지만, 지금은 문학의 고전이 되었음
1950~60년대의 “자동 프로그래밍”은 사실 컴파일러를 의미했음
1980년대의 4GL은 도메인 특화 고수준 언어였고, 지금의 LLM은 자연어 명세로부터 초안을 생성하는 단계임
결국 인간은 여전히 반복적 수정과 설계 변경을 통해 완성도를 높여야 함
지금은 장인급 개발자(artisanal coder) 의 마지막 세대를 보고 있는지도 모름
Antirez 같은 장인은 인간의 한계를 넘어선 개념들을 다루며, Redis처럼 단순하면서도 아름다운 소프트웨어를 만들어냄
AI는 인간이 할 수 없는 속도로 코드를 만들지만, 그건 붓과 캔버스가 아님
새로운 세대는 완전히 다른 방식의 장인이 될 것임
나 역시 두렵지만, 이 새로운 도구들을 받아들이며 새로운 공예의 시대를 실험하고 있음
AI를 잘 다루는 능력이 추가될 뿐, 기존 지식이 불필요해지진 않음
Antirez의 글에서 “vibe coding과 automatic programming의 차이”를 명확히 구분한 점이 인상적이었음
이는 건축가가 손으로 도면을 그리던 시대에서 BIM, CAD로 전환된 것과 비슷한 변화임
AI 시대의 개발자는 덜 코딩하는 게 아니라, 가치의 초점이 바뀐 것임
“vibe coding vs automatic coding”은 이분법이 아닌 스펙트럼임
한 프로젝트 안에서도 여러 단계의 접근을 혼합할 수 있음
중요한 건 도구를 비판적으로 활용하고 지속적으로 개선하는 태도임
어떤 이는 이를 “spec strumming”이라 부름