Product Engineer가 되어보자 - PEC 6기 후기(1)

PEC에 참가하게 된 계기

AI가 믿을 수 없을 정도로 나날이 발전을 거듭하고 있다. 이제 업무에 AI를 활용하지 않으면 바보일 정도가 된 것 같다. 나 또한 LLM을 정말 많이 활용하면서 느낀 것은 설계 능력이 없는 대부분의 신입 혹은 주니어 개발자들은 분명히 LLM에 의해 대체될 수 있고 실제로 시장에 반영되고 있다는 것이다. 나 역시 여전히 LLM에 의해 대체되기 쉬운 주니어 개발자를 벗어나지는 못했다는 생각이 들어서 대체되지 않을 차별점을 가져야 살아남을 수 있겠다고 생각했다.

그렇다면 나는 어떤 차별점을 가질 수 있을까? 개발 실력으로 차별점을 갖기엔 나의 역량이 너무 부족하기도 하고, 이미 그렇게 해서 들어갈 수 있는 자리는 포화상태인 것 같아 다른 차별점을 가져야겠다고 생각했다. 그러다 우연찮게 헤드헌터를 통해 레브잇의 Problem Solver라는 직무를 처음으로 접하게 됐다.

Problem Solver? 이건 도대체 뭘까 하고 봤는데 조사, 기획, 디자인, 개발, 운영 모든 책임을 지는 직무였다. 이걸 보자마자 '아 이걸 나의 차별점으로 가져갈 수 있겠다'라는 생각에 큰 관심을 갖고 스터디에서 Problem Solver를 주제로 발표까지 하는 등 개발 역량만으로 승부보는 것이 아니라, 개발이라는 틀에서 벗어나, 문제 자체를 이해하고 해결하는 것에 집중하는 능력을 길러야겠다는 생각이 점차 자리잡았다.

면접은 개인사정으로 포기했지만, Problem Solver가 되고자 하는 생각은 사라지지 않았고, 몇개월 후 양질의 프론트엔드 영상을 올려주셔서 자주 보던 유튜브 Boaz 채널 커뮤니티에서 Product Engineer Camp 참가자 모집글을 보게 되었다.

Product Engineer가 뭘까?

프로덕트가 생성되는 과정을 단순화하면 아래의 3단계로 나눌 수 있을 것 같다.
1. 사용자가 겪는 문제를 발견하고 정의한다.
2. 발견한 문제를 해결해주기 위한 서비스 기획안을 작성한다.
3. 기획안에 맞도록 개발을 진행한다.

원래 우리 개발자들의 책임은 보통 3번에 그친다.
하지만 Product Engineer는 여기서 더 나아가서 1번과 2번도 포함하는 넓은 책임을 가진 직군이다.

그러면 멀쩡히 3번 책임을 잘 수행하던 개발자는 왜 Product Engineer가 되어야할까?

3번의 책임으로는 크게 구현 / 설계가 있는데, AI의 급격한 발전으로 인해 구현의 책임은 빠르게 줄어들고 있다. 그렇게 줄어든 만큼의 책임을 다른 부분이 채워야하기 때문에 설계 역량이 중요해지게 된다. 그리고 그 설계를 잘하기 위해서는 기획을 잘 해야한다. 그리고 그 기획을 잘 하기 위해서는 유저의 눈높이에 맞춘 문제 정의를 잘 해야한다는 것이다.

그렇기 때문에 결국 시장에서 살아남기 위해서는 개발자의 책임은 1,2,3단계 전체로 확장될 수 밖에 없는 것 같다. PEC는 이 1,2,3단계를 모두 직접 경험하며 Product Engineer가 되기 위한 역량을 기를 수 있는 캠프로, 기획이 50%, 개발이 50%라는 설명을 듣게 되었다.

항상 사회 문제를 해결하기 위한 개인 프로젝트를 만들고 싶었지만, 늘 기획 단계에서 무너져서 번번히 포기했던 나는 이 캠프에 관심이 갈 수 밖에 없었다. 그래서 줌 미팅으로 여러가지 질문을 드리고 설명을 받은 끝에 참가를 결정하게 되었다.

1주차. 문제 정의

문제를 발견하고, 잘 정의하기 위해서는 공감이 가장 중요하다는 것을 배웠다. 공감을 하기 위해서는 사용자의 눈높이에 맞추어야한다!

Simon Sinek의 Golden Circle

