전자서명을 직접 만들지 않고도 어려운 일은 남았다

21앤의 전자계약에서는 전자서명을 자체 구현하지 않고 모두싸인을 연동했다. 앱과 API, 관리자 화면, 인프라를 함께 다루는 조건에서 문서 서명까지 직접 만드는 것은 유지보수 범위를 크게 늘리는 선택이었다. 이미 필요한 기능을 제공하는 서비스를 사용하는 쪽으로 경계를 잡았다.

맡길 수 있는 것과 남는 것

서명 서비스를 사용한다고 우리 제품의 계약 상태까지 자동으로 정리되지는 않는다. 어느 문서가 어느 계약에 해당하는지, 사용자가 현재 어디까지 진행했는지, 외부 결과를 우리 화면에 어떻게 반영하는지는 여전히 제품의 책임이다.

당시 공개 사례에는 모두싸인 연동과 계약·포인트·정산의 연결을 기록했다. 지금 돌아보면 외부 API 호출 성공을 기능 완료와 혼동하지 않는 것이 핵심이었다. 문서 생성 요청이 받아들여진 시점과 사용자 서명이 끝난 시점은 다르다. 사용자에게 보여 줄 문구도 그 차이를 반영해야 한다.

다시 검토한다면 실패를 세분화하겠다

요청 전에 실패한 경우, 외부 시스템에서 처리됐지만 응답을 받지 못한 경우, 결과는 확인했지만 내부 반영이 실패한 경우를 나누겠다. 세 상황에 같은 재시도 버튼을 붙이면 중복 요청이 생길 수 있다. 다시 요청하기 전에 기존 외부 문서나 처리 상태를 확인할 수 있는지부터 살펴야 한다.

복구 경로는 지금 더 명시적으로 설계하고 싶은 부분이다. 외부 요청 식별자와 내부 계약 식별자의 연결이 남아 있어야 사람이 상황을 추적할 수 있다. 단순히 “연동 오류”라고 기록하기보다 어느 계약의 어느 요청이 어디까지 진행됐는지 남기겠다.

자체 구현을 줄이는 판단의 가치

직접 만들지 않는 선택을 기술적으로 덜 도전적인 길이라고 볼 필요는 없었다. 실제 과제는 서비스의 핵심 흐름을 끝까지 연결하는 것이었다. 서명 도구를 만들 시간과 계약 상태를 정확히 보여 줄 시간을 비교하면, 후자가 이 제품의 사용자에게 더 직접적인 가치였다.

내게 남은 교훈은 외부 서비스가 복잡도를 없애 주지는 않는다는 것이다. 복잡도의 일부를 계약된 API 경계 밖으로 옮겨 준다. 그 경계의 상태와 실패를 이해하고 우리 제품의 언어로 바꾸는 일은 개발자의 몫으로 남았다.

관련 기록: 21앤의 외부 연동과 운영 판단