이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 메시지 큐 라이브러리를 고를 때 먼저 기능보다 커뮤니티 상태를 확인했습니다. GitHub 이슈가 수천 개인데 최근 커밋이 1년 전인 프로젝트가 있었고, 화려한 기능 목록에 비해 실제 질문에 답이 없는 상태였습니다.
최근 6개월 커밋 수, 이슈 대응 속도, 공식 문서 최신화 여부를 기준으로 비교했습니다. 기능이 조금 부족해도 꾸준히 관리되는 쪽을 선택했고, 이후 업그레이드 시 마이그레이션 가이드가 잘 정리돼 있어 편했습니다.
실패 경험도 있었습니다. 한 번은 스타 수만 보고 선택했다가 버전 업그레이드에서 하위 호환이 깨져 대응에 하루가 걸렸습니다. 오픈소스는 인기보다 '내가 3년 후에도 쓸 수 있는가'를 기준으로 골라야 한다는 걸 그때 배웠습니다.
인턴 때 전문 검색 라이브러리 도입을 검토하면서, 문서만 읽고 좋아 보인다는 이유로 바로 도입하려다 선임이 먼저 소규모로 검증해 보자고 했습니다. 그게 옳은 판단이었습니다.
실제 데이터 10만 건으로 색인·검색 성능을 직접 측정했더니, 공식 문서의 벤치마크와 우리 환경에서의 결과가 크게 달랐습니다. 특히 한국어 형태소 분석 플러그인 설정이 복잡해서 예상 도입 기간이 3배로 늘어나는 문제가 확인됐습니다.
그 검증을 통해 도입을 보류하고 기존 DB 전문 검색 기능으로 대체했습니다. 오픈소스 검토는 문서 리딩에서 끝내지 말고 우리 환경에서 직접 돌려보는 단계가 꼭 있어야 한다는 것이 그때 배운 기준입니다.
사이드 프로젝트에서 PDF 생성 라이브러리를 도입하려다 라이선스를 뒤늦게 확인했더니 상업적 이용에 제한이 있었습니다. 이미 기능 구현을 80% 마친 뒤에 알게 됐고, 대안 라이브러리로 갈아타느라 이틀을 다시 썼습니다.
그 이후로 오픈소스를 고를 때 제일 먼저 라이선스 유형을 확인합니다. MIT·Apache 2.0·BSD는 비교적 자유롭고, AGPL은 서버 배포 시 소스 공개 의무가 있어 상업 서비스엔 맞지 않습니다. 보안 취약점도 npm audit 같은 도구로 확인하는 단계를 넣었습니다.
기능 검토와 라이선스 검토를 동시에 하지 않으면 나중에 큰 비용이 생긴다는 걸 그 경험이 가르쳐 줬습니다. 지금은 첫 검토 단계에서 라이선스 → 유지보수 상태 → 기능 순서로 확인합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.