<div id="readability-page-1" class="page"><p><cite>anyjava</cite>
                  <span> 2020. 7. 30. 09:15</span>
                </p><div>
                                <p>큰 꿈과 희망을 가지고, 이직하면 모든 불만이 해결되겠지.. 라며 회사를 뛰쳐나올지도 모른다. 하지만 더 큰 문제가 앞에서 기다리고 있을 것이다. 낯선 공간, 낯선 사람, 낯선 개발도구들. 모든 것들이 낯선 상황에서 어떻게 적응해서 새로운 조직에서 성과를 낼 수가 있을까?</p>

<p>나의 경우 5년 만에 배민에서 카카오로 이직을 했었고, 이직하는 팀에 아는 사람이라고는 1도 없어 오로지 면접으로 증명하고 합격을 했었다. 그래서 입사한 새로운 조직에서 안정적으로 soft landing 을 잘하기 위해 했던 노력들의 썰을 풀어 본다. 결론부터 말하자면 soft landing 은 성공적이다. (뭐 우선 난 그렇다.ㅎㅎㅎ)&nbsp; 그리고 지금은 작은 조직의 장을 맡게 되었다. (이게 아닌데...)</p>


<h2>바꾸고 싶어도 참아라, 신뢰가 우선이다.</h2>

<p>일을 하기전에 신뢰를 쌓는 게 먼저다.</p>
<p>우아한형제들에서 봉타임(대표님과 대화)에서 들었던 내용이다. 새로운 조직 새로운 사람이 왔을 때 일은 어떻게 해야 할까요? (질문은 정확히 기억이 안 난다)라는 익명 질문이었는데 이런 답변을 주셨다.</p>

<p><b>"일을 시키기 전에 상대방과의 신뢰관계 형성이 먼저입니다."</b></p>

<p>인상 깊은 답변이였고, 나에게도 동일한 상황이 왔을 때 지키려 했었다. 나 또한 새로운 조직에서 효율적이지 않거나 내가 기존에 하던 방식과 다르게 하고 있을 수도 있다. 이에 대해서 내가 편한 방식으로 바꾸자고 주장하는 건 신뢰관계가 없는 상황에서는 반감이 먼저 생기기 마련이다.&nbsp; 바꾸려고 하는것 보다 왜 동료들이 그렇게 하고 있는지를 이해하는 게 먼저이다. 분명 이유가 있을 것이다. 적어도 3개월은 기존 일 하는 방식을 건들지 말고 자연스럽게 스며들어야 한다.</p>

<p>나 같은 경우는 관찰자처럼 어떻게 일하는지를 지켜보았었다. 주어진 업무도 계속 피드백을 드리며 방향성에 대해서 검증하면서 일을 했던 것 같다. (왜냐면 난 잘 모르니깐..ㅎㅎ) 그렇게 첫배포를 하게 되었고, 결정적으로는 다른 동료들의 처한 어려움을 같이 찾아주고 해결해 주기도 하면서 점점 신뢰가 나도 모르게 쌓이고 있었던 것 같다.</p>

<h2>현재의 유산은 과거의 누군가에겐 최선이었다.</h2>

<p><a href="https://youtu.be/amvG-eHjbBE?t=707">세바시 강연</a> 에서 나온 이야기이다.&nbsp; (실제 배민에서도 전사 발표 때 봤었다.) 새로운 조직이나 프로젝트에서 기존 코드를 보면 리팩터링 욕구가 막막 샘솟아 오를지도 모른다. 당장 멈춰라. 당신이 보는 그 코드는 과거의 누군가에게는 최선이었을 것이다. 그 코드가 당신을 채용할 수 있게 돈을 벌어다 주었던 코드일 수도 있고, 심지어 현재도 많은 고객들에게 가치를 제공하고 있는 코드이다.</p>

<p>완벽한 코드는 세상에 없으며, 지속적으로 좋은 코드를 향해 변화하는 코드만 있을 뿐이다. 좋은 코드 또는 클린코드는 같이 일 하는 동료들이 다 같이 이해하고 동의된 코드라고 생각한다. 조금씩 꾸준하게 개선을 해나가야 하며 한 번에 갈아엎을 생각을 하지 말라. 코드 리뷰 등을 통해서 토론하고 다수가 동의하는 구조로 개선해 나가야 한다.&nbsp; 설득이 필요하다면,&nbsp; 샘플 프로젝트 등을 통해서 예시를 보고 설득해야 한다.</p>


