배경

우선 제목과 같이 자극적인 주제를 사용한 이유는 배경을 들으면 충분히 그럴 수 있다고 이해할 것이다.
배경은 일단 국민취업제도의 일경험 프로그램의 일환으로 기업에서 체험형 인턴 직무를 수행했을 때이다. 아쉽게도 현 제도의 큰 문제점이 있는데, 이 문제의 중대함을 뒤늦게 인지하고 입사 하루만에 run 한 지원자들의 부재가 이번 포스트의 원인이다.

문제점은 바로 지원금 제도와 IT 기업의 특성이다. 당시 23년도에는 정부와 결탁한 기업들에게 인턴을 제공하는 대신 기업은 일체 자본을 소비하지 않고, 대신 정부가 참여 인턴에게 지원금을 월급 대신 주는 제도로 이루어진 것이 일경험 프로그램이다.

다만 대개의 IT 업계는, 더구나 스타트업은 해당 인턴들을 위한 온보딩 시스템을 구축하기 어려울 뿐더러, 무언가 실질적인 결과를 빠르게 내야하기 위해 각 프로젝트 별 분업을 함으로 인턴들도 정규직과 비슷한 강도의 업무를 맡을 수 밖에 없다고 생각한다.

그래서 한달에 140만원이라는 적은 금액으로 정규직과 같은 업무를 진행한다는 것에 무서움을 느끼고 같이 들어온 다른 프론트엔드 개발자, 나중에 알았는데, 나 이전에 불러들였던 다른 프론트엔드 개발자들도 입사 후 바로 나가버리는 상황이 생겨버린 것이다.
나야 뭐, 선임 프론트엔드 개발자의 팁을 가까이서 배우면서 내 부족한 점을 채울 수 있다는 점에 혹해서 2개월간 입에 풀칠할 정도의 금액으로 버티긴했지..

프론트와의 소통이 없는 API라..

위의 배경에 덧붙여서 말하자면 인턴들끼리 회사에서 할당한 새로운 프로젝트를 알아서 진행하는데
앞서 말했듯, 프론트들이 다 나가버려서 백엔드 인턴들끼리 Figma의 기획안을 보면서 API를 개발하였다고 한다.

아, 물론 PM 분들께서 기획안을 정말 잘 써놓으셨기 때문에 백엔드 분들끼리 충분히 좋은 API를 작성할 수 있다고 생각한다. 이전에는 그냥 디자인 페이지에 기획을 메모로만 덕지덕지 붙인 느낌이 있어서 해당 UI에서 어떤 상호작용 및 무슨 데이터를 어떻게 활용해야되는지 조건들도 알기 어려웠는데 이번에는 좀 체계적이라서 프론트인 내가 서비스를 제작하기에도 정말 많이 도움이 되었다.

아무튼 내가 다른 인턴분들보다 뒤늦게 합류하게 되어서 거의 완성되어가는 API를 활용하기 위해 문서를 보게 되었는데, 여기서 여러 문제가 발생하게 된다.

문서화의 부재

문서화의 중요성을 정~말 크게 느낀 프로젝트였다. 문서는 서로의 시간을 아낄 수 있으며, 오해 또한 미리 막을 수 있다.

어떤 데이터가 무엇을 말하는지 알 수가 없다.

말 그대로다. API를 받아오면 데이터들이 객체에 담겨져 오는데, 과연 이 데이터가 무엇을 말하는지 알아야 편하게 클라이언트에 반영할 수 있다.
하물며, 해당 데이터 이름은 백엔드 분들이 작성하시기 때문에 서로 약속되어있는 변수명이 따로 존재하지 않다면 문서화를 통해 해당 변수가 무엇을 말하는지 알려줘야 된다고 생각한다.

또한 데이터의 ID값을 숫자로 관리하게 되면, 해당 숫자값이 어떤 의미를 말하는지도 알아야한다.
만약에 boolean 값으로 알림이 켜졌는지 안켜졌는지, true, false가 아니더라도 0, 1로 들어온다면 대강 0이 false고 1이 true임을 짐작할 수 있을 것이다.

하지만 다음과 같아지면 달라진다.

/** 출근 현황 */
export const AttendType {
  결근 = 1,
  휴가 = 2,
  반차 = 3,
  출근 = 4,
} as const

