비전공자를 위한 이해할 수 있는 IT 지식
개발 협업에 답답함을 느끼는 당신에게
개발을 배워야 할지 고민하는
비개발자에게 추천하고 싶은 책
내가 이 책을 꼭 읽고 싶었던 이유
"아.. 답답해, 개발을 좀 알아야 하나?" IT업계에서 일하는 디자이너가 한 번쯤 하게 되는 고민이다. UIUX디자이너로 9년째 일하고 있지만 "개발을 배워야 하나?"라는 생각은 1년 차 때부터 했던 것 같다. 디자인이 어떤 방식으로 구현되는지 궁금하기도 했고, 개발을 핑계로 안된다고만 하는 일부 농땡이 개발자들로부터 방어할 수단이 필요하기도 했다.
일단 개발을 제대로 공부하자니 너무 진입장벽이 높았다. 그때 누군가는 그랬다. "반대로 말해서 개발이 일할 때 디자인을 배우려고 하나요? 뭘 굳이.. 배울 필요 없어요", "개발 공부할 시간에 디자인에 대한 고민을 더 하는 게 나아~"등의 답변을 받았다. 하지만 업무를 할 때마다 느껴지는 답답함은 꾸준히 나를 불편하게 했다.
가장 먼저 알아야 할 것은
프로그래밍 언어가 아닌 '커뮤니케이션'
막연하게 개발에 대해 고민하지만, 우리에게 필요한 건 개발 언어가 아니라 바로 '커뮤니케이션'이다. 소통이 가능한 정도의 개발 구조를 먼저 이해하자. 그리고 그 개발 이해의 시작으로 이 책을 추천한다. 이 책은 프론트/백엔드의 개념을 쉽게 설명한다. 디자이너는 백엔드와 협업할 일이 많이 없지만, 그래도 전반적인 개발흐름을 알아두면 좋다. 개발을 전혀 모르는 UIUX디자이너라면 이 책을 통해 개발 개념을 간단히 파악한 뒤, 틈틈이 개발 지식을 찾아보거나(생활코딩, 유튜브 등) 프로젝트 진행 시 개발자와 끊임없이 소통하는 것을 추천한다. 나도 프로젝트 진행 시 궁금한 부분은 개발자에게 계속 물어본다. (그래서 개발자에게 잘해주려고 한다..)
책을 읽으며 중요하다고 생각되는 부분을 약간의 도식화와 함께 정리했다.
(정리하다 보니 겁내 길어졌다. 스크롤 압뷁 조심하세요..)
1. 프로그래밍 언어 & 운영체제
1-1. 프로그래밍 언어는 어느 나라 말..?
언제나 개발자의 화면은 스펠링이 가득한 화면으로 도배되어 있다. 정확히 무슨 일을 하는 걸까?
개발자는 컴퓨터로 다양한 서비스를 구현해내는 사람이다. 하지만 컴퓨터는 사람의 말을 못 알아듣는다. 그래서 개발자와 컴퓨터 사이에는 컴퓨터에게 일을 시키는 '컴파일러'가 존재하는데, 개발자가 프로그래밍 언어로 컴파일러에게 문서를 전달하면 컴파일러가 컴퓨터 언어인 0,1로 변환하여 컴퓨터에게 일을 시킨다.
컴퓨터에게 일을 시키는 언어들(C언어, 자바, 파이썬 등등)은 천재 개발자 or 기업(에 있는 천재)에서 만든다. 개발자들에게 사랑을 받아 살아남거나 사라짐을 끊임없이 반복하며 개발 언어가 진화한다.
IDE란 개발 코딩을 돕는 프로그램이다1-2. 운영체제 파악 전에 컴퓨터에 대해 간단히 알아보자.
"HDD보다는 SSD지", "메모리 용량이 얼마나 돼?" IT업계에서 일하면서도 저런 말들을 1도 못 알아 들었다. 그만큼 컴퓨터에 관심이 없었는데 알고 보니 저 용어들은 사람의 뇌, 간, 허파처럼 컴퓨터를 구성하는 장기(?)라고 생각하면 쉽다.
CPU는 컴퓨터의 뇌다. 하지만 기억력은 없다. 그래서 HDD, SSD에 기억을 저장해서 필요한 정보를 그때그때 꺼내 쓴다. 근데 HDD, SSD가 너~~무 넓다 보니 원하는 정보를 찾는 시간이 넘나 오래 걸린다. 그래서 Memory라는 작업공간을 따로 만들어서 필요한 정보 덩어리를 일단 옮긴 후, Memory에서만 작업하기 때문에 훨씬 속도가 빨라지는 것이다. 예로 포토샵을 사용하려고 클릭하면 HDD(SSD)에서 포토샵만 똑 꺼내와서 메모리에 넣어놓고 우리는 그 안에서 메모리랑 소통하며 작업하는 것이다. 깨달았다. 그래서 메모리 용량을 올리면 속도가 좀 더 빠르게 느껴지는 거였군!
이렇게 컴퓨터의 작동 원리를 알면 운영체제도 이해가 쉬워진다.
겉으로 보기에는 프로그램을 클릭-실행하는 것 같이 간단해 보이지만, 보이지 않는 곳에서 운영체제가 작동하여 컴퓨터 화면으로 출력해준다. 우리가 잘 아는 윈도우, 맥, IOS, Android들이 바로 그 운영체제들이다.
1-3. 윈도우와 맥은 말이 안 통해!
윈도우에서 만든 프로그램은 맥에서 사용할 수 없고, 아이폰 앱을 구글 앱스토어에서 다운로드할 수 없다. 어쩌면 운영체제는 각각의 나라 같아서, 달러로 한국에서 물건을 살 수 없는 것과 같은 너낌이다.
이렇게 되면 개발이 힘들어진다. 서비스 하나를 만들려면 윈도우용 맥용 2번 개발해야 한다. 그래도 2개 운영체제까지는 어찌저찌 대응하겠지만, 운영체제가 3개 4개라면? 공수는 3배 4배가 될 것이다. 이런 불편함을 해결하기 위해 다른 천재들이 어떤 운영체제에서도 사용할 수 있는 프로그램을 개발했다.
JVM(자바), 파이썬 등의 프로그램이 바로 그것이다..! 저 프로그램들을 깔고 개발을 하면, 하나의 언어로 많은 운영체제 위에서 실행이 가능한 서비스를 만들 수 있다. 단점이라면 운영체제 위에 해당 프로그램을 깔고 거기서 개발을 하기 때문에 좀 느려질 수는 있다고 한다.
2. 네트워크, 서버, 클라이언트
2-1. 랜(LAN)이 뭐죠?
컴퓨터'만' 사용하는 사람은 없다. 인터넷을 통해 다른 사람과 의견을 나누고 정보를 교환한다. 어떻게 그게 가능할까? 컴퓨터가 연결된 작은 지역을 LAN(Local Area Network)라고 한다. 그리고 그 작은 LAN들을 하나로 연결해 MAN(Metropolitan Area Network)이 된다. 그리고 더 크게 연결하여 WAN(Wide Area Network)를 만들었다. 우리가 한강에서 카카오톡을 하고, 집에서 다른 친구와 게임을 하는 것들은 다 이런 네트워크가 잘 연결되었기 때문이다.
2-2. IP가 있는 이유
컴퓨터는 서로 LAN-MAN-WAN으로 연결되어 정보들을 주고받는다. 친구에게 편지를 보낼 때도 집주소를 적어야 편지가 온전히 전달되듯이 컴퓨터도 서로 정확한 위치에 정보를 전달하려면 주소가 필요하고, 그 컴퓨터 주소가 바로 IP이다. 숫자가 간편하고 명확하기 때문에 IP는 12개의 숫자로 이루어져 있으며 위치정보이기 때문에 연결하는 기기가 이동하면 IP주소도 이동한다.
2-3. 주거나 받거니, 서버와 클라이언트
카카오톡에 올린 이미지를 내 핸드폰에 저장하려고 클릭하고 다운로드했다. 여기서 내 핸드폰은 무언가를 요청하는 클라이언트(Front) 컴퓨터이고, 해당 이미지를 다운로드할 수 있도록 해주는 보이지 않는 컴퓨터가 서버(Back)이다.
2-4. 서버 컴퓨터는 어떤 운영체제일까?
우리가 사용하는 컴퓨터(클라이언트)는 윈도우,맥 등 우리가 잘 아는 운영체제로 이루어져 있다.
그렇다면 서버 컴퓨터는 어떻게 구성되어 있을까? 보통 서버 컴퓨터는 보편적으로 '리눅스'라는 운영체제에서 프로그램을 돌린다. 왜 리눅스를 사용할까? 이유는 간단하다. 무료이기 때문이다.
'리누스 토발스'라는 천재가 리눅스 프로그램을 만들어 무료로 배포했다고 한다.
2-5. 서버 컴퓨터들은 어디 있는 걸까?
컴퓨터로 소통하고 정보를 교환하려면 네트워크를 통해 클라이언트-서버 2대의 컴퓨터가 필요하다.
지하철, 학교, 회사 등 사람들이 사용하고 있는 모든 컴퓨터가 클라이언트이다.
수많은 사람들이 24시간 시도 때도 없이 요청하는 정보를 주려면 수많은 서버 컴퓨터들이 하루 종일 움직여야 할 것이다. 만약 개인이 서비스를 만들어서 많은 사람들이 사용한다고 하면 전기세가 만만치 않을 거다.
그래서 이 서버 일들을 대신해주는 회사들이 나타나기 시작한다. 아마존의 AWS, 카페24, 가비아 등이 서버 운영 전문 업체이다. 그 회사 안에 서버 컴퓨터들이 숨어있을 것이다..
3. API와 JSON
개인적으로 프로젝트를 하면서 가장 많이 들어본 단어라 책 내용을 좀 더 많이 담았다. 스크롤 압뷁 주의..
3-1. API(Application Programming Interface)란?
간단히 말하면 데이터를 "조회할 수 있도록 만들어진 규칙"이다.
클라이언트가 어떤 요청을 하면 서버 컴퓨터가 응답을 해줘야 한다. 하지만 컴퓨터는 인간의 말을 모르기 때문에 이것이 어떤 요청인지를 알려줄 '방법'이 필요했고, 그 방법이 바로 API이다. 서로 다른 프로그램 사이에서 요청과 응답을 주고받을 수 있게 만든 체계이다. 책만으로는 API가 피부에 와 닿게 이해가 되지 않아 아래 링크를 좀 더 참고했다.
Midium: 초보 개발자 > API란?
https://dydrlaks.medium.com/api-%EB%9E%80-c0fd6222d34c
3-2. API가 하는 일 좀 더 자세히 보기
API는 요청과 응답 사이에서 교환을 돕는 역할을 하기 때문에 요청을 보내는 쪽과 응답을 주는 쪽이 나뉘어 있다. 또한 요청을 깔끔하게 정리하기 위해 요청 별로 이 요청은 A지역, 저 요청은 B지역으로 이동시켜 요청들을 구분하기 쉽게 정리한다. 여기서 '지역'이 서버주소(IP주소)이다. 참고로 API에는 요청을 주고받는 기능 외에도 데이터를 주고받는 기능도 함께 넣는다. 예로 로그인 요청 시 필요한 아이디/비번, 이미지 요청 시 필요한 이미지 파일 등의 데이터도 함께 API에 담겨야 한다.
3-3. 클라이언트 관점에서 보는 API
기본적으로 요청은 CRUD를 가지고 있다보통 하나의 요청은 "[Creat]올려줘, [Read]불러와줘, [Update]바꿔줘, [Delete]지워줘" 이 4가지 요소를 담고 있다. 개발자들도 데이터를 볼 때 항상 CRUD 4가지 관점에서 생각한다. 그래서 기획자는 항상 어떤 서비스를 생각할 때 이 CRUD의 관점에서 기획하는 습관이 필요하다. 예를 들어, 데이터를 볼 수는 있는데 수정하거나 삭제하는 기획이 없으면 안 되는 것처럼 말이다.
3-4. 좀 더 똑똑한 API, RESTful API
하나의 요청당 CRUD 4개의 주소를 각각 가지고 있다. 그런데 규모가 커질 경우 이렇게 각각의 주소를 가지면 문제가 생긴다. 주소가 너무 많아진다는 점이다. 주소가 많아지면 혹시나 주소가 겹쳐 혼선이 생길 수도 있고 관리하기가 어려워진다. 그래서 답답한 개발자들이 이 문제에 대한 방법을 고민했고, 요청 체계를 더 체계적으로 관리하기 위해 만들어진 것이 RESTful API라고 한다. (참고로 RESTful은 절대 규칙이 아닌 유명한 체계이다.)
CRUD를 하나의 주소로 관리하되 C, R, U, D를 구분할 수 있도록 스티커*를 붙여서 전송한다.
무분별하게 늘어나는 주소를 관리하기 위해, 하나의 주소에 CRUD를 관리하되 요청을 구분할 수 있게 스티커를 붙여 전송한다.* RESTful API에 붙는 스티커란?
쉬운 표현으로 '스티커'라는 단어를 사용했지만, 개발에서는 메소드(Method)라는 용어를 사용한다. 메소드는 개발에서 함수를 뜻한다. 또한 변하는 수 'x'를 '변수', '파라미터'라고 표현한다. 예를 들어 로그인 요청에 필요한 ID와 비밀번호를 '로그인 요청에 필요한 요청 변수' 혹은 '파라미터'라고 표현한다.
3-5. 서버의 관점에서 보는 API
위에 CRUD라는 4개의 요소로 데이터를 서버에게 요청한다. 그럼 서버가 응답할 것이다. 예상되는 응답은 성공, 실패 2가지다. 하지만 컴퓨터는 인간의 언어를 알아듣지 못한다. 그래서 명확한 숫자로 회신을 표시한다. 또한 숫자를 디테일하게 정의하여 어떤 문제인지를 쉽게 파악할 수 있도록 한다. 우리가 가끔 보는 404 에러가 바로 이것이다. (400대이니 서버는 문제가 없는데 클라이언트 요청이 이상했다는 뜻이다.)
- 성공 시: 200번대 코드 (201,202 등등)
- 실패 시: 클라이언트 요청이 잘못돼서 안된 경우 400번대, 서버 문제로 안된 경우 500번대
*주로 200, 400, 500이 빈번하게 쓰인다고 한다. 100-300 상태 코드 외 자세히 알고 싶다면 아래 링크를 확인해보자.
https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C
3-6. API의 개념을 확장한 SDK
API가 클라이언트와 서버의 연결 체계라면 SDK는 소프트웨어와 소프트웨어를 연결해주는 도구이다. Software Development Kit의 약자로 소프트웨어를 개발할 때 도움을 주는 '다른 소프트웨어'이다.
예를 들어 자신이 만든 소프트웨어에 구글 지도 기능을 넣고 싶으면 어떻게 해야 할까? 이럴 때 구글 지도 SDK를 내 소프트웨어에 설치하면 된다. 구글 지도 SDK에서 제공하는 API를 통해 구글 지도에 요청을 보내 데이터를 받아 사용할 수 있다.
3-7. JSON은 뭐죠?
디자이너 기준으로 말하면 '에펙에서 만든 결과물을 컴퓨터가 읽을 수 있도록 만든 코드 규칙 문서'로 에펙 작업물을 컴퓨터가 읽을 수 있도록 도와주는 역할을 한다.
보통 움직이는 애니메이션을 에펙에서 만드는데 gif로 삽입하면 용량이 크고 느려질 수 있기 때문에 JSON파일로 전달하면 좋다. 에펙 파일을 컴퓨터가 읽을 수 없기 때문에 JSON이라는 코드 규칙 안에 데이터를 잘 담아 컴퓨터에 전달하면 고스펙 애니메이션을 가볍게 구현할 수 있다.
*그럼 로띠(Lottie)는 뭐지?
로띠(Lottie)는 에어비엔비가 만든 애니메이션 라이브러리로 에펙에서 만든 모션을 JSON파일로 변환해주는 플러그인이다. 로띠 사이트(lottiefiles.com)에서 다양한 애니메이션을 다운받을 수도 있다.
3-8 JSON 알아보기
API, SDK, JSON 모두 범위는 다르지만 동일한 개념으로 클라이언트와 서버 , 소프트웨어와 소프트웨어 사이에서 요청한 응답을 주고받을 수 있게 만든 하나의 도구들이다. JSON에는 데이터를 담은 기능도 같이 개발되어있는데 그 '기능'에는 여러 가지 형식이 있을 수 있다.
회원 정보를 담은 API를 예로 들어 보자.
A. 아이디,요청일자,다른정보////abcd1234,20201217,VIP회원
B. 아이디:abcd1234, 요청일자:20201217, 다른정보:VIP회원
C. [(아이디:abcd1234)], [(요청일자:20201217)], [(다른정보:VIP회원)]
위 A, B, C처럼 개발자마다 회원정보(데이터)도 각기 다른 형식으로 담을 수 있다. 하지만 이렇게 규칙이 너무 많아지면 개발이 힘들어진다. 곳곳에 들어가는 규칙이 전부 다~ 다르면 그 규칙을 읽을 수 있게 코드를 또 다~~ 짜야하기 때문이다. 그래서 개발자들은 유명한 형식을 동일하게 같이 써서 효율성을 높이고자 했고, 그 형식 중 하나가 JSON이다. (예전에는 XML이라는 형식이 널리 쓰였는데 지금은 JSON이 가장 유명하다고 한다.)
3-9. JSON 조~금 더 알아보기
자, 그럼 JSON이 유명한 코드 규칙이라고 했는데 어떻게 생겼을까?
*JSON형식
{
키1(Key): 값1(Value),
키2(Key): 값2(Value),
키3(Key): [ 값3, 값4, 값5 ] <-- 여러정보 요청시
}
JSON은 키와 값으로 이루어져 있고 :(콜론)으로 구분한다. 여러 정보를 같이 불러올 때는 배열(Array)이라는 형식 [값, 값, 값]을 사용한다. 로그인 요청을 JSON으로 보낸다고 가정해보자.
{
"id": "jerrie",
"pw": "abcd12345"
}
ID는 jerrie, PW는 abcd12345인 사용자를 로그인시켜줘!라고 요청할 때 정보를 JSON파일에 담아서 보냈다.
{
"category": "음료"
"taste": "달다"
"items": [ "카페 모카", "카페라떼", "카라멜마끼야또" ]
}
category가 '음료', taste가 '달다'인 아이템 카페모카, 카페라떼, 카라멜마끼야또 정보를 받아!라고 상품 정보를 응답할 수도 있다. 마치 데이터를 주고받는 주머니 같다.
3-10. API 문서 살펴보기
API, JSON 개념을 파악했으니 실제 개발에서 사용되는 API문서를 살펴보자. 깃북은 API문서 작성을 도와주는 서비스이다.
위 깃북 사이트에 들어가 봤다.
가입을 하고 API문서 생성을 하면 요런 페이지가 뜬다.우리가 앞서 배웠던 GET스티커(라 부르고 메소드라 이해한다)를 발견했다! 오 신기신기ㅋㅋ
API는 요청/응답을 도와주는 도구라고 했듯 Request, Respense 항목이 있다.
그리고 저 GET스티커를 눌러보니 위에서 앞서 공부했던 다른 스티커들도 발견했다. 근데 모르는 스티커(메소드)도 있다. 요청/응답 부분도 한번 살펴보자.
Path Parameters, Headers, Query Parameters들이 적혀있다.
요소 하나하나를 이해할 순 없지만 "Parameter"는 메소드(함수)를 보낼 때 요청 변수라고 했다. 어떤 요청을 보내기 위해 필요한 파라미터(요청 변수)를 체크하는 영역이라고 이해하면 될 것 같다.
오~ 앞서 배웠던 서버가 응답을 보내는 숫자 코드이다.(3-5 참조) 200대일 경우 아래 코드를 전송하고, 404일 경우 "Ain't no cake like that"(그런 케이크는 없다)라는 메시지를 보내주라고 되어있다.
+Add Respense Example 버튼을 눌러 다른 메시지를 추가 구성할 수도 있다.
4. 애플리케이션
4-1. 애플리케이션의 특징
데스크톱에 설치하는 프로그램은 '응용 프로그램'이라고 부르고, 스마트폰에 설치하는 프로그램은 '앱'
, '어플' 혹은 '애플리케이션'이라고 부른다. 이런 프로그램들은 특정 운영체제 위에서 작동되는 공통점이 있다.
앱은 꾸준히 업데이트된다. 그리고 개발자는 자신이 개발한 프로그램에 '1.0.0'과 같이 번호를 부여하는데, 이 번호를 버전이라고 한다. 보통 오른쪽 끝자리는 작은 변화를 의미하고, 왼쪽 끝자리는 하위 버전과 호환이 가능하지 않은 큰 변화를 의미한다.
앱은 업데이트를 해야만 변경된 내용이 보이기 때문에 가격 정보같이 변화에 민감한 내용은 앱에 넣지 않는다. API로 서버에서 불러오도록 한다.
4-2. 앱 생태계
모바일은 '앱 마켓'에서 앱을 올려놓고 판매할 수 있다. iOS의 '앱스토어'와 안드로이드의 '구글 플레이 스토어'를 말한다. 각 앱 마켓마다 룰이 정해져 있어 해당 직원이 직접 애플리케이션을 살펴보고, 버그가 있으면 앱스토어에 올리는 걸 거절하는데 이를 '리젝(Reject)'이라고 한다. 사전 심사는 애플이 깐깐하여 등록이 좀 더 어렵다. 안드로이드는 상대적으로 등록이 쉽다고 하는데, 대신 구글 지침에 맞지 않는 앱이 있다면 예고 없이 마켓에서 내려버린다. 그리고 복구에 대해 구글과 논의하려면 상당한 시간이 걸린다. 이렇게 구글과 애플은 서로 다른 생태계를 가지고 있다.
5. 웹
웹은 HTML, CSS, JavaScript 3가지로 구성되어 있다. 이들의 정체를 개념만 살짝 파악해보자.
5-1. HTML은 프로그래밍 언어가 아니다.
HTML은 '유럽 입자 물리 연구소'에서 시작되었다. 그 당시 연구소에서 일하던 '팀 버너스리'는 연구소 직원들에게 수많은 정보들을 편리하게 주고받기 위해 어떤 운영체제나 프로그램에 상관없이 일정한 내용이 동일하게 보이도록 하는 구조를 만들었는데, 그것이 바로 HTML이다. HTML은 프로그래밍 언어가 아니다. 컴퓨터가 아닌 단지 '브라우저'가 볼 수 있는 문서를 적는 언어이다.
5-2. CSS! HTML을 도와줘
여튼 이렇게 만들어진 HTML로 많은 사람들이 정보를 교환하기 시작했다. 그러면서 점점 디자인 기능에 대한 아쉬움이 생겨난다.
'웹을 통해 회사를 멋있게 소개하고 싶은데 방법이 없을까?'
'내가 가게를 하나 열었는데, 오픈/마감 시간이나 메뉴를 잘 보여줄 순 없을까?'
HTML은 정보를 많은 사람들에게 알려주는 것에만 초점을 두다 보니 디자인 기능이 부족했다. 사람들은 포토샵이나 일러스트레이터 같은 디자인 기능을 원했고, HTML에 디자인을 입힐 수 있는 코드인 CSS(Cascading Style Sheets)를 만들어 붙였다. CSS는 HTML뼈대에 입히는 디자인 스타일이라고 보면 된다.
그리고 HTML과 CSS를 합쳐서 '퍼블리싱' 작업이라고 표현하고, 이런 일을 하는 사람들을 '퍼블리셔'라고 부른다. '마크업'이라는 말도 종종 사용한다. '마크업 디자인', '마크업 작업', '마크업 개발자'등등으로도 불린다.
5-3. JavaScript의 등장
이렇게 HTML로 정보의 뼈대를 만들어 CSS로 정보를 시각적으로 잘 표현했고 사람들은 더 널리 웹을 사용했다. 그러자 또 다른 기능을 원하는 사람들이 생겨났다.
'링크 말고 좀 다른 기능을 붙이고 싶은데..'
'API요청을 주고받고 싶은데..'
'장바구니에 물건을 넣고 싶은데..'
'로그인과 회원가입을 어떻게 시킬 수 있을까?'
단순히 정보를 주고받는 것을 넘어 회원가입을 한다거나, 다른 기능들을 웹에 연결하는 좀 더 동적인 작업을 필요로 했다. 이런 기능은 HTML과 CSS로는 힘든 기능들로 프로그래밍 언어가 필요하다.
그래서 웹에서는 JavaScript라는 프로그래밍 언어가 그 역할을 하기 시작했다. (줄여서 js라고도 부른다)
5-4. JAVA와 JavaScript와의 관계
이름만 비슷할 뿐 아~무런 관계가 없다. 이 둘은 '인도'와 '인도네시아'의 관계라고도 말한다. 단지 이름만 비슷할 뿐!
5-5. JavaScript가 하는 일
HTML과 CSS가 못하는 동적인 업무를 JavaScript가 한다는데 좀 더 와 닿는 사례로 살펴보자.
검색창에 'a'를 입력하여 'a'에 해당하는 실시간 검색어들을 불러와서 홈페이지에 노출된다.
이 행위는 HTML, CSS만으로는 할 수 없다. HTML과 CSS는 정보를 잘 보여주는 것이지 어떤 입력에 대한 답을 실시간으로 해줄 수는 없다.
위 사례에서 JavaScript가 'a'입력을 감지하여 정보를 주고받을 수 있게 도와주었다.
사용자가 'a'를 입력했다. 그 후 JavaScript가 'a'를 감지한 후, 'a'와 관련된 검색어 조회하는 API요청을 서버에 보내고(GET 요청) 서버는 'a'와 관련된 검색 목록을 정리해서 응답한다. 응답한 내용이 홈페이지에 노출되어 우리는 a와 관련된 실시간 검색어를 볼 수 있는데, 바로 이 역할을 JavaScript가 하는 것이다.
5-6. 웹과 앱의 차이
앱은 운영체제 위에서 돌아가는 프로그램이므로 반드시 업데이트를 해야 수정된 내용을 확인할 수 있다. 하지만 웹은 서버에 저장되어 있기 때문에 저장된 내용을 서버에 올렸다면 '새로고침'만으로도 모든 유저들이 변경된 내용을 확인할 수 있다. 단, 웹은 네트워크에 예민하여 너무 많은 사용자가 접속하면 속도가 매우 느려지는 단점이 발생한다.
카카오톡을 예로 들어보자. 만약 모든 대화가 웹에 있다면 너무 용량이 커져서 대화방을 리셋해야 할 것이다. 하지만 카카오톡은 대화를 스마트폰에 저장하여 속도 이슈를 해결했다.
5-7. 웹 개발이 어려운 이유
크롬, 익스플로러, 파이퍼폭스, 오페라, 사파리 등 브라우저 프로그램은 다양하다. 그리고 HTML, CSS, JavaScript는 새로운 기능들이 추가되며 발전한다. 이 사이에서 문제가 생긴다. 모든 브라우저가 변화하는 웹 언어를 전부 이해하지 못할 수 있기 때문에 브라우저별로 개발 대응이 필요한 상황이 생긴다.
어떤 브라우저에서는 잘 작동하는데 어떤 브라우저에서는 잘 작동하지 않는다면, 작동하지 않는 해당 브라우저는 변화된 웹 언어상황을 아직 반영하지 않아서다. 모든 브라우저를 다 대응할 수는 없다. 보통 '점유율' 기준으로 많이 쓰이는 브라우저 중심으로 개발 대응을 한다. 이런 고민은 해당 프로젝트를 진행하는 모든 사람들이 의논하고 합의를 통해 결정해야 한다.
5-8. 반응형 웹과 CSS
데스크톱, 태블릿, 스마트폰은 너무나 크기가 다양하다. 따라서 해당 기기 가로넓이에 대응하여 구성요소가 변하는 기술을 반응형 웹이라고 한다. 예전에는 해당 가로 사이즈별로 CSS를 다르게 적용하였지만, 요즘은 하나의 CSS 코드 안에서 가로 사이즈별로 레이아웃을 다르게 구현하여 코드의 수를 효율적으로 줄였다.
5-9. 하이브리드 앱
iOS 개발을 위한 언어로는 스위프트, Object-C가 있고 안드로이드 개발을 위한 언어로는 자바, 코틀린이 있다. 이렇게 프로그래밍 언어로만 개발된 앱을 '네이티브 어플리케이션'이라고 한다. 그리고 앱 안에 일부 '브라우저'를 내장한 앱을 '하이브리드 어플리케이션'이라고 부른다. 앱 안에 일부 웹페이지가 들어있는 형태이다.
이런 앱의 경우 브라우저 위에서 돌아가는 페이지는 서버의 HTML, CSS, JavaScript를 수정하면 되고, 네이티브 언어로 구성된 앱 페이지는 수정 후 심사에 통과하여 앱을 업데이트해야 수정된 화면이 적용된다.
6. 데이터베이스와 이미지 처리
6-1. 데이터에 대해서 생각해보자.
데이터베이스란 뭘까? 일상에서 살펴보자. 쇼핑몰을 운영한다고 하면 '회원명, 아이디, 주문 상품명, 상품 가격'들의 정보들이 데이터이다. 그리고 그 정보들은 모두 텍스트여서 txt 파일로 관리를 한다. 근데 쇼핑몰의 회원이 10만 명이라고 하자. 그럼 10만 개의 텍스트 파일이 생긴다. 이때 '홍길동'이라는 고객이 '홍길순'으로 개명하여 정보를 수정하려고 한다. 그럼 컴퓨터는 첫 번째 텍스트 파일부터 뒤져서 '홍길동'을 찾을 것이다.
만약 '홍길동'이라는 회원이 여러 명이라면? 동명이인을 구분하는 코드를 만들어야 한다. 만약 동명이인을 구분하는 코드에 버그가 생겨 잘못 데이터를 수정했다면? 한 건이라면 큰 문제가 없을 것이다. 하지만 1% 확률로 데이터가 이상해진다고 가정해보자. 10,000명이면 100명의 데이터가 이상해진다. 그렇게 오염된 고객정보는 분명 결제와 쇼핑몰 이용에 문제를 일으킬 것이고 사업에 굉장한 타격이 생길 것이다.
그래서 데이터는 단 1%의 결점도 없어야 한다.
6-2. 관계형 데이터베이스
1%의 결점도 없이 무결하게 관리하기 위해 만든 방법론이 '관계형 데이터베이스'이다. 관계형 데이터베이스란 정보에 고유번호를 부여하여 관리하는 것이다. txt 파일당 고유번호를 부여하면, 동명이인의 정보여서 고유번호가 다르기 때문에 구별이 쉽다.
6-3. 관계형 데이터베이스 관리 시스템
실제 개발자들은 소프트웨어를 통해 이 데이터들을 저장하고 관리한다. 소프트웨어들 덕분에 데이터를 만들고, 수정하고, 삭제하는 복잡한 업무를 편리하게 수행할 수 있다.
관계형 데이터베이스를 기반으로 만들어진 관리 시스템에는 MS SQL, Oracle DB, MySQL, MariaDB 등 다양한 시스템들이 존재한다. 이런 종류가 있다는 것만 알아두자!
6-4. 데이터를 클라가 들고 있다는 게 뭐죠?
컴퓨터에서 데이터는 '보조기억장치'에 저장된다. 클라이언트와 서버는 모두 컴퓨터이기 때문에 '보조기억장치'를 가지고 있다. 따라서 서버뿐만 아니라 클라이언트에도 데이터베이스 관리 시스템을 돌릴 수 있다는 말이다. 개발 이슈에 따라 클라이언트에서 데이터베이스를 활용하는 경우도 있다.
예를 들어보자. 알람 앱이 있다. 알람 시간은 '데이터'이다. 이 시간 데이터는 클라이언트에 있을까? 서버에 있을까? 답은 클라이언트이다. 어떻게 알 수 있을까?
바로 인터넷이 연결되어 있지 않은 상태에서도 동작하기 때문이다. 알람의 '시간 데이터'는 서버가 필요하지 않기 때문에 클라이언트에 데이터를 저장하여 관리하는 것이다.
이렇게 겉으로 보고 모든 데이터가 클라이언트인지, 서버인지 파악하는 것은 어렵다. 하지만 'API문서'를 보면 데이터의 위치를 알 수 있다. 데이터를 어디에서 불러오는지 파악할 수 있다는 것은 꽤 중요하다. 이는 개발팀 상황을 파악할 수 있다는 뜻이며, 정확한 사람에게 정확한 요청을 하기 위해 알아야 하는 중요한 부분이다.
6-5. 이미지의 위치가 정말 중요한 이유
프로젝트에서 이미지는 정말 자주 수정되는 영역 중 하나다. 위에서 설명한 대로 데이터는 클라이언트 or 서버 두 곳 다 저장하여 관리할 수 있는데, 이미지 데이터가 어디에 위치하느냐에 따라 향후 수정 및 관리 시 장/단점이 나뉜다.
* 이미지가 클라이언트에 위치할 때
큰 이미지를 다운로드해야 하는 경우, 클라이언트에 저장되어 있기 때문에 로딩 시간 없이 이미지를 노출시킬 수 있다. 하지만 앱이 업데이트돼야만 수정된 이미지를 노출할 수 있다.
* 이미지가 서버에 위치할 때
큰 이미지가 서버에 저장되어 있는 경우, 서버는 네트워크에 영향을 받기 때문에 앱에 노출하려면 로딩 시간이 걸릴 수 있다. 단, 앱 업데이트 없이도 수정된 이미지를 노출할 수 있다.
이런 식이라면.. 예를 들어 고객이 수정하는 프로필 사진, 쇼핑몰의 가격 정보 등 관계가 맺어진 이미지나 빠른 적용이 필요한 데이터는 서버에 넣어두고 관리해야 문제가 발생하지 않을 것이다.
이미지가 클라이언트에 있는지 서버에 있는지 확인하는 가장 좋은 방법은 API 문서를 보는 것이다. API를 통해 이미지의 주소(URL)이 서버에 있다면, 그 이미지는 서버에 있는 이미지라고 판단할 수 있다.
7. 프레임워크와 라이브러리
7-1. 프레임워크가 뭘까?
도넛 가게를 차린다고 생각해보자. 도넛 재료부터 브랜딩, 메뉴판 등등 해야할 것이 너무 많다. 하지만 빠르게 도넛 가게를 차릴 방법이 있다. 바로 던킨도너츠 프랜차이즈로 들어가는 것이다. 그러면 던킨도너츠에서 제공하는 도넛 재료와 브랜딩, 메뉴판을 사용하여 빠르게 운영할 수 있다.
쉽게 말해 프레임워크는 '던킨도너츠'이다. iOS 앱을 만들 때 개발자는 버튼부터 한 땀 한 땀 코딩하지 않는다. 이미 애플이 만들어놓은 버튼 코드를 가져다 쓴다.
* Apple Framework UIkit 사이트
https://developer.apple.com/documentation/UIkit
이처럼 제공해주는 프레임워크를 사용하면 좀 더 쉽고 빠르게 앱을 만들 수 있다.
7-2. 라이브러리는 뭘까?
라이브러리도 다른 사람들이 만들어놓은 코드를 이용한다는 측면에서는 프레임워크와 같다. 하지만 라이브러리가 프레임워크보다 더 작은 개념이다. 각종 라이브러리와 코드들이 모여 프레임워크가 된다.
한 프로젝트에서 프레임워크는 하나만 쓸 수 있다. 한 자동차를 운전하면서 동시에 다른 자동차를 운전할 수 없는 것과 같은 개념이다. 반면, 라이브러리는 망치나 가위 같은 도구들이기 때문에 한 프로젝트에서 함께 사용이 가능하다.
# 참고) 프레임워크, 라이브러리의 종류
애플 - Cocoa / 구글 - Android Frame Work / 웹 - Angular.js, Reacr.js, Vue.js
자바 - 스프링(Spring) / 파이썬 - 장고(Django)...
8. 협업, 소스관리, 디자인
8-1. 커밋?
프로젝트에서 기획은 정말 자주 바뀐다. 개발을 다 해놨는데 다시 이전 버전으로 복구를 해야 할 때, 이미 코드를 덮어썼다면 내용을 돌이키기도 힘들고 빡친다. 이런 문제를 깃(Git)이 해결해준다. 개발 단계별로 '깃발'을 꽂아 체크하는데 그 행위를 커밋(Commit)이라고 한다. 이는 무슨 개발을 했는지 적어주는 메모이다. 깃(Git)을 통해 커밋을 하여 버전 관리를 할 수 있다.
8-2. 브랜치와 머지? 는 뭐지?
깃은 커밋 외에도 다양한 기능을 가지고 있다. 브랜치(Brandch)는 '분기', '가지'라는 뜻으로 새로운 가지를 뻗는 것을 의미한다. 한창 개발 중인데 새로운 방향의 개발을 추가해야 할 때 기존 개발을 덮어쓰지 않고, 새롭게 가치를 쳐서 작업할 때 브랜치를 한다. 머지(Merge)는 말 그대로 코드를 합치는 기능이다.
8-3. 깃허브로 동시에 개발하기
개발자들이 각기 다른 영역을 동시에 개발한다. 사람의 방식이 모두 다르기 때문에, 이렇게 하나의 프로젝트를 동시에 작업하면 서로 겹치는 부분이나 맥락이 안 맞는 영역이 생길 수 있다. 이에 개발자들은 깃을 기반으로 한 깃허브(GitHub), 비트 버킷(Bitbucket)이라는 '원격 저장소'를 만들었다.
자신의 컴퓨터에서 작업을 한 뒤 커밋을 하면, 그 결과를 원격 저장소에 보낼 수 있고 원격 저장소에서 이미 작업된 결과물을 가져올 수도 있다.
구글 드라이브에서 자료를 실시간으로 공유하고 다운로드할 수 있는 것처럼 개발자들끼리 개발 상황을 서로 공유하며 수월하게 협업할 수 있다.
8-4. 디자이너도 프레임워크를 숙지해야 한다.
개발자는 프레임워크와 라이브러리에서 제공하는 기능을 활용한다. 만약 디자이너가 프레임워크와 라이브러리에서 제공하는 수준을 벗어난 디자인 디테일을 요구한다면 조금 힘들어진다. 그렇기에 디자이너는 가이드에 관심을 가져야 한다. 각 프레임워크에서 제공하는 가이드 문서를 어느 정도 숙지하고 있어야 한다.
* 애플 - HIG(Human Interface Guideline)
https://developer.apple.com/design/human-interface-guidelines
* 구글 - Material Design
https://material.io/design
마치며..
정리하다 보니 저~~ 엉말 길어졌다.. 읽은 시간보다 정리하는데 2배 이상 시간을 쏟은 것 같다. 하지만 이런 과정은 책을 읽고 난 후 기억을 잃어버릴 미래의 나를 위해 꼭 필요하다. 또한 개발의 기본 개념을 파악하고 싶어 하는 누군가를 위해 좀 더 쉽게 정리하려고 노력했다. (물론 책에서 더 쉽고 재미있게 알려주지만!)
주니어 때부터 했던 'IT 디자이너는 개발을 알아야 하나?'라는 고민에 대한 답을 이제는 할 수 있다. 개발자처럼 개발을 알아야 할 필요가 전혀 없다. 단, 협업을 원활하게 할 수 있는 정도의 개발은 알아야 더 강력한 UIUX 디자이너가 될 수 있다.
요즘은 코딩이 필수 교육인 시대라고 들었다. 나중 세대에 동떨어지지 않기 위해서라도 기본적인 개발 지식을 알아두는 건 나쁘지 않을 것 같다. 그래서 앞으로도 나는 계속 개발 지식을 틈틈이 공부하게 될 것 같다.
이 책 덕분에 컴퓨터와 개발의 전반적인 개념에 대해서 공부할 수 있었다. 작가님 최고..
