나는 LLM을 마치 컨설팅 회사처럼 보게 되었음, 요청할 때마다 전문가나 인턴이 내 코드를 써줄 확률이 50%씩 있다는 느낌임, 그리고 누가 쓰는지 알 방법이 없음. 이걸 받아들이고 대충 코딩할 때도 있지만, 결과가 중요한 경우엔 한 줄 한 줄 내가 직접 다 읽어야 함. 코드를 읽는 것이 쓰는 것보다 어렵기 때문에 시간이 더 걸리는 데, LLM 덕분에 이제는 코드를 직접 쓰는 게 게을러졌음. 제일 좋았던 건 Cursor의 자동완성 기능이었음, 3-4줄씩 써주니까 검증하기도 쉽고, API나 함수 시그니처를 매번 찾지 않아도 되는 점이 매우 유용했음
나도 비슷한 경험을 했음, vibe-coding 이후로 너무 게을러졌음. 내 역할이 개발자에서 코드 리뷰어나 수정자로 빠르게 바뀌었음. 전체적으로는 긍정적임, 프론트엔드 컴포넌트와 API endpoint를 반복하는 일이 너무 지루해졌으니 이런 잡일은 AI에게 넘기고 나는 감독하는 게 만족스러움
나 역시 느낀 점인데 "코드를 읽는 게 쓰는 것보다 어렵다는 것"에 동감함. 특히, 안 좋은 코드는 읽는 게 쓰는 것보다 훨씬 힘들고, 좋은 코드는 읽는 게 쓰는 것보다 더 쉬움
이걸 마치 시간과 도박하는 기분이라고 설명함. 매번 VSCode에서 Cline extension을 쓸까 말까 고민하면서 “이번에는 쓸만한지” “내가 이걸 썼을 때 결과가 괜찮을 확률이 얼마인지” 따져봄. 간단한 리팩토링에는 AI를 잘 쓰지만, 최근 일주일 동안 5-6번은 확률이 낮다고 느껴서 그냥 직접 했음. AI를 쓰면서 점점 어떤 작업은 AI가 쉽게 하고, 어떤 작업은 직접 해야 한다는 감이 생김
자동완성과 vibe-coding의 중간 방식도 있음. 효과적으로 쓰려면 상황에 맞게 AI에게 맥락을 잘 주어 AI가 상상력을 동원하지 않도록 하고, 먼저 계획을 짜게 한 뒤, 시간이 되면 구현을 실시간으로 지켜보고 승인하는 식임. 중간에 멈추고 교정하기도 하고, 이걸 반복함. AI가 코딩하는 동안 나는 다음 할 일을 준비함. 대량 작업도 하나씩 분할해서 짧은 시간 내 검토 가능한 단위로 AI에게 맡김
기존 코드베이스에 이미 잘 정착된 패턴이 있을 때, 여러 줄 자동완성 기능이 가장 적합하다고 느낌. 새로운 기능을 추가할 때는 구조만 잡아주고 주석 달면서, 코드 블럭에 몇 글자만 입력하면 대부분 Tab 키로 자동입력이 가능함
잘 알려진 문제와 익숙한 언어를 선택한 점이 AI의 동작에 영향을 미쳤다고 생각함. AI의 유용성은 학습 데이터와 강한 상관관계가 있음, 파이썬이나 해당 문제에 대한 데이터가 풍부하니까 효과가 좋았던 것임. 만약 문제나 언어/생태계가 다르면 어떤 결과가 나올지 궁금함. 그래도 아주 흥미로운 읽을거리였음
맞는 얘기라고 봄. 나는 게임 개발을 하는데, 거의 C/C++이고 약간은 Python, C#임. 게임 개발 영역에서 LLM은 일종의 고무 오리(즉, 말을 걸어 정리하는 용도)에 가까움. AI가 만들어주는 코드는 대부분 시작점이나 웃음거리로만 쓸 수 있음. 그 이상은 전혀 쓸모없음. 게임 개발 인구도 적고, 관련 블로그나 자료도 적으니 모델이 학습할 기회도 적음. 게임 업계는 워낙 보수적이고 회사 내부 노하우가 많은 이유가 있음
난 AI 모델 테스트로 8비트 어셈에서 최근 발명된 연산을 시키는 식의 쿼리를 날림. 예를 들어 24비트 posit 곱셈을 8비트 AVR로 구현해달라고 해봄. 지금까지 성공한 모델이 없음. 이유는 대부분 8비트 레지스터에 8비트 이상을 넣으려고 해서임. 알고리즘적으로는 방향을 잡은 것 같지만, 8비트 제약을 끝까지 유지하지 못함
완전히 동의함. Haskell에서 LLM을 써봤는데 Go에 비해 성능이 확실히 떨어졌음. 물론 이건 1년 전 GPT 3.5 기준임
나는 Julia로 고성능 데이터 파이프라인을 다룰 때 꽤 만족스러운 결과를 얻었음
내 경험상 Prolog에 대해서는 ChatGPT가 거의 쓸모없음
만약 누군가 나보고 “이 문서 5장에서 언급된 모든 실수를 할 개발자와 함께 일하라”고 하면 절대 안 할 것 같음. 그런데 저자는 “AI 모델 없이 앞으로는 코딩 안 할 것”이라 끝맺음. 나는 저자만큼 관대한 성격이 아닌 듯함
"AI guy vibing AI code for AI application"이라면 당연한 결과라고 생각함. Marco가 처음부터 "AI 에코 챔버"라며 경고했는데 소임을 다했다고 봄
어떤 사람들은 코드를 얼마나 잘 썼는지보다는 생산성 자체에 더 가치를 둠. 나는 Claude Code 덕분에 생산성이 엄청나게 올라감. 매번 짬날 때 잠깐씩 작업하고, 나머진 기계가 알아서 하니 부모로서도 정말 편함. 직업 개발자가 아닌데도 나와 같은 사람들을 위해 Claude나 유사 도구가 일의 방식을 완전히 바꾼 경험임
글이 아주 훌륭했음, 아직 읽는 중인데 워낙 방대해서 오래 걸림. 한 가지 언급하고 싶은 건, “vibe coding”이란 코드를 전혀 읽지 않는 방식임. LLM만으로 코딩하되 결과물을 단계마다 꼭 검토하는 이 방식을 지칭하는 용어가 필요해 보임
예전 CASE(Computer-aided Software Engineering)라는 약어를 다시 쓸 수도 있음
그냥 “코드 리뷰”라고 부르면 됨. 내가 직접 작성하지 않은 코드에는 절대로 책임을 지지 않겠음
나는 “프로코딩(Pro-coding)”이라고 부름. 전문성이나 프로세스, 최소한 어느 정도의 형식을 의미함. AI의 유무는 따지지 않고, vibe-coding과 그렇지 않은 게 중요한 기준이라고 생각함
“프롬프트 코딩(Prompt coding)”이나 그냥 “프롬프트 작성”이라고도 함. “이걸 위해 마이크로서비스 하나 프롬프트로 만들어보자”, “요즘 무슨 프롬프트 썼어?”, “커밋 로그를 보니 이제 프롬프트 코딩이 전체 결과물의 50%임. 연봉 올려야겠네” 같은 대화가 생김
가장 인상적인 점은 AI를 운영하는 사람이 충분한 지식과 역량이 있기에 필요하다면 직접 코드를 다 짤 수도 있는 수준이었다는 것임. 이미 여러 번 언급됐겠지만, 앞으로는 “AI를 쓴 개발자 vs 안 쓴 개발자”의 경쟁이 될 전망임. 특히 이런 부분이 인상 깊었음:
“자연어가 본질적으로 모호하기 때문에 (간접적으로) 프로그래밍 도구로서 기계가 해석·변환하는 게 정말 효과적일까 심각한 의문이 들었음. 이제 의심은 사라졌음. LLM 기반 AI 코딩 도구는 정말 유용하고 강력하며, 나의 동력을 북돋아줌.
하지만 이것이 제대로 유용하고 안전하려면 사용자가 무슨 일을 하는지 알고, AI가 뭘 하고 있는지 파악하고 직접 수정·지시할 수 있어야 함. 자기 자신을 신뢰할 수 있다면 AI도 신뢰할 수 있음”
바로 그거임. 그래서 사실 대중에 알려진 ‘vibe coding’—비전문가가 그냥 복사/붙여넣기로 운영하는 소프트웨어 구현—라고 부르긴 어려움. 강력한 도구이지만, 결함을 찾을 전문성이 있는 사람이 써야 효과적임
우리 팀에는 코딩 에이전트를 루프에 넣어두고 활용한 적 있음. 방법은 간단함, 문제를 주고 환경과 라이브러리 세팅을 끝낸 후 코드를 반복적으로 고치고 결과를 체크함. 이렇게 반복 개선함. 예를 들어 여러 LLM이 만든 diff를 파일에 적용하는 새로운 메서드를 만들었는데, 각기 다른 모델이 잘 하는 영역이 달라서 가장 성능이 좋은 접근을 찾아낼 수 있었음. 인간이 이걸 이렇게 반복적으로 실험하는 건 거의 불가능하다고 생각함
주로 어떤 문제들을 던져줬는지 궁금함
본문 중에서 “AI assistant가 메모리 3.5GB를 쓰는(심각한 버그 때문) 상황에서, ‘전혀 문제없음!’ 이라고 했다는 얘기”가 나오는데, 이거 내 동료들 얘기랑도 닮았음
분명히 하자면, 이건 vibe coding 실험이 아님. 저자는 단계마다 코드 변경을 감독하고 검토했으며, 실수와 비효율적인 솔루션을 잡아내고 LLM과 협업하여 개선을 했음. “X를 만들어줘”라고만 한 뒤 그냥 결과를 받아들인 게 전혀 아님. (비판이 아니라, 실제로 깊이 있는 학습이 있었고 “진짜 vibe-coding”만 했다면 오히려 별로 배울 게 없었을 것 같음)
오랜 기간 프로그래머로 일하면서 Claude Code로 아주 긍정적인 경험을 하고 있음. 내가 직접 코드를 다 쓸 수도 있고, 더 잘 쓸 수 있다고도 확신함, 아마 속도도 더 빠름. 하지만 내겐 시간과 에너지가 부족함. 그래서 요구사항과 코드 리뷰에 집중하고, 세부 구현은 CC(SK: Claude Code)에 맡겨 개인 생활에 집중할 수 있음. 이 점이 정말 큰 가치임. 덕분에 다시 코딩을 하게 만들어준 도구임
Hacker News 의견
나는 LLM을 마치 컨설팅 회사처럼 보게 되었음, 요청할 때마다 전문가나 인턴이 내 코드를 써줄 확률이 50%씩 있다는 느낌임, 그리고 누가 쓰는지 알 방법이 없음. 이걸 받아들이고 대충 코딩할 때도 있지만, 결과가 중요한 경우엔 한 줄 한 줄 내가 직접 다 읽어야 함. 코드를 읽는 것이 쓰는 것보다 어렵기 때문에 시간이 더 걸리는 데, LLM 덕분에 이제는 코드를 직접 쓰는 게 게을러졌음. 제일 좋았던 건 Cursor의 자동완성 기능이었음, 3-4줄씩 써주니까 검증하기도 쉽고, API나 함수 시그니처를 매번 찾지 않아도 되는 점이 매우 유용했음
나도 비슷한 경험을 했음, vibe-coding 이후로 너무 게을러졌음. 내 역할이 개발자에서 코드 리뷰어나 수정자로 빠르게 바뀌었음. 전체적으로는 긍정적임, 프론트엔드 컴포넌트와 API endpoint를 반복하는 일이 너무 지루해졌으니 이런 잡일은 AI에게 넘기고 나는 감독하는 게 만족스러움
나 역시 느낀 점인데 "코드를 읽는 게 쓰는 것보다 어렵다는 것"에 동감함. 특히, 안 좋은 코드는 읽는 게 쓰는 것보다 훨씬 힘들고, 좋은 코드는 읽는 게 쓰는 것보다 더 쉬움
이걸 마치 시간과 도박하는 기분이라고 설명함. 매번 VSCode에서 Cline extension을 쓸까 말까 고민하면서 “이번에는 쓸만한지” “내가 이걸 썼을 때 결과가 괜찮을 확률이 얼마인지” 따져봄. 간단한 리팩토링에는 AI를 잘 쓰지만, 최근 일주일 동안 5-6번은 확률이 낮다고 느껴서 그냥 직접 했음. AI를 쓰면서 점점 어떤 작업은 AI가 쉽게 하고, 어떤 작업은 직접 해야 한다는 감이 생김
자동완성과 vibe-coding의 중간 방식도 있음. 효과적으로 쓰려면 상황에 맞게 AI에게 맥락을 잘 주어 AI가 상상력을 동원하지 않도록 하고, 먼저 계획을 짜게 한 뒤, 시간이 되면 구현을 실시간으로 지켜보고 승인하는 식임. 중간에 멈추고 교정하기도 하고, 이걸 반복함. AI가 코딩하는 동안 나는 다음 할 일을 준비함. 대량 작업도 하나씩 분할해서 짧은 시간 내 검토 가능한 단위로 AI에게 맡김
기존 코드베이스에 이미 잘 정착된 패턴이 있을 때, 여러 줄 자동완성 기능이 가장 적합하다고 느낌. 새로운 기능을 추가할 때는 구조만 잡아주고 주석 달면서, 코드 블럭에 몇 글자만 입력하면 대부분 Tab 키로 자동입력이 가능함
잘 알려진 문제와 익숙한 언어를 선택한 점이 AI의 동작에 영향을 미쳤다고 생각함. AI의 유용성은 학습 데이터와 강한 상관관계가 있음, 파이썬이나 해당 문제에 대한 데이터가 풍부하니까 효과가 좋았던 것임. 만약 문제나 언어/생태계가 다르면 어떤 결과가 나올지 궁금함. 그래도 아주 흥미로운 읽을거리였음
맞는 얘기라고 봄. 나는 게임 개발을 하는데, 거의 C/C++이고 약간은 Python, C#임. 게임 개발 영역에서 LLM은 일종의 고무 오리(즉, 말을 걸어 정리하는 용도)에 가까움. AI가 만들어주는 코드는 대부분 시작점이나 웃음거리로만 쓸 수 있음. 그 이상은 전혀 쓸모없음. 게임 개발 인구도 적고, 관련 블로그나 자료도 적으니 모델이 학습할 기회도 적음. 게임 업계는 워낙 보수적이고 회사 내부 노하우가 많은 이유가 있음
난 AI 모델 테스트로 8비트 어셈에서 최근 발명된 연산을 시키는 식의 쿼리를 날림. 예를 들어 24비트 posit 곱셈을 8비트 AVR로 구현해달라고 해봄. 지금까지 성공한 모델이 없음. 이유는 대부분 8비트 레지스터에 8비트 이상을 넣으려고 해서임. 알고리즘적으로는 방향을 잡은 것 같지만, 8비트 제약을 끝까지 유지하지 못함
완전히 동의함. Haskell에서 LLM을 써봤는데 Go에 비해 성능이 확실히 떨어졌음. 물론 이건 1년 전 GPT 3.5 기준임
나는 Julia로 고성능 데이터 파이프라인을 다룰 때 꽤 만족스러운 결과를 얻었음
내 경험상 Prolog에 대해서는 ChatGPT가 거의 쓸모없음
만약 누군가 나보고 “이 문서 5장에서 언급된 모든 실수를 할 개발자와 함께 일하라”고 하면 절대 안 할 것 같음. 그런데 저자는 “AI 모델 없이 앞으로는 코딩 안 할 것”이라 끝맺음. 나는 저자만큼 관대한 성격이 아닌 듯함
"AI guy vibing AI code for AI application"이라면 당연한 결과라고 생각함. Marco가 처음부터 "AI 에코 챔버"라며 경고했는데 소임을 다했다고 봄
어떤 사람들은 코드를 얼마나 잘 썼는지보다는 생산성 자체에 더 가치를 둠. 나는 Claude Code 덕분에 생산성이 엄청나게 올라감. 매번 짬날 때 잠깐씩 작업하고, 나머진 기계가 알아서 하니 부모로서도 정말 편함. 직업 개발자가 아닌데도 나와 같은 사람들을 위해 Claude나 유사 도구가 일의 방식을 완전히 바꾼 경험임
글이 아주 훌륭했음, 아직 읽는 중인데 워낙 방대해서 오래 걸림. 한 가지 언급하고 싶은 건, “vibe coding”이란 코드를 전혀 읽지 않는 방식임. LLM만으로 코딩하되 결과물을 단계마다 꼭 검토하는 이 방식을 지칭하는 용어가 필요해 보임
예전 CASE(Computer-aided Software Engineering)라는 약어를 다시 쓸 수도 있음
그냥 “코드 리뷰”라고 부르면 됨. 내가 직접 작성하지 않은 코드에는 절대로 책임을 지지 않겠음
나는 “프로코딩(Pro-coding)”이라고 부름. 전문성이나 프로세스, 최소한 어느 정도의 형식을 의미함. AI의 유무는 따지지 않고, vibe-coding과 그렇지 않은 게 중요한 기준이라고 생각함
“프롬프트 코딩(Prompt coding)”이나 그냥 “프롬프트 작성”이라고도 함. “이걸 위해 마이크로서비스 하나 프롬프트로 만들어보자”, “요즘 무슨 프롬프트 썼어?”, “커밋 로그를 보니 이제 프롬프트 코딩이 전체 결과물의 50%임. 연봉 올려야겠네” 같은 대화가 생김
가장 인상적인 점은 AI를 운영하는 사람이 충분한 지식과 역량이 있기에 필요하다면 직접 코드를 다 짤 수도 있는 수준이었다는 것임. 이미 여러 번 언급됐겠지만, 앞으로는 “AI를 쓴 개발자 vs 안 쓴 개발자”의 경쟁이 될 전망임. 특히 이런 부분이 인상 깊었음:
“자연어가 본질적으로 모호하기 때문에 (간접적으로) 프로그래밍 도구로서 기계가 해석·변환하는 게 정말 효과적일까 심각한 의문이 들었음. 이제 의심은 사라졌음. LLM 기반 AI 코딩 도구는 정말 유용하고 강력하며, 나의 동력을 북돋아줌.
하지만 이것이 제대로 유용하고 안전하려면 사용자가 무슨 일을 하는지 알고, AI가 뭘 하고 있는지 파악하고 직접 수정·지시할 수 있어야 함. 자기 자신을 신뢰할 수 있다면 AI도 신뢰할 수 있음”
우리 팀에는 코딩 에이전트를 루프에 넣어두고 활용한 적 있음. 방법은 간단함, 문제를 주고 환경과 라이브러리 세팅을 끝낸 후 코드를 반복적으로 고치고 결과를 체크함. 이렇게 반복 개선함. 예를 들어 여러 LLM이 만든 diff를 파일에 적용하는 새로운 메서드를 만들었는데, 각기 다른 모델이 잘 하는 영역이 달라서 가장 성능이 좋은 접근을 찾아낼 수 있었음. 인간이 이걸 이렇게 반복적으로 실험하는 건 거의 불가능하다고 생각함
본문 중에서 “AI assistant가 메모리 3.5GB를 쓰는(심각한 버그 때문) 상황에서, ‘전혀 문제없음!’ 이라고 했다는 얘기”가 나오는데, 이거 내 동료들 얘기랑도 닮았음
분명히 하자면, 이건 vibe coding 실험이 아님. 저자는 단계마다 코드 변경을 감독하고 검토했으며, 실수와 비효율적인 솔루션을 잡아내고 LLM과 협업하여 개선을 했음. “X를 만들어줘”라고만 한 뒤 그냥 결과를 받아들인 게 전혀 아님. (비판이 아니라, 실제로 깊이 있는 학습이 있었고 “진짜 vibe-coding”만 했다면 오히려 별로 배울 게 없었을 것 같음)
오랜 기간 프로그래머로 일하면서 Claude Code로 아주 긍정적인 경험을 하고 있음. 내가 직접 코드를 다 쓸 수도 있고, 더 잘 쓸 수 있다고도 확신함, 아마 속도도 더 빠름. 하지만 내겐 시간과 에너지가 부족함. 그래서 요구사항과 코드 리뷰에 집중하고, 세부 구현은 CC(SK: Claude Code)에 맡겨 개인 생활에 집중할 수 있음. 이 점이 정말 큰 가치임. 덕분에 다시 코딩을 하게 만들어준 도구임