본문 바로가기

Daily/민주책방

[IT 도서리뷰] 비전공자를 위한 이해할 수 있는 IT지식

# 비전공자를 위한 이해할 수 있는 IT지식
주관적 평가 - 별 5개 (5/5) ★★★★★

 

 

개발자들과의 원활한 '커뮤니케이션'을 위한 필수 도서!

이 한 마디로 정리할 수 있는 책이다.

 

IT서비스기획자로 일하면서 항시 들었던 용어들의 총 집합이었다.

다만, 그 용어들을 이해하기 쉽게 풀어주어 참 고마운 책이다.

 

 

입사 초반, 사수없이 개발자들과 직접 일하면서 맨땅에 헤딩하는 일이 다반사였다.

용어나 구조를 모르는 상태에서 무언가를 계속 요청했으니.. 개발자들도 기획자인 나도 서로가 얼마나 답답했을지.. 참 아득했던 시절이다. 지금도 전공자들과 비교하면 잘 안다고 할 수는 없지만, 책을 읽으며 업무를 복습하는 친근함을 느꼈으니 아득했던 입사 초반보다는 훨씬 성장했다는 생각이 든다.

 

입사 2년차까지 파견의 파견을 나가기도 하고, 사수없이 정말 고생 많이 했었는데, 그 때 이 책이 나와서 읽을 수 있었더라면 얼마나 좋았을까. 그 당시, 개발자들에게 커피를 사주며 적극적으로 먼저 물어보기도 하고, 생활코딩의 도움도 받고, 당시에 할 수 있었던 모든 최선을 다했었다. 그래서 더 빠르게 성장할 수 있었던 것 같다. 그런데, 그 당시 이 책을 읽을 수 있었더라면 더더더 플러스 알파로 성장할 수 있지 않았을까 하는 생각이 든다.

 

 

 

 

후배들은 나처럼 고생하지 않기를 바라며, 서비스기획자로 일하는 사회초년생들에게 정말 추천해주고픈 책이다.

물론, 깊게 들어가면 한도끝도 없을 것이다.

다만, 개발자와의 원활한 커뮤니케이션을 할 수 있을 정도의 기본 지식은 이 책에서 모두 얻을 수 있다.

 

서비스기획자에게 필요한 역량은 개발 역량이 아니다.

담당 서비스가 성공적으로 만들어지고 성장할 수 있게끔, 일이 되게끔 하는 역량이 필요하다.

이를 위해서는 다양한 이해관계자들과의 커뮤니케이션 역량, 프로젝트 추진력, 서비스 기획력 등 다양한 능력이 필요하다. 그 중 개발자와의 커뮤니케이션의 경우, 이 책을 통해 도움을 받을 수 있을 것이다.

 

비전공자를 위한 이해할 수 있는 IT지식.

IT에 대한 흥미와 애정을 더욱 키울 수 있었던, 재미있고 유익한 책이었다.

 

 

-

 

 

아래의 내용들은

기록하고 싶어서 남겨둔 정보들.

 

 

 

 

■ 프로그래밍 언어를 구분하는 하나의 기준

- 저수준 : 컴퓨터 친화적인 언어 (배우기 쉽지 않음. 구체적으로 꼼꼼하게 적어주어야 하므로, 낮은 사양의 컴퓨터에서도 원활히 작동) (ex. C언어)

- 고수준 : 인간 친화적인 언어 (사람들이 학습하기 쉬움. 저수준 언어보다 작동이 느림. 컴퓨터 사양에 따라 작동 속도 다름.) (ex. python)

저수준 언어를 사용하는 이유 - 컴퓨터 사양을 낮추어 컴퓨터 가격을 저렴하게 사용하기 위함. (IPTV 셋톱박스)

 

 

■ CRUD, RESTful API

클라이언트에서 서버에 요청을 보낼 때, 크게 4가지 - CRUD - 요소로 나눌 수 있다.

CRUD 요청은 각각의 주소를 가지는데, 주소가 너무 많아지고 관리하기 힘들어지는 문제가 발생한다. 이를 해결하기 위해, 조금 더 체계적인 API라는 사회 운동이 만들어지고, 이를 REST(Representational Sate Transfer)ful API라고 부른다.

- C : Create. 올려줘/생성해줘 : POST

- R : Read. 불러와줘 : GET

- U : Update. 바꿔줘 : PUT(전체)/PATCH(일부)

