프로젝트 오픈은 왜 항상 고통스러울까?

회사에서 반년 간 도맡아 준비했던 프로젝트를 드디어 오픈했다.

 

준비하는 내내 '오픈만 하면 숨 좀 돌릴 수 있겠지'라는 마음이 컸다. 하지만 그건 그저 순진한 바람일 뿐이라는 걸 내심 알고 있었다. 막상 서비스가 라이브 환경에 배포되고 나면, 개발 환경에서는 전혀 예상치 못했던 기상천외한 예외 상황과 기획 수정 요청이 얽히고설켜 오히려 오픈 전보다 일이 더 많아지기 일쑤다.

 

이전 프로젝트 때도 그랬고, 이번에도 마찬가지다. 개발자로 일하는 이상 프로젝트 오픈은 숙명처럼 찾아온다.

나는 이런 숙명을 피할 수 없기에, 왜 매번 이런 고통스러운 상황이 반복되는지, 그리고 어떻게 이 굴레를 끊어낼 수 있을지 한 번쯤 깊게 고민해 볼 필요가 있었다. (물론 고민한다고 당장 모든 게 마법처럼 해결되진 않는다...)

 

 

원인

"테스트할 시간과 자원의 부재"

 

내가 내린 결론은 결국 '테스트 부족'이다.

좀 더 정확히 말하자면, 충분히 테스트할 수 있는 시간과 환경의 부재다. 상황을 복기해 보면 패턴은 늘 비슷하다.

 

1. 일정에 쫓기는 개발: 오픈 일정을 맞추기 위해 바쁘게 기능 구현만 치고 나간다.
2. 테스트의 우선순위 하락: 인력과 시간이 부족하다 보니 자연스럽게 테스트는 뒷전이 된다.
3. 정상적인 흐름 위주의 검증: 다양한 엣지 케이스를 고려하지 못하고, 가장 이상적이고 정상적인 흐름(Happy Path)에서만 기본적인 확인을 거친다.
4. 운영 환경의 변수: 하지만 실제 사용자들은 우리가 예상한 '정상적인 상황'으로만 서비스를 이용하지 않는다.
5. 무한 버그 수정의 굴레: 미처 고려하지 못했던 예외 상황들이 터져 나오며 끊임없는 핫픽스와 수정 작업이 발생한다.

우리가 했던 것 (부족했던 테스트)

• 단편적인 유닛 테스트
• 정상 상황에 대한 E2E 테스트

우리가 했어야 할 것 (이상적인 테스트)

• 촘촘한 커버리지의 유닛 테스트
• 모듈 간의 연결을 확인하는 통합 테스트
• 정상뿐만 아니라 비정상적인(예외) 상황까지 고려한 E2E 테스트

 

해결 방안

이 악순환을 끊기 위한 해결 방안을 효과가 확실한 순서대로 고민해 보았다.

 

1. 충분한 테스트 기간을 포함하여 현실적인 일정 산정하기
2. QA 등 테스트 전문 인력과 자원 확대하기
3. 테스트 자동화 구축하기

 

해결 방안	원인 해결 정도	회사 입장 실현 비용	실무자 입장 실현 비용
테스트 기간 포함 일정 산정	높음	높음	낮음
테스트 인력 및 자원 확대	중간	중간	중간
테스트 자동화 구축	낮음	낮음	높음

 

 

표로 정리해 보니 현실적인 해결책이 더욱 명확해진다. 가장 근본적인 해결책인 '충분한 일정 확보'는 회사의 사업 및 영업상 요구사항과 직결되므로 실현 가능성이 매우 낮다.

 

결국 당장 내가 통제할 수 있는 현실적인 대안은 기존 실무 역량을 활용해 '테스트를 자동화'하는 것이다. 당장 코드를 짜기에도 바쁜 실무자 입장에서는 초기 구축 비용(시간과 노력)이 꽤 높게 들겠지만, 장기적인 평화를 위해서는 피할 수 없는 선택이다.

(당장 코드를 짜기에도 바쁜 실무자는 나다..)

 

 

결론

결국에 답은 자동화다.

 

당장 프레임워크를 설정하고 테스트 코드를 짜는 것이 고생스럽겠지만, 미래의 나를 구원하기 위해서는 결국 테스트 자동화 환경을 고려해야만 한다.

나뿐만 아니라 수많은 회사에서 고군분투하는 개발자들이 비슷한 고민을 거쳤을 것이다. 먼저 이 길을 걸어간 선배 개발자들의 레퍼런스들을 참고하면서, 빠르진 않더라도 내 프로젝트에 맞는 테스트 자동화 방안을 하나씩 적용해 나가며 이 문제를 주도적으로 해결하여 편해져 보려 한다.