본문은 요즘IT와 번역가 David가 함께 마르코 베네데티(Marco Benedetti)의 글 <Vibe Coding as a Coding Veteran>을 번역한 글입니다. 마르코는 40년의 코딩 경력을 가진 베테랑 개발자이자 AI 연구 분야 박사로, 8비트 머신의 어셈블리 언어부터 최신 프로그래밍 언어까지 약 20개의 언어를 다뤄왔습니다. 과학 소프트웨어, 모바일 앱, 비즈니스 애플리케이션 개발 경험을 보유하고 있으며, 현재는 대규모 조직의 AI 팀에서 연구 고문으로 활동하고 있습니다.

본 글에서는 최첨단 AI 코딩 어시스턴트(Claude Sonnet 4, Gemini Pro 2.5, OpenAI o3)를 활용한 2주간의 실제 프로젝트 경험을 다룹니다. 저자는 파이썬으로 하노이 탑 솔버를 개발하면서 AI의 장단점, 생산성 변화, 심리적 영향 등을 세밀하게 분석하며, '바이브 코딩'이 개발 패러다임에 가져올 근본적인 변화를 탐구합니다.

분량이 길어 1, 2편으로 나누어 발행하며, 1편에서는 AI 코딩 어시스턴트를 활용해 하노이 탑 솔버를 개발한 실제 프로젝트 경험을 다룹니다.

*글에 포함된 각주(표시)는 '번역자주'입니다. 글에 포함된 링크는 원문에 따라 표시했습니다.

시작하며

AI가 코드를 작성하고, 리팩토링하고, 디버깅하는 동안 개발자는 '무엇을 만들 것인가'에만 집중하는 시대가 왔습니다. 이른바 '바이브 코딩'이라 불리는 이 새로운 개발 패러다임은 개발자 커뮤니티에 뜨거운 논쟁을 불러일으키고 있습니다. 수십 년의 코딩 경험을 가진 베테랑 개발자로서, 저는 이 전망에 흥미와 두려움을 동시에 느꼈습니다. "컴퓨터 프로그래밍의 예술"이 더 이상 예술이 아니라 똑똑한 "지적 로봇"이 운영하는 공장이 된 것은 아닐까요?

그래서 직접 테스트해보기로 했습니다. 2주 동안 총 40시간을 투자해 코딩 어시스턴트와 함께 실제 프로젝트를 진행했습니다. 파이썬으로 작성된 하노이 탑 솔버(약 5천 줄, 50개 파일, 20개 클래스)를 처음부터 끝까지 AI와 개발한 것입니다. 흥미롭게도 이 프로젝트는 교과서에 실린 AI 알고리즘으로 교과서 문제를 푸는 프로그램 만들기였습니다.

참고로, 저는 80년대 8비트 머신의 어셈블리 언어부터 시작해 40년간 약 20개의 프로그래밍 언어를 사용했고, 과학 소프트웨어부터 모바일 앱, 비즈니스 애플리케이션까지 다양한 프로젝트를 진행했습니다. 그리고 인공지능 분야에서 (LLM 이전 시대의) 박사 학위를 가지고 있습니다. AI 전문가가 AI 어시스턴트를 사용해 AI 코드를 만드는 셈이죠. 약간의 에코 챔버*이지만, 뭔가 흥미로운 통찰이 나올 것 같았습니다.

*에코 챔버: 같은 생각이 반복되어 증폭되는 현상

참고로 이 글은 AI가 작성한 것이 아닙니다. 몇 주에 걸쳐 직접 손으로 작성했습니다. 의심스러운 비유까지 포함해서 말이죠. 이 AI 에코 챔버에서 누군가는 인간의 관점을 유지해야 했으니까요!

1. 소프트웨어의 기능과 개발 방식

저는 하노이 탑 솔버를 푸는 프로그램을 파이썬으로 개발했습니다. 코더, 퍼즐 애호가, 컴퓨터 과학자, 또는 그저 호기심 많은 분이라면 이미 이 문제가 무엇인지 알고 계실 겁니다. 처음 들어보시는 분들을 위해 설명하자면, 특정 규칙에 따라 디스크를 막대 사이에서 옮기는 수학 퍼즐입니다. (이 짧은 영상을 확인해 보세요.)

