확장성을 고려해 구조를 설계한 경험
프로젝트에서 초기에는 단일 서버로 충분했지만, 사용자가 늘어날 상황을 가정해 데이터베이스와 애플리케이션 서버를 분리하는 구조로 설계했습니다. 실제로 부하 테스트를 진행했을 때, 이렇게 분리해둔 덕분에 서버 하나만 늘려도 처리량을 쉽게 늘릴 수 있었습니다. 처음부터 완벽한 대규모 설계를 하기보다, 나중에 확장할 수 있는 여지를 남겨두는 것이 현실적인 접근이라고 생각합니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
프로젝트에서 초기에는 단일 서버로 충분했지만, 사용자가 늘어날 상황을 가정해 데이터베이스와 애플리케이션 서버를 분리하는 구조로 설계했습니다. 실제로 부하 테스트를 진행했을 때, 이렇게 분리해둔 덕분에 서버 하나만 늘려도 처리량을 쉽게 늘릴 수 있었습니다. 처음부터 완벽한 대규모 설계를 하기보다, 나중에 확장할 수 있는 여지를 남겨두는 것이 현실적인 접근이라고 생각합니다.
외부 API에 의존하는 기능을 개발할 때, 그 API가 응답하지 않는 상황을 가정해 타임아웃과 재시도 로직을 함께 설계했습니다. 실제로 테스트 중 외부 서비스가 일시적으로 응답하지 않는 상황을 재현해봤는데, 이 로직 덕분에 전체 서비스가 함께 멈추지 않고 해당 기능만 제한적으로 동작을 멈췄습니다. 정상 동작만 가정하고 설계하면 작은 장애가 전체 장애로 번질 수 있다는 것을 배웠습니다.
데이터 일관성과 응답 속도 중 어느 쪽을 우선할지 고민했던 경험이 있습니다. 실시간성이 중요한 기능이라 약간의 지연을 감수하더라도 응답 속도를 우선하는 방향으로 설계했고, 대신 데이터 정합성은 별도의 배치 작업으로 주기적으로 보정하는 방식을 택했습니다. 모든 것을 동시에 만족시킬 수 없다는 것을 이해하고, 서비스 특성에 맞게 우선순위를 정하는 것이 설계의 핵심이라고 느꼈습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.