프로덕트 매니저는 엔지니어가 아닙니다. 하지만 프로덕트 매니저가 기술적으로 충분히 엔지니어와 의사소통하고, 이해 관계자와 기술적 개념을 명확히 표현할 수 있어야 한다는 기대가 있습니다.
대부분 비기술적인 이해관계자는 대부분의 기술적 개념에 대한 이해가 거의 없을 것이지만, 제품 개발의 모든 부분 중에서 이해 관계자와 가장 많이 이야기할 것은 API일 것입니다.
영업팀 리드 혹은 마케팅팀 리드와 리액트 컴포넌트 혹은 NoSQL 데이터베이스의 중요성에 관해 언제 마지막으로 얘기했습니까? API에 대한 경솔한 언급과 대조적으로, API에 관한 실무 지식은 프로덕트 매니저에게 가장 중요한 지식 중 하나입니다.
우리는 이전에 API의 놀라운 세계에 관해 깊게 다룬 바가 있습니다. API의 작동방식에 대해 다시 상기하고 싶다면 여기서 확인하실 수 있습니다. 이번 글에선 API 관련 기술의 한 가지 측면에 중점을 둘 것입니다. 바로 API 문서를 읽고 이해하는 능력입니다.
API를 사용하는 주요 이점 중 하나는 당신의 제품이 다른 제품에 편승해 사용자에게 새로운 형태의 가치를 전달할 수 있는 점입니다. API 통합이 없었다면 많은 제품이 존재하지 않았을 것입니다.
이메일 제공업체에 연결할 수 없는 CRM을 상상해보세요.
Quickbooks가 비즈니스 뱅킹 피드에 연결할 수 없다면 어떻게 될까요?
혹은 이커머스 공급자가 배송료와 추적을 제공할 수 없다면 어떻습니까?
API는 이제 제품 개발의 필수입니다. PM으로서 API를 처음 맞닥뜨릴 곳은 아마도 잠재적 API 통합 혹은 파트너십을 탐색해야 하는 상황이 될 수 있습니다.
<aside> 💡 API 문서를 읽는 법을 배워야 하는 이유
저는 API 파트너십에 대한 근본적인 질문을 잊어버리고, 미리 API 문서를 읽지 않았을 때 어렵게 배웠습니다. API 문서가 모두 오래된 SOAP/XML 형식으로 되어 있어 파트너십을 불가능하게 만들 수 있다는 사실을 토론의 후반부에서야 깨달았습니다. 그다지 좋았던 경험은 아니었죠. 🙂
REST API 문서는 일반적으로 다음과 같은 내용을 포함합니다.