기획87 랜턴의 서비스 기획 이야기 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. 개발 과정에서의 중간 산출물 요구사항 정의서 기획 초반에 요구사항 정의서를 분명히 남겨서, 도메인 전문가의 요구사항을 반영할 수 있도록 한다. 워터폴 방식으로 진행할 때에도도메인 전문가의 의견이나, 상호 소통 부족에 따라 요구사항은 새롭게 정의될 수 있다. 이는 요구사항에 대한 추적표를 통해 별도 관리하여 최신화될 수 있도록 한다. 요구사항 추적표도메인 전문가 또는 프로젝트 참여자의 착오로 기존 요구사항이 변경될 수 있다.혹은 프로젝트 진행 과정에서 터지는 현실적인 문제들도 원인일 수 있다. 필요하면 다음 기회로 해당 요구사항을 넘겨야 할 수도 있고,아예 개발요건에서 삭제도 가능하다. 화면설계서도메인 전문가와 업무를 진행할 때,실제로 커뮤니케이션 가능한 시점은 바로 이 시점부터라고 생각이 든다. 요구사항에 화면설계가 대응될 .. 2025. 1. 25. 랜턴의 서비스 기획 이야기 11 늦어진 개발 환경 구성 22년도 연말부터 인프라에 대한 결정 요구가 개발파트로부터 있었다당시 나는 그게 무얼 의미하는지 몰랐고, 당장 눈 앞에서 기획 의사결정하기에 바빴으므로, 의사결정 요청의 중요성에 대해 크게 인식하지 못했다. 하지만 새해에는 달랐다. 기본적인 요건 정의도 얼추 끝나는 단계였으므로,개발파트에서 더 강도 높게 인프라 결정에 대한 요구를 해왔다.인프라는 웹보다도 나에게는 완전 생소한 영역이었으므로 공부가 필요했다. 클라우드 서비스가 무엇인지 클라우드 서비스 프로바이더는 어떤 업체들이 있는지 등 등 정말 기본적인 시장 조사부터 빠르게 마쳤다. 하지만, 현 단계에서 어떤 스텝을 밟아야 할지는 경험과 가이드가 없는 나로서는 여전히 당황스러웠다. 내가 의사결정할 수 있는 것은 무엇인가? 어디까.. 2025. 1. 3. 랜턴의 서비스 기획 이야기 10 운이 좋게 시작한 프런트 엔드 공부 11월에 사내에서 Udemy 계정을 준다고 하여, 좋은 기회다 싶어서 잽싸게 신청했다.욕심은 기획하는 동안 필요할 수 있는 모든 강의를 듣고 싶었다. 백엔드, 데이터, 프런트엔드 ,디자인 .. 등 등.계정이 당해 12월까지 만료였기 때문에, 수강에 대한 전략을 세워야 했다. 당장 하고 있는 방식의 전문성을 높이는 게 필요하다 싶었다.이에, 프런트 엔드 강의를 듣기로 하였다. 나는 수학에 대해서 욕심을 좀 많이 내는 편이라,실습 포함 600강 정도 분량이 되는 강의를 선택했었다.기간이 45일 정도 되었으므로, 주말 제외 30일 정도로 잡고하루 평균 20강 정도 들으면 어림 잡아 완강 가능하다고 계산했던 것이었다.강의를 2배속으로 들으면 실질 수강 시간은 10강 남짓에 .. 2024. 12. 29. 랜턴의 서비스 기획 야이기 9 분석단계에서의 기획에 대한 무지 -> 소통이라도.. 나는 당초부터 기존의 개발 업체를 유지하는 방향으로 업무를 추진했다. 사유는 아래와 같았다, - 이 웹이 달성하고자 하는 비즈니스 목적을 설명하고 이해시키는 것이 가장 어렵고 - 컨센서스를 만드는 데 소요되는 시간 비용이 적지 않을 것이라는 생각이 있었으며 - 기존 매터리얼을 참조하여 구조를 유지하는 데도 이 편이 편했기 때문이었다 사용자 분석과 비즈니스 분석을 명징하게 하지는 않았지만,이전의 기획서와 비슷한 몇 가지 아이템들로 감각적인 컨센서는 확보할 수 있었다.그럼에도 불구하고, 나의 개선에 대한 의지 + 대대적인 디자인 개편이 있었기 때문에개발 그룹은 어디서부터 요건을 정리해 나갈지 감을 잘 못잡는 편이었다이는 당시 지식적 경험적으로 불완전.. 2024. 12. 22. 랜턴의 서비스 기획 야이기 8 첫번째 컨셉 디자인 그리고 나의 문제점 : 디자인에 대한 무지 8월말에 우리는 크게 3가지의 컨셉 디자인을 뽑을 수 있었다- 마케팅 커뮤니케이션 가이드에 의존한 디자인- 업체가 평소에 자주 하던 디자인- 3D 콘텐츠를 보여주는 시스템이라는 점을 최대한 UI적으로 부각한 디자인 차라리 어떤 것이 미학적으로 촌스러움이 확 부각되었다면 문제가 쉽게 풀렸을 터였다.하지만, 디자인을 하시던 분이 디자인 했으므로 기본적인 미학성은 보장되었다.그러니까, 나는 시안까지 제작을 시켰음에도 여전히 결정할 수 없었다. '무엇이 좋은가?' 선택하기도 중요했지만, 나는 그것보다 근원적인 문제가 있음을 알았다. '바로 왜 나는 결정할 수 없는가? '라는 문제였다. (쓰면서 느끼는 건데, 나는 확실히 스스로에게 어려운 질문을 .. 2024. 12. 18. 랜턴의 서비스 기획 야이기 7 돌아보았을 때 아쉬웠던 점 내가 IT 기술 조직이 있지 않았기 때문에,또 협력업체 역시 전문 PM 인력 구비가 안되었었기 때문에,산출물과 프로젝트 매니지먼트가 제대로 이뤄지지 않았다.가령, 이 단계에서 우리는 기획에 대한 보다 면밀한 조사 단계와RFP를 작성했어야 했다. 우리가 가진 것은, 본부장님 상대의 보고 자료와 그 보고자료를 만들기 사전에 나 홀로 파워포인트로 만든PPT에 가까운 요건 기획서가 있었다. 그것으로는 수개월 동안 지속해서 참조할 자료로는 역부족이었던 것이다. 당시에는 하지만 어떻게 해야 할 지 몰랐다. 내가 업무를 추진하는 방식과 스킬에 부족한 점이 있다는 것은 경험적 / 감각적으로 알고 있었다.다만, 팀 내에 나와 같은 생각과 시선을 공유할 사람이 없었다.그래서 어쩔 수 없이 나.. 2024. 12. 10. 이전 1 2 3 4 ··· 10 다음 반응형
