기능 구현을 넘어 제품의 결과를 만드는 개발자의 관점 전환

#00
기능을 만드는 사람에서, 사용자의 행동을 설계하는 사람으로.

안녕하세요, Pit 팀에서 제품을 만들고 있는 프로덕트 개발자 장서희입니다.
저는 10년 넘게 백엔드 개발자로 일해왔습니다.

개발자로 일하며 가장 재미있었던 순간은 아이디어가 실제 제품으로 살아나는 과정이었습니다.
누군가 “이런거 있었으면 좋겠다”라고 말한 것이 실제 화면이 되고, 기능이 되는 과정은 꽤 신기하고 재밌습니다.

그런데 개발을 하다 보면 꼭 한 번씩 이런 말을 듣게 됩니다.

“기능은 있는데… 사용자들이 잘 안 쓰는 것 같아요.”

그 말을 들으면 개발자는 살짝 억울해집니다.
서버도 멀쩡하고, 오류도 없고, 테스트도 다 통과했거든요.

그런데 이상하게 사람들은 안 씁니다.
코드는 잘 돌아가는데, 사용자는 떠나는 상황.

저는 그 이유가 늘 궁금했습니다.

#01
코드는 멀쩡한데, 제품은 사용되지 않을 때

개발자는 보통 새로운 기능 요청이 들어오면 이런 생각부터 합니다.

• 어떻게 만들지?
• 속도는 괜찮을까?
• 오류는 없을까?
• 일정 안에 끝낼 수 있을까?

물론 다 중요한 고민입니다.
그런데 사용자는 사실 코드를 보지 않습니다.

사용자는 그냥 “경험”을 느낍니다.

회원가입하다 막히면 짜증나고,
로딩이 길면 귀찮고,
에러 메세지가 어렵게 나오면 그냥 닫아버립니다.

아무리 좋은 코드라도 사용자가 불편하면 제품 안에서는 의미가 없어지는 거죠.
그때부터 저는 개발도 “기능 중심”보다 “사용자 흐름 중심”으로 봐야 한다고 느끼기 시작했습니다.

그리고 그 때 다시 보게 된 개념이 바로 AARRR 퍼널이었습니다.
이름은 조금 어렵지만 생각보다 단순합니다.

• 사람들은 어떻게 들어오고
• 어디서 제품이 괜찮다고 느끼고
• 왜 다시 돌아오고
• 왜 추천하고
• 왜 결제하는가

제품 안에서 사람들이 움직이는 흐름을 보는 방식에 가깝습니다.

이 관점으로 보기 시작하면 개발도 조금 달라집니다.

예를 들어 단순히 “속도가 느립니다”가 아니라,
”사람들이 첫 화면에서 기다리다 그냥 나가고 있습니다”라고 보면 문제의 무게가 완전히 달라집니다.

그 순간 개발자는 단순히 기능을 만드는 사람이 아니라,
사용자의 다음 행동을 설계하는 사람이 됩니다.

#02
퍼널로 보면 코드의 역할이 달라집니다.

퍼널 관점에서 보면 개발은 단순히 기능을 만드는 일이 아닙니다.
코드는 사용자가 “다음 행동”을 하게 만다는 작은 장치들에 가깝습니다.

• Acquisition, 유입
  사람들은 생각보다 기다리는 걸 정말 싫어합니다.
  앱이나 사이트가 느리면 내용을 보기 전에 그냥 닫아버립니다.
  그래서 속도를 개선하는 일은 단순히 개발자의 욕심이 아니라, “일단 한 번 써보게 만드는 일”에 가깝습니다.
• Activation, 활성화
  회원가입, 첫 결과 확인, 첫 추천 받기.
  사용자가 “오? 이거 괜찮은데?”를 느끼는 순간입니다.
  그런데 이때 화면이 멈추거나 에러가 뜨면 기대감도 같이 사라집니다.
  첫인상이 중요한 건 사람도 서비스도 똑같더라고요.
• Retention, 유지
  개발자는 새 기능 추가를 좋아합니다.
  하지만 사용자는 “원래 잘 되던 것”이 바뀌는 걸 훨씬 더 민감하게 느낍니다.
  자주 가던 카페 메뉴 위치가 갑자기 바뀌면 괜히 불편한 것처럼요.
  그래서 유지율은 새로운 기능보다도, 익숙한 경험을 안정적으로 이어주는 데서 만들어집니다.
