brunch

You can make anything
by writing

C.S.Lewis

by 아리언니 Sep 01. 2020

화면 설계 안 하는 서비스 기획자

물론 컨펌은 합니다.

어느덧 이직한 지 1년이 다 되었는데, 내 업무를 종합해보면 "화면 설계를 직접 그리지 않는 서비스 기획자이자 PM(이하, Product Manager)"이다.  


종종 기획자들이 모인 커뮤니티에서 대화를 나누다 보면 직접 화면 설계를 하지 않는 기획자 이야기에 놀라는 사람들이 꽤 많다. 나 또한 내가 생각한 업무 롤이 함께 일하는 파트너 사로 넘어가게 되어 가끔 '이게 맞나?' 할 때가 있곤 했다. 


오늘 글은 화면 설계를 하지 않게 되었을 때, 특정 조직에서 기획자가 어떤 역할을 하는지에 대한 이야기이다.




왜 자사 서비스 화면 기획을 직접 하지 않지?


내가 화면을 그리지 않게 된 이유 중 가장 큰 부분은 조직의 구성이다. 나는 사업팀에 소속됐으며 사업팀 내에 IT관련자는 나뿐이다.  내 첫 업무는 외주 개발사를 물색하고 선정하는 것이었고 개발을 리딩 해야 하는 역할이 주어졌다. 


당시 신사업을 론칭 과정에서 필요한 IT서비스에 필요한 기능들을 내부에서 압축해 상위 기획을 했다.

이 서비스가 왜 필요한지, 어떤 유저가 사용하게 될지 등을 설계해 파트너사에 전달했고 파트너사는 우리의 요청을 바탕으로 화면 설계서 작업을 진행해주었다. 


이전 회사에선 내가 무조건 화면 설계서를 그리고 외주업체에 전달해주는 형태였기에 파트너사에서 화면 설계를 그려왔을 땐 '아, 정말 꼼꼼하다, 나는 이렇게 할 수 있을까?(자괴감)'이 가장 크게 들었다.

그간 인하우스에서 기획해 왔던 것과 실제 파트너사에서 산출물로 가져온 기획서는 퀄리티 차이가 어마어마했다. 


하지만 이내 내 롤은 이 기획서가 우리 사업에서 요구하는 방향과 맞는지 검토하는 일이었다. 





그렇다, 검토와 커뮤니케이션이 주 업무가 되었다.


처음엔 내가 기획한 내용을 내부에 공유하다 보니 기획서가 나오는 대로 모여서 논의하고 수정을 했지만 업체에서 그려오는 기획서는 내가 온전히 이해를 하고 내부에 공유해야 해 소화하는데 시간이 꽤 걸렸다.

그러다 보니 '이럴 거면 내가 그릴걸 그랬나..'싶었지만 정말 파트너사 분들이 없었다면 신사업 IT서비스는 제때에 세상에 나올 수 없었을 것이다. 그래서 나는 업체와 논의한 WBS에 맞춰 화면을 컨펌하기 시작했다.


매일 메일이 20통씩 쌓였다. 그중 10건은 검토를 해야 하는 건이었다. 

그리고 그 검토는 온전히 나 혼자만 결정을 할 수 있는 게 아니었다.

그러다 보니 내 선에서 논리적으로 이해가 가는 사항들을 OK 하고 넘어갔는데 이게 또 문제가 생겼다.

논리적으론 맞을 지라도 사업적인 방향과 맞지 않는 결정들이 있었다. (정말 내 역량 부족) 

파트너사에서 내 잘못된 direction으로 기획 원복을 몇 번하게 되었고 이후 나는 극단적으로 변했다. 


'내가 생각하지 않고 내부에 확인받기'였다.


이 시기 정말 자괴감이 많이 들었다. 나는 그냥 중간 역할인가? 정말 커뮤니케이션만 대신해주는 사람인가? 싶었으면서 내 잘못된 결정으로 파트너사가 불필요한 업무를 하는 것에 대해 미안한 마음이 컸기에 세세한 부분이라도 묻고 진행하게 됐다. 


하지만 이건 정답이 아니다.


사업팀에서 나에게 바라는 역할은 IT서비스를 사업의 취지에 맞춰 구성을 해나가는 것이었다.