이 퍼즐의 최단 해법은 디스크 개수가 늘어남에 따라 '폭발적으로' 길어집니다. 인간이 머릿속으로 그려내기는 매우 어렵지만, 전문화된 알고리즘이나 범용 검색 알고리즘을 통해 기계가 구성하기는 쉽습니다. 제가 구현한 프로그램은 고전적인 재귀 및 너비 우선 탐색부터 깊이 우선 탐색, 반복 심화, A* 탐색, 탐욕적 최선 우선 탐색, 양방향 너비 우선 탐색 등 최적 및 비최적 전략을 모두 다룹니다. 또한 일반화된 버전으로 (a) 임의의 시작/종료 구성과 (b) 한 번에 여러 디스크 들어올리기도 지원합니다.

이 알고리즘 핵심은 표현력 있는 CLI 문법을 갖추고, 단계별로 해법을 시각화할 수 있으며, 방법 간 성능을 벤치마크하고, 고전적·사용자 정의·무작위 초기 및 최종 구성을 처리할 수 있는 파이썬 스크립트에 내장되었습니다. 중요한 점은 이 코드 전체가 AI 어시스턴트와의 협업으로 생성되었다는 것입니다. 제가 직접 작성한 코드나 문서는 단 한 줄도 없습니다. 개발 프로세스는 AI 기반 IDE인 커서 내에서 저와 AI 어시스턴트 간의 긴 기술 대화 형태로 진행되었습니다.

약 40시간의 페어 프로그래밍 동안 300회 이상의 인간/AI 대화가 이루어졌습니다. 계산해보면 1회당 평균 8분이지만, 실제로는 교환 자체가 훨씬 빨랐고, 대부분의 시간은 AI가 만든 결과물을 평가하고 검토하는 데 사용되었습니다.

2. AI 어시스턴트, 어느 정도인가?

솔직히 말하면, 저는 이 AI 어시스턴트들이 보여주는 수준에 정말 감동했습니다. 코드와 자연어 지시사항 모두에서 절대적으로 놀라운 수준이었습니다. 여러 번 시스템에 프롬프트를 준 후 '내가 충분히 명확하게 설명하지 못한 건 아닐까' 생각했지만, 어시스턴트는 모든 것을 이해했을 뿐만 아니라 제 논리나 명확성의 공백까지 채워주었고, 제가 의도한 것을 저보다 더 잘 설명해 주었습니다.

프로그래밍 언어에 대한 숙달은 정확성, 생성 속도, 관용적 표현, 문법 지식, 라이브러리 활용 등에서 명백히 초인간적 수준입니다. 특히 인상 깊었던 순간은, 제가 해법이 없는 문제에 대해 예외를 발생시켜야 하는지 물었을 때였습니다. 어시스턴트는 풀 수 없는 퍼즐은 존재하지 않는다는 것을 증명했습니다. AI가 문제를 그래프 공간에 매핑하고 모순을 통해 추론하는 사고 체인*으로 올바르게 증명했기 때문에, 이것이 단순히 훈련 데이터에서 '복사'된 것이라고 생각하지 않습니다. 저도 같은 증명을 손으로 스케치하고 있었는데 완료하는 데 10분은 걸렸을 겁니다. AI 어시스턴트는 30초 만에 "증명 완료(QED)"를 썼습니다. 저는 30초 만에 AI의 증명을 읽고 확신했습니다. 복잡하고 어려운 작업에서 9분을 절약한 것입니다!

*사고 체인(Chain of Thought): AI가 단계별로 논리적 추론을 수행하는 방식

또한 AI 어시스턴트가 간단한 알고리즘 문제에서 저를 허를 찌른 적도 몇 번 있었습니다. 당황스러웠지만 겸허히 받아들일 수 있었습니다. 이 도구들의 비판단적 성격이 정말 신선하고 해방감을 주기 때문입니다.

3. 어떤 AI 어시스턴트를 사용했나?

모든 AI 코딩 어시스턴트가 똑같이 만들어진 것은 아닙니다. 저는 (2025년 7월 기준) 최고로 평가받는 세 가지 어시스턴트와 작업했습니다.

OpenAI의 o3, Anthropic의 Claude Sonnet 4, 그리고 Google의 Gemini Pro 2.5.

o3와의 코딩 경험은 오래가지 않았습니다.얼마 지나지 않아, 저는 o3를 직접 코드를 작성하는 용도가 아니라 "보조 AI 어시스턴트"로 선호한다는 것을 깨달았습니다. 레퍼런스 확인, 알고리즘 속성 검증, 언어 의미론에 대한 질문, 코딩 결과물을 수정하고 정리하는 스크립트 생성, 일러스트레이션 제작, 그리고... 바로 이 에세이 같은 것들에 대한 제2의 의견을 구하는 용도로 말이죠. o3는 이 모든 작업과 그 이상에서 탁월함을 입증했습니다.

