나는 VibeCode Arena에서 일주일을 보냈다. 예상치 못한 모든 것들

I’m happy to translate the article for you, but I’ll need the full text of the post (aside from the source line you’ve already provided). Could you please paste the content you’d like translated? Once I have it, I’ll keep the source line unchanged and translate the rest into Korean while preserving all formatting, markdown, and code blocks.

소개

무언가에 대해 솔직히 말하겠습니다.
나는 이것을 거의 쓰지 않을 뻔했습니다. 그 주가 지루해서가 아니라 – 사실은 그 반대였습니다. 내가 발견한 것 중 일부를 인정하기가 불편했기 때문에 거의 쓰지 않을 뻔했고, 편한 방법은 하이라이트 영상을 올리고 넘어가는 것이었을 겁니다.

하지만 하이라이트 영상은 쓸모가 없습니다. 그래서 여기 실제 이야기를 전합니다.

VibeCode Arena를 발견한 방법

나는 VibeCode Arena에 대해 조금씩 듣고 있었다 – HackerEarth가 만든 플랫폼으로, 같은 프롬프트에 대해 AI 모델들이 경쟁하는 모습을 보고, 결과가 공개되기 전에 눈가리고 투표하며, 결과를 커뮤니티 챌린지로 열 수 있다.

흥미롭게 들렸다. 나는 마치 내가 뭘 해야 할지 모르는 느낌을 주는 무언가를 미루는 것처럼 계속 미뤘다. 결국 그냥 열어봤다.

첫 화면은 Duels feed이다. 사람들이 프롬프트를 제출했고, 두 모델이 정면 대결을 펼쳤으며, 커뮤니티는 어느 출력이 더 좋은지 투표하고 있다. 여기서 사람들이 만드는 것 중 일부는 정말 창의적이다 — 레트로 터미널, 인터랙티브 툴, 작은 게임 등. 나는 실제로 뭔가를 시도하기 전에 스크롤만 하느라 원래 생각보다 더 오래 시간을 보냈다.

나의 첫 번째 듀얼

작동 방식은 간단합니다:

1. 프롬프트를 작성합니다.
2. 두 AI 모델이 동시에 생성합니다.
3. 두 출력물을 나란히 확인합니다.
4. 모델 이름이 공개되기 전에 더 나은 쪽에 투표합니다.
5. 투표를 마친 후에야 이름이 공개됩니다.

나는 실제로 보고 싶었던 것을 입력했습니다 — 테스트용 프롬프트가 아니라, 내가 오랫동안 고민해 온 실제 아이디어였습니다. 두 출력이 도착했고, 나는 그것들을 읽어본 뒤 투표했습니다.

그때 모델 이름이 나타났습니다. 나는 평소 사용하지 않던 모델에 투표한 것이었습니다. 몇 달 전 조용히 포기해버린 그 모델은 다른 사람들의 의견에서 얻은 막연한 인상 외에 구체적인 근거가 없었습니다. 나는 정당성을 확인한 느낌은 없었습니다. 오히려 약간 부끄러웠습니다. 그 이유는 암시가 명확했기 때문인데, 나는 실제 결과가 아니라 명성이나 습관에 따라 도구를 선택하고 있었던 것입니다.

그날 나는 추가로 세 번의 듀얼을 진행했습니다. 내 가정은 두 번 틀렸습니다.

재미있는 실험

내가 직접 챌린지를 만들어 보려고 했고, 과도하게 고민하고 싶지 않아서 이렇게 입력했다:

“스틱 피규어가 싸우는 게임을 디자인해라”

두 개의 출력이 나타났다:

• Output A – 깔끔하고 구조적이지만, 게임이라기보다 다이어그램에 가까운 느낌이었다.
• Output B – 좋은 의미에서 혼란스러웠다: player‑1 공격 버튼, player‑2 공격 버튼, 체력 바 등 모든 요소가 있었다. 실제로 2분 정도 시간을 낭비하고 싶어질 정도였다.

나는 두 번째를 선택했다 – Codestral‑2508 – 이전에 진지하게 고려해본 적 없는 모델이다. 다시 말해, 블라인드 형식이 솔직한 평가를 강요했다.

나는 이를 커뮤니티 챌린지로 열었다. 이는 이제 누구든지 참여해 그 기반을 가져가 AI에게 개선을 요청하고 자신의 버전을 제출할 수 있다는 뜻이다. 리더보드에는 같은 시작점을 가지고 각기 다른 사람들이 만든 결과물이 채워진다.

