<div id="readability-page-1" class="page"><cite>anyjava</cite>
 2019. 7. 9. 05:30
 <div>
 <blockquote>
<div>지난 5년간 다녔던 우아한형제들을 퇴사 예정이다. (현재 잔여 휴가를 즐기는 중) 5년을 정리하려니 너무 많은 일이 있어서 차근차근 정리해보려고 한다. 무엇보다도 5년 전의 내 모습과 너무나도 많이 달라져 있기 때문에, 이 회사에서 배운 것에 대해서 정리해 보려 한다.다 적고 나서 다시 읽어 보는 데, 글도 길지만 하고 싶은 말을 다 녹이지 못해 아쉽다.</div>
</blockquote>

<h2>항상 고객 중심을 생각하며 일해야 한다</h2>

김봉진 대표님이 항상 강조하시는 말이 있다.

“만드는 사람이 수고로우면 쓰는 사람이 편하고, 만드는 사람이 편하면 쓰는 사람이 수고롭다”
<figure data-filename="blob" width="820" height="408">
 
 <img src="https://k.kakaocdn.net/dn/pNrYv/btqwCqgxXH7/yydLSp49IpjAuvkyj2wQ8k/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="blob" width="820" height="408">
 
 <figcaption>사내 곳곳에 여러 글귀가 붙어 있다.</figcaption>
</figure>
특정 피쳐를 개발 할때는 일이 중심이 되어서도 안 되고, 기술이 중심이 되어서도 안된다고 본다. 제일 먼저 고객에게 좀 더 나은 가치를 제공할 수 있을지 구성원 모두가 고민해야 한다. 사내 어디서든지 문구로서 확인할 수 있고, 대표님도 항상 강조하시던 부분이라. 5년이 지난 지금에는 몸에 배 있을 정도다.


특히, 이 회사 와서 가장 좋았던 게 있다. 회의를 할 때, 일이 되는 방향으로 회의가 진행된다는 것이다. 조직의 R&amp;R 을 논하며 일을 피하지 않고, 적극적으로 고객에게 어떤 가치를 줄 수있을지에 대한 방안을 논의한다는 것이다. (사실 전직장에서는 특정 피쳐를 개발하면 장애난다. 우리 팀 롤이 아니다. 등으로 일을 하지 않기 위한 회의를 많이 겪었다.) 안돼요. 라는 말을 하는 게 아니라. 할 수 있는 방법을 찾는 회의를 할 때가 가장 즐겁고 뿌듯했던 것 같다.


&nbsp; 지금 내가 개발하는 것이 고객에게 어떤 가치를 제공할 수 있는지 고민하자. 그리고 이해 관계자 모두가 동의한 내용이라면 개발자는 기술로서 해당 기능을 구현해 내야 한다. 나는 그게 개발자의 역할이라고 보고 있다.

<h2>치열하게 서비스를 성장 시키며 배운 것</h2>

<h2>개발자라고 개발만 하지 않는다.</h2>

창업 초기에 전단지를 직접 주워 모아서 서비스를 만들었다는 건 많이 알려진 사실이다. (<a href="https://www.venturesquare.net/759688" target="_blank" rel="noopener">처음에는 보잘것 없다. 배민도 그랬다</a> - 벤처스퀘어) 내가 입사 했을 때는 전단지를 줍는 대대적인 캠페인을 하는 시점은 지났었지만, 그래도 구성원들이 퇴근하고 다니는 곳에서 전단지를 주워 와서 전단지 모으는 곳에 두는 건 습관화가 되어 있었다.


2014년 7월 복날이었었다. 주말마다 주문중계 예비군(자세한 내용은 아래 우아한 tech 글 참고)을 운영하고 있었는데, 그날 복날에는 주문을 처리할 수 없을 정도로 주문이 많았었다. 그래서 직원 중에서 가능한 예비군을 모집했고, 나는 지원을 해서 전화 주문중계를 같이 했었다.
입사한지 1년도 되지 않아 되게 어리숙하게 했었는데, 현업부서 분들이 어떻게 일하는지를 직접 경험할 수 있었던 아주 좋은 계기가 되었던 것 같다. 지금에서 생각이지만 그때 경험 때문에 더 고객 중심으로 일할 수 있었던 것 같다.
<center></center>
그 이후에도 주기적으로 영업 매니져 분들과 동행을 나가서 업주분들과대화를 나누는 걸 옆에서 지켜보며 서비스에 어떻게 도움이 될 수 있을지 개선할 점을 없을지에 대해서 고민했었던 것 같다.