이후 저는 Gemini로 옮겨갔습니다. 한 세션에서, 테이프를 읽어 그 위의 심볼이 서로 다른 진법으로 같은 정수를 나타내는지 확인하는 간단한 튜링 머신 스타일의 프로그램을 만들어달라고 요청했습니다. AI의 아버지가 계산에 대해 했던 원초적인 사고 실험을 떠올리게 하는 이런 추억의 작업을 최첨단 AI 어시스턴트들에게 맡기는 것이 재미있었습니다. 어쨌든, Gemini의 문체가 매력적이었고 코드도 효과적이었습니다. 그래서 저는 Google의 어시스턴트로 하노이 프로젝트 개발을 시작했습니다. 오고 가는 토큰에 대한 통계를 보면 이 프로젝트의 약 15%가 Gemini에서 나왔습니다(초기 설정 및 초기 구현).

하지만 호기심에 Claude를 시도해봤는데, 즉시 더 깊은 수준의 이해력, 통찰력, 참여도를 느꼈습니다. 코드를 다루는 방식과 저와 상호작용하는 방식 모두에서요. 그래서 나머지 개발 기간 동안 Claude를 사용했습니다. 예를 들어, 위에서 언급한 에피소드, 즉 AI 어시스턴트가 무의미한 예외로 코드를 오염시키는 대신 풀 수 없는 퍼즐의 부재를 증명한 것은 전형적인 Sonnet 스타일입니다.

나중에 인터넷을 둘러보니, Claude Sonnet 4가 복잡한 코딩 작업을 위한 매우 높이 평가되는 AI 어시스턴트라고 생각하는 사람이 저뿐만이 아니었습니다. (Claude 4 Opus가 Sonnet을 능가하지만 실행 비용이 비싸서, 이 정도 크기와 복잡도의 소프트웨어에는 과도할 것 같아 Sonnet을 선택했습니다.)

4. 코드에 대한 대화: 추상화 수준의 변화

이 AI 어시스턴트들과 대화하는 것은 마치 약간 신경다양성*을 지닌 사고방식과 아첨 재능이 있는, 믿을 수 없을 만큼 지식이 풍부하고 빠른 인간 프로그래머와 대화하는 것 같습니다. 이러한 대화의 추상화 수준은 상당히 높으며, 코딩 원시 요소의 영역보다 아이디어의 영역에 훨씬 더 가깝습니다. 한 가지 예를 들어보겠습니다.

*신경다양성(neurodivergent): 표준적인 사고방식과 다른 독특한 인지 패턴

[나] 다음과 같은 실행에서, 솔버가 특정 인스턴스에서 타임아웃되면, 해당 인스턴스의 실행 시간은 0으로 간주되고 인스턴스는 전혀 계산되지 않습니다. 이것은 약한 솔버에게 불공정한 이점을 주고 실제로 무슨 일이 일어났는지에 대한 왜곡된 관점을 제시합니다. 적어도 한 솔버가 최소 한 번 타임아웃에 도달했을 때 올바르게 해야 할 일은, 각 솔버가 타임아웃된 횟수를 표시하기 위해 "Timeouts"라는 이름의 열을 추가하고, 인스턴스가 0초가 아니라 "타임아웃 시간", 즉 이 예시에서는 5초에 해결된 것으로 간주하는 것이라고 생각합니다.

[이전 실행의 출력 데이터를 붙여 넣음]

[Claude] 완전히 맞습니다! 타임아웃 처리 방식에 있어서 이것은 중요한 문제입니다. 알고리즘이 타임아웃될 때, 현재는 시간 계산에서 제외되는데, 이는 성능에 대한 오해를 불러일으킵니다. 타임아웃 처리 코드를 살펴보고 이 문제를 수정하겠습니다.
[긴 추론이 이어지고, 4개 파일이 업데이트되고, 새 코드가 생성되고, 테스트가 실행됩니다. 모든 것이 예상대로 작동합니다.]

(관심이 있으시다면, 추가로 반 다스 정도의 주요 대화를 여기에서 찾을 수 있고, 더 긴 인간/AI 대화를 여기에서 볼 수 있습니다.)

