현재 일을 하는 직장에서는 DB의 특정 테이블 등 영향도가 있는 작업을 하는 경우 메신저로 아래와 같은 메시지를 보내온다.
“언제 XXX Table을 수정하므로 각 업무 담당자는 영향도를 확인하여 주십시오.”
문제는 해당 테이블은 공용 업무가 아닌 특정 업무의 DB라는 점이다.

해당 테이블이 여러 업무에서 사용하는 공용 테이블이라면 문제가 되겠지만,
특정 업무에서 사용되는 DB를 모든 업무 담당자에게 영향도를 조사한다는게 말이 되는건가...?

일단 원인을 파악해보았다.
먼저 A, B, C라는 업무가 있을 때 A팀에서 관리하는 DB를 B팀과 C팀에서 직접적으로 접근하는 경우가 다수 존재한다.

문제는 이런 상황이 발생하는 경우 프로그램의 복잡도가 기하급수적으로 올라간다는 점이다.
위의 이미지에서 빨간색 선은 각 팀의 서비스에서 다른 팀의 DB를 접근한다고 가정했을 때를 표시한 것이다.
3개의 서비스와 3개의 Table만 놓고 보더라도 이렇게 복잡한데, 실제로는 100개 이상의 테이블과 서비스가 존재한다.

그렇다면 이런 경우 각 업무별로 프로그램을 분리하고 A, B, C간의 CRUD를 Private한 API로 만들어서 사용하면 어떨까?
A팀에서 B팀과 C팀에 필요한 정보를 제공하는 API를 만들고 관리한다면 Table이 수정될 일이 생기더라도 A팀에서는 다른 팀의 영향도 파악 필요 없이 제공중인 API까지만 확인하면 될 것이다.

물론 DB 성능 등을 위해 직접적으로 DB를 Join 하는 경우도 있을 것이다.
A팀의 DB를 B팀에서 사용해야한다고 가정하면, 이런 경우 View로 작성해서 A팀과 B팀에서 해당 View를 같이 관리한다면 조금 더 쉽게 영향도 확인이 가능하지 않을까?
물론 내가 개발 능력이나 DB에 대해서 많이 부족해서 틀린점이 있을지는 모르고 위에서 말한 내용 이외에도 많은 예외 사항이 있을 수도 있지만,
현재 상황에서 생각했을 땐 위와같은 방식으로 하면 지금의 문제는 해결이 가능할 것 같다고 생각한다.

물론 권한도 없고 쉽게 수정할 수 있는 부분은 아니기 때문에 이렇게 정리해두고, 혹시 내가 이런 상황이 발생한다면 직접 경험해보는 것도 나쁘지 않을 것 같다.
개발을 하면 할 수록 Interface의 중요성을 느낀다.