여러분이 개발자라면 꼭 본인이 하는 서비스가 어떻게 운영되고 있는지 직접 체험해 보라. 그래야 내가 어떻게 개발을 해야 할지 안다.

<h2>장애 피할 수 없으면 즐겨라</h2>

개발자라면 장애는 피할 수 없는 것이다. 피할 수 없으면 즐겨라 라는 말이 있다. 나는 5년간 정말 장애를 (좀 오바해서) 즐겼던 것 같다. 5년간 겪었던 수많은 장애를 일일이 나열할 수 없지만, 외부로 공유된 내용이 있어서 공유해본다.

<center></center>
그때는 무한도전의 파급력이 대단하다고 생각했었지만, 지금 와서 생각해 보면 개발조직이 많이 성숙하지 못했던 것 같다.

내가 하고 싶은 말은 장애를 통해서 배우라는 것이다.

나는 배달의민족 서비스에서 5년간 광고시스템만을 개발해 왔다. 그래서 상대적으로 대용량 트래픽을 처리할 기회가 적어서 대용량 트래픽에 경험이 풍부하지 못하다. 그래서 나는 장애 후에는 장애보고서 / 장애회고 / 직접 찾아가서 묻기 등을 통해서 배우려고 했었다.

이 장애가 왜 발생했고, 어떻게 해결했는지 나라면 어떻게 했을 것 같은지에 대해 항상 고민 했었던 것 같다. 그런 덕에 더 많이 성장 할 수 있고, 다음번 회사 면접에서도 좋은 평가를 받을 수 있었던 것 같다.


몇일전 팀 내 주니어 개발자에게 해준 말이 기억이 난다.
<blockquote>
"장애를 처리하는 걸 보면 그 개발자가 일을 잘하는지 못하는지 알 수 있어요. 장애 났을 때, 허둥지둥 하는 게 아니라 어디가 문제일지 감이&nbsp; 와야 합니다. 그게 바로 경험과 지식 때문이에요.”
</blockquote>


그리고, 장애에 대해서 절대 특정인을 blame 해서는 안 된다. 그러면 사람들은 장애가 두려워 개발하려 하지 않고 보수적으로 변한다. 우아한형제들 개발조직에 여러 장점 중 하나가 장애에 대해서 개인을 blame 하지 않는다는 것이다. 단, 동일한 실수에 대해서는 엄격하고 재발 방지를 위한 노력 또한 철저해야 한다.


장애 이야기는 따로 한 번 더 정리를 하면 좋을 것 같다. 장애 보고서를 쭉 둘러보았는데 매년 수십 건씩 있던 게 올해는 1/2등급 장애가 상반기가 지났는데도 1건이다. 정말 뿌듯한 수치인 듯…

<h2>기술부채</h2>

김범준 CTO님께서 우아한형제들로 옮기고 난 후 인터뷰 내용을 참고하면 좋을 듯 하다.
<center></center>
<a href="https://m.blog.naver.com/PostView.nhn?blogId=oops_mimi&amp;logNo=220504072234&amp;proxyReferer=https%3A%2F%2Fwww.google.com%2F" target="_blank" rel="noopener">기술부채 없이 성장할 수 없다</a> - imso 게시물 링크가 깨져 blog 글로 대신함


레거시 시스템이라고 불리는 게 서비스 초창기에는 최선의 기술셋이였고, 서비스의 초기 성장의 발판이 된 중요한 시스템이다. (절대 레거시시스템에 대해서 욕하지 말 것, 그때는 그게 최선이였다) 하지만, 내가 입사하고 얼마 지나지 않아 늘어나는 개발자간의 코드 컨플릭트 횟수가 증가하고 장애의 발생 빈도가 잦아졌다. 매년 2배 이상씩 성장하는 서비스를 더는 레거시 시스템으로는 버틸 수 없는 상황이었던 것 같다.


어떤 자리인지는 기억이 나지 않지만 김범준CTO님께서 개발실 전체를 대상으로 하셨던 말씀이 기억이 난다.


