<div id="readability-page-1" class="page"><article itemscope="" itemtype="http://schema.org/BlogPosting">

  

  <div itemprop="articleBody">
    <p>최근에 우리 회사 인재검색 크루에서 경험한 개밥 먹기 경험에 대해서 공유하고자 글을 작성하게 되었다.</p>

<p>새로운 업무 환경으로 업무 조직을 개편했고 개편한 팀에서 해결해야 할 문제를 정의함에 있어서 개밥 먹기가 어떻게 효용적이었으며, 어떻게 했기 때문에 효과가 있었는지 간단하게 공유해본다.</p>

<h2 id="개밥-먹기란">개밥 먹기란?</h2>

<p>내가 처음 개밥 먹기라는 단어를 알게 된 것은 첫 회사의 CTO님을 통해서였고, 이후 <a href="https://www.joelonsoftware.com/2001/05/05/what-is-the-work-of-dogs-in-this-country/">조엘 온 소프트웨어에</a>서도 자세히 설명되어서 읽어본 적이 있다.</p>

<p>간단하게 설명하자면 프로덕트를 개발하는 조직이 자신의 제품을 직접 사용하는 것을 <strong>개밥먹는다</strong>고 표현한다.</p>

<p>단순히 고객의 불편사항을 통해서만 제품의 문제점을 파악하는 게 아니라 직접 사용하면서 불편함에 대해서 이해하고 더 나은 제품을 만들기 위해 노력하기 위해서 나왔을 거라고 예상한다.</p>

<p>특히 고객의 불편사항을 단순히 고객의 탓으로 넘기거나, 별거 아니라고 생각해서 우선순위를 뒤로 미루는 경우가 종종 있는데 직접 사용하고 불편함을 느낀다면 적절한 우선순위를 두고 개선을 하고, 추후 제품을 수정하거나 개발하는 데 있어서 좋은 영향을 줄 수 있을 거라고 생각한다.</p>

<p>처음에 내가 개밥 먹기를 제안했을 때 크루원들은 개밥먹기가 뭐냐고 <strong>스테이크 먹기로 하자!</strong> 라고 했는데 동료 개발자에게 이야기 했더니 <q>스테이크는 그냥 찾아서 먹고 싶지 않아요?</q> 라고 하셨다.</p>

<p>그 말을 들으니 개밥 먹는다는 건 선뜻 하기는 어려운, 어쩌면 제품을 만드는 사람 입장에서는 두려운 의미에서 지어진 이름인 것 같다.</p>

<h2 id="개밥-먹기를-해보자">개밥 먹기를 해보자</h2>

<p>이를 설명하기 전에 내가 속한 크루가 어떤 서비스를 하는지 간단하게 설명해본다.</p>

<p>우리 크루는 리멤버가 새로 선보이는 서비스 중 인재 검색 서비스를 개발하고 있고, 이직을 원하거나 좋은 기회를 찾고자 하는 고객에게는 프로필 입력을 통해 채용의 기회를 제공하고 인사 담당자와 헤드헌터가 편하게 인재를 찾을 수 있도록 서비스를 제공하고 있다.</p>

<p><img src="https://blog.dizy.dev/images/remember-career.png">
<span>(작년에 출시한 리멤버 인재검색 서비스)</span></p>

<p>우리 서비스를 제대로 경험해보기 위해서는 진짜 개밥 먹기를 한 사이클 끝내기 위해서는 직접 채용에 뛰어들고 제안을 보내고 채용 사례도 만드는 게 가장 좋다. 하지만 개밥 먹기를 위해 실제 채용을 진행하는 것은 사실상 불가능하고 채용을 하지 않는데 제안을 보내게 되면 유저가 제안 메시지를 받게 되고 불편함을 줄 수 있기 때문에 그렇게 진행하지는 않고 대신 다른 방법으로 진행을 했다.</p>

<h2 id="실제-경험-사례를-따라-하기">실제 경험 사례를 따라 하기</h2>

<ul>
  <li>실제로 의뢰를 받아서 진행된 Job Description를 정리하여 1인당 3개의 JD를 할당했다.</li>
  <li>이를 토대로 제안에 어울리는 인재를 직접 찾아본다</li>
  <li>실제로 이루어진 제안과 비교하여 내가 이용하면서 보낸 제안과 실제 제안이 진행된 프로필을 비교한다</li>
</ul>

