'AI 슬롭'이 뭐냐면
요즘 영어권 개발자 커뮤니티에서 부쩍 자주 보이는 단어가 하나 있어요. 바로 '슬롭(slop)'인데요. 원래는 돼지한테 주는, 이것저것 막 섞어놓은 짬밥 사료를 뜻하는 말이거든요. 그런데 요즘은 이게 'AI가 영혼 없이 대량으로 찍어내는 저품질 콘텐츠'를 가리키는 말로 자리를 잡았어요. 블로그 글이든 그림이든 코드든, 버튼 한 번 누르면 그럴듯해 보이는 결과물이 무한정 쏟아지는데, 막상 들여다보면 알맹이가 없는 그런 것들 말이에요.
이번에 소개할 글은 이런 '슬롭의 시대'에 직접 소프트웨어 잼(software jam)을 열어본 운영자의 경험담이에요. 소프트웨어 잼이 뭐냐면, 게임 잼(game jam) 들어보셨죠? 정해진 짧은 시간, 보통 주말 며칠 안에 주제 하나를 받아서 뚝딱 무언가를 만들어내는 창작 이벤트예요. 해커톤과 비슷한데, 상금이나 경쟁보다는 '만드는 즐거움' 그 자체에 더 무게를 두는 모임이라고 보면 돼요.
AI가 다 만들어주는 시대에 잼이 무슨 의미가 있나
글쓴이가 고민한 지점이 바로 여기예요. 예전엔 잼에서 뭔가를 완성해 오면 그 자체로 박수를 받았거든요. 짧은 시간에 동작하는 결과물을 만든다는 게 쉬운 일이 아니니까요. 그런데 지금은 누구나 AI한테 '이런 거 만들어줘' 하면 반나절 만에 화면에 뭔가 돌아가는 걸 띄울 수 있어요. 그러다 보니 결과물의 '완성도'만 보면 사람이 밤새 손으로 짠 것과 AI가 뽑아준 것을 구분하기가 점점 어려워지는 거죠.
그래서 글쓴이가 내린 결론이 흥미로워요. 잼의 가치를 '결과물의 완성도'가 아니라 '과정과 사람'에 다시 두자는 거예요. 다시 말해, 얼마나 매끈하게 뽑았느냐보다 그 사람만의 엉뚱한 아이디어, 직접 부딪히며 배운 흔적, 동료들과 함께 끙끙댄 시간 같은 걸 더 쳐주자는 방향이죠.
슬롭을 걸러내는 운영의 디테일
구체적으로는 몇 가지 장치를 둬요. 먼저 심사 기준을 바꿔요. '얼마나 그럴듯한가'가 아니라 '이 사람이 뭘 직접 해냈는가', '이 아이디어가 얼마나 그 사람답나'를 봐요. 또 제출할 때 만드는 과정을 기록하게 하거나, 직접 시연하면서 '여긴 왜 이렇게 짰어요?'를 물어보면 AI한테 통째로 맡긴 결과물은 금방 티가 나거든요. 발표하면서 본인이 설명을 못 하면 그게 바로 슬롭의 신호인 셈이죠.
여기서 오해하면 안 되는 게, 이 글은 'AI 쓰지 마'라고 말하는 게 아니에요. 도구로서 AI를 쓰는 건 괜찮은데, 그게 사람의 창작을 '대신'하는 게 아니라 '거드는' 선에서 멈춰야 한다는 거예요. 결국 잼이라는 자리는 결과물 전시장이 아니라, 사람들이 모여서 직접 손을 더럽혀 가며 배우고 노는 자리라는 본질을 지키자는 이야기인 거죠.
우리에게 주는 시사점
이건 사실 해커톤 주최자만의 고민이 아니에요. 사내 코드 리뷰, 채용 과제, 신입 교육, 사이드 프로젝트 발표회까지 죄다 같은 문제에 부딪히고 있거든요. '이거 본인이 짠 거 맞아요?'를 어떻게 가려낼지, 그리고 더 근본적으로는 '우리가 진짜 평가하고 싶은 게 결과물인가, 사람의 성장인가'를 다시 묻게 되는 거예요.
한국에서도 부트캠프, 대학 동아리, 회사 해커톤이 정말 많잖아요. 이런 행사를 운영하시는 분이라면 심사 기준에 '과정 설명'이나 '라이브 시연 후 질의응답'을 꼭 넣어보시길 권해요. 완성도만 보면 AI가 다 이기는 시대라, 사람만이 보여줄 수 있는 부분을 평가의 중심에 둬야 행사가 의미를 잃지 않거든요.
한 줄로 정리하면, AI가 결과물을 흔하게 만든 시대에는 '무엇을 만들었나'보다 '누가 어떻게 만들었나'가 진짜 가치라는 거예요. 여러분이 해커톤 심사위원이라면, AI로 매끈하게 뽑은 작품과 거칠지만 본인이 직접 부딪힌 작품 중에 어느 쪽에 손을 들어주시겠어요?
🔗 출처: Hacker News