[위코드 X 원티드] 프리온보딩 백엔드 - 네 번째 기업과제 후기

8퍼센트 기업과제

입금, 출금, 거래내역 조회 api를 만드는 기업과제였다.
과제를 보자마자 다른 api만드는 것 보단 더 안정성에 힘써야 했다 생각했다.
이를테면 거래내역과 계좌의 잔액이 다른 데이터 정합성 문제가 일어나면 정말 큰 문제라 생각했다.

즉, '입금을 한다'의 하나의 요청에 대해

1. 계좌의 잔액 변경
2. 입금 거래내역 생성

두개의 각각의 결과가 DB내에 동일하게 존재 하여야한다.

그렇기 위해선 트랜잭션을 생각할 수밖에 없었다.

트랜잭션은 트랜잭션 내 하나의 쿼리가 오류가 나면 모두다 롤백시킨다. 즉, 원자성의 특징을 띈다.

그런데 더 나아가 우린 '동시성'에 대해서도 깊게 고민했다.
찾아보니 트랜잭션에 고립레벨을 줄 수가 있는 걸 알게 되었다.

DBMS마다 기본적으로 트랜잭션 고립레벨이 다르다는 것도..

아무튼 이런저런 깊은 고민을 하게 하는 과제였다.

기능 분할

팀원들과 기능을 분할해야했다. 그전에 먼저 서로 협업을 위해 맞춰야 할게 여러개 있었다.

1. 시나리오 설계
2. DB설계
3. typeorm 엔티티의 생성
4. 시드 데이터 생성
5. eslint, prettier
6. 코드 컨밴션(커밋 메시지, 브랜치 전략등등 )

그레야 이제 팀원간 입금, 출금, 거래내역 api를 분할하여 만들 수 있다 생각했기 때문이다.

위 사항들이 맞춰줘야 협업 시, 충돌에 쉽게 대응할 수 있다 생각했다.

이렇게 공통 사항을 서로 회의하고 각자 개발하였다. 그러나 기능들을 어떻게 분배해야할지 잘 모르겠다.
어떻게 보면 너무 적은 기능이라 생각했기 때문이다.

이를테면, 출금, 입금, 송금을 세명이서 각각 나누어 개발한다 치자.
출금 - 송금, 입금 - 송금은 되게 겹치는 코드도 많을 것이고 그게 효율적인가?라는 의문이 들게 만든다.
어떻게 보면 한사람이 이 기능들을 하는 것이 더 효율적이지 않을까?라는 생각이 들기도 하였다..

우리는 후자를 선택했다.

그렇기에 실제 기능을 나는 개발하지 않았다.

그러나, 우린 제출 당일이 되어서야 기능 개발을 완료 하였다.

즉, 효율적이라 생각한 기능 역할 분배가 효율적이지 않았던 것이다.

그러나 이게 데드라인이 짧아 시간 자체가 모자라서 그런건지, 아니면 혼자서 비슷한 기능들을 처리했기에 시간이 부족한건지 모르겠다.

그래서 난, 겹치는 기능이라도 일단 팀원과 동등하게 분배한다음 작업을 하자!라는 생각을 했다. 왜냐면 이렇게는 시도해 본적이 없기 때문이다. 그렇기에 다음에는 일단 겹치는 기능이라도 동등하게 분배한다음 작업을 시도해볼 예정이다.

우리는 모르기에 직접 해보는 수밖에없다!! 다음엔 다른 방법으로 기능 개발을 분배하여보자..!!!

쉽지 않은 협업

사실 이틀 반이라는 너무 짧은 기간이기에 개발에 착수하기 전 소통할 시간이 부족하다 생각했다.

나는 A라는 시나리오를 생각하고, 그렇기에 테이블 설계를 이런식으로 했다 생각했는데 다른 팀원은 B라는 시나리오를 생각하기도 했다.

이런일이 일어나면 서로 개발한 것들을 다시 해야하기에 이런점이 힘들었다.

또한, prettier와 같은 포매팅이 각각 모두 다르기에 머지할때 충돌이 너무 잦았다.
누구는 .prettierrc라는 설정파일을 토대로 포맷팅이 되고, 어떤 이는 에디터에서 설정한 포메터로 포멧팅이 되니 머지할 때 충돌이 일어나기 일쑤였다.

또한, 제출해야하는 당일이 되도 개발이 끝나지 않은 문제가 있었다.
우리가 설렁설렁 하진 않았는데 시간 분배를 잘 하지 못했던 것 같다. 초반의 소통도 당연히 중요하지만 데드라인이 짧게 정해져 있기에 시간 분배를 잘해야 한다 생각한다. 설계는 A시간까지, 개발은 B시간 까지, 등등.. 좀더 시간적 여유를 고려하여 시간적 분배를 해야한다고 느꼈다.

알았으니 이제 잘하면 되지!

많은 걸 고민해 좋기도 했지만 많은 어려움을 겪은 프로젝트였다.
이번에 시행착오를 느꼈으니 좀더 잘하면 된다!

• prettier, eslint 등 포멧팅과, 코드컨벤션을 미리 맞추자. github action을 이용해서라도 서로간의 코드 컨벤션을 맞추자
• 시간 분배를 잘하자. 언제까진 회의, 언제까진 개발, 언제까진 테스트 코드 작성, 언제까진 배포등 처음에 시간분배를 잘해야 겠다 생각했다.
• 이해가 안되면 바로바로 질문!
  • 어떠한 시나리오에 대해서 서로 이해가 잘되지 않으면 서로간 바로 질문을 하거나, 애매하면 확인을 받자!, 잘못된 시나리오로 계속 개발하다간 모두 초기화 해야 할수도 있기에..

결론

• 트랜잭션, 동시성에 대해 고민할수 있는 좋은 기업과제였다.
• 어떤 방식으로 역할을 분배해야 좋은 협업이 될수있을까?란 고민을 많이 하게된 프로젝트였다.