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

 사이드 프로젝트를 회고하면서 기획자는 넓고 얕은 지식이 중요하다고 스스로 정의내렸고, 개발+디자인을 더 공부해야겠다고 마음 먹었다. 그 결심을 실천하고자 이 책을 읽었다.

 

---

1장 오리엔테이션

1.  개발자에게 "언제까지 될까요?"라는 질문은 항상 어렵습니다.
   1. 나도 핀블을 하면서 이런 질문을 많이 물어봤다. 그래서인지 이 문장을 보고 굉장히 뜨끔했다. API 문서를 읽을 줄 알았다면 진행 상황이 어느 정도 되었고, 대략 얼마나 소요될지 알 수 있었을 텐데. 아쉬운 마음이 든다.

2장 프로그래밍 언어 & 운영체제

1. 자바, 파이썬, 루비, 스위프트 등 영어로 되어 있는 프로그래밍 언어를 사용해 컴파일러에게 명령을 전달하면, 컴파일러가 그 명령을 기계어인 0과 1로 변환해 컴퓨터에게 전달을 하는 방식입니다.
2. CPU는 컴퓨터의 머리이고, 보조기억장치인 HDD와 SSD는 컴퓨터의 창고라고 볼 수 있습니다. CPU는 따로 데이터를 저장하지 않기 때문에 데이터를 연산하거나 처리하려면 저장된 데이터를 CPU로 보내줘야 합니다. 이때 CPU는 창고 역할을 하는 기억장치인 HDD, SSD에 신호를 보냅니다.
3. ...CPU가 보조기억장치를 계속 기다려야 하므로 속도가 하향 평준화가 됩니다. 그래서 '메모리'라는 CPU의 개인 작업 공간을 만들었습니다. 이제 CPU는 보조기억장치에 필요한 데이터를 그때그때 요청하지 않아도 됩니다. 작업이 필요한 큰 데이터 뭉치를 보조기억장치에서 메모리로 한 번 옮겨놓고 메모리 안에서만 작업하면 되니까요. 가끔 메모리에 큰 데이터 뭉치만 전달해주면 되기 때문에 시간이 크게 줄어들었습니다.
4. 프로그램을 실행할 때 '자! 이제 하드디스크의 3번 플래터에 접근해서, 포토샵 데이터를 2번 메모리의 3번 구역에 올린 뒤 CPU에게 일을 시켜야지!'라고 마음먹지 않습니다. 사실 이 모든 과정을 몰라도 프로그램을 사용하는 데는 아무 문제가 없습니다. 왜냐하면 '어떤 소프트웨어'가 이 모든 과정을 대신해 주기 때문입니다. 그 '어떤 소프트웨어'가 뭘까요? 바로 운영 체제(OS)입니다....이 모든 운영체제는 우리 대신 하드웨어를 관리해줍니다.

3장 네트워크, 클라이언트, 서버

1. 파일을 계속 달라고 보채는 컴퓨터를 '클라이언트'라고 합니다. 그리고 파일을 주는 컴퓨터를 '서버'라고 합니다.
2. 리눅스는 하드웨어를 관리해서 사용자가 프로그램을 사용하기 쉽게 도와주는 윈도우나 맥 OS 같은 운영체제이고(그런데 이제 무료인), 우분투는 그런 리눅스 버전 중 하나라고 이해하시면 됩니다.
3. 레드햇은 리눅스를 개량해서 유료로 판매하는 회사입니다.
4. 서버 컴퓨터는 리눅스 위에서 서버 프로그램을 돌립니다.

4장 API와 JSON

