1단계: 제약 조건의 변경 (Change the Constraints)
소프트웨어 개발에서 ‘불가능’은 대개 여러 제약 조건이 얽혀 있을 때 발생합니다. Aha! Develop의 TestRail 확장 기능을 개발할 때, 백엔드 Lambda의 실행 시간은 10초로 제한되어 있었으나 API 호출에는 최대 60초가 소요되는 상황이었습니다. 이를 해결하기 위해 단일 Lambda에서 모든 작업을 처리하려던 기존의 제약을 버리고, 호출을 여러 인스턴스로 분산하여 각 인스턴스가 하나의 API만 담당하도록 구조를 변경했습니다. 이처럼 내가 제어할 수 없는 외부 제약(API 타임아웃)과 제어할 수 있는 내부 제약(Lambda 구조)을 구분하는 것이 문제 해결의 첫걸음입니다.
2단계: 어려운 부분은 과감히 생략하기 (Don’t Do the Hard Part)
모든 엣지 케이스를 완벽하게 해결하려는 시도는 종종 프로젝트를 마비시킵니다. TestRail의 특정 테스트 런이 전체 테스트 케이스의 하위 집합만 포함하는 드문 사례를 처리하려다 보니 성능 저하가 발생했습니다. 이를 해결하기 위해 모든 데이터를 미리 로드하는 대신, 사용자가 특정 런을 선택했을 때만 데이터를 로드하고 일치하지 않으면 에러 메시지를 보여주는 방식을 택했습니다. 또한, 제품 관리자(PM)와의 긴밀한 소통을 통해 ‘이름 검색’과 같은 핵심 요구사항을 파악하고, 불필요한 기능 구현에 낭비되는 시간을 줄여야 합니다. 완벽함보다는 적시 배포가 더 높은 가치를 가질 때가 많습니다.
3단계: 해결 방식의 전면 수정 (Change Your Solution)
특정 방식에 매몰되어 더 이상 진전이 없을 때는 ‘지역 최적점’에 갇힌 것일 수 있습니다. 이때는 작성하던 코드를 잠시 내려놓고 완전히 다른 접근 방식을 고민해야 합니다. 동료에게 문제를 설명하는 ‘고무 오리 디버깅’을 활용하거나, AI의 도움을 받거나, 산책을 통해 뇌를 환기하는 것이 도움이 됩니다. 때로는 해결책을 약간 수정하는 것보다 아예 처음부터 다시 설계하는 것이 더 빠를 수 있습니다.
4단계: 중단 및 재정비 (Stop and Regroup)
모든 시도에도 불구하고 해결이 불가능하다면, 현재의 기술적 수준이나 우선순위에서 적절하지 않은 문제일 수 있습니다. 2022년에 중단되었던 TestRail 확장 기능 개발이 2025년에 성공할 수 있었던 이유는 과거의 개발자가 남긴 상세한 분석 문서 덕분이었습니다. 당장 문제를 해결하지 못하더라도, 왜 실패했는지와 무엇을 배웠는지를 기록해 두면 미래의 팀원이나 본인에게 결정적인 단서가 됩니다.
5단계: 끈기와 반복적 개선 (Keep Going)
문제를 계속 진행하기로 했다면, 거대한 과제를 아주 작은 단위로 쪼개어 하나씩 정복해 나가야 합니다. 첫 번째 버전이 성능이 낮거나 버그가 있더라도 실망하지 않고, 사용자 피드백을 받으며 지속적으로 개선하는 과정이 필요합니다. 필자 역시 6개월 동안 다섯 번 이상의 설계를 변경하며 성능 이슈를 해결해 나갔습니다. 팀원들과 진행 상황을 공유하고 작은 성취를 축하하며 심리적 동력을 유지하는 것도 엔지니어링의 중요한 부분입니다.