02. 문제는 발견하는가, 만드는가

문제 제기: 알람은 울렸는데, 무엇이 문제였을까

새벽 두 시, 모니터 한쪽에서 빨간 알람이 깜빡인다. 응답 시간이 평소보다 300밀리초 늘었다. 슬랙에는 온콜 담당자의 이름이 호출되고, 대시보드에는 그래프 하나가 천천히 위로 기어오른다. 팀은 곧바로 묻는다. “문제가 어디서 발생했지?” 데이터베이스인가, 네트워크인가, 최근 배포인가. 그러나 조금 뒤 다른 질문이 떠오른다. 정말 문제는 이미 어딘가에 존재하고 있었던 것일까? 아니면 우리가 특정한 수치와 임계값과 서비스 수준을 정해 놓았기 때문에 비로소 ‘문제’가 된 것일까?

공학에서 문제는 흔히 자연물처럼 다뤄진다. 바위처럼 앞을 가로막고 있으니 찾아내어 제거해야 한다는 것이다. 버그는 코드 안에 숨어 있고, 장애는 시스템 안에 잠복해 있으며, 요구사항은 사용자의 머릿속에 이미 완성되어 있다고 생각한다. 하지만 실제 현장에서 문제는 그렇게 순수하게 발견되지 않는다. 문제는 관찰 방식, 측정 단위, 조직의 목표, 누군가의 불편을 말할 권한이 서로 얽힌 결과로 나타난다.

철학적 논점: 문제는 사실이면서 동시에 선택이다

철학은 여기서 당연한 문장을 멈춰 세운다. “문제가 있다”는 말은 단순한 사실 보고가 아니다. 무엇을 정상으로 볼 것인지, 무엇을 손실로 계산할 것인지, 누구의 경험을 증거로 인정할 것인지가 이미 들어 있는 판단이다. 존 듀이가 문제 상황을 인간과 환경의 상호작용 속에서 보았던 것도 이 때문이다. 문제는 세계에 붙어 있는 라벨이 아니라, 어떤 흐름이 막히고 그 막힘이 우리의 행위를 요구할 때 구성된다.

같은 현상도 관점에 따라 전혀 다른 문제가 된다. 추천 시스템의 클릭률이 떨어졌다고 하자. 성장팀에는 매출의 문제이고, 사용자에게는 관심 없는 콘텐츠가 반복되는 경험의 문제이며, 창작자에게는 자신의 작업이 노출되지 않는 분배의 문제일 수 있다. “클릭률을 어떻게 높일까?”라는 질문은 이미 문제를 하나의 방향으로 만들어 버린다. 그 질문에 답하는 동안 우리는 다른 문제들을 조용히 삭제한다.

그렇다고 문제가 전부 임의적인 것은 아니다. 서버는 실제로 다운되고, 사람은 실제로 기다리며, 예산은 실제로 소진된다. 철학적 성찰은 현실을 부정하는 일이 아니라 현실의 여러 층위를 구별하는 일이다. 무엇이 물리적 제약이고 무엇이 조직의 관습인지, 무엇이 사용자의 필요이고 무엇이 우리가 편리하게 측정할 수 있는 대리 지표인지 분해해야 한다. 문제를 만든다는 말은 허구를 꾸며낸다는 뜻이 아니라, 복잡한 상황에서 특정한 면을 전경으로 끌어올리고 행동 가능한 형태로 구성한다는 뜻에 가깝다.

공학 사례: 고객의 불만을 티켓으로 바꾸는 순간

한 팀이 “검색이 불편하다”는 고객 피드백을 받았다고 하자. 엔지니어는 검색창의 자동완성, 색인 속도, 오타 교정부터 떠올릴 수 있다. 하지만 인터뷰를 따라가 보면 사용자는 결과가 늦어서가 아니라, 검색 결과를 믿을 수 없어서 불편해하고 있을지도 모른다. 같은 상품이 판매자마다 다른 이름으로 올라오고, 품절 상품이 상단에 남아 있으며, 가격이 바뀌어도 이전 설명이 노출된다. 여기서 문제는 ‘검색 API의 지연 시간’이 아니라 ‘검색 결과를 판단할 수 없는 상태’다.

문제 정의가 달라지면 구조도 달라진다. 전자의 정의는 캐시와 인덱스 튜닝을 부른다. 후자의 정의는 상품 데이터의 정합성, 품절 상태의 갱신, 결과의 출처 표시, 사용자가 검색어를 수정할 수 있는 인터페이스를 부른다. 코드 한 줄의 차이가 아니라 시스템이 무엇을 책임져야 하는지의 차이다. 공학자는 문제를 발견한 뒤 해결하는 사람인 동시에, 무엇을 해결할 가치가 있는지 경계를 그리는 사람이다.

특히 AI 시스템에서는 이 경계가 더 선명해진다. “모델이 틀렸다”는 진단은 편리하지만 너무 넓다. 모델의 지식 부족인가, 프롬프트의 모호함인가, 평가 데이터가 현실을 대표하지 못한 것인가, 아니면 애초에 자동화하면 안 되는 판단을 자동화한 것인가. 문제를 정확히 다시 만들지 않으면 팀은 모델을 계속 키우면서도 제품의 위험을 키울 수 있다.

반론과 긴장: 사용자가 문제를 말하지 않아도 되지 않는가

물론 모든 문제를 끝없이 재정의할 수는 없다. 장애가 발생한 밤에 철학 세미나를 열 수는 없다. 이미 정해진 운영 목표와 계약상의 의무가 있고, 빠르게 복구해야 하는 순간도 있다. 문제를 구성한다는 통찰이 실행을 늦추는 핑계가 되어서는 안 된다. 때로는 먼저 불을 끄고 나중에 화재 감지기의 위치를 다시 살펴야 한다.

그러나 속도와 성찰은 반드시 반대가 아니다. 좋은 팀은 긴급 대응과 문제 정의를 서로 다른 시간축에서 수행한다. 즉시 롤백할 때는 즉시 롤백하되, 회고에서는 “왜 이 지표가 우리에게 문제였는가”, “누가 이 장애의 비용을 떠안았는가”, “복구율만 높이고 재발 가능성을 숨긴 것은 아닌가”를 묻는다. 빠른 해결은 필요하지만, 빠르게 잘못 정의한 문제를 해결하는 것은 가장 비싼 종류의 속도다.

마무리 질문

당신이 다음 스프린트에서 받게 될 “문제”는 정말 세계가 건네는 단단한 물체일까. 아니면 팀의 지표와 권한과 습관이 함께 빚어낸 임시적인 모양일까. 우리가 해결책을 쓰기 전에 먼저 물어야 할 것은 “어떻게 고칠까?”가 아니라 “무엇이 누구에게, 어떤 기준에서 문제인가?”일지 모른다.