<blockquote>
(정확한 워딩이 아닐 수 있음) 우리는 유행에 따라 MSA를 선택하는 것이 아니라. 특정 도메인의 장애가 전면 장애로 전파되는 것을 막기 위함입니다.
</blockquote>


2016년부터는 프론트 시스템부터 도메인별로 하나씩 하나씩 시스템을 분리해 나가고 있었다. 나는 그 과정을 옆에서 생생히 지켜보았고, 나도 참여해서 레거시 시스템 개선에 참여했다. 그리고 결국 올해 4월 배달의민족을 서비스하는 대부분의 시스템이 신규 시스템들로 분리되어 Java / Spring 기반으로 탈바꿈되었다. (그놈의 탈루비…) 사실 정말 레거시 개선 과정도 이렇게 짧게 끝내기에는 아까운 주제이기도 하다.


다음은 마지막으로 진행했던 대규모 프로젝트 리뷰 현장 스케치 영상이다.
<center><iframe src="https://www.youtube.com/embed/tB9TGODfSDg" width="560" height="315" frameborder="" allowfullscreen=""></iframe></center>


인터넷 서비스 회사에서 아무리 기술이 뛰어나도 사용자가 좋아해 주지 않으면 의미가 없다. 기술은 하나의 목적을 해결하기 위한 수단일 뿐이다. 그 자체가 목적이 되면 안될 것이다.


<h2>공유하고 학습하는 문화</h2>

스터디를 하는 방법에 대해서 제대로 배웠던 것 같다. 5년간 다니면서 수많은 스터디에 참여하기도 했었고, 그리고 진행을 하기도 했었다. 나는 스터디의 목적은 2가지 정도 생각하고 있다. 첫 번째는 내가 학습을 하면서 동료들에게 알려 줄 수 있는 것. (사실 알려주면서 가장 많이 배울 수 있다) 두 번째는 팀 구성원들의 생각을 맞춰가는 과정이라고 본다. 좁게는 코딩 스타일이 될 수도 있고, 넓게는 시스템 설계 클래스 설계 스타일 등이 있을 것이다.


다음은 내가 스터디 했던 것들에 대한 회고 글 목록이다.
<ul>
<li>
2015년 회고 중 FP in Scala 스터디 <a href="https://blog.anyjava.net/118" target="_blank" rel="noopener">https://blog.anyjava.net/118</a>
</li>
<li>
내가 주도 했던 토비의 Spring 스터디 <a href="http://woowabros.github.io/experience/2017/07/19/finish_toby_study.html" target="_blank" rel="noopener">좋은 동료와 함께 성장하는 기쁨 - 우아한형제들 기술블로그</a>
</li>
</ul>
그리고 김범준 CTO 님의 공유에 대한 글도 있었다. 본문의 내용 중 월간잡지에 대한 내용도 있는데, 내가 작성해서 발행했던 내용이다.
<ul>
<li><a href="http://woowabros.github.io/woowabros/2016/06/30/woowabros_cto.html" target="_blank" rel="noopener">우아한형제들의 step by step - 우아한형제들 기술블로그</a></li>
</ul>

지금도 우아한형제들에서는 꾸준히 학습과 공유가 이루어지고 있다. 그 형태는 다양해지고 있지만 이런 활동들을 통해 습관화되고 배울 수 있었던 것 같다. (사실 그래서 이 글도 공유의 목적에서 쓰고 있다. 예전에 페이스북에 내가 겪고 있는걸 어떻게 공유 할까하는 글을 적었는데, 그 글에 대한 결과물을 이제서야….)

<h2>마치며,,,</h2>

가장 크게 배운 건 우아한형제들만의 특별한 기업문화다. (자세한 내용은 <a href="http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&amp;mallGb=KOR&amp;barcode=9791187289081&amp;orderClick=LAG&amp;Kc=" target="_blank" rel="noopener">배민다움</a> 이란 책을 추천한다)
무엇보다도 우아한형제들은 3개월마다 대표님과 수습해제 인터뷰를 하는데, 수습해제 인터뷰 당시 대표님과 나눴던 이야기다. 페이스북에 올렸던 글을 캡처해서 공유한다.

