원문: https://www.infoworld.com/article/4029093/9-habits-of-the-highly-ineffective-vibe-coder.html (Translated by Google Gemini)

바이브 코딩이 정말 그렇게 쉽다고요? AI의 현실 세계적 등가물인 집사를 생각해 보세요. 새로운 집사에게 아침 식사를 제공하거나 완벽한 마티니를 만드는 방법과 같은 기술을 가르치는 전문 학교가 있습니다. 하지만 이 학교들이 부자들에게 집사와 잘 지내는 방법을 가르치는 병행 과정도 있다는 것을 알고 계셨나요? 맞습니다. 부자들은 찻잔을 올바르게 잡는 방법을 배워서 집사가 우아하게 차를 채울 수 있도록 합니다. 심지어 어떤 종류의 요청이 적절하고 어떤 것이 그렇지 않은지도 배웁니다. 이것은 2분짜리 틱톡 비디오에서는 가르칠 수 없는 종류의 일입니다.

수발을 드는 것은 쉽지 않습니다. 찻잔을 올바르게 잡는 방법이 있으며, 적절한 요청과 실패할 수밖에 없는 요청의 차이를 아는 것이 중요합니다.

바이브 코딩도 마찬가지입니다. 물론, 인공지능과 생성형 AI가 할 수 있는 일은 놀랍습니다. 훌륭한 AI 코딩 도우미는 개발자가 원하는 대부분의 작업을 수행하는 작동 코드를 조립할 수 있으며, 종종 몇 개의 대략적인 문장과 무작위적인 손짓(일명 프롬프트 엔지니어링)을 기반으로 합니다. 어떤 날에는 몇 줄만 입력하면 AI가 몇 시간 또는 며칠이 걸릴 작업을 몇 분 만에 해낼 수 있습니다. 하지만 그런 날은 좋은 날입니다. AI 생성 코드의 한계는 미묘할 수 있지만, 항상 존재합니다. 설상가상으로, 우리는 그것들이 정확히 무엇일지 확실히 알지 못합니다. 우리 모두는 배우고 있습니다. 인간과 기계 모두요.

다음은 소프트웨어 개발자들이 바이브 코딩에서 잘못 갈 수 있는 9가지 방법입니다.

LLM을 신뢰하기#

오늘 아침, 저는 AI에게 URL 목록을 작성해 달라고 요청했습니다. AI는 제가 필요한 형식에 맞고 정확해 보이는 멋진 목록으로 몇 초 만에 답했습니다. 하지만 제가 확인해 보니, 모두 404 오류를 생성했습니다. 모든 링크가 깨져 있었습니다.

제가 AI에게 말했더니, “맞습니다. 죄송합니다! 웹사이트 링크는 자주 변경될 수 있으며, 이전 정보가 오래된 것 같습니다. 각 항목을 재확인하고 올바르고 작동하는 URL로 목록을 업데이트했습니다.“라고 답했습니다. 하지만 새 목록에 있는 URL도 모두 작동하지 않았습니다.

오늘날 많은 표준 AI의 비밀 시스템 프롬프트를 작성한 인간은 우리 모두에게 해를 끼쳤습니다. 이러한 대규모 언어 모델의 지배적인 성격은 지칠 줄 모르는 아첨꾼인 것 같습니다. AI는 무엇보다 동의하고 도움이 되도록 프롬프트되어 있으며, 그래서 무언가를 알아낼 수 없을 때에는 그냥 쓸모없는 것을 뱉어내고 작동한다고 주장합니다.

바이브 코딩의 첫 번째 치명적인 실수는 애초에 LLM을 신뢰하는 것입니다.

모든 모델이 같다고 가정하기#

하나의 대규모 언어 모델이 다른 모든 모델과 같다고 생각하기 쉽습니다. 인터페이스가 대부분 동일하니까요. 텍스트를 넣으면 마법 같은 답변이 나온다고요? LLM은 쉬운 질문에 대해서는 비슷한 답변을 주는 경향이 있습니다. 그리고 이름도 많은 것을 알려주지 않습니다. 대부분의 LLM 개발자는 설명적인 이름보다는 귀여운 이름을 선택하기 때문입니다.

하지만 모델은 내부 구조가 다르며, 이는 코드 작성과 같은 복잡한 논리가 포함된 문제를 얼마나 잘 풀고 이해하는지에 영향을 미칠 수 있습니다. 일부 모델은 문제를 여러 부분으로 나누고 각 부분을 개별적으로 처리하는 루프를 생성하기 위한 더 정교한 메커니즘을 가지고 있습니다. 이것은 큰 차이를 만들 수 있습니다.

