[13호] AI 시대, 0→1 서비스에서 오픈보다 운영이 더 중요한 이유

안녕하세요. 프로덕트를 만들며 생각이 점점 많아지고 있는 hubert입니다.

요즘은 무엇이든 예전보다 훨씬 빠르게 만들 수 있는 시대가 된 것 같습니다. 기획 문서를 정리하는 일도, 화면 초안을 잡는 일도, 개발 보조를 받는 일도 이제는 AI의 도움을 꽤 자연스럽게 받을 수 있게 됐습니다.

그래서인지 새로운 서비스를 준비할 때도 예전보다 훨씬 빠르게 앞으로 나아갈 수 있다는 감각이 있습니다. 좋은 의미로든 부담스러운 의미로든, 오픈까지의 속도는 점점 더 빨라지고 있습니다.

그런데 서비스를 실제로 런칭하고 나면 이야기가 조금 달라집니다.

기능은 열렸는데 운영은 불안정하고, 서비스는 시작됐는데 구조는 아직 버티지 못하고, 결국 사람 몇 명이 계속 붙어 있어야만 굴러가는 상태를 자주 보게 됩니다. 저는 0→1 서비스가 진짜 어려워지는 시점이 오픈 직전이 아니라 오픈 이후였던 경우를 더 많이 봤습니다. 그리고 AI가 강력해질수록 오히려 이 차이는 더 커질 수도 있다고 생각합니다. 기능을 만드는 속도는 빨라졌지만, 운영 구조가 자연스럽게 따라 만들어지는 것은 아니기 때문입니다.

1. 오픈은 더 빨라졌지만, 운영 대응은 여전히 느리다

새로운 서비스를 만들 때는 늘 오픈이 가장 큰 목표가 됩니다. 언제까지 출시할지, 어떤 기능까지 포함할지, 유관 부서 일정은 맞는지, 리스크는 없는지. 오픈 직전의 조직은 대체로 같은 방향을 봅니다. 그런데 막상 서비스를 열고 나면 그다음부터 조금 다른 종류의 어려움이 시작됩니다.

오픈 전에는 잘 보이지 않던 문제들이 운영에 들어가면 갑자기 선명해집니다. 누가 어떤 기준으로 판단해야 하는지 애매하다거나, 생각보다 예외 케이스가 자주 발생한다거나, 고객 문의와 내부 운영 이슈가 특정 사람에게 몰린다거나 하는 문제들입니다.

오픈 전에는 “기능이 동작하는가”를 보게 되지만, 오픈 후에는 “이 구조가 반복 가능한가”가 더 중요해집니다. 많은 0→1 서비스가 흔들리는 이유도 여기에 있습니다. 겉으로는 서비스가 돌아가지만, 실제로는 아직 사람이 계속 붙어 있어야만 유지되는 상태이기 때문입니다.

AI가 있어도 이 문제는 저절로 해결되지 않습니다. 오히려 기능을 더 빨리 여는 것이 가능해질수록, 운영 구조를 미처 만들지 못한 상태로 오픈하는 일도 더 쉬워질 수 있습니다. 그래서 지금은 “얼마나 빨리 출시할 수 있는가”만큼이나 “출시 후 얼마나 덜 흔들릴 수 있는가”를 같이 봐야 하는 시기라고 생각합니다.

2. 0→1 서비스는 왜 운영에서 더 어려워질까

왜 이런 일이 생길까 생각해보면, 보통 비슷한 패턴이 반복됩니다.

첫째는 운영 기준보다 기능이 먼저 열려 있기 때문입니다. 정상과 예외를 어떻게 구분할지, 누가 어떤 상황에서 어떤 판단을 해야 할지, 어디까지 자동 처리되고 어디서부터 사람이 개입할지가 늦게 정리되는 경우가 많습니다.

둘째는 예외가 구조가 아니라 사람에게 붙기 때문입니다. 초기 서비스에서는 “일단 오픈하고 보완하자”는 판단이 현실적으로 필요할 때가 많습니다. 문제는 그 보완이 시스템이나 정책으로 흡수되지 않고, 특정 운영자나 기획자의 기억과 노하우에 남아 있을 때입니다. 그러면 서비스는 안정화되는 게 아니라 점점 더 사람에 의존하게 됩니다.

셋째는 운영 데이터가 제품 학습으로 연결되지 않기 때문입니다. 초기 서비스에서는 고객 문의, 반복 장애, 예외 대응, 수기 처리 로그 같은 것들이 가장 중요한 학습 재료가 됩니다. 그런데 이런 정보가 흩어져 있거나 대응만 하고 끝나면 운영은 계속 바쁜데 제품은 잘 배우지 못합니다.

그래서 저는 0→1 서비스에서 PM이 가장 먼저 해야 하는 일이 기능을 더 넣는 것이 아니라 운영 가능한 구조를 만드는 일이라고 생각합니다.

예를 들면 이런 것들입니다.

