재작년에 파이썬코리아에 참석했었다. 개발자도 아니면서 '파이썬'이란 언어에 한창 빠져 배우고 있을 때 개발자에 대한 로망이 있었던 거로지. 개발 용어로 난무하는 강연에서 절반도 못 알아듣는 일이 허다했지만, '완벽한 결과물'이 아닌 개발하는 과정에서 벌어지는 삽질의 연속을 생생하게 들을 수 있다는 점이 매력적으로 다가왔다. 당시에는 머리를 싸매고 치열하게 고민하던 과정이 있었을 것이다. 그러나 그런 과정을 숨기지 않고 유머러스하게 풀어내며 다른 개발자가 삽질하지 않게 기꺼이 노하우를 공유하고 있었다. 나는 그런 문화가 좋았다.
그래서 이제 입사한 지 한 달이 채 되지 않은 시점에 첫 프로젝트를 맡으면서 기획자의 삽질한 경험을 공유해보려 한다. 누군가 보기엔 별거 아닐 수 있겠지만, 주니어 기획자가 어떤 점에서 어려움을 겪고 어떻게 해결할지 모르는 분들께는 도움이 될 거라 생각한다. 지난번에 썼던 <주니어 기획자가 느끼는 고민들> 이후로 브런치에 기획자 관련 글들이 자주 보이게 된 것 같아서 기분이 좋기도 하고. 기획자들 사이에서도 삽질에 대한 얘기가 많이 나왔으면 좋겠다.
사수가 없는 스타트업에서 기획을 하려다 보면 멘붕의 순간을 맞이한다. 기업마다 기획자에 대해 요구하는 역할이 다르기도 하고, 팀마다 일하는 방식이 다르기 때문이다. 입사한 지 2주일이 됐을 때 이번 분기에 추진하려고 했으나 우선순위에 밀려 미뤄뒀던 프로젝트를 맡기로 했다. 2주 내내 어떤 일을 해야 할지 몰라 방황하던 중에 받은 첫 업무라 이제 일을 제대로 하는구나 싶어 좋았다. 그런데 막상 '자, 시작!' 하고 나니 '뭐부터 해야 하지??' 하며 반 백지상태가 돼버렸다.
우리 회사는 노션에 프로젝트 일정을 관리하고 있는데, 내가 맡은 프로젝트를 살펴보니 대략적으로 UI나 담을 콘텐츠가 정해져 있었다. 분명히 기획자가 하는 일, 프로젝트 방식에 대한 아티클을 무수히 많이 읽었는데 막상 일이 닥쳐오니 하나도 생각이 안 났다. 애초에 내가 겪는 상황에 딱 적합한 내용도 없었다. 그렇게 내 첫 삽질은 팀원에게 묻는 대신 인스파이어드, 프로덕트 오너와 같은 책을 보며 나름의 형식을 만들려고 했다는 데서 시작됐다.
하루, 이틀, 사흘, 나흘. 시간이 지날수록 마음은 초조해지고 여전히 쭈뼛한 상태에 있었다. 그러던 중 하루는 주로 재택근무만 하시던 개발자분이 회사에 나와 점심을 같이 먹게 됐다. 가는 길에 프로젝트는 언제 시작하냐는 얘기가 나왔다. 나는 기획일이 처음이라 어디서부터 시작해야 할지 모르겠다고 털어놓았다. 그러자 개발자분은 이렇게 말했다.
"저는 꽃비내린이 경력직인 줄 알았어요. 아마 다른 팀원분들도 꽃비내린이 어느 정도까지 알고 있는지 몰라서, 말해주길 기다리는 거일 수도 있어요. 먼저 이렇게 해보자라고 말하면 바로 답해주실 거예요."
나는 이 말을 듣고 아차 싶었다. 일을 진행하려면 뭐가 필요한지 알려면 팀원들에게 물어보면 되는 거였다. 프로젝트를 해본 경험이 없으니 하나하나 알려달라고 하기 부끄러워서 주춤했던 것 같다. 그 얘기를 듣고 자리에 돌아와 슬랙으로 곧장 이런 걸로 해보고 싶은데, 개발에선 뭐가 필요한지 디자인에선 뭐가 필요한지를 물었다. 팀원분들은 '이런 걸 챙겨줬으면 좋겠어요'라고 답했고 이제 내가 뭘 해야 할지를 알았다.
두 번째 삽질은 네이밍 선정이었다. 외부인의 시선으로만 봤을 땐 별거 아닌 네이밍이 내부인의 시선에선 고민에 고민을 거듭해 완성된 거구나 싶었다. 우리 서비스가 특수한 형태의 서비스다 보니 레퍼런스를 찾기도 쉽지 않았다. 자칫하면 서비스의 정체성과 멀어질 수도 있는 이 기능을 어떻게 하면 서비스에 잘 녹아들어 갈 수 있게 할까 고민이 많았다. 해결점은 외부가 아닌 내부에서 찾을 수 있었다.
여러 서비스를 둘러보던 중 문득 다른 서비스를 보는 게 의미 없다는 생각이 들었다. 이 서비스와 우리 서비스는 추구하는 방향이 다르다. "이걸 억지로 우리 서비스에 적용하는 게 맞을까?", "그러면 우리 서비스는 평소에 어떤 톤을 쓰고 있지?" 나는 앱을 다시 두루 훑어보며어떤 말투와 톤으로 전달하는지를 살펴봤다. 이거다. 나는 운영진이 쓴 글에서 네이밍의 힌트를 얻을 수 있었다. 그리고 그 네이밍을 썼을 때 레퍼런스를 참고했을 때보다 훨씬 자연스러웠고 우려되던 점도 사라졌다. 답을 모르겠거든 우리 서비스를 다시 돌아보는 것도 좋을 듯하다.
마지막 삽질은 커뮤니케이션이었다. 아무래도 재택근무하는 분들과 원격으로 일하다 보니 의사소통이 잘못 이뤄지는 경우가 있었다. 보통은 내가 텍스트를 다르게 해석해서 벌어지는 일이었다. 우선은 "이렇게 하면 이렇지 않을까요?"라는 질문에 성급하게 근거를 대려고 했다는 점이다. 사실 개발자나 디자이너는 이런 질문을 던지면서 나름의 해결책을 고민하고 있다. 고민하는 시간을 충분히 주지 않고 바로 답을 하다 보면 이게 맞니, 저게 맞니라는 식의 논쟁으로 변할 수 있다. 상대방이 충분히 해결책을 찾는 시간을 주자. 기다리다 보면 개발자와 디자이너가 오히려 더 좋은 방안을 제안할 수 있다.
또 다른 점은 서로 이해하는 용어가 달라서 벌어진 점이다. 이 부분은 어제 겪었던 일인데, 원래대로라면 yes, no로 끝날 일을 길게 길게 스레드를 생성하다 마지막에 '저는 이거에 대해 알고 싶었던 거였어요'라고 정리해줘서 다시 정정했었다. 텍스트로 소통하다 보니 같은 단어를 다른 뜻으로 받아들인 건지 알기 쉽지 않았다. 그래서 집에 돌아오면서 어떻게 하면 커뮤니케이션 비용을 줄일 수 있을까 고민했고 세 가지 체크리스트를 만들었다.
1. 내가 용어를 제대로 이해한 게 맞는지
2. 전에 합의한 내용과 달라진 부분인지
3. 어떤 현상만 들었다면 그 현상에 대해 무엇을 알고 싶은지
(이해가 안된다면 스크린샷이든 그림이든 보여달라 하자)
아직 실천은 안 했지만 다음 주에 한번 적용해보려고 한다. 커뮤니케이션 비용을 줄이는 것은 중요하다. 개발자는 개발하는 시간에, 디자이너는 디자인하는 시간에 더 많이 투자하도록 해야기 때문이다. 그 외 의사결정이 필요한 부분은 기획자가 잘 정리해서 선택하기 쉽게 하고, 여러 대안을 마련해 고민할 시간을 줄이게 해줘야 한다. 현재도 프로젝트가 진행 중이긴 하지만 하다 보면 또 다른 삽질이 있을 거다. 그때마다 문제가 뭘까 고민하고 해결책을 마련해봐야겠다. 이걸로 기획 삽질기는 끝!
