업무를 보면서 생긴 문제점을 반복하지 않으려 기록하는 글
1년 2개월동안 구매대행 서비스 회사(배송, 창고, 포장같은 것을 다루는 풀필먼트같은..?)에서 백엔드 파트 개발자로 일을 하면서 "불안하다"라는 감정을 정말 많이 느꼈습니다.
워낙 한명 당 커버해야하는 부분이 많아서 어쩔 수 없는 부분이기도 합니다.
여기서 나온 문제들을 모두 회고하고 학습해서 개선하는 것이 내가 희망하는 규모, 포지션에서 가서도 도움이 될지는 장담할 수 없습니다.
집중적으로 내가 원하는 곳이 원하는 기술만 보강을 하려고 합니다.
일단 제가 생각하는 이전 회사의 기술적 문제에 대하여 나열하고자 합니다.
내가 생각한 힘들었던 점과 개선 방향
1. DB Schema, 구조가 한 번 정의되고 운영이 되면 회귀하기가 정말 어렵다.
- 인원이 적고 저연차가 많아 시간을 많이 준다고(주지도 않음) 해도 좋은 data modeling을 하기가 어렵다.
- 잘못된 구조 설계를 할 수 밖에 없다고 생각하고 운영중인 서비스에서 구조 마이그레이션을 하는 방법을 터득하자.
2. 테스트에 사용하는 Database와 운영 Database의 상태가 다르다.
- 컬럼추가로 Production Server Database 구조가 달라지면서 시간이 지나고 결국 Test Server Database와 구조가 달라진다.
- 어떻게 상태를 동일하게 유지하는지 찾아보자.
+ Batch Program을 주기적으로 돌리기
3. 모니터링 시스템 구축 ( APM, 핀포인트 )
- 누가 언제 어떤 요청을 하고 어떤 응답을 받고 어떤 예외가 생겼는지 어떤 데이터가 수정되었는지 추적하기가 어려웠습니다. cloudWatch를 사용하고 로깅도 해서 추적을 하긴 하지만 비효율적이여서 정신적 스트레스가 컸습니다.
- 좋은 로그 포맷과 예외 정의 노하우 알아보기
4. 테스트 코드 부재로 인한 코드 리팩토링 불가
- 리팩토링의 근거가 없어 코드 개선이 매우 힘들다.
- 다음 회사에서는 생산성 향상에 직접적인 도움이 될 수 있을만큼 테스트 코드 작성을 연습하자.
5. 가상화
- Window, Ubuntu, MacOS, Java 8 ~ 11, Kotlin, Legacy Spring ~ Spring Boot같이 여러 환경이 복합적으로 사용하여 세팅이 피곤합니다.
Docker를 사용해서 동일한 환경에서 할 수 있도록 합니다.
어떻게 개선해야 할까?
- 안정적인 서비스 운영을 위해 필요한 Infra 요소를 찾아보기
- 운영중인 서비스의 스키마 마이그레이션을 연습하고 학습하기
- DB 설계 서적 한 번 독파
즐겁게 개발하기