<figure width="820" height="568">
 
 <img src="https://t1.daumcdn.net/cfile/tistory/991EB7475D23AAC30D" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" width="820" height="568">
 
 <figcaption>우아한형제들은 수습 3개월이 지나면 대표님과 면접을 본다.</figcaption>
</figure>

나는 이제 우아한형제들이라는 좋은 회사를 함께 만드는 일은 멈추게 되었다.

좋은 회사를 만드는 일은 끝이 아니라 지금부터 시작이라고 생각한다. 우아한형제들에서 배웠던 좋은 것들을 다른 조직에서 공유하고 전파해서 또 다른 좋은 회사를 만드는 데 기여를 하고 싶다.




<h3>마지막으로 함께 했던 우아한형제들 구성원분들 감사합니다.</h3>
<figure width="820" height="466">
 
 <img src="https://t1.daumcdn.net/cfile/tistory/99EA81425D23AAC40D" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" width="820" height="466">
 
 <figcaption>우아한형제들 회사 내부에 붙여진 문구</figcaption>
</figure>
 
 
 </div></div>

또라이개발자

Son Hyeon Tae

지난 5년간 다녔던 우아한형제들을 퇴사 예정이다. (현재 잔여 휴가를 즐기는 중) 5년을 정리하려니 너무 많은 일이 있어서 차근차근 정리해보려고 한다. 무엇보다도 5년 전의 내 모습과 너무나도 많이 달라져 있기 때문에, 이 회사에서 배운 것에 대해서 정리해 보려 한다.
다 적고 나서 다시 읽어 보는 데, 글도 길지만 하고 싶은 말을 다 녹이지 못해 아쉽다.
 
항상 고객 중심을 생각하며 일해야 한다
 
김봉진 대표님이 항상 강조하시는 말이 있다.
 
“만드는 사람이 수고로우면 쓰는 사람이 편하고, 만드는 사람이 편하면 쓰는 사람이 수고롭다”
특정 피쳐를 개발 할때는 일이 중심이 되어서도 안 되고, 기술이 중심이 되어서도 안된다고 본다. 제일 먼저 고객에게 좀 더 나은 가치를 제공할 수 있을지 구성원 모두가 고민해야 한다. 사내 어디서든지 문구로서 확인할 수 있고, 대표님도 항상 강조하시던 부분이라. 5년이 지난 지금에는 몸에 배 있을 정도다.
 
 
특히, 이 회사 와서 가장 좋았던 게 있다. 회의를 할 때, 일이 되는 방향으로 회의가 진행된다는 것이다. 조직의 R&R 을 논하며 일을 피하지 않고, 적극적으로 고객에게 어떤 가치를 줄 수있을지에 대한 방안을 논의한다는 것이다. (사실 전직장에서는 특정 피쳐를 개발하면 장애난다. 우리 팀 롤이 아니다. 등으로 일을 하지 않기 위한 회의를 많이 겪었다.) 안돼요. 라는 말을 하는 게 아니라. 할 수 있는 방법을 찾는 회의를 할 때가 가장 즐겁고 뿌듯했던 것 같다.
 
 
  지금 내가 개발하는 것이 고객에게 어떤 가치를 제공할 수 있는지 고민하자. 그리고 이해 관계자 모두가 동의한 내용이라면 개발자는 기술로서 해당 기능을 구현해 내야 한다. 나는 그게 개발자의 역할이라고 보고 있다.
 
치열하게 서비스를 성장 시키며 배운 것
 
개발자라고 개발만 하지 않는다.
 
