해결된 질문
작성
·
20
·
수정됨
0
안녕하세요. 잘 수강하고 있습니다.
수치화 하는 부분에 있어 궁금한 점이 있습니다!
개선점을 수치화 하기 전에, 개선에 앞서서 미리 문제 상황을 예상하고 고려 할 수 있는 방법도 궁금합니다.
미리 고려 했어야 하는 점과, 실제로 실무에서도 문제상황으로 마주하는 부분을 구분하기가 어려운 것 같습니다. 현업에서는 어디까지 미리 고민을 해보고, 어느 정도부터는 실제 문제로 마주하게 되는지 궁금합니다.
질문의 배경은 아래와 같습니다.
면접에서 개선 및 수치화 사례에 대해서 "해당 이슈는 매우 known이슈인데, 충분히 미리 고려 할 수 있는 부분이 아니었는지? 고민을 안했었는지?" 질문을 받았었습니다.
예를 들어 7초 -> 2초 줄이는 것보다 2초 -> 0.7초 개선하는것이 더 어려울텐데
설계나 개발전에 미리 고민해보고 2초로 시작 할 수 있었던 문제 아니냐 라는 질문 같았습니다!
수치화를 위한 수치화로 보인다거나, 사전에 고려하지 않는 태도로 보였을까봐 우려되는 지점이었습니다.
이러한 우려를 피하고 싶은데 고견 부탁드립니다
감사합니다!
답변 1
0
고양이님 좋은 질문 해주셔서 감사합니다.
이 질문은 정말 많은 주니어 분들이 실제로 겪는 고민이에요. 면접관 입장도 이해가 가지만, 실무 현실도 분명히 있거든요. 하나씩 같이 파헤쳐 봅시다!
실무에서는 이런 단계로 진행돼요
프로젝트 초기 (MVP 단계) 이 시점에는 솔직히 말하면 "일단 동작하는 것"이 우선입니다. 왜냐하면 서비스가 실제로 유저를 받을지, 어떤 부분이 병목이 될지 아무도 모르거든요. 트래픽이 하루 100명도 안 오는데 동시 접속 1만명 대비 설계를 한다? 이건 오버 엔지니어링이죠.
서비스 성장 단계 (실제 부하 발생) 유저가 늘면서 "어? 이 부분 느린데?"가 나타나기 시작합니다. 이때부터가 진짜 최적화 타이밍이에요. 실제 데이터와 트래픽 패턴을 보고 병목 지점을 찾아서 개선하는 거죠.
그래서 7초 → 2초 개선이 전혀 이상한게 아닙니다. 오히려 "우리 서비스가 성장하면서 병목을 발견하고, 데이터 기반으로 개선했다"는 스토리거든요.
그래서 면접관이 정말 묻고 싶은 건 이거 같습니다
"문제를 발견하는 능력이 있나?"
"왜 이 방법을 선택했는지 논리가 있나?"
"다음에는 어떻게 할 건가?"
"왜 미리 안 했어?"가 아니라 "어떻게 생각하는 사람인가?"를 보는 거죠.
그래서 다음과 같이 흐름을 준비해가시면, 충분히 좋은 대답을 하실 수 있을 것 같습니다
상황 설명 "초기에는 서비스 검증이 우선이어서 기본적인 구현에 집중했습니다. 당시 트래픽은 하루 평균 X명 수준이었고, 응답 속도도 크게 문제가 되지 않았어요."
문제 발견 "그런데 X월부터 일 방문자가 Y명으로 증가하면서, 특정 API의 응답시간이 평균 7초까지 늘어나는 걸 모니터링에서 발견했습니다. 특히 오후 2-3시 피크 타임에 문제가 심각했어요."
분석 과정 "slow query log를 분석해보니 WHERE 절에 사용되는 컬럼에 인덱스가 없어서 풀 테이블 스캔이 발생하고 있었습니다. 10만 건 데이터를 매번 전체 검색하고 있었던 거죠."
개선 및 결과 "해당 컬럼에 인덱스를 추가하고, 실행 계획을 확인해서 index scan으로 변경됐는걸 확인했습니다. 결과적으로 평균 응답시간이 2초로 개선됐고, 피크 타임에도 안정적인 서비스가 가능해졌어요."
배운 점 "이 경험을 통해 서비스 초기부터 모니터링 환경을 구축하는 게 중요하다는 걸 배웠습니다. 다음 프로젝트에서는 Spring Actuator + Prometheus를 초기부터 세팅해서 쿼리 성능을 실시간으로 추적했고, 덕분에 비슷한 이슈를 사전에 발견할 수 있었습니다."
이런 식으로 답변하면 "반성하고 성장하는 개발자"로 보여요.
그럼 실제 프로젝트에서 이런 경험을 쌓아보시고, 면접에서 당당하게 말할 수 있는 스토리를 만들어보세요. 좋은 질문 감사합니다!!