새로 합류한 회사에서 첫 번째 스프린트를 끝냈다.
이번 회고는 첫 스프린트 동안의 느낀 점, 반성, 그리고 앞으로의 다짐을 정리하는 기록이다.
스프린트 시작: 설계가 끝난 상태에서의 시작
첫 스프린트는 팀 리더가 이미 테이블 설계와 데이터 모델링을 마무리한 상태에서 시작했다. 백엔드 개발에 있어서 설계가 제일 빡세다고 생각하고, 그래서 BE 개발의 꽃이라고 생각하는데, 이걸 내가 안 해도 된다니 작업이 수월하겠다고 생각했다. 하지만... 참조해야 할 테이블이 왜 이렇게 많냐?
기본적으로 4~5개의 테이블은 건드려야 하나의 API가 만들어지는 구조였다. 조회 성능 최적화를 위해 데이터가 분산 저장되어 있었는데, 이 방식이 전 직장에서 쓰던 설계와는 너무 달라서 구조를 이해하는 데 꽤 오래 걸렸다.
특히 역정규화를 이렇게 자유롭게(?) 활용하는 설계 방식을 처음 겪어봤다. 작업이 끝난 지금은 그 구조가 효율적이라고 느껴지지만, 당시에는 낯선 설계 방식과 컨벤션을 파악하느라 고생 좀 했다.
그리고 정책 문서가 따로 없어서 하나하나 사수에게 물어보며 진행해야 했던 점도 불편했다. 원래 모르거나 이해가 안가는 건 바로 바로 물어보는 성격이라 질문하는 건 어렵지 않았지만, 물어보는 데 걸리는 시간 때문에 작업 속도가 더뎌질 수밖에 없었다. 게다가 많이 물어보다 보니 이미 들었던 질문을 또 하고, 반복되는 질문에 사수가 저번에 설명 드렸는데~ 하면서 답해줄 때는 약간 빡친 게 아닐까 싶어 쫄리기도 했다.
근데 어쩌겠어, 지금 물어봐야 나중에 덜 혼난다. 그렇게 눈치보면서 계속 물어보며 작업을 진행했다. 죄송합니다 나중에 잘할께요!!
아직도 부족하다고 느낀 API 설계
API 설계는 자신 있었다! 전 직장에서 몇 번의 스프린트를 거치며 해왔던 작업이라 익숙하다고 생각했다. 하지만, 이번에 목 데이터를 설계하면서도 실수를 반복했다.
클라이언트 작업이 빨리 진행될 수 있도록 목 데이터를 기반으로 API를 설계했는데, 이후 작업 도중 클라이언트와 협의 없이 Response DTO를 수정하거나, 기존에 NOT NULL로 내려가던 데이터를 갑자기 Nullable로 바꾼 적이 있었다. 심지어 속성 이름까지 수정했는데, 이런 변경들이 프론트에서 문제를 일으켰다.
전 직장에서도 똑같은 실수를 했었는데, 그걸 다시 반복했다는 게 너무 한심했다..
결국 리더가 프론트와 소통하는 방법에 대해 따로 미팅을 잡았고, 어떤 경우에 서로에게 의견을 물어야 하는 지 설명해줬다.
이 미팅이 나 때문에 열렸구나 싶어 다른 팀원들에게 너무 미안했고 한편으로는 또 감사했다 ㅠㅠ 나 때문에 얼마나 힘드셨을까... 그래도 설명해주신다고 자리도 마련해주고 흑
가시방석에서 진행됐던 미팅이였지만, 실수는 누구나 할 수 있어.. 줄여 나가면 돼!! 나 자신을 다독이며 잘 이겨냈지만, 여전히 마음 속 죄송한 마음이 든다 ㅠㅠ
실수에서 얻은 교훈
-
소통의 중요성
API 설계에서 클라이언트와의 협의는 필수다. 설계 단계에서 피드백을 주고받아야만 예기치 못한 문제를 줄일 수 있다. -
변경 사항은 사전 공유
데이터 타입이나 속성 이름 변경은 클라이언트 입장에서 큰 영향을 미친다. 사소한 수정도 공유하고 협의하는 습관을 들이자.
다음 스프린트를 위한 다짐
-
목 데이터 설계와 공유
개발 시작 전에 목 데이터를 기반으로 한 API 설계를 명확히 정리하고, 클라이언트와 충분히 공유하겠다. -
클라이언트 친화적인 API 설계
클라이언트가 원하는 데이터를 정확히 제공할 수 있도록 더 유연한 설계를 시도하겠다. 필요하다면 도움을 요청하는 것도 주저하지 말자.
결론: 실수는 성장의 발판이다
이번 스프린트는 실수와 반성으로 가득했지만, 이 경험을 통해 또 많은 걸 배웠다고 생각한다. 클라이언트가 같이 일하고 싶은 백엔드 개발자가 되고 싶다.더 나은 소통과 설계를 보여주고 싶은데, 이게 어떻게 한번에 되겠어...
UI에서 보여지는 데이터가 정적이냐 동적이냐에 따라 판단해봐라는 팁을 기억하자.
또 설계하는 방법에서는, '감'이라는 게 있다고 한다.
n번 반복하다보면 나에게도 감이 생기지 않을까!!? 포기만 하지말자!!!
다음 회고에서는 실수보다 더 많은 성공 경험을 적을 수 있었으면 좋겠다ㅠㅠ
사실 이번 스프린트에서 잘한 점도 꽤 많다.
저번에 배웠던 Map, 빌더 패턴, 우리만의 어메이징한 인증 가드 등 해당 코드들을 참고해서 나에게 맞게끔 적용도 했다.
비록 지금은 고작 응용 따위였지만, 응용을 할 줄 알면 나중에는 직접 만들 수도 있을 거야...!! 고생했다 나 자신!
그래도 QA에서 예상보다 적은 버그가 발견됐으니, 그건 또 꼼꼼하게 작업했다는 증거라고 생각한다. 꼼꼼하니까 다음 스프린트는 클라이언트와 더 잘 소통할 수 있어!!
다음 스프린트는, 아쉬웠던 점 말고 잘한 점을 적을 수 있도록 최선을 다해봐야겠다.
다음 스프린트도 파이팅!!
