본문 바로가기

기획/기획이야기19

랜턴의 서비스 기획 이야기 19 베타테스트 진행 글로벌 권역 현지 주재원을 통해, 기존 실적이 좋았던 호주,인도,중남미 대상으로 베타테스트를 진행했다. 셧다운 이후 재런칭하는 시점에, 사용실적 오프셋을 어느정도 확보하기 위함이었다. 특별히, 베타테스트를 할 기회를 제공한다는 취지로 커뮤니케이션을 실시했다. 이는 주재원 및 현지직원들과 레포를 형성하기 위함이었다. 어찌되었던 서비스 전개 관점에서, 오퍼레이터는 내가 아니라 그들이었기 때문에, 나는 그들의 전적인 협력이 필요했다, 따라서, 그들에게 적당한 칭찬으로 커뮤니케이션 장벽을 미리 허물고, 내가 완전히 을의 포지션이 되지 않도록 관계 설정을 하고자 했다. 동시에, 괜스레 서비스 셧다운이라느니 보안 문제라느니 등의 약점이 잡히지 않도록, 주목을 돌리는 방안이기도 했다. .. 2025. 5. 13.
랜턴의 서비스 기획 이야기 18 서비스 중단에 따른 예상들 내가 제공하는 서비스는 그레이존 업무에 가까운 성격을 가졌다. 이는 여러 이유가 있었는데, - 직접적인 내부사용자가 아니라, 회사와 계약을 맺은 협력사의 내부 사용자 대상이었으며 - 정식 업무 프로세스에 편재되지 못했으며 - 직접적인 베네핏이 없는 서비스가 아니었으며 - 사내 정치적 혹은 조직 구조에 따른 지지를 받지 못했고, - 그럴만한 성격의 서비스도 아니긴 했다 따라서, 월 평균 4만건 정도 사용되던 서비스 사용량이 폭락할 것이라고 예상했었다. 그리고 폭락한 이후에 사용량 회복 역시 어려울 것이었다. 따라서, 서비스 셧다운에 따른 사용률 폭락의 임팩트를 완충할 전략 수립이 필요했다. 3/4월 사용률 제고 계획 사용률을 어떻게 제고시킬 것인가? 수리적 .. 2025. 5. 13.
랜턴의 서비스 기획 이야기 17 내년의 계획은 미궁으로 AI에 대한 꾸준한 관심.그리고 나 자신의 역량 개발에 대한 갈망.기술 트렌드와 경험에 뒤쳐지는 것에 대한 걱정.업무 확장을 위해 후배들을 비슷하게 육성해야한다는 나만의 인사이트와 리더십.그리고 이제 입사 3년차로 성장하면서,자연스럽게 다음에 내가 할 일을 만들어야 함을 알게 되고 그럴 수 있게 되어갔다는 사실 등이 당시 하고 있던 프로젝트의 다음 프로젝트를 이어서 추진하고 싶어하게 했다. 하지만, 앞서 말한 것처럼, 당시 팀장님은 이런 데에 대한 지식과 역량이 없었다. AI에 대해 놀라움을 가졌지만, AI 기술을 가져오려면 내부 인력의 성장과 경험을 축적이 필수임을 이해하지 못했다.지금까지 그래왔듯이,대충 업체에게 시키면 AI를 적용할 수 있다는 잘못된 인식을 갖고 있었다.그 .. 2025. 4. 16.
랜턴의 서비스 기획 이야기 16 Google Korea Summit 참석 23년 11월 구글 코리아 서밋은, 코로나 이후 처음으로 열리는 구글 코리아 오프라인 행사였다. 그리고 나에게도 처음으로 참여하는 빅테크 행사이기도 했다. 21년 입사해서, 메타버스니 XR이니 디지털트윈이니 여러 기술들이 유행처럼 지나갔지만, 이번만큼은 더 이상 원히트원더가 아니라는 확신이 있었다. 23년부터 꾸준히 공부했던, AWS 공부는AI 기술 확장이 먼 일이 아님을오히려 한국에 있기 때문에 내가 얼마나 우물 안 개구리에 불과한지를 빠르게 깨닫게 해주었다. 내가 속한 조직이 IT 조직이 아니기 때문에, 뒤쳐진다는 압박감이 오히려 거셌을지도 모르겠다. 모르는 게 얼마나 많을지, 내가 얼마나 뒤쳐져있을지 감조차 오지 않았으니까 지금와서 생각해보면 정말 별.. 2025. 4. 15.
랜턴의 서비스 기획 이야기 15 화면기획서 등 개발 문서 부재의 아쉬움  중소업체는 문서 작성에 대해 큰 부담을 느낀다.그럴듯한 기획자 인력을 운용하는 것이 비용적으로 쉽지 않을 뿐더러 사실, 문서 작성이 가능한 기획자 인력이란 생각보다 요구되는 조건이 높기 때문이다. 조직 자체가 RQMT만 만족시키는 정도만 하면 된다는 생각의 허들 자체가 낮을 수도 있다. 나는 모두가 개발 전 과정에 참여하는 스크럼 형식으로 이 프로젝트가 운영되길 바랬다.이런 노력은 개발업체의 메인 디자이너가 PM역할을 해주기도 했고,개발자 인력이 대거 교체되면서 자연스럽게 문화를 빌드할 수 있는 여건이 되기도 했기 때문에그럭저럭 그렇게 되긴 했다.다만, 나 역시 초보 기획자였고, 문서의 중요성에 대해 잘 몰랐으며급하게 꾸려진 개발업체의 팀 역시 마찬가지였다.  Q.. 2025. 4. 7.
랜턴의 서비스 기획 이야기 14 클라우드 인프라 구축  실제로는 파일럿 프로덕트가 7-8월 즈음에 나와야 했지만, 여름 동안은 보안 심사 대응하는 것만해도 벅차서, 그냥 그렇게 시간을 흘려 보내버렸다.  그래도 봄 막판에, 인프라 전문 담당자가 개발팀에 합류하고6월에는 NCP 및 MSP와 계약 협의가 순조롭게 이어졌다.개발 외적인 것들을 정리하고, MSP와 인프라 설계에 대한 간략한 미팅을 거쳤다. AWS를 그래도 상반기에 몇개월 공부를 했기 때문에,NCP 서비스 구조나, 기존에 없던 서비스가 왜 추가 되야하는지 대략적으로 이해할 수 있었다.  ISMS 심사 준비 요구가 강하게 들어왔던 7-8월에는, 협력사와 어떻게 To-do 리스트를 정리할 지 깊이 토의했다. 개발 팀은 구 시스템은 보안 대응, 인프라 팀은 신 시스템 인프라 구축 개.. 2025. 2. 16.
랜턴의 서비스 기획 이야기 13 WEBGL 컨텐츠  내가 만들고 있는 웹은 크게 2가지의 유즈 케이스를 가지고 있었다.1. 전형적인 정적 컨텐츠 위주의 화면을 제공하는 경우 2. WEBGL 기반의 유저 인터랙션을 동반하는 시뮬레이션 화면을 제공하는 경우 특히, 2번의 경우는, Web+App을 만들겠다는 리더들의 염원에 의해 강력하게 이루어졌는데,이를 반대했던 나로서는 개발 과정의 중간에서라도 점검하고 싶었다.  나는 시장의 기대보다 작동하지 않을 경우를 대비하여Two Track으로 대응 방안을 수립했다.1. 컨텐츠 글로벌 사용 정책 수립 -> 글로벌 전개 시 동시 배포2. 개발 과정 중 WEBGL 컨텐츠 동시 제작 + 필드 베타 테스트 +a. 로컬에 캐싱을 지원하는 서비스 구성    1번의 대응방안은, 네트워크 불안 지역 또는 그러한 .. 2025. 2. 16.
랜턴의 서비스 기획 이야기 12 공부와 기획, 업무에 기름칠하기  10월부터 디자인 매터리얼을 꾸준히 탐독했고,12월~1월 사이에는 HTML / CSS를 공부했으며, 2~3월  사이에는 SQL과 RDB에 대한 공부를,4월부터는 AWS 중심으로 클라우드 공부를 하게 되었다.  좋은 PM 이전에, 내가 답답한 팀원이 되기 싫었기 때문이었다.나 스스로에게도  답답한 게 싫었고,협력사 개발자 및 디자이너들에게는 더더욱 싫었다. 공부를 하면 할 수록, 확실히 커뮤니케이션이 가속화되었다.개발자/디자이너들은 어려운 상황에 대해 장황하게 설명하는 노력을 하지 않아도 되었다. 나는 훨씬 명료하게, 아규먼트가 최소화될 수 있는 방향으로 요구사항을 정리할 수 있었다. 동시에 커뮤니케이션이 가능한 범위 역시 엄청나게 확장되었다. 개발자/디자이너들이 구체적인.. 2025. 2. 1.
랜턴의 서비스 기획 이야기 11 늦어진 개발 환경 구성  22년도 연말부터 인프라에 대한 결정 요구가 개발파트로부터 있었다당시 나는 그게 무얼 의미하는지 몰랐고, 당장 눈 앞에서 기획 의사결정하기에 바빴으므로, 의사결정 요청의 중요성에 대해 크게 인식하지 못했다. 하지만 새해에는 달랐다. 기본적인 요건 정의도 얼추 끝나는 단계였으므로,개발파트에서 더 강도 높게 인프라 결정에 대한 요구를 해왔다.인프라는 웹보다도 나에게는 완전 생소한 영역이었으므로 공부가 필요했다. 클라우드 서비스가 무엇인지 클라우드 서비스 프로바이더는 어떤 업체들이 있는지 등 등 정말 기본적인 시장 조사부터 빠르게 마쳤다. 하지만, 현 단계에서 어떤 스텝을 밟아야 할지는 경험과 가이드가 없는 나로서는 여전히 당황스러웠다. 내가 의사결정할 수 있는 것은 무엇인가? 어디까.. 2025. 1. 3.
반응형