<div id="readability-page-1" class="page"><div><p><img src="https://sungjk.github.io/images/2021/02/07/process.png" alt="Process" title="Process"></p>
<center>개발자가 갖추어야 할 9가지 기술(https://youtu.be/fHyTA-UIcqs)</center>
<blockquote>
  <p><strong>프로세스는 전체 시스템을 보호해주고, 어떤 사람이 실수를 해도 계속해서 나아갈 수 있도록 도와준다.</strong></p>
</blockquote>

<p>회사라는 곳은 각기 다른 개성을 가진 사람들이 모인 곳이고, 각자 일을 하는 방식도 다릅니다. 그래서 업무를 효율적으로 하기 위한 프로세스가 없다면, 개인 간에는 불만이나 의견 충돌이 생기거나 Product는 불안정하게 만들어질 수 밖에 없다고 생각합니다. 그래서 오늘은 몇 달 전 팀에서 더 나은 커뮤니케이션, 그리고 안정적인 Product를 만들기 위해 노력했던 2가지를 기록하려 합니다. 각 팀마다 적용할 수 있는 프로세스가 다르고, 일을 효율적으로 하기 위한 방법에도 정답은 없다고 생각합니다. 이 글에 있는 이야기 또한 <strong>하나의 시도이자, 한 발자국 나아가는 과정</strong>이라고 생각해주시면 감사하겠습니다.</p>

<hr>

<h2 id="이-글을-읽기-전에">이 글을 읽기 전에,</h2>
<p>팀에 공유했던 글을 잠깐 살펴보면 전체적인 맥락을 이해하기에 좋을것 같아요. 글은 <a href="https://blog.banksalad.com/tech/we-work-by-tech-spec/">뱅크샐러드의 테크 스펙</a>을 참고하여 만들었습니다. 뱅크샐러드의 테크 스펙은 커뮤니케이션 비용을 줄이고 의도와 목적을 조율할 수 있는 수단으로 사용하기에 좋은 템플릿입니다. 강추👍👍</p>

<p><img src="https://sungjk.github.io/images/2021/02/07/tech-specs.png" alt="Tech Specs" title="Tech Specs">
<img src="https://sungjk.github.io/images/2021/02/07/tech-specs2.png" alt="Tech Specs" title="Tech Specs"></p>

<hr>

<h2 id="커뮤니케이션-방식-개선하기">커뮤니케이션 방식 개선하기</h2>
<h3 id="비동기-커뮤니케이션">비동기 커뮤니케이션</h3>
<blockquote>
  <p>A: (에어팟을 끼며) 이제 집중 좀 해볼까<br>
B: A님 이런 요청이 왔는데 확인 좀 부탁드릴게요.<br>
A: 언제까지 확인해주면 될까요?<br>
B: 다음주까지 하면 되는데 미리 해놓으려구요.<br></p>
</blockquote>

<p>회사에서는 보통 시간(Time)과 공간(Space)이 중심이 되는 <strong>동기 커뮤니케이션(Synchronous Communication)</strong>을 기반으로 업무가 진행됩니다. 동기 커뮤니케이션은 실시간 커뮤니케이션이라고도 부르는데요. 위 대화에서 다소 이기적일 수 있는 B의 행동은 동기 커뮤니케이션이 가져다 준 단점에서 비롯되었다고 생각합니다. 같은 공간에 있어서 실시간으로 대화할 수 있고, 급하고 성가신 일을 바로 처리할 수 있습니다. 이런 동기 커뮤니케이션에 따른 즉각적인 처리가 자주 발생하면 흔히 말하는 컨텍스트 스위칭(Context Switching)이 자주 발생하고, 업무의 몰입을 방해하는 요인으로 이어지게 됩니다. 개발자의 경우 업무에 몰입할 시간이 부족해지면 코드 품질은 떨어지기 마련이죠. 즉각적인 답변이 가능해지는 등 다양한 장점이 있겠지만, 코로나로 인해 재택근무가 길어지는 상황에서의 동기 커뮤니케이션은 어울리지 않는 퍼즐의 조각이 아닐까 생각합니다.</p>

<p>이와 반대로 <strong>비동기 커뮤니케이션(Asynchronous Communication)</strong>은 메신저처럼 즉각적인 답변을 요구하는 것과 달리 이메일이나 코멘트를 통해 소통하는 것처럼 답변을 잠시 미루었다가 원하는 때에 하는 것이라고 생각하면 됩니다. 이렇듯 답변이나 일 처리를 언제할 지 그 시점을 내가 컨트롤 할 수 있기 때문에, 업무에 몰입할 수 있는 시간을 효율적으로 관리할 수 있습니다.</p>

<h3 id="메인-채널-선정하기">메인 채널 선정하기</h3>
<p>코로나로 인해 재택근무가 길어지면서 회의 뿐만 아니라 불필요한 커뮤니케이션이 많이 줄어들기도 했지만, 한편으로는 동료들과의 업무 공간이 분리되어 실시간 커뮤니케이션이 어려워지다보니, 기존에 사용중이던 메신저, 사내 게시판 그리고 <a href="https://www.atlassian.com/ko/software/jira">Jira</a>를 통한 커뮤니케이션이 더 피로하게 느껴졌습니다. 비동기적으로 커뮤니케이션하는 문화가 정착되어 있지 않아서 모든 채널에 응답해줘야 하는 상황이 빈번해서가 아닐까…</p>

<p><img src="https://sungjk.github.io/images/2021/02/07/jira-issue.png" alt="Jira Issue" title="Jira Issue"></p>
<center>종료 조건(Acceptance Criteria)과 배포 환경</center>

<p>효율적인 비동기 커뮤니케이션을 위해 가장 먼저 고려해야 할 사항은 메인 채널을 선정하는 것이라고 생각합니다. 그래서 저희 팀은 여러 가지 커뮤니케이션 채널 중에서 Jira에 <strong>Task의 시작과 끝, 그리고 모든 히스토리를 관리</strong>하기로 결정하였습니다. 그리고 Issue 생성자와 담당자 사이에 완전한 비동기 커뮤니케이션을 가능하게 만들기 위해 몇가지 규칙을 정하였습니다.</p>

<p><img src="https://sungjk.github.io/images/2021/02/07/given-when-then.png" alt="GWT" title="GWT"></p>

<ul>
  <li>Issue 생성자: 반드시 해당 Issue의 <strong>종료 조건(Acceptance Criteria)</strong>를 추가한다.</li>
  <li>Issue 담당자: 해당 기능이 <strong>어느 단계(dev, prod 등)까지 배포되었는지</strong> 추가한다.</li>
  <li>Issue 생성자와 담당자: 기능 배포 후 <strong>테스트 결과</strong>를 추가한다.</li>
</ul>

<p>개발자들은 흔히 단위 테스트(UnitTest)를 작성할 때 '어떤 조건 하에(Given) 어떤 일을 하면(When) 어떤 결과를 얻는다(Then)' 라는 Given-When-Then 전략을 많이 사용합니다. 이처럼 Issue에 대한 종료 조건과 현재 진행 상황이 잘 기록되어 있다면, Issue 생성자와 담당자 모두 커뮤니케이션의 비용을 줄일 수 있었습니다.</p>

<hr>

<h2 id="nip-it-in-the-bud">Nip it in the bud</h2>
<p>넷플릭스의 조직문화 이야기를 담은 <a href="https://sungjk.github.io/2020/09/26/no-rules-rules.html">규칙없음</a>에도 소개되었듯, 넷플릭스는 직원들이 최대한 창의적으로 일할 수 있는 환경을 제공하기 위해 실무자의 업무 활동을 감독하거나 통제하지 않는다고 합니다. 이와 반대로, <strong>회사가 위험이라는 것에 민감할 수록 위험이라는 오류를 제거하기 위해 더 많은 노력을 해야 한다</strong>고 말합니다. 오류가 발생할 수 있는 여지를 미리 바로 잡는게 좋다는 말입니다. 책에서 이 부분을 읽었을때 제가 몸담고 있는 회사가 생각났습니다. 금융이라는 민감한 서비스를 다루고 있어서, 사소한 실수로 인한 장애가 큰 사고로 이루어질 수 있는 곳입니다.</p>

<p><img src="https://sungjk.github.io/images/2021/02/07/release-engineer.png" alt="Release Engineer" title="Release Engineer"></p>
<center>채용 페이지에 소개된 Release Engineer 업무내용</center>

<p>그래서 <strong>장애가 발생할 수 있는 여지를 사전에 방지(Nip it in the bud)</strong>하기 위해 Release Engineer(RE)라는 팀이 신설되었습니다. 잠깐 RE팀에 속해서 서비스 배포를 직접 전담한 경험을 하였는데, 안정적인 배포를 위해 테스트와 모니터링이 중요하다는걸 배울 수 있었습니다. 안정적인 배포에 신경쓰다보니 테스트 커버리지를 높이는 것과 코드 리뷰에 많은 노력을 기울이고 있는지 되돌아보게 되었습니다.</p>

<h3 id="pull-request-템플릿-만들어보기">Pull Request 템플릿 만들어보기</h3>
<p>팀에서 어떤 기능 추가나 개선 즉, 코드 수정으로 인한 장애가 발생한다면, 개인의 실수가 아니라 팀원 모두에게 책임이 있습니다. 이 글의 첫 문단에서도 언급했듯이, 프로세스는 전체 시스템을 보호해주고 어떤 사람이 실수를 해도 계속 나아갈 수 있도록 도와줍니다. 그리고 이런 실수를 사전에 방지할 수 있는 프로세스가 없다는건 팀원 모두의 책임이 아닐까요?</p>

<p>저희 팀에는 기존에 따로 정해진 Pull Request(PR) 템플릿이 없어서 정해진 규칙 없이 담당자가 알아서 작성하고 있었습니다. 리뷰할 내용에 대한 컨텍스트가 공유되지 않아서, 어떤 부분을 중점적으로 리뷰해야 할 지 모호한게 가장 큰 문제였다고 생각했습니다. 그래서 필요해 보이는 몇가지 사항을 추가해서 아래와 같은 PR 템플릿을 사용하기로 결정했고, 기대되는 효과는 다음과 같았습니다.</p>

<ol>
  <li><strong>리뷰어에게 이 PR이 왜 필요한지 히스토리와 Context를 공유합니다.</strong></li>
  <li><strong>중점적으로 리뷰할 부분을 명시함으로써 해당 코드에서 생길 수 있는 버그를 사전에 발견합니다.</strong></li>
  <li><strong>테스트 결과를 첨부함으로써 코드에 대한 신뢰도를 올려줍니다.</strong></li>
</ol>

<p><img src="https://sungjk.github.io/images/2021/02/07/pr-template.png" alt="Github Template" title="Github Template"></p>

<h2 id="아직">아직,</h2>
<p>개선해야 할 부분은 많고, 갈 길이 멀게만 느껴집니다. 나부터, 작은 것부터 하나, 둘 개선해 나아가다 보면 어느샌가 목표에 도달해 있지 않을까 싶어요.</p>

<hr>

<h3 id="references">References</h3>
<ul>
  <li><a href="https://youtu.be/fHyTA-UIcqs">개발자가 갖추어야 할 9가지 기술</a></li>
  <li><a href="https://platum.kr/archives/145578">비대면 시대, 일하는 방식의 변화와 협업툴</a></li>
</ul>
</div></div>

coyled.com

Jeremy Kim

개발자가 갖추어야 할 9가지 기술(https://youtu.be/fHyTA-UIcqs)
  
프로세스는 전체 시스템을 보호해주고, 어떤 사람이 실수를 해도 계속해서 나아갈 수 있도록 도와준다.
회사라는 곳은 각기 다른 개성을 가진 사람들이 모인 곳이고, 각자 일을 하는 방식도 다릅니다. 그래서 업무를 효율적으로 하기 위한 프로세스가 없다면, 개인 간에는 불만이나 의견 충돌이 생기거나 Product는 불안정하게 만들어질 수 밖에 없다고 생각합니다. 그래서 오늘은 몇 달 전 팀에서 더 나은 커뮤니케이션, 그리고 안정적인 Product를 만들기 위해 노력했던 2가지를 기록하려 합니다. 각 팀마다 적용할 수 있는 프로세스가 다르고, 일을 효율적으로 하기 위한 방법에도 정답은 없다고 생각합니다. 이 글에 있는 이야기 또한 하나의 시도이자, 한 발자국 나아가는 과정이라고 생각해주시면 감사하겠습니다.
이 글을 읽기 전에,
팀에 공유했던 글을 잠깐 살펴보면 전체적인 맥락을 이해하기에 좋을것 같아요. 글은 뱅크샐러드의 테크 스펙을 참고하여 만들었습니다. 뱅크샐러드의 테크 스펙은 커뮤니케이션 비용을 줄이고 의도와 목적을 조율할 수 있는 수단으로 사용하기에 좋은 템플릿입니다. 강추👍👍
커뮤니케이션 방식 개선하기
비동기 커뮤니케이션
A: (에어팟을 끼며) 이제 집중 좀 해볼까
회사에서는 보통 시간(Time)과 공간(Space)이 중심이 되는 동기 커뮤니케이션(Synchronous Communication)을 기반으로 업무가 진행됩니다. 동기 커뮤니케이션은 실시간 커뮤니케이션이라고도 부르는데요. 위 대화에서 다소 이기적일 수 있는 B의 행동은 동기 커뮤니케이션이 가져다 준 단점에서 비롯되었다고 생각합니다. 같은 공간에 있어서 실시간으로 대화할 수 있고, 급하고 성가신 일을 바로 처리할 수 있습니다. 이런 동기 커뮤니케이션에 따른 즉각적인 처리가 자주 발생하면 흔히 말하는 컨텍스트 스위칭(Context Switching)이 자주 발생하고, 업무의 몰입을 방해하는 요인으로 이어지게 됩니다. 개발자의 경우 업무에 몰입할 시간이 부족해지면 코드 품질은 떨어지기 마련이죠. 즉각적인 답변이 가능해지는 등 다양한 장점이 있겠지만, 코로나로 인해 재택근무가 길어지는 상황에서의 동기 커뮤니케이션은 어울리지 않는 퍼즐의 조각이 아닐까 생각합니다.
이와 반대로 비동기 커뮤니케이션(Asynchronous Communication)은 메신저처럼 즉각적인 답변을 요구하는 것과 달리 이메일이나 코멘트를 통해 소통하는 것처럼 답변을 잠시 미루었다가 원하는 때에 하는 것이라고 생각하면 됩니다. 이렇듯 답변이나 일 처리를 언제할 지 그 시점을 내가 컨트롤 할 수 있기 때문에, 업무에 몰입할 수 있는 시간을 효율적으로 관리할 수 있습니다.
메인 채널 선정하기
코로나로 인해 재택근무가 길어지면서 회의 뿐만 아니라 불필요한 커뮤니케이션이 많이 줄어들기도 했지만, 한편으로는 동료들과의 업무 공간이 분리되어 실시간 커뮤니케이션이 어려워지다보니, 기존에 사용중이던 메신저, 사내 게시판 그리고 Jira를 통한 커뮤니케이션이 더 피로하게 느껴졌습니다. 비동기적으로 커뮤니케이션하는 문화가 정착되어 있지 않아서 모든 채널에 응답해줘야 하는 상황이 빈번해서가 아닐까…
종료 조건(Acceptance Criteria)과 배포 환경
효율적인 비동기 커뮤니케이션을 위해 가장 먼저 고려해야 할 사항은 메인 채널을 선정하는 것이라고 생각합니다. 그래서 저희 팀은 여러 가지 커뮤니케이션 채널 중에서 Jira에 Task의 시작과 끝, 그리고 모든 히스토리를 관리하기로 결정하였습니다. 그리고 Issue 생성자와 담당자 사이에 완전한 비동기 커뮤니케이션을 가능하게 만들기 위해 몇가지 규칙을 정하였습니다.
Issue 생성자: 반드시 해당 Issue의 종료 조건(Acceptance Criteria)를 추가한다.
Issue 담당자: 해당 기능이 어느 단계(dev, prod 등)까지 배포되었는지 추가한다.
Issue 생성자와 담당자: 기능 배포 후 테스트 결과를 추가한다.
개발자들은 흔히 단위 테스트(UnitTest)를 작성할 때 '어떤 조건 하에(Given) 어떤 일을 하면(When) 어떤 결과를 얻는다(Then)' 라는 Given-When-Then 전략을 많이 사용합니다. 이처럼 Issue에 대한 종료 조건과 현재 진행 상황이 잘 기록되어 있다면, Issue 생성자와 담당자 모두 커뮤니케이션의 비용을 줄일 수 있었습니다.
Nip it in the bud
넷플릭스의 조직문화 이야기를 담은 규칙없음에도 소개되었듯, 넷플릭스는 직원들이 최대한 창의적으로 일할 수 있는 환경을 제공하기 위해 실무자의 업무 활동을 감독하거나 통제하지 않는다고 합니다. 이와 반대로, 회사가 위험이라는 것에 민감할 수록 위험이라는 오류를 제거하기 위해 더 많은 노력을 해야 한다고 말합니다. 오류가 발생할 수 있는 여지를 미리 바로 잡는게 좋다는 말입니다. 책에서 이 부분을 읽었을때 제가 몸담고 있는 회사가 생각났습니다. 금융이라는 민감한 서비스를 다루고 있어서, 사소한 실수로 인한 장애가 큰 사고로 이루어질 수 있는 곳입니다.
채용 페이지에 소개된 Release Engineer 업무내용
그래서 장애가 발생할 수 있는 여지를 사전에 방지(Nip it in the bud)하기 위해 Release Engineer(RE)라는 팀이 신설되었습니다. 잠깐 RE팀에 속해서 서비스 배포를 직접 전담한 경험을 하였는데, 안정적인 배포를 위해 테스트와 모니터링이 중요하다는걸 배울 수 있었습니다. 안정적인 배포에 신경쓰다보니 테스트 커버리지를 높이는 것과 코드 리뷰에 많은 노력을 기울이고 있는지 되돌아보게 되었습니다.
Pull Request 템플릿 만들어보기
팀에서 어떤 기능 추가나 개선 즉, 코드 수정으로 인한 장애가 발생한다면, 개인의 실수가 아니라 팀원 모두에게 책임이 있습니다. 이 글의 첫 문단에서도 언급했듯이, 프로세스는 전체 시스템을 보호해주고 어떤 사람이 실수를 해도 계속 나아갈 수 있도록 도와줍니다. 그리고 이런 실수를 사전에 방지할 수 있는 프로세스가 없다는건 팀원 모두의 책임이 아닐까요?
저희 팀에는 기존에 따로 정해진 Pull Request(PR) 템플릿이 없어서 정해진 규칙 없이 담당자가 알아서 작성하고 있었습니다. 리뷰할 내용에 대한 컨텍스트가 공유되지 않아서, 어떤 부분을 중점적으로 리뷰해야 할 지 모호한게 가장 큰 문제였다고 생각했습니다. 그래서 필요해 보이는 몇가지 사항을 추가해서 아래와 같은 PR 템플릿을 사용하기로 결정했고, 기대되는 효과는 다음과 같았습니다.
리뷰어에게 이 PR이 왜 필요한지 히스토리와 Context를 공유합니다.
중점적으로 리뷰할 부분을 명시함으로써 해당 코드에서 생길 수 있는 버그를 사전에 발견합니다.
테스트 결과를 첨부함으로써 코드에 대한 신뢰도를 올려줍니다.
아직,
개선해야 할 부분은 많고, 갈 길이 멀게만 느껴집니다. 나부터, 작은 것부터 하나, 둘 개선해 나아가다 보면 어느샌가 목표에 도달해 있지 않을까 싶어요.
References
개발자가 갖추어야 할 9가지 기술
비대면 시대, 일하는 방식의 변화와 협업툴

커뮤니케이션 방식과 PR 템플릿 개선해보기

댓글