API 설계 우선 방식에 변경 워크플로 구축

문제 발견

백엔드 담당자가 API 구현을 완료할 때까지 프론트엔드 담당자가 기달려야 하는 이슈와 같이 다른 이해 관계자에게 영향을 주는 이슈는 빨리 발견하는 것이 좋다.

최근에는 적합한 워크플로를 파악하는 데 있어 점점 더 '예술적'이라고 말하며, 새로운 이념이 등장하고 있다. 콘웨이의 법칙에서 말하는 것처럼, 대부분의 문제와 그 해결책은 조직의 구조에서 비롯된다.

API 설계 및 구현에는 조직 구조 전반에 걸쳐 다음과 같은 공통된 관심사가 있으며, 두 명 이상이 API 설계 및 구현에 관련된 상항에서는 고통 관심사가 더욱 극명하게 드러난다.

• API의 진실에 대한 출처: 항상 합의된 최신 버전의 API를 찾을 수 있는 곳이있어야 한다.

• 구현 중에 API 설계 변경을 피할 수 없는 문제가 발생할 수 있다. 이런 변경을 이해관계자에게 알일 방법이 필요하다.

• 변경사항에 대한 논의 후 변경 사항 통합에 대한 합의를 도출할 수 있는 방법이 있어야 한다.

• 이해 관계자가 마지막으로 API 정의서를 본 이후 어떤 변경사항이 발생했는지 확인할 수 있어야 한다.

API의 진실의 출처는 그 계약 또는 API 정의서다. 코드는 설계를 만족하도록 구현되므로 API 정의서는 'A와 B 중 어느쪽이 맞는가?'에 대한 답을 갖고 있어야 한다.

이슈는 다음과 같다.

• 최신 API 정의서 확인

• 변경 제안

• 변경 비교

• 변경 수용

변경 논의와 대응 방법

API 설계에 대한 변경은 불가피하다는 사실이 워크플로에서 가장 핵심을 이룬다. 우리가 관심을 갖고 지켜볼 것은 설계 단계에서는 예상할 수 없었고 구현 단계에서 발생하는 변경이다. 때문에 변경은 불가피하다고 가정할 수 있다.

문제는 그 변경을 수용할 수 있는 워크플로를 구축하는 방법이다. 이해관계자는 설계에서 문제를 강조하고, 변경을 제안하고, 변경에 대한 합의를 도출할 수 있어야 한다. 또한 다른 이해관계자에 의해 발생한 변경에도 대응활 수 있어야 한다. 이런 변경은 모두 진실의 출처에 바탕을 두고 있어야 한다. 신뢰할 수 있는 출처가 없다면 유효하지 않은 기능에 시간을 낭비할 수도 있다.

워크플로 엔진으로서의 깃허브

위에서 얘기했던 세 가지 문제를 깃허브를 이용해 해결해 보자.