나는 화면 설계서를 내부에 컨펌받는 게 아니라 화면 설계 중 사업적으로 이슈가 될 만한 부분을 캐치해 Needs를 파악하고 이를 반영할 수 있게 피드백하는 일이다.  그리고 내가 개선하길 원하는 부분 정도만 내부에 공유해 의견을 수렴해 더 나은 방향으로 이끄는 일이다.





그럼에도 나는 끌려다녔다. 


(사업팀에, 파트너사에) 

이건 전적으로 내가 내 롤에 대한 이해가 부족했기 때문에 생긴 문제였다.

얼마나 롤에 대한 이해가 없었냐면 IT서비스 개발 주간회의에 실무 담당자를 모두 참석시켰다. 

당시 내 마인드는 논쟁할 게 있으면 여기서 하고 여기서 컨펌하자, 나는 내부 입맛 맞추기가 힘들어 였던 것 같다. (정말 무책임하다....) 


당시 바쁘긴 무지 바빴지만 중심을 잡지 못했고 실무 담당자들의 소중한 시간을 뺏어가며 내 업무를 편하게만 하려고 했었다. 

환경이 변화하면 그에 맞게 내 역할도 변화하고 그 변화에 맞춰 나를 탈바꿈해야 함에도 그저 멍하니, 

파트너사가 그려오는 몇 백장 화면 설계서를 보며 그저 감탄하고 이걸 언제 다 확인하지 하며 압박감만 느꼈다. 매일 하는 업무 중 가장 큰 부분이 메일 확인이었고 다 확인하면 퇴근하곤 했다. 그 당시에 나에겐 정말 발전이 없었다. 파트너사가 주가 되고 사업일정이 주가 되어 나는 끌려다녔다.


그래서일까, 당시 나는 개발 중인 서비스에 대해 명확하게 설명하지 못했다. 






나는 신사업 IT서비스 책임자입니다.


신사업 론칭 도중 내부 조직의 업무 구조 변화가 있었다. 기존에는 없던 사업의 Project Manager를 지정했고 나는 PM과 소통하며 서비스를 만들어가기 시작했다.

처음엔 사업 론칭을 3개월도 안 남기고 조직 변화가 있다 보니 risky 하다고 생각했지만 결론적으론 PM덕분에 서비스에 대한 애정과 책임감, 그리고 리딩 할 수 있는 자신감이 생겼다. 


PM으로 지정된 동료와 처음 미팅 때, 내가 끌려다니며 주체적으로 IT서비스를 리딩 했으면 좋겠다는 피드백을 받았다. 내부에서도 내가 끌려다니던 포지션일 때 나에게 바라던 롤을 내가 소화하지 못하고 있었다는 걸 느꼈다. 그때 어찌 보면 부정적인 피드백이었지만 나는 이상하게 기운을 얻었다. 


"그래, 내가 정말 제대로 리딩 해볼게."


늦었지만 그때 깨달았다. 내가 위에서 느낀 점들을


마음을 고쳐먹고 적극적으로 QA를 진행했다. (이미 개발 진척이 많이 되었다) 

당시 QA 진행 전 유저 시나리오를 작성해 서비스 흐름에 대해 나뿐만 아니라 내부 담당자들의 서비스 이해도를 높인 후 QA를 진행했다.

Flow를 체화하고 QA를 하니 기획서와 다르게 구현된 것들, 문제사항들이 많이 보였고 약 200건 정도의 수정사항을 요청했다. (업체에서도 이미 몇 백개의 수정 사항을 업데이트한 후였다) 


그렇게 완벽에 완벽을 가해 8월 3일 신사업 IT서비스 중 하나인 홈페이지를 오픈했다. 





이것도 내가 해야 해? YES


홈페이지를 오픈하고 기쁨은 잠시, SEO 작업을 파트너사에 요청한 적이 없었고 내부에서도 SEO에 대한 이해가 없었다. 아무리 우리 사이트를 검색해도 홈페이지가 뜨지 않았다.

내부에선 개발사가 진행해야 하는 업무라고 한다. 개발사에선 요청받지 않은 업무이며 내부에 전문가가 없다고 한다.

이때 이전 회사에선 해당 작업을 마케팅 팀에서 진행했던 걸 떠올렸다.

그래서 내부 홍보 담당자가 해야 하는 업무라며 옥신 각신 언쟁을 했다. (미안...)