대부분의 사람들은 서비스를 계획할 때, 무엇(What)을 만들어야할까? 에 집중한다.

그러나 이렇게 되면 무엇을 만들까? -> 어떻게 만들까? -> 근데.. 왜 만들어야하지? 이렇게 이어지며 가장 중요한 Why가 이전 단계에서 설정된 What과 How에 영향을 받게 된다. 그러면 행동을 먼저하고 그 행동을 합리화하기 위한 그럴듯한 이유를 찾아 나중에 갖다붙히는 꼴이 되어버린다. 이렇게 제품이 만들어지게되면, 결국 Why는 실제 유저의 문제가 있는 곳을 정확하게 타겟팅하지 못하게 된다. 이것은 마치 눈을 감고 사격을 했는데, 그곳에 우연히 타겟이 있길 바라는 것에 지나지 않을 것이다.

그래서 우리는 What이 아닌 Why에 집중해야한다. How와 What은 Why로부터 도출된 결과여야하지, 그 반대가 되면 안된다. 문제를 제대로 정의하여 Why를 명확히 하는 것은 사격에서 목표물의 위치를 파악하고 제대로 조준하는 과정이라고 볼 수 있겠다.

우리가 해결하려고한 문제

Why
양적이 아닌 질적으로 우수한 인간관계 형성을 돕기 위해
How
사용자가 다른 사람에게 자신을 더 쉽고 효과적으로 드러내도록 도와줄
What
개인별 맞춤 프로필 서비스를 개발할 것입니다!

그래서 우리는 친목 활동에서 서로를 소개하는데 도움을 줄 수 있는 프로필 서비스를 만들기로 했다.

사용자 인터뷰

1주차에 가장 어려운 과제인 사용자 인터뷰가 주어진다. 3 ~ 5명을 인터뷰하기 위해 인터뷰 질문지를 PEC 팀원들이 각자 작성해오고 그걸 하나로 뭉쳐서 다시 각자 인터뷰를 진행했다. 인터뷰가 생각보다 정말 어려웠다. 주어진 질문대로만 물어보면 인터뷰이가 답을 하기 어려워하는 경우도 잦았으며, 내가 예상했던 반응에서 크게 벗어나는 경우도 꽤 있었기 때문이다. 그래서 정해진 질문에 제한되지 않고 질문을 조금 바꾸거나 꼬리질문을 통해서 사용자가 겪는 문제를 어떻게든 잘 캐내야 한다는 것을 몸소 체험할 수 있었다.

그리고 인터뷰 전에 절대로 '답정너'가 되면 안된다고 신신당부 하셨었는데, 답정너에서 벗어나기가 정말 어려웠다. 질문지를 작성하면서, 또 실제로 인터뷰를 진행하면서도 계속 '사용자는 아마 이런 불편을 겪을 것이다, 이렇게 하면 잘 이용할 것이다' 하는 생각이 무의식 중에 자꾸 찾아들어서 사용자가 특정 방향으로 답변할 확률이 높도록 슬그머니 밀어버린 것 같았다.

비록 인터뷰를 통한 문제 발견 과정은 지나갔지만, 그래도 인터뷰에서 두가지 큰 교훈을 얻었다.

1. 어떤 것도 예측하려 하지 말고, 완전히 열린 마음으로 진행할 것. 모든 정답은 사용자에게 있다!
2. 사용자는 자기 스스로 문제가 뭔지 모른다는 점이다.

두가지가 상반된다고 느껴질 수 있지만, 사실은 그렇지 않다. 이것은 마치 병은 환자에게 존재하지만, 환자는 본인이 걸린 병이 무엇인지 모르고, 의사는 환자에게 증상을 묻고 검사를 진행해서 병이 무엇인지 알아내는 과정과 매우 흡사하다는 생각이 들었다.

인터뷰어도 이런 의사의 마음가짐으로, 모든 가능성을 열어두고 수단과 방법을 가리지 않고 인터뷰이로부터 문제를 Mining 해내어야 하는 것임을 깨달을 수 있었다.

그렇게 각자 진행한 인터뷰 내용을 모아 공통되는 부분을 중심으로 추상화하여 페르소나를 만들었다.

2주차. Information Flow

