프로젝트 기획 회고록
4F 방법
- 사실(Fact): 일어난 일에 대한 객관적인 기록
- 느낌(Feeling): 상황에 대한 감정적인 반응
- 교훈(Finding): 경험을 통해 배울 수 있었던 것
- 향후 행동(Future action): 향후 할 수 있는 개선된 행동
Fact
프로젝트 기획을 하고 필요한 기능들을 정리 한 후 어떤 기술 스택을 사용할 것인지와 기술에 대한 세부사항을 적고 구현할 우선순위를 정한 후 ERD 설계를 시작했다.
이를 기반으로 ERD 설계를 하였다. 이렇게 제대로된 ERD를 처음 만들어보기도 하고, 생각보다 기능이 많아서 그 기능들간의 관계성 등을 생각하다보니 시간이 꽤 오래걸렸다.
자료형을 정하는 데에 있어서는 어느정도 통일을 하고 팀원 6명을 세팀으로 나눠 작업했다.
PK를 정하는 과정에서 AUTO INCREMENT로 해야할지, UUID를 사용해야 할지 에 대한 논쟁이 발생했다.
Feeling
우선 이런 복잡한 ERD를 설계해본적이 처음이라 생각보다 고려해야할 점들이 많아서 어려웠다. 그리고 PK에 대한 문제는 어떻게 해야할지 고민이 많이 됐었다. 우리 프로젝트가 분산 환경이 아니라는 점과, 대규모 서비스로 운영할 계획이 아직 없다는 점, 조회가 어렵다는 점에서 UUID를 굳이 써야할까?하는 생각이 들었었다. 보통 UUID는 분산 환경에서 많이 쓰이기 때문이다. 그러나 Auto Increment를 쓰게 된다면 보안이 좋지 않다는 점에서 문제가 생겼다. 처음에는 우리가 분산 환경이라고 생각해서 uuid를 쓰기로 했었다. 그러나 우리는 db를 여러개 쓰는 것이지 분산환경은 아니었다. 이에 보안을 위해 uuid를 쓸 것인지, 조회 성능을 위해 auto increment를 쓸 것인지 고민했다.
Finding
결과적으로, 우리는 분산환경이 아니기 때문에 uuid는 쓰지 않고 auto increment를 쓰되, 발생할 수 있는 보안상의 문제는 secret key를 만들어 사용하기로 했다.
이 문제를 논의하는 과정에서 백엔드 개발자로 일하고 있는 선배에게 조언을 구했었는데 둘 중 무엇을 선택하던 정답은 없지만 어떤 것을 선택하는 이유가 명확하기만 하면 된다는 말을 들었다. 이렇게 결정하는 것도 개발자의 능력이구나 하는 생각이 들었다. 좋은 결정을 내리려면 관련 지식이 풍부해야한다는 것을 다시 한번 느끼게 되었다.
Future action
auto increment를 사용하면서 발생하는 보안상의 문제를 방지하기 위해 secret key를 만들어 사용하기로 했기 때문에, 이에 대한 공부를 할 예정이다.
앞으로는 어떤 기술을 사용할 지 정할 때 그 기술들의 장단점을 명확히 알아봐야겠다.
