1. 디비 모델링
현실세계의 요구사항을 rdb 스키마로 풀어내야 됨.
근데 이게 그냥 풀어내면 되는 게 아니라 앞으로 서비스가 어떤 방향으로 발전할지 예측해서 어디가 성능적으로 병목이 될지 파악해서 비정규화를 한다던지, 어느 부분이 확장될건지 예측해서 확장성있게 구성한다던지 이런 고민이 필요.
2. 아키텍쳐링
간단한 게시판이야 그냥 백엔드 세우고 거기에 바로 붙으면 되지만
실서비스 가게되면 캐시는 필수불가결.
그럼 캐시는 어떤 식으로 어느 부분을 붙일지, cdn 이 필요하다면 그건 또 어떻게 설정할지, rdb 외에 다른 데이터베이스가 필요하다면 어떤 디비를 선택해서 또 어떻게 구성할지, 또 분산 환경이라면 그에 따르는 다른 고민들이 필요함
3. msa
msa 가 몇년전부터 트렌드인건 알고 있을테고
그럼 여기서 공통 코드는 어떻게 유지할지, 각 서비스간 인터페이스는어떻게 정의해서 어디에 유지할지, api gw 는 어떤 전략으로 설정할지 등등
등등
아무튼 백엔드의 고민은 단순히 코드 영역 내로 한정되지 않음.
- dc official App
아니 이런건 대체 어디서 공부해야하냐
이런건 어디 뭐 정해진 커리큘럼이나 수업에서 배울 수 있는 내용이 아님. 자기가 그냥 평소에 관심가지고 다른 사람들은 어떤 고민을 하면서 어떻게 문제를 해결해가는지 계속 찾아보면서 공부해야댐 - dc App
쩝.. 글쿠만잉
그래서 백엔드가 더 어려운 것도 있음. 2, 3번은 인터넷 찾으면 내용 많이 나오기도 하는데 1번은 거의 회사마다 대외비 수준으로 공개를 안함. 그리고 같은 백엔드더라도 도메인마다 필요한 경험들이 다르기도 하고. - dc App
이래서 교수님이 맨날 간단한 거라도 주먹구구식 말고 설계부터 생각하라고 글케 말하셨구나