Post

예쁜 쓰레기가 나를 속여왔다

지난달, 내가 만든 두 개의 제품을 스스로 “예쁜 쓰레기”라고 부르기로 했다.


두 개의 고백

하나는 코드베이스를 스캔해서 자동으로 기능명세서를 뽑아주는 도구였다. 로컬에 목업 서버를 띄워서 브라우저에서 바로 확인할 수 있게 만들었다. 화면도 있었고, 플로우도 이어졌고, 버튼을 누르면 동작했다.

팀원들에게 공유했다. “이런 거 만들었어요.” 반응은 있었다. “오, 이런 것까지 되네요.” 딱 거기까지였다. 신기해했지, 필요로 하지는 않았다.

구조적인 이유가 있었다. 이 도구는 완성된 코드베이스를 역으로 분석해서 명세를 뽑아냈다. 이미 다 만든 것의 문서를 사후에 생성하는 구조였는데, 거기서 수요가 없었다. 팀은 “지금 뭘 만들고 있는가”가 궁금한 거지, “완성된 것을 정리한 명세서”가 필요한 게 아니었다.

더 근본적인 문제도 있었다. 사람이 읽기 좋은 UI 형태로 뽑아냈는데, 정작 이 출력물을 가장 잘 소비할 수 있는 건 사람이 아니라 AI였다. 팀 레벨로 끌어올리려면 동기화 주기, 저장 위치, 브랜치 전략과의 연계 같은 가드레일을 설정해야 했는데, 그 기준이 하나도 정해져 있지 않았다. 로컬에서 혼자 돌리는 게 전부였고, 거기서 멈췄다.

누군가가 돈을 내고 쓸까? 그 질문을 처음부터 안 했다.

다른 하나는 같은 IP로 장르만 바꾼 방치형 게임이었다. “IP는 있으니까 재탕해보지” 하는 마음으로 에이전트에게 돌렸다. 핵심 루프가 나왔을 때 플레이해봤고, 재미가 없었다.

당연했다. 내가 한 번도 “이 루프가 재미있나?”를 진지하게 물은 적이 없으니까. 루프를 만들었을 뿐, 루프를 검증한 적이 없었다. 재미는 만드는 것으로 생겨나지 않는다.

둘 다, 만들 필요가 있어서 만든 게 아니다. 만들 수 있으니까 만든 것이다.


보름에 500만원, 실제로 낸 돈은 $200

보름 동안 내가 소비한 토큰의 값어치다.

  • 환산 비용: $3,606.20 (4월 1일~16일)
  • 콜 횟수: 33,473
  • 세션: 790
  • 캐시 히트: 100%

CodeBurn 대시보드

실제로 낸 돈은 Max20 구독 $200 한 줄이다. 4월 초순에는 하루에 $300~$380을 찍은 날이 다섯 번이었다. 4/11, 4/12는 $25, $13으로 뚝 떨어졌는데, 주간 한도가 차서 회사 계정이 막힌 날이었다. 그날은 개인 계정의 힘을 잠깐 빌렸다.

처음에는 이 밀도 자체가 좋았다. 실험 하나를 떠올리면 바로 돌려볼 수 있고, 하루 만에 뭔가가 나오는 감각이 새로웠다. 그 자체를 즐겼다.

그런데 실험이 쌓일수록 질문이 바뀌었다. “이게 될까?”보다 “이게 의미 있나?”가 더 자주 떠오르기 시작했다. 재밌는 실험과 필요한 제품은 다르다는 걸, 실험을 많이 할수록 더 선명하게 알게 됐다.

이 밀도 안에서, 나는 예쁜 쓰레기 두 개를 찍어냈다.


AI는 판단력을 100배로 만들지 않는다

단순하게 계산해보자.

제품 100개가 시장에 나왔고, 그중 5개가 실제로 쓸 만한 제품이라고 해보자. 5% 타율이다.

이제 AI가 생산 속도를 100배로 끌어올렸다. 10,000개의 제품이 나왔다. 그럼 쓸 만한 제품은 500개가 됐을까?

내 체감은 다르다. 쓸 만한 제품의 절대 수는 늘었을 수 있다. 하지만 그보다 훨씬 빠른 속도로, 그럴싸해 보이지만 아무도 계속 쓰지 않는 제품이 쌓였다. 신호 대비 노이즈가 폭발적으로 커진 것이다.

도구가 100배 빨라진 거지, 판단이 100배 정확해진 게 아니다. AI는 내 판단력을 증폭한다. 판단이 좋으면 좋은 제품이 빨리 나온다. 판단이 나쁘면 나쁜 제품이 더 빨리, 더 예쁘게 나온다.

예쁜 쓰레기는 AI의 부작용이 아니다. 판단 체계 없이 AI를 쓸 때 벌어지는 일이다.


성취감이라는 가짜 신호

만들고 나서 느껴지는 성취감은 제품의 품질과 아무 상관이 없다. 이 둘을 같은 신호로 다루면 안 된다.

예쁜 쓰레기가 위험한 이유는 보기에 그럴싸해서다. 화면이 붙어 있고, 플로우가 이어지고, 버튼을 누르면 동작한다. 만든 사람이 가장 먼저 속는다.

나는 기능명세 도구를 만들고 나서 “이거 꽤 쓸 만한데”라고 느꼈다. 실제로 써봤으니까. 하지만 내가 쓸 수 있다는 것과 남들이 필요로 한다는 건 완전히 다른 말이었다. 내 불편이 남의 불편이 아니었고, 내 편리함이 남의 니즈가 아니었다. 만든 사람의 감각을 시장의 감각이라고 착각하는 것, 이게 1인 프로젝트의 가장 흔한 사망 원인이다.

