수치화 관련 질문

작성자 없음

작성한 질문수 0

0

고양이님 좋은 질문 해주셔서 감사합니다.

이 질문은 정말 많은 주니어 분들이 실제로 겪는 고민이에요. 면접관 입장도 이해가 가지만, 실무 현실도 분명히 있거든요. 하나씩 같이 파헤쳐 봅시다!

실무에서는 이런 단계로 진행돼요

프로젝트 초기 (MVP 단계) 이 시점에는 솔직히 말하면 "일단 동작하는 것"이 우선입니다. 왜냐하면 서비스가 실제로 유저를 받을지, 어떤 부분이 병목이 될지 아무도 모르거든요. 트래픽이 하루 100명도 안 오는데 동시 접속 1만명 대비 설계를 한다? 이건 오버 엔지니어링이죠.

서비스 성장 단계 (실제 부하 발생) 유저가 늘면서 "어? 이 부분 느린데?"가 나타나기 시작합니다. 이때부터가 진짜 최적화 타이밍이에요. 실제 데이터와 트래픽 패턴을 보고 병목 지점을 찾아서 개선하는 거죠.

그래서 7초 → 2초 개선이 전혀 이상한게 아닙니다. 오히려 "우리 서비스가 성장하면서 병목을 발견하고, 데이터 기반으로 개선했다"는 스토리거든요.

그래서 면접관이 정말 묻고 싶은 건 이거 같습니다

• "문제를 발견하는 능력이 있나?"

• "왜 이 방법을 선택했는지 논리가 있나?"

• "다음에는 어떻게 할 건가?"

"왜 미리 안 했어?"가 아니라 "어떻게 생각하는 사람인가?"를 보는 거죠.

그래서 다음과 같이 흐름을 준비해가시면, 충분히 좋은 대답을 하실 수 있을 것 같습니다

상황 설명 "초기에는 서비스 검증이 우선이어서 기본적인 구현에 집중했습니다. 당시 트래픽은 하루 평균 X명 수준이었고, 응답 속도도 크게 문제가 되지 않았어요."

문제 발견 "그런데 X월부터 일 방문자가 Y명으로 증가하면서, 특정 API의 응답시간이 평균 7초까지 늘어나는 걸 모니터링에서 발견했습니다. 특히 오후 2-3시 피크 타임에 문제가 심각했어요."

분석 과정 "slow query log를 분석해보니 WHERE 절에 사용되는 컬럼에 인덱스가 없어서 풀 테이블 스캔이 발생하고 있었습니다. 10만 건 데이터를 매번 전체 검색하고 있었던 거죠."

개선 및 결과 "해당 컬럼에 인덱스를 추가하고, 실행 계획을 확인해서 index scan으로 변경됐는걸 확인했습니다. 결과적으로 평균 응답시간이 2초로 개선됐고, 피크 타임에도 안정적인 서비스가 가능해졌어요."

배운 점 "이 경험을 통해 서비스 초기부터 모니터링 환경을 구축하는 게 중요하다는 걸 배웠습니다. 다음 프로젝트에서는 Spring Actuator + Prometheus를 초기부터 세팅해서 쿼리 성능을 실시간으로 추적했고, 덕분에 비슷한 이슈를 사전에 발견할 수 있었습니다."

이런 식으로 답변하면 "반성하고 성장하는 개발자"로 보여요.

그럼 실제 프로젝트에서 이런 경험을 쌓아보시고, 면접에서 당당하게 말할 수 있는 스토리를 만들어보세요. 좋은 질문 감사합니다!!