그룹웨어 서비스 연동 - 협업간 조직도 연동 방식 고찰

 

들어가기 

 

회사에서 제공하는 서비스를 특정 기관(고객)에 배포를 하는데, 다른 솔루션 업체들과 협업을 하는 경우가 많았다. 그럴 때마다 공통으로 확인하는 사항이 있었는데, 바로 조직도이다.

 

웹메일, 메신저, ERP, 포탈, 그룹웨어 등 다양한 솔루션을 주로 담당하는 회사들의 제품을 사용하는 고객입장에서는 모든 기능에서 조직도는 동일해야 문제없이 업무를 진행할 수 있다. 즉, 업체들끼리 조직도를 연동해야 할 필요성이 있는 것이다.

이 글에서는 이러한 조직도를 연동하는 방식에 대해 간단하게 언급하고자 한다.

 

 

본론

 

여러 방법들을 언급하기 전에 가장 먼저 정해야 하는 것이 있다. 마스터, 슬레이브를 정하여할것인지, 아닌지이다. 즉, 조직도 동기화의 주체가 되는 마스터 업체와 이를 반영하는 슬레이브 업체를 따로 둘 지이다.

마스터, 슬레이브 형식으로 진행한다면 데이터 책임이 한 군데에만 있기 때문에, 동기화 문제나 동시 수정으로 인한 충돌을 피하는 등 일관성을 유지할 수 있고, 슬레이브는 읽기 전용으로 운영되기에 잘못된 쓰기로 인한 사고를 방지할 수 있다.

또한 마스터는 쓰기, 슬레이브는 읽기로 분산하여 부하를 줄일 수 있다는 장점이 있다.

 

물론 이 방법이 무조건 좋은 것은 아니다. 상황에 따라 다를 수 있다. 마스터 슬레이브 구분 없이, 아무 서비스에서 조직도를 변경하면 다른 서비스들도 모두 반영되도록 할 수도 있는 것이다. 

 

정해진 방법은 없으니 업체들 간의 협의를 통해 어떤 방식으로 할지 결정하면 된다.

 

1. DB 데이터 연동 - VIEW 테이블을 통한 연동

일반적으로 사이트를 운영하는 서버와 DB가 있고, 솔루션 업체들은 해당 기관의 DB 내에 각각의 스키마를 가지고 데이터를 저장한다. 보통 마스터, 슬레이브 관계일 때 자주 활용하는데, 마스터 업체에서 조직도의 변동이 있을 시 VIEW 테이블에도 반영을 하고, 슬레이브 업체에서는 마스터 업체의 View 테이블을 조회하여 테이블을 업데이트하는 방식이다. 

사전에 슬레이브 업체의 스키마가 마스터 업체의 스카마가 가진 View 테이블 조회 권한을 주면 간단하게 적용할 수 있는 방식이다. 실제로 우리 회사에서는 이 방식을 고수하고 있다.

만약 각각 다른 DB에 데이터를 저장하고 있다면, DB LINK를 활용하여 VIEW 테이블을 조회하는 방법도 있다.

 

슬레이브 업체에서는 VIEW 테이블을 조회하여 반영하게 위해서 크롭탭이나 스케줄링, 스프링 배치와 같은 방식을 통해 프로시저, sql문을 실행하는 등 다양한 방식으로 진행할 수 있다.

이 방식은 단순하고 직관적이며 일관성 있다는 장점이 있지만, 아래와 같은 단점들이 존재한다.

1. 보안 문제: 마스터 업체의 DB에 직접 접근하는 구조 →  보안 리스크가 커진다.
2. 결합도 높음 (Tightly Coupled): 마스터 업체의 DB 구조가 변경되면 슬레이브 업체에 영향을 주고, View 구조나 컬럼명 변경만으로도 장애 발생 가능하다.
3. 확장성 부족: 업체가 늘어나면 이런 방식은 유지보수에 어려움이 있을 수 있다.

 

2. API 기반 호출

가장 일반적으로 생각할 수 있는 연동 방식으로, 슬레이브 업체들이 마스터 업체의 정보를 조회하여 반영하는 방식이다.

다른 서비스 DB에 직접 접근하지 않고, 그 서비스의 API를 통해 데이터를 전달받으므로, 느릴 순 있지만 의존성과 일관성 관리가 쉽다는 장점이 있다. 또한 느슨한 결합이 이루어지며 확장성이 높고, 보안성이 우수하다.

마스터 업체가 REST API, GraphQL API 등을 제공하면 슬레이브 업체들은 스케줄링을 통해 특정 시각에 해당 API를 호출하여 데이터를 가져갈 수 있으며, 인증/인가(OAuth2, API Key 등)로 보안 처리할 수 있다.

 

3. ETL 방식(Export → Transform → Load)

마스터 업체가 주기적으로 조직도 데이터를 파일로 export(csv, json 등)하면 이를 Sftp, Cloud Storage, Message Queue 등의 방식으로 슬레이브 업체에 전달하는 방식이다. 슬레이브 업체에서는 이를 가져와 가공하여 DB에 적재한다. 

시스템 간 독립성을 유지한다는 점에서 API 방식과 유사하며, 대용량 데이터에 적합하다.

이 방식 또한 마찬가지로 스케줄링, 배치를 통해 일정 주기로 갱신할 수 있다.

하지만 실시간 동작을 진행하기에는 어려움이 있다는 단점이 있다. 

 

4. 이벤트기반 비동기 연동

Kafka, RabbitMQ 등 메시지큐 방식의 통신방식을 통해 연동 정보를 주고받는 방식이다. 

이벤트 기반의 방식으로 실시간 동기화, 높은 확장성을 가지고 있기에 마스터, 슬레이브 없이 각각의 업체에서 변경된 값을 전체 기관으로 송신하는 실시간 방식을 구현할 때 유리하다.

하지만 이벤트기반 비동기 통신을 위한 새로운 기술을 적용하는 것 자체에 도입 난이도가 있으며, 운영이 복잡하다는 단점이 있다.

 

5. 조직도 서비스 구축

조직도 정보만을 가지고 있는 공용 DB, 스키마를 지정하거나 서비스를 구축하는 방식이다.

사용자가 조직도를 조회할 때는 해당 서비스를 통해 조회를 하며, 수정 또한 해당 시스템 내 DB에 반영이 된다. 

독자적인 서비스로 존재한다는 장점이 있지만, 시스템을 새로 구축한다는 부담이 존재하며, 조직도 서비스를 전문으로 하는 업체를 도입하는 것을 고려할 수도 있다.

만약 한 업체 내에서 팀단위로 기능을 분담하여 개발할 경우에는 조직도 구축 팀을 만들어 진행하기에, 해당 방식이 적합할 수 있다.

 

 

결론

 

이렇게 간단하게 조직도 연동하는 방법에 대해서 알아보았다.

조직도 연동뿐만 아니라 서버와 서버가 통신하는 데에도 다양하게 적용될 수 있으며, 어떤 방식을 사용하든, 정답은 없고 더 획기적인 방식은 존재할 것이라고 생각한다.

결국 연동을 진행하는 업체들 간의 협의가 중요한 것 같다.