<p>개밥 먹기를 해본 뒤에 우리 팀원은 모두 충격을 빠졌다. 실제로 사용하니 불편한 점도 많았고 또 우리가 생각한 고객의 모습과 실제 고객의 유저 경험 결과가 달랐던 점들이 너무 많았다. 제안 후보가 겹치는 경우가 거의 없었다.</p>

<h2 id="개밥-먹기-이후">개밥 먹기 이후</h2>

<p>막연하게 생각했던 이용자의 입장을 조금 더 선명하게 파악했고, 문제의식이 팀원 모두에게 잘 정렬되었다.</p>

<p>물론 현실적인 문제로 개밥 먹기에서 나왔던 모든 개선 사항을 다 개선하지는 못했지만, 언제든지 고려할 수 있도록 문제점에 대한 백로그를 정리하고 한 걸음씩 나아갔다.</p>

<p>그 결과 유저의 불편함을 해결 하기 위해 다음과 같은 테스크들을 진행했다.</p>

<ul>
  <li>제안 액션과 관련한 UI/UX 일부 개선</li>
  <li>검색 필터 개선</li>
  <li>서비스 최초 접속자에게 튜토리얼 제공</li>
  <li>이용권 정책 개선</li>
</ul>

<p>대부분 유저의 불편함을 해결하기 위해 노력했고, 실제로 조금씩 개선되는 제품을 보며 우리의 노력을 긍정적으로 바라보고 있다는 피드백도 종종 받게 되어서 뿌듯했다.</p>

<h2 id="개밥-먹기-이후-느낀-점">개밥 먹기 이후 느낀 점</h2>

<ul>
  <li>단순히 개밥 먹기라고 기능을 간단하게 이용하고 끝냈다면 그저 개발을 진행하면서 잘 작동하는지 테스트하는 수준으로 끝났을 거라고 생각한다.</li>
  <li>유저의 불만이 어디서 오는지 알게 되었고, 팀 전체가 이 불편한 경험을 개선하는 게 큰 숙제라는 문제의식을 공유하게 되어서 더 빠르게 의사결정을 하고 일을 할 수 있었다.</li>
  <li>특히 실제 사례를 비교해보았기 때문에 우리가 생각한 서비스의 방향성과 고객이 원하는 방향성이 어떤 점이 같고 어떤 점이 다른지에 대해서도 많이 생각할 수 있게 되었다.</li>
</ul>

<p>프로덕트를 만드는 사람들은 자신의 제품을 자기가 잘 알고 있다고 자만에 빠지기 쉽다. 하지만 그런 경험은 경계해야 하고, 실제로 유저의 입장에서 간지러운 부분들도 잘 해결 해 줄 수 있도록 노력해야 한다.</p>

<p>우리는 좋은 품질의 코드를 개발하는 사람이기도 하지만 그 이전에 좋은 제품을 만들어서 유저에게 좋은 가치를 전달해 주는 개발자라는 것을 잊지 않아야 한다.</p>

  </div>

</article></div>

Epilogue

