반쯤 전념하는 바이브 코더 저널

Source: Dev.to

(번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.)

Season 5 Prep & AI‑Assisted Coding

Side note: Season 5 starts NEXT WEEK! Episodes drop on Thursdays – just like our Adventures here.
Head over to the YouTube channel, leave a like, a comment, an emoji, and hit Subscribe. It’s free and helps more people find our Adventures together!

Why I’m Using AI

While building the app for the upcoming season I’ve been using AI as a companion. It’s:

• Readily available – no need to wade through docs for every random thing I need to remember.
• Fast – often quicker than a manual search.
• Curiosity‑driven – there’s a ton of hype about AI replacing software engineers. Is it true? The best way to find out is to try it out.

(We should chat sometime about the value of building in public and learning this way… 💡💡💡)

My “Half‑Committed” Vibe‑Coder Approach

I don’t just yeet requirements at a model and let it generate everything.
Instead I:

1. Write as much code myself as I ask the model to write.
2. Use the model as a sounding board and for exploration.

I also have a day‑job in software development, so some observations come from that work too.

시즌 5 준비 & AI‑보조 코딩

부가 설명: 시즌 5가 다음 주에 시작됩니다! 에피소드는 목요일에 공개되며, 여기서 우리 모험과 같은 일정이에요.
유튜브 채널에 가서 좋아요, 댓글, 이모지를 남기고 구독을 눌러 주세요. 무료이며 더 많은 사람들이 우리 모험을 함께 찾을 수 있게 도와줍니다!

내가 AI를 사용하는 이유

다가오는 시즌을 위한 앱을 만들면서 AI를 동반자로 활용하고 있습니다. 이유는 다음과 같습니다:

• 즉시 사용 가능 – 기억해야 할 사소한 내용들을 문서를 뒤적일 필요가 없습니다.
• 빠름 – 수동 검색보다 종종 더 빠릅니다.
• 호기심 기반 – AI가 소프트웨어 엔지니어를 대체한다는 과대광고가 많습니다. 과연 사실일까요? 가장 좋은 방법은 직접 사용해 보는 것입니다.

(공개적으로 만들고 배우는 가치에 대해 언제든 이야기해요… 💡💡💡)

나만의 “반‑전념” 바이브‑코더 접근법

요구사항을 모델에 뿌려버리고 모든 것을 자동 생성하게 하지 않습니다.
대신에:

1. 모델에게 코드를 작성해 달라고 요청하는 만큼, 직접 코드를 많이 작성합니다.
2. 모델을 아이디어 검증용 보드와 탐색 도구로 활용합니다.

저는 소프트웨어 개발을 전업으로 하고 있기 때문에, 일부 관찰은 그 업무 경험에서도 나옵니다.

Source: …

몇 주간 코딩 후 관찰

1. 자유도가 너무 높으면 머리 굴리는 데 시간 많이 듦

시즌 5 프로젝트는 게임이며, 몇 가지 기본 패턴을 포함합니다:

• 게임 Event Loop
• 화면 painting logic
• Loading & Saving

전체 요구사항 문서를 만들지는 않습니다 – 취미 개발자들은 기본을 몇 개 만들고, 동작하게 만든 뒤에 기능을 추가하는 경향이 있죠.

제가 “Breakout 클론 게임을 만들 생각이다”라고 말했을 때, LLM은 바로 Pygame 메인 루프를 생성해 윈도우 안에서 바로 게임을 초기화했습니다.

저는 이를 멈춰야 했습니다:

“잠깐, 사용자가 바로 게임에 들어가기 전에 메인 메뉴가 있으면 경험이 더 나아지지 않을까요?”

모델은 즉시 메인 메뉴 구현을 추가했지만, 저는 아직 빈 프로젝트 구조가 남아 있다는 점을 상기시켜야 했습니다:

• 코드 파일은 어디에 두나요?
• 아트 에셋은 어디에 보관하나요?
• 변수를 하드코딩하지 않고 설정 파일을 어떻게 다루나요?
• 자동화 테스트는 어떻게 할까요?

핵심: 인간 개발자를 완전히 없앨 수는 없습니다. AI는 기쁘게 맞추려는 욕심에 프로젝트를 유지보수하기 쉽게 만드는 설계 사고를 건너뛰고, 마치 완전 초보 개발자처럼 행동합니다.

졸업한 지 얼마 안 된 신입을 최소한의 가이드만으로 미션‑크리티컬 애플리케이션에 투입한다면 어떨까요? 그렇지 않다면, AI에게 왜 믿고 맡겨야 할까요?

2. “간단한” 작업이 긴 반복으로 변함

저는 코파일럿에게 직접 하기 귀찮은 삼각함수 계산용 작은 함수를 만들어 달라고 요청했습니다.

결과: 여섯 번의 반복 끝에 기능은 동작했지만 정확히 맞지는 않았습니다. 우리는 몇 시간 동안 어떻게 동작하는지 논쟁했으며, 얼마나 많은 토큰이 소모됐는지 궁금해졌습니다.

제 “시간‑절약” 바이브‑코딩 프롬프트가 실제로는 수동으로 해결하는 것보다 더 많은 시간을 잡아먹었습니다.

이것은 일회성이 아니라, 반복해서 같은 장애물을 마주하고 있습니다.

3. 모델은 말을 많이 함

한 줄 코드를 요청하면 모델은 그 전체 배경을 설명하려 듭니다. 간결함을 요구해도 여전히 부가 설명을 덧붙입니다.

