테스트 기간이라는 지옥
코드가 아닌 관리 구조가 문제다.
개발이 끝났다고 프로젝트가 끝나는 게 아니다. 테스트가 시작된다. 프로젝트에서 가장 바쁜 시기, 낮과 밤이 바뀌는 시기가 바로 이때다.
테스트는 출시 전 마지막 관문이다. 고객과 기획자, 그리고 테스트 전문 인력이 대거 투입된다. 개발자가 만든 모든 기능을 실제로 사용해보고, 오류를 찾아내고, 기획서대로 구현됐는지 확인한다. 통과해야 출시가 가능하다.
테스트가 오전부터 진행된다. 오후가 되면 결과가 전달된다. 엑셀 파일 하나가 메일로 온다. 시트를 열면 오류 목록이 빼곡하게 적혀있다. 화면 번호, 재현 경로, 오류 내용, 기대 결과, 실제 결과, 심각도까지.
"회원가입 화면에서 이메일 형식이 잘못됐을 때 오류 메시지가 안 나옴"
"상품 상세에서 옵션 선택 후 장바구니 담기 누르면 빈 페이지로 이동"
"마이페이지 주문내역 클릭 시 로딩 후 아무 반응 없음"
"관리자 화면에서 엑셀 다운로드 버튼 클릭 시 서버 오류 500"
하나하나 읽다 보면 한숨이 나온다. 어제 수정한 부분에서 새로운 오류가 또 생겼다. 분명 테스트했는데 놓친 케이스가 있었다. 다른 개발자가 작업한 부분과 연결되면서 생긴 문제도 있다.
그날 올라온 오류는 그날 수정해야 한다. 다음날 오전에 다시 테스트가 들어가기 때문이다. 엑셀 시트의 오류들을 하나씩 확인하고, 재현하고, 원인을 찾고, 수정한다. 수정이 끝나면 직접 테스트해보고, 문제없으면 배포한다.
오후 3시에 받은 오류 목록을 밤 10시까지 처리하는 게 목표다. 간단한 오류는 금방 고쳐지지만, 복잡한 로직에서 발생한 문제는 원인 파악만 몇 시간이 걸린다. 디버깅을 하며 코드를 한 줄씩 따라가다 보면 어느새 시간이 흘러있다.
테스트 전문 인력은 기획서나 자료 없이 테스트한다. 일반 고객처럼 무작위로 사용해본다. 버튼을 마구 눌러보고, 예상치 못한 순서로 기능을 실행하고, 이상한 값을 입력해본다. 그래서 기획서에 없는 내용도 오류나 황당한 테스트도 오류라고 많이 올라온다.
"상품 검색 후 뒤로가기 누르면 검색어가 사라져야 하는데 남아있음"
"회원가입 중간에 브라우저 닫았다가 다시 열면 입력했던 정보가 그대로 있음"
"이미지 업로드할 때 100MB 넘는 파일은 올라가지 않음"
"상품 상세에서 브라우저를 닫았다가 새로운 브라우저로 열었는데, 같은 상품 상세 페이지가 나오지 않음"????
기획서에는 명시되지 않은 케이스들이다. 일반적으로는 당연히 그렇게 동작해야 한다고 생각할 수 있지만, 개발 단계에서는 기획서에 나온 기능만 구현한다. 예외 처리나 세부 동작은 명시되지 않으면 누락되는 경우가 많다.
이럴 때마다 기획자나 프로젝트 관리자가 하나하나 대응한다. 기획서에 없는 내용이니 오류가 아니라고 설명하거나, 합의를 통해 수정 여부를 결정한다. 개발자는 그 결과를 기다렸다가 수정 대상으로 확정되면 작업에 들어간다.
테스트 기간의 가장 큰 고통은 연쇄 반응이다. 하나의 오류를 수정하면 다른 곳에서 새로운 오류가 생긴다. 공통으로 사용하는 함수를 수정했더니, 그 함수를 쓰는 다른 화면에서 문제가 발생한다. 데이터 구조를 바꿨더니, 연결된 API에서 오류가 난다.
어제 수정한 부분이 오늘 테스트에서 또 오류로 올라온다. 수정했다고 체크했는데 왜 또 나오는지 확인해보면, 수정 과정에서 다른 케이스를 놓쳤거나, 배포가 제대로 안 됐거나, 캐시 문제였거나. 같은 오류를 여러 번 수정하는 일도 비일비재하다.
그래서 테스트 기간에는 모든 수정 사항을 조심스럽게 다룬다. 하나를 고치기 전에 영향 범위를 파악한다. 이 함수가 어디에서 쓰이는지, 이 데이터가 어느 화면까지 전달되는지, 수정하면 어떤 부분에 영향을 줄지 미리 체크한다.
수정 후에는 직접 테스트를 여러 번 한다. 고친 부분만 확인하는 게 아니라, 연관된 기능들도 다 돌려본다. 그래도 놓치는 게 있다. 사람이 하는 일이라 완벽할 수 없다.
테스트 기간 동안은 거의 대부분이 야근이다. 오후에 받은 오류 목록을 그날 안에 처리해야 하는데, 오류가 많으면 정규 시간 안에 끝나지 않는다. 심각도가 높은 오류는 반드시 당일에 수정해야 한다. 다음날 테스트에 영향을 주기 때문이다.
오래 걸리는 수정은 미리 협의한다. 로직을 전면 수정해야 하거나, 데이터 구조를 바꿔야 하는 경우는 2~3일의 시간을 요청한다. 그 외에는 당일 처리가 원칙이다.
오후 3시에 오류 목록을 받아서 밤 10시까지 수정하고, 배포하고, 간단히 테스트한다. 퇴근은 11시나 12시가 된다. 집에 가서 씻고 자면 새벽 2시, 아침 8시에 다시 출근한다. 이 패턴이 테스트 기간 내내 반복된다.
테스트가 2주 정도 진행되면 체력이 바닥난다. 낮과 밤이 바뀐다는 말이 과장이 아니다. 오전에는 멍한 상태로 메일 확인하고, 회의하고, 오후에 받을 오류 목록을 기다린다. 개발은 오후부터 밤까지 이어진다. 집에 못 들어간 날도 있다. 사무실에서 쪽잠을 자고, 씻지도 못하고 다음날 아침을 맞는다.
건강도 해친다. 제대로 된 식사를 못한다. 점심은 간단히 때우고, 저녁은 야근하며 배달 음식으로 해결한다. 커피를 달고 산다. 잠이 부족하니 집중력도 떨어진다. 집중력이 떨어지니 실수가 늘고, 실수가 늘면 오류가 더 생긴다. 악순환이다.
그래서 가능하면 야근을 하지 않으려고 노력한다. 평소에 일정을 잘 지키고, 개발할 때 꼼꼼하게 테스트하고, 코드 리뷰를 받고, 공통 함수는 신중하게 수정한다. 테스트 기간이 짧아지면 야근도 줄어들것 같지만, 꼼꼼하게 오류 없이 개발하면 다른 요구사항이 들어올 수 있다. - 테스트 기간에 요구사항을 수정하거나 기획이 바뀌는건 인간이라면 할 짓이 아니라고 생각한다. -
모든 오류를 당일에 수정할 수는 없다. 우선순위를 정한다. 심각도가 높은 오류, 즉 서비스가 멈추거나 데이터가 잘못 저장되는 문제는 최우선으로 처리한다. 화면이 깨지거나 문구가 틀린 정도는 나중에 처리한다.
기획자, 프로젝트 관리자와 계속 협의한다. 이 오류는 당장 고쳐야 하는지, 다음 버전으로 미뤄도 되는지, 아예 제외해도 되는지. 테스트 일정과 출시 일정을 고려해서 결정한다.
때로는 타협도 한다. 완벽하게 고치려면 시간이 오래 걸리는 경우, 임시방편으로 처리하고 출시 후에 재작업하기로 합의한다. 이상적이지는 않지만, 일정을 맞추기 위해 불가피한 선택이다.
고객도 이해하려고 노력은 한다. 완벽한 시스템은 없다는 걸 알지만 모든 기능이 되야함은 변함이 없다. 막판에는 치명적인 오류만 없으면 일단 출시하고 개선하는 방향으로 선택한다. 중요한 건 일정을 지키는 것이다.
테스트가 끝나면 모두가 지쳐있다. 개발자도, 기획자도, 테스트 인력도, 고객도. 하지만 안도하지 않는다. 오히려 더 긴장된다. 진짜 전쟁은 이제부터다.
테스트 환경과 실제 환경은 다르다는 걸 개발자들은 인지하고 있다. 소수의 테스터가 아닌 수천, 수만 명의 사용자가 동시에 접속하면 어떤 일이 벌어질지 모른다. 테스트에서는 정상적인 시나리오와 소수의 테스터들의 무작위만 확인했지만, 실제 사용자들은 예상 밖의 행동을 한다.
출시일이 다가올수록 불안해진다. 혹시 놓친 케이스가 있지 않을까. 서버가 트래픽을 감당할 수 있을까. 결제 연동은 문제없을까. 밤에 장애가 나면 누가 대응하나. 출시 후 운영 체계는 제대로 갖춰졌나.
회식 자리는 축하보다 긴장감이 감돈다. 술을 마시면서도 폰을 들여다본다. 출시 후 모니터링 방법을 다시 확인한다. 장애 대응 매뉴얼을 점검한다. 긴급 연락망을 재확인한다.
테스트가 끝났다고 끝난 게 아니다. 이제 시작이다. 실제 사용자들이 쓰기 시작하면 또 다른 오류가 발견될 것이다. 테스트에서는 못 찾은 예외 상황, 많은 사용자가 동시에 접속했을 때의 문제, 다양한 브라우저와 환경에서 발생하는 이슈들.
출시 버튼을 누르는 순간, 심장이 빨리 뛴다. 이제 돌이킬 수 없다. 모니터링 화면을 주시한다. 에러 로그가 올라오지 않기를 기도한다. 첫 주문이 정상적으로 처리되는지 확인한다. 서버 부하가 정상 범위인지 체크한다.
출시 후 며칠은 폰을 끼고 산다. 새벽에도 알람이 올 수 있다. 주말에도 긴급 호출이 들어올 수 있다. 안정화될 때까지는 긴장을 풀 수 없다.
경험이 쌓이면서 배운 게 있다. 테스트 기간을 줄이는 방법은 없다.
화면 설계서를 아무리 꼼꼼히 읽어도 소용없다. 개발 단계에서 모든 케이스를 생각하고, 예외 처리를 철저히 해도 마찬가지다. 단위 테스트를 꼼꼼히 하고, 코드 리뷰를 받고, 영향 범위를 파악해도 테스트 기간은 지옥이다.
문제는 코드의 버그도 있겠지만, 더 큰 문제가 있기 때문이다.
테스트 막바지에 기획이 바뀐다. 고객이 갑자기 새로운 아이디어를 낸다. "이 기능 하나만 추가하면 안 될까요? 간단한 건데." 간단하지 않다!. 화면 하나를 추가하려면 데이터 구조부터 다시 봐야 하고, 연관된 기능들을 다 수정해야 한다.
요구사항이 추가된다. "원래 이 부분은 이렇게 하기로 했었는데 기억 안 나세요?" 기획서 어디에도 없는 내용이다. 하지만 고객은 분명히 얘기했다고 한다. 회의록을 뒤져봐도 흔적이 없다. 결국 추가 개발로 들어간다.
경쟁사 서비스를 보고 온 고객이 말한다. "저기는 이런 기능이 있던데 우리도 넣을 수 있나요?" 출시 일주일 전이다. 불가능하다고 말해도 소용없다. 일정을 늦추거나, 밤을 새워서라도 넣어야 한다.
개발 단계를 아무리 철저히 해도, 기획자와 아무리 자주 소통해도, 이런 외부 변수는 막을 수 없다. 테스트 기간의 지옥은 코드 품질 문제가 아니라 프로젝트 관리의 구조적 문제다.
그리고 무엇보다, 테스트 기간을 잘 견딘다고 끝나는 게 아니다. 출시는 또 다른 지옥의 시작이다. 실제 사용자들이 몰려오면 테스트에서는 발견하지 못한 문제들이 쏟아진다. 서버 부하, 동시 접속 처리, 예상 못한 사용 패턴, 다양한 환경에서의 호환성 문제.
출시 후 일주일은 테스트 기간보다 더 긴장된다. 새벽에도 장애 알람이 온다. 주말에도 긴급 대응이 필요하다. 안정화될 때까지 몇 주가 걸린다.
25년 동안 수많은 테스트 기간을 거쳤다. 엑셀 시트 가득한 오류 목록, 밤을 새우며 고친 코드, 다음날 또 올라온 같은 오류. 막판에 추가된 기획, 출시 직전의 요구사항 변경. 그리고 출시 후의 장애 대응.
지나고 보면 추억이라고 말할 수도 없다. 그냥 견뎌낸 시간일 뿐이다. 지금도 테스트 기간이 다가오면 긴장된다. 이 시기를 잘 견뎌도, 출시 후 또 다른 지옥이 기다리고 있다.
테스트 기간은 테스트만 하라고 정해둔 기간이다. 요구사항이나 기획을 바꾸라고 정해둔 기간이 아니다. 기획이 바뀌면 테스트를 다시해야한다.
하지만 오픈 일정은 변하지 않는다.
…개발자의 삶은 그렇다.
