한 신입 개발자의 포트폴리오를 검토하면서 프로젝트에서 테스트를 어떻게 진행했는지 질문한 적이 있습니다. 학생은 기능을 완성한 뒤 화면을 직접 눌러보며 모두 확인했다고 답했습니다. 회원가입과 로그인, 게시글 작성 기능이 정상적으로 동작했고 발표에서도 오류가 발생하지 않았기 때문에 충분히 검증했다고 생각했습니다.
추가로 회원가입에서 비밀번호를 입력하지 않거나 이미 가입된 이메일을 사용하면 어떻게 되는지 물었습니다. 학생은 정상적인 정보만 입력해 봤기 때문에 해당 상황은 확인하지 않았다고 답했습니다. 실제로 빈 비밀번호를 입력하자 화면에서는 가입이 거부되었지만 서버에 직접 요청하면 비밀번호가 없는 계정이 생성되었습니다. 프런트엔드에서만 입력값을 검사하고 서버에서는 같은 조건을 확인하지 않은 것이 원인이었습니다.
문제를 수정한 뒤에도 새로운 오류가 나타났습니다. 서버의 검증 방식을 변경하면서 기존 테스트 계정의 로그인 요청까지 실패한 것입니다. 학생은 회원가입 오류를 고친 사실만 확인했지만 관련된 로그인과 사용자 정보 조회 기능은 다시 점검하지 않았습니다. 하나의 코드를 변경하면 연결된 기능에도 영향이 생길 수 있다는 점을 놓친 사례였습니다.
신입 개발자에게 테스트 경험이 필요한 이유는 프로젝트에서 오류가 하나도 발생하지 않았다고 주장하기 위해서가 아닙니다. 어떤 조건에서 기능이 실패할 수 있는지 예상하고, 변경 전후의 결과를 비교하며, 수정이 다른 기능에 미친 영향까지 확인할 수 있는지 보여주기 위해서입니다.
자동화 도구를 많이 사용하지 않았더라도 정상 조건과 예외 조건을 구분하고, 재현 가능한 방식으로 결과를 기록했다면 충분한 경험이 됩니다. 중요한 것은 테스트 개수가 아니라 코드가 어디까지 의도대로 동작하는지 근거를 가지고 설명하는 능력입니다.
품질관리는 정상 화면 밖의 조건을 확인하는 과정입니다
- 정상적인 입력만 확인하면 중요한 오류를 놓칠 수 있습니다
기능을 구현한 개발자는 자신이 예상한 순서대로 값을 입력하고 결과를 확인하는 경향이 있습니다. 회원가입에서는 올바른 이메일과 비밀번호를 입력하고, 게시글 작성에서는 제목과 내용을 모두 작성하며, 결제에서는 정상적인 수량을 선택합니다.
하지만 실제 사용자는 개발자가 예상한 방식으로만 행동하지 않습니다. 필수 입력값을 비워두거나 허용된 길이를 넘길 수 있고, 버튼을 빠르게 여러 번 누르거나 이전 화면으로 돌아갈 수도 있습니다. 잘못된 행동뿐 아니라 네트워크 연결이 끊기거나 서버 응답이 늦어지는 상황도 발생합니다.
한 쇼핑 프로젝트에서는 장바구니 수량을 변경하는 기능이 정상적으로 동작했습니다. 학생은 수량을 1개에서 2개로 바꾸고 총금액이 달라지는 것을 확인했습니다. 그러나 수량 입력창에 0이나 음수, 매우 큰 숫자를 넣는 상황은 점검하지 않았습니다.
실제로 수량을 0으로 변경해도 상품이 장바구니에 남았고 총금액은 0원으로 표시되었습니다. 음수를 입력하면 전체 금액이 줄어드는 문제도 있었습니다. 화면과 서버 모두 수량의 허용 범위를 정하지 않은 것이 원인이었습니다.
- 정상 조건: 수량을 1개에서 2개로 변경하면 상품 금액과 전체 금액이 다시 계산됩니다.
- 경계 조건: 최소 수량인 1개와 최대 허용 수량에서 정상적으로 저장되는지 확인합니다.
- 실패 조건: 0, 음수, 문자, 허용 범위를 넘긴 값을 입력하면 저장되지 않고 적절한 안내가 표시되는지 점검합니다.
기능 하나를 검증할 때도 정상 동작만 확인하지 말고 입력값의 경계와 비어 있는 상태, 잘못된 형식, 반복 요청을 함께 살펴봐야 합니다. 이러한 습관이 있어야 사용자의 다양한 행동을 고려한 품질관리 경험으로 발전합니다.
- 화면 결과와 실제 데이터 상태를 함께 확인해야 합니다
버튼을 눌렀을 때 성공 안내가 나타난다고 해서 모든 처리가 정상적으로 끝난 것은 아닙니다. 화면은 성공으로 표시되었지만 서버에서 저장에 실패할 수 있고, 데이터는 저장되었지만 화면이 갱신되지 않을 수도 있습니다.
한 팀 프로젝트에서는 게시글 삭제 버튼을 누르면 목록에서 해당 게시글이 사라졌습니다. 프런트엔드 담당자는 기능이 정상적으로 작동한다고 판단했습니다. 그러나 페이지를 새로 열자 삭제한 게시글이 다시 나타났습니다. 화면의 목록에서만 항목을 제거했고 서버에는 삭제 요청이 전달되지 않았기 때문입니다.
반대 상황도 발생할 수 있습니다. 서버에서는 게시글이 정상적으로 삭제되었지만 화면 상태가 갱신되지 않아 사용자는 계속 게시글이 남아 있다고 생각할 수 있습니다. 따라서 검증할 때는 화면 변화와 서버 응답, 데이터베이스 상태를 구분해야 합니다.
확인해야 할 기준:
- 사용자의 동작 이후 화면이 예상대로 변경되는가
- 요청이 올바른 주소와 값으로 전달되는가
- 서버가 성공과 실패를 정확한 응답으로 구분하는가
- 데이터베이스의 값이 실제로 생성·수정·삭제되는가
- 페이지를 다시 열어도 변경된 상태가 유지되는가
- 처리에 실패했을 때 화면이 성공으로 표시되지 않는가
개인 프로젝트에서 모든 계층을 정교한 도구로 검사하지 못하더라도 브라우저의 네트워크 기록과 서버 로그, 데이터베이스 값을 비교할 수 있습니다. 화면에 보이는 결과만 확인하는 것보다 데이터가 이동하는 흐름을 따라 점검하면 기능에 대한 이해도도 높아집니다.
- 완료 기준은 기능을 만들기 전에 정하는 편이 좋습니다
개발을 끝낸 뒤 무엇을 확인할지 생각하면 이미 구현한 방식에 맞춰 정상적인 결과만 찾기 쉽습니다. 기능을 시작하기 전에 사용자 행동과 예상 결과를 정리하면 빠뜨린 조건을 더 일찍 발견할 수 있습니다.
한 프로젝트에서는 댓글 작성 기능을 구현한 뒤에야 비회원의 접근, 빈 댓글, 최대 글자 수, 삭제된 게시글에서의 작성 여부를 논의했습니다. 각 조건을 추가할 때마다 화면과 서버 코드를 다시 수정해야 했고 일정도 늦어졌습니다.
개발 전 확인 항목:
- 로그인한 사용자는 댓글을 작성할 수 있습니다.
내용이 비어 있으면 저장되지 않습니다.
최대 글자 수를 넘기면 입력 단계에서 안내합니다.
삭제되었거나 존재하지 않는 게시글에는 작성할 수 없습니다.
저장에 성공하면 새로운 댓글이 목록에 표시됩니다.
저장에 실패하면 입력 내용이 유지되고 오류 원인을 안내합니다.
이처럼 예상 결과를 먼저 정리하면 화면에서 필요한 상태와 서버에서 검사할 조건, 응답 방식까지 함께 생각할 수 있습니다. 테스트는 개발이 끝난 뒤 오류를 찾는 마지막 단계만을 의미하지 않습니다. 기능의 완료 기준을 미리 구체화해 구현 과정에서 빠질 수 있는 조건을 발견하는 활동이기도 합니다.
오류방지는 수정한 부분과 연결된 기능을 다시 보는 데서 시작됩니다
- 발생한 오류를 같은 조건에서 재현할 수 있어야 합니다
오류가 발생했을 때 바로 코드를 수정하면 원인을 잘못 판단할 수 있습니다. 어떤 사용자와 데이터, 화면, 실행 환경에서 문제가 나타났는지 확인하지 않으면 수정 후에도 같은 문제가 해결되었는지 판단하기 어렵습니다.
한 학생의 게시판 프로젝트에서는 특정 게시글만 상세 화면이 열리지 않았습니다. 학생은 서버가 불안정하다고 생각해 여러 번 재시작했지만 문제는 계속되었습니다. 정상 게시글과 실패한 게시글의 데이터를 비교하자 오류가 발생한 게시글에만 첨부파일 정보가 비어 있었습니다.
화면에서는 첨부파일이 항상 존재한다고 가정하고 파일 이름을 읽었습니다. 정보가 없는 경우를 처리하지 않아 화면 전체가 중단된 것입니다. 학생은 값이 비어 있을 때 첨부 영역을 표시하지 않도록 수정한 뒤 첨부파일이 있는 게시글과 없는 게시글을 각각 확인했습니다.
- 모호한 오류 기록: 일부 게시글에서 오류가 발생해 코드를 수정했습니다.
- 재현 조건이 포함된 기록: 첨부파일이 없는 게시글의 상세 화면에 접근하면 파일 이름을 읽는 단계에서 오류가 발생했습니다.
- 검증 결과가 포함된 기록: 첨부파일이 있는 게시글과 없는 게시글을 같은 환경에서 비교해 값이 비어 있는 조건을 찾았습니다. 예외 처리를 추가한 뒤 두 유형의 게시글과 잘못된 게시글 주소까지 다시 확인했습니다.
재현할 때는 다음 내용을 기록하는 것이 좋습니다.
- 오류가 발생한 화면과 기능
- 사용한 계정과 권한
- 입력하거나 선택한 데이터
- 오류 직전까지 수행한 순서
- 화면과 서버에 나타난 결과
- 같은 방법을 반복했을 때의 발생 여부
이 내용이 있으면 다른 팀원도 같은 상황을 확인할 수 있고, 수정 이후 동일한 조건으로 결과를 비교할 수 있습니다.
- 하나의 수정이 다른 기능에 미치는 영향도 확인해야 합니다
오류가 발생한 기능만 고친 뒤 정상적으로 동작하면 작업을 끝냈다고 생각하기 쉽습니다. 그러나 여러 기능이 같은 코드와 데이터 구조를 사용한다면 하나의 변경이 다른 화면에도 영향을 줄 수 있습니다.
한 백엔드 프로젝트에서는 사용자 정보를 안전하게 보호하기 위해 API 응답에서 비밀번호 필드를 제외했습니다. 회원정보 조회 기능은 정상적으로 개선되었지만 관리자 페이지의 사용자 목록이 열리지 않았습니다. 관리자 화면에서도 같은 응답 객체를 사용하면서 기존 필드가 존재한다고 가정한 코드가 남아 있었기 때문입니다.
학생은 회원정보 화면만 확인한 뒤 수정을 완료했다고 판단했습니다. 이후 관리자 기능의 오류를 발견하면서 동일한 데이터 구조를 사용하는 위치를 찾아 다시 점검했습니다.
- 수정 전 확인: 변경할 코드와 데이터를 사용하는 기능을 검색합니다.
- 수정 직후 확인: 처음 발생한 오류가 같은 조건에서 해결되었는지 살펴봅니다.
- 관련 기능 확인: 같은 함수, 응답 구조, 데이터베이스 테이블을 사용하는 화면을 점검합니다.
- 최종 확인: 정상 조건과 실패 조건을 다시 실행하고 새로운 오류가 발생하지 않았는지 확인합니다.
이러한 검증을 회귀 테스트라고 설명할 수 있지만 용어만 알고 있는 것보다 실제 프로젝트에서 어떤 관련 기능을 다시 살펴봤는지가 중요합니다. 큰 자동화 체계를 만들지 않았더라도 변경 영향 범위를 찾고 핵심 기능을 다시 실행한 경험은 오류방지 태도를 보여줍니다.
- 수정 전후를 같은 기준으로 비교해야 결과가 남습니다
테스트 결과를 정상 또는 실패로만 기록하면 무엇이 달라졌는지 확인하기 어렵습니다. 수정 전의 현상과 조건, 수정한 내용, 같은 조건으로 다시 확인한 결과를 연결해야 합니다.
한 프로젝트에서는 상품 검색이 느리다는 문제가 있었습니다. 학생은 데이터베이스 조회 코드를 변경한 뒤 체감상 빨라졌다고 판단했습니다. 그러나 데이터 수와 검색어가 달랐기 때문에 개선 효과를 객관적으로 설명하기 어려웠습니다.
학생은 동일한 데이터와 검색어를 준비하고 여러 번 요청해 응답 시간을 비교했습니다. 검색 결과가 정확히 같은지도 함께 확인했습니다. 속도가 빨라졌더라도 검색 결과가 누락된다면 성공적인 개선으로 볼 수 없기 때문입니다.
비교할 항목:
- 수정 전후에 같은 실행 환경을 사용했는가
- 동일한 데이터와 입력 조건으로 확인했는가
- 속도뿐 아니라 결과의 정확성도 점검했는가
- 한 번의 결과가 아니라 반복된 결과를 비교했는가
- 개선 과정에서 다른 기능이 느려지거나 실패하지 않았는가
모든 개인 프로젝트에서 정밀한 성능 측정을 할 필요는 없습니다. 다만 변경 전후의 조건이 다르다면 결과를 직접 비교하기 어렵다는 점은 이해해야 합니다. 같은 기준을 사용한 기록이 있어야 수정의 효과를 면접과 포트폴리오에서도 구체적으로 설명할 수 있습니다.
코드신뢰도는 검증 범위와 한계를 설명할 때 높아집니다
- 자동화는 반복할 가치가 있는 항목부터 시작해야 합니다
테스트 자동화를 어려운 프레임워크부터 배워야 하는 별도의 영역으로 생각하는 신입 개발자가 많습니다. 그러나 자동화의 출발점은 반복해서 확인해야 하는 조건을 코드로 실행할 수 있게 만드는 것입니다.
한 학생은 계산 기능이 포함된 프로젝트에서 할인 금액을 화면으로만 확인했습니다. 정상 가격과 할인율을 입력했을 때는 문제가 없었지만 할인율이 0이거나 100을 넘는 경우, 가격이 음수인 경우는 매번 직접 입력해야 했습니다.
학생은 할인 금액을 계산하는 함수를 분리한 뒤 다음 조건을 코드로 확인했습니다.
- 정상 가격과 할인율에서 예상 금액이 반환되는가
- 할인율이 0이면 원래 가격이 유지되는가
- 허용된 최대 할인율에서 올바르게 계산되는가
- 음수 가격과 범위를 넘긴 할인율은 거부되는가
- 소수점이 발생할 때 정해진 기준으로 처리되는가
작은 함수 하나라도 여러 조건을 반복 검증하는 코드를 작성하면 수정 후 결과를 빠르게 확인할 수 있습니다. 이후 서비스 로직과 API로 범위를 넓혀갈 수 있습니다.
자동화 경험을 설명할 때는 테스트 개수나 코드 커버리지 수치만 강조하지 않아야 합니다. 어떤 오류가 반복될 가능성이 있었고 왜 해당 항목을 자동으로 확인했는지가 함께 보여야 합니다.
- 테스트 데이터와 실행 환경도 기록해야 결과를 재현할 수 있습니다
같은 코드를 실행하더라도 데이터와 환경이 다르면 결과가 달라질 수 있습니다. 개발자의 컴퓨터에서는 이미 필요한 데이터가 존재하지만 다른 팀원의 데이터베이스는 비어 있을 수 있습니다. 실행 순서에 따라 앞선 테스트에서 만든 값이 다음 결과에 영향을 줄 수도 있습니다.
한 프로젝트에서는 회원가입 중복 검사가 어떤 날에는 성공하고 어떤 날에는 실패했습니다. 테스트가 시작되기 전에 데이터베이스에 같은 이메일이 남아 있는지에 따라 결과가 달라졌기 때문입니다. 학생은 코드가 불안정하다고 생각했지만 실제 문제는 테스트 데이터를 일정하게 준비하지 않은 데 있었습니다.
팀은 각 검증에 필요한 초기 데이터를 정하고 실행 후 생성된 데이터를 제거했습니다. 테스트용 계정과 일반 계정을 구분하고, 기능마다 필요한 권한과 상태도 기록했습니다.
기록해야 할 조건:
- 사용한 실행 환경과 주요 버전
- 시작 전에 필요한 데이터 상태
- 검증에 사용하는 계정과 권한
- 외부 API나 파일처럼 결과에 영향을 주는 요소
- 실행 순서에 따라 달라질 수 있는 데이터
- 확인 이후 원래 상태로 되돌리는 방법
이러한 기록은 자동화된 검증뿐 아니라 직접 화면을 확인하는 과정에도 필요합니다. 조건이 분명해야 다른 사람이 결과를 재현할 수 있고 오류가 코드 때문인지 데이터와 환경 때문인지 구분할 수 있습니다.
- 확인한 범위와 남은 한계를 구분해야 신뢰를 얻습니다
프로젝트에 테스트를 적용했다고 해서 모든 오류를 방지할 수 있는 것은 아닙니다. 오히려 어떤 범위를 확인했고 어떤 부분은 검증하지 못했는지 설명하는 태도가 코드에 대한 신뢰를 높일 수 있습니다.
한 팀 프로젝트에서는 주문 기능의 서비스 로직을 자동으로 검증했지만 실제 결제 서비스와 연결되는 구간은 테스트하지 못했습니다. 학생은 처음에는 주문 기능 전체를 검증했다고 설명했습니다. 그러나 추가 질문에서 외부 결제 실패와 네트워크 지연 상황은 확인하지 않았다는 사실이 드러났습니다.
답변을 수정하면서 검증한 범위를 구분했습니다.
- 확인한 범위: 상품 재고가 충분한 경우와 부족한 경우, 중복 주문 요청, 주문 금액 계산, 권한이 없는 사용자의 접근을 확인했습니다.
- 확인하지 못한 범위: 실제 결제 서비스의 응답 지연과 중단 상황, 배포 환경에서 여러 사용자가 동시에 주문하는 상황은 검증하지 못했습니다.
- 다음 개선 방향: 외부 결제 응답을 대신하는 데이터를 활용해 성공과 실패 상황을 분리하고, 동시 요청이 재고에 미치는 영향을 추가로 확인할 계획을 세웠습니다.
모든 부분을 검증했다고 과장하는 것보다 범위와 한계를 구분하는 편이 좋습니다. 자신이 확인한 결과를 정확하게 설명하고 다음으로 필요한 검증을 알고 있다면 프로젝트를 책임 있게 바라보는 태도를 보여줄 수 있습니다.
- conclusion
신입 개발자에게 테스트 경험이 필요한 이유는 오류 없는 프로젝트를 만들었다고 주장하기 위해서가 아닙니다. 기능이 어떤 조건에서 정상적으로 동작하고 어디에서 실패할 수 있는지 확인하며, 수정한 코드가 다른 기능에 미친 영향까지 살펴봤다는 근거를 만들기 위해서입니다.
품질관리는 완성된 화면을 한 번 실행하는 것으로 끝나지 않습니다. 정상적인 입력뿐 아니라 빈 값과 경곗값, 잘못된 형식, 권한이 없는 요청을 확인해야 합니다. 화면의 변화와 서버 응답, 실제 데이터 상태가 일치하는지도 살펴볼 필요가 있습니다.
오류를 방지하려면 발생 조건을 재현하고 수정 전후를 같은 기준으로 비교해야 합니다. 하나의 코드가 변경되었다면 같은 함수와 데이터 구조를 사용하는 관련 기능도 다시 확인해야 합니다.
- 정상 조건과 실패 조건을 기능별로 구분합니다.
- 오류가 발생한 계정, 데이터, 실행 순서를 기록합니다.
- 수정 전후를 동일한 환경과 입력값으로 비교합니다.
- 변경된 코드와 연결된 다른 기능을 다시 확인합니다.
- 반복할 가치가 높은 검증 항목부터 자동화합니다.
- 확인한 범위와 검증하지 못한 한계를 구분합니다.
실제 포트폴리오를 살펴보면 테스트 도구를 사용했다는 내용은 있지만 무엇을 검증했는지 설명하지 못하는 경우가 있습니다. 테스트 코드의 개수와 커버리지 수치는 보이지만 어떤 오류를 예상했고 실패 결과를 어떻게 해석했는지는 빠져 있기도 합니다.
반대로 복잡한 도구를 많이 사용하지 않았더라도 회원가입의 정상·중복·빈 입력 조건을 구분하고, 수정 후 로그인과 권한 기능까지 다시 확인했다면 구체적인 경험이 됩니다. 검증 기준과 결과를 설명할 수 있기 때문입니다.
자신의 프로젝트에서 가장 중요한 기능 하나를 선택해 보세요. 정상적으로 사용하는 상황만 확인하지 말고 입력값이 비어 있을 때, 권한이 없을 때, 같은 요청이 반복될 때, 서버 처리에 실패했을 때의 결과를 정리해야 합니다.
결국 테스트 경험이 실무 역량으로 보이는 순간은 테스트 코드를 작성했다고 말할 때가 아닙니다. 오류가 발생할 조건을 예상하고, 재현 가능한 방법으로 결과를 확인하며, 변경된 코드가 어디까지 신뢰할 수 있는지 근거와 한계로 설명할 수 있을 때입니다.
