API 설계 결정 과정과 그 이유를 구체적으로 전달한다
팀 프로젝트에서 로그 수집·포매팅 공통 유틸리티를 만들면서 API 설계를 처음부터 결정해야 했습니다.
가장 먼저 한 것은 사용자(팀원)가 어떤 상황에서 이 라이브러리를 쓸지 시나리오를 3개 작성하는 것이었습니다. 그 시나리오에서 공통으로 필요한 파라미터와 그렇지 않은 것을 분리하였습니다. 꼭 필요한 파라미터는 최소화하고 나머지는 기본값으로 충분히 동작하도록 설계하였습니다. 예를 들어 logger.log(message) 하나만으로 기본 로그가 남고, 포맷·레벨·출력 대상은 설정 객체로 선택적으로 전달하는 구조였습니다. 실패는 초기에 메서드 이름을 너무 줄여서(`lg`, `dbg`) 팀원이 무엇이 무엇인지 모르겠다고 피드백이 온 것이었고, 전부 log, debug, error로 변경하였습니다. 명확성이 간결성보다 중요하다는 것을 그때 배웠습니다.
좋은 API는 처음 쓰는 사람이 문서 없이도 대략 쓸 수 있는 것이라고 생각합니다. 그 기준을 항상 팀원 입장에서 확인해가며 설계하였습니다.