Readme에서 발췌 내용 소개. 이 라이브러리(그리고 스키마 문서)는 대부분 Anthropic의 AI 모델 Claude의 도움을 받아 작성함. Cloudflare 엔지니어들이 철저하게 검토하고 보안 및 표준 준수에 신경 씀. 초기 산출물에서도 많은 개선이 이루어졌고, 주로 Claude에게 추가 프롬프트를 주고 결과를 반복적으로 검토하면서 진행함. 커밋 히스토리에서 Claude를 어떻게 프롬프트했고, 어떤 코드가 나왔는지 실제로 직접 확인 가능함. 처음에는 “LLM이 인증 라이브러리를 작성하게 두면 안 된다”는 전통적인 회의적 입장이었음. 2025년 1월만 해도 나 역시 AI에 매우 회의적이었고, LLM은 그저 ‘화려한 Markov 체인 생성기’ 정도에 불과하며, 참신함이나 실제 코드를 만들어내지 못한다고 생각함. 프로젝트를 재미 삼아 시작했지만, 생각보다 괜찮은 코드가 나와서 충격을 받음. 완벽하지는 않았지만 AI에게 수정 요청만 하면 제대로 고쳐줬음. 한 줄 한 줄 다 각종 RFC와 비교해보며, 보안 전문가들과 함께 검토함. 내 회의론을 검증하려고 했으나, 오히려 스스로 틀렸음을 증명한 결과임. 커밋 이력, 특히 초기 커밋을 꼭 참고해 보면 이 과정을 확인할 수 있음
숙련된 엔지니어가 적절하게 프롬프트를 했을 때 LLM이 이런 코드 정도는 충분히 만들어낼 수 있으리라 기대함. OAuth는 새로운 기술이 아니고 이미 수많은 오픈소스 예제와 다양한 언어의 구현 케이스가 데이터로 쓰였을 것임. 하지만 LLM이 전혀 새로운 연구, 소재 과학, 경제, 발명 등에 혁신적으로 기여할 거라는 주장에는 여전히 회의적임. ‘실시간으로 배우는 능력’이 정말 필요한 영역인데, 현존 LLM은 이미 아는 오래된 정보를 바탕으로만 능력을 보여왔음. 유의미한 성과는 대개 아주 제한된 환경 내 cherry-pick 사례에 불과함. 숙련된 엔지니어가 있다면 과거 데이터를 바탕으로 새로운 코드 생성이 당연히 가능하다고 생각하지만, LLM 도입이 가져오는 환경적, 사회적 부담이 실제 효율성에 비해 과도하다고 여전히 의문임
“나는 2025년 1월까지 (@kentonv)와 같은 생각을 가지고 있었다”라는 표현에 혼란을 느낌. kentonv가 다른 사용자이기 때문임. 이게 본인 부계정인가, 아니면 오타나 오해인지 궁금함. 편집: 대부분의 글이 README 인용인 걸 확인함. >와 * 기호를 사용해서 인용을 명확히 했으면 혼란이 덜했으리라 생각함. kentonv 프로필 링크 첨부
"LLM을 화려한 Markov 체인 생성기라 생각했다"와 "AI가 꽤 괜찮은 코드를 만들어내 놀랐다" 이 두 의견은 서로 모순이 아님. LLM이 굉장히 유용하다고 느끼지만, 여전히 본질은 패턴 생성기에 가까움. 중요한 점은 그 정도가 이미 충분하고, 인간 역시 크게 다르지 않은 구조일 수도 있다는 사실임
요즘은 pro-AI 보다는 더 회의적인 입장이지만, 어쨌든 워크플로우에서 AI 도입하려 계속 시도 중임. 실제로는 설명이 더 어려워서 그냥 직접 하는 게 더 쉽다고 느낌. 큰 재미도 없지만, 이게 “미래”의 도구이니 익히는 게 현명하다고 생각함. 아직은 진짜 AI 툴링은 초창기 수준이라 봄. 앞으로 신기한 UX 사례 등장에 계속 관심이 생김
초기에 Claude가 어떻게 프롬프트 받았고, 실제 코드를 어떻게 생성했는지 커밋 히스토리 직접 참고 안내. 최초 커밋 페이지로 바로가기 링크 제공. 명확하고 구체적인 지시가 많았고, 예시 커밋1, 예시 커밋2 등도 볼만함
Cloudflare workers-oauth-provider 커밋 중 이슈 커밋 발췌. Claude가 이전 커밋에서 버그를 내서 여러 번 프롬프트로 수정하려 했으나 계속 실패함. 결국 인간이 직접 수정하고, README에 OAuth 2.1 스펙 이슈까지 문서화함. 이런 경험이 나 개인적으로도 AI 활용에서 매우 공감됨. 절반까지 잘 가다가 나머지는 힘들어하는 모습을 종종 봄
AI가 중간까지는 잘 해내지만, 한 번 실수하면 이후 전부 망가진다는 점에 주목함. 실수 발견 시 즉시 대화 처음부터 프롬프트를 재작성해서 시작해야 함. 한 번 실수한 이후엔 아무리 바로잡으려 해도 결과가 계속 잘못됨. 그래서 올바른 시작 메시지에 모든 걸 명확하게 담아 다시 처음부터 만들어야 실수를 반복하지 않음
이런 문제를 완화하려면 테스트나 명확한 명세(spec)를 마련해 AI에게 해결하도록 하면 도움됨. 몇 달 전만 해도 AI가 이런 명세 퍼즐을 푸는 데 시간이 많이 걸렸고, 결과물도 빠른 답변보다 품질이 낮았음. 하지만 최근엔 모델 성능이 많이 좋아져서 이러한 작업이 꽤 재미있고, 스펙화 할 수 있는 경우 활용도가 올라감. 나 개인적으로는 sonnet 3.7이 3.5보다 큰 발전을 보였고, Gemini 2.5 Pro가 더 인상 깊었음. sonnet 4는 실수가 더 적지만, 여전히 소프트웨어 엔지니어링 관점(요구사항 정리, 기술 솔루션 탐색, 아키텍처 설계, 유저 스토리 및 명세 작성, 코드 작성)에서 AI를 제대로 유도해 줘야 양질의 결과물을 얻을 수 있음. 추가로, 좋은 예제를 AI에 추가해 넣으면 효과가 극대화됨. 최근 OpenAI Realtime API로 앱을 만들 때도 초반엔 완전 실패했지만, 문서 두 페이지와 데모 프로젝트 하나를 워크스페이스에 추가하고 나니 바로 원하는 결과가 나옴(내 경우엔 API를 다르게 써야 했음에도 잘 맞음)
커밋 163~172줄 언급 내용 중 명백히 사실과 다르거나 A/S(인증 서버) 구현별로 해석이 다른 주장들 발견. Auth0의 인증 서버는 네트워크 조건을 감안한 “leeway” 설정이 있지만, 일부 인증 서버는 훨씬 엄격함. 각 구현체마다 세부 설계가 달라서, 표준(RFC)와 공개된 오픈소스만으로 LLM이 안전하게 구현할 확률은, 결국 직접 만드는 것과 맞먹는 수준의 인간의 감수가 필요하다고 생각함
LLM 기반 도구가 실제로 투입 인력을 절약해줄 수 있는지, 아니면 생산 착시만 주는지에 대한 장기적 연구 결과가 궁금함
이런 경험에서 AI 도구들이 실제로 이해하고 있는 것이 아니라, 거대한 패턴 데이터 모음을 바탕으로 우연적(emergent) 출력을 만들어내는 것이라 봄
AI 코딩의 미래는 소프트웨어 엔지니어가 사라지고, 비즈니스맨이 버튼 누르면 모든 게 끝나는 LinkedIn/ X류 판타지와 달리, 숙련 엔지니어들이 AI로 코드 일부를 만들고 이를 꼼꼼히 검토, 테스트하는 방향일 것임. 진짜 중요한 질문은, “kentonv가 AI 없이 혼자 이 라이브러리를 더 빠르게 만들 수 있었을까?”라는 점임
AI와 함께 라이브러리를 만드는 데 며칠 걸림. 직접 손수 만들면 몇 주, 어쩌면 몇 달 걸렸을 거라 추정함. 다만, 여기서는 매우 이상적인 사례임. 명확한 표준, 명확한 API 스펙 기반에, 이미 잘 알려진 플랫폼이라는 조건이 있어 가능했던 것임. AI로 Workers Runtime 자체를 바꾸려 했을 땐 시간 절감 효과가 별로였음. 그러나 내가 익숙하지 않은 다른 사람 코드베이스엔 AI가 정말 큰 도움이 됨. 이제는 낯선 복잡한 코드 탐험실에도 진입이 편리해졌고, 과거엔 그런 걸 피했다면 지금은 스스로 필요한 변경을 쉽게 할 수 있음
AI 없이 혼자 직접 만들었으면 더 빨랐을까란 질문엔 확실히 아니라고 생각함. 지금 우리가 가진 도구와, 계속 나아지고 있는 활용 노하우로 볼 때, 앞으로 3-6개월 내에는 AI로 직접 새 솔루션을 코딩하는 게 더 빨라질 전망임. 다만 잘 문서화되고, 구조가 명확하며, 빠른 피드백 루프(좋은 린트/유닛 테스트)가 갖춰진 코드베이스 장비가 중요하다고 생각함. 우리는 그쪽으로 가는 중임
경험상 AI가 일부 코드를 만들어주면 꼼꼼히 리뷰, 테스트해야 하는데 이 과정이 오히려 내가 직접 코딩하는 것보다 <i>느림</i>. 그래서 지금 단계에선 AI가 큰 도움이 안 됨. 잘못된 도우미가 없느니만 못하다는 속담처럼, 아직 AI는 “나쁜 도우미”인 셈임
“경험 많은 엔지니어가 AI로 코드 일부를 만들고 꼼꼼히 테스팅하는 구조”라면, 결국 20명의 kentonv 대신 2명만 있으면 충분한 것 아닌가란 고민 생김. 나머지 일할 사람 18명을 위한 일거리가 계속 생길까? 저자 사례는 기술적으로 어려운 프로젝트지만, 밋밋한 LoB(업무용) 앱 개발에는 어떤 변화가 있을지 궁금함
경험 많은 엔지니어가 꼼꼼히 리뷰 및 테스트만 한다면, 주니어 개발자 자리를 전부 AI로 대체했을 경우 경력 개발자가 어디서 생길지 물음. 단순 반복 작업에도 그만한 가치를 두는 입장임
이런 다양한 논점과 의견들을 보는 것이 그 자체로 신기함. Cloudflare가 인터넷 보안 분야 리더답게 새로운 ‘vibe 코딩’ 방식으로 세상을 연결하는 시도를 보여줌에 감사함. 이러한 AI 프롬프트, 코드 등이 다른 개발자들에게도 프로그래밍 탐구 의지를 높여줌을 느꼈음. vibe programming이 내 우울감을 돌파하고, 내가 익숙한 방식으로 코딩하게 해준 매우 의미 있는 수단임. 이런 경험이 다른 사람에게도 도움이 되기를 바람. 현재와 미래 세대 모두 이런 방식을 활용할 것으로 기대함. 다만, 이 방식이 사람의 정신 건강이나 심리 문제와도 연결될 수 있다는 점을 논의해야 한다고 생각함. 결국 이러한 도구는 인간의 조력수단임을 유념하면서, 우리가 열정을 갖고 성장할 수 있도록 어떻게 활용할지 고민함. 오픈소스 분야에서 기술 역량뿐 아니라, 논리와 사려 깊은 프로젝트 접근법을 보여줄 사례들이 많이 나오길 기대함. Cloudflare에 다시 한 번 칭찬을 보냄
대표적인 프롬프트 주고받기 예시를 모아둠. 프롬프트 트랜스크립트 예시에서는 실제 비용(총 $6.45)까지 공개함. 관련 커밋1, 커밋2 등 자료도 안내함. AI 워크플로우에 대한 제대로 된 경험기(특히 숙련자들)의 정보가 하이프에 묻혀 별로 없다는 게 놀라움. todo list 외에 실제 라이브 코딩 사례 정보가 궁금한 상황임. antirez, tptacek의 글(antirez 사례, tptacek 글)도 참고하면 좋을 듯함
정확히는 추적하지 않았지만 Claude 사용 비용은 대략 $50 정도라 추정함. 절약된 시간에 비하면 의미 없는 비용 수준임
나는 “vibecoding”이 결국 생존하지 못할 거라 봄. 여전히 뛰어난 프로그래머의 검증, 버그 수정이 필요하며, AI가 못 고치는 버그도 있었음. 결국 이런 도구는 자신이 이미 해당 작업을 잘 알고 있는 사람이 속도를 높일 수 있는 보조도구임. 정말 기초적인 홈페이지 정도는 몰라도, 그런 걸 자동 생성해 주는 툴은 수년 전부터 존재함
vibecoding은 지금은 stakes가 낮은 작업에 최적임. GUI, CRUD 앱, 일회성 실험 등 파워 없는 이들에게 새로운 힘을 주는 부분에서 쓸모가 높음. 이번 건은 vibecoding이 아니라 LLM-assisted coding이라 생각함
실제로는 vibecoding이라는 말을 공격용 허수아비처럼 사용하는 경향이 느껴짐. 대부분 LLM에게 맡긴 코드를 약간만 고쳐서 쓰는 것 역시 vibe coding이라 보면 되는 거 아닌지?
OP가 AI로 생성된 코드 뿐 아니라 프롬프트까지 공개해준 점이 크게 고마움. 개인적으로 LLM으로 비웹 코드(특히 요즘엔 SAP ABAP 역공학해서 데이터를 Snowflake에 맞추는 .NET 구현)를 개발하려다 매번 ‘환각’ 이슈에 고생함. 다른 사람들은 성공 사례가 많다 하길래 내 프롬프트만 문제라 생각했는데, 이번 공개된 사례를 보니 나도 그리 멀지 않다는 걸 알게 됨. LLM이 내게 잘 안 맞는 이유는 만든 문제가 조금 희귀하고 새롭기 때문이라 판단함. GitHub에 공개된 OAuth 케이스처럼 많이 학습된 대상이 아니면 LLM이 잘 못 따라옴
이런 종류의 반복적이고 이미 수백 번 구현된 코드는 AI에 완벽히 적합함. 전체 코드 1200줄 정도라 작은 규모임. AI 쓰고도 2일 이상 걸렸다는 게 오히려 의외임
최근 몇 달간 Cursor로 Claude를 이용해 나만의 greenfield 프로젝트를 진행하며 느낀 점은 첫째, 엄청나게 생산성이 높아졌음. 둘째, 이전보다 정신적으로 훨씬 더 피로함. 셋째, 단기간 내에도 도구들이 상당히 빨리 발전하기 시작하며, 위 두 가지 효과도 증폭되고 있음
내 경험 및 다른 개발자들과도 똑같음. LLM assisted coding은 실제로 생산성 향상에 큰 도움이 되지만, 에너지 소모가 그만큼 더 큼. 오히려 이상하게 느껴질 정도임
“이렇게 더 피곤하다”는 점에 질문함. 난 기존 방식보다 내 에이전트(Devstral)와 “페어 프로그래밍” 형태로 활용하고 있고, 코드 전체를 일일이 타이핑하는 것보다 리뷰가 훨씬 쉬움. time wise 관점에서 큰 장점임. vibe coding에선 코드베이스 맥락이 사라져 나중에 리뷰와 진입 장벽이 훨씬 커짐. 반면 페어 프로그래밍에선 맥락을 쌓으면서 진행되니 리뷰가 훨씬 빠르다고 느낌
나는 오히려 정반대임. AI가 사소한 디테일을 전부 알아서 챙겨주니까 오히려 큰 안도감 생김. 아키텍처 등 상위 목표에 집중할 수 있게 자유로워짐
Cloudflare 같은 회사에서 "Too Many Requests" 에러가 나는 게 꽤 유쾌하게 느껴짐
Hacker News 의견
Readme에서 발췌 내용 소개. 이 라이브러리(그리고 스키마 문서)는 대부분 Anthropic의 AI 모델 Claude의 도움을 받아 작성함. Cloudflare 엔지니어들이 철저하게 검토하고 보안 및 표준 준수에 신경 씀. 초기 산출물에서도 많은 개선이 이루어졌고, 주로 Claude에게 추가 프롬프트를 주고 결과를 반복적으로 검토하면서 진행함. 커밋 히스토리에서 Claude를 어떻게 프롬프트했고, 어떤 코드가 나왔는지 실제로 직접 확인 가능함. 처음에는 “LLM이 인증 라이브러리를 작성하게 두면 안 된다”는 전통적인 회의적 입장이었음. 2025년 1월만 해도 나 역시 AI에 매우 회의적이었고, LLM은 그저 ‘화려한 Markov 체인 생성기’ 정도에 불과하며, 참신함이나 실제 코드를 만들어내지 못한다고 생각함. 프로젝트를 재미 삼아 시작했지만, 생각보다 괜찮은 코드가 나와서 충격을 받음. 완벽하지는 않았지만 AI에게 수정 요청만 하면 제대로 고쳐줬음. 한 줄 한 줄 다 각종 RFC와 비교해보며, 보안 전문가들과 함께 검토함. 내 회의론을 검증하려고 했으나, 오히려 스스로 틀렸음을 증명한 결과임. 커밋 이력, 특히 초기 커밋을 꼭 참고해 보면 이 과정을 확인할 수 있음
숙련된 엔지니어가 적절하게 프롬프트를 했을 때 LLM이 이런 코드 정도는 충분히 만들어낼 수 있으리라 기대함. OAuth는 새로운 기술이 아니고 이미 수많은 오픈소스 예제와 다양한 언어의 구현 케이스가 데이터로 쓰였을 것임. 하지만 LLM이 전혀 새로운 연구, 소재 과학, 경제, 발명 등에 혁신적으로 기여할 거라는 주장에는 여전히 회의적임. ‘실시간으로 배우는 능력’이 정말 필요한 영역인데, 현존 LLM은 이미 아는 오래된 정보를 바탕으로만 능력을 보여왔음. 유의미한 성과는 대개 아주 제한된 환경 내 cherry-pick 사례에 불과함. 숙련된 엔지니어가 있다면 과거 데이터를 바탕으로 새로운 코드 생성이 당연히 가능하다고 생각하지만, LLM 도입이 가져오는 환경적, 사회적 부담이 실제 효율성에 비해 과도하다고 여전히 의문임
“나는 2025년 1월까지 (@kentonv)와 같은 생각을 가지고 있었다”라는 표현에 혼란을 느낌. kentonv가 다른 사용자이기 때문임. 이게 본인 부계정인가, 아니면 오타나 오해인지 궁금함. 편집: 대부분의 글이 README 인용인 걸 확인함. >와 * 기호를 사용해서 인용을 명확히 했으면 혼란이 덜했으리라 생각함. kentonv 프로필 링크 첨부
"LLM을 화려한 Markov 체인 생성기라 생각했다"와 "AI가 꽤 괜찮은 코드를 만들어내 놀랐다" 이 두 의견은 서로 모순이 아님. LLM이 굉장히 유용하다고 느끼지만, 여전히 본질은 패턴 생성기에 가까움. 중요한 점은 그 정도가 이미 충분하고, 인간 역시 크게 다르지 않은 구조일 수도 있다는 사실임
요즘은 pro-AI 보다는 더 회의적인 입장이지만, 어쨌든 워크플로우에서 AI 도입하려 계속 시도 중임. 실제로는 설명이 더 어려워서 그냥 직접 하는 게 더 쉽다고 느낌. 큰 재미도 없지만, 이게 “미래”의 도구이니 익히는 게 현명하다고 생각함. 아직은 진짜 AI 툴링은 초창기 수준이라 봄. 앞으로 신기한 UX 사례 등장에 계속 관심이 생김
초기에 Claude가 어떻게 프롬프트 받았고, 실제 코드를 어떻게 생성했는지 커밋 히스토리 직접 참고 안내. 최초 커밋 페이지로 바로가기 링크 제공. 명확하고 구체적인 지시가 많았고, 예시 커밋1, 예시 커밋2 등도 볼만함
Cloudflare workers-oauth-provider 커밋 중 이슈 커밋 발췌. Claude가 이전 커밋에서 버그를 내서 여러 번 프롬프트로 수정하려 했으나 계속 실패함. 결국 인간이 직접 수정하고, README에 OAuth 2.1 스펙 이슈까지 문서화함. 이런 경험이 나 개인적으로도 AI 활용에서 매우 공감됨. 절반까지 잘 가다가 나머지는 힘들어하는 모습을 종종 봄
AI가 중간까지는 잘 해내지만, 한 번 실수하면 이후 전부 망가진다는 점에 주목함. 실수 발견 시 즉시 대화 처음부터 프롬프트를 재작성해서 시작해야 함. 한 번 실수한 이후엔 아무리 바로잡으려 해도 결과가 계속 잘못됨. 그래서 올바른 시작 메시지에 모든 걸 명확하게 담아 다시 처음부터 만들어야 실수를 반복하지 않음
이런 문제를 완화하려면 테스트나 명확한 명세(spec)를 마련해 AI에게 해결하도록 하면 도움됨. 몇 달 전만 해도 AI가 이런 명세 퍼즐을 푸는 데 시간이 많이 걸렸고, 결과물도 빠른 답변보다 품질이 낮았음. 하지만 최근엔 모델 성능이 많이 좋아져서 이러한 작업이 꽤 재미있고, 스펙화 할 수 있는 경우 활용도가 올라감. 나 개인적으로는 sonnet 3.7이 3.5보다 큰 발전을 보였고, Gemini 2.5 Pro가 더 인상 깊었음. sonnet 4는 실수가 더 적지만, 여전히 소프트웨어 엔지니어링 관점(요구사항 정리, 기술 솔루션 탐색, 아키텍처 설계, 유저 스토리 및 명세 작성, 코드 작성)에서 AI를 제대로 유도해 줘야 양질의 결과물을 얻을 수 있음. 추가로, 좋은 예제를 AI에 추가해 넣으면 효과가 극대화됨. 최근 OpenAI Realtime API로 앱을 만들 때도 초반엔 완전 실패했지만, 문서 두 페이지와 데모 프로젝트 하나를 워크스페이스에 추가하고 나니 바로 원하는 결과가 나옴(내 경우엔 API를 다르게 써야 했음에도 잘 맞음)
커밋 163~172줄 언급 내용 중 명백히 사실과 다르거나 A/S(인증 서버) 구현별로 해석이 다른 주장들 발견. Auth0의 인증 서버는 네트워크 조건을 감안한 “leeway” 설정이 있지만, 일부 인증 서버는 훨씬 엄격함. 각 구현체마다 세부 설계가 달라서, 표준(RFC)와 공개된 오픈소스만으로 LLM이 안전하게 구현할 확률은, 결국 직접 만드는 것과 맞먹는 수준의 인간의 감수가 필요하다고 생각함
LLM 기반 도구가 실제로 투입 인력을 절약해줄 수 있는지, 아니면 생산 착시만 주는지에 대한 장기적 연구 결과가 궁금함
이런 경험에서 AI 도구들이 실제로 이해하고 있는 것이 아니라, 거대한 패턴 데이터 모음을 바탕으로 우연적(emergent) 출력을 만들어내는 것이라 봄
AI 코딩의 미래는 소프트웨어 엔지니어가 사라지고, 비즈니스맨이 버튼 누르면 모든 게 끝나는 LinkedIn/ X류 판타지와 달리, 숙련 엔지니어들이 AI로 코드 일부를 만들고 이를 꼼꼼히 검토, 테스트하는 방향일 것임. 진짜 중요한 질문은, “kentonv가 AI 없이 혼자 이 라이브러리를 더 빠르게 만들 수 있었을까?”라는 점임
AI와 함께 라이브러리를 만드는 데 며칠 걸림. 직접 손수 만들면 몇 주, 어쩌면 몇 달 걸렸을 거라 추정함. 다만, 여기서는 매우 이상적인 사례임. 명확한 표준, 명확한 API 스펙 기반에, 이미 잘 알려진 플랫폼이라는 조건이 있어 가능했던 것임. AI로 Workers Runtime 자체를 바꾸려 했을 땐 시간 절감 효과가 별로였음. 그러나 내가 익숙하지 않은 다른 사람 코드베이스엔 AI가 정말 큰 도움이 됨. 이제는 낯선 복잡한 코드 탐험실에도 진입이 편리해졌고, 과거엔 그런 걸 피했다면 지금은 스스로 필요한 변경을 쉽게 할 수 있음
AI 없이 혼자 직접 만들었으면 더 빨랐을까란 질문엔 확실히 아니라고 생각함. 지금 우리가 가진 도구와, 계속 나아지고 있는 활용 노하우로 볼 때, 앞으로 3-6개월 내에는 AI로 직접 새 솔루션을 코딩하는 게 더 빨라질 전망임. 다만 잘 문서화되고, 구조가 명확하며, 빠른 피드백 루프(좋은 린트/유닛 테스트)가 갖춰진 코드베이스 장비가 중요하다고 생각함. 우리는 그쪽으로 가는 중임
경험상 AI가 일부 코드를 만들어주면 꼼꼼히 리뷰, 테스트해야 하는데 이 과정이 오히려 내가 직접 코딩하는 것보다 <i>느림</i>. 그래서 지금 단계에선 AI가 큰 도움이 안 됨. 잘못된 도우미가 없느니만 못하다는 속담처럼, 아직 AI는 “나쁜 도우미”인 셈임
“경험 많은 엔지니어가 AI로 코드 일부를 만들고 꼼꼼히 테스팅하는 구조”라면, 결국 20명의 kentonv 대신 2명만 있으면 충분한 것 아닌가란 고민 생김. 나머지 일할 사람 18명을 위한 일거리가 계속 생길까? 저자 사례는 기술적으로 어려운 프로젝트지만, 밋밋한 LoB(업무용) 앱 개발에는 어떤 변화가 있을지 궁금함
경험 많은 엔지니어가 꼼꼼히 리뷰 및 테스트만 한다면, 주니어 개발자 자리를 전부 AI로 대체했을 경우 경력 개발자가 어디서 생길지 물음. 단순 반복 작업에도 그만한 가치를 두는 입장임
이런 다양한 논점과 의견들을 보는 것이 그 자체로 신기함. Cloudflare가 인터넷 보안 분야 리더답게 새로운 ‘vibe 코딩’ 방식으로 세상을 연결하는 시도를 보여줌에 감사함. 이러한 AI 프롬프트, 코드 등이 다른 개발자들에게도 프로그래밍 탐구 의지를 높여줌을 느꼈음. vibe programming이 내 우울감을 돌파하고, 내가 익숙한 방식으로 코딩하게 해준 매우 의미 있는 수단임. 이런 경험이 다른 사람에게도 도움이 되기를 바람. 현재와 미래 세대 모두 이런 방식을 활용할 것으로 기대함. 다만, 이 방식이 사람의 정신 건강이나 심리 문제와도 연결될 수 있다는 점을 논의해야 한다고 생각함. 결국 이러한 도구는 인간의 조력수단임을 유념하면서, 우리가 열정을 갖고 성장할 수 있도록 어떻게 활용할지 고민함. 오픈소스 분야에서 기술 역량뿐 아니라, 논리와 사려 깊은 프로젝트 접근법을 보여줄 사례들이 많이 나오길 기대함. Cloudflare에 다시 한 번 칭찬을 보냄
대표적인 프롬프트 주고받기 예시를 모아둠. 프롬프트 트랜스크립트 예시에서는 실제 비용(총 $6.45)까지 공개함. 관련 커밋1, 커밋2 등 자료도 안내함. AI 워크플로우에 대한 제대로 된 경험기(특히 숙련자들)의 정보가 하이프에 묻혀 별로 없다는 게 놀라움. todo list 외에 실제 라이브 코딩 사례 정보가 궁금한 상황임. antirez, tptacek의 글(antirez 사례, tptacek 글)도 참고하면 좋을 듯함
나는 “vibecoding”이 결국 생존하지 못할 거라 봄. 여전히 뛰어난 프로그래머의 검증, 버그 수정이 필요하며, AI가 못 고치는 버그도 있었음. 결국 이런 도구는 자신이 이미 해당 작업을 잘 알고 있는 사람이 속도를 높일 수 있는 보조도구임. 정말 기초적인 홈페이지 정도는 몰라도, 그런 걸 자동 생성해 주는 툴은 수년 전부터 존재함
vibecoding은 지금은 stakes가 낮은 작업에 최적임. GUI, CRUD 앱, 일회성 실험 등 파워 없는 이들에게 새로운 힘을 주는 부분에서 쓸모가 높음. 이번 건은 vibecoding이 아니라 LLM-assisted coding이라 생각함
실제로는 vibecoding이라는 말을 공격용 허수아비처럼 사용하는 경향이 느껴짐. 대부분 LLM에게 맡긴 코드를 약간만 고쳐서 쓰는 것 역시 vibe coding이라 보면 되는 거 아닌지?
OP가 AI로 생성된 코드 뿐 아니라 프롬프트까지 공개해준 점이 크게 고마움. 개인적으로 LLM으로 비웹 코드(특히 요즘엔 SAP ABAP 역공학해서 데이터를 Snowflake에 맞추는 .NET 구현)를 개발하려다 매번 ‘환각’ 이슈에 고생함. 다른 사람들은 성공 사례가 많다 하길래 내 프롬프트만 문제라 생각했는데, 이번 공개된 사례를 보니 나도 그리 멀지 않다는 걸 알게 됨. LLM이 내게 잘 안 맞는 이유는 만든 문제가 조금 희귀하고 새롭기 때문이라 판단함. GitHub에 공개된 OAuth 케이스처럼 많이 학습된 대상이 아니면 LLM이 잘 못 따라옴
이런 종류의 반복적이고 이미 수백 번 구현된 코드는 AI에 완벽히 적합함. 전체 코드 1200줄 정도라 작은 규모임. AI 쓰고도 2일 이상 걸렸다는 게 오히려 의외임
최근 몇 달간 Cursor로 Claude를 이용해 나만의 greenfield 프로젝트를 진행하며 느낀 점은 첫째, 엄청나게 생산성이 높아졌음. 둘째, 이전보다 정신적으로 훨씬 더 피로함. 셋째, 단기간 내에도 도구들이 상당히 빨리 발전하기 시작하며, 위 두 가지 효과도 증폭되고 있음
내 경험 및 다른 개발자들과도 똑같음. LLM assisted coding은 실제로 생산성 향상에 큰 도움이 되지만, 에너지 소모가 그만큼 더 큼. 오히려 이상하게 느껴질 정도임
“이렇게 더 피곤하다”는 점에 질문함. 난 기존 방식보다 내 에이전트(Devstral)와 “페어 프로그래밍” 형태로 활용하고 있고, 코드 전체를 일일이 타이핑하는 것보다 리뷰가 훨씬 쉬움. time wise 관점에서 큰 장점임. vibe coding에선 코드베이스 맥락이 사라져 나중에 리뷰와 진입 장벽이 훨씬 커짐. 반면 페어 프로그래밍에선 맥락을 쌓으면서 진행되니 리뷰가 훨씬 빠르다고 느낌
나는 오히려 정반대임. AI가 사소한 디테일을 전부 알아서 챙겨주니까 오히려 큰 안도감 생김. 아키텍처 등 상위 목표에 집중할 수 있게 자유로워짐
Cloudflare 같은 회사에서 "Too Many Requests" 에러가 나는 게 꽤 유쾌하게 느껴짐