19 07 오픈빌더회고 당연의 오류

목차

• 당연의 오류
• 당연의 오류 첫 번째! 업무 처리 방식
• 당연의 오류 두 번째! 설계를 모두 이해 했을 것이다.
• 결국 커뮤니케이션을 많이 해야 겠다.

당연의 오류

최근에 프런트 개발을 같이 하는 협업자들과 일하며 당연시 생각하는 게 당연하지 않다는 것을 느끼게 되었다. 프런트 개발자는 나 포함 4명이다. 여기서 내 역할은 일정관리 및 설계를 담당하고 있다.

당연의 오류를 느낀 것은 두 가지가 있다. 두 가지는 업무 처리 방식과 설계를 모두 이해했을 거라는 기대이다. 하지만 이 두 가지가 동료들의 문제가 아니다. 이 두 가지는 내가 당연시 생각했던 부분이고, 당연히 "이렇게 하겠지"라는 생각을 가진 것이 오류였다.

내 생각과 동료의 생각이 어떻게 달랐는 지 회고해 보겠다.

당연의 오류 첫 번째! 업무 처리 방식

프런트 업무를 진행 전 선작업 필요한 작업이 퍼블리싱과 백엔드 API이다. 하지만 스프린트가 시작된 뒤 몇일 뒤에 전달받을 때가 있다. 이 상황에서 프런트 업무를 한다면 어떤 선택을 할까?

1. 퍼블리싱과 백엔드 API가 전달 되기전에 인터페이스 및 프로토타이핑을 한다.
2. 계속적으로 퍼블리싱 임시 파일을 받아와 프런트 작업하고, 백엔드 API 전체가 완성안되도 하나씩 확인하며 벡엔드 담당자에게 동작오류를 제보한다.

나는 1번으로 작업한다. 하지만 동료중에는 2번을 선택하는 동료가 있었다. 어떤게 틀렸고 어떤게 정답이라고 할 수 없다. 저마다 장점이 있기 때문이다.

일단 2번으로 작업하는 동료들의 의견은 이렇다.

1. 이번 스프린트때 작업해야 하는 테스크인데, 시간이 지나도 퍼블리싱과 백엔드 API가 전달안되서 할 일이 없다.
2. 그래서 퍼블리싱 담당자가 작업을 완료하지 않아도 해당 브랜치의 작업 내용을 가져온다.
3. 백엔드 API 일부만 받아도 그 일부가 동작이 안되면 빠르게 피드백을 주는 게 좋다고 본다.

내가 1번으로 작업하는 이유는 이렇다.

1. 퍼블리싱이 없으면 정상적인 UI를 표시할 수 없다.
2. 백엔드 API가 없으면 데이터를 CRUD 할 수 없다.
3. 그래서 View와 연동할 인터페이스와 백엔드 API의 목업을 만들어 작업한다.
4. 이후는 다른 업무를 진행한다. 다른 업무는 리팩토링 또는 부서업무를 한다.

나는 퍼블리싱이 완료됬을 때 적용한다. 그 이유는 중간에 디자인부서에서 퍼블리싱에 반영된 디자인 반영을 리뷰하고, 그 때 미반영 부분에 대한 수정 사항이 발생하기 때문이다. 완료가 되기전에 반영하는 것은 재수정이 발생할 우려가 있다.

백엔드 API가 완료될 때 브라우저에서 요청을 날려 확인을 한다. 비정상 동작을 하거나 문의가 필요할 때 백엔드 개발자에게 요청을 한다. 그 이유는 API 개발 도중에 API가 얼마든지 수정될 수 있고, API 개발중에 제보를 하게 되면 일정지연을 가져온다. 한 스탭 개발이 완료되기 전에 사소한 것들에 대한 수정 요청을 하게 되면 컨텍스트 채인지 비용이 발생하기 때문에 되도록 중간에 요청하지 않는 편이다.

시간을 효율적으로 사용하여 생산력을 높이는 게 중요하다고 생각한다. 그리고 개발자 한명 한명의 비용은 굉장히 비싸다고 생각한다. 그렇기 때문에 시간을 들였을 때 그 만큼의 가치를 발생시킬 수 있는 업무를 조절하며 모든 업무를 적시에 마칠 수 있는 게 좋은 방향이라고 생각한다.

당연의 오류 두 번째! 설계를 모두 이해 했을 것이다.

여기서 말하는 설계는 폴더별로 역할 부여하고 구조를 설계하는 것과 내부 상세한 코드의 작성 방법을 설계하는 것을 말한다.

구체적인 내용은 이렇다.

프로젝트에서 Angular를 사용하는 데, Angular의 스타일 가이드를 일부 따르고 있다. Angular는 NgModule로 세 가지(CoreModule, SharedModule, FeatureModule)로 역할을 구분한다. 추가적으로 프로젝트에서는 Angular의 Service에 부여할 수 있는 역할을 구체적으로 나눠서 작성한다. Service는 Helper, API, Store Manager로 세 가지를 구분한다. 내부적으로 비동기는 RxJs의 Observable을 사용하지 않고 Promise로 정의한다.

이런 내용들을 설계규칙으로 가지고 있다.

설계 내용이 정해질 때 마다 회의를 통해 전달하고 있다. 하지만 코드 리뷰를 할 때 잘 지켜지지 않는 경우를 많이 봤다. 코드 리뷰때 설계가 지켜지지 않는 것을 보면 서운(?)하다.

하지만 지금 생각해보면 업무를 진행하면서 "설계를 이해하고 반영하리"라는 기대는 무리한 기대일 것이다. 설계를 적응할 시간이 필요하다고 생각한다.

결국 커뮤니케이션을 많이 해야겠다.

업무 방식 그리고 설계에 적응하는 것은 커뮤니케이션 부족이라고 볼 수 있다. 업무 방식에 대한 당연히 생각하여 관련된 이야기를 못했다. 그리고 설계에 대한 적응 시간도 필요해 보인다.