위코드 프리온보딩 백엔드 과정 - 회고 2주차 2회 (8퍼센트)

어찌어찌 하다보니 이제 절반이 지나가고있다. 좀 더 힘내자.

 

개발 요구사항

📝 “계좌 거래 API” 구현

 

• 계좌의 잔액을 별도로 관리해야 하며, 계좌의 잔액과 거래내역의 잔액의 무결성의 보장
• DB를 설계 할때 각 칼럼의 타입과 제약

 

1) 거래내역 조회 API

• 계좌의 소유주만 요청
• 거래일시, 출금, 입금 필터링.
• Pagination
• 거래내역이 1억건을 넘어갈 때에 대한 고려

2) 입출금 API

• 계좌의 소유주만 요청
• 계좌의 잔액내에서만 출금가능

개발과정

• 이번 과제는 API가 매우 적은게 특징이었다. 조건을 보니 기업의 특성에 맞게 트랜잭션과 성능에 중점을 두는 걸로 보였다.
• 쿼리 최적화때문에 가장 어려워보이는 거래내역조회의 경우는 쿼리튜닝에 경험이 있는 팀원분이 하기로 하셨고 나는 입출금api를 담당했다. 사실 이번엔 전체적으로 익숙하고 작은 규모의 과제였기에 분석-설계-개발-배포의 라이프사이클에 익숙해지는 과정이었다. 
•  팀원분과의 얘기를 통해 쿼리에 대해 많은 것을 알 수 있었다. Prepared statements가 SQL Injection의 예방 뿐만아니라 쿼리 캐싱의 기능도 한다는 것. where 조건문의 경우 DBMS에서 자체적으로 execution plan을 최적화하는 과정을 거치기 때문에 where문에 적은 순서대로 expression을 평가하지 않아 오히려 느려질 수 있다는 것. 이는 컴파일러 최적화로 비유하자면 lazy Evaluation이 제대로 작동하지 않는다는 의미이다. 
   이를 해결하는 방법으로 subquery를 이용한다 것도 알 수 있었다. subquery보다는 하나의 쿼리가 보통 더 낫지 않나? 라는 생각이었는데 이 얘기를 듣고 잘못생각했다는 것을 깨달았다.

끝내며

아무래도 이번엔 과제의 크기가 작았기때문에 좀 더 여유롭게 쿼리튜닝 같은 지식을 배우며 작업할 수 있었다. 매주 2번씩 하는 과제이지만 그럼에도 배워가는 것이 있기에 즐거운 경험이 되는 것 같다.