- D : Delete. 지워줘 : DELETE

 

요청을 보낼 때의 POST 등을 '메소드(Method)'라고 부른다. 수학의 함수와 같은 의미로 사용한다.

x라는 입력값에 따라서 y라는 결과가 나오는 것을 함수라고 한다.

요청을 보내면, 결과가 나오는 API 모습이 함수와 같아서 메소드라는 용어를 사용한다.

그래서 x를 '변수', '파라미터(Parameter)'라고 표현한다.

예를 들어, 로그인 요청에서 필요한 ID와 비밀번호를 '로그인 요청에 필요한 요청 변수' 혹은 '파라미터'라고 표현한다.

 

 

■ SDK (Software Development Kit)

API를 제공해주는 '다른 소프트웨어'를 SDK라고 부른다.

예를 들어, 배민이나 쿠팡이츠에서 사용하는 네이버/구글지도는 네이버/구글에서 제공하는 지도 SDK를 설치하여 기능을 넣은 예시라고 할 수 있다. 이 SDK에서 제공해주는 API들을 통해 네이버/구글 지도에 요청을 보낼 수 있다.

 

 

■ JSON

클라이언트는 요청하고 서버는 이에 응답하는데, 그 때 필요한 데이터들을 JSON 형식으로 주고 받는다.

JSON은 데이터를 주고받는 주머니와 같다. JSON이라는 파일 안에 JSON 형식으로 데이터들이 들어간다.

 

 

■ 응답 코드

- 200번대 코드 (201, 202, ...) : 잘 됐어

- 400번대 코드 (401, 404, ...) : 클라이언트 요청에서 문제가 있는 경우

- 500번대 코드 (500, 501, ...) : 서버에 문제가 있는 경우

 

 

■ 클라이언트 / 서버 - 데이터가 어디에 있는가

- 클라이언트에 데이터가 있다 : 로컬, 내부DB, 네이티브, 클라/클라이언트, 프론트/프론트엔드

- 서버에서 데이터를 가져왔다 : 서버, API, DB, 백/백엔드

 

컴퓨터라면 모두 이미지 파일을 보관할 수 있다. 즉, 클라이언트에도 이미지 파일이 있을 수 있고, 서버에도 이미지 파일이 있을 수 있다. 그 모두는 주소를 가지고 있다.

클라이언트에 이미지를 놓으면 장점이 있다. 이미지를 다운로드받지 않아도 된다. 클라이언트 프로그램이 이미지 주소를 통해 이미지를 가져온다. 네트워크보다 훨씬 빠르다.

최대한 네트워크에 부담이 가지 않도록 많은 이미지를 클라이언트에 놓아야 하지만, 이미지가 바뀌었을 때 서비스에 영향을 준다면 서버에서 가져와야 한다.

관계가 맺어진 텍스트(ex. 특정 ID 비공개로 올린 이미지 주소)는 관리하기 힘드므로 DB에 넣어둔다.

API 문서를 보았을 때, API를 통해 이미지의 주소(URL)를 서버에서 받아온다면, 그 이미지는 서버에 있는 이미지라고 판단할 수 있다.

 

 

■ 프레임워크, 라이브러리

쉽고 빠르게 개발할 수 있도록 해주는 템플릿 같은 역할.

프레임워크가 더 큰 개념이다. 각종 라이브러리와 코드들이 모여 프레임워크가 된다. 더불어 한 프로젝트에서 프레임워크는 하나만 쓸 수 있다. 한 자동차를 운전하면서 동시에 다른 자동차를 운전할 수 없는 것과 같다.

반면 라이브러리는 더 작은 개념이다. 망치나 가위 같은 도구들이기 때문에 한 프로젝트에서 함께 사용이 가능하다.

 

 

■ 커밋, 머지

- 커밋(Commit) : 개발 단계별로 꽂는 깃발

- 커밋 로그(Commit Log) : 커밋에는 항상 메모가 따라다니는데, 무슨 개발을 했는지 적어두는 메모

- 브랜치(Branch) : 새롭게 가지를 쳐서, 기존 브랜치에 커밋을 하는 것이 새로운 브랜치에 영향을 주지 않고, 마찬가지로 새로운 브랜치에 커밋을 하는 것이 기존 브랜치에 영향을 주지 않음.

- 머지(Merge) : 각각의 브랜치에서 작업한 코드들을 합치는 기능