Vibe Coding은 마지막 수단 실수!!
Source: Dev.to
Introduction
우리 모두 그런 경험을 해봤습니다. 프로젝트에 깊이 파고들어 좋은 진행 상황을 보이고 있었는데, 갑자기 벽에 부딪히게 되죠. 앱이 API에서 데이터를 읽는 데 문제가 있거나, 오류 처리를 위한 코드가 엉망이고 혼란스러워질 때가 바로 그때입니다.
- 구조체를 물어보지도 않고 재구성했습니다.
- 의미 없는 포인터를 삽입했습니다.
- 논리를 “환각된” 걸작으로 만들어 실행조차 되지 않게 했습니다.
당시엔 깨닫지 못했지만, 저는 함정에 빠진 것이었습니다. 제 파일에서 무슨 일이 일어나고 있는지 거의 이해하지 못했죠. 결국 ChatGPT와의 오고‑오며 대화가 급박하게 이어졌고, 저는 프롬프트를 입력하고, 오류 메시지를 복사하고, 코드를 붙여넣는 일만 반복했습니다. 복사‑붙여넣기 게임이 어떻게 끝나는지는 모두 알고 있죠.
작업을 살리기 위해서는 그 순환을 멈춰야 했습니다. 저는 피해자였고, 프로젝트는 피해를 입었습니다. AI가 만든 혼란스러운 상황에서 다시 정상 궤도로 돌아가기 위해 저는 다음 단계를 밟았습니다:
The Hard Reset
마지막으로 정상 작동하던 버전으로 돌아가야 했습니다. 아직 Git을 사용하고 있지 않다면, 이것을 계기로 깨달으세요. “환각”을 “되돌릴” 수 있는 능력이 최고의 안전망입니다.
# This command resets your file to the last saved version
git checkout -- weather_app.go그렇게 AI “슬롭”은 사라지고, 원래 로직이 복구되었습니다.
Surgical Prompting
AI에게 전체 파일을 주는 것을 멈췄습니다. 특정 로직 블록 하나만 분리해서 물었습니다:
“왜 이 특정 라인이 오류를 발생시키나요?”
Verification
AI가 해결책을 제시하면, StackOverflow와 Official Go Docs 같은 외부 자료를 통해 검증했습니다. 이를 통해 수정에 대한 이유를 실제로 배울 수 있었습니다.
The “No‑Paste” Rule
코드를 바로 붙여넣는 대신, 해결책을 직접 타이핑해서 에디터에 입력했습니다. 이렇게 하면 뇌와 화면 사이의 정신적 연결이 다시 구축됩니다.
A Framework for Safe AI Use
AI는 마지막 수단이어야지, 막다른 길에 닿았을 때 첫 번째 선택이 되어서는 안 됩니다. 코드가 “슬롭”이 되는 것을 방지하려면 다음 프레임워크를 따르세요:
- S – Scope: AI에게 필요한 스니펫만 제공하세요.
예시: “FetchWeather함수만 수정해 주세요.” - P – Parameters: 사용할 라이브러리를 명시적으로 알려 주세요.
예시: “표준 라이브러리만 사용하세요.” - E – Edge Cases: 실패 상황을 어떻게 처리할지 물어보세요.
예시: “404 오류나 타임아웃이 발생하면 어떻게 처리해야 하나요?” - C – Constraints: 기존 구조에 대한 제약을 확고히 하세요.
예시: “기존 구조체 정의는 변경하지 마세요.”
2026년 현재, 누구나 프롬프트를 입력할 수 있지만, 모두가 엔지니어링을 할 수 있는 것은 아닙니다. AI가 여러분의 학습 여정의 주 설계자가 되지 않게 하세요. 엄격한 지시가 필요한 페어 프로그래머로 활용하십시오. 화면에 무엇을 하고 있는지, 무엇이 보이는지 이해하지 못하게 되는 순간—즉시 멈추세요.
원본 코드를 되돌리고, 프레임워크를 따라가며, 논리를 스스로 제어하세요.