상금권 바로 밖에서 끝났다

2026년 8월, 4박 5일 동안 진행된 딥러닝 여름부트캠프와 경진대회에 참가했다. 강의와 실습 뒤에 두 개의 이미지 과제를 풀었다. 첫 번째는 식당 이미지를 여덟 개 범주로 분류하는 문제였고, 두 번째는 이미지와 자연어 질의를 함께 보고 질의가 가리키는 대상을 마스크로 분할하는 문제였다.

우리 팀은 최종 6위였다. 상금은 5위까지였다. 한 계단 차이였으니 결과가 아쉽지 않았다고 말할 수는 없다. 대회가 끝난 직후에는 다른 팀의 작업 방식과 그것을 구분하지 않은 운영에 대한 불만도 컸다. 지금도 그 평가가 공정했다고 생각하지 않는다.

그런데 원고를 처음 썼을 때처럼 그 이야기만 앞세우면, 이번 대회에서 내가 잘못 판단한 부분이 뒤로 숨었다. 나는 팀의 목표를 합의하지 않았고, 이전 참가 경험으로 현재의 규정과 운영을 지레짐작했다. 내가 맡은 쪽에 사람이 더 필요했는데도 해야 할 일이 분명해질 때까지 혼자 붙잡고 있었다. 짧은 실험을 빠르게 돌렸지만, 파이프라인 전체로는 너무 늦게 되돌아갔다.

평가에 대한 문제 제기와 내 전략에 대한 반성은 둘 중 하나를 고르는 일이 아니다. 불공정했다고 느꼈다는 이유로 내 판단 착오가 사라지지 않고, 내가 잘못한 부분이 있었다고 해서 그 평가가 공정해지는 것도 아니다.

내가 당연하게 여긴 목표는 합의된 목표가 아니었다

내가 생각한 대회의 목표는 분명했다. 팀원들이 가능한 한 직접 공부하고 이해하면서 좋은 결과를 내고, 상금까지 받는 것이었다. 나는 이 순서가 당연하다고 여겼다. 이해하지 못한 결과를 받아 제출하는 것보다 조금 느리더라도 우리 힘으로 판단하는 편이 낫다고 생각했다.

하지만 그것은 내가 중요하게 여긴 기준이지, 팀이 함께 정한 우선순위는 아니었다. 어떤 팀원에게는 배우는 것보다 상금이 먼저였을 수도 있다. 둘이 충돌할 때 어디까지 AI를 쓰고 무엇을 포기할지 우리는 미리 이야기하지 않았다. 나는 내가 좋다고 생각한 방향이니 괜찮다고 여겼고, 그 선택의 비용은 팀 전체가 함께 부담했다.

결국 상금권에 들지 못했다. 결과만 놓고 모든 원인을 내 선택 하나로 돌릴 수는 없지만, 합의하지 않은 내 기준으로 팀의 전략을 정한 점은 미안하게 남았다. 공부하고 이해하자는 원칙이 틀렸다는 뜻은 아니다. 그 원칙을 공동의 목표로 삼으려면 먼저 동의를 구했어야 한다는 뜻이다.

나에게는 이전 참가 경험도 있었다. 나는 1회차에 참여했고 이번은 3회차였다. 그래서 그사이 규정과 관리가 더 엄격해졌을 것이라고 자연스럽게 생각했다. 실제로 현재 운영이 그런지는 확인하지 않은 채, 과거 경험에서 만든 예상대로 움직였다. 내가 가진 맥락을 다른 사람도 알고 있고 지금도 유효한 것처럼 여긴 셈이다. 이번에는 경험이 이점이라기보다 지식의 저주로 작용했다.

시킬 일이 분명해질 때까지 사람을 붙이지 않았다

내가 맡은 파이프라인 쪽에는 다른 팀원이 조금 더 일찍 붙는 편이 맞았다. 그런데 나부터 어떤 작업이 맞는지 확신이 없었다. 할 일을 제대로 쪼개지 못한 상태에서 막연하게 이쪽에 붙어서 더 해달라고 하는 것은 좋은 요청이 아니라고 생각했다. 그래서 내가 방향을 잡고 시킬 일이 분명해진 다음에 요청하려 했다.

돌이켜보면 사람은 분명해진 일을 실행할 때만 필요한 것이 아니었다. 무엇을 해야 할지 함께 알아내고, 내가 놓친 가정을 질문하고, 작업을 같이 쪼개는 단계에도 한 명이 더 붙을 수 있었다. 더 일찍 같이 탐색했다고 순위가 반드시 올랐다고 말할 수는 없지만, 적어도 내가 혼자 확신을 만드는 데 쓴 시간과 시야의 한계는 줄일 수 있었을 것이다.

지시는 생각보다 훨씬 구체적이어야 한다는 것도 배웠다. 한 번은 팀원에게 파일을 드라이브에 올려 공유해 달라고 했다. 내가 생각한 곳과 달리, 팀원은 주최 측이 우리 조의 제출용으로 만들어 둔 드라이브에 파일을 올렸다.