이런 대화를 하고 코드가 성장하고 개선되는 것을 보면서, AI 어시스턴트와 대화하는 것이 충족감 있고, 몰입적이고, 도전적이고, 보상을 받는다는 것을 깨닫게 됩니다. 프로그래머들이 마음속 아이디어를 구현하는 데 완전히 집중할 때 경험하는 전형적인 몰입 상태에 들어가지만, 코드를 직접 작성하는 것보다 더 추상적이고 개념적인 수준에서입니다.

시간이 지나면, 이러한 기계들과 "좋은 대화"를 나누는 방법을 발견하게 됩니다. 놀랍게도, 그 요소들은 인간과 대화할 때와 동일합니다: 좋은 경청자가 되고, 올바른 질문을 하는 데 능숙해지는 것입니다.

특히 다음 두 가지를 개발해야 합니다.

1.질문/제안/힌트를 만드는 데 능숙해야 합니다. 결국 "프롬프트 엔지니어링"이 이유가 있어서 존재하는 것 같습니다. 통계학자라면 확률 분포가 너무 미묘하고 복잡해서 의미 있는 밀도 추정을 위해서는 좋은 사전 정보가 전제 조건이라고 말할 것입니다. 저는 통계학자가 아니기에, 오스카 와일드의 버전을 인용하자면 "질문은 결코 무례하지 않지만, 답변은 때때로 그렇다."

2.답변을 숙고하고, 파싱하고, 해석하고, 재고하고, 다듬고, 수정하는 데 능숙해야 합니다.좋은 AI 보조 소프트웨어 개발자는 주의 깊게 듣고, 말해진 모든 것을 감사히 여기며, 그 어느 것도 맹신하지 않는 사람입니다.

이것은 Knuth의 "문학적 프로그래밍"에 완전히 새로운 의미를 부여합니다. 자연어 명세와 그에 상응하는 인공 언어 구현을 공간(코드 페이지)상의 이야기로 섞는 대신, AI 어시스턴트와의 대화 중에 시간상으로 번갈아 가며 진행합니다. 게다가 이야기의 절반만 작성하면 됩니다.

5. AI의 결함, 오류, 편향: 현실적인 문제들

이 도구들은 완벽과는 거리가 멉니다. (조용히) 온갖 종류의 오류를 만들어내고, 크고 작은 결함을 가지고 있습니다. 코드에 관한 약 300회의 대화 중, 대략 20%는 AI가 도입한 불만족스러운 코드를 반복 수정하거나 AI가 도입한 문제/오류를 수정하는 데 소요되었습니다 (나머지는 행복하고 건설적인 인간/기계 상호작용이었습니다). 이 작은 프로젝트 과정에서 제가 겪은 몇 가지 오류와 문제의 예시를 아래에 나열했습니다.

필연적으로, 다음의 코딩 문제 목록은 빠르게 다소 기술적으로 변합니다. 개발자나 컴퓨터 과학자가 아니라면 내용이 약간 모호하게 느껴질 수 있으니, 완전히 건너뛰셔도 됩니다. 요점을 말씀드리자면,

60%는 "단지 결함"이었습니다. AI의 출력이 명백하게 원하는 것이 아니거나, 충분히 좋지 않거나, 약간 벗어난 불편함입니다. 올바르게 만들기 위해 많은 시간을 들여 반복해야 합니다.
나머지 40%는 버그가 있는 코드였습니다. 처음 보기에는 괜찮아 보이고 잘 작동하는 것처럼 보이지만, 신중한 분석과 고려 후에 상당한 수정이 필요하다는 것을 깨닫게 됩니다.

이제 몇 가지 구체적인 예시를 살펴보겠습니다.

"결함"

