이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
자동화 스크립트를 처음 만든 건 수업 과제에서 반복 집계 작업을 Python으로 처리했을 때입니다. pandas와 pathlib을 써서 여러 폴더에 흩어진 파일을 한 번에 읽어 집계하는 스크립트를 만들었습니다.
이후 팀 프로젝트에서도 Git 커밋 이력에서 기여도 통계를 뽑는 작은 스크립트를 만들었는데, subprocess와 정규표현식을 처음으로 직접 조합해봤습니다. 복잡하진 않았지만 "이 도구들을 조합하면 이런 것도 된다"는 자신감이 생겼습니다.
스크립트 개발에서 배운 건 언어보다 "무엇을 자동화하면 팀에 가장 도움이 되는가"를 먼저 아는 것이 중요하다는 점입니다. 단순 반복 작업을 줄이는 것부터 시작해서, 자동화 범위를 점차 넓혀가는 방식이 실용적이라고 봅니다.
자동화 스크립트를 개발할 때 모든 자리를 자동화하는 것이 항상 좋은 결이 아니라는 걸 경험했습니다. 반복적인 데이터 수집은 자동화가 유용했지만, 결과를 해석하고 판단하는 자리는 사람이 확인해야 했습니다.
자동화 이후 스크립트가 예외 케이스를 처리하지 못하는 상황이 생겼고, 사람이 직접 결과를 검토해야 하는 자리가 남아 있었습니다. 자동화가 시간을 아끼는 도구이지, 판단까지 대신하는 결이 아니라는 것을 그 경험에서 배웠습니다. 자동화가 실질적으로 쓰이려면 어디를 자동화하고 어디에 사람이 남아야 하는지를 구분하는 것이 먼저입니다. 그 경계를 정하는 것이 스크립트 개발보다 더 중요한 결이 됩니다.
자동화 범위 판단이 스크립트 개발의 결이라고 생각합니다.
자동화 스크립트를 만든 후 실제로 얼마나 효과가 있었는지를 확인한 경험이 있습니다. 처음에는 "빠르게 됐다"는 느낌만 있었는데, 이전 방식과 처리 시간을 직접 비교해보니 약 70% 절감됐다는 걸 확인했습니다.
이 확인이 중요한 이유는 자동화에 투자한 시간과 자동화로 절약되는 시간을 비교할 수 있어야 다음 자동화 판단에 기준이 생기기 때문입니다. 효과를 측정하지 않으면 자동화가 실제로 유용한지 판단하기 어려운 결이 됩니다. 그 경험 이후로 스크립트를 만들 때 측정 기준을 먼저 생각하는 습관이 생겼습니다. 어떤 지표로 효과를 확인할지를 먼저 정하는 것이 자동화 설계의 출발입니다.
효과 측정이 자동화의 가치를 만드는 결이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 KT 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.