10주차는 7회차 마지막 멘토링 때 나눴던 내용을 가볍게 풀어볼까 한다.
최종 발표 준비보다는, 프로젝트를 진행하면서 가장 많이 막혔고 고민했던 지점들을 중심으로 멘토님과 이야기를 나누며 정리하는 시간이었다.
사실 프로젝트를 진행하면서 어려웠던 점, 새로 배운 점 등이 매우 많은데
하나하나 다 깊게 공부하면서 글로 정리하고 싶지만 개발 마무리가 시급한 이유로
이번 글에서는 그 내용을 preview 느낌으로 정말 간단하게만 정리해두려고 한다.
1. 외부 API 연동, 특히 결제 API
결제 API처럼 서버에서 또 다른 외부 서버를 호출하는 구조는 생각보다 고려할 게 많았다.
• 네트워크 실패
• 외부 API의 4xx / 5xx 응답
• 우리가 컨트롤할 수 없는 영역특히 결제는 한 번 잘못되면 끝인 영역이라,
요청 → 검증 → 임시 저장 → 최종 확정 같은 단계적 흐름이 왜 필요한지도 다시 한 번 짚어볼 수 있었다.
⸻
2. 돈과 관련된 기능은 왜 더 조심해야 할까?
멘토링에서 가장 강조된 부분 중 하나는
결제는 절대 단순 CRUD로 보면 안 된다는 점이었다.
• 중복 결제 방지
• 검증되지 않은 상태에서의 상태 변경
• 롤백 불가능한 흐름이런 이유로 결제 도메인에서는
임시 상태 저장, 검증 로직, 상태 전이 관리가 필수적이라는 걸 다시 한 번 인지하게 되었다.
⸻
3. DB Lock, 트랜잭션 격리 수준
결제와 함께 자연스럽게 DB 이야기로 이어졌다.
• 동시에 요청이 들어오면?
• 같은 데이터를 여러 트랜잭션이 건드리면?
• Lock은 언제 잡히고 언제 풀리는지?결제 기능을 구현하면서 비관적 Lock을 사용해봤는데, 다양한 DB의 격리 수준, Lock 개념에 대해 이해하는 시간이 더 필요할 것 같다고 느꼈다.
⸻
4. Flyway를 쓰면서 겪은 시행착오
Flyway도 이번 프로젝트에서 처음 사용해봤다. 사실 들어본 것도 처음이다.ㅋ
• DDL / DML 마이그레이션 개념을 명확히 이해하지 못한 상태에서 시작
• 이미 적용된 마이그레이션을 수정하면서 겪은 삽질
• “왜 이게 안 되지?”의 반복어찌저찌 사용은 하고 있지만.. 사실 Flyway가 정말 필요한 경우 또는 잘 쓰이는 경우에 대해서는 계속 궁금할 뿐 체감하지 못하고 있었다. DB 스키마 변경 이력을 관리한다는 게 어떤 의미인지를 뒤늦게 체감했다.
⸻
5. 왜 멀티 모듈인가?
우리 프로젝트는 MSA를 적용하고 있다. 정확히는 멀티 모듈인데, "왜 멀티 모듈인가?"에 대해 근본적인 생각을 해봤다.
• 공통에 대한 처리가 효율적이다
• 협업에 좋은 느낌이런 구조 관련해서는 정말 다양한 방식이 있고 말도 많지만 팀원들과는 이 정도 이유가 있지 않을까 얘기했다.
⸻
6. 메시지 기반 아키텍처와 Sync 테이블
우리는 Kafka 대신 AWS SNS, SQS를 사용했는데, 메시지 기반 통신 또한 완전히 처음 접한 개념이었기에 쉽진 않았지만 솔직히 꽤 흥미로웠던 것 같다.
• 왜 굳이 이벤트로?
• 왜 바로 API 호출이 아닌지?
• Sync 테이블은 왜 필요한지?MSA에서 데이터 정합성을 맞추는 현실적인 방법이라는 관점으로 우리는 이런 방식을 택했고, 멘토님께서도 최종 발표 때 이 부분을 조금 강조해도 되겠다고 말씀하셨다.
⸻
7. 프론트엔드 경험이 있었던 게 도움이 된 부분
프론트를 해왔던 입장에서 백엔드를 해보니
• 데이터 흐름을 어떻게 설계하면 프론트가 편한지
• 어떤 응답 구조가 사용하기 좋은지
• 잘 짜인 API 인터페이스는 어떤 느낌인지를 자연스럽게 고려하게 되었다. 냉정하게 아직 찍먹 수준이지만 풀스택이 되어가는 기분을 느낄 수 있었다ㅎ
마무리
이번 멘토링은
“이걸 잘했냐 못했냐”보다는
👉 왜 어렵게 느껴졌는지
👉 내가 어디까지 이해하고 있었는지
를 정리하는 시간에 가까웠다.
프로젝트를 하면서 마주친 대부분의 어려움은
경험 부족 + 개념 이해 부족에서 나왔다는 것도 솔직하게 인정하게 되었다.
각 주제들은 이후에 하나씩 따로 더 깊게 정리해볼 예정이다.
이번 글은 그 출발점 정도로 남겨둔다.
추후 올라오는 글 많 관 부