LLM 매개변수의 수도 모델 안에 얼마나 많은 지식이 담겨 있는지에 대한 대략적인 지표입니다. 더 많은 매개변수가 일반적으로 더 좋지만, 그렇지 않은 경우도 있으며, 때로는 실험을 통해서만 이를 알 수 있습니다.

LLM은 또한 다른 데이터 세트로 훈련되며, 훈련 세트의 구성은 종종 미스터리입니다. 여러분의 LLM이 오픈 웹에서 스크랩된 JavaScript로 학습했는지, 아니면 작동하는 저장소의 잘 문서화된 코드로 학습했는지요? 오래된 레거시 코드를 처리하는 데 유용할 만큼 충분한 COBOL을 흡수했는지요?

때로는 기계에 코딩 문제를 맡기는 것이 유일한 방법입니다.

LLM을 쓰레기통처럼 취급하기#

많은 개발자는 LLM이 입력 크기에 얼마나 영향을 받는지 깨닫지 못합니다. 모델은 유용할 수 있는 것을 생성하기 전에 프롬프트의 모든 토큰을 처리해야 합니다. 더 많은 입력 토큰은 더 많은 리소스를 필요로 합니다.

습관적으로 LLM에 큰 코드 블록을 버리는 것은 비용을 증가시킬 수 있습니다. 너무 많이 하면 하드웨어를 압도하고 컨텍스트 창을 채우게 됩니다. 일부 개발자는 심지어 전체 소스 폴더를 “혹시 모르니까” 업로드하는 것에 대해서도 이야기합니다.

상업용 모델은 입력 및 출력 토큰별로 비용을 청구하는 경향이 있으므로 긴 탐색은 더 느리고 훨씬 더 비쌀 수 있습니다. 모든 코드 조각은 처리하는 데 비용이 듭니다.

많은 코드는 AI를 산만하게 할 수 있으며 심지어 혼란을 야기할 수도 있습니다. LLM은 여러분이 달성하려는 목표와는 전혀 관련 없는 코드 섹션에 집중할 수 있습니다. AI 코딩 도우미가 세부 사항을 처리할 만큼 충분히 똑똑하더라도 방대한 코드베이스를 던지는 것은 역효과를 낼 수 있습니다.

AI가 우리처럼 생각한다고 가정하기#

그들은 우리처럼 말합니다. 우리처럼 환각을 일으키고 잘못 기억합니다. AI가 우리와 똑같다고 상상하기 쉽습니다. 하지만 그들은 훈련 데이터에서 조각조각들을 이어 붙여 유용한 것을 만들어내는 영리한 모방자에 불과합니다. 그것이 그들이 정확히 생각하고 있다는 것을 의미하지는 않습니다.

AI 도우미는 소프트웨어 문서의 모호한 부분에 우리의 주의를 집중시킬 때 가장 잘 작동합니다. 또는 우리가 예상했던 곳에 없는 어떤 기능에 대한 작은 정보를 찾을 때도 마찬가지입니다. 그들은 방대한 훈련 세트에서 딱 맞는 통찰력을 검색하는 데 놀랍습니다.

하지만 그들은 항상 종합하거나 깊은 통찰력을 제공하는 데 능숙하지는 않습니다. 물론, 때로는 놀라울 때도 있지만, 그것은 종종 훈련 세트에 있는 어떤 문서를 작성한 영리한 인간을 흉내 내기 때문입니다. AI 코딩 도우미가 매번 천재일 것이라고 기대하지 않는 것이 좋습니다.

누더기 코드를 만들기#

대부분의 개발 팀은 코드에 규칙을 부과하는 코딩 표준 모음을 가지고 있으며, 이는 모두 출력의 조화를 목표로 합니다. AI는 그렇게 훈련되지 않습니다. 실제로, 그들은 종종 프로세스에 충분한 무작위성을 주입하여 출력의 코딩 스타일이 호출마다 변경됩니다. 동일한 프롬프트를 반복하면 매번 완전히 다른 코드가 생성되는 경우가 많습니다. 작동은 하지만, 스타일의 변동은 거슬릴 수 있습니다.