위의 예시처럼 들어오는 객체를 한글로 UI에 반영하기 위해 숫자 값을 바탕으로 결정하기 위해 작성하였다. 사용자가 결근을 눌렀을 때에는, 이 객체를 활용하여 1을 서버에 보내주면 서버는 이 사람이 결근을 했구나 라는 것을 인지할 것이고.
반대로 서버에서 1이 들어오면 프론트는 결근을 화면에 반영할 것이다.

그런데 만약 저 숫자값들이 무엇을 의미하는지 알지 못하면 어떻게 될까?

대혼란이다. 애초에 해당 API를 연동시킬 엄두도 나지 않으며 계속 백엔드 개발자 붙잡고 이거 뭐에요? 말로하면 까먹을 수도 있으니 문서로 만들어 두면 어때요? 이래야된다. 그러다보면 계속 업무를 방해받는 셈이 되고, 미움을 받을지도 모른다. (필자는 아마 어떻게 말해야지 개의치않고 해주려나.. 라며 고민 열심히 때리느라 시간 보낼 듯 하다.)

그래서 API가 서로의 약속이라고 하듯이 이러한 부분을 상세히 문서화하면 서로의 시간과 오해를 아낄 수 있지 않을까 생각한다.

Bearer 처리를 누가 담당할 것인지

예를 들면, 로그인 이후의 처리이다.
로그인 후에 API 호출은 USER ID 역할을 하기 위해 headers 내의 Authorization에 access token을 담고 보내고 Bearer 처리를 진행하게 된다. 왜냐하면 이 토큰을 사용하는 소유자에게 권한을 부여해주세요 라고 서버에게 알려줘야 하니까.

그런데 Bearer 처리한 응답이 계속 401 (unAutorization) 으로 튕겨 나오는 모습을 확인했었다.
난 분명히 의도대로 잘 헤더에 담아서 보냈단 말이지.

나중에야 알고보니 내 Bearer에 서버에서 Bearer처리를 다시 한 것이었고, 결국 Bearer Bearer ${accessToken}과 같이 들어간 꼴이다. 그러니 인식을 못하지.

이것도 서로 약속이 되어있다면 간편한 작업이었다.
하지만 서버측에서도 들어오는 Header에 Bearer를 씌울 수 있다는 것을 몰랐던 나의 부족함도 잘못이라고 생각한다. 만약 이런 상황을 미리 인지했다면 더 빠르게 조치할 수 있었지 않았을까?

약관 동의에서 모두 선택 란의 정보를 달라고 하신다.

우리가 흔히 회원가입 때 사용하는 약관동의를 만들 때 생긴 에피소드다.

필수 동의 사항이 총 3개, 그리고 마케팅 (선택 사항)이 총 2개로 보내야할 항목의 boolean 값이 총 5개였다.
그런데 API를 보니 총 7개 였던 것을 확인할 수 있었다.

자세히 알아보니 기획 페이지에서 체크박스는 모두 선택 + 마케팅 모두 선택을 포함해서 7개의 boolean 값을 받아야 된다고 생각하여 작성하셨던 것이다.

일단 첫 눈에 보았을 때에는 프론트인 나의 입장에서는 이해가 잘 되지 않았다.
너무 어렵게 생각한 것이 아닌지, 정작 서버측에서 알아야할 건 요 알맹이 5개인데, 모두 선택의 여부까지 달라는 이유를 이해할 수 없었다.
하지만 그때에 나는 이유를 물어보지 못해서 아마 이렇게 작성하신 이유가 따로 있으실 것이라 생각이 든다. 스프링은 노드와 다를 수도 있으니까.

그렇지만 이것도 내가 좀 더 빨리 합류하여서 API 짜기 전에 물어볼 수 있는 계기가 있었다면 더 좋은 방법으로 구현을 생각해볼 수 있지 않나 싶다!

이번 계기로

어떻게 보면 문서화에 대한 부재로 인해 답답했던 심정을 풀어내는 포스트가 되는 것 같아서 좀 억울하다(?).
하지만, 서로의 시간을 존중하려면 문서를 통한 약속이 상호 협의가 되어야하며, 백, 프론트 간에 기능을 바라보는 관점이 분명히 다르기에 API는 같이 설계하는 것이 좋다는 생각을 다시 한번 하게된다.
또한 언젠간 풀스텍을 바라보겠다만, 지금 프론트를 몰두하면서 틈틈히 서버가 기능을 어떻게 설계하는지 정도는 틈틈히 공부하면 소통에 큰 도움이 될 것이라는 것도 배운 시간이었다.