.jpg)
📘 이 책을 읽게 된 이유와 느낀 점
지금은 2년차 주니어 프론트엔드 개발자이지만, 비전공자로 시작했기 때문에 이러한 책을 읽어볼 필요가 있다고 생각이 들었다. 내가 모르는 전공자들만의 것 이 궁금했기 때문이다.
책의 내용은 전공자가 아니더라도 실무를 하고 있는 개발자라면 거의 대부분 실무를 통해 알게 될 수 밖에 없는 내용들이었다. 분명 중간중간 내가 몰랐던 흥미로운 내용들도 있었지만 거의 다 익숙한 이야기들이었다.
사실 이 책의 주 타켓은 개발자 라기 보다는 기획자 또는 디자이너 였다. 하지만 이제 막 신입 개발자가 됐거나 개발자를 준비하는 사람들에게도 이 책을 추천할 수 있을 것 같다.
- 개발자들은 왜 저런 소통을 하며,
- 개발자들의 하는 이야기들을 어떻게 받아들여야 하며,
- 개발자들과 어떻게 소통해야 하는지
이러한 초점으로 글이 흘러간다. 그래서 이제 이 책을 주변에 필요한 사람에게 나눔을 하면 좋을 것 같다는 생각이 들었다.
✏️ 이 글에서 정리 하고자 하는 이야기
책에서 흥미롭게 봤던 이야기들에 대해서 정리하고자 한다. 책의 극히 일부분만 정리 할 것이기 때문에 책의 전반적인 내용이 궁금하다면 이 글 만으로는 부족하다. 공부 한 것을 정리하기 위한 글은 아니기 때문이다.
주변에 이제 개발을 준비하거나 신입 개발자로 취업한 친구들이 있다면 꼭 알려주고 싶은 내용이거나, 그냥 개인적으로 흥미로웠던 내용들이 될 것이다.
- 서버와 클라이언트. 그리고 신호
- 요청과 응답 (HTTP 상태 코드)
- 중요한건 API 문서!
- 앱과 웹 그리고 하이브리드 앱
- 클라가 들고 있다는게 뭐죠?
- 배너 좀 바꾸려는데, 자꾸 자기한테 말하면 안된대요
⚡ 서버와 클라이언트. 그리고 신호
신호를 주고 받는 과정
우리는 무의식적으로 서버와 클라이언트를 사용하고 신호를 주고받는다.
아래 예시를 보자.
카카오톡을 다운로드하고 실행하면 아래 순서로 일이 진행된다.
- 스마트폰을 꺼내 앱스토어에서 카카오톡을 설치한다.
- 다운로드 버튼을 누르면 가장 가까운 기지국으로
카카오톡 설치 파일을 보내줘!라는 신호가 간다.- 신호는 WAN을 따라 이동하고 마치 우편물처럼 최종 목적지(애플 앱스토어)를 향해 이동한다.
- 카카오가 앱스토어에
설치 파일을 올려두었기 때문에 애플의 앱스토어에는카카오톡 설치 파일이 존재한다. 이제 애플의 컴퓨터에서카카오톡 설치 파일을 내 컴퓨터(스마트폰)로 보내준다.- 다운로드가 완료되면 자동으로 설치가 되고 컴퓨터(스마트폰)의 보조기억장치 (HDD나 SSD)에 실행파일이 저장된다.
- 카카오톡 아이콘을 누르면 실행에 필요한 부분들이 메모리 위로 올라가고
- CPU가 이 데이터들을 처리하며 카카오톡을 동작시킨다.
- 친구들의 보낸 이미지, 동영상들을 다운로드하면 위 과정과 동일하게 신호를 보내고, 카카오톡의 컴퓨터에서 이미지와 동영상 파일을 나의 컴퓨터(스마트폰)으로 보내준다.
서버와 클라이언트
스마트폰은 하나의 컴퓨터이다. 일반적인 퍼스널 컴퓨터(PC)와 같이 CPU, 메모리, 보조기억장치가 존재하고 window와 같은 운영체제가 설치되어있다. (iOS | Android)
위 예시에서 컴퓨터의 역할을 두가지로 정의해보자. 서버와 클라이언트 이다.
- 클라이언트: 파일을 달라고 보채는 컴퓨터 (당신의 스마트폰)
- 서버: 파일을 주는 컴퓨터 (애플 | 카카오)
식당에서 주문하는 예시를 보자.
"여기 메뉴판좀 주세요"
"물 좀 가져다주세요"
"주문이요"
이것은 손님(클라이언트)의 역할이다. 종업원은 서빙하는 사람. 즉 서버라고 할 수 있다.
💌 요청과 응답
CRUD와 RESTfulAPI
우리는 개발을 공부할때 기본적인 것 중에 CRUD 를 배운다.
- C = Create (생성)
- R = Read (읽기)
- U = Update (쓰기)
- D = Delete (삭제)
데이터를 다루는 아주 기본적인 내용이다. 책에서는 이것은 기획자들에게도 중요하다고 말한다. 예를들어 데이터를 볼 수는 있는데, 만드는 기획을 빠뜨릴 수 있고, 수정하거나 삭제하는 기획을 빠뜨릴 수 있다.
백엔드와 프론트엔드가 통신을 할때도 마찬가지로 좀 더 체계적으로 API를 관리할 수 있도록 CRUD를 의미적으로 전달해야 한다. 이러한 API 요청을 REST(Representational State Transfer)한 API라는 의미에서 RESTfulAPI 라고 한다.
자주 쓰이는 Method 에는 POST, GET, PUT, PATCH, DELETE 이렇게 5가지가 있다. 이 5가지는 위에 설명한 CRUD와 매칭이 된다.
POST= CreateGET= ReadPUT= Update (전체)PATCH= Update (일부)DELETE= Delete
RESTfulAPI는 모든 회사에 통용되는 절대 규칙은 아니고 일종의 사회운동으로써, 상황마다 다양한 방식으로 변형해서 사용한다.
요청과 응답
서버(파일을 주는 컴퓨터) 의 관점에서 생각해보자. 클라이언트가 어떠한 응답을 했을때 컴퓨터는 이렇게 생각할 수 있다.
"요청을 보낸 사용자가 우리 서비스에 가입된 사용자인가?"
"비밀번호가 틀렸다! 확인해보라고 말해줘야겠네"
"친구 중에 A를 찾아달라고? A는 없는데? 없다고 말해줘야겠네"
컴퓨터가 생각한다는 것은 개발자가 그렇게 코딩했다는 것을 의미한다. 컴퓨터가 응답하는 것에는 크게 2가지로 나눌 수 있다.
- 잘 됐다.
- 잘 안됐다.
하지만 잘 됐다와 잘 안됐다도 각각 표현이 다를 수 있다.
그래서 헷갈리지 않게 HTTP Status 코드로 잘 됐다의 경우 200번대 코드로 표현하기로 한다. (200, 201, 202 ...)
잘 안됐다의 경우는 크게 클라이언트의 요청이 잘못 됐을 경우와 서버 내부적으로 잘못 됐을 경우가 있다. 그 경우 400, 500번대로 표현하기로 한다.
200번대: 잘 됐다.400번대: 클라이언트 요청이 잘못돼서 잘 안됐다.500번대: 서버 내부적으로 문제가 있어서 잘 안됐다.
📱 앱과 웹 그리고 하이브리드 앱
애플리케이션 (앱)
애플리케이션(앱)이 뭘까? 설치해서 사용하는 모든 프로그램을 말한다. 윈도우 운영체제에서는 응용 프로그램이라 부르지만 같은 특징을 가지고 있다.
설치해서 사용하는 프로그램 이다보니 사용자들마다 프로그램을 설치한 날짜와 버전이 다를 수 밖에 없다. 만약 누군가는 버전을 업데이트하고 누군가는 하지 않는다면 어떤 문제가 발생할 수 있을까?
버전 1.0.0에서 아래와 같은 공지를 애플리케이션에 넣어놨다고 가정한다.
"우리 서비스의 가격은 10,000원 입니다."
그런데 시간이 흘러 가격이 올랐고, 버전 1.0.1로 업데이트를 하면서 변경된 가격인 20,000원으로 공지를 바꾼다.
"우리 서비스의 가격은 20,000원 입니다."
어떤 문제가 있을까? 버전 1.0.0을 사용하는 사람들에게는 여전히 10,000원으로 보인다는 점이다. 막상 결제를 하려고 보니 20,000원이 결제 되어있는 황당한 상황을 겪게 될 것이다.
그래서 변동 가능한 회사 정책에 관한 정보는 보통 애플리케이션에 넣지 않고 API를 통해 불러오게 만든다.
웹
웹은 운영체제 상관 없이 브라우저만 있으면 동일한 정보를 볼 수 있다. 웹은 설치해서 사용하는 프로그램 이 아니기 때문에 (브라우저는 설치해야 한다) 버전을 따로 업데이트 할 필요가 없다.
웹사이트의 버전이 업데이트 됐을 경우, 사용자 입장에서는 그냥 새로고침을 해주거나 사이트에 다시 접속하게 되면 새로운 HTML, CSS, Javascript, 이미지 파일등이 새로 다운로드 된다.
하이브리드 앱
애플리케이션의 특정 부분이나 페이지에 브라우저 를 올리는 방식이다. HTML을 불러올 URL을 설정해두면 HTML파일과 관련 파일들을 불러온다 (HTML, CSS, Javascript, 이미지 등) 이런 혼합된 파일들을 하이브리드 애플리케이션 이라고 부른다.
하이브리드앱의 장점에는 브라우저가 올라간 페이지는 수정하기 좋다는 점이 있다. 스토어에 애플리케이션 버전을 업데이트 하기 위해서는 심사를 받아야 하는데 애플은 심사가 참 까다롭다. 그리고 유저들도 앱을 업데이트 해줘야 한다.
하지만 브라우저에 올라가 있는 HTML등의 파일은 새로고침을 하면 바로 업데이트가 반영이 되기 때문에 수정이 편하다는게 장점이다.
하이브리드앱의 단점에는 브라우저가 올라간 페이지는 네트워크에 종속되기 때문에 와이파이나 모바일 네크워크가 느린 공간에 가면 영향을 받을 수 있다는 점이 있다.
❓ 클라가 들고있다는게 뭐죠?
보통 데이터는 서버쪽에 저장한다고 생각하기 쉽지만 사실 클라이언트에도 데이터를 저장할 수 있다. 개발의 이슈에 따라서 클라이언트의 데이터베이스도 많이 활용된다.
예를들어 알람 앱을 떠올려보자.
8시 20분, 8시 30분, 8시 40분... 이 시간은 데이터이고 클라이언트에서 관리한다. 이것을 어떻게 알 수 있을까? 인터넷이 연결되지 않은 상태에서도 동작하는 것을 보고 알 수 있다.
그리고 앱스토어를 보자. 앱스토어의 카카오톡 데이터는 서버쪽 데이터베이스이다. 이 데이터는 어떤 스마트폰에서 접속해도 똑같이 보인다. 데이터가 서버에 있기 때문에 데이터를 변경한다면 다른 모든 기기에도 변경된 데이터가 표시 될 것이다.
🏞 배너 좀 바꾸려는데, 자꾸 자기한테 말하면 안된대요
"이 배너 좀 새로운 캠페인 배너로 바꿔주세요. 엄청 중요하고 급해요!"
"배너 이미지는 서버에서 받아오고 있어요. 서버 개발자에게 얘기하세요."
자주 발생할 수 있는 이야기다.
"이 부분 아이콘을 새롭게 바꾸고 싶어요."
"아이콘은 클라에 있는 거에요. 클라 개발자한테 얘기하세요."
도대체 이미지가 어디에 위치하는지 어떻게 구분할 수 있을까?
1
생각해보자. 이미지 하나에 100MB가 넘는 큰 이미지가 있다고 가정하면, 그 이미지를 다운로드 하려면 어마어마한 시간이 걸릴 것이다.
클라이언트에 이미지를 놓게 되면 이 이미지를 매번 다운받을 필요 없이 프로그램 내에서 가져오게 된다.(앱) 네트워크보다 훨씬 빠르다.
그렇다면 굳이 서버에 이미지를 둘 필요가 있을까?
다시 생각해보자. 클라이언트의 이미지는 어떻게 수정할까? 클라이언트의 이미지를 수정하기 위해서는 앱을 업데이트 해야 한다. 만약 고객이 앱을 업데이트 하지 않는다면 수정 전의 이미지를 보게 될 것이다.
2
이미지를 만드는 주체가 회사일 수 있지만, 고객일 수도 있다. 예를들면 인스타그램의 게시글이나 프로필 이미지 등이 있다. 이러한 관계(고객-이미지)가 연결 된 상황에서는 데이터를 DB에 보관해야한다. 고객이 프로필 사진을 업데이트 했다고 해서 인스타그램 버전이 올라가야 하는것은 말이 안된다.
마치면서
위 정리한 글 외에도 저자는 기획자로 API문서를 볼 줄 알아야 한다를 강조했다. 협업하는 사람들에게 많은 것을 묻지 않고도 스스로 진행을 파악할 수 있으며 서비스 전반적인 기능을 파악할 수 있기 때문이다.
IT업계에 발을 들인 기획자, 디자이너라면 이 책이 분명 개발자와의 소통에 도움이 될 것이고, 꼭 소통을 위한다기 보다는 IT업계의 기본일지도 모르는 이야기들이 많다. 또는 초보 개발자들이 꼭 알아야 할 내용도 많다.
쉬운 예시와 그림과 함께 잘 설명 되어 있기 때문에 이해하기도 어렵지 않아 보인다.
하지만 아무리 비전공자라도 이미 경력을 쌓고있는 2년차 주니어개발자 이상 개발자들에게는 이미 알고있는 이야기들이 많아서 이 책 보다는 다른 책들을 찾는게 맞다고 생각한다.