1. API는 클라이언트, 서버와 같은 서로 다른 프로그램에서 요청과 응답을 주고 받을 수 있게 만든 체계입니다. '정확한 곳'에 해당하는 주소는 '서버주소/A'의 형태로 정의되어 있습니다. 여기서 '서버 주소'는 서버 컴퓨터가 위치한 주소입니다. ... 이러한 기능은 서버 개발자가 만들며, 그 결과물이 서버 프로그램입니다.
2. 즉, API는 서버 개발자가 개발하고, 클라이언트 개발자는 그 API를 사용합니다.
3. RESTful API에서는 이전보다 주소 개수가 줄어듭니다. CRUD를 하나의 주소로 관리합니다. 그리고 요청을 보낼 때 다음과 같이 어떤 요청을 보냈는지 파악할 수 있는 스티커(메소드)를 붙여서 함께 전송합니다.
4. 정리하자면 API는 소프트웨어가 다른 소프트웨어의 기능을 쓰기 위해 중간에 필요한 체계입니다. 쉽게 말해, 기능을 사용하기 위해 주소로 요청을 보내면 응답을 해주는 소프트웨어끼리의 체계라고 이해하시면 됩니다.
5. API를 제공해주는 '다른 소프트웨어'를 SDK라고 부릅니다.
6. JSON - 요청(Request), 응답(Response) 안에 데이터를 담는 형식
7. 클라와 서버는 요청과 응답을 주고받고, 그때 필요한 데이터들을 JSON 형식으로 주고받는다.

6장 웹(Web)

1. 각 브라우저는 서로 다른 애플리케이션이기 때무에 브라우저에 따라 그 안의 구현 방식이 다릅니다. 
2. 웹 프론트 개발자는 소비자의 브라우저 버전과 종류에 맞춰 정상적으로 동작할 수 있도록, 추가로 코드를 작성해야 합니다. 이 문제를 '브라우저의 파편화'라고 부르고, 문제 해결을 위한 코딩을 '파편화를 잡는다'고 표현합니다.
   1. 하지만 실질적으로 점유율이 높은 브라우저는 몇 안 되기 때문에 큰 상관이 없다.
3. 운영체제 안에 브라우저가 내장되자 새로운 방식으로도 애플리케이션 개발이 가능해졌습니다. 바로 애플리케이션의 특정 부분에 '브라우저'를 올리는 방식입니다. 그리고 HTML 파일을 불러올 URL을 설정해두는 거죠. 그럼 브라우저가 뜨고 그 브라우저는 HTML과 HTML에 연결된 파일들을 불러와서 보여줍니다. 그 부분은 HTML, CSS, JavaScript로 구성되어 있죠. 네이티브와 브라우저가 혼합된 애플리케이션입니다. 이렇게 웹과 애플리케이션이 혼합된 애플리케이션을 '하이브리드 애플리케이션'이라고 부릅니다.
   1. 어떤 기능이 웹인지 앱인지 구분하는 방법은! API 문서 보기!

7장 데이터베이스와 이미지 처리

1. 우리는 개발팀의 사정과 상황에 무관심해선 안 되며 회사의 개발 결과물을 잘 파악하고 있어야 합니다. 더불어 개발팀이 현재 어디에 집중하고 있는지, 어떤 부분에서 막혔는지 파악하고 있어야 합니다. 그 시작이 바로 API 문서입니다.
2. 최대한 네트워크에 부담이 가지 않도록 많은 이미지를 클라이언트에 놓아야 하지만 이미지가 바뀌었을 때 서비스에 영향을 준다면 서버에서 가져와야 합니다.

9장 협업, 소스관리, 디자인

1. 깃을 통해 개발자들은 개발 단계별로 '깃발'을 꽂을 수 있습니다. 그 행위를 커밋이라고 합니다.
2. 분석 기능과 동시에 진행해야 하는 코드들은 브랜치로 따로 관리합니다. 각각 서로 다른 곳에서 개발하는 거죠.
3. 이후 각각의 브랜치에서 작업한 코드들을 합치기만 하면 됩니다. 코드를 합치는 기능이 바로 머지입니다.
4. 개발자들은 깃을 기반으로 한 깃허브, 비트버킷 등의 원격 저장소라는 걸 만들었습니다. 개발자들이 자신의 컴퓨터(로컬)에서 작업을 한 뒤 커밋을 하면, 그 결과를 원격 저장소에 보낼 수 있고, 원격 저장소에서 이미 작업된 결과물을 가져올 수도 있습니다.

---

 역시 책은 아티클을 읽었을 때와 달리 체계화된 지식을 갖추기에 좋다. 주니어 기획자로서 개발에 필요한 지식은 이제 어느 정도 갖춘 것 같다. 실무를 하면서 아직 모르는 것들을 배워가야겠다.