예전에는 만드는 비용이 높아서 시작 전에 “이게 정말 필요한가?”를 여러 번 물을 수밖에 없었다. 지금은 만드는 비용이 낮아졌다. 그러면 만든 뒤에 더 냉정하게 물어야 한다. 나는 그 질문을 건너뛰었다. 그게 문제였다. AI가 문제가 아니라.


많이 쓴다고 잘 쓰는 게 아니었다

보름에 500만원 어치 토큰을 태운 사람이 만든 게 예쁜 쓰레기 두 개다.

이게 내 말의 근거다. AI를 많이 쓴다고 좋은 제품이 나오지 않는다. 오히려 많이 쓸수록, 판단 없는 실행의 속도도 함께 올라간다. 그리고 빠르게 만든 것들은 빠르게 예뻐진다.

처음엔 나도 숫자가 올라가는 게 기분 좋았다. 콜 횟수, 세션 수, 캐시 히트율. 뭔가를 열심히 하고 있다는 증거처럼 느껴졌다.

그런데 그 숫자들은 내가 무엇을 만들고 있는지를 말해주지 않았다. 얼마나 많이 시도했는지를 말해줄 뿐이었다.

나는 코드 쪽에서 먼저 이 문제를 만났다.


코드를 잘 리뷰하는 것에서, 잘못 만들지 않게 만드는 것으로

처음에 내가 집중했던 건 “AI가 틀린 코드를 내면 어떻게 잘 리뷰할 것인가”였다. 한 줄씩 읽었고, 타입 에러를 놓치지 않으려 애썼고, 리뷰 CI를 붙였다.

그런데 한참을 일하다 보니 한 칸씩 뒤로 물러나게 됐다.

같은 종류의 실수가 반복된다는 걸 알았을 때부터였다. 틀린 코드를 고치는 일보다, 애초에 틀리게 만드는 원인을 줄이는 일이 훨씬 덜 피곤했다.

  • 에이전트가 참조하는 가이드라인 문서를 다듬었다.
  • 반복되는 실수를 프롬프트 단에서 차단하는 쪽으로 구조를 바꿨다.
  • 테스트를 먼저 강화했다. 커버리지를 뒤로 미루지 않고.
  • 에이전트의 기억 구조를 정리했다. 무엇을 최우선으로 읽게 할지, 어디서 잘라낼지.

찾아보니 이걸 하네스 엔지니어링(harness engineering)이라고 부르더라. 나보다 먼저 같은 고민을 한 사람들이 있었다.

그런데 코드 품질에 이걸 적용하고 나서, 같은 질문을 제품 쪽으로 가져오게 됐다.

제품 판단에도 하네스가 필요한 게 아닐까. 새 프로젝트를 열기 전에 “이미 돈을 내고 쓰는 사람이 있는가”, “내가 없애려는 마찰이 실제로 이 사람들의 문제인가”, “내가 한 달 뒤에도 이걸 직접 쓸 것인가”를 물어야 한다. 기억이 아니라 구조로.

두 개의 예쁜 쓰레기가 가르쳐준 건 그거다. 코드 하네스보다 제품 하네스가 더 먼저였어야 했다.


성공한 모델을 더 갖고 싶게

그래서 요즘 나는 새로운 걸 먼저 떠올리려 하지 않는다.

이미 누군가 돈을 내고 쓰고 있는 제품을 본다. 그 제품이 왜 그 자리에 있는지를 본다. 그리고 그 제품이 아직 놓치고 있는 작은 지점을 본다.

이건 카피하라는 말이 아니다. 순서가 반대라는 뜻이다. 새로움은 맨 앞이 아니라 맨 뒤에 놓아야 한다. 먼저 갖춰야 할 건 검증된 수요의 흔적과, 그 위에서 내가 집요하게 파고들 수 있는 한 지점이다.

성공한 모델을 더 갖고 싶게 만드는 것. 지금 내게 가장 어려운 일이다. 진입장벽이 낮아졌기 때문에 비슷한 것들은 범람하지만, 더 갖고 싶게 만들려면 결국 사람의 시간과 판단이 들어가야 하기 때문이다.

AI로 시간을 아꼈는데, 아낀 시간을 판단을 세우는 데 다시 써야 한다. 그게 지금 내가 하는 일이다.

완벽보다 완료라고 믿던 시기가 있었다. 지금은 완료의 다음이 있다는 걸 안다. 완료 다음은 검증이다. 완료에서 멈추면 그게 예쁜 쓰레기가 된다.


마치며

성취감은 쉬워졌다. 검증은 더 비싸졌다.

AI 시대의 제품을 판별하는 감각은 “얼마나 빨리 만들었는가”가 아니라 “만들고 난 뒤에도 여전히 갖고 싶은가”여야 한다.

100배 생산성이라는 말은 매력적이다. 그런데 그 말 뒤에는 100배의 판단이 필요하다는 사실이 숨어 있다. 판단은 생산성으로 자동화되지 않는다. 적어도 지금은.

예쁜 쓰레기를 두 개 만들어본 사람으로서 적는다. 다음에 새 프로젝트를 열기 전에, 스스로에게 꼭 이 질문을 던지려 한다.

이거, 만들 수 있으니까 만드는 건가? 만들 필요가 있어서 만드는 건가?

그 질문 하나가, 판단과 속도를 둘 다 가진 사람과 속도만 가진 사람을 가른다고 믿는다.


built with CodeBurn + Claude Max + 예쁜 쓰레기를 두 개 쌓아둔 로컬 폴더

This post is licensed under CC BY 4.0 by the author.