그 순간 내가 느낀 것은 예상치 못한 것이었다: 일종의 진정한 호기심. “뭔가를 만들었다”가 아니라 “뭔가를 시작했지만 어디로 갈지 전혀 모른다”는 느낌이었다. 이는 다른 감정이며 솔직히 더 흥미롭다.

3일 차 – 만들기보다 관찰하기

3일 차 대부분을 아무것도 만들지 않고, 그냥 바라보는 데 보냈다.

챌린지 피드에는 다양한 제출물이 있다:

• Serious – UI 컴포넌트, 접근성 중심 도구, 폼 빌더.
• Unhinged – 자유분방하고 실험적인 프로젝트.

각 항목의 리더보드는 커뮤니티가 실제로 무엇을 가치 있게 여기는지와 처음 눈에 띄는 인상적인 것 사이의 차이를 알려준다.

내가 눈치챈 것은 같은 출발점을 가지고 다른 사람들이 만든 반복을 관찰함으로써 얼마나 많이 배울 수 있는가이다:

• 누군가는 기본 출력을 받아 완전히 재구성한다.
• 또 다른 사람은 당신이 생각하지 못한 기능을 추가한다.
• 세 번째 사람은 틀린 것처럼 보이는 방향으로 나아가지만, 그들의 점수를 보면 가정을 다시 생각하게 된다.

계속 생각했다 – 이것이 사람들이 AI만 사용할 때 가장 놓치는 부분이다. 자신의 맹점 플러스 모델의 맹점을 얻게 된다. 이를 열어보면 같은 문제에 대해 갑자기 스무 개의 서로 다른 시각이 생긴다.

구체적인 예시 – 기타 챌린지

다음 프롬프트로 대결을 진행했습니다:

“모든 주요 음이 현에 표시된 기타를 설계하세요.”

여섯 단어. 저는 기타를 조금 치기 때문에, 실제로 제대로 평가할 수 있는 것이 모델이 어떻게 처리할지 궁금했습니다.

두 결과 모두 인터랙티브 기타 프렛보드를 만들었습니다: 상단에 12개의 음, 6개의 현, 음을 클릭하면 해당 위치가 초록색으로 강조됩니다. 처음 보면 꽤 멋져 보였고—깨끗하고 기능적이며, 여섯 단어만으로 기대했던 것보다 더 나았습니다.

하지만 실제로 사용해 보니 문제점이 명확해졌습니다:

다시 Codestral‑2508에 투표했습니다 – 시각적 레이아웃이 더 좋고 구조도 약간 개선됐지만, 두 출력 모두 근본적인 문제는 동일했습니다.

명확한 브리프를 달아 챌린지로 열었습니다:

• 음 위치를 수정할 것.
• 프렛 번호를 추가할 것.
• 프렛 마커(전형적인 인레이 마커)를 추가할 것.
• 사운드 재생을 추가할 것.

완성된 출력이라고 가장하는 것보다 더 솔직한 접근이라고 생각했습니다.

사흘(4일) 후에 배운 점

나는 이와 관련된 가이드를 읽지 않았다; 그냥 자연스럽게 일어났다. 사흘 동안 다른 모델들의 출력을 신중히 평가하면서, 내가 프롬프트를 다르게 작성하고 있다는 것을 깨달았다:

• 덜 구조를 어떻게 짜는지에 대해.
• 더 무엇을 해야 하는지와 왜 해야 하는지에 대해.

출력은 크게 달라지지는 않았지만 눈에 띄게 개선되었다.

요점

블라인드 투표는 모델이 실제로 생성하는 무엇을 평가하도록 강요하고, 평판에 기반해 당신이 생각하는 어떤 것을 생성해야 한다는 기대와는 다르게 한다. 프로세스를 커뮤니티에 개방하면 관점이 배가되고, 스스로는 절대 발견하지 못할 맹점을 드러낸다. 그 결과? 더 깊은 호기심, 더 나은 프롬프트, 그리고 궁극적으로 더 유용한 AI‑생성물.

VibeCode Arena에서 일주일을 보낸 뒤의 성찰

제가 생각하기에 일어난 일은 평가 쪽에 시간을 투자하면서—출력 결과를 실제로 들여다보고 무엇이 잘 작동하고 무엇이 안 되는가를 물어보는 과정이—프롬프트에 넣는 내용 자체를 조용히 바꾸어 놓았다는 점입니다. 프롬프트가 만들어내는 결과와 실제로 만들어내야 할 결과 사이의 차이에 대해 어느 정도 내면화하게 되었고, 그 차이가 반대쪽에서 드러나기 시작했습니다.

