원티드x위코드 프리온보딩 2주차 2차 과제 후기

과제 내용

과제 Repository

https://github.com/wanted-InfinityLoop/8percent-InfinityLoop

내용

이번 과제는 8persent라는 P2P서비스를 제공하는 과제의 기업으로, 해당 기업의 비지니스 로직 전체를 구현하는 것이 아닌 투자 로직 중 입금, 출금, 조회 기능만 구현하였다.

과제에 대한 세부 사항

1. 전체 4명에서 모든 API를 구현하였고, 팀원들 3분이 입금, 출금, 조회 기능을 구현하였고 나 혼자 회원 가입, 로그인, 로그인 기능을 구현하였다.
2. 전체 기능을 구현하고 나서, 기업 과제 중 1억건 이상의 거래 내역을 생겼을 때를 고려해서 구현하라, 라는 부분을 함께 풀어보려고 하였으나 여의치 않았다.
3. 도커로 배포하려고 하였으나 2번 사항을 놓고 구현을 하다보니 시간이 부족해 EC2 환경에서만 배포가 되었다.

배운 점

transactions 처리

1. 트랜잭션(Transaction)이란, 데이터베이스의 상태를 변화시키는 작업의 단위이다. 트랜잭션에 존재하는 중간 과정들이 모두 예외(모든 과정 실행 중에 Error 없이)없이 실행이 되면, 데이터베이스의 상태가 변한다. 그 과중 중에 하나라도 예외가 발생하면 실행 중인 작업 단위의 모든 과정이 Rollback 된다.
2. 트랜잭션을 사용하는 이유는 데이터의 원자성, 일관성, 고립성, 지속성을 보장하게 위해 사용된다.
3. 사용 방법에는 크게 3가지가 있다. 데코레이터를 활용하는 방법 하나, with 명령어를 사용하는 방법 하나, 그리고 savepoint를 직접 지정해 주는 방법 하나. 이번 프로젝트 때는 작업 단위 앞에 with.transaction.atomic()을 붙여주는 방법을 사용하였다. 사용 방법은 간단하나 왜 사용하는지에 대한 이해가 중요한 것 같다.
4. 이번 프로젝트 땐 user 테이블에 one to one 관계로 묶여 있는 deposit 테이블에 데이터가 따로 CRUD 되는 것을 막기 위해 사용했다. 만약, 회원 가입을 하면서 1 유저 당 1 계좌를 가져야 하는 상황에서, 유저 가입은 되었으나 모종의 문제가 발생하여 코드가 deposit까지 도달하지 못했다고 가정해보자. 그렇다면 1 유저는 데이터에 생성이 되었으나 1 계좌(in deposit table)은 생성되지 않을 수 있지 않겠는가? 이런 경우를 막기 위해 사용했다.

one to one field

참고 : https://whatisthenext.tistory.com/118
참고 : https://brunch.co.kr/@ddangdol/10

uuid

참고 : https://code.tutsplus.com/ko/tutorials/quick-tip-how-to-create-a-universally-unique-identifier-in-python--cms-25927 이 파트에 대한 전반적인 내용을 참고하였습니다.

1. UUID(Universal Unique Identifier)란, 기본적으로 어떤 객체(데이터)를 고유하게 식별하는 데 사용되는 16바이트 길이의 숫자이다. 고유성을 갖기 위해 장비의 네트워크 주소, 타임스탬프, 무작위로 생성된 요소들로 구성된다.
2. in python

```python
>>> print(uuid.uuid4())
40886a04-48ac-43a0-a327-f68a13f5c820
```

3. uuid1 ~ uuid4까지가 대체적으로 많이 사용되는 것 같다.

Bearer 토큰

참고 : https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=jmjm223&logNo=221483149513

1. Bearer Token은 일종의 token 포맷이다.
2. 클라이언트 사이드에서 REST API 호출 시 Bearer Token을 포함하여 서버로 request를 보내고, 서버는 연동된 DB를 조회하여 클라이언트가 보낸 토큰이 vaild한 토큰인지 확인 후 서비스를 제공하거나, invalid token 정도의 response를 보낼 수 있으면 된다.
3. 이번 구현 과제에서는 Bearer Token을 활용하기로 하였고, postman 사용 시 request.haeder에 Authorization의 키 값을 통해 토큰을 확인할 수 있도록 로직을 작성했다. 즉, {"Authorization" : Bearer ——token——} 이렇게 작성을 하였다.

느낀 점

1. 이번 프로젝트의 진행 과정은 상당히 깔끔하였다. 적당한 시간 내에 테스트 코드, 배포까지 완료를 하였으니 말이다. 하지만 추가 구현 사항에 대한 토론이나 시도는 해보지 못했다. 역량 부족으로 손도 대보지 못하고 끝난 느낌이어서, 이 부분에 대해서는 많이 아쉬울 따름이다.
2. 아주 아주 중요한 git rebase에 대한 이해! 지난 번 프로젝트 까지는 어느 정도 팀원 분들의 도움을 받으며 git을 사용했었다면 이번 프로젝트 때는 나 스스로 주도적으로 git을 사용해보았다. 사실 git을 사용하며 가장 불안한 부분은 "내 코드가 내 잘못으로 main에 merge가 되어 버리면.." 이라는 불안감?일 것 같은데 사실 branch를 나눠 rebase로 작업하면 그럴만한 위험, 부담도 적어지는 것이었다. 잘못된 사항이 있으면 명령어를 검색해 시도해보고 고치고.. 이런 식으로 작업을 하다보니 막연한 불안감은 사라졌다. 아주 큰 수확이라고 생각한다.

전체 정리

지금까지 달려온 만큼 2주의 시간이 남았다. 프로젝트 때 소요되는 의사 결정 시간도 줄어들고 있다. 다음