<h2>회고를 했다는 게 너무 좋아요.</h2>

<p>입사한 지 2개월여 만에 한 나의 첫 회고의 유일한 코멘트이다.&nbsp; 회고란 지나온 길을 뒤돌아 보고 앞으로 더 나은 방향으로 나아가기 위한 과정이라고 본다. 첫 회고에서 동료들의 아쉬운 점 중 코드 리뷰가 힘들다는 내용이 많았다. 나 혼자만의 고민이 아니였구나 하는 걸 알게 되었고 (의견 개진 자신감 뿜뿜!), 그래서 의견을 내어 매주 오프라인 코드 리뷰를 제안하기도 했었다. 그리고 회고를 자주 하자고 했다.</p>

<p>3개월 뒤, 입사 6개월 차에 회고를 하자고 먼저 제안을 했다. (맞다. 첫 회고 후 회고는 없었다) 업무 리딩 해주셨던 분이 흔쾌히 승낙을 하셨고 나에게 주도해서 진행해달라고 위임해주셨다. 좋은 방법을 같이 공유할 절호의 기회였고 나는 준비해서 회고를 진행했다. (어떤 방식인지는 <a href="https://woowabros.github.io/experience/2020/05/13/birth-of-team-culture.html">팀 문화의 탄생을</a> 참고) 첫 회고의 Try 결과인 action item 으로 업무 워크숍을 진행하고, git branch 전략 공유 등이 나왔었다. 그 이후로는 매월 1회 회고를 진행하고 있다. 회고를 하면서 놀라운 게 다들 비슷한 고민과 어려움을 고민한다는 점이었다. 그래서 그런 고민들을 바탕으로 Keep / Problem / Try를 하면서 조금씩 조금씩 개선을 함께 해나가고 있다. 여러 가지 action item 하나를 소개하면 해당 월의 미어캣을 지정하여, 운영 이슈나 궁금한 점에 대해 기획자들이 편하게 물어볼 수 있게 담당자를 지정하여 운영하고 있다.</p>



<p>1년이 된 지금에 돌아보면, 아무런 인연이 없는 나에게 조직장과의 1on1 미팅에서 내가 하고 있는 방식을 지지해 주셨던 게 가장 큰 도움이 되었던 것 같다. 사실, 면접을 통해 뽑아주셨던 분이기도 하니 추천한 분이기도 하다. 입사 첫날 나랑 가장 신뢰해주는 사람은 나를 뽑아준 팀장님이지 않을까? 그래서 최초의 아군(?)을 실망시키지 말아야 한다. 의견을 묻고 고민을 털어놓으면 좋을 것 같다.</p>


<h2>마무리를 해보자면,</h2>

<p>신뢰를 기반으로 하여 팀 문화를 점점 개선해 나가려는 노력을 했던 것 같다. 처음 부여받은 미션, 팀에서의 궂은일, 히스토리를 빠르게 파악하고 기존 동료들이 어떻게 일 하고 있는지를 파악해야 한다. 또한 오프라인 코드 리뷰라는 방법을 가지고 사람들과의 개발에 대한 방향성과 약속들을 정리해 나가면 좋다. 물론 이미 정리되어 있다면 더할 나위 없이 좋을 것이다.</p>
<p>마지막으로 회고라는 도구를 가지고 내가 원하는 방향의 개선이 아니라 동료들 간의 공감된 문제를 가지고 같이 해결해가는 게 중요하다. 난 단지 내가 경험한 사례를 알려줌으로써 선택지를 넓혀 줄 뿐이었다. 개발이든 개발 문화 혹은 업무방식이든 주기적인 피드백을 바탕으로 개선해 나가는 게 좋을 것 같다. 어느 조직에서는 나 혼자 잘해서는 큰 성과를 바라기는 어렵다. 내 옆에 있는 동료들과 함께 성과를 내야 한다.</p>

<p>회고를 하고 있지 않다면 회고를 해보세요.</p>



<h3>덧,</h3>

