AI 도구의 발전으로 개인 개발자가 서비스를 만드는 속도는 크게 빨라졌다. 화면을 구성하고, 데이터를 모으고, 태그를 붙이고, 설명을 생성하고, 배포하는 일까지 예전보다 훨씬 적은 비용으로 가능해졌다.
하지만 이 속도는 나에게만 주어지는 것이 아니다. 다른 사람도 같은 도구를 쓴다. 그래서 이제 단순한 정보형 서비스에서는 “만들 수 있는가”보다 “언제 공개할 것인가”가 더 중요한 문제가 된다.
본 글은 국제차문화대전 부스 정보를 인터랙티브 맵으로 정리해 배포한 경험을 바탕으로, AI 시대의 빠른 배포가 어떤 신뢰 문제를 동반하는지 정리한다.
국제차문화대전에 참여하려고 공식 부스배치도를 확인했다.
그런데 정보 탐색성이 좋지 않았다.
부스 위치는 한눈에 들어오지 않았고, 어떤 업체가 어디에 있는지, 어떤 성격의 업체인지, 내가 관심 있는 카테고리의 부스가 어디에 모여 있는지 파악하기 어려웠다.
그래서 직접 인터랙티브 맵을 만들기 시작했다.
처음 아이디어는 단순했다. 공식 부스배치도를 기반으로 부스 위치를 웹에서 탐색 가능하게 만들고, 업체별로 태그와 설명을 붙이고, 검색과 필터링이 가능하게 만드는 것이었다. 업체 정보는 LLM을 이용해 초안을 만들었다. 업체명을 기준으로 관련 정보를 찾고, 어떤 제품이나 서비스를 다루는지 추정하고, 리뷰성 정보나 외부 언급도 최대한 모으려 했다.
처음 목적은 내가 행사장에서 실제로 쓰기 위한 비공식 탐색 도구에 가까웠다. 개인용으로만 쓴다면 배포까지 할 필요도 없었다. 내가 필요한 정보만 확인하고, 행사장에서 지도처럼 쓰고 끝내도 충분했다.
그런데 어느 정도 만들고 나니 생각이 바뀌었다.
부스맵을 정리하고, 업체 정보를 모으고, 태그를 정리하고, 화면을 다듬는 과정에는 생각보다 많은 시간과 추론 비용이 들어갔다. 단순한 개인용 스크립트라기보다 작은 정보형 서비스에 가까워지고 있었다. 그렇다면 이걸 나 혼자 쓰고 끝내기보다는 실제 사용자에게 공개하고 반응을 보는 편이 낫겠다고 판단했다.
사용자가 어떤 식으로 검색하는지, 어떤 정보를 신뢰하는지, 어떤 지점에서 불편함을 느끼는지 확인할 수 있다면 다음에 다른 서비스를 만들 때도 도움이 될 수 있다.
다만 가장 큰 문제는 데이터였다.
지도와 기본 UI는 비교적 빠르게 만들 수 있었다. 하지만 업체별 태그와 설명은 달랐다. LLM이 정보를 모으고 분류해줄 수는 있지만, 그 결과를 그대로 믿을 수는 없었다. 업체가 실제로 어떤 제품을 다루는지, 특정 태그가 적절한지, 외부 정보가 맞는지 하나씩 확인해야 했다.
그래서 정보 수집과 검수 보조 에이전트를 돌려두고, 사람이 확인해야 하는 항목을 계속 검토하고 있었다.
여기까지는 내부 작업의 문제였다. 시간이 더 필요할 뿐, 방향은 명확했다.
문제는 그 사이에 외부 상황이 바뀌었다는 점이다.
정보 수집과 검수 에이전트를 돌려놓고 잠시 다른 일을 했다. 운동을 다녀오고, 이후 트위터와 인스타그램을 훑어봤다. 그런데 비슷한 페이지를 런칭하려는 움직임이 보였다.
그 결과물의 완성도가 당장 위협적일 정도로 높아 보이진 않았다. 화면 구성이나 UX는 내가 만들고 있던 것에 비해 부족해 보였다. 하지만 중요한 건 완성도가 아니었다.
그들은 빠르게 배포하는 전략을 취하고 있었다.
이 지점에서 판단 기준이 바뀌었다.
경쟁 서비스의 품질이 낮더라도, 먼저 사용자에게 도달하면 상황이 달라진다. 특히 행사 정보 서비스는 타이밍이 중요하다. 완성도 높은 도구 늦게 나와봐야 의미가 줄어든다.
사용자는 행사 한참 전에 링크를 받고, 북마크하고, 공유하고, 현장에서 사용한다. 따라서 며칠 뒤의 완성도보다 지금 당장의 접근성이 더 강한 무기가 될 수 있다.
당시 내가 본 상황은 이랬다.
몇시간 전에 배포된 서비스가 있었다.
그러나 내가 가진 UI와 UX의 품질 우위가 있었다.
그렇다면 완전 검수를 기다리는 것보다, 화면과 사용성을 조금만 더 다듬은 뒤 빠르게 공개하는 편이 낫다고 판단했다. 경쟁 서비스가 먼저 퍼지기 전에, 더 나은 사용성을 가진 버전으로 먼저 사용자 유입을 잡을 수 있다고 봤다.
그래서 전략을 바꿨다.
완전 검수 후 배포가 아니라, 사용 가능한 수준에서 먼저 공개하고 이후 수정하는 방식으로 가기로 했다. 새벽 4시까지 화면과 UX를 만지고, 기본 동선을 테스트하고, 배포 가능한 수준이라고 판단한 뒤 공개했다.
다만 데이터는 완전히 검수된 상태가 아니었다.
그래서 사이트에는 비공식 서비스라는 점, 일부 정보는 AI로 생성되었다는 점, 아직 검수 중이라는 점, 정확한 내용은 직접 확인해야 한다는 점을 명시했다. 또한 오픈소스로 공개해 잘못된 정보를 수정할 수 있는 여지도 열어두었다.
개발자 입장에서 이 선택은 합리적으로 보였다.
빠르게 배포하지 않으면 시장을 놓칠 수 있었다.
검수를 기다리면 더 안전하겠지만, 그 사이 사용자 유입을 잃을 수 있었다.
그런데 자고 일어나서 보니, 문제는 바로 다른 방향에서 터져 있었다.
배포 후 반응이 올라오기 시작했다. 트래픽이 있는 것 같았다. 사람들이 실제로 사이트를 보고 있는 듯했다.
문제는 그들이 정보를 받아들이는 방식이었다.
아직 검수하지 못한 태그나 설명을 본 사용자가 “이런 부스는 원래 적은가?”, “이 업체가 정말 이런 걸 하는 곳인가?”, “이 카테고리는 여기밖에 없는가?” 같은 식으로 반응하기 시작했다.
내 입장에서는 해당 정보가 아직 검수 중인 데이터였다.
LLM이 생성한 초안이고, 사람이 확인해야 하는 항목이었다.
사이트에도 그렇게 적어두었다.
하지만 사용자는 그렇게 소비하지 않았다.
제작자는 데이터의 내부 상태를 알고 있다. 어떤 정보가 공식 자료 기반인지, 어떤 정보가 LLM 생성인지, 어떤 항목이 검수되었고 어떤 항목이 미검수인지 알고 있다.
하지만 사용자는 모른다.
사용자에게 보이는 것은 그냥 웹페이지다. 검색이 되고, 태그가 붙어 있고, 지도 위에 위치가 표시되면 그 정보는 더 이상 초안처럼 보이지 않는다. 서비스의 형태 자체가 정보에 권위를 부여한다.
게다가 운영 측면에서도 문제가 있었다.
빠르게 배포하는 데 집중하느라 트래픽 추적 장치를 제대로 달아두지 않았다. 분석 도구가 없으니 실제로 얼마나 많은 사람이 들어왔는지, 어떤 페이지를 봤는지, 어떤 검색어를 입력했는지, 어디에서 이탈했는지 확인할 수 없었다.
정성 피드백은 올라오는데, 정량 데이터는 없는 상태였다.
사용자가 있다는 것은 느껴졌다.
문제가 있다는 것도 보였다.
하지만 규모와 우선순위는 알 수 없었다.
결국 배포 직후의 문제는 두 가지였다.
첫째, 사용자가 미검수 정보를 예상보다 강하게 신뢰하기 시작했다.
둘째, 그 반응을 분석할 수 있는 관측 장치가 없었다.
빠른 배포 전략은 성공한 듯 보였지만, 동시에 신뢰 관리와 운영 관측성의 부재를 그대로 드러냈다.
오픈소스로 공개했다는 사실은 개발자에게는 중요한 의미를 가진다.
개발자 입장에서 오픈소스는 투명성의 장치다. 코드가 열려 있고, 데이터 수정 이력이 남고, 잘못된 부분은 이슈나 PR로 고칠 수 있다. 완성되지 않은 상태라도 공개적으로 개선할 수 있다. 특히 빠른 배포가 필요한 상황에서는 오픈소스가 꽤 합리적인 선택지처럼 보인다.
나 역시 그렇게 생각했다.
검수 중인 데이터가 있더라도, 오픈소스로 열어두면 수정 가능성이 생긴다. 잘못된 정보가 발견되면 고치면 된다. 사용자가 제보할 수도 있고, 관심 있는 사람이 직접 PR을 보낼 수도 있다. 개발자 관점에서는 이것이 자연스러운 운영 방식이다.
하지만 일반 사용자는 그렇게 보지 않는다.
사용자는 GitHub 저장소를 보지 않는다.
커밋 로그를 보지 않는다.
데이터 파이프라인을 보지 않는다.
이슈 탭을 보지 않는다.
오픈소스인지 아닌지도 신경 쓰지 않을 가능성이 높다.
사용자는 배포된 URL에 접속한다.
검색창에 키워드를 넣는다.
결과를 본다.
그리고 판단한다.
개발자에게 이 서비스는 “검수 중인 오픈소스 프로젝트”였다.
사용자에게 이 서비스는 “행사 정보를 보기 좋게 정리한 웹사이트”였다.
사용자는 미완성 상태를 결과물로 경험한다.
개발자는 “열어두었으니 고칠 수 있다”고 생각한다.
사용자는 “여기에 이렇게 적혀 있으니 맞겠지”라고 받아들인다.
따라서 오픈소스는 사용자 신뢰 문제를 자동으로 해결하지 않는다. 오픈소스는 개발 과정의 투명성을 높일 수는 있지만, 사용자가 화면에서 정보를 어떻게 해석하는지는 별개의 문제다.
댓글 0