이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
취업 준비 중 IT 기획 직무를 목표로 공부하면서 COBIT과 ISO 27001 같은 IT 거버넌스 프레임워크를 처음 접했는데, 처음엔 단어만 외웠고 실제로 어디에 쓰이는지 몰랐습니다. 그래서 기업 공시 자료와 뉴스에서 IT 거버넌스 관련 사고 사례를 찾아보기 시작했습니다. 금융권 IT 장애 사례에서 변경 관리 절차가 없었던 것이 원인이었다는 기사를 읽으면서, 변경 관리가 거버넌스의 어느 항목에 해당하는지를 다시 프레임워크에서 찾아봤습니다. 처음엔 프레임워크만 보면 너무 추상적이어서 맥락이 안 잡혔는데, 사건과 프레임워크를 교차해서 보니 어디에 어떤 통제가 필요한지가 보이기 시작했습니다. 지금도 IT 관련 장애 뉴스를 보면 어떤 통제가 빠졌기 때문인지를 먼저 생각해보는 편입니다.
인턴 때 IT 운영팀에서 변경 요청 승인 프로세스를 보조했는데, 담당자가 변경 요청 양식에 영향 범위와 롤백 계획을 꼭 적어야 한다고 했습니다. 처음엔 "이게 왜 필요하냐"고 생각했는데, 롤백 계획 없이 서버 설정을 바꿨다가 2시간 서비스 중단이 생긴 사례를 팀에서 공유받았습니다. 그 이후 저는 변경 요청 양식에서 롤백 계획이 비어 있으면 반려하는 체크포인트를 담당자와 함께 추가했습니다. 팀에서 실제로 체크포인트를 추가한 이후 반려된 요청이 4건 나왔고, 그중 2건은 담당자가 롤백 방법을 재검토하면서 설계 자체를 바꾼 케이스였습니다. 처음엔 절차가 번거롭다고만 생각했는데, 이 경험이 통제 절차의 의미를 실감하게 해준 계기가 됐습니다.
학부 캡스톤 프로젝트에서 팀이 만든 웹 서비스에 배포 권한을 3명 모두 갖고 있었는데, 한 팀원이 본인 코드를 직접 배포했다가 전체 서비스가 30분 다운되는 사고가 났습니다. 저는 그 사건을 계기로 IT 거버넌스가 왜 필요한지를 처음으로 실감했습니다. 이후 팀에서 배포 전 리뷰 없이는 프로덕션에 반영 금지라는 규칙을 만들었고, 저는 리뷰어 역할을 맡았습니다. 나머지 프로젝트 기간 동안 동일한 유형의 장애가 없었고, 마지막 발표까지 서비스를 안정적으로 운영했습니다. 거버넌스를 "규정"이 아니라 "실수를 미리 잡는 구조"로 이해하게 된 건 그 다운 사고 덕분이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 경영기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.