결과적으로 우리 조직에선 내 업무 롤이 맞았다. SEO 검색엔진 최적화 작업을 위해선 홈페이지 내에 메타태그를 삽입해야 하고 이걸 검색엔진에서 읽어오도록 검색로봇 소스도 심어야 한다. 개발사에의 도움으로 해야 하는 업무는 전적으로 내 역할이었으므로 내가 해야 했기에 네이버 서치 어드바이저 도움말을 보며 알음알음 태그를 추가했다. 그럼에도 신사업을 검색했을 때 사이트가 나오지 않았다.


이때, 몇 날 며칠을 끙끙 앓다가 내가 할 수 없는 일이라면 전문가의 도움을 받자 라고 결론 내렸고 수소문 끝에 SEO 검색엔진 최적화 전문가를 찾았다. 곧바로 견적과 기대효과에 대해 PM과 팀장에게 보고했고 전문가를 섭외했다.


당시 왜 내가 다 하려고, 내부에서 다 소화하려고 아등바등 괴로워하며 시간을 보냈을까 라는 생각이 든다. 

(미련했다) 


전문가가 방문해 1시간가량 사이트 분석을 하고 코드 몇 개를 수정하고 며칠이 지나자 신사업 검색 시 우리 사이트가 상위 노출되었다. 네이버 서치 어드바이저에서 사이트 평가를 해보니 전문가를 부르기 전엔 웹 표준 준수 상위 18%였는데 다녀가고 나선 상위 3%로 올라갔다. 그 덕에 지금도 검색엔진에서 정말 잘 나온다. (심지어 사이트 맵도 불러온다!) 





IT서비스에 대한 주인의식을 가지고 설계하자.


이제 IT서비스를 세상에 내놓았으니 사이트를 더 개선하고 사용하기 편하게 해야 한다. 


물론 사이트뿐 아니라 관리자 사이트, 자사 앱도 있기에 항상 유저의 이야기를 귀담아듣고 잘 수렴해 적절한 시점에 개발사에 업무 요청을 해야 한다. 이 또한 경험이 적은 안정화 업무이기에 긴장이 많이 되지만 이 사업에 있어서 나의 역할과 책임에 대해 깨닫게 된 후론 중심이 생겼다. 나는 화면 설계를 직접 그리지 않지만 사용자의 목소리를 귀담아 우리 서비스에 녹여내는 설계자이다. 


이번 프로젝트를 통해서 내가 느낀 건  화면 기획만 직접 그리지 않았을 뿐이지 이 서비스를 개발하면서 내가 involve 한 부분이 이렇게나 많았다.  







몸담은 조직이 나에게 바라는 것이 무엇일지 항상 생각하자.


이전 회사와 같은 IT서비스 기획자라는 직무로 이직을 했지만 내 역할은 180도 달랐다. 

단순히 화면 설계를 하고 QA를 하던 기획자를 벗어나 전체 product를 책임지는 관리자가 되었다.

그렇기에 이 서비스가 잘못되면 전적으로 내 탓이고 나는 어떻게든 이 서비스가 제대로 전달될 수 있게 긴장하고 있어야 한다. 그리고 내가 선 그었던 '내 업무 아냐!' 했던 것들도 product의 완성도를 위해서라면 다시 되짚어 보고 모르면 찾아보고 그럼에도 힘들다면 전문가의 도움을 얻어서라도 해내야 한다.

또 같은 조직에 있더라도 시대 변화에 따라 요구하는 역할은 달라질 것이라는 걸 항상 생각해야 한다.


그렇기에 나는 더 완벽한 product를 설계할 수 있는 역량강화를 목표로 삼았다.


말도 많고 탈도 많고 스트레스도 많았던 프로젝트지만(아직 끝나지도 않았지만), 

내가 리딩 한 서비스가 더 좋은 사용자 경험을 제공할 수 있게 늘 긴장하고 냉철하게 바라봐야겠다.


또 이 모든 건 서로가 함께 만들어간 결과물이다. 그렇기에 내가 한 일들만 위주로 썼지만 진행하며 깊게 고민하고 개발까지 이끌어준 개발사분들, 내부 동료들의 시간을 소중히 하며 커뮤니케이션해야 한다. 

매거진의 이전글 사이트를 리뉴얼해야 하는 이유

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari