업무 규칙

회사에서 개발을 하다보면 혼자가 아닌 여럿이서 하기 마련이다. 여럿이 일을 하는 조직에서 내가 리딩을 맡았을때 다른 분들에게 자주 이야기하는 것들을 정리했다.
쓰고보니 개발자 규칙이라기보다 회사원 규칙이라고 하는게 더 어울려보이긴한다.

내 한주는 5일이 아닌 4일이다.

• 내가 아는 많은 회사, 그리고 내가 다녀본 회사들은 월요일에서 금요일까지 주5일 근무제를 한다. 월요일에서 금요일까지 5일중 온전히 코드를 작성할 수 있는 시간은 정말 많아야 4일이다. 보통 최소 하루는 회의 및 문서화 등 커뮤니케이션을 하는데 시간이 사용된다. 가능하면 한주의 리소스 계획을 할땐, 내 리소스를 최대 나흘로 계획하기를 권한다. 물론 이 나흘도 상당히 빡빡한 시간이며 부족한 경우가 태반이다.
• 혹여나 컴 할 일이 없어서 하루가 남는다면 그땐 리팩토링 같은 욕심나던 엔지니어링 업무를 하면 된다. 문서화에는 다른 이의 코드 리뷰도 포함된다. 5일을 온전히 코드를 작성하는데 다 쓸 수 있다고 계획하면 계속 쌓여만 가는 지라 티켓을 볼 수 있다.

코드 리뷰는 코드만 보는 작업이 아니다.

• 사람마다 코드 리뷰에 대해 기대하는 것들이 다 다를것이다. 코드 리뷰에 대해 내가 기대하는 효과는 다음과 같다.
  1. 기능 및 정책에 대한 다른 개발자로의 전파.
     • 지속가능한 제품을 만들기 위해서는 하나의 기능에 대해서 여러 사람이 파악하고 있을수록 좋다.
     • 따라서 코드 리뷰를 할땐 코드 확인보다 기능 및 정책 파악을 먼저 봐야한다. 목적을 알아야 코드가 그에 맞게 구현됐는지 파악할 수 있기때문이다. 목적에 맞게 코드가 구현되었는지 확인 하고, 코드 자체에 대한 개선을 확인해주면 좋다.
  2. 코드 구조 유지
     • layer마다 어떤 특성을 가져야 할지, class 마다 어떤 속성을 가져야 할지등 전체적인 코드 구조에 대해 계속 유지시켜나간다.
     • 세부 구현인 코드는 바꾸기 쉽지만 구조는 한번 엇나가기 시작하면 고치기어렵다.

기능을 추가할땐 항상 전체 사용 시나리오를 확인해라.

• 기능을 추가할때는 항상 두가지 관점에서 바라봐야 한다. 지금 현재 내가 만드는 기능이 요건에 맞게 잘 구현되는지, 그리고 이 기능이 추가되었을때 전체 서비스 관점에서 잘 돌아가고 다른 기능과 충돌이 없을지를 확인해야 한다.
  • 따라서 추가하는 부분뿐 아니라 전체 흐름에 대해서도 시나리오를 다시 한번 점검하는게 좋다.
  • 기능 추가할때 해당 기능을 넣은 부분이 문제 없을지 확인이 되었다면 전체적인 흐름에서도 문제가 없을지 확인해야 한다.

일감은 최대한 작고 단순하게 한다.

• 일감(티켓)을 만들때는 에픽이 아니라면 한 티켓의 일정 최대 값은 2주를 넘기지 말아야한다. 길게 늘어진 일감은 본인의 능률도 깎아먹을 뿐더러, 일정이 큰만큼 덩치가 비대해져 장애를 일으키기 쉽다. 티켓도 그렇고 배포도 항상 가장 작은 단위로, 자주 하는게 좋다.

공유는 항상 중요하다.

• 내가 무엇을 하고 있고 어떤 것을 하려는지 팀내에 공유가 안되고 혼자 진행한다면 그 즉시 멈춰야 한다. 내가 하고 있는 일이 팀의 나아가고자 하는 방향이 일치하는지 혼자 결정하지 말고 다른 사람과 항상 얼라인을 맞춰야 한다.

장애도 설계가 필요하다.

• 장애 알람이 울리면 항상 하던 업무를 멈추고 즉시 대응해야한다. 이를 위해선 장애 알람에도 설계가 필요하다. 장애 알람을 발생시킬때 이게 과연 즉시 대응을 해야하고 개발자들의 업무를 중단시키는 정도의 내용일지 고민이 필요하다. 그렇다고 무조건 장애 알람을 보내지 말아야 한다는 것은 아니다.
• 장애가 발생한다고 해서 즉시 해결해야하는 것은 아니다. 장애 알림이오면 해당 장애가 무엇인지, 서비스에 어떤 영향을 끼치는지 파악하고 여기에 대해서 계획을 세워야 한다. 계획에 따라 바로 핫픽스할지 아니면 다가오는 일정에 따라 수정할지 결정해야 한다.
  • 물론 되도록이면 가능한 빠르게 해결하는게 좋긴하다.

기능을 추가할때는 목적과 수단을 구분해야 한다.

• 이 기능을 추가하는 목적에 대해 확실히 파악후 이를 실현하기 위한 여러 수단을 고민해봐야 한다. 그리고 각 수단마다 장단점을 비교해가며 선택해야 한다. 구현 수단에 대해 하나 떠올렸다고 고민없이 개발을 시작해서는 안된다.
• 이를 위해선 항상 기능 추가를 요청한 사람과 이야기를 많이 해야한다. 왜 필요한지, 내가 생각하고 이해한 것과 요청자가 생각한 것이 일치하는지 확인이 필요하다.

회의는 항상 wrap up과 함께 끝나야한다.

• 시간보다 일찍 논의를 마무리하고, 항상 마무리된 논의에 대해 간단하게 문서로 정리해서 서로 이해한바가 맞는지 확인해야한다.
  • 나중에 공유해주는 문서는 사람들이 잘 보지 않는다.
  • 문서에는 오늘 회의에서 결정한 내용, 그리고 Action Item과 실행 주체가 명확하게 나와야 한다.