책임과 기술, 그리고 오버엔지니어링

아키텍처에 관한 글을 작성하다 보니 자꾸 늘어져서 다른 글을 주저리 적어본다.

현재 재직중인 회사에서 API 요청과 응답에 대한 Type validation 라이브러리 도입에 대한 논의를 진행했다(zod, joi, yup 등). 이 라이브러리들은 단순 응답 형식(타입스크립트 인터페이스) 작성을 통한 형변환을 넘어, 최소값과 최대값, 그리고 형식 등을 체크해주는 일종의 미들웨어다. 그런데 나는 회의 도중 문득 '이게 정말 필요한 것일까'라는 반골 기질의 의문이 들었다. 개인적으로 FE 개발자로서 업무를 진행한다면 프론트엔드에서 하는 '사내 내부 요청'은 항상 검증되어 있어야 한다고 생각하기 때문이다. 프론트엔드 제공을 위한 백엔드(BFF)에서 저런 데이터 검증을 한다는 것은 API, 다시말해 백엔드을 믿지 못하기 때문이다. 외부 업체의 API인 경우 변화에 대해 장담할 수 없기 때문에 그러한 작업이 필요할 수 있다고 생각하지만, 사내의 동료를 믿는다면 굳이 그럴 필요가 있나 싶었다.

 

사내 백엔드간 Rest API 요청에 타입 체크가 필요한걸까?

 

그런식으로 생각해보니 이것은 단순한 기술적 문제가 아니라는 생각이 들었다. 팀 간 무너진 신뢰와 책임 관계를 기술로 막아내는 상황이 된 것이다. 타입 체크라는 기술을 통해, 같은 회사의 '믿을 수 없는' API를 체크함으로써 장애에 대한 대응을 하고자 한 것이다. 나만 그렇게 생각한 것일수도 있지만... 이건 정말 이상하다.

 

개인적으로 사용자가 접근한 '화면'이 이상한 경우는 프론트엔드, '데이터'가 이상한 경우에는 백엔드의 책임이라고 생각한다. 따라서 '데이터'가 이상하여 화면에 오류가 발생한 것 또한 백엔드의 책임이라고 생각한다. 이전 글에서 작성했듯, 나는 R&R을 명확하게 나눠 업무를 진행하는 것에 매우 긍정적인 편이다. 그렇기 때문에 위 단락에서 이야기한, 사내 API의 응답에 대한 체크는 오버엔지니어링이라는 생각이 든다. 데이터에 대한 유효성 체크는 백엔드 개발자의 몫이다. 프론트엔드 개발자로서는 API로 요청한 응답이 '이상한' 형태인 경우를 상정하지 않고, 에러 응답 코드에 대한 대응을 하면 된다. 백엔드에서는 항상 @Validated 어노테이션 등을 이용해 아주 '기본적으로' API로 요청한 데이터의 유효성을 검사한다. 이처럼 유효성 체크는 백엔드 개발에 있어 기본중에 기본이다. 결국 프론트엔드 측에서만 작성해야 하는 코드가 많아지고 인적, 물리적 리소스 소모량이 늘어 유지보수 편의성을 해치게 될 것이다.

 

Rest API에 대한 기술적인 측면에서 접근해도 마찬가지다. Rest API의 특성상 응답이 변하는 경우 API의 버전을 올리게 된다. 프론트엔드에서 요청하는 코드를 수정하지 않았다면 항상 같은 형식의 데이터가 응답으로 와야 한다는 것이다. 프론트엔드에서 API의 응답을 체크한다는 것은 API가 '정상적인 룰'을 따르는 Rest API인지조차도 신뢰할 수 없다는 뜻이 아닐까?

 

난 지금 팀장이 아니니 강력하게 주장하지 않는다. 무거운 워터폴 형식의 회사는 아니지만, 명확한 프로젝트-서비스 히스토리와 발생할 수 있는 상황에 대해 잘 인지하지 못했기 때문이다. 이 라이브러리 도입이 단순히 '기술을 사용하고 싶은' 개발자의 향상심에 의한 것일지도 모른다. 하지만 정말 내가 우려한, 팀간 신뢰가 깨진 상황이라면... 개발 부서의 앞길이 불투명하다는 생각이 든다. 만약 내가 높은 직급에 있을 때 이러한 '팀간 신뢰가 깨진' 상황에 어떻게 대응해야 할까. 억지로 모아놓고 술이라도 먹여야되나? 그러면 회사 짤릴텐데.