비전공자를 위한 이해할 수 있는 IT지식(최원영 저)

<서평>
: 비전공자를 위한 이해할 수 있는 IT지식이 아니라 새내기 IT 기획자가 봐야하는 IT지식이 더 어울리는 책이다.
IT스타트업에서 PM역할을 수행했었던 기억이 새록새록 나고 뭔가 내 경험담을 직접 써놓은 것 같아서 공감되고 좋았다.
비전공자이지만 개발꿈나무인 나로서는 이미 알고 있는 내용이 대부분이어서 복습하는 겸 보기 딱 좋은 책이었다.
1회독하는데 1시간 내외 남짓이었다.
개발 입문자 대상으로 적절해 보이고 IT 기획자라면 필독서로 읽히고 싶다. 

1. 핵심 기능 -> 필요한 기능 -> 새로운 기술과 기능 반영 -: 서비스 개발

 

2. IT 서비스는 완벽한 프로세스가 없고, 고객의 니즈와 회사의 사정에 맞춰 그때그때 서비스가 계속 발전되어 나간다.

 

3. 기획자는 항상 고객을 포함한 모든 서비스 구성원들과 대화해야 한다.

 

4. IT산업에서 일하는 기획자에게 가장 먼저 필요한 건 파이썬과 자바가 아닌 커뮤니케이션이다.

 

5. 개발자에게 "언제까지 될까요?"라는 질문은 항상 어렵다.

 

6. 리누스 토발즈 - 리눅스와 Git을 만듦

 

7. 레드햇 리눅스 - 무료 운영체제를 사용하다 고장나면 AS요청 또는 질책할 수 없음 -> 레드햇을 유료로 사용하는 이유

 

8. 서버 프로그램은 24시간, 365일 안정적으로 돌아가는 게 중요하기 때문에 리눅스의 경우 굳이 GUI 방식 채택 X

 

9. API는 클라이언트, 서버와 같은 서로 다른 프로그램에서 요청과 응답을 주고 받을 수 있게 만든 체계이다.

 

10. API를 만들 때는 데이터를 주고 받는 기능도 함께 넣는다 

 

11. CRUD는 아주 중요하다. 항상 데이터를 볼 때 CRUD의 관점에서 생각하자.

 

12. 컴퓨터가 생각한다는 것은 개발자가 코딩했다는 것을 의미한다.

 

13. SDK는 API를 제공해주는 다른 소프트웨어 ex) 구글 지도 SDK 

 

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

 

15. 애플리케이션 - 설치해서 사용하는 모든 프로그램 / 스마트폰의 등장으로 스마트폰에 설치하는 애플리케이션 = 앱, 데스크톱 = 응용 프로그램

 

16. 변동이 가능한 회사 정책에 관한 정보는 보통 API로 서버에서 불러오게 만듦 - 요새는 notion페이지를 활용하기도 함(개인 경험)

 

17. HTML - 단지 브라우저가 볼 수 있는 문서를 적는 언어 / 팀버너스리가 CERN(유럽 입자 물리 연구소)에서 정보를 주고받는 상황에서 통일시키고자 만듦

 

18. HTML + CSS = 퍼블리싱

 

19. 웹 구성 3요소 - HTML(내용, 구조) + CSS(디자인) + JavaScrip(프로그래밍 언어)

 

20. 브라우저의 파편화 - 소비자의 브라우저 버전과 종류에 맞춰 정상적으로 동작할 수 잇도록 추가로코드를 작성해야함. 참고) caniuse.com 

모두를 만족시킬 필요는 없다. 중요한 건 '점유율'이다. 

 

21. 반응형 웹 - 브라우저의 가로 넓이에 '반응'하여 구성 요소가 변하는 기술

 

22. 스마트폰 내에서 꾹 눌렀을 때 회색박스 생기면 HTMl의 링크를 보여주는 애니메이션이며, 모든 부분이 새로고침된다면 이 또한 웹일 확률이 높다. 정확한 방법은 API 문서를 살펴보는 것인데, API 문서에는 웹과 앱 개발자를 위한 부분이 구분되어 있다. 같이 쓰는 경우에는 별다른 표시가 없을 수도 있긴하다.

 

23. 데이터는 단 1%의 결점도 없어야 합니다. 그래서 데이터를 관리하는 게 어렵습니다. 이러한 속성을 데이터의 무결성이라고 합니다. 그래서 데이터를 다루는 사람들은 보수적일 수밖에 없습니다. 쉽게 변화를 허용하지 않습니다.

 

24. API 문서를 읽어보면 데이터를 어디에서 불러오는지 명확하게 알 수 있다.

 

25. 클라이언트 : 로컬, 내부DB, 네이티브, 프론트/클라 // 서버 : API 요청, DB, 백

 

26. 현업에서는 이미지를 가장 많이 수정하는데, 이미지 추가, 수정을 위해서는 이미지의 위치와 주소가 중요하다.

 

27. 이미지를 클라에 놓으면 다운로드받지 않아도 돼서 빠르다.

 

28. 변동 가능한 이미지는 백에 넣어야 한다.

 

29.  git에서 개발 단계별로 깃발을 꽂는 행위 = Commit 커밋에는 항상 무슨 개발을 했는지 적어주는 메모(Commit Log)가 따라다님

 

30. git은 깃발과 깃발 사이의 변화와 누가 언제 커밋했고, 어떤 부분을 바꿨는지 추적해줌, 체크아웃을 통해 깃발이 꽂힌 부분의 코드로 옮겨 다닐 수 있음 -> 버전 관리

 

31. 브랜치 - 분기, 가치라는 뜻으로 새로운 방향의 개발을 추가해야 할 때, 기존 개발에 덮어씌어 작업하지 않고 새롭게 가지 쳐서 작업할 수 있음 -> 브랜치 간 영향 주지 않음

 

32. 머지 - 각각 브랜치에서 작업한 코드를 합침 -> 겹치는 경우 충돌(Conflict)을 알려주고 어떤 부분이 충돌됐는지 보여줌 -> 그 부분 수정하면 됨 -> 머지 후 추가 테스트를 반드시 하여야 함

 

33. 원격저장소 - GitHub, Bitbucket 등의 원격저장소는 여러 명이서 함께 작업할 때 겹치는 문제를 방지 해 주기 위한 저장소 -> 로컬에서 작업한 뒤 커밋하면 그 결과를 원격 저장소에 보낼 수도 있고, 이미 작업된 결과물을 가져올 수도 있음

 

34. 스케치, 재플린, XD - 디자이너의 작업 결과물의 수치를 보여주는 프로그램

 

35. 클라이언트 개발자는 UI를 바라보는 감각이 중요하며, 애플의 HIG(Human Interface Guideline), 구글의 Material Design 가이드 라인을 참고하여 클라이언트 개발을 잘 해나가야 한다.

 

36. 서버 개발자 = 기능 개발 후 API를 만들고 API 문서 작성

 

37. API 문서 읽는 법

애플리케이션이든 웹이든 텍스트와 이미지로 이루어져 있다. 텍스트와 이미지의 출처를 구분하자

- 해당 텍스트.이미지는 클라이언트에 있는가 서버에서 가져왔는가

- POST로도 정보를 불러오기도 하지만, 주의깊게 봐야할 정보는 GET이다.

- 분석한 결과물을 문서화하자. 무엇을 요청하기 전에 그 문서를 먼저 확인하자.

- 처음부터 완벽한 구분을 하려 하지 말자. API 문서 분석의 목적은 완벽한 분석에 있기 보다 원활한 커뮤니케이션에 있다.