우문현답
愚 問 賢 答
회사별 면접직군별질문 가이드진행 방식
    홈›회사별›라인›SRE›질문 상세
    問
    라라인SRE직무 역량2026년 출제

    관찰 가능성 아키텍처를 설계하거나 운영한 경험이 있다면, 그 과정에서 배운 점은 무엇인가요?

    답변 미리보기

    팀 프로젝트에서 서비스 장애 원인을 찾는 데 1시간 이상 걸린 경험이 관찰 가능성 설계에 관심을 갖게 된 계기였습니다. 당시에는 로그가 흩어져 있고 메트릭이…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    구성 결을 분별하는가?
    한 결로 답하는지, 로그·메트릭·트레이스·이벤트 결로 가른 흔적이 답에 있는지 보는 자리입니다. 한 결로 묶는 답은 깊이가 약해지는 자리입니다.
    骨
    02
    본인 사례가 있는가?
    이론 결만 답하는지, 본인이 실제 굴린 관측 결의 흔적이 답에 묻어 있는지 살피는 자리입니다. 책에서 본 결은 실무 감각이 약해지는 자리입니다.
    語
    03
    지표가 분명한가?
    감으로 답하는지, MTTR·SLI/SLO·비용 결로 가른 변화가 답에 있는지 살피는 자리입니다. 지표 없는 결은 표면적입니다.
    本
    04
    활용을 의식하는가?
    구축만 답하는지, 알람·디버그·용량 계획 결로 가른 활용이 답에 있는지 보는 자리입니다. 활용 없는 결은 자리가 흐려지는 자리입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    라인 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    로그·메트릭·트레이스 세 축 + 알림 임계값 설계 경험으로 설명약 70초구조화 로그·분산 트레이싱과 SLO 기반 지표로 장애 원인·복구 성과를 정량화 결알람 분류·전달전략과 메트릭 기반 용량계획을 결
    예시 답변 1
    약 70초

    로그·메트릭·트레이스 세 축 + 알림 임계값 설계 경험으로 설명

    팀 프로젝트에서 서비스 장애 원인을 찾는 데 1시간 이상 걸린 경험이 관찰 가능성 설계에 관심을 갖게 된 계기였습니다. 당시에는 로그가 흩어져 있고 메트릭이 없었습니다. 이후 프로젝트에서는 로그·메트릭·트레이스 세 축을 처음부터 설계해서 들어갔습니다. 로그는 structlog로 JSON 형태로 남기고, 메트릭은 Prometheus 클라이언트로 요청 수와 응답 시간을 수집했습니다. 트레이스는 trace_id를 요청 헤더로 전파해서 마이크로서비스 간 요청 흐름을 한 줄로 연결할 수 있게 했습니다. 운영 중에 알림 임계값을 너무 낮게 잡으면 알림이 너무 자주 와서 무시하게 되는 문제도 경험했고, 임계값 설정 자체도 설계가 필요하다는 걸 배웠습니다.

    관측 가능성은 만들 때가 아니라 장애가 났을 때 진짜 가치가 드러나는 자리라는 걸 그때 알았습니다.

    이 결의 특징
    로그·메트릭·트레이스 세 축을 처음부터 설계이라는 구체적 기술을 직접 경험하고 그 과정에서 배움을 얻은 흔적이 드러납니다.
    이 결이 통하는 자리
    구체적인 도구나 기술 이름과 함께 그것을 왜 배웠는지 과정이 있을 때 실제 경험으로 인정받는 자리입니다.
    예시 답변 2

    구조화 로그·분산 트레이싱과 SLO 기반 지표로 장애 원인·복구 성과를 정량화 결

    관찰 가능성 체계를 도입한 뒤 가장 뚜렷하게 달라진 것은 장애 대응 시간이었습니다. 이전에는 문제가 생기면 로그를 grep하거나 배포 이력을 뒤지는 데 시간을 썼는데, 구조화된 로그와 트레이스를 붙이고 나서는 어느 서비스, 어느 엔드포인트에서 오류가 시작됐는지를 첫 5분 안에 좁힐 수 있었습니다.

    OpenTelemetry로 trace_id를 서비스 간에 전파하면서 분산 환경에서 요청 흐름을 한 줄로 연결하는 구조를 만들었고, 응답 시간 P99 지표를 SLO 기준으로 정해 알림 임계값을 설정했습니다. SLO를 99.5%로 설정하고 에러 버짓을 계산해보니 월간 허용 가동 중단 시간이 약 3.6시간이라는 것이 구체적으로 잡혔고, 알림이 실제 예산 소비와 연결된다는 느낌이 생겼습니다.

    지표를 보기 전까지는 장애 복구가 잘 됐는지 나쁘게 됐는지 감으로만 판단했는데, 측정 결과가 쌓이고 나서야 '이번은 MTTR이 줄었다'고 말할 수 있는 자리가 생겼습니다.

    이 결의 특징
    시행한 개선의 결과를 데이터와 수치로 입증하는 검증된 경험의 흔적이 드러납니다.
    이 결이 통하는 자리
    단순 개선보다 '얼마나' 나아졌는지 측정 가능한 수치가 제시될 때 강점이 살아나는 자리입니다.
    예시 답변 3

    알람 분류·전달전략과 메트릭 기반 용량계획을 결

    관찰 가능성 체계를 운영하면서 처음 맞닥뜨린 현실적인 문제는 알람 피로였습니다. 임계값을 조금 낮게 설정하자 자정에도 알람이 오는 상황이 됐고, 팀원들이 알람을 습관적으로 무시하기 시작했습니다.

    이 경험에서 알람 설계도 별도의 관리가 필요하다는 것을 배웠습니다. 알람을 긴급·경고·정보 세 단계로 나누고, 긴급 알람만 즉시 호출로 연결하고 나머지는 집계 후 배치로 전달하는 방식으로 바꾸자 팀 내 알람 피로가 크게 줄었습니다.

    용량 계획도 메트릭이 쌓이고 나서야 의미 있게 할 수 있었습니다. 월별 요청 증가율을 메트릭에서 추출하고 현재 인프라가 언제 병목에 걸릴지를 역산해보니, 단순히 '느려지면 늘린다' 방식보다 훨씬 여유 있게 대응할 수 있었습니다. 관찰 가능성이 문제 탐지 이상으로 용량 계획·팀 운영까지 이어지는 자리라는 것을 그 경험에서 처음 느꼈습니다.

    이 결의 특징
    기술 선택을 넘어 그 선택이 왜 필요한지 설계 철학까지 담아내는 흔적이 드러납니다.
    이 결이 통하는 자리
    개별 사건에 그치지 않고 그것을 통해 배운 보편적 가르침을 제시할 때 깊이감이 살아나는 자리입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕고른 것만 말하고 있지 않은가? 검토했다 접은 선택지가 하나라도 나와야 판단으로 읽힙니다.
    • ✕판단 기준이 그 상황에 붙어 있는가? "더 좋아서"는 일반론이고, 그때의 조건을 짚은 말이 본인의 답입니다.
    • ✕결과를 확인한 방법이 있는가? 수치든 주변 반응이든, 무엇을 보고 됐다고 판단했는지가 빠지면 막연해집니다.
    • ✕지금 다시 한다면 무엇을 바꿀지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊게 남습니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹왜 그 구성 결을 고르셨나요?
    대응왜 그 결을 본인 기준으로 골랐는지 답하는 결이 강합니다. 본인 근거가 묻어나면 자리가 단단해지는 결로 통합합니다.
    貳막힌 관측 경로 결도 있었나요?
    대응어디서 막혔고 어떻게 보정한 결인지 솔직히 짚는 결이 자주 보입니다. 본인 가설이 깨진 회고가 자리를 살리는 결로 통합합니다.
    參본인만의 관측 결이 있나요?
    대응왜 그 결이 본인에게 잘 통한 결인지 답하는 자리가 강합니다. 본인 근거가 묻어나면 자리가 단단해지는 결로 통합합니다.
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 라인 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    마켓컬리 · 솔루션 아키텍트
    ERP 연동 아키텍처를 설계할 때 주의해야 할 점은 무엇이라고 생각해?
    이 질문 보기
    CJ올리브영 · 프론트엔드
    프론트엔드 아키텍처 설계 경험이 있다면, 어떤 아키텍처를 사용했고 그 이유는 무엇인지 설명해 주세요.
    이 질문 보기
    카카오페이 · 백엔드
    고가용성 아키텍처를 설계할 때 어떤 점에 주의해야 하나요?
    이 질문 보기
    세나클소프트 · 백엔드
    MSA 기반 시스템 아키텍처를 설계한 경험이 있다면 그 과정에서 어떤 점을 고려했는지 이야기해 주세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 라인 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기