하나의 클래스를 "단순화"하려는 시도로 각각 불명확한 작업을 수행하는 10개의 클래스로 믿을 수 없을 정도로 복잡한 리팩토링을 제안
동시성과 병렬 실행의 차이를 완전히 놓치고, 제 요청과는 상당히 다른 것을 구현
인간이 파싱하고 이해하기 매우 어려운 수천 줄의 상용구 파일 생성
복잡한 리팩토링에서 길을 잃고 포기하거나 심지어 사과하기도 함
클래스와 메서드를 적절하지만 장황하고 미묘하게 불만족스러운 방식으로 명명
어려운 문제 해결의 가장 간단한 경로일 때 코드와 기능의 전체 섹션을 "자율적으로" 제거
명백한 이유 없이 여러 파일에 코드를 복제
방금 대체된 AI 생성 코드 조각을 제거하는 것을 잊음
어시스턴트 자체가 도입한 이름 불일치를 인식하지 못함
성능에 민감한 컨텍스트에서 동기화 오버헤드로 죽을 수 있는 다중 프로세스 솔루션을 제안
무작위 인스턴스 집합에 대한 집계 통계를 수행하기 위해 동일한 인스턴스를 반복해서 여러 번 해결하도록 제안
스크립트 사용자를 위한 출력에 무의미한 설명을 도입. 하나의 특정 인스턴스에 대한 해결책을 무작위 인스턴스 집합의 모든 구성원에 대한 해결책으로 주저 없이 제시
PEP 8 준수를 위해 간단한 파일 이름 변경만 필요했을 때, 상대 임포트를 사용하는 복잡한 패키지로 코드 전체를 재구성하도록 촉발

"오류"

명백한 이유 없이 구조화된 데이터 표현에서 중간 막대를 오른쪽 막대와 조용히 혼동하여 코드 정확성을 파괴
단위 테스트를 준비했는데, 직접 "True"를 반환했기 때문에 잘 통과함(실제 테스트 로직은 False로 평가됨)
최적이 아닌 알고리즘을 작성하고 최적이라고 주장함
특정 업데이트가 이루어졌고 완전히 테스트 되었다고 주장했지만, 신중한 검토 결과 그렇지 않음
완전히 제거하라고 요청받은 기능의 제거를 시각적 흔적만 숨겨서 가짜로 만듦
몇 번의 편집 상호작용 후 미묘한 회귀(regression) 도입
허용 가능한 휴리스틱으로 실제로는 허용 가능하지 않은 것을 사용하여 A* 최적성을 파괴
솔버가 실제로 실패하거나 타임아웃된 모든 인스턴스를 성공적으로 해결된 것으로 계산하여 출력 통계를 왜곡

이 목록은 계속될 수 있으며, 이것들은 단지 몇 가지 샘플일 뿐입니다.

또 다른 광범위한 패턴은 AI 어시스턴트들이 주로 대규모 산업용 코드베이스에서 훈련되어 문맥에 관계없이 "산업용 강도" 솔루션으로 기본 설정하는 경향입니다. 예를 들어, 제 코드베이스는 교육용 프로젝트에 의미 있는 이점 없이 상당한 오버헤드를 추가하고 가독성을 떨어뜨리는 광범위한 타입 주석을 포함합니다.

또 다른 현상은 린터*와정적 분석 도구를 만족시키는 쪽으로 편향되는 것입니다 - 그들의 지적을 수정하는 것이 인간 가독성이나 기능성을 개선하지 않고 복잡성만 추가하는 경우에도요. AI 어시스턴트들이 코드 명확성과 새로운 기능 구현을 희생하면서 "스타일에 대해 과도하게 최적화"하는 것을 반복적으로 발견했습니다.

*린터(linter): 코드의 스타일이나 잠재적 오류를 검사하는 도구

6. 신중한 채택이 필요한 이유

전반적으로, 코드를 "소유"하고 원하는 대로 작동하는지 확인하려면 AI 어시스턴트가 작성한 모든 것을 주의 깊게 읽어야 한다는 것입니다. 대부분의 AI 생성 코드는 훌륭하고 거의 완벽할 것이지만, 나머지 부분은 미묘하고 감지하기 어려운 방식으로 프로젝트 비전과 건전성을 탈선시킬 수 있습니다. 또한 원하는 방향으로 전체 개발을 강력하게 이끌어야 합니다. 그렇지 않으면 자신에게 의미가 없고 코드를 천천히 그러나 꾸준히 무색하게 만드는 산업용 데이터 구조와 모범 사례에 대한 AI의 기억에 의해 납치될 위험이 있습니다.

이 AI들의 멋지고 읽기 쉬운 클래스 레이아웃과 파일 시스템 구조에 대한 감각은 제 것과 근본적으로 다르지만, 이것은 개인 취향의 문제일 수 있습니다. 제가 좋아하는 파일 구조, 이름, 레이아웃 - 그리고 친근하고 명확한 클래스 이름에 도달하기 위해 많이 싸워야 했습니다.

