AI로 처음 개발하기 시작했을 때 가장 신기했던 것은 생각한 것이 바로 만들어진다는 점이었다. 예전 같으면 시간이나 기술 때문에 시작하지 못했을 앱도 여러 개 만들었다. 웹사이트도 만들었고, 언젠가 만들어보고 싶다고 생각만 했던 서비스도 실제 화면으로 옮겨봤다.
말 그대로 딸깍 몇 번이면 결과가 나왔다. 만들 수 있다는 사실 자체가 신나서 한동안은 무엇을 만들었는지 세기 어려울 정도로 계속 만들었던 것 같다.
1. 만들 수 있게 되자 기능부터 늘어났다
태권도를 오래 해왔기 때문에 태권도장에서 필요한 서비스를 만들어보면 좋겠다고 생각했다. 현장을 알고 있으니 필요한 기능도 잘 알 수 있을 것 같았다.
그런데 개발을 시작하자 생각의 순서가 조금씩 바뀌었다. 태권도장에서 어떤 문제가 반복되는지 살펴보기보다, 이런 기능도 있으면 좋겠고 저런 기능도 넣을 수 있겠다는 생각이 먼저 나왔다. AI에게 설명하면 금방 만들어주니 떠오르는 기능을 마구 추가했다.
만드는 동안에는 정말 재미있었다. 화면이 생기고 버튼이 동작하고 기능 목록이 길어질수록 서비스가 완성되어 간다고 느꼈다. 구현 속도가 빠르니 잠시 멈춰서 이 기능이 정말 필요한지 확인할 이유도 별로 없어 보였다.
2. 다 만들고 나니 내가 모르는 서비스가 되어 있었다
문제는 어느 정도 다 만들고 난 뒤에 보였다. 서비스를 다시 살펴보다가 스스로에게 묻게 됐다.
내가 진짜 필요한 기능을 만든 걸까?
이 기능은 뭐지?
왜 만든 거지?
기능은 많은데 내가 정확히 모르는 기능도 많았다. 처음 의도와 다르게 개발된 부분도 있었다. 어떤 기능은 누가 언제 쓸지 설명하기 어려웠고, 어떤 기능은 비슷한 역할을 하는 다른 기능과 겹쳤다. 구현은 끝났지만 제품을 내가 온전히 이해하고 있다는 느낌은 들지 않았다.
AI가 코드를 잘못 만들었다는 말만으로 설명하기도 어려웠다. 기능을 추가해달라고 한 것은 나였고, 왜 필요한지 충분히 정하지 않은 채 다음 기능으로 넘어간 것도 나였다. AI는 내가 멈추라고 하지 않는 한 계속 만들어냈다.
3. AI 슬롭이라는 말을 발견했다
비슷한 현상을 찾아보다가 AI 슬롭(AI slop)이라는 표현을 알게 됐다. 매일경제는 슬롭을 “AI가 작성한 저품질 콘텐츠”라고 소개했다. 생성형 AI로 글과 이미지 같은 결과물을 빠르게 대량 생산할 수 있게 되면서, 겉모습은 그럴듯하지만 품질이나 의미가 부족한 결과물을 가리키는 말로 쓰이고 있었다.
여기에서 파생된 말로 워크슬롭(workslop)도 있었다. 조선일보는 이를 “겉보기에는 그럴듯하지만 내용과 맥락이 부족해 받은 사람이 검증하고 다시 작업해야 하는 AI 결과물”이라고 설명했다. 결과물이 완성된 것처럼 보여도 누군가는 다시 맥락을 확인하고 틀린 부분을 고쳐야 한다는 의미였다.
내가 만든 태권도장 서비스를 그대로 AI 슬롭이나 워크슬롭이라고 부르는 것은 정확하지 않을 수 있다. 공개용 콘텐츠를 대량 생산한 것도 아니고, 다른 사람에게 미완성 업무를 넘긴 것도 아니기 때문이다. 다만 만드는 비용이 거의 사라지자 의미를 충분히 확인하지 않은 결과물이 빠르게 쌓였고, 나중에는 만든 사람인 내가 기능의 목적과 맥락을 다시 해석해야 했다는 점에서 닮은 부분이 있었다.
코드가 동작하고 화면이 그럴듯하다는 이유만으로 제품의 의미까지 생기는 것은 아니었다. 기능 수가 많다고 사용자의 문제가 더 잘 해결되는 것도 아니었다. AI가 만든 결과물의 품질을 걱정하기 전에, 내가 왜 만들고 있는지 설명할 수 있는지가 먼저였다.
4. AI 시대에는 무엇보다 왜를 먼저 정해야 했다
태권도장 서비스를 만들며 내가 얻은 가장 큰 깨달음은 AI 시대에는 만드는 일 자체에만 집중하면 안 된다는 것이었다. 구현은 이미 충분히 빨라졌다. 오히려 부족해진 것은 무엇을 만들지 고르고, 왜 필요한지 설명하고, 만들지 않을 것을 정하는 시간이었다.
태권도장 서비스를 만들고 나서야 문제보다 해결책을 먼저 정해버렸다는 사실이 보였다. 사용자가 실제로 무엇을 불편해하는지 확인하기 전에 기능의 형태부터 상상했고, 그 상상을 곧바로 구현했다. 앞으로는 해결책을 정하기 전에 사용자가 겪는 문제와 상황을 먼저 이해하고, 내가 세운 가정을 일찍 확인하려고 한다.
앞으로 새로운 기능이 떠오르면 바로 구현 목록에 넣기 전에 몇 가지를 먼저 물어보려고 한다.
- 이 기능은 누구의 어떤 불편을 줄이는가?
- 지금도 그 문제를 해결하는 다른 방법이 있는가?
- 이 기능이 필요하다는 사실을 무엇으로 확인할 수 있는가?
- 전체를 만들기 전에 가장 작게 시험할 방법은 무엇인가?
- 반응이 없다면 미련 없이 빼낼 수 있는가?
질문에 답하지 못한다면 AI가 금방 만들어줄 수 있어도 일단 보류하는 편이 낫다. 만들 수 있다는 것과 만들어야 한다는 것은 다른 문제이기 때문이다.
5. 크게 만들기보다 작게 확인하고 싶다
필요하다고 판단한 기능도 처음부터 완성형으로 만들 필요는 없다고 생각한다. 먼저 가장 작은 형태로 만들고 실제 사용자의 반응을 확인하는 편이 낫다. 사용자가 충분히 많고 비교할 조건이 된다면 A/B 테스트로 두 방식을 나눠볼 수도 있다. 아직 사용량이 적다면 인터뷰, 관찰, 짧은 프로토타입만으로도 처음 가정을 확인할 수 있다.
A/B 테스트는 두 가지 버전을 사용자에게 나눠 보여주고, 미리 정한 목표에 어떤 차이가 생기는지 비교하는 방법이다. 하지만 테스트라는 형식부터 갖추는 것이 목적은 아니다. 먼저 무엇을 알고 싶은지, 어떤 변화가 생기면 가설이 맞았다고 볼 것인지 정해야 한다. 사용자 수가 충분하지 않다면 인터뷰나 관찰만으로도 시작할 수 있다.
이전 바이브 코딩 1년을 돌아본 글에서는 코드를 직접 짜는 일보다 AI가 같은 원칙 안에서 움직이도록 설계하는 일을 더 고민하게 됐다고 적었다. 이번 태권도장 서비스는 그보다 한 단계 앞의 질문을 남겼다. AI를 어떻게 움직이게 할지 정하기 전에, 왜 움직여야 하는지부터 분명해야 했다.
AI 덕분에 이제는 예전보다 훨씬 많은 것을 만들 수 있다. 그래서 오히려 덜 만드는 판단이 중요해진 것 같다. 기능을 하나 더 완성하는 속도보다, 사용자가 정말 필요로 하는 이유를 찾는 속도가 더 중요할지도 모르겠다.
그냥 갑자기 떠오른 생각을 적기 시작했는데, 다음에 무언가를 만들 때는 이 질문만큼은 먼저 꺼내보려고 한다.
이 기능을 만들 수 있는가가 아니라, 왜 만들어야 하는가.
답글 남기기