외부 API 샌드박스 환경을 직접 만들어보는 것은 어떨지

외부 서비스 자격 심사 전에는 검증이 어렵습니다

만들고자 하는 웹서비스는 주기적으로 데이터를 외부로부터 수집해야 하는 기능이 포함되어 있습니다. 만약에 외부로부터 데이터를 수집할 준비가 아직 안 되어 있다면, 개발한 게 제대로 동작됐다는 것을 어떻게 확인해볼 수 있을까요? API 문서를 확인해서 거기에 맞게 작업은 했지만, 실제 요청을 해볼 수 없으니, 실제로 요청을 할 수 있는 자격을 얻고 난 뒤에나 그 동작을 확인해볼 수 있는 상황이 발생하게 됩니다.

외부 서비스가 샌드박스 환경을 주었다면, 자격 심사 결과를 기다리기 전에 확실하게 필요한 데이터를 샘플 응답으로 받아서 활용해볼 수 있겠습니다. 다만, 외부 서비스가 샌드박스 환경을 제공하지 않는다면 어떻게 해야 할까요. 그렇다면 첫 번째 문단에서 이야기했듯, 운영 환경이 되어서야 제대로 동작되는지 확인할 수밖에 없습니다.

운영 배포 직후에야 발견되는 치명적 오류의 위험

이러한 상황은 굉장히 위험이 큽니다. 고객들이 직접 쓰기 시작하는 와중에 동작하기를 기대했던 시스템이 버그가 나서 동작을 하지 않는다면, 서비스 출시를 하자마자 그 에러로 인해 고객은 불편을 겪게 되고, 제대로 된 서비스를 제공할 수 없는 상태가 됩니다. 그걸 곧바로 확인해서 오류를 수정한 뒤 재배포를 할 수도 있습니다. 그러나 그게 단시간에 끝날 수 없는, 차마 배포하기 전에 검수하지 못한 치명적인 오류라면 어떨까요? 우리는 최악의 경우를 상정해서 개발을 할 필요가 있습니다.

AI 시대, 샌드박스 환경을 직접 만들어보는 선택지

AI가 코드를 대신 짜주기 때문에 우리는 번거로운 일을 어느 정도 AI에게 위임할 수 있게 됐습니다. 그 중에서는 사실, AI가 없더라면 하지 않았을 시도를 해볼 수도 있게 된 것입니다. 외부 서비스를 이용해야 하는데, 외부 서비스가 샌드박스 환경을 제공하고 있지 않다면, 우리가 그 API 문서를 확인해서 샌드박스 환경을 직접 만들어보는 것입니다. 샘플 데이터가 필요한데, 외부 서비스에서 가져올 샘플 데이터를 구할 수 없다면, 우리가 외부에서 필요한 샘플 데이터를 구했다고 가정할 수 있는 서버를 만들어보는 것이죠.

외부 서비스의 샌드박스 환경을 우리의 소프트웨어 품질을 위해 직접 구축하는 것은 트레이드오프이긴 합니다. 그렇게 투자할 시간을 더 집중해야 할 개발이 있다면 그 개발을 진행하는 것이 맞겠습니다. 다만, E2E 테스트 등을 단순히 호출이 무조건 성공했다가 아니라, 우리가 구축한 시스템이 직접 외부로 호출을 했고, 그 호출에 대한 기대하는 응답값을 받았고, 그렇게 하여 우리가 처리하고자 하는 데이터를 가공했다는 리허설을 해볼 수 있게 하는 것은 상황에 따라 필요한 작업인 경우가 있을 것입니다.