최근에 우리 회사 인재검색 크루에서 경험한 개밥 먹기 경험에 대해서 공유하고자 글을 작성하게 되었다.
새로운 업무 환경으로 업무 조직을 개편했고 개편한 팀에서 해결해야 할 문제를 정의함에 있어서 개밥 먹기가 어떻게 효용적이었으며, 어떻게 했기 때문에 효과가 있었는지 간단하게 공유해본다.
개밥 먹기란?
내가 처음 개밥 먹기라는 단어를 알게 된 것은 첫 회사의 CTO님을 통해서였고, 이후 조엘 온 소프트웨어에서도 자세히 설명되어서 읽어본 적이 있다.
간단하게 설명하자면 프로덕트를 개발하는 조직이 자신의 제품을 직접 사용하는 것을 개밥먹는다고 표현한다.
단순히 고객의 불편사항을 통해서만 제품의 문제점을 파악하는 게 아니라 직접 사용하면서 불편함에 대해서 이해하고 더 나은 제품을 만들기 위해 노력하기 위해서 나왔을 거라고 예상한다.
특히 고객의 불편사항을 단순히 고객의 탓으로 넘기거나, 별거 아니라고 생각해서 우선순위를 뒤로 미루는 경우가 종종 있는데 직접 사용하고 불편함을 느낀다면 적절한 우선순위를 두고 개선을 하고, 추후 제품을 수정하거나 개발하는 데 있어서 좋은 영향을 줄 수 있을 거라고 생각한다.
처음에 내가 개밥 먹기를 제안했을 때 크루원들은 개밥먹기가 뭐냐고 스테이크 먹기로 하자! 라고 했는데 동료 개발자에게 이야기 했더니 스테이크는 그냥 찾아서 먹고 싶지 않아요? 라고 하셨다.
그 말을 들으니 개밥 먹는다는 건 선뜻 하기는 어려운, 어쩌면 제품을 만드는 사람 입장에서는 두려운 의미에서 지어진 이름인 것 같다.
개밥 먹기를 해보자
이를 설명하기 전에 내가 속한 크루가 어떤 서비스를 하는지 간단하게 설명해본다.
우리 크루는 리멤버가 새로 선보이는 서비스 중 인재 검색 서비스를 개발하고 있고, 이직을 원하거나 좋은 기회를 찾고자 하는 고객에게는 프로필 입력을 통해 채용의 기회를 제공하고 인사 담당자와 헤드헌터가 편하게 인재를 찾을 수 있도록 서비스를 제공하고 있다.
(작년에 출시한 리멤버 인재검색 서비스)
우리 서비스를 제대로 경험해보기 위해서는 진짜 개밥 먹기를 한 사이클 끝내기 위해서는 직접 채용에 뛰어들고 제안을 보내고 채용 사례도 만드는 게 가장 좋다. 하지만 개밥 먹기를 위해 실제 채용을 진행하는 것은 사실상 불가능하고 채용을 하지 않는데 제안을 보내게 되면 유저가 제안 메시지를 받게 되고 불편함을 줄 수 있기 때문에 그렇게 진행하지는 않고 대신 다른 방법으로 진행을 했다.
실제 경험 사례를 따라 하기
실제로 의뢰를 받아서 진행된 Job Description를 정리하여 1인당 3개의 JD를 할당했다.
이를 토대로 제안에 어울리는 인재를 직접 찾아본다
실제로 이루어진 제안과 비교하여 내가 이용하면서 보낸 제안과 실제 제안이 진행된 프로필을 비교한다
개밥 먹기를 해본 뒤에 우리 팀원은 모두 충격을 빠졌다. 실제로 사용하니 불편한 점도 많았고 또 우리가 생각한 고객의 모습과 실제 고객의 유저 경험 결과가 달랐던 점들이 너무 많았다. 제안 후보가 겹치는 경우가 거의 없었다.
개밥 먹기 이후
막연하게 생각했던 이용자의 입장을 조금 더 선명하게 파악했고, 문제의식이 팀원 모두에게 잘 정렬되었다.
물론 현실적인 문제로 개밥 먹기에서 나왔던 모든 개선 사항을 다 개선하지는 못했지만, 언제든지 고려할 수 있도록 문제점에 대한 백로그를 정리하고 한 걸음씩 나아갔다.
그 결과 유저의 불편함을 해결 하기 위해 다음과 같은 테스크들을 진행했다.
제안 액션과 관련한 UI/UX 일부 개선
검색 필터 개선
서비스 최초 접속자에게 튜토리얼 제공
이용권 정책 개선
대부분 유저의 불편함을 해결하기 위해 노력했고, 실제로 조금씩 개선되는 제품을 보며 우리의 노력을 긍정적으로 바라보고 있다는 피드백도 종종 받게 되어서 뿌듯했다.
개밥 먹기 이후 느낀 점
단순히 개밥 먹기라고 기능을 간단하게 이용하고 끝냈다면 그저 개발을 진행하면서 잘 작동하는지 테스트하는 수준으로 끝났을 거라고 생각한다.
유저의 불만이 어디서 오는지 알게 되었고, 팀 전체가 이 불편한 경험을 개선하는 게 큰 숙제라는 문제의식을 공유하게 되어서 더 빠르게 의사결정을 하고 일을 할 수 있었다.
특히 실제 사례를 비교해보았기 때문에 우리가 생각한 서비스의 방향성과 고객이 원하는 방향성이 어떤 점이 같고 어떤 점이 다른지에 대해서도 많이 생각할 수 있게 되었다.
프로덕트를 만드는 사람들은 자신의 제품을 자기가 잘 알고 있다고 자만에 빠지기 쉽다. 하지만 그런 경험은 경계해야 하고, 실제로 유저의 입장에서 간지러운 부분들도 잘 해결 해 줄 수 있도록 노력해야 한다.
우리는 좋은 품질의 코드를 개발하는 사람이기도 하지만 그 이전에 좋은 제품을 만들어서 유저에게 좋은 가치를 전달해 주는 개발자라는 것을 잊지 않아야 한다.

개밥 먹기 경험하기

댓글