이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
소프트웨어 공학 수업에서 자동 검증 시스템 설계안을 제출하는 과제를 했습니다. 저는 어떤 입력에 대해 어떤 출력이 나와야 하는지를 기준으로 테스트 케이스를 분류하는 방식을 제안했습니다. 교수님이 경계값 검증을 빠뜨렸다는 피드백을 주셨는데, 정상 케이스만 테스트해서는 실제 오류를 잡기 어렵다는 설명이 납득됐습니다. 이후 정상 케이스, 경계값, 예외 케이스 세 범주를 항상 같이 보는 방식으로 바꿨습니다.
검증 품질은 얼마나 많은 케이스를 다루느냐보다 어떤 종류를 다루느냐에 달려 있다는 인식이 생겼습니다. 현업에서 실제 자동화 테스트를 구축하는 경험을 쌓고 싶습니다.
개인 프로젝트에서 간단한 계산 함수에 단위 테스트를 처음으로 작성해봤습니다. 처음에는 함수가 정상 입력에서 맞게 동작하는 케이스만 테스트했는데, 배포 후 음수 입력이 들어올 때 오류가 발생하는 버그가 생겼습니다. 음수 케이스를 테스트에 넣지 않았던 게 원인이었습니다. 이후 입력 범위를 정의하고 범위 바깥 값도 케이스로 추가했습니다.
테스트 케이스를 만들 때 어떤 값이 들어올 수 있는지부터 정의해야 한다는 걸 그 경험으로 배웠습니다. 작은 경험이었지만 자동 검증의 기본 원리를 몸으로 익혔습니다. 음수 케이스를 테스트에 넣지 않았던 게 원인이었습니다. 테스트 케이스를 만들 때 어떤 값이 들어올 수 있는지부터 정의해야 한다는 걸 그 경험으로 배웠습니다.
현업에서 더 체계적인 방식을 익히겠습니다.
인턴 기간에 기능 출시 전 QA 체크리스트를 작성하는 보조 업무를 맡았습니다. 담당자 분이 쓰는 체크리스트를 보니 기능 동작 여부 외에 엣지케이스, 다른 기능과의 충돌, 성능 저하 항목이 따로 있었습니다. 기능이 맞게 동작하는 것만 확인하면 된다고 생각했는데, 다른 기능에 영향을 주는지도 같이 봐야 한다는 걸 그때 알게 됐습니다.
품질 기준이 기능 단위가 아니라 시스템 전체 안정성까지 포함한다는 시각이 생겼습니다. 현업에서 실제 자동 검증 파이프라인이 어떻게 구성되는지 배우고 싶습니다. 기능이 맞게 동작하는 것만 확인하면 된다고 생각했는데, 다른 기능에 영향을 주는지도 같이 봐야 한다는 걸 알게 됐습니다. 품질 기준이 기능 단위가 아니라 시스템 전체 안정성까지 포함한다는 시각이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.