이 기준이 있어야 운영이 “사람이 버티는 상태”에서 “서비스가 버티는 상태”로 넘어갈 수 있습니다. 그리고 이 지점에서야 비로소 AI가 현실적인 도움을 줄 수 있습니다. 운영을 대신하기 때문이 아니라, 운영의 빈틈을 더 빨리 구조로 보이게 해주기 때문입니다.

예를 들어 초기 서비스 운영에서는 비슷한 문의와 예외 대응이 반복돼도, 처음에는 그것이 구조적 문제인지 단순한 잡음인지 구분하기 어렵습니다. 이럴 때 Claude 같은 AI에 최근 운영 이슈를 모아 이런 식으로 요청할 수 있습니다.

예전에는 이런 내용을 사람이 하나씩 읽고 감으로 묶어야 했다면, 이제는 어떤 문제가 반복되고 있는지, 무엇이 가장 먼저 구조화 대상인지 훨씬 빨리 드러낼 수 있습니다.

중요한 건 이 프롬프트가 정답을 대신 준다는 뜻이 아니라는 점입니다. 다만 운영을 막연한 바쁨으로 두지 않고, 구조적인 문제의 목록으로 바꾸는 속도는 분명히 빨라집니다.

3. AI는 운영을 대신하지 않지만, 구조는 더 빨리 보이게 한다

저는 AI가 초기 운영에서 특히 도움이 되는 지점이 세 가지라고 생각합니다.

첫째는 반복 이슈를 유형별로 빠르게 묶는 일입니다. 초기 서비스에서는 “요즘 비슷한 문제가 계속 생긴다”는 감각은 있는데, 그걸 정확한 유형으로 정리하는 데 시간이 많이 듭니다. AI는 이 반복 패턴을 먼저 드러내는 데 유용합니다.

둘째는 운영 로그와 대응 이력을 학습 가능한 형태로 요약하는 일입니다. Slack, 메일, CS툴, 회의 메모에 흩어진 정보를 사람이 다 읽고 묶으려면 늘 뒤로 밀리게 됩니다. 이때 Claude를 활용하면 “반복된 예외 5개”, “운영 가이드 부재로 생긴 문제”, “제품 수정 없이 사람 대응으로 막고 있는 이슈” 같은 형태로 빠르게 정리할 수 있습니다.

셋째는 운영 가이드 초안을 만드는 일입니다. 초기 서비스는 운영 기준이 문서보다 사람 머릿속에 먼저 존재하는 경우가 많습니다. 이럴 때 실제 대응 기록을 넣고 초안을 만들게 하면, 빈 페이지에서 시작하는 것보다 훨씬 빠르게 운영 기준을 정리할 수 있습니다.

예를 들면 이런 식입니다.

이런 방식이 특히 좋은 이유는 사람 머릿속에 흩어져 있던 운영의 암묵지를 문서화 가능한 형태로 끌어낼 수 있기 때문입니다. 실제로 운영 이슈를 모아 Claude에 분류를 요청해보면, 막연히 “요즘 운영이 너무 바쁘다”라고 느끼던 상태가 꽤 구조적인 문제로 정리되기도 합니다.

예를 들면 아래처럼 말입니다.

이런 결과물을 보면 운영이 단순히 바쁜 상태를 넘어서 어떤 구조적 문제를 품고 있는지가 훨씬 빠르게 보이기 시작합니다. 결국 중요한 건 AI 자체가 아닙니다. 어떤 운영 문제가 반복되고 있는지, 무엇이 구조적 문제인지, 무엇을 먼저 정리해야 하는지를 구분하는 시선입니다.

저는 그래서 AI를 운영의 대체재라기보다 운영 구조를 더 빨리 드러내는 증폭기로 보는 편이 맞다고 생각합니다. 오픈은 분명 중요합니다. 하지만 0→1 서비스에서는 오픈 자체보다 그 이후를 버티게 만드는 구조가 더 중요할 때가 많습니다.

제품은 출시되는 순간 완성되는 게 아니라,
운영을 견디는 과정 속에서 비로소 제품다워지는 것인지도 모르겠습니다.

📮 다음 호 예고

[14호] AI한테 메모앱 만들어달라고 했더니, 먼저 같이 기획서부터 쓰자고 하던데요.

요즘 Github에서 17만 스타 받고 있는 Superpowers라는 게 있어요. 클로드 코드에 깔고 "메모앱 만들어줘" 했더니 코드를 안 짜요. 대신 요구사항을 캐묻고, 스펙을 정리해서 승인받고, 그걸로 다시 고퀄 기획서를 써서 또 승인받은 다음에야 코딩을 시작하더라고요. 기획자 입장에서 보면 AI가 알아서 기획서를 싹 다 뽑아주고, 개발할 땐 합의한 스펙에 없는 기능은 절대 안 만드는 셈이에요. AI 코딩이 등장하면서 잠깐 잊혔다가 다시 주목받고 있는 스펙 드리븐 개발(SDD), 어떻게 할 수 있는지 메모앱 하나 만들면서 정리해봤습니다.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요. 🙂