또한 이 어시스턴트들은 (현재로서는) "많은", "적은", "예외적인", "평균적인" 등이 무엇인지에 대한 상식을 전혀 보이지 않습니다. 예를 들어, (버그로 인해) 3개 디스크 문제를 해결하는 데 3.5GB의 메모리(!!)를 소비한 것을 측정한 후, 어시스턴트는 모든 것이 잘 되었다고 선언하고 새로운 기능 구현을 진행할 수 있다고 했습니다.

7. 생산성 향상

저는 본질적으로 모호한 자연어를 (간접적인) 프로그래밍 도구로 사용하는 것의 실현 가능성과 효율성에 대해 심각한 의구심을 가지고 있었습니다. 엄격한 형식 의미론을 갖춘 인공 언어로의 모든 해석과 번역을 중간에서 기계가 수행하는 방식 말이죠. 이제는 의구심이 없습니다: LLM 기반 AI 코딩 어시스턴트는 극도로 유용하고, 믿을 수 없을 만큼 강력하며, 진정으로 활력을 불어넣어 줍니다.

하지만 그들이 완전히 유용하고 안전한 것은 여러분이 무엇을 하고 있는지 알고 있고, 그들이 하고 있을 수 있는 것을 확인하고 (재)지시할 수 있는 경우에만 가능합니다. 자신을 신뢰할 수 있다면 그들을 신뢰할 수 있습니다.

그리고 이 경우, 생산성 향상은 부인할 수 없습니다. 특정 작업에서는 제 생각에 쉽게 10배-100배입니다. 코드를 문서화하고, 단위 테스트를 작성하고, (너무 복잡하지 않은) 리팩토링을 수행하고, 오류 메시지를 작성하고, 예외를 생성하고 캡처하고, 일관되고 올바른 동작을 위해 코드를 확인하고, 교과서적이거나 표준적인 로직/알고리즘/데이터 구조를 코딩하고, 엄청난 양의 상용구 코드를 작성하고, 관용적인 소스 코드를 생성해야 할 때, 그리고 위의 모든 것을 수십 번 반복해야 할 때 말이죠.

코딩 속도가 증가하기보다는 오히려 감소하는 몇 가지 상황이 있습니다. 특히 AI 에이전트가 어려움을 겪고 있는 것을 보았을 때 직접 코딩하지 않고 단순히 원하는 것과 구현 방법을 AI 어시스턴트에게 설명하는 데 고집을 부릴 때 그렇습니다. 하지만 저는 "완전히 합성되었지만 완전히 인간이 지시한 소스 코드", 즉 "메타 프로그래밍 언어로서의 영어" 시나리오를 테스트하기 위해 의도적으로 그렇게 했습니다.

전반적으로, 이 특정 실험에서, AI가 생성한 모든 코드와 문서를 검토한 후, 저는 대략 2배 속도로 작업했다고 추정합니다. 인정하건대 생산성에 불리한 저의 작업 스타일에도 불구하고, 평소 생산성의 두 배입니다. 그것은 많은 것입니다. 결과 코드는 일부 측면에서는 제가 직접 작성했을 것보다 약간 낫고, 다른 측면에서는 더 나쁩니다. 하지만 전반적으로 꽤 비슷합니다.

AI 어시스턴트와 함께 작업하든 그렇지 않든 사실이라고 느끼는 한 가지 생산성 관련 언급은, 약간의 완벽주의자라면 코드가 충분히 좋아 보이거나 완전히 다듬어진 것처럼 보이지 않을 것이라는 점입니다. 끝없이 코드베이스를 리팩토링하고 정리하는 것이 당신이든 당신을 대신해 반복하는 AI 어시스턴트든, 절대 출시되지 않을 것입니다.

이것은 현재의 실험적 프로젝트에도 적용됩니다. 코드에 리팩토링과 개선의 (때로는 명백한) 기회가 남아 있다는 것을 충분히 알고 있지만, 시간 투자 대비 품질 수익이 감소하기 시작했을 때 그만두기로 했습니다. 적어도, 결정한 것이 저였다고 생각합니다. 아니면 제 AI 어시스턴트가 플러그를 뽑아달라고 애원했던 걸까요?

※2편에서 계속됩니다.

2편에서는 AI 어시스턴트와의 협업이 개발자의 생산성, 역할, 사고방식에 어떤 영향을 미치는지, 그리고 앞으로 개발자의 일은 어떻게 달라질지를 중심으로 살펴봅니다.

<원문>

Vibe Coding as a Coding Veteran