창업 초기에 전단지를 직접 주워 모아서 서비스를 만들었다는 건 많이 알려진 사실이다. (처음에는 보잘것 없다. 배민도 그랬다 - 벤처스퀘어) 내가 입사 했을 때는 전단지를 줍는 대대적인 캠페인을 하는 시점은 지났었지만, 그래도 구성원들이 퇴근하고 다니는 곳에서 전단지를 주워 와서 전단지 모으는 곳에 두는 건 습관화가 되어 있었다.
 
 
2014년 7월 복날이었었다. 주말마다 주문중계 예비군(자세한 내용은 아래 우아한 tech 글 참고)을 운영하고 있었는데, 그날 복날에는 주문을 처리할 수 없을 정도로 주문이 많았었다. 그래서 직원 중에서 가능한 예비군을 모집했고, 나는 지원을 해서 전화 주문중계를 같이 했었다.
입사한지 1년도 되지 않아 되게 어리숙하게 했었는데, 현업부서 분들이 어떻게 일하는지를 직접 경험할 수 있었던 아주 좋은 계기가 되었던 것 같다. 지금에서 생각이지만 그때 경험 때문에 더 고객 중심으로 일할 수 있었던 것 같다.
그 이후에도 주기적으로 영업 매니져 분들과 동행을 나가서 업주분들과대화를 나누는 걸 옆에서 지켜보며 서비스에 어떻게 도움이 될 수 있을지 개선할 점을 없을지에 대해서 고민했었던 것 같다.
 
여러분이 개발자라면 꼭 본인이 하는 서비스가 어떻게 운영되고 있는지 직접 체험해 보라. 그래야 내가 어떻게 개발을 해야 할지 안다.
 
장애 피할 수 없으면 즐겨라
 
개발자라면 장애는 피할 수 없는 것이다. 피할 수 없으면 즐겨라 라는 말이 있다. 나는 5년간 정말 장애를 (좀 오바해서) 즐겼던 것 같다. 5년간 겪었던 수많은 장애를 일일이 나열할 수 없지만, 외부로 공유된 내용이 있어서 공유해본다.
 
그때는 무한도전의 파급력이 대단하다고 생각했었지만, 지금 와서 생각해 보면 개발조직이 많이 성숙하지 못했던 것 같다.
 
내가 하고 싶은 말은 장애를 통해서 배우라는 것이다.
 
나는 배달의민족 서비스에서 5년간 광고시스템만을 개발해 왔다. 그래서 상대적으로 대용량 트래픽을 처리할 기회가 적어서 대용량 트래픽에 경험이 풍부하지 못하다. 그래서 나는 장애 후에는 장애보고서 / 장애회고 / 직접 찾아가서 묻기 등을 통해서 배우려고 했었다.
 
이 장애가 왜 발생했고, 어떻게 해결했는지 나라면 어떻게 했을 것 같은지에 대해 항상 고민 했었던 것 같다. 그런 덕에 더 많이 성장 할 수 있고, 다음번 회사 면접에서도 좋은 평가를 받을 수 있었던 것 같다.
 
 
몇일전 팀 내 주니어 개발자에게 해준 말이 기억이 난다.
"장애를 처리하는 걸 보면 그 개발자가 일을 잘하는지 못하는지 알 수 있어요. 장애 났을 때, 허둥지둥 하는 게 아니라 어디가 문제일지 감이  와야 합니다. 그게 바로 경험과 지식 때문이에요.”
 
 
그리고, 장애에 대해서 절대 특정인을 blame 해서는 안 된다. 그러면 사람들은 장애가 두려워 개발하려 하지 않고 보수적으로 변한다. 우아한형제들 개발조직에 여러 장점 중 하나가 장애에 대해서 개인을 blame 하지 않는다는 것이다. 단, 동일한 실수에 대해서는 엄격하고 재발 방지를 위한 노력 또한 철저해야 한다.
 
 
장애 이야기는 따로 한 번 더 정리를 하면 좋을 것 같다. 장애 보고서를 쭉 둘러보았는데 매년 수십 건씩 있던 게 올해는 1/2등급 장애가 상반기가 지났는데도 1건이다. 정말 뿌듯한 수치인 듯…
 
기술부채
 