이 일을 팀원이 이상하게 이해한 사례로 남기고 싶지는 않다. 내가 어느 드라이브의 어느 폴더에, 어떤 이름으로 올리고, 누구에게 어떤 권한으로 공유해야 하는지 말하지 않았다. 특히 개발 관련 전공이 아닌 팀원에게는 내가 당연하게 생략한 경로와 작업 맥락이 당연하지 않았다. 지시가 짧았던 것이 효율적인 게 아니라 불완전했던 것이다.

빠른 실험을 했지만 전체는 늦게 봤다

두 번째 과제에서 내가 주로 파고든 구조는 Qwen3-VL이 이미지와 질문을 읽고 대상의 박스나 점을 찾은 뒤, SAM 2.1이 그것을 픽셀 단위의 마스크로 바꾸는 파이프라인이었다. 하나의 박스, 여러 박스, 박스 안의 점, Find 명령, target 추론과 빈 결과를 다시 처리하는 방법 등을 차례로 비교했다.

초기 실험은 아주 느리지 않았다. Qwen3-VL을 처음 불러오는 데 약 5분이 걸렸고, 한 번 불러온 뒤 여러 번 호출해 결과를 만드는 데 약 10분이 더 걸렸다. 그래서 초반의 작은 실험 하나는 대체로 10분에서 15분 안에 확인할 수 있었다.

문제는 파이프라인을 여러 단계로 쪼개 각 단계에서 Qwen3-VL을 다시 불러오게 되면 달라졌다. 그렇게 완성된 구조는 한 번 실행하는 데 30분에서 1시간까지 걸릴 수 있다고 예상했다. 나는 아직 실험 단계이니 긴 파이프라인부터 만들기보다 10분 안팎의 실험으로 방향을 확실히 잡는 것이 먼저라고 판단했다. 이 판단 자체는 지금도 잘못이었다고 생각하지 않는다.

병목은 그다음에 있었다. 나는 한 부분의 방향을 확실히 잡고, 그 부분을 완성한 뒤, 다음에 무엇을 붙일지 고민하는 식으로 움직였다. 각 실험은 짧았지만 전체 탐색은 순차적으로 길어졌다. 한 구조를 깊게 이해할수록 그 구조 안에서 더 나은 프롬프트와 예외 처리를 찾게 됐고, 파이프라인 전체를 바꿀 만큼 크게 되돌아가는 시점은 늦어졌다.

다음에는 한 부분을 완성하기 전에 거친 전체 구조를 몇 가지 먼저 그려볼 것이다. 30분이나 1시간짜리 파이프라인을 무작정 여러 번 돌리겠다는 뜻은 아니다. 전체 구조별 예상 실행 시간과 가장 불확실한 지점을 먼저 적고, 짧은 실험이 어느 전체 구조를 살리거나 버리기 위한 것인지 연결하겠다는 뜻이다. 백트래킹의 단위도 프롬프트 한 줄이 아니라 파이프라인 전체가 되어야 했다.

경험이 속도를 보장하지 않았다

대회 전에 모델을 더 이해하고 파이프라인의 큰 틀을 미리 생각해 둘 수도 있었다. 나는 이전 경험이 있으니 막상 시작하면 어렵지 않을 것이라고 생각했다. 그 자신감 때문에 준비할 수 있었던 부분까지 현장에서 처리하게 됐다.

막상 대회가 시작되자 내가 본 현장에서는 생성형 AI 사용이 사실상 보편적이었다. 비슷한 모델과 문제를 놓고 모두가 LLM에 질문하면 처음 떠올리는 아이디어도 빠르게 비슷해졌다. 차이는 기발한 첫 생각보다, 구조적으로 다른 안을 얼마나 빨리 실제 결과로 바꾸고 무엇을 버리느냐에서 생겼다. 나는 한 방향을 오래 파고드는 데 익숙했지만, LLM으로 여러 안을 동시에 밀어붙이는 속도는 충분히 계산하지 못했다.

돈이 걸리면 규정의 빈틈이나 편법으로 보이는 방법도 자연스럽게 등장한다는 것도 보았다. 모든 참가자가 그랬다고 일반화하려는 말은 아니다. 다만 상금이 있는 경쟁에서 각자가 자발적으로 같은 선을 지킬 것이라고 기대해서는 안 된다는 뜻이다. 주최 측은 실제로 적용할 기준을 분명히 해야 하고, 참가자는 적혀 있는 규정뿐 아니라 현장에서 무엇이 허용되고 어떻게 확인되는지도 살펴야 한다.

나는 1회차의 경험을 바탕으로 3회차의 관리가 더 엄격할 것이라 생각했고, 그 가정을 팀의 전략에 깔았다. 그러나 현장에서 LLM을 사용하는 참가자들의 작업 속도는 내가 예상한 것보다 훨씬 빨랐다. 내가 지키고 싶은 원칙이 있었다면, 운영진이 알아서 기준을 적용하리라 믿기 전에 팀과 먼저 합의하고 실제 적용 범위도 확인했어야 했다.