호출당 토큰이 과금되는 세상에서는 이런 장황함이 비용 효율적이지 않으며, 거의 의심스러울 정도입니다. 토큰을 판매한다면, 각 호출에서 가능한 한 많은 토큰을 절약하고 싶겠죠.

4. 실제 리팩토링 고통

업무에서 1,000줄 파이썬 모듈을 리팩토링하라는 과제를 받았습니다. “바이브‑코딩”의 위험 신호가 명백했습니다:

요약

• 인간의 판단이 여전히 중요합니다. AI는 특정 작업을 가속화할 수 있지만, 코드 유지보수를 가능하게 하는 중요한 설계 및 아키텍처 결정을 종종 건너뜁니다.
• 토큰 비용에 주의하세요. 장황한 응답은 예산을 빠르게 소진할 수 있습니다.
• AI를 대체가 아닌 파트너로 활용하세요. AI를 완전 자율 코더가 아니라 멘토링하는 주니어 개발자로 대하십시오.

다음 단계는?

• 시즌 5 게임 개발을 계속하되, 모델이 코드를 작성하기 전에 설계 단계를 강화하십시오.
• 프로젝트 구조 체크리스트(자산, 설정, 테스트 등 폴더)를 유지하여 AI에게 파일 위치를 상기시킵니다.
• 토큰 제한을 설정하고 가능한 경우 간결한 답변을 요청하십시오.

즐거운 코딩 되세요, 그리고 다음 에피소드는 목요일에 뵙겠습니다! 🎮🚀

Cognitive Complexity Calculator

Context

코드는 작동합니다 – 출력이 입력과 일치합니다. 코딩을 한 번도 해보지 않은 사람이 이 코드를 보면 흥분할 것이며(그게 바로 이야기의 핵심입니다: 비즈니스 임원들이 실행되는 모습을 보고 우리가 얼마나 빨리 전달했는지에 감탄했습니다).

하지만 이 모듈은 **우리가 앞으로 만들게 될 사용 사례군의 첫 번째 사용 사례일 뿐이며, 각각은 전체 애플리케이션 프레임워크에 연결되는 맞춤형 버전이 필요합니다.

현재 상태로는 이 코드를 다른 개발자가 새로운 사용 사례를 만들 때 예시로 사용할 수 없습니다.

생각해 보세요: 두 번째 사용 사례를 만들라는 새로운 요구가 들어옵니다. 개발자는 무엇을 할까요?
첫 번째 것을 봐요! 스파게티 코드를 풀어내는 데 며칠을 보낼 것입니다.

Anticipated Counter‑Arguments

1. “The Junior Dev Analogy is a Feature, Not a Bug”

Blink, you should be scaling up so you have a collection of a hundred Junior Devs doing your bidding, while you’re the Architect!

표면적으로는 설득력 있고 힘을 실어주는 것처럼 보이지만, 우리가 듣는 과대광고와는 맞지 않습니다. 방금 LinkedIn 피드를 새로 고쳤는데, 처음 세 개의 포스트는 AI 에이전트가 소프트웨어 엔지니어링을 끝냈다고 주장하는 내용이었습니다.

• 질문: 우리는 권한을 부여받고 있는 건가요, 아니면 파괴되고 있는 건가요?
• 답변: 둘 다 될 수는 없습니다.

2. “Vibe Coding vs. Agentic Workflows” Gap

Blink, you’re just doing it wrong. These problems exist because you aren’t using $SOME_FRAMEWORK or $SOME_MODEL.

누군가가 하나만 더 추가하면 모든 이점을 얻을 수 있다고 약속할 때 저는 매우 의심스럽습니다. 마치 “하나만 더 필요해”라는 영원한 영업 전략—피라미드 사기와도 같습니다.

3. “Ensloppification” Is a Human Discipline Issue

Blink, you could actually cure ensloppification with AI if you just prompt it to produce clean code…

The Core Problem

AI는 누구나 앱을 만들 수 있는 방법으로 마케팅되고 있으며, 누구든 기술 수준에 관계없이 사용되고 있습니다.

• 인간의 책임: 개발자는 궁극적으로 코드 품질에 대한 책임이 있습니다.
• 현실: 많은 개발자들은 아직 이를 인식하지 못하고, 겉보기엔 멋지고, 동작도 하며, 수익까지 창출할 수 있는 앱을 배포하지만, 그 앱은 버그가 많고, 보안이 취약하며, 위험합니다.

Real‑World Example

몇 주 전, 누군가가 “vibe‑coded”한 플랫폼이 4일 만에 150만 명의 사용자를 끌어들였습니다. 그로부터 3일 뒤, 전체 프로덕션 데이터베이스가 접근당하고 유출되었습니다(API 키, 이메일, 개인 메시지 등).

우리는 기존 소프트웨어 엔지니어링에서도 악의적인 행위를 막기 위해 고군분투합니다. 이 vibe‑into‑production 모델은 문고리에 열쇠를 꽂아 두는 셈입니다.

Closing Thoughts

새로운 기술에 흥분하는 것은 저를 이 분야에 머무르게 하는 주요 이유입니다. 제가 흥분하지 않는 것은 새로운 기술의 무책임한 사용입니다. 우리 지구는 이미 충분히 많은 문제를 안고 있는데, 우리가 그 문제를 운영하는 소프트웨어를 파괴할 필요는 없습니다.

제가 바라는 것은 조금의 신중함과 사려 깊음뿐입니다.

그게 너무 많은 요구일까요?