여기어때 3주년 회고
2022년 8월 나는 여기어때 리서처로 입사했다.
이전 회사에서는 기획자와 컨설턴트 사이 어딘가에서 반쪽짜리 리서처로 일해왔었다. 늘 리서치를 하긴 했지만 ‘나 리서처입니다.’라고 자신 있게 말하긴 어려웠다. 그래서 여기어때에서의 새로운 시작은 나에게 ‘리서처’라는 타이틀을 처음 갖고 일할 수 있는 자리였고, 동시에 ‘진짜 리서처가 될 수 있을까’라는 시험대이기도 했다.
입사 초기에는 긴장과 불안이 컸다. 오죽하면 회사에서 퇴사를 권유당하는 꿈을 꾸기도 했다. 그만큼 나는 확신이 없었다. 내가 하고 있는 리서치가 잘 되고 있는지, 이렇게 진행해도 되는 건지, 결과가 정말 쓸모 있는 것인지 계속해서 주변에 묻게 되고 자신감도 낮아졌다.
그러던 어느 날, 연말 평가 자리에서 토드는 내게 이렇게 말했다.
“ 소냐, 스스로의 쓸모를 증명하세요. 이제는 자기 PR 할 줄 알아야 해요. 내년엔 8층에 소냐를 모르는 사람이 없게 해 보는 건 어때요?”
그 한마디가 꽤 오래 머릿속을 맴돌았다.
"나는 어떤 리서처로 보이고 있을까?"
"이 조직 안에서 어떤 사람으로 기억되고 싶을까?"
"내 쓸모는 어디까지일까?"
그래서 나는 이 질문들에 답하기 위해 ‘실험’을 시작했다.
이 글은 내가 여기어때에서 리서처로서 어떤 실험을 해왔는지 소개하고 회고하고자 한다.
그 질문은 두 방향으로 흘러갔다.
‘나는 어떤 사람인가?’
‘나는 어떤 일을 하는 사람인가?’
일보다 사람이 먼저였다.
‘소냐’라는 사람이 어떤 사람인지부터 알려야, 그 뒤에 리서치도 설득력있게 들릴 거라 생각했다.
“소냐라는 사람이 있어요. 그 사람은요...” 조직 내에서 이 말이 먼저 돌 수 있다면, 이후의 모든 커뮤니케이션이 쉽고 부드러워질 거라 생각했다.
“ 8층에서 저를 모르는 사람이 없도록 할게요.”
2023년 프로덕트 신년회에서 모두의 앞에서 다짐을 말했다. 뭐든 말로 밖에 나오면, 하게 될 거라 생각했다.
그러나 나는 사회적 에너지가 낮은 INTP이다. (MBTI를 맹신하진 않지만, 사회성이 부족하고 내향적인 사람이다.) 나에게 자기 PR을 하라는 건, 광화문에서 버스킹을 하라는 소리와 같다. 티타임을 돌며 대화를 시도해야 하나? 내가 무작정 찾아가서 말을 걸면 되는 건가? 고민을 하던 찰나에 컬처팀 합류 제안을 받았다. 부담스러웠지만, 덥석 수락했다. 이유는 하나였다. 나를 알릴 수 있는 기회니까.
컬처팀에서 나는 동료들에게 따뜻한 인풋과 아웃풋을 주는 역할을 맡았다. 가장 기억에 남는 활동은 두 가지다.
1. 조직 내 생일 축하 메시지 작성
생일이 다가오는 동료들의 업무 태도와 성향을 관찰해 진심을 담은 축하 메시지를 써서 올핸즈 채널에 공유했다. “소냐 글은 항상 감동이에요”, “얼마나 신경 쓰고 있는지 느껴져요” 같은 피드백이 돌아왔다.
2. 칭찬 문화 만들기
서로 칭찬할 수 있는 '칭찬함'으로 동료 간 감사를 주고받는 문화를 만들었다. 감사와 존중이 자연스럽게 퍼질 수 있도록 유도했다. 이 프로젝트는 칭찬함에서 칭찬트리로, 지금은 '감쟈합니다' 로 계속 발전 중이다.
“소냐는 뭐 하는 사람이길래 글을 잘 써?” -> “ux 리서처래"
이 흐름이 만들어지니, 자연스레 ‘소냐’라는 사람에 대한 인상이 생겼고, 업무에서도 라포 형성까지의 시간이 짧아졌다. 처음 만나는 동료가 “생일 축하 메시지 기다리고 있었어요!”라고 말해줄 때, 낯섦은 한결 줄어들었다.
리서처란, 결국 사람을 이해하고 연결하는 사람이다. 컬처팀 활동은 리서치 이전에 ‘사람과 사람 사이의 거리’를 좁히는 훌륭한 실험이었다.
그 실험은 결국 대성공이었다.
나는 올해, 2025년 컬처팀 리드 제안을 받았다. 컬처팀 리드를 하게 되니, 인연이 거의 없었던 구성원들과 자연스럽게 친밀도가 생겼고, 그 덕분에 더 깊은 이야기들도 주고받을 수 있게 되었다. ‘온 우주가 돕는다’라고 했던가. 조금은 벅찬 일이지만 꽤 즐겁게 해내고 있다.
‘읽고 싶은 리서치 결과’는 어떻게 만들어지는가?
입사 초기, 리서치 결과를 정리해 공유했을 때 욘두가 내게 이렇게 물었다.
“이 문서, 당신이 아니라 다른 사람이 읽었을 때 이해가 갈까요?”
“리서치 과정을 모르는 사람도 읽고 싶고, 이해할 수 있을까요?”
"누구를 위해 쓴 리서치 결과인가요?
또 한 번은 전사적인 요청으로 ‘여기어때 왜 안 써요?’라는 리서치를 진행한 적이 있었다. 높은 단계에서 내려온 요청이었기 때문에 당연히 모두가 배경을 알고 있을 거라 생각했다. 하지만 디브리핑 중, 예상치 못한 질문이 나왔다.
“그래서 이걸 왜 한 거죠?”
“이 정도로 결론 내려도 되는 거예요?”
몹시 당황스러웠다.
하지만 동시에 명확히 깨달았다.
그 후로, 나는 문서의 목적과 대상을 항상 스스로 되묻기 시작했다.
이 문서를 '누가', '왜' 보게 될까?
읽는 사람이 누구인지에 따라 메시지 구조, 전달 방식, 시각 자료 모두 달라져야 한다는 것을 온몸으로 배웠다. ‘잘 전달되는’, ‘자꾸 읽어보고 싶은’, ‘유익한’ 결과임을 어필하는 것 또한 리서처가 해야 하는 설계의 일부다.
리서치 배경이 모두에게 공감될 수 있어야 의심받지 않는 리서치가 될 수 있다.
이미 다른 조직의 많은 리서처들이 하고 있는 일이지만, 제일 효과가 좋았던 전달 방법은 이렇다. :
1. 스토리텔링을 곁들여 리서치 결과를 기승전결로 전달하기
2. 결과를 위한 보조자료로 멈춰있는 사진도 좋지만, 직접 화면을 구현하면서 보여주기
3. 약간의 연기 : 유저 보이스를 직접 결과 맥락에 맞게 넣고, 보이스를 읽어주기
4. 유저의 보이스와 행동이 담긴 클립을 첨부해 몰입도를 높이기
타이틀은 영향력 넓혀보기지만, 결국 조직 내 리서치 성숙도를 끌어올리기 위한 실험이었다.
작년까지 여기어때 리서처는 선행 리서치보다는, PO나 디자이너가 필요성을 느끼는 시점에 요청이 들어와 대응하는 경우가 많았다. 회사 전체의 로드맵은 알고 있지만, 리서처가 인입되기를 기다리는 구조.
당연히 리서처가 프로젝트 챔피언이 될 수 없는 구조였고, 프로젝트를 성공적으로 마무리했을 때 리서처의 공로는 매우 희석되어 있었다.
1년 반 정도 지났을 때는 이 일을 하는 것에 대해 약간의 무기력함과 권태 그 사이의 알 수 없는 감정도 느꼈다. (나는 이걸 매너리즘이라고 한다)
여기어때는 이미 입사 때부터 리서치 성숙도가 꽤 높은 회사였다. 그럼에도 불구하고 매너리즘을 느낀다는 건 챌린지가 필요하다는 의미다. 그래서 RO시스템 도입을 실험 해봤다.
RO 시스템은 ‘왜 리서처는 프로젝트 챔피언이 될 수 없을까?’라는 질문에서 출발했다.
올해 초 도메인 기반 오너 체계(Research Owner)를 제안했다. 동일 도메인을 꾸준히 맡으며 연속성과 깊이를 가져갈 수 있었고, PO와 디자이너 입장에서도 “이 리서치는 누구에게 물어봐야 하는지”가 명확해질 수 있다.
이미 작년에 국내 숙소 / 해외 숙소 / 파트너와 같이 큰 비즈니스별로 도메인을 나눠 업무를 해봤다. 큰 단위로 도메인 담당자를 맡다 보니 각각 도메인별로 리서처에 종속되는 문제가 심화됐고, 나중에는 리서처들 간 정보 불균형도 생겼다.
RO 시스템은 작은 프로젝트 단위로 도메인을 세분화해 각 리서처가 오너십을 갖고 연속적으로 리서치를 수행할 수 있도록 하며, 지식이 특정 도메인에만 편중되는 문제를 완화해 다양한 분야를 폭넓게 경험할 수 있게 개선한 시스템이다.
장점은 다음과 같다.
맥락 유지: 중복된 실수나 재조사를 줄임
일관된 방향성: 설계부터 결과까지 톤이 안정적
선제적 제안: 리서처가 먼저 문제를 정의하고 프러젝트를 리드
이 방식은 리서처의 영향력을 배로 키울 수 있게 된다. RO가 프로젝트의 ‘챔피언’으로서 주도권을 가지고 성과를 이끄는 동시에, 진행 과정에서 얻은 지식과 인사이트를 공유해 선제적으로 아이템을 발굴하고 프로젝트 방향을 제안할 수 있게 한다.
단점을 보완하기 위해서는 아래와 같은 방법을 꾸준히 해볼 예정이다.
가벼운 디브리핑 확산 : 오너가 주기적으로 결과를 공유해 팀 내 집단 지식 확장
Cross-domain 러닝 시스템 : 다른 도메인의 리서처도 핵심 맥락과 인사이트를 빠르게 습득할 수 있어, 긴급 시 대체 투입 가능.
이 방식은 오너가 문서화와 공유 세션을 통해 후속 인력·백업 인력을 자연스럽게 키워 업무 병목이 해소된다.
아직 RO 체계는 구체화해야 할 것들이 많다. 하지만 지금까지는 생각보다 잘 운영되고 있는 것 같다.
실제로 RO 도입 이후 선행 리서치 결과를 가지고 디자인 스프린트도 리드했으며 백로그에 쌓여있던 고민을 선행 리서치로 시동 걸어보기도 했다.
(구체적인 이야기는 회사 기술 블로그에서 작성될 예정이다.)
과거엔 디브리핑 전 떨며 스크립트를 외우고, 자기 확신 없이 혼자 끙끙대며 고민하다 정답을 찾아야 한다는 압박에 시달렸다.
지금은 나름의 능청스러움으로 인사이트를 전달하고, 청자의 맥락을 읽고 메시지를 설계하고, 동료의 관점을 유연하게 수용하며, 먼저 흐름을 읽고 리서치를 제안하는 사람이 되었다. 그리고, 조직 안에서 리서치를 어떻게 리드할 수 있는지를 고민하고 그 구조를 만들어가는 사람이 되었다.
하지만 아직은 개발자들과의 연결고리가 약하다.
이제 나는 ‘리서치의 범위를 코드까지 연결하는 실험’을 시작해보려 한다. 왜 이 인사이트가 나왔고, 이 해결책이 어떤 근거에서 파생되었는지 개발자도 궁금해 할 수 있도록 리서치를 설명하고, 공유하려고 한다. 이 첫걸음에 스프린트 진행이 큰 도움이 됐으리라 믿는다.
리서처의 강한 영향력은 질문을 설계하고, 공감을 설득하고, 흐름을 만들어내는 힘에서 나온다.
나는 이 조직 안에서, 나만의 방식으로 영향력을 실험해 온 사람이다.
그리고 앞으로도, 그렇게 천천히 그러나 분명하게 나를 가지고 후속 실험을 이어가고자 한다.