그래도 AI를 썼다는 한마디로 같아지지는 않는다

이 대목에서 내가 생성형 AI를 쓰지 않은 사람인 것처럼 물러설 생각은 없다. 나도 Codex로 코드를 만들고 고쳤다. 결과를 비교하고 실패 원인을 검토할 때도 도움을 받았다. 모든 코드를 한 줄씩 손으로 썼다고 주장할 수 없다.

그래도 AI에게 코드를 작성하게 한 것과 문제 해결 전체를 맡긴 것은 다르다고 생각한다. 다른 팀의 최종 발표를 들으며 파이프라인을 왜 그렇게 설계했는지, 무엇을 비교했고 어떤 결과를 보고 다음 실험을 골랐는지 질문했다. 핵심 질문에는 제대로 된 답을 듣지 못했다. 발표자는 AI를 사용했으니 그것 때문에 실격된다면 어쩔 수 없다는 취지의 말도 했다.

내가 그 팀의 내부 로그를 본 것은 아니다. 하지만 발표를 듣고 질문을 거듭한 뒤 내린 판단은 명확하다. 그 팀은 핵심 파이프라인 설계와 실험을 Codex에 사실상 맡겨 성적을 냈고, 그 결과를 나중에 따라가며 이해했다. 나는 지금도 이 판단을 바꾸지 않았다.

운영진은 모두가 생성형 AI로 코드를 작성했다는 취지로 상황을 정리했고, 그 안의 차이를 더 구분하지 않았다. 직접 이해하고 코딩한다는 원칙이 있었다면, 적어도 참가자가 구조를 고른 이유와 실패한 실험, 버린 대안, 제출물을 다시 설명하고 바꿀 수 있는지는 확인했어야 한다고 생각한다.

가장 강한 반론도 알고 있다. 어떤 AI를 얼마나 써도 좋고 최종 점수만 보는 대회였다면, 문제 해결을 더 많이 맡겨 높은 점수를 만든 팀이 전략을 더 잘 쓴 것이다. 그 조건이라면 나는 현장의 속도를 충분히 따라가지 못하고 진 것이다.

하지만 내가 안내받고 이해한 규정과 프로그램의 목표는 생성형 AI를 사용하지 않고 직접 이해하며 코딩하는 것이었다. 실제 평가는 그 원칙을 확인하지 않았다. 내가 문제라고 생각하는 것은 바로 그 불일치다.

다음에는 확신이 생기기 전에 움직일 것이다

이번 경험을 다음 경진대회나 팀 프로젝트에 가져간다면 시작할 때부터 다음을 확인하려 한다.

1. 팀의 목표부터 합의한다. 배우는 것과 상금 가운데 무엇이 우선인지, 둘이 충돌하면 어디까지 AI를 사용할지 먼저 이야기한다.
2. 현재의 규정과 실제 운영을 확인한다. 이전 대회의 기억이나 주최 측이 알아서 관리할 것이라는 기대를 현재 사실처럼 쓰지 않는다.
3. 불확실한 일에도 사람을 일찍 붙인다. 시킬 일이 완성될 때까지 기다리지 않고, 무엇을 해야 할지 함께 알아내는 역할부터 나눈다. 반대로 실행 지시를 할 때는 위치, 파일, 결과물과 완료 조건을 구체적으로 말한다.
4. 부분보다 거친 전체를 먼저 비교한다. 구조적으로 다른 파이프라인을 먼저 놓고, 각 짧은 실험이 어느 안을 살리거나 버리기 위한 것인지 정한다.
5. 백트래킹 시점을 미리 정한다. 같은 방향의 개선을 몇 번까지 시도할지, 언제 전체 구조로 돌아갈지를 점수가 나오기 전에 결정한다.

AI는 코드를 빨리 만들고 여러 대안을 펼치는 데 계속 사용할 것이다. 다만 무엇을 비교할지, 결과를 무엇으로 해석할지, 어느 방향을 버릴지는 내가 설명할 수 있어야 한다. 이 기준은 남을 평가하기 전에 내 작업에 먼저 적용해야 한다.

6위보다 오래 남은 것

6위라는 결과 뒤에는 여러 감정이 함께 남았다. 평가 방식에 대한 허탈감도 있고, 팀과 목표를 합의하지 않은 채 내 기준을 당연하게 여긴 미안함도 있다. 사람을 더 일찍 붙이지 못한 아쉬움과, 한 방향을 너무 오래 붙든 답답함도 있다.

다음에는 확신이 생긴 뒤에야 사람을 부르지 않을 것이다. 목표와 규정은 먼저 확인하고, 불확실한 작업은 함께 쪼개고, 완성된 부분보다 거친 전체를 먼저 볼 것이다. 평가에 대한 내 판단은 그대로 남겨두되, 그 판단만으로 내가 놓친 것을 가리지 않을 것이다.

합의하고 확인했어야 할 목표와 규정은 내가 이미 안다고 생각했고, 함께 탐색했어야 할 기술 문제는 내가 확신할 때까지 혼자 붙잡고 있었다.