정치.
중간 보고. 거기에 보통 들어가는 것들이 퍼소나, 고객 여정, 그리고 UX 컨셉. 디자인 색이 강할 경우 룩앤필, 무드보드, 톤앤매너 같이 컨셉이라는 단어에 따라오는 또다른 유사 개념들도 있다.
아무래도 스타트업 종사자 분들에겐 컨셉이란 조금 낯선 개념일 것 같기도 하다. 정확히 말하면 낯설진 않아도 '굳이?'라는 생각을 하실 것 같기도 하다. 프로덕트 디자이너, 프론트엔드나 백엔드 개발자 분들은 아마 관심도 없어하실 것이다. 그리고 프로덕트 매니저라고 해도 많은 사람들이 사실 이런 추상적인 방향성보다는 구체적인 GA 데이터나 VOC가 중요하다고 생각하실 것 같다. 컨셉이라니 뭔가 겉만 번지르르한 실속 없는 소리처럼 들린다. 나도 어느 정도는 동의하긴 한다.
필요하긴 하다. 이상적인 컨셉이란 높은 하늘을 가로지르는 매우 좁고 뾰족한 구름다리와도 같다. 모든 사람들이 질서 있게 한 줄로 걸으며 단 한 가지의 목적지를 향해 망설임 없이 나아갈 수 있게 해주는 장치. 인하우스식으로 말하자면 제품의 장기 로드맵이다. 단순히 소통을 도와줄 뿐만이 아니라 팀이 자동으로 다음 단계로 발을 내딛을 수 있도록 만든다. 혹은 어디로 가야할지 고민이 될 때 언제라도 초심 찾으러 돌아올 수 있는 마음의 고향이라고 생각하는 것도 괜찮을 것 같다.
필요하지만, 우리처럼 프로덕트의 소유권을 가지고 있지 않은 외부자들에게 컨셉이란 결국 본질적으로 '어떻게 보여주는가'의 문제이지, 알맹이의 변화가 있는 건 아니다. 우리는 구름다리를 직접 만든다기보다는 구름다리가 예쁘게 지어져있는 AR 설계도 영상의 여러 가지 버전을 보여드린다. 그리고 그 구름다리가 정말 건설될 지는 아무도 모른다.
우리가 짓는 것도 아닌데 왜 굳이 열심히 해야 돼? 이게 실제로 제품에 기여한다는 보장이 있어? 우리가 구름다리에 개입할 수 있는 것도 아닌데 이 뇌피셜 가지고 끙끙거리는 과정이 대체 무슨 의미가 있어?
컨셉을 잡는 과정을 불필요하게 길게 끌고 갈수록 무익하게 시간을 소모하게 될 가능성이 크다. 사소한 관점 차이와 확정되지 않은 미래 리스크가 컨셉과 결과물의 수준(fidelity)을 좌우하는 것이 에이전시에선 비일비재하다. 아마도 이것들이야말로 훗날 내가 우리 회사를 나가 다시 새로운 길을 떠날 사유가 될 것이다. 다만 그게 지금은 아니다.
필요하긴 하다. 이런 '보여주기' 실력은.
당신에게도 많이 배웠다. 의심의 여지 없이.
G 팀장님이 오랜만에 우리 1팀 세 명을 회의실에 불러서 R&R을 정하기 시작했다. 팀장이 우릴 갑작스럽게 불렀다는 건, 프로젝트 진행에 무언가 이슈사항이 생겼다는 뜻과 마찬가지다.
G: 지금 일정이 좀 빠듯해서요. 한번 역할 분담을 정리하고 가죠.
G 팀장님은 화이트보드에 표를 그려서, 업무를 나열해가며 우리 셋이 하고 있는 작업에 따라 우리 이름을 배치하기 시작했다.
아이데이션: All (진행중)
Raw Data 추출: All (완료)
와이어프레임: B, C (진행중)
IDI 분석: A (진행중)
중간보고서: - (진행 예정)
G: 지금 C씨랑 B씨가 와이어프레임 작업을 하고 있죠? A씨는 IDI 보고서 작업중이고.
G: 요 이후로 저희가 중간보고서를 써야 하거든요. (C의 이름을 적는다)
중간보고서: C (진행 예정)
C: 아, 벌써요? 할 일이 많네요.. 와이어프레임도 아직 완성되려면 멀었는데.
G: 조금 빠듯해도 좀만 버팁시다. 아이데이션은 일단 여기서 마무리지을게요. 중간보고서는 C씨가 책임지고 업무 분배해서 진행해주세요. 그리고... (B를 쳐다본다)
G: B씨는 지금 운영 쪽에 이슈가 좀 많이 들어왔거든요. 그래서 그거를 좀 해야 할 것 같고...
B: 아...
B는 예상은 이미 하고 있었던 듯했지만, 다시 운영 업무로 돌아가야 해서 매우 아쉬워보이는 얼굴이었다. 그리고 C는 같이 작업을 하던 B가 작업에서 빠지게 되자, 조금 언짢은 얼굴로 팀장님께 말을 꺼냈다.
C: 거기 이슈가 또 들어왔대요? 혹시 다른 팀에서 지원은 없을까요? 저 혼자 다 진행하는 건 무리인데. UT 설계도 곧 해야 되잖아요? 지금 할 거 투성인데.
G: 그렇죠. 그것도 고민인데... 운영 이슈가 좀 많아가지고 2팀도 그걸 쳐내야 하는 상황이라. 일단 일정이 급하니 진행을 좀 해보고, 만약 도저히 안되겠다. 너무 빠듯하면 저한테 말해주세요.
B: 그 다른 팀... 디자인 팀이나 영상 쪽에서 도와주실 순 없을까요...?
G: 저도 그게 효율적이라 생각하긴 한데... 그게 문제가 좀 있어서.
팀장님은 대표님 때문에 어쩔 수 없다며 말을 아꼈다. 이건 예전부터 우리 회사에 있었던 문제였다. 업무 불균형. 왜냐하면 명백하게 우리 기획팀과 다른 팀들의 업무량이 차이가 났으니까. 그리고 기획팀 중에서도 1팀과 2팀의 업무량에도 차이가 꽤 많이 났다. 유독 우리 팀, 1팀이 야근을 하는 날이 많았다. 그리고 내가 봐도 우리 팀이 가장 많고 스케일이 큰 업무를 하고 있었다. B와 C는 할 말이 많아 보였지만, 일단은 당장 들어온 일이 급해서 입을 다물었다.
중간 보고서. 우리가 IDI를 하고 아이데이션을 하고 이걸 기반으로 와이어프레임을 완성하기 전에, 이 와이어프레임과 우리의 프로젝트의 존재의미 자체를 좌우하는 그 물건이다. 드디어 우리 프로젝트의 방향성이 '정당한지' 총체적인 설득을 공개적으로 해야 할 날이 왔다.
일반적인 중간 보고서와는 조금 성격이 다르다. 왜냐하면 우리가 하는 프로젝트가 선행연구 프로젝트이기 때문이다. 아직 세상에 존재하지 않는 서비스의 존재의의를 설명해야 한다. 그래서 좀 더... 스토리텔링이 필요한 보고서다. 우리와 클라이언트의 방향성을 (만나뵌 적도 없는) 윗선에 설득하기 위해서.
에이전시는 프로덕트와 프로젝트의 방향성을 판단하고 결정하는 조직이 아니다. 그 반대다. 탐색하는 조직이다. 일단 클라이언트가 방향성이 안 잡혀 있어 "우엥 정해주세요"하는 경우도 많았다. 나는 그걸 보고 순간적으로 '와우 대기업 아무나 들어가네'라는 깜찍한 생각을 했던 적도 있었다.
에이전시의 경우, 프로젝트를 기획하고 방향성을 잡는 건 보통 클라이언트의 역할이다. 에이전시는 그 방향성대로 가게끔 하는 실무자들이다. 머리는 클라이언트, 손은 에이전시라고 비유하면 아주 정확하지는 않겠지만 대충은 이해가 가실 것 같다.
다만, 클라이언트가 항상 방향성을 하나하나 확실히 잡고 오는 경우는... 없다. 확실하게 없다. 보통은 아이디어 시드와 현황, 리스크, 그리고 아웃풋의 형태(*단, 얼마든지 변경될 수 있음) 정도 들고 오는 경우가 태반이다. 애초에 처음부터 방향성을 확실하게 잡는 건 불가능하다. 현실에서의 프로젝트들은 가을 바람을 맞는 갈대들마냥 흔들리고 지랄이 나기 마련이니까.
그렇기 때문에 에이전시는 세컨드 기획자로서, 클라이언트 대신 생각해주는 역할을 맡는다. 우리는 클라이언트의 챗gpt이자 깃허브다. 쬐끔 서버 부하가 많이 걸리는 AI 툴.
수많은 정책과 경영진의 압박에 시달려 시야가 좁아져서 갈피를 못 잡고 갈대가 되어버린 클라이언트 대신에, 그들보다는 개방적이고 틀에 사로잡히지 않는 우리들이 나서서, 그들의 입장이 되어서 이 프로젝트가 나아가야 할 방향을 탐색하고, 자료를 조사하고, 근거를 만들어서, 친절하게 클라이언트의 머릿속에 던져주어야 한다. 그냥 던지면 못 알아듣는다. 우리는 UX를 하는 사람들이니까. 언제나 친절하고 산뜻하게, 사용성 좋게 의견을 던져주자.
그렇기 때문에 아이디어, 컨셉, 의도, 방향성이라는 단어가 상당히 많이 회의에서 언급되는 편이다. 질릴 만큼 나온다. 우리 모두가 사랑하는 더블 다이아몬드 프로세스에 의하면, 발견-정의-개발-전달 4단계 중 정의 단계에 해당할 것이다. 보통 데스크 리서치와 유저 리서치를 전부 마치고, 거기서 나온 인사이트들을 한가운데 모아서 아이디어를 뽑아내고, 그 아이디어들 중 개발 단계에 들어갈 만한 가치 있는 아이디어들을 뽑아, 그걸 기준으로 삼아 방향성을 정리한다. 여기서 나오는 방향성을 우리는 컨셉이라고 말한다. 그러니 우리는 지금 아이디어를 일단 뽑는 데까진 완료했고, 이걸 정리하는 것이 중간보고서/컨셉보고서라는 의미이다.
컨셉을 모든 UX 프로젝트에서 매번 정하지는 않는다. 사실 컨셉은 그렇게 거창한 것이 아니다. 컨셉이란 어휘는 프로젝트마다 의미와 정의가 상당히 가변적이다. 일반적인 프로젝트의 경우 보통은 '유저 리서치에서 이런 결과가 나왔으니, 이 결과에 맞게 이 pain point를 고칩시다' 가 컨셉이 된다. 유저 데이터라는 근거가 명확하니, 컨셉 도출 단계가 크게 발목 잡히지 않는다.
문제는 선행연구 프로젝트다. 없는 것을 만들어내야 할 때. 유저 데이터에서 은유적으로 보이는 것을 발견해서 의미를 붙이고 스토리를 만들어서 '이게 아마도 미래에 봤을 때 이런 가치를 만들어낼 겁니다 아마도요!'를 타인에게 설득해야 할 때... 컨셉 도출 단계는 노답이 된다. 왜냐하면 진짜 답이 없기 때문이다.
앞으로 우리가 만들어야 할 중간 보고서는 이 컨셉을 하나의 스토리, 즉 설득력 있는 내러티브로 만드는 작업이다. 그렇게 보시면 된다.
G 팀장님의 업무 분배가 끝나고, C와 B, 그리고 나 실무자 세 명이 한 자리에 모여 현황 보고와 중간 보고서에 대한 이야기를 꺼냈다.
C: 갈수록 일이 많아지네. 이게 와이어프레임이랑 Flow랑 동시에 하려니까 힘들어요. B씨는 이제 또 그거 하러 가야 되잖아요? 그럼 나 혼자 해야 되네. 보고서는 또 언제 해?
B: 전 사실 슬슬 팀장님이 다른 팀에 업무 배분을 좀 해줄 줄 알았어요. 대표님한테 말을 해보던가, 본인이 해줄 것도 아니고.
C: 맞아. 솔직히 왜 이렇게 질질 끄는지 이해가 안돼요. 우리만 일을 다 하는 건 불공평하잖아요. 저기 그래픽 디자인 쪽은 뭔 일을 하는 지도 잘 모르겠고.
B: 거기는 이제 프로젝트가 끊겨가지고, 다들 퇴사 예정이실 거예요. 그럼 그냥 그 쪽을 우리 부서에 데려오면 해결되는 거 아닌가?
C: 그러게요. 예전부터 얘기 나왔다면서요? 팀 구조 바꿔야 된다고.
B: 팀장님이 대표님한테 말은 해보겠다 하셨는데...
C: 거짓말 아냐?
B: 대표님은 운영은 아예 잘 모르세요. 이번에 F 님도 퇴사하시는데... 왜 퇴사하시는지도 이해를 잘 못하더라고요.
C: 아니 그럼 당연히 퇴사하지, 이런 회사를!
F가 퇴사한다는 얘기는 전에 나도 스치듯 들었다. 그때는 나와는 아무 접점도 없었던 사람이라서 크게 신경 쓰지 않았다. 근데 전에 내가 홀로 앉아있던 아이데이션 작업실에 F가 찾아왔던 게 떠올라서 기분이 되게 묘해졌다.
나랑 가까워지고 싶었던 걸까? 퇴사하기 전인데 왜 굳이? F한테 말을 건넸어야 했나? 난 F가 나보다 되게 선임이라 생각해서 말을 붙일 생각도 하지 못했다. 그쪽에서 나한테 말을 건네왔다면 모를까...
난 F가 왜 퇴사하는지, 무슨 역할을 하고 있었는지도 아는 게 잘 없다. B와 동시에 운영 관리자라는 것밖에.
여담으로 이 운영 업무는 정확히 말하면 QA에 가깝다. 우리 회사는 별도의 서비스를 개발하고 있진 않으니까. 클라이언트의 프로덕트 화면 설계에 오류가 없는지 같이 봐주는 것이 일이었다. 검수. 컴포넌트 수정. 오타 수정. 그런 것들.
어쩌면 F도 B와 비슷한 입장이었을까? B는 그런 QA 업무에만 할당되는 것에 내심 불만을 많이 갖고 있었고 항상 현장 프로젝트를 하고 싶어했다. 그러나 그 의사를 적극적으로 표현하지는 못했다. 하지만 내가 입사한 해에 처음으로 B는 1팀에 포함되어 셋이서 프로젝트를 진행하게 되고, C가 B를 적극적으로 도와주고 응원해주면서 요즘 자신감이 붙은 듯 보였다. 내 생각에 B가 프로젝트를 맡게 된 이유에는 C가 B 대신 적극적으로 B를 어필해줬던 것도 있었던 것 같았다.
F한텐 그런 구원자가 없었다. QA 담당자로 할당된 만큼 프로젝트에 참여할 시간은 당연스레 줄어들고, 프로젝트에 배정되는 인력에서도 우선순위에서 밀렸다. F는 실무자 중 가장 경력이 많은 C를 제외하고 그다음으로 우리 회사에서 경력과 나이가 가장 많은 편에 속했다. 그 말은 더이상 성장 인력도 아니라는 뜻이다.
왜 내가 있는 곳에 들어왔을까.
C: 어떡해. 저 F씨랑은 친해지지도 못했는데...ㅠ 우리 송별회라도 해야 하는 거 아닌가요?
B: 송별회할 시간이 있을지 모르겠네요... 바빠가지구...
C: 그니까! 이게 다 팀장님 때문이야.
나는 화제를 돌렸다.
나: 그 중간 보고서는 뭔가요? 제가 쓰는 IDI 보고서랑 좀 다른가요?
C: 많이 다르죠~ 되게 중요한 거기도 하고요.
나: 중요한 거?
C: 해볼래요?
근데 그 중요한 걸 왜 내가 하냐?
난 심지어 저 당시에 아직 수습 기간이라 정규직도 아니었다.
나: 정확히 어떤 건가요? 제가 그거 할 짬밥이 되는지 잘 모르겠네요.
C: 짬밥이라뇨, 그런 거 없어요. 할 수 있는 사람이 하는 거죠.
C: A씨는 우리 회사가 첫 회사라고 했죠? 이게 대기업에서는 이렇게 중간에 보고하는 절차가 있는데, 이거는 윗분들이 보는 거라서 분량도 길면 안돼요. 한 15장 이내? IDI 보고서 같은 건 수십장이잖아요? 이거는 디자인도 되게 중요해요.
C: A씨는 사실 아이디어 내는 것도 그렇고, 글도 잘 쓰시는 거 보면 잘하실 것 같긴 해요. 창의력이 좀 필요한 거라.
난 잠깐 머리를 굴렸다.
나: 제가 해볼까요?
C: 어? 그래줄래요?
정말로 중요하다면, 그걸 나 혼자서 한다면... 좋겠지. 혼자서 하는 만큼... 오롯이 나를 향해서 평가가 돌아올 게 아닌가. C에게 거쳐서 들어오는 게 아니라.
주도권이 생기는 거고. 영향력이 생기는 거고.
내가 그런 걸 좋아한단 걸 눈치 빠른 C도 분명히 알고 있었을 거고. 그래서 '권유'를 해준 걸 거고.
정말로 중요하다면, 책임의 의무도 생길 거고.
위험할 거고.
나: 어차피 와이어프레임이 훨씬 중요한 거니까 보고서는 차라리 제가 쳐내는 게 낫지 않나요?
C: 어 아니에요. 와이어프레임이 훨씬 중요한 건 아니고. 둘 다 중요하죠.
나: 전 상관없어요. IDI 보고서도 거의 다 했고. 제가 해도 되는 거면 괜찮아요.
C: 고마워요!
욕심.
나는 스스로 뛰어드는 불나방이다.
IDI 보고서 같은 단순한 유저 리서치 보고서는 기록물이며, 실무진이 참고하는 용도다. 그러나 중간보고서의 목적은 '이 프로젝트가 기존 계획대로 잘 흘러가고 있나요?'를 증명하는 것이다. 참고와 증명의 차이는 매우 크다. 잘 이해가 안되신다면 다음 질문에 대한 대답을 보고서로, 프로스럽게 만들어본다고 생각해보자.
이 프로젝트의 의미와 가치는 무엇인가요?
를 스스로에게 물어보자. 이게 얼마나 대답하기 어려운 질문인지.
Raw Data가 정확하게 들어가 있으면 되면 상관없는 유저 리서치 보고서와 다르게, 이 중간보고서는 상부에게 '우리 잘 되고 있어요'라고 설득할 수 있게끔 철저하게 요리가 되어서 만들어져야 한다. 그러니까 데이터의 정확도는 당연하고, 형식의 일관성, 디자인의 심미성, 분량 조절, 오타 없는지, 우리 프로젝트의 정체는 뭐고 목표는 이렇고 내러티브는 이렇고 전부 이해가 잘 되는지... 기타 등등 단어 하나하나 전부 신경을 써야 한다는 것이다.
엄청나게 부담스럽고, 귀찮다. 데이터 정리가 개빡센 일반 보고서를 쓰는 것과는 아예 다른 종류의 귀찮음이다. '3분 안에 대강 훑어봐도 이해가 되냐?' '어디 삐꾸난 데는 없냐?' '디자인이 보기 좋냐?' 이런 것들이 중간 보고서에서는 중요하다. 디자이너와 협업까지 해야 한다. 간격, 단어, 맥락 하나하나 평소에는 전혀 신경을 안 쓰는 부분에도 신경을 써야 해서 머리가 아프다. 막말로 유저 리서치 보고서 쓰는 게 훨씬 쉽다. 진짜루.
에이전시는 인하우스와 다르다. 클라이언트가 대기업이라면 더욱 달라진다. 필연적으로 을의 입장이다.
대기업에서 진행하는 프로젝트들은 필연적으로 큰 돈이 오고가는 만큼 의사결정 라인이 매우 단단하고 수직적이고 빼곡하다. 같은 자료 가지고 보고만 몇번을 하는지 모르겠다. 빠르고 부담 없이 애자일하게 마구 진행되고 마구 반복하는 스타트업이랑은 프로젝트 구조 자체가 완전히 다르다.
만약 보고서 품질에 문제가 생기거나 하면.. 그 책임을 지는 건 우리가 될 가능성이 높다. 어차피 우리가 구름다리를 짓는 것도 아닌데 무슨 책임을 지냐고? 막말로 에이전시라는 조직은 애초에 클라이언트의 책임을 덜어드리기 위해 존재하는 셈이다~
친절하고 다정한 클라이언트는 "아 전부 마음대로 해주세요~ 막 바꾸셔도 돼요! 다들 전문가 분이시니까~"
라며 우리에게 산출물을 완전히 맡기고, 문제가 생기면 얼굴을 바꿔 돌변하여 "저희는 기획 의도를 분명히 말씀드렸는데 이상하네요." 라며 우리에게 책임을 전가한다. 클라이언트가 우리를 자유롭게 해주는만큼, 클라이언트는 산출물의 퀄리티 이슈에서 자유로워질 수 있고, 도망갈 수 있다.
그래서... 완전히 다 풀어주고 떠맡기는 클라이언트보다, 좀 성질 더러워도 까탈스럽게 하나하나 다 피드백 해주는 클라이언트가 더 낫다. 그래야 리스크를 사전에 방지할 수 있고, 죽어도 같이 죽을 수 있으니까...
C는 그걸 알고 안 쓰려고 한 걸 거다. 귀찮은데, 어렵고, 리스크가 크기까지 하니까.
그렇다고 이걸 쓴다고 우리한테 큰 도움이 되냐? 글쎄. 우리 입장에서는 귀찮을 뿐이다. 이거 잘한다고 돈 더 받나? 그것도 아니고.
C는 개입하지 않음으로써 편해질 수 있다. 잘되면 뭐 좋은 거고, 별로면 도망갈 수 있다.
C는 내게 권유했고, 그 권유를 나는 받아들였다. 그건 절대 강요가 아니었고, 내 호승심이었다. C는 강요는 절대 하지 않았다.
하지만 난 마냥 혼자서 책임을 다 떠안을 생각은 없었다. 나는 결과가 잘나올 거란 확신이 전혀 없었다. 당연히. 나는 또 '내 실력이 올라갈 거니까 괜찮다'고 합리화할 생각이 없었다.
한번 시험해볼까...
애초에 신입 혼자서 다 책임질 만한 작업이 아니잖아? 이건 내가 '해준' 거지, 내가 반드시 해야 하는 게 아니고. 원래 이걸 책임져야 할 사람은 누구인가?
C는 자진해서 포기한 셈이고, 그럼 G는 어떨까?
그래서 내 상사 둘 중 누가 더 책임감이 있는지 한번 보자고.
가끔 그런 생각을 한다. 나한텐 두 가지 선택지가 있었다.
그때 내가 화제를 돌렸을 때.
F의 얘기로 돌렸어야 했을까?
아마도 난 그때 눈이 멀었던 걸지도 모른다. 내 개인적인 욕심에.
후회는 하지 않는다. 유감스럽게도.