• Referral, 추천
  사람들은 좋지 않은 제품은 추천하지 않습니다.
  그런데 재미있는 건, 좋은 제품이어도 공유 과정이 귀찮으면 추천을 안 한다는 점입니다.
  링크가 이상하거나, 캡처가 안 예쁘거나, 초대 과정이 복잡하면 그냥 포기합니다.
  추천은 생각보다 “작은 귀찮음”과의 싸움입니다.
• Revenue, 수익
  결제 순간은 사용자가 가장 예민해지는 타이밍입니다.
  결제 버튼을 눌렀는데 오래 기다리게 되면 갑자기 불안해집니다.
  “결제된 거 맞아…?” 하면서 새로고침도 누르게 되고요.
  그래서 결제 관련 코드는 단순히 돈을 받는 기능이 아니라, 사용자를 안심시키는 경험에 더 가깝습니다.

퍼널로 코드를 보기 시작하면 개발의 기준도 달라집니다.
단순히 “기능이 돌아가는가?”가 아니라, “이 기능이 사용자를 더 편하게 움직이게 만들고 있는가?” 를 고민하게 됩니다.

#03
Logging은 모든 퍼널을 관측하는 설계 방법입니다.

개발하다 보면 종종 이런 말을 듣습니다.

“이벤트 뭐 찍을까요?”

처음엔 그냥 데이터 남기는 작업처럼 들립니다.
그런데 사실은 꽤 중요한 질문입니다.

사람들이 어디서 멈추는지, 어디서 나가는지, 무엇을 좋아하는지는 기록하지 않으면 알 수 없기 때문입니다.
예를 들어 카페 사장님도 “어떤 메뉴가 잘 팔리는지”를 봐야 가게를 운영할 수 있듯이, 서비스도 사람들의 행동을 봐야 개선할 수 있습니다.

문제는 개발팀 안에서는 종종 이런 대화가 나온다는 점입니다.

“API 속도가 느립니다.”

그런데 이 말은 생각보다 긴급하게 들리지 않습니다.

반면 이렇게 말하면 이야기가 달라집니다.

“사람들이 첫 화면에서 기다리다가 나가고 있습니다.”

이건 단순 기술 문제가 아니라, 실제 사용자 경험의 문제가 되기 때문입니다.

퍼널을 이해하면 개발자는 기술 문제를 “사람의 행동” 기준으로 설명할 수 있게 됩니다.
그리고 그 순간부터 개발은 단순 유지보수가 아니라, 제품의 막힌 흐름을 해결하는 일이 됩니다.

#04
그렇다면 우리는 무엇을 먼저 고쳐야 할까요?

서비스를 만들다 보면 고쳐야 할 건 끝도 없이 생깁니다.

• 언젠가 정리해야 할 코드
• 보기만 해도 머리 아픈 구조
• 건드리기 무서운 오래된 기능

문제는 “고칠 게 있다”가 아닙니다.
무엇을 먼저 고칠지가 더 중요합니다.

개발자 입장에서는 복잡한 코드가 가장 거슬릴 수 있습니다.
하지만 사용자 입장에서는 결제 직전 오류 하나가 훨씬 더 치명적일 수 있습니다.

예를 들어 관리자 페이지 버튼 하나가 조금 불편한 것과, 결제 버튼이 느린 것은 영향력이 전혀 다릅니다.

퍼널 관점으로 보면 질문이 바뀝니다.

• 어디에서 사람들이 가장 많이 떠나는가?
• 어디가 가장 답답한 경험인가?
• 무엇이 구매나 재방문을 막고 있는가?

그때부터 우선순위는 코드의 복잡도가 아니라, 사용자 경험에 미치는 영향으로 정해지기 시작합니다.

#05
질문 하나가 개발을 바꿉니다.

퍼널을 이해한 개발자는 기능을 만들기 전에 질문 하나를 먼저 합니다.

“이 기능은 사람들의 어떤 행동을 바꾸기 위한 걸까?”

이 질문 하나로 설계가 달라집니다.

• 처음 사용하는 사람이 쉽게 적응해야 하는 기능인지
• 다시 돌아오게 만드는 기능인지
• 구매를 망설이지 않게 만드는 기능인지

목표에 따라 만드는 방식도 달라지기 때문입니다.

결국 개발은 단순히 화면과 기능을 추가하는 일이 아닙니다.

사람들이 더 쉽게 들어오고,
덜 불편하게 사용하고,
다시 돌아오고 싶게 만드는 흐름을 만드는 일에 더 가깝습니다.

그리고 저는 그 지점부터 개발이 훨씬 더 재미있어졌습니다.

코드를 만드는 일이 아니라,
사람의 행동을 설계하는 느낌에 가까워졌기 때문입니다.