이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 실시간 데이터 처리 기능을 설계할 때 성능과 안정성 사이에서 선택해야 하는 지점이 여러 번 있었습니다. 예를 들어 응답 속도를 높이기 위해 캐시를 적극 쓰는 방향이 있었는데, 캐시 만료 시점에 데이터 불일치가 생길 수 있다는 안정성 이슈가 있었습니다. 결국 자주 바뀌지 않는 데이터만 캐시하고, 실시간 데이터는 캐시 없이 처리하는 방식으로 절충했습니다. 테스트 단계에서는 부하 테스트를 직접 만들어 응답 지연과 오류율을 동시에 측정했습니다. 설계 단계에서 트레이드오프를 명확히 정해두면 나중에 코드를 수정할 때 판단 기준이 생깁니다. 그 기준이 없으면 조건마다 다른 결정을 내리게 됩니다.
트레이드오프를 명시적으로 기록하면 코드 수정 시 판단 근거가 남아있어 유지보수가 쉬워집니다. 설계 단계의 결정이 나중 비용을 결정합니다.
설계와 개발에서 안정성은 코드를 다 짜고 나서 테스트하는 것이 아니라 개발하면서 함께 확인하는 것이 더 효율적이라는 것을 배웠습니다. 캡스톤 프로젝트에서 핵심 기능에 대한 단위 테스트를 개발과 병행해서 작성했더니, 나중에 기능을 수정했을 때 어느 부분이 깨지는지 바로 확인할 수 있었습니다. 테스트 없이 개발할 때는 수정 후에 전체를 수동으로 확인해야 했는데 누락이 생겼고, 테스트가 있을 때는 자동으로 알려줬습니다.
안정성은 코드가 아니라 확인 체계에서 나옵니다. 성능과 안정성 중 어느 쪽을 먼저 잡을지 고민이 될 때 안정성 기반을 먼저 만들어두는 쪽이 성능 개선을 안심하고 시도할 수 있게 합니다. 기반이 있어야 속도를 냅니다.
실시간 처리 시스템을 개발할 때 정상 상황에서는 잘 동작해도 동시 요청이 몰릴 때 어떻게 반응하는지를 미리 확인해야 한다고 생각합니다. 팀 프로젝트에서 간단한 로드 테스트 스크립트를 만들어 동시 요청 수를 점진적으로 올리는 방식으로 시스템 반응을 측정했습니다. 처음에는 50개 동시 요청에서 응답이 늦어지기 시작하는 지점을 발견했고, 원인을 분석하니 DB 커넥션 풀 설정이 너무 작았던 것이었습니다. 설정을 조정하고 다시 측정하니 200개 동시 요청까지 안정적으로 처리됐습니다.
성능과 안정성은 부하 조건을 직접 만들어봐야 보입니다. 테스트 없이 추정하는 것은 약한 고리를 모르는 채로 운영하는 것입니다. 측정해야 알 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.