이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
복잡한 워크플로우를 최적화할 때 저는 먼저 전체 흐름을 시각화하는 것에서 시작합니다. 팀 프로젝트에서 배포 프로세스가 너무 복잡해졌던 적이 있는데, 각자 다른 방식으로 이해하고 있어서 같은 문제를 두 번 다른 이름으로 처리하는 일이 생겼습니다. Mermaid로 흐름도를 그려보니 중간에 불필요한 승인 단계가 있었고, 그걸 제거하니 배포 리드타임이 줄었습니다.
문제 지점을 찾기 전에 전체 그림을 먼저 공유하는 것이 팀 전체가 같은 맥락을 갖게 해줘서, 개인이 각자 고치려 할 때보다 훨씬 빠르게 해결이 됐습니다. 복잡성은 각자의 머릿속에 있을 때보다 그림으로 꺼내놓을 때 실체가 보입니다.
워크플로우 최적화에서 제일 먼저 보는 건 어디서 가장 오래 기다리는지입니다. 속도를 높이려다 실제 병목이 아닌 부분을 개선하는 데 시간을 쓰는 경우가 많다고 느꼈습니다. 인턴 때 리뷰 승인 대기 시간이 전체 PR 처리 시간의 절반 이상인 걸 확인했고, 코드 품질보다 리뷰어 배정 기준을 명확히 하는 것이 더 빠른 해결책이었습니다.
측정 없이 개선하면 체감도 없다는 걸 직접 배웠습니다. 어디서 시간이 사라지는지를 먼저 숫자로 보는 습관이 방향을 잡는 데 훨씬 유리하다고 느꼈습니다. 병목을 찾는 것보다 병목을 측정하는 방법을 찾는 것이 더 앞에 있는 문제였습니다.
복잡한 워크플로우는 대부분 처음에 단순하게 시작했다가 예외 케이스가 쌓이면서 복잡해지는 구조입니다. 개인 프로젝트에서 CI/CD 파이프라인을 구성할 때, 초반엔 깔끔했는데 배포 환경이 추가되면서 조건 분기가 늘었고 어느 순간 어떤 조건이 언제 실행되는지 파악이 안 됐습니다. 그때부터 신규 단계를 추가할 때 기존 흐름에서 제거할 단계도 함께 찾는 것을 원칙으로 삼았습니다. 추가보다 정리가 더 어렵지만 그게 더 중요하다는 걸 느꼈습니다. 복잡성은 한 번에 생기지 않고 매번 조금씩 쌓이기 때문에 매 변경 시점마다 점검하는 것이 유일한 예방책이었습니다. 나중에 한꺼번에 정리하려면 어디서부터 손대야 할지 막막해집니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.