그리스 신화에 테세우스의 배 이야기가 있다. 아테네인들은 테세우스가 타고 돌아온 배를 수백 년간 보존했다. 낡은 판자가 썩으면 새 판자로 교체하고, 또 교체하고. 결국 원래 판자가 하나도 남지 않았을 때 철학자들은 물었다. 이게 여전히 테세우스의 배인가?
소프트웨어 엔지니어링에는 이 역설과 똑같은 패턴이 있다. Strangler Fig라고 불리는데, 같은 패턴을 두고 사람들이 Ship of Theseus라 부르기도 한다.
Strangler Fig은 열대의 교살무화과나무에서 따온 이름이다. 숙주 나무를 감싸며 자라다 결국 대체하는 식물인데, 레거시를 점진적으로 교체하는 전략과 닮아서 Martin Fowler가 2004년에 이름 붙였다. “교살”이라는 이름이 거칠어서인지, Ship of Theseus 패턴이라고도 불린다.
내가 있는 스타트업에도 이 배가 한 척 있다. 처음에는 Django 모놀리스였다. 모든 기능이 하나의 코드베이스에 들어 있었다. MSA로 전환하면서 기능을 하나씩 떼어냈고, Django는 요청을 각 서비스로 보내주는 프록시가 됐다. 판자를 하나씩 교체한 셈이다. 그리고 지금, 그 프록시마저 Spring WebFlux로 바꾸는 작업이 시작됐다. 마지막 남은 판자다.
이 교체가 끝나면 Django 코드는 한 줄도 남지 않는다. 그러면 테세우스의 배와 같은 질문을 하게 된다. 이건 같은 서비스인가? 같은 이름이고 같은 사용자가 같은 요청을 보내지만, 처음의 코드는 한 줄도 없다.
여전히 같은 배일 것이다. 판자가 나무든 철이든, 같은 바다를 건너 같은 목적지에 도착한다면 그건 같은 배다. 특히 소프트웨어에서 정체성은 코드가 아니라 계약에 있다. 같은 사용자가 같은 요청을 보내고 같은 응답을 받는 한, 그건 같은 서비스다. 코드는 그 계약을 잠시 떠받치는 판자일 뿐이고, 이를 바꾼다고 배가 달라지는 건 아니다. 오히려 같은 계약을 보다 빠르게, 또는 더 먼 바다까지 데려가는 일이다. 낡은 판자로는 한계가 있고, 그게 우리가 계속 판자를 바꾸고 질문하는 이유다.