C++로 오디오 스트리밍 시스템을 Vibe Coding 해봤습니다: 결과는 이렇습니다
Source: Dev.to
Letting the Vibes Drive
분명히 말하자면, 저는 완전히 눈을 감고 진행한 것이 아닙니다. 저는 오디오 스트리밍, 링 버퍼, 그리고 이것이 렌더러에 어떻게 통합되어야 하는지를 이해하고 있기 때문에 LLM을 올바른 방향으로 살짝 유도했습니다. 그럼에도 불구하고 결과는… 제가 예상한 그대로였습니다.
- 작동합니다.
- 충돌이 없습니다.
- 눈에 띄는 오류도 없습니다.
하지만 자세히 보면, 실제로는 제대로 작동하지 않습니다.
제가 얻은 것은 누군가가 오디오 스트리밍을 구현할 가능성 있는 평균 방식이었습니다. 새로움도 없고, 이 스트림이 렌더러 안에 존재한다는 인식도 없습니다. 단지 통계적으로 가장 가능성이 높은 솔루션일 뿐이죠.
솔직히 말해서, 평균이라는 것이 최악의 부분은 아닙니다. 최악은 다음과 같습니다:
2.1 k 라인의 무언가.
참고로, 이것은 AMP와는 전혀 관계가 없습니다—AMP는 훌륭한 도구이며, 그들의 무료‑유료 전환은 실제로 인상적입니다. 이것들은 LLM이 하는 일을 하는 LLM의 프론트엔드일 뿐입니다.
예를 들어, raylib 같은 것을 사용한 오디오 스트리밍(여기서도 사용됨)은 깨끗한 C++ 코드 100줄 이하면 충분합니다—당신이 무엇을 하는지 안다면 말이죠.
그럼 그 2 k+ 라인은 무엇일까요? 끝부분을 자세히 보세요. TODO들.
첫눈에 문제를 못 찾을 수도 있습니다. 문제는 이렇습니다:
이제 저는 읽고 디버깅해야 하는 평균적인 솔루션을 갖게 되었습니다.
- 제 저장소는 수천 줄에 달하는 자동 생성된 마크다운 “문서”로 오염되었습니다.
- 이걸 생성하는 데 오래 기다렸는데, 그 시간에 직접 코드를 작성할 수 있었을 겁니다.
The Real Cost: Reading Code
코드베이스를 인수받아 본 적이 있다면, 이 고통을 이미 알고 있을 겁니다. 아직이라면, 다음 연습을 해보세요: 당신이 의존하고 있는 어떤 프로젝트든 포크하고 읽어보세요.
당신이 쓰지 않은 코드를 읽는 것은 어렵습니다. 그것은 당신의 정신 모델과 연결되지 않으며, 머릿속에 존재하지도 않습니다.
이제 대부분은 작동하지만 완전히는 아닌 코드를 읽어보세요. 저수준 개발자들 사이에 오래된 격언이 있습니다: “나는 세그폴트를 좋아한다. 왜냐하면 정확히 무엇이 잘못됐는지 알려주기 때문이다.” 그리고 이것은 사실입니다. 합리적으로 보이고, 실행되며, 조용히 잘못된 일을 하는 코드보다 더 무서운 것은 없습니다.
그게 바로 vibe 코딩이 저에게 준 것이었습니다. 결국 저는 직접 코드를 작성하고 뇌를 쓰는 데 걸렸을 시간보다, 이 코드를 다루는 데 더 많은 시간을 소비했습니다. LLM이 실제로 도움이 되는 부분에만 사용한 것이죠.
이제 프로그래밍 배경이 전혀 없는 사람을 상상해 보세요. 그들은 얼마나 자주 재프롬프트를 할까요? “뭐가 틀렸는지”조차 말하기 어려울 겁니다.
Where I Actually Landed
이 글을 쓰는 지금, 저는 솔직히 의욕이 없습니다. 그 변경 사항들을 볼 의욕도 제로입니다. 그래서 저는 실제로 권장하는 방식대로 LLM을 사용할 겁니다: 도구로서.
“Claude, 이 코드를 훑어보고 어떻게 동작하는지 간결하게 정리해 줘, 그리고 링크도 달아줘.”
그게 전부입니다.
Final Thought
Anti‑vibe 코더들은 LLM에 반대하는 것이 아닙니다. 우리는 무분별한 마케팅 판타지와 초보자에게 실제로 끼치는 해악에 반대할 뿐입니다. 이것이 우리가 처음부터 말해온 전부입니다.
하지만, 인생은 당신의 것입니다. 원하는 대로 활용하세요.