서비스 시스템의 개발자들은 어떤 서브시스템의 운영을 다른 팀에 맡기더라도 그 서브시스템에 의해 외부화되는 효과들 – 그 서브시스템이 다른 서브시스템이나 서비스가 사용하는 기능이나 데이터에 영향을 미치는 것들 – 에 대해서는 매우 명확하게 파악하고 있어야 한다.
예를 들어,
L4/L7의 셋업을 요청한다고 할 때, 어떠한 방법으로 셋업을 실행하는지, L4 장비가 어떤 식으로 배치되는 가 등은 네트워크 운영을 담당하고 있는 팀의 업무로 추상화되어서 외부로는 알려지지 않아도 되는 정보 – 필요한 경우도 존재한다 – 라고 할 수 있다. 하지만, L7 Healthcheck가 어떤 식으로 동작하는지는 정확하게 파악하고 있어야 실제로 L7 Healthcheck가 어떤 상황에서도 정확하게 동작하는지, 통상적인 문제 상황에서 가용성을 보장할 수 있는지 등을 판단할 수 있고, 나아가서는 장애 상황에서 알고 있는 것들은 문제의 원인에서 배제하거나 다시 확인할 수 있고 더 빨리 원인을 찾을 수 있게 된다. 흔히 DBA 팀에 맡기는 DB의 경우에도 마찬가지다. DB의 어떤 오퍼레이션 디테일은 전혀 몰라도 상관없지만, 특정 쿼리의 성능 특성이나 DB connection pool의 동작 특성 등을 알고 있는 것, 백업 등의 서비스 쿼리의 성능 특성에 영향을 미치는 운영 특성을 인지하고 있는 것은, 여러가지 문제를 예방할 수 있을 뿐더러 문제가 발생했을 때 더욱 빨리 찾을 수 있게 된다.
이러한 행동을 하기 위한 전제 조건에는 다음과 같은 것들이 있을 수 있는 것 같다.
- 외부화 효과에 대해 명확한 파악이 필요한다는 인지. (레시피에 따른 행동을 포함.)
- 어떤 것이 외부화 효과인지 판단할 수 있는 능력.
- 오랜 경험에 의해 어떤 것이 문제가 되기 쉬운지 파악하고 있음.
- 논리적인 도출.
서비스 개발 조직 관점에서는 이러한 외부화 효과들을 개개인의 경험이나 논리적인 능력에만 의존하기보다는 보다 집합적인 지식으로 만들어나가는 것을 목표로 하는 것이 바람직할 것이다. 또한 이러한 서브시스템을 개발 또는 운영하고 있는 조직의 관점에서는 외부화 효과라고 이미 알려진 것들을 효율적으로 커뮤니케이션할 수 있도록 문서화하거나 도구화하는 것, 어떤 것이 외부화 효과인 것인지 외부로부터의 질문이나 장애 등의 경험 등으로부터 파악하는 등의 고수준의 엔지니어링 노력이 필요하다.