Be 개발자 : 매일 안 쓰는 일기
6개월 동안의 가장 큰 깨달음은 'API디자인'
우인입니다
2025. 5. 8. 08:35
나는 식당의 사장이고, 어느날 서빙 담당 직원이 말한다.
“손님들이 콜라를 많이 요청해요.”
이 때 가장 먼저 생각나는 대응방식은 ‘콜라가 나오는 기계 세팅하기’이다.
이제 요청이 들어온 콜라만큼은 빠르게 간편하게 응대가 가능해졌다.
하지만 다음과 같은 상황이 발생한다면, 어떻게 대응할것인가.
- 콜라 이외에 2,3번째 음료수까지 필요하다면?
- 예상보다 콜라 주문량이 적고, 콜라기계 관리가 까다롭다면?
어쩌면 처음부터 여러 음료수 종류로 확장하는것을 염두하고 여러 맛을 동시에 공급가능한 기계를 구비해두는게 현명했을지 모른다.
혹은, 이미 거래중인 도매처에 콜라캔만 추가 주문하는것이 초기비용은 조금 발생하더라도
현재 갖춰놓은 인프라내에서 가끔발생하는 이슈에 대한 효율적인 대처 방법일지 모른다.
지난 6개월간 개발자로서 내가 일했던 방식은 위와 같은 예시상황 속 비유해보자면,
나는 콜라에 대한 요구사항에 곧바로 ‘콜라 나오는 기계’를 어떻게 깔끔하고 성능좋게 만들지 고민하던 개발자였다.
하지만, 이러한 방식이 얼마나 좁은 시야의 설계라는 생각이 들고, 이것은 6개월간의 가장 큰 깨달음이다.
곧이어 이러한 개념을 ‘API 디자인’ 라는 이름으로 정리된 자료들을 여럿 발견했고 공부할 과제로 정했다.
명확하게 맞는 개념인지는 파악중이다.
아래는 현재 내가 새로운 기능 구현하기전 고려하는 사항들이다.
- 현재 갖춰진 인프라는 어떤 것이 있는지
- 해당 요청이 얼마나 중요한지 빈번하게 호출될지
- 추가로 발생하게될 관리 지점은 효율적인지
- 향후에 추가로 어떠한 기능까지 확장될지
- 근본적으로 서버측에서 필요한 작업일지
시간이 흐르고 부족한 점이 발견되겠지만, 그래서 더더욱 생각정리를 남겨본다.