R&R은 Role and Responsibility의 약자로, 직무와 책임을 의미한다.
서버개발 Unit의 R&R은 다음과 같이 구분된다.
- 서버개발 엔지니어
- 서버 시스템의 설계, 개발, 운영을 담당합니다.
- 서버 시스템의 성능, 보안, 안정성을 확보합니다.
- 서버 시스템의 신규 기능 개발 및 유지 보수를 수행합니다.
실제 개발 업무는 회사마다 상이하다.
예를 들면 웹 백엔드인 경우 Service API, CMS API, DataBase, BackEnd 개발이 있다.
Service API는 서비스의 기능 및 데이터를 제공하는 기능 개발이며,
CMS API는 서비스에 사용되는 콘텐츠를 관리하기 위한 admin 전용 API 개발이다.
이에 따른 Database 역량이 요구되며, BackEnd 개발은 서버 아키텍처, 테스트, 배치, 외부 모듈 연동 등 포괄적인 개념이다.
만약 서비스의 도메인이 여러 개인 경우 이를 로테이션으로 개발하는 경우가 있다. 이는 하나의 도메인에 하나의 개발자가 담당하게 되면 인수인계 관련해서 문제가 발생할 수 있고 편파적인 시야를 갖기 때문이다.
이렇게 로테이션으로 다양한 도메인을 경험하기 위해서는 적절한 인수인계 문서 작성이 필수이다. 코드 또한 마찬가지이다.
팀원 수준을 고려한 높은 가독성을 갖는 코드, 그러면서 성능은 챙기고 멋진 클린 코드를 작성해야 한다.
인수인계 문서의 양식은 정해지지 않았지만 음.. 고민해 보자. 인수인계에 어떠한 내용이 있는 것이 좋을까?
내가 담당했던 모든 업무의 매뉴얼을 작성하는 것.
다만 개발적인 부분에 있어 큰 결정이 내린 경우에는 기술에 대한 이야기를 첨부하고 그렇지 않다면 제외한다.
해당 도메인에서 큰 이슈가 발생했다면 해당 이슈의 원천과 해결 방법을 알려주면 추후 도움이 될 수도 있을 것 같다.
작성된 인수인계 문서는 계약서처럼 나 한 장, 도메인을 맡은 개발자 한 장을 갖는다.
이후 질문이나 보완이 필요한 경우 이를 지속적으로 채운다. 이를 위해선 공유 문서 플랫폼을 이용하면 더 좋을 듯하다.
나는 이번에 노션을 통해 공유하였다. 노션으로 공유하니. 실제 답글을 남겨 추가적인 부분을 보완하거나 질문에 대한 부분을 더 추가하는 등 매우 괜찮은 방법이라고 생각이 되었다.
또한 답글로 못 다했던 이야기를 남기면 그 사람과의 커넥션이 지속되는 느낌을 받기도 한다. 난 이렇게 인수인계를 마무리했다.
아 그래서 R&R의 뜻은 Role and Responsibility이다.
댓글