이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
하나의 서비스를 2년 이상 운영하면서 겪었던 가장 큰 문제와 그 해결 방법에 대해 설명하겠습니다.
동아리에서 1년 반 동안 운영한 스터디 플랫폼이 있었는데, 처음에는 빨리 만드느라 코드 구조를 크게 신경 쓰지 못했습니다. 6개월쯤 되었을 때 기능 하나를 추가하려면 관련 없는 부분 세 군데를 같이 수정해야 하는 상황이 생겼습니다. 새 팀원이 코드를 읽는 데 하루가 걸린다고 했을 때 문제라고 인식했습니다. 리팩토링을 하자는 의견을 냈지만 팀 내에서 당장 기능을 추가해야 하는데 리팩토링을 해도 되냐는 반대가 있었습니다. 두 달에 걸쳐 기능 추가와 병행하면서 조금씩 정리했습니다.
기술 부채는 나중에 갚으려면 이자가 붙는다는 것을 직접 느꼈습니다. 그 과정이 값진 배움이었습니다.
개인 포트폴리오 프로젝트를 1년 넘게 운영했는데 초반엔 DB 쿼리를 최적화할 생각을 못 했어요. 방문자가 50명 정도였을 땐 괜찮았는데, SNS에 소개되면서 하루 500명이 오자 응답이 5초가 넘어갔어요. DB 쿼리를 확인했더니 N+1 문제가 4군데였어요. 조인 쿼리로 바꾸고 자주 조회하는 컬럼에 인덱스를 추가했더니 응답이 0.4초로 줄었어요. 이 경험을 하기 전엔 개발자 PC에서만 확인하고 충분하다고 생각했어요.
실 사용 패턴을 미리 상상해보는 게 개발 단계에서도 중요하다는 걸 배웠어요. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다. 그 과정이 값진 배움이었습니다.
사이드 프로젝트를 2년 가까이 방치했다가 다시 개발을 시작했는데, npm install이 실패했어요. 패키지 버전들이 서로 맞지 않아서 의존성 충돌이 23개 생겼어요. 하나씩 버전을 올리다 보니 한 패키지를 올리면 다른 게 깨지는 의존성 지옥에 빠졌어요. 이틀 반이 걸려서 해결했는데, 이 과정에서 package-lock.json을 커밋하는 이유를 제대로 이해했어요. 이후로는 한 달에 한 번 패키지 업데이트를 소량씩 하는 습관이 생겼어요.
오래 운영하는 서비스는 기능 개발만큼 유지보수 루틴이 중요하다는 걸 배웠어요. 운영은 만들고 끝이 아니라는 걸 직접 경험했어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.