바이브 코더는 이를 무시하고 모든 것을 잘라내어 붙여넣는 경향이 있습니다. 코드는 실행되지만, 바보의 얼룩덜룩한 모습입니다. 진정한 일관성이나 표준이 없습니다. 그들은 그저 손가락을 꼬고 이 혼란 속을 헤치고 들어가 무엇이 문제인지 알아낼 필요가 없기를 바랄 뿐입니다.

LLM의 프로그래밍 편향 무시하기#

우리는 모두 AI는 훈련 세트만큼만 좋다고 늘 말합니다. LLM에 들어가는 모든 것은 결국 나오는 것에 영향을 미칩니다. 많은 개발자들이 작은 편향이 코드에서 어떻게 폭발했는지에 대한 무용담을 가지고 있습니다. 어떤 사람들은 프로그래머가 동일한 디자인 패턴을 계속해서 재사용할 때 나타나는 “최근 편향"에 대해 이야기합니다. 다른 사람들은 팀이 자신들의 선호하는 결과물에 기울어지는 “여기서 발명되지 않은 편향"에 대해 이야기합니다. 훈련 세트에는 수십 가지 편향이 있으며, 이 모든 편향은 어떤 식으로든 LLM의 출력에 반영될 것입니다.

많은 바이브 코더에게 이러한 세부 사항에 대해 걱정하지 않는 것이 전부입니다. 이것은 기본적인 프로그래밍 작업에는 효과가 있을지 모르지만, 이러한 고유한 프로그래밍 편향은 더 큰 코드베이스와 중요한 프로젝트에 부정적인 영향을 미칠 수 있습니다.

비용 무시하기#

AI 도구는 겉으로는 저렴해 보입니다. 특히 건강 보험과 휴가를 원하는 인간 코더 옆에서는 더욱 그렇습니다. 하지만 토큰별로 요금을 청구하며, 클라우드 머신처럼 토큰도 계속해서 늘어날 수 있습니다.

바이브 코더는 동일한 요청을 반복적으로 하는 경향이 있습니다. 그들은 큰 코드 블록을 컨텍스트 창에 던져 넣고 AI가 알아서 해결하도록 합니다. 토큰은 계속해서 늘어납니다. 어딘가에는 전체 시스템을 계속 가동하기 위해 고대 공룡을 태우는 발전기가 있습니다. 연료와 비싼 GPU 사이에서 비용은 정말 많이 늘어날 수 있습니다.

지휘권을 넘겨주기#

컴퓨터 프로그래밍은 지루할 정도로 반복적일 수 있지만, LLM은 프로세스에 무작위성을 주입하는 경향이 있습니다. 매번 조금씩 다르게 작동하기 때문에 특정 역할과 책임을 맡기는 것은 위험합니다. 약간의 무작위성은 그들의 설계에 필수적입니다.

일부 바이브 코더는 이것을 힘든 방식으로 깨달았습니다. 특히 무서운 이야기 중 하나에서는 AI가 프로덕션 데이터베이스를 삭제했습니다. 데이터가 영원히 손실되었을까요? LLM은 신경이나 썼을까요? 다음 프롬프트로 넘어갔기 때문에 우리는 결코 알 수 없을 것입니다.

AI 환각을 쫓기#

최근 기억에 남는 최악의 프로그래밍 날 중 하나는 AI 코딩 도우미를 믿은 후였습니다. 기계는 내 컬러 코딩 편집기에서 매우 신뢰할 수 있어 보이는 길고 정교하게 포맷된 주석과 함께 엄청난 양의 아름다운 코드를 뱉어냈습니다. 일부는 완벽하게 실행되기도 했습니다.

문제는 AI가 내 프롬프트를 해결할 완벽한 라이브러리 호출의 존재를 환각했다는 것입니다. API 호출을 둘러싼 글루 코드는 잘 작동했지만, 라이브러리 호출은 존재하지 않았습니다. 라이브러리는 호출된 메서드나 유사한 것을 제공하지 않았습니다. 하지만 AI가 이름을 잘못 철자한 것이 아닌지 확인하기 위해 몇 시간을 오래된 문서와 소스 코드를 뒤져보기 전까지는 이것을 알지 못했습니다.

내가 문제를 지적했을 때, AI는 가짜 진심으로 극진히 사과할 뿐이었습니다. “정말 죄송합니다. 맞습니다.“라고 말했습니다. 그러고 나서 다른 방식으로 똑같이 틀린 더 많은 잘못되고 사용할 수 없는 코드를 생성했습니다.

때로는 코드를 직접 작성하는 것이 더 쉽습니다.