[끄적끄적] 취준 개발자의 방황 (RESTful API)

어떤 영상을 보고.. 시니어 개발자들이 주니어 개발자에게 무엇을 바라는지
어떤 글을 보고.. 개발자란 어떤 사람을 이야기하는지를 보며  (해당 영상과 링크는 포스팅 하단에 따로 링크를 걸어두도록 하겠다.)

나는 취준을 어떻게 준비하고 있었지? 라는 생각을 하게 되었다.

나는 막연한 백엔드 개발자로 Node.js 경험과 AWS, 서버 운영 경험만을 가지고 그렇게 "나는 준비됐어!"라는 생각에
백엔드 개발자 모집란에 부족한 이력서를 들고 설쳤다.

그러다 문득 저 영상과 글을 보고 내 이력서를 봤을 때 이런 근본 없어 보이는 이력서를 보고 누가 날 뽑을까 라는 생각을 했다.
나는 이력서에 내가 할 수 있는 모든 것을 다 써놨었다. 백엔드, 프런트 일부, 파이썬 , GUI, IoT, MQTT..

정말 통일성 없고, 저렇게 많은 분야를 다뤄서 뭐 하나 제대로 할까?라는 생각을 했다. 단 하나도 완벽하게 하기 힘든 것을.

 

그래서 쳐내기로 했다. 내가 하고 싶은 직무와 관련된 것을 제외한 것들을

먼저 내가 하고싶은 일을 정했다. iot 같은 것들을 쳐내고 API 개발과 백엔드에 집중하기로.

 

주니어가 모든 것을 완벽하게 할 순 없을 것이다. 다만, 성장 가능성이 보여야 한다고 생각한다.

이 사람이 얼마나 본질을 인식하고 있고, 어떤 자가적인 성장을 통해 개발의 주축으로 성장할 수 있는지, 무엇을 모르고 무엇을 알고 있는지 

이런 것들을 어떻게 기업 인사담당자들에게 보여줄 수 있을까

곰곰이 생각해볼 때 API 개발자로서 RESTful API에 대한 생각을 다시 해보기로 했다.

 

그 시간을 통해 RESTful API와 API를 다시 바라보면서 API에 대한 개념을 다시 정립시킬 수 있었다.

기존에 내가 인식하고 있던 RESTful API는 그저 Json 형식이나 Xml 형식으로 데이터를 제공해주는 것.
딱 이 정도만 인식하고 있었다.

내가 이해한 바로의 RESTful API는 '제약조건 속의 자유함'이다.
만약 제약조건이 없고, 자유로운 방식으로 API를 제공한다면 사용하는 사람들은 각 회사마다의 수백 가지 다른 형태의 API를 알아야 할 것이기에.. 

우리 사회가 법률이라는 제약조건 속에서 안전하며, 자유하게 살아갈 수 있는 것 처럼
API 형태도 마찬가지로 제약조건을 통해 더 효율성 있고 더 발전 가능한 API를 설계할 수 있지 않을까.

물론 말로 하는 것은 누구나 할 수 있다. 중요한 것은 이것을 적용시키는 것.

필자가 읽고 있는 책에서는 이 과정에 대해 이렇게 소개한다.

 가장 단순한 형태의 설계 절차는 두 단계를 따른다.

1. 표현에 사용할 미디어 유형을 선택한다.

이는 프로토콜 의미체계(HTTP 프로토콜 하에서 API의 행동양식)와 애플리케이션의 의미 체계(표현이 참조할 수 있는 실제 세계의 것들)에 제약사항을 결정한다.

2. 그 외 모든 것을 다루는 프로파일을 작성한다.

이것이 오늘날 대부분의 API 가 하고 있는 것이고 바로 내가 멈추려고 하는 것이다.

 

책의 저자는 이후 7가지 단계를 설명한다.

1.의미 체계 서술자 나열하기

2. 상태 다이어그램 그리기

3. 이름 조정하기

4. 미디어 유형 선택하기

5 프로파일 작성하기

6. 구현하기

7. 게시하기

 

책의 내용을 이곳에 다 넣을 생각은 없기에 여기에서 설명을 마치고, 이젠 어설프게 나마  내 서비스인 scoreloader의 API를 분석하려고 한다. RESTful API라고 가볍게 말했던 시간을 REST에대한 무게감을 느끼며 다시금 기초부터 잡아나가려 한다.

https://www.youtube.com/watch?v=fv5pIa_l7ns&t=237s&ab_channel=eo

개발자로 거듭나기⋯ 네 가지 기본 소양을 기억하세요 - 골든래빗