김범준 CTO님께서 우아한형제들로 옮기고 난 후 인터뷰 내용을 참고하면 좋을 듯 하다.
기술부채 없이 성장할 수 없다 - imso 게시물 링크가 깨져 blog 글로 대신함
 
 
레거시 시스템이라고 불리는 게 서비스 초창기에는 최선의 기술셋이였고, 서비스의 초기 성장의 발판이 된 중요한 시스템이다. (절대 레거시시스템에 대해서 욕하지 말 것, 그때는 그게 최선이였다) 하지만, 내가 입사하고 얼마 지나지 않아 늘어나는 개발자간의 코드 컨플릭트 횟수가 증가하고 장애의 발생 빈도가 잦아졌다. 매년 2배 이상씩 성장하는 서비스를 더는 레거시 시스템으로는 버틸 수 없는 상황이었던 것 같다.
 
 
어떤 자리인지는 기억이 나지 않지만 김범준CTO님께서 개발실 전체를 대상으로 하셨던 말씀이 기억이 난다.
 
 
(정확한 워딩이 아닐 수 있음) 우리는 유행에 따라 MSA를 선택하는 것이 아니라. 특정 도메인의 장애가 전면 장애로 전파되는 것을 막기 위함입니다.
 
 
2016년부터는 프론트 시스템부터 도메인별로 하나씩 하나씩 시스템을 분리해 나가고 있었다. 나는 그 과정을 옆에서 생생히 지켜보았고, 나도 참여해서 레거시 시스템 개선에 참여했다. 그리고 결국 올해 4월 배달의민족을 서비스하는 대부분의 시스템이 신규 시스템들로 분리되어 Java / Spring 기반으로 탈바꿈되었다. (그놈의 탈루비…) 사실 정말 레거시 개선 과정도 이렇게 짧게 끝내기에는 아까운 주제이기도 하다.
 
 
다음은 마지막으로 진행했던 대규모 프로젝트 리뷰 현장 스케치 영상이다.
 
 
인터넷 서비스 회사에서 아무리 기술이 뛰어나도 사용자가 좋아해 주지 않으면 의미가 없다. 기술은 하나의 목적을 해결하기 위한 수단일 뿐이다. 그 자체가 목적이 되면 안될 것이다.
 
 
공유하고 학습하는 문화
 
스터디를 하는 방법에 대해서 제대로 배웠던 것 같다. 5년간 다니면서 수많은 스터디에 참여하기도 했었고, 그리고 진행을 하기도 했었다. 나는 스터디의 목적은 2가지 정도 생각하고 있다. 첫 번째는 내가 학습을 하면서 동료들에게 알려 줄 수 있는 것. (사실 알려주면서 가장 많이 배울 수 있다) 두 번째는 팀 구성원들의 생각을 맞춰가는 과정이라고 본다. 좁게는 코딩 스타일이 될 수도 있고, 넓게는 시스템 설계 클래스 설계 스타일 등이 있을 것이다.
 
 
다음은 내가 스터디 했던 것들에 대한 회고 글 목록이다.
2015년 회고 중 FP in Scala 스터디 https://blog.anyjava.net/118
내가 주도 했던 토비의 Spring 스터디 좋은 동료와 함께 성장하는 기쁨 - 우아한형제들 기술블로그
그리고 김범준 CTO 님의 공유에 대한 글도 있었다. 본문의 내용 중 월간잡지에 대한 내용도 있는데, 내가 작성해서 발행했던 내용이다.
우아한형제들의 step by step - 우아한형제들 기술블로그
 
지금도 우아한형제들에서는 꾸준히 학습과 공유가 이루어지고 있다. 그 형태는 다양해지고 있지만 이런 활동들을 통해 습관화되고 배울 수 있었던 것 같다. (사실 그래서 이 글도 공유의 목적에서 쓰고 있다. 예전에 페이스북에 내가 겪고 있는걸 어떻게 공유 할까하는 글을 적었는데, 그 글에 대한 결과물을 이제서야….)
 
마치며,,,
 
가장 크게 배운 건 우아한형제들만의 특별한 기업문화다. (자세한 내용은 배민다움 이란 책을 추천한다)
무엇보다도 우아한형제들은 3개월마다 대표님과 수습해제 인터뷰를 하는데, 수습해제 인터뷰 당시 대표님과 나눴던 이야기다. 페이스북에 올렸던 글을 캡처해서 공유한다.
 
 
나는 이제 우아한형제들이라는 좋은 회사를 함께 만드는 일은 멈추게 되었다.
 
좋은 회사를 만드는 일은 끝이 아니라 지금부터 시작이라고 생각한다. 우아한형제들에서 배웠던 좋은 것들을 다른 조직에서 공유하고 전파해서 또 다른 좋은 회사를 만드는 데 기여를 하고 싶다.
 
 
 
 
마지막으로 함께 했던 우아한형제들 구성원분들 감사합니다.

우아한형제들(배달의민족)에서 5년간 내가 배운것

댓글