That is not something I could have gotten from reading about prompting. It came from doing the evaluation work repeatedly.

저는 몇 달 전에 직접 만든 것과 거의 비슷한 프롬프트로 듀얼을 진행했습니다. 조용히 자신감이 있었습니다. 이 영역을 이미 알고 있었고, 문제를 해결한 적도 있었으니까요.

그 결과 중 하나는 제가 생각했던 것보다 특정 상호작용 부분을 더 잘 처리했습니다.

• 전체적으로 더 좋았던 것은 아닙니다.
• 모든 차원에서 우수했던 것도 아닙니다.
• 하지만 중요한 한 가지 측면에서, 제가 내리지 못했던 결정을 내렸고 그 결정은 옳았습니다.

그 상황을 저는 필요 이상으로 오래 곱씹었습니다.

제가 도달한 결론

AI가 더 낫다는 것이 아니라, 내가 이전에 만든 솔루션에 너무 가까이 있었기 때문에 그 약점을 명확히 보기 어려웠던 것이었습니다. 저는 무언가를 만들고, 배포하고, 그 뒤를 떠났으며, 그 주위에 굳어버렸습니다. 새로운 평가—모델을 통한 평가조차—가 제가 더 이상 볼 수 없게 된 부분을 포착해냈습니다.

그것은 불편하지만 동시에 유용합니다.

일주일은 길지 않습니다. 모든 것이 변했다고 가장할 수는 없지만, 몇 가지가 확실히 바뀌었습니다.

• 모델 선택: 이제는 다르게 생각합니다. “일반적으로 어떤 모델이 가장 좋은가”라는 질문은 실용적인 답이 없으니, 어떤 작업에, 어떤 조건에서, 어떤 기준으로 평가했는가에 초점을 맞춥니다. 이 프레이밍이 더 솔직하고 실용적입니다.
• 평가 엄격성: AI 출력물을 더 신중히 평가합니다. 실제로 무엇을 보고 있는지—진정으로 견고한 것, 겉만 보기 좋은 것, 나중에 문제를 일으킬 수 있는 것—에 대한 감이 더 명확해졌습니다. 이 명확성은 반복적인 블라인드 평가를 통해 얻은 것이지, 관련 글을 읽어서 얻은 것이 아닙니다.
• 불완전함에 대한 편안함: 제가 다루던 두 과제—스틱 피규어 격투와 기타 프렛보드—는 명확히 미완성된 상태였습니다. 이를 완벽하게 다듬기보다 도전 과제로 남겨두는 것이 옳다고 느꼈습니다. 플랫폼은 불완전함을 실패가 아니라 초대로 다룹니다. 이 재구성은 조용히 큰 도움이 됩니다.

Vibe coding의 맥락

Vibe coding에 대한 대부분의 대화는 속도에 초점이 맞춰져 있습니다: 더 빠르게 만들고, 더 빠르게 배포하고, 모든 코드를 손으로 직접 쓰는 일을 줄이자.
그것도 사실이지만, 전부는 아닙니다.

올바르게 Vibe coding을 수행하려면 더 나은 판단력이 필요합니다. 이제 모든 라인을 직접 쓰는 사람이 아니므로, 모든 라인을 평가할 수 있는 사람이 되어야 합니다. 즉, 다음을 해야 합니다.

1. 좋은 결과가 어떤 모습인지 알기.
2. 배포 전에 잘못된 부분을 잡아내기.
3. AI가 당신의 컨텍스트가 부족해 내릴 수 없는 결정을 대신 내리기.

VibeCode Arena는 그 판단력을 기를 수 있는 가장 직접적인 방법이라고 생각합니다—튜토리얼이 아니라 실제 프롬프트와 실제 출력물을 가지고, 정직하게 점수를 매기며, 같은 목표를 가진 커뮤니티와 함께 하는 과정이죠.

현재 나의 위치

• 일주일이 지난 지금, 이전보다 더 잘 보정된 상태입니다.
• 동시에 아직도 보정이 필요한 부분이 얼마나 많은지도 더 잘 인식하고 있습니다.

그것이 바로 내가 있어야 할, 적절한 자리라는 느낌이 듭니다.

직접 해보세요

• VibeCode Arena 홈:
• 실시간 챌린지 (기타 프렛보드):

VibeCode Arena에서 일주일을 보낸 가장 좋은 점은 내가 모르는 것에 대해 솔직해지게 만든 것이었습니다. 그것이 만든 어떤 결과물보다 더 가치가 있습니다.