통합 작업이 치과 조직적 드래그가 될 때
Source: Dev.to
Introduction
통합이 처음 배포될 때 나는 눈치채지 못했다.
중단도 없었고, 사후 분석도 없었으며, 극적인 실패도 없었다.
바뀐 것은 대화였다.
우리 제품 책임자는 새로운 치과 고객을 온보딩하는 데 며칠이 아니라 몇 주가 걸리는 이유를 물었다.
우리 데이터 책임자는 숫자가 맞지 않을 때 어느 시스템을 신뢰해야 하는지 물었다. Eaglesoft와 Denticon은 마치…
다른 누군가는 스탠드업 회의 중에 상위 API 변경 때문에 로드맵 항목을 이동시켜야 하는지 물었다.
통합은 기술적으로 “작동”했지만, 모두가 이를 우회하기 시작했다. 질문은 있었지만 큰 변화는 없었다.
그때 비로소 당신은 더 이상 PMS만 통합하고 있는 것이 아니라는 것을 깨닫는다.
당신은 인프라를 운영하고 있으며, 누구도 예상하지 못한 “내 일이 아니다” 상황을 더 많이 겪고 있다.
숨겨진 단계
이것은 팀들이 이름 붙이지 않는 단계입니다. 어떻게 시작됐는지 되돌아봅시다.
우리는 다중 위치 치과 데이터가 크게 고장 나지는 않지만 서서히 흐려진다는 것을 알고 있습니다.
- 리더십 입장에서는 보통 보고서의 주의사항, 일정 지연, 숨겨진 비용으로 처음 나타납니다. (원본 게시물은 여기.)
- 위치마다 일정 관리가 다르게 작동하고, 그 결과 환자 신원 정보가 분열됩니다.
- 제공자들이 데이터 모델이 예상하지 못한 방식으로 사무실을 넘나듭니다.
- 단일 클리닉에서는 깔끔했던 워크플로우가 규모가 커지면서 모호해집니다.
이것은 버그처럼 보이지 않습니다. 느린 적응처럼 보입니다.
조직적 저항
우리의 대화, 스탠드‑업, 그리고 월간 체크‑인에서는 다음 중 하나에 초점이 맞춰졌습니다:
- “내 일이 아니라서 고칠 수 없어,” 혹은
- “다음 회의 전에 이걸 어떻게 임시방편으로 해결하지?”
우리는 정상화가 겨우 진행되고 있었고, 제품 팀은 불확실성을 안주하며 받아들였으며, 데이터 팀은 대시보드에 구두 면책 조항을 추가했고, 리더십 팀은 고통스럽게 느린 프로젝트에도 불안해하면서도 침착하게 대응하고 있었습니다.
깨질 정도로 심각한 문제는 없었기에 우리는 소매를 걷어붙이고 각 이슈를 직접 해결하는 것 외에 다른 선택지가 없었습니다. 바로 그때부터 우리 조직의 저항(드래그)이 기대보다 더 자주 나타나기 시작했습니다.
내가 결국 수행한 작업
어느 순간 나는 더 이상 PMS 시스템만 통합하고 있는 것이 아니라는 것을 깨달았다.
- 나는 PMS 전반에 걸쳐 버전별 동작을 유지하고 있었다.
- 스탠드‑업에서 “아무것도 바뀐 게 없는데” 하위 시스템이 다운된 이유를 설명하고 있었다.
- 재시도가 상태를 손상시키지 않도록 가드레일을 추가했다.
- 기술적으로는 유효하지만 운영상 안전하지 않은 동작을 보완하기 위해 코드를 작성했다.
대부분의 치과 EHR 벤더
- 읽기‑중심 엔드포인트를 노출
- 쓰기, 업데이트 또는 워크플로우‑중요 작업을 제한하거나 생략
- 대량 작업, 일정 변동, 재무 편집 또는 상태 변화를 제한
데이터는 볼 수 있지만, 네이티브 UI나 내부 시스템이 할 수 있는 방식으로 행동할 수는 없습니다.
그것은 의도된 것입니다.
Downstream Impact
팀이 API가 안정적인 계약처럼 동작한다는 것을 신뢰할 수 없을 때, 엔지니어링이 그 격차를 메웁니다.
엔지니어링이 격차를 메우면, 제품 일정은 조건부가 됩니다.
일정이 조건부가 되면, 팀은 역량이 아니라 불확실성을 기준으로 계획을 세우기 시작합니다.
이때 통합 작업은 조용히 조직적 마찰로 변합니다—뭔가가 고장났기 때문이 아니라, 모든 팀이 자신이 통제할 수 없는 제약을 보상하고, 위험을 단일 시스템이 소유하지 않기 때문입니다.
비즈니스 측면에서는 이것이 “추가 시간”처럼 보입니다.
엔지니어링 측면에서는 이것이 필수 작업으로 인식됩니다. 양쪽 모두 비합리적으로 보일 수 있는 요청을 가지고 있는데… 저는 양쪽 모두 옳다고 생각합니다.
통합 위험이 로드맵 위험으로 전환되면, 팀은 이를 명명하는 것을 피하는 경향이 있습니다. 아무도 이를 공개적으로 말하고 싶어 하지 않는데, 그 이유는 전달 일정이 순전히 엔지니어링 역량에 의해 좌우되지 않고 외부 시스템에 의존하게 되기 때문입니다.
Ask
- Do we delay the roadmap?
- Do we rebuild internally?
- Do we scramble for an alternative?
This is where integration work stops being a technical concern and becomes a business one.
Our roadmap didn’t slip because the team is slow.
It slipped because the system boundary was never stable.
솔루션을 향해 나아가기
결국 우리는 “이 통합을 어떻게 고칠까?” 라는 질문을 멈추고 다음을 고민하게 되었습니다:
왜 우리는 제품 팀에게 재시도, 정규화, 가시성, PMS‑변동성 처리와 같이 제품을 차별화하지 않지만 절대적으로 제품을 좌초시킬 수 있는 통합 보증을 맡기고 있을까?
이는 도구에 관한 질문이 아닙니다.
이는 시스템 결정입니다.
그리고 구매‑대‑구축 논의가 실제로 자리해야 하는 곳이 바로 여기입니다.
우리 엔지니어가 만들 수 없어서가 아니라, 레거시와 최신 PMS 시스템 전반에 걸친 통합을 유지하는 데에 제품 자체에 필요한 대역폭이 소모되고 있었기 때문에 이 결론에 도달했습니다.
우리가 필요로 했던 것은:
- PMS 전반에 걸친 표준화된 데이터 동작
- 관찰 가능한 동기화 상태와 실행 가능한 로그
- 안전한 재시도와 오류 처리
- 상위 API 변경으로부터의 격리
- 모든 팀이 PMS 전문가가 될 필요 없이 확장할 수 있는 능력
그래서 우리는 Synchronizer API by NexHealth 를 도입했습니다 – 이는 지름길이라기보다 인프라스트럭처였습니다. 우리가 이를 인정하든 않든, 결국 우리가 시도하려던 것이 바로 그것이었습니다.
Synchronizer API는 엔지니어링 판단을 대체하지 않았습니다. 대신 차별화되지 않은 통합 작업을 핵심 경로에서 제거함으로써 팀들이 실제로 제품을 개선하는 일에 집중할 수 있게 했습니다.
What Changed
- 개발자들이 동일한 보장을 다시 구축하는 일을 중단했습니다.
- 통합 버그가 신비로운 것이 아니라 진단 가능한 것이 되었습니다.
- 온보딩 일정이 안정되었습니다.
- 지원 부담이 감소했습니다.
- 제품 팀이 미지의 요소를 전제로 계획하는 일을 멈췄습니다.
- 가장 중요한 것은, 조직이 보상을 중단했다는 점입니다.
그것이 대부분의 팀이 놓치는 신호입니다.
개발자, 엔지니어링 리드, 제품 소유자, 혹은 기술 이해관계자라면 이 글을 읽으며 “우리는 이미 대부분을 스스로 하고 있다.”고 생각할 수 있습니다.
실제로 그렇습니다. 그리고 바로 그게 핵심 포인트입니다. 진행 상황은 어떤가요?
문제는 통합 보장이 중요한가가 아니라, 그것이 모든 곳에 존재해야 하는가, 아니면 의도된 곳에만 존재해야 하는가입니다.
통합 작업이 조직적 부담으로 변하는 것을 한 번 보면 눈을 뗄 수 없습니다.
그리고 그것을 이름 붙이면, 이제 무엇을 할지 결정할 수 있습니다.
솔루션 탐색
팀이 이 작업을 외부에 어떻게 제공하는지 이해하는 가장 쉬운 방법은 Synchronizer API by NexHealth Postman 컬렉션을 보는 것입니다.
개발자는 컬렉션을 자신의 Postman 워크스페이스로 포크할 수 있는데, 이는 안전하게 실험할 수 있는 개인 복사본을 만든다는 의미입니다.
- 프로덕션에 영향 없음
- 되돌릴 설정 없음
- 선택하지 않는 한 아무것도 공유되지 않음
기술 이해관계자와 비기술 이해관계자 모두에게 통합 계약이 실제로 어떻게 보이는지 확인할 수 있는 위험이 낮은 방법입니다.
결정을 내리기 전에 동작, 보장 사항 및 엣지 케이스를 이해하기 위한 방법으로 컬렉션을 포크하는 것 자체가 어떤 약속도 필요하지 않습니다.