Use case 이해의 중요성

지난 일,이주간 많은 일이 있었지만 그중에 본인이 실수를 저지를 것이 있었는데 바로 Use case를 확실히 인지 못하고 개발에 착수 했다는 것이다. 

 

가령 개발 프로세스와 아래와 비슷하다면

 

 

본인이 받은 개발 목표는 Validation Service에서 1.New Data와 5.Result Data 의 데이터의 새로운 필드 값을 설정해서 6.Validated result data 로 보내 DB에 저장하는것이 목표이다. 이때 Validation Service는 AMQ로 데이터를 받는다.

 

그러나 문제는 1 -> 2 -> 3 -> 4 -> 5 -> 6 의 플로우 Use case를 정확하게 짚지않고 개발 티켓에 적힌 것 (1.New Data에서 추가 필드) 을 토대로  단순히 Validation Service안에서만 생각을 하여 들어오는 Core Service에서 오는 인풋을 예상하고 개발에 착수해버렸다. 어쩌면 처음에 API request 메시지를 AMQ메시지로 오해해서 생긴 이유인것 같기도 하다.

 

결국 본인은 5. Result data의 추가 데이터가 Core service에서도 똑같이, 혹은 재연산되어 보내는 것으로 착각하고 개발을 진행해 버렸는데 문제는 해당 데이터는 API(1.New Data)에서만 제공되고 DynamoDB에 저장된 이후로 다른 Service가 사용 하지 않고 데이터를 보내지도 않는다는 것이다.

 

한마디로 Core Service가 우리가 필요한 추가 필드를 보내지 않고 5.Result data 프로세싱을 시작할 때 Validation Service안에서 DB를 탐색해 처음에 보낸 추가 필드의 데이터를 재 사용 해야한 다는 것이였다.

 

문제는 프로덕트 배포 예정일이 몇일 안남았고 Validation Service의 배포는 매우 어려운 상황인데다 이미 본인의 개발완료된 코드가 해당 팀의 테스팅에 들어간 상태였다. 만약 이 문제를 바로 잡자고 하면 프로덕트 배포가 밀리는 상황이였다.

 

결국 Core Service의 개발/테스팅 환경의 릴리즈가 아직 진행이 되기 하루 전이여서 곧바로 선임개발자가 3.Stream data에서 추가 데이터를 Core Service에서 받아서 나중에 Validation Service로 보낼 때 같이 보내는 방식으로 변경하여 위기를 모면했다. 그러나 이후 대판 깨졌다... Use case 이해를 못하면 어떻게 하냐고 말이다.

 

실수를 인정한다. 분명 본인이 확실히 하고자 했으면 다른 개발팀이든 선임개발자한테 물어봐서 확인을 했어야 했다. 그래도 다른 대안이 있어서 다행이지 고객에게 신뢰를 잃어 엄청난 손실을 안겼을 뻔한 일화였다. 이후로 모든 개발 티켓에는 Use case를 재 확인 하는 프로세스가 생겼고 end-to-end 플로우를 제대로 작성해야 개발이 착수 가능하게끔 정책이 바뀌었다. 

 

본인의 개발 환경에 경각심이 생기게 된 계기였기도 하고 문제가 많았던 개발 티켓도 조금 더 다듬어질 수 있게 된 것 같다.