<p>회고 홍보글 같지만, 맞는 것 같다.🙂 면접에서 보통 마지막에 궁금한 게 없냐고 물어본다. 나는 꼭 물어보는 게 있다. "코드 리뷰는 어떻게 하시나요?" "회고는 어떤 방식으로 하시나요?"라고 꼭 확인하고 입사하자. 그래서 연차가 낮을수록 이미 하고 있는 조직에 합류하길 추천한다. 고연차라면 직접 도입하는 걸 추천한다.</p>
            
            
                </div></div>

또라이개발자

Son Hyeon Tae

큰 꿈과 희망을 가지고, 이직하면 모든 불만이 해결되겠지.. 라며 회사를 뛰쳐나올지도 모른다. 하지만 더 큰 문제가 앞에서 기다리고 있을 것이다. 낯선 공간, 낯선 사람, 낯선 개발도구들. 모든 것들이 낯선 상황에서 어떻게 적응해서 새로운 조직에서 성과를 낼 수가 있을까?
 
나의 경우 5년 만에 배민에서 카카오로 이직을 했었고, 이직하는 팀에 아는 사람이라고는 1도 없어 오로지 면접으로 증명하고 합격을 했었다. 그래서 입사한 새로운 조직에서 안정적으로 soft landing 을 잘하기 위해 했던 노력들의 썰을 풀어 본다. 결론부터 말하자면 soft landing 은 성공적이다. (뭐 우선 난 그렇다.ㅎㅎㅎ)  그리고 지금은 작은 조직의 장을 맡게 되었다. (이게 아닌데...)
 
 
바꾸고 싶어도 참아라, 신뢰가 우선이다.
 
일을 하기전에 신뢰를 쌓는 게 먼저다.
우아한형제들에서 봉타임(대표님과 대화)에서 들었던 내용이다. 새로운 조직 새로운 사람이 왔을 때 일은 어떻게 해야 할까요? (질문은 정확히 기억이 안 난다)라는 익명 질문이었는데 이런 답변을 주셨다.
 
"일을 시키기 전에 상대방과의 신뢰관계 형성이 먼저입니다."
 
인상 깊은 답변이였고, 나에게도 동일한 상황이 왔을 때 지키려 했었다. 나 또한 새로운 조직에서 효율적이지 않거나 내가 기존에 하던 방식과 다르게 하고 있을 수도 있다. 이에 대해서 내가 편한 방식으로 바꾸자고 주장하는 건 신뢰관계가 없는 상황에서는 반감이 먼저 생기기 마련이다.  바꾸려고 하는것 보다 왜 동료들이 그렇게 하고 있는지를 이해하는 게 먼저이다. 분명 이유가 있을 것이다. 적어도 3개월은 기존 일 하는 방식을 건들지 말고 자연스럽게 스며들어야 한다.
 
나 같은 경우는 관찰자처럼 어떻게 일하는지를 지켜보았었다. 주어진 업무도 계속 피드백을 드리며 방향성에 대해서 검증하면서 일을 했던 것 같다. (왜냐면 난 잘 모르니깐..ㅎㅎ) 그렇게 첫배포를 하게 되었고, 결정적으로는 다른 동료들의 처한 어려움을 같이 찾아주고 해결해 주기도 하면서 점점 신뢰가 나도 모르게 쌓이고 있었던 것 같다.
 
현재의 유산은 과거의 누군가에겐 최선이었다.
 
세바시 강연 에서 나온 이야기이다.  (실제 배민에서도 전사 발표 때 봤었다.) 새로운 조직이나 프로젝트에서 기존 코드를 보면 리팩터링 욕구가 막막 샘솟아 오를지도 모른다. 당장 멈춰라. 당신이 보는 그 코드는 과거의 누군가에게는 최선이었을 것이다. 그 코드가 당신을 채용할 수 있게 돈을 벌어다 주었던 코드일 수도 있고, 심지어 현재도 많은 고객들에게 가치를 제공하고 있는 코드이다.
 
완벽한 코드는 세상에 없으며, 지속적으로 좋은 코드를 향해 변화하는 코드만 있을 뿐이다. 좋은 코드 또는 클린코드는 같이 일 하는 동료들이 다 같이 이해하고 동의된 코드라고 생각한다. 조금씩 꾸준하게 개선을 해나가야 하며 한 번에 갈아엎을 생각을 하지 말라. 코드 리뷰 등을 통해서 토론하고 다수가 동의하는 구조로 개선해 나가야 한다.  설득이 필요하다면,  샘플 프로젝트 등을 통해서 예시를 보고 설득해야 한다.
 
 
회고를 했다는 게 너무 좋아요.
 