문제 정의, 인터뷰는 마인드맵처럼 여러가지 데이터를 수집하는 발산의 단계였다. 그리고 이렇게 수집한 데이터를 통해 Persona와 Information Flow를 작성하는 것은 발산한 데이터를 추상화하여 '정보'로 만드는 수렴의 단계이다. 수 많은 데이터는 그 자체로는 의미가 없는 더미일 뿐이다. 하지만, 데이터에서 특정한 패턴을 찾아내어 가공하는 과정을 겪으면, 뚜렷한 방향성과 의미를 가진 '정보'로 거듭날 수 있다.

이 단계에서는 페르소나와 인터뷰를 기반으로 서비스에 필요한 기능을 추상화한 Service Flow,
서비스에 필요한 모든 데이터를 조직화한 Information mind map, 그리고 마지막으로 유저가 서비스에서 겪게 될 User WorkFlow를 작성해보는 시간을 가졌다.

여기서 가장 많이 헤맸던 것 같다. 처음 작성해보는 것이다보니 제대로 하고 있는 건지, 뭔가 빠뜨린 것은 없는지 계속 걱정되어서 과제를 하면서도 긴가민가해서 꽤 아쉬움이 남았다.

3주차. 서비스 구체화

서비스 구체화 단계에서는 지난주 작성한 추상화된 Information Flow를 말 그대로 구체화하는 단계였다.
구체화 단계에서 주의해야할 점은 자세해지는 과정에서 직관에서 벗어나서는 안된다는 점이었다. 유저가 목적을 달성하기 위해 몰라도 될 사항들까지 유저에게 노출시키게 된다면 유저는 서비스 사용에 어려움을 겪을 수 밖에 없다고 한다. 이것에 주의하며 서비스 구체화를 진행해야 했는데, 이 부분이 가장 어려웠다.

각 기능이 어떻게 하나의 온전한 사이클을 갖는지 Service Process를 작성하고, 유저가 서비스를 navigate 할 수 있는 Page flow도 작성해보았는데 MECE (중복없이, 빠짐없이 알고리즘 문제처럼) 하게 진행하는 것이 정말로 쉽지 않았다.

MECE는 쉽게 말하면 프로그래밍적 사고라고도 할 수 있을 것 같다. 기획도 알고리즘 문제와 마찬가지로, MECE하게 진행되어야한다. 그런데 MECE는 원래 개발자가 잘하는 것이다. 그래서 개발자가 이런 점에서는 기획자보다 장점을 갖는다고 한다.

확실히, 회사에서도 기획자분이 작성한 기획안 리뷰를 진행할 때, 개발자와 QA는 기획자가 놓치는 작은 디테일을 잘 발견한다는 것을 느꼈었는데 이렇게 직접 기획을 해보는 경험을 통해 회사에서도 기획자님을 내가 도와줄 수 있지 않을까? 하는 생각을 갖게 되었다. 큰 틀을 기획하는 것은 기획자가 더 잘 할수도 있겠지만, 로직이 잘못되거나 아예 빠뜨리는 경우는 개발자가 더 잘 캐치할 수 있는 것을 느낄 수 있었다. 그래서 앞으로는 회사에서도 기획 단계에 참여해보고 싶은 마음이 생겼다.

배운점

우선은 매우 좋은 경험이 되었다. 특히 유저 인터뷰가 가장 기억에 남고 재미있었다. 사실 인터뷰를 진행하기 전에, 아마 이럴 것이다 하는 예측을 어쩔 수 없이 하게 되는데, 실제로 인터뷰를 진행하면서 내가 예상했던 정 반대의 답을 하는 경우도 꽤 있었고 심지어는 전혀 상상도 못했던 답을 내놓는 인터뷰이도 있었다. 그렇다보니 인터뷰가 얼마나 중요한지 몸소 체감할 수 있었다. 앞으로도 만들고 싶은 개인 프로젝트가 많이 있는데, 그 때도 반드시 사용자 인터뷰를 먼저 진행하고 페르소나를 만드는 순서로 진행해야겠다.

이렇게 1~3주차는 코드는 단 한줄도 치지 않고 기획에 대해서만 배웠다. 4~8주차까지 이렇게 열심히 인터뷰하고 UX framework를 활용한 기획안을 바탕으로 코드를 설계하고 개발을 진행하게 되는데, 기획이 설계에 직접적으로 어떤 영향을 미치게 될지 매우 기대가 되었다. 다음 글에서는 4~8주차에서 경험하고 배운점들에 대해서 작성해보려고 한다.