이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
주니어 1년차 때 사내에서 오래된 신청 시스템을 손보는 일을 도운 경험이 있습니다. 처음에는 제 눈에 낡아 보이는 부분부터 고치려 했습니다. 그런데 사수님이, 먼저 실제로 쓰는 사람들에게 무엇이 불편한지 물어보라고 했습니다. 동료 여덟 명 정도에게 물어보니, 제가 생각한 부분이 아니라 신청 후 결과를 못 보는 것이 가장 큰 불만이었습니다. 그래서 저는 진행 상태를 보여주는 화면부터 더했습니다. 처음에는 고도화를 내가 보기에 낡은 걸 바꾸는 일로 여겼는데, 쓰는 사람의 불편에서 출발해야 한다는 걸 배웠습니다. 지금도 저는 시스템을 손보기 전에 쓰는 사람의 말부터 듣습니다.
인턴 때 한 내부 도구 개선 작업을 도우면서, 저는 처음에 전부 한꺼번에 새로 만들자고 생각했습니다. 그런데 사수님이, 한 번에 다 바꾸면 문제가 생겼을 때 어디가 원인인지 못 찾는다고 알려주셨습니다. 그래서 저희는 도구를 기능 단위로 나눠, 한 부분씩 차례로 바꿨습니다. 한 부분을 바꾸고 문제가 없는지 확인한 다음 다음으로 넘어갔습니다. 실제로 중간에 한 번 오류가 났을 때, 바로 직전에 바꾼 부분만 보면 돼 금방 찾았습니다. 처음에는 한 번에 끝내는 게 빠른 줄 알았는데, 작게 나눠 바꾸는 쪽이 결국 안전하고 빠르다는 걸 배웠습니다. 지금도 저는 큰 변경은 조각으로 나눠 진행합니다.
주니어 2년차 때 사내 도구의 한 기능을 고도화한 뒤, 그게 정말 나아졌는지 확인한 경험이 있습니다. 처음에는 고치면 당연히 좋아진 줄 알았는데, 사수님이 '무엇으로 좋아졌다고 말할 거냐'고 물으셨습니다. 그래서 저는 고치기 전후로, 그 기능을 쓰는 데 걸리는 시간을 각각 열 번씩 재봤습니다. 평균이 절반 가까이 줄어든 게 숫자로 보였습니다. 그 숫자가 있으니 보고할 때도 분명했고, 다음에 무엇을 더 손볼지도 정하기 쉬웠습니다. 처음에는 고도화는 고치는 데서 끝인 줄 알았는데, 무엇이 얼마나 나아졌는지 확인해야 진짜 끝이라는 걸 배웠습니다. 지금도 저는 개선 작업에 전후 비교를 함께 둡니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 Tmap Mobility SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.