입사한 지 2개월여 만에 한 나의 첫 회고의 유일한 코멘트이다.  회고란 지나온 길을 뒤돌아 보고 앞으로 더 나은 방향으로 나아가기 위한 과정이라고 본다. 첫 회고에서 동료들의 아쉬운 점 중 코드 리뷰가 힘들다는 내용이 많았다. 나 혼자만의 고민이 아니였구나 하는 걸 알게 되었고 (의견 개진 자신감 뿜뿜!), 그래서 의견을 내어 매주 오프라인 코드 리뷰를 제안하기도 했었다. 그리고 회고를 자주 하자고 했다.
 
3개월 뒤, 입사 6개월 차에 회고를 하자고 먼저 제안을 했다. (맞다. 첫 회고 후 회고는 없었다) 업무 리딩 해주셨던 분이 흔쾌히 승낙을 하셨고 나에게 주도해서 진행해달라고 위임해주셨다. 좋은 방법을 같이 공유할 절호의 기회였고 나는 준비해서 회고를 진행했다. (어떤 방식인지는 팀 문화의 탄생을 참고) 첫 회고의 Try 결과인 action item 으로 업무 워크숍을 진행하고, git branch 전략 공유 등이 나왔었다. 그 이후로는 매월 1회 회고를 진행하고 있다. 회고를 하면서 놀라운 게 다들 비슷한 고민과 어려움을 고민한다는 점이었다. 그래서 그런 고민들을 바탕으로 Keep / Problem / Try를 하면서 조금씩 조금씩 개선을 함께 해나가고 있다. 여러 가지 action item 하나를 소개하면 해당 월의 미어캣을 지정하여, 운영 이슈나 궁금한 점에 대해 기획자들이 편하게 물어볼 수 있게 담당자를 지정하여 운영하고 있다.
 
 
 
1년이 된 지금에 돌아보면, 아무런 인연이 없는 나에게 조직장과의 1on1 미팅에서 내가 하고 있는 방식을 지지해 주셨던 게 가장 큰 도움이 되었던 것 같다. 사실, 면접을 통해 뽑아주셨던 분이기도 하니 추천한 분이기도 하다. 입사 첫날 나랑 가장 신뢰해주는 사람은 나를 뽑아준 팀장님이지 않을까? 그래서 최초의 아군(?)을 실망시키지 말아야 한다. 의견을 묻고 고민을 털어놓으면 좋을 것 같다.
 
 
마무리를 해보자면,
 
신뢰를 기반으로 하여 팀 문화를 점점 개선해 나가려는 노력을 했던 것 같다. 처음 부여받은 미션, 팀에서의 궂은일, 히스토리를 빠르게 파악하고 기존 동료들이 어떻게 일 하고 있는지를 파악해야 한다. 또한 오프라인 코드 리뷰라는 방법을 가지고 사람들과의 개발에 대한 방향성과 약속들을 정리해 나가면 좋다. 물론 이미 정리되어 있다면 더할 나위 없이 좋을 것이다.
마지막으로 회고라는 도구를 가지고 내가 원하는 방향의 개선이 아니라 동료들 간의 공감된 문제를 가지고 같이 해결해가는 게 중요하다. 난 단지 내가 경험한 사례를 알려줌으로써 선택지를 넓혀 줄 뿐이었다. 개발이든 개발 문화 혹은 업무방식이든 주기적인 피드백을 바탕으로 개선해 나가는 게 좋을 것 같다. 어느 조직에서는 나 혼자 잘해서는 큰 성과를 바라기는 어렵다. 내 옆에 있는 동료들과 함께 성과를 내야 한다.
 
회고를 하고 있지 않다면 회고를 해보세요.
 
 
 
덧,
 
회고 홍보글 같지만, 맞는 것 같다.  면접에서 보통 마지막에 궁금한 게 없냐고 물어본다. 나는 꼭 물어보는 게 있다. "코드 리뷰는 어떻게 하시나요?" "회고는 어떤 방식으로 하시나요?"라고 꼭 확인하고 입사하자. 그래서 연차가 낮을수록 이미 하고 있는 조직에 합류하길 추천한다. 고연차라면 직접 도입하는 걸 추천한다.

11년차 개발자의 새로운 조직 적응기

댓글