[비전공자를 위해 이해할 수 있는 IT 지식] by 최원영

개발자는 앉아서 뭐하고 있어? 뭔가 연주하고 있긴 한데… 프로그래머는 어떻게 저 모든 단어와 기호를 술술 쓸 수 있죠? 그 이유는 어떤 프로그램이 작업을 도와주기 때문입니다. 이 프로그램에는 앞의 몇 글자만 치면 자주 사용되는 문장을 추천하거나 코드가 아닌 그림으로 작업할 수 있도록 하는 등 개발자의 작업을 돕는 기능이 포함되어 있습니다. 이러한 프로그램을 IDE(통합 개발 환경, Integrated Development Environment)라고 부릅니다. 코딩에 필요한 다양한 기능이 포함되어 있으며 그 기능을 통해 쉽게 코드를 만들 수 있습니다.

Android Studio : Android 어플리케이션 개발 용도 – Xcode : 애플 운영체제상 어플리케이션 개발 용도 – Eclipse : C/C+ 개발, 자바 개발, 웹 개발 용도 – PyCharm : 파이썬 개발 용도
안드로이드 위로 돌아가는 애플리케이션을 만들려면 안드로이드 스튜디오라는 IDE를 사용합니다. 아이폰, 아이패드, 맥북 등 애플 기기의 앱을 만들기 위해서는 엑스코드라는 IDE를 사용합니다. 이처럼 IDE는 거의 어떤 분야에 특화되어 있습니다.
컴퓨터 컴포넌트에서 CPU가 있습니다. CPU는 컴퓨터가 ‘머리’ 역할을 합니다. 다음은 ‘메모리(RAM)’입니다. 마지막으로 HDD(하드디스크), SDD라고 불리는 보조 기억 장치가 있습니다. 컴퓨터의 「창고」로서 작동합니다. 전원이 꺼져도 이 안에 데이터는 남아 있습니다. 이 부품들을 마더보드라는 판에 끼워 넣습니다. 여기에 전원을 켜면 컴퓨터가 됩니다.
CPU는 컴퓨터의 머리이고 보조 기억 장치인 HDD와 SSD는 컴퓨터의 창고입니다. CPU는 따로 데이터를 저장하지 않기 때문에 데이터를 연산하거나 처리하려면 저장된 데이터를 CPU로 보내야 합니다. 이때 CPU는 창고 역할을 하는 기억장치인 HDD, SSD로 신호를 보냅니다.
그런데 창고가 너무 커서 필요한 데이터를 찾을 때까지 시간이 걸립니다. 이처럼 보조기억장치는 CPU보다 속도가 매우 느리기 때문에 CPU와 보조기억장치가 함께 일하면 CPU가 보조기억장치를 계속 기다려야 하기 때문에 속도가 하향 평준화됩니다. 사람들은 CPU와 보조 기억 장치를 함께 일하게 해서는 안 된다고 생각했습니다.
그래서 ‘메모리’라는 CPU의 개인 작업 공간을 만들었습니다. 이제 CPU는 보조 기억 장치에 필요한 데이터를 그때그때 요청하지 않아도 됩니다. 작업이 필요한 큰 데이터 뭉치를 보조기억장치에서 메모리로 옮겨놓고 메모리 안에서만 작업하면 되기 때문입니다. 가끔 메모리에 큰 데이터 뭉치만 건네주기 때문에 시간이 크게 줄었습니다.
– 포토샵을 예로 들어봅시다.먼저 포토샵이 어디에 저장되어 있는지 생각해봅시다. Windows(OS) 기준으로 ‘C드라이브-Programfiles-Adobe-Photoshop’에 포토샵 실행에 필요한 파일이 있습니다. 보통 데스크톱에서 포토샵 아이콘을 ‘더블 클릭’하거나 ‘시작’을 눌러 포토샵 아이콘을 클릭합니다. 이 프로세스는 “Programfiles-Adobe-Photoshop” 안에 있는 포토샵 실팡 파일의 [바로가기]를 클릭한 것입니다. 결국 보조 기억 장치에 저장된 프로그램을 실행하는 것입니다. 실행한다는 것은 cpu가 일한다는 뜻입니다. 하지만 그렇다고 포토샵이 바로 실행되는 것은 아닙니다. 로드 화면이 나타나고 실행까지 시간이 좀 걸립니다. 이 과정에서 무슨 일이 일어나고 있을까요? 보조 기억 장치에서 ‘실행에 필요한 데이터’가 메모리에 올라와 있는 것입니다. 이 프로세스가 완료되면 포토샵이 실행됩니다. 포토샵으로 사각형을 만들어도, 색을 바꿔도 CPU가 메모리 상에서 빠르게 작업을 수행할 수 있게 됩니다. 프로그램은 이렇게 돌아가요.
컴퓨터의 구성 요소, 사실 우리는 오늘 아침에도 CPU, 메모리, 보조 기억 장치와 함께 프로그램을 사용했다. 그런데 왜 이 이야기가 낯설지? 사실 이 모든 과정을 몰라도 프로그램을 사용하는 데 아무런 문제가 없다. 왜냐하면 ‘어떤 소프트웨어’가 이 모든 과정을 대신해주기 때문이다. 그 어떤 소프트웨어가 운영체제(OS)다. 대표적으로 윈도 맥OS iOS 안드로이드가 있다. 윈도우와 맥OS는 PC에서 많이 쓰이고 iOS와 안드로이드는 모바일에 특화돼 있다.
이 모든 운영체제(OS)는 우리 대신 하드웨어를 관리해 준다. 하드웨어 용량이 얼마나 되는지 확인할 수 있는 것도 운영체계가 보조기억장치(HDDSSD)를 관리하고 있기 때문에 가능한 일이다. 프로그램을 인스톨/실행하는 것도 마찬가지다. 운영체계가 하드웨어를 컨트롤하고 CPU와 메모리 등을 관리해주기 때문에 우리는 클릭 몇 번만으로 편하게 파워포인트를 실행하고 카카오톡을 실행할 수 있다.

운영체제에 따라 프로그래밍 언어도 달라진다. 따라서 운영체제 회사는 개발자의 생활에도 큰 영향을 미치고 있다. 애플의 운영체제 위로 돌아가는 프로그램을 만들려면 Objective-C 혹은 스위프트라는 언어를 사용해야 한다. 구글 운영체제 위로 돌아가는 프로그램을 만들려면 자바 또는 코틀린이라는 언어를 사용해야 한다.

우리가 자바 최신 버전을 설치해야 하는 이유 과거에는 운영체제 종류가 훨씬 다양했기 때문에 개발자들이 배워야 할 프로그래밍 언어도 매우 많았다. 문제는 각기 다른 언어를 모두 배운다고 해도 프로그램 버그를 수정하거나 새로운 기능을 추가할 때는 할 일이 산더미처럼 늘어난다는 것이었다. 10개의 운영체제가 있다면 같은 작업을 10번씩 해야 했다. 이 문제는 자바라는 프로그래밍 언어가 해결한다.

자바를 만든 팀은 각 운영체제 위에 JAVA(Java Virtual Machine)라는 소프트웨어를 만들었다. JVM 위에서 자바 언어로 만든 프로그램이 가동될 수 있도록 한 것이다. 사용자가 자신의 컴퓨터에 JVM을 설치할 뿐 운영체제별로 여러 프로그램을 작성할 필요 없이 JVM만 작성하면 된다. 즉 자바로만 프로그램을 만들어도 모든 운영체제에서 사용할 수 있게 된 것이다.

자바 이외에도 다양한 언어가 이런 방식을 취하고 있다. 대표적인 것이 파이썬이다. 파이썬으로 프로그램을 작성하면 윈도우나 맥OS 등의 운영체제 위에서 프로그램을 설치 및 실행할 수 있다. 물론 자바나 파이썬 같은 프로그램을 사용하는 방식의 단점도 있다. 속도가 느리다는 얘기다. 운영체제 위에 프로그램을 올리고 그 위에 다시 프로그램을 올리는 것이기 때문이다.

또 하나 알아야 할 사실은 모바일은 PC와 달리 IOS와 안드로이드가 시장을 양분하고 있다. 때문에 과거보다 JVM과 같은 컨셉트에 대한 요구가 적다. 더욱이 만약 모바일 위에 특정 프로그램을 설치하고 그 위로 프로그램을 돌리는 방식을 사용하면 여러 문제가 생긴다. 우선 모바일은 기본적으로 크기가 PC보다 작기 때문에 그 안에 들어가는 부품도 PC보다는 더 작을 수밖에 없다. 그 때문에 용량이나 성능에 제한이 있다. 프로그램 위로 프로그램을 돌리면 매우 느려진다. 게다가 이런 개념을 허용하면 애플과 구글이 가진 시장에 대한 영향력이 줄어들기 때문에 애플과 구글은 이런 상황을 원하지 않는다. 따라서 다양한 이유로 모바일에서는 JVM과 같은 개념이 PC보다 상대적으로 발전하지 않게 된다.

야! 내가 방을 만들었어. 빨리 들어와!” “어? 안 보이는데? 안 들어가!” “그래? 그럼 네가 만들어 봐. 내가 들어갈게! ‘그래 잠깐만!’ 만들었어!방이 없는데? 하아.(절망)

초등학교 컴퓨터 수업 시간에는 이런 대화가 오갔다. 컴퓨터실에는 친구들과 함께 게임을 ‘할 수 있는 자리’와 ‘할 수 없는 자리’가 나뉘어 있었기 때문이다. 이때 게임이 될 장소, 할 수 없는 장소는 컴퓨터 연결이 어떻게 되느냐에 따라 달라진다. 회선으로 직접 연결된 컴퓨터는 서로 파일을 주고받거나 게임을 할 수 있었다. 그러나 연결이 되지 않는 두 개의 다른 컴퓨터는 함께 게임을 할 수 없었습니다. 여기서 중요한 사실을 배울 수 있다. 컴퓨터를 연결하면 할 수 있는게 많구나!

컴퓨터가 연결되면 함께 게임을 할 수 있고 파일을 주고받을 수 있습니다. 덕분에 우리는 회사에서 엑셀 파일, PDF 파일 등 여러 파일을 주고받으며 일할 수 있게 됐다. 컴퓨터가 연결된 작은 지역을 LAN(Local Area Network)이라고 한다. 학교 컴퓨터실 하나, 아파트 하나, 커피숍 하나하나가 모두 랜이다. 랜을 연결하는 선을 랜선이라고 부른다. 또 사람들은 도시의 여러 LAN을 하나로 묶어 MAN(Metropolitan Area Network)을 만들었다. 그리고 도시와 도시, 나라와 나라를 모두 묶어 WAN(Wide Area Network)을 만들었다.

이 선을 잇기 위해 당시 수많은 공사가 진행되었다. 정전도 다발했다. 각사는 ADSL VDSL 광케이블 등 초고속 인터넷망을 선전했다. 당시 컴퓨터실을 떠나 집에서 다른 친구들과 함께 게임을 할 수 있다는 것은 큰 충격이었다. 네트워크가 만들어낸 일이다. 게다가 사람들은 이 신호를 무선으로 만들기 시작했다. 어느 순간 3G, 4G, 5G라는 말이 오가기 시작했다.

한강에서 카카오톡을 내려받고 실행하면 일어나는 일을 먼저 앱스토어에 들어가 카카오톡을 검색하고 다운로드 버튼을 누르면 가까운 기지국에 ‘카카오톡 설치 파일을 보내줘’라는 신호가 온다. 신호는 WAN을 따라 이동한다. 이때 항상 최종 목적지가 정해져 있다. 우편물을 생각하면 돼. 집 주소처럼 하나의 정해진 컴퓨터 주소로 신호가 전달된다. 여기서는 앱스토어여서 애플이 가지고 있는 컴퓨터에 신호가 간다. 애플은 카카오톡 파일을 가지고 있다. 카카오가 앱스토어에 설치 파일을 올렸기 때문이다. 이제 애플 컴퓨터는 ‘카카오톡 설치 파일’을 여러분의 컴퓨터로 보내준다. 다운로드 중이라는 화면이 뜨고 잠시 후 카카오톡이 설치된다. 이후 앱을 클릭해 실행하면 운영체제 장에서 설명한 과정이 그대로 일어난다. 컴퓨터 보조기억장치(HDD, SSD)에 카카오톡 실행 파일이 저장돼 여러분이 카카오톡 아이콘을 누르는 순간 실행에 필요한 부분이 메모리 위로 올라온다. 그리고 CPU가 이들 데이터를 처리하고 카카오톡이 작동한다.

지금 설치된 카카오톡을 실행해 친구가 보낸 이미지, 동영상을 다운로드한다. 이미지, 동영상을 다운로드할 때 일어나는 일은 아까 앱스토어에서 카카오톡을 다운로드한 과정과 같다. ‘동영상을 나에게 보내줘’라는 신호를 가장 가까운 기지국으로 보내면 카카오톡 프로그램이 지정해 놓은 주소를 따라 카카오톡이 켜놓은 컴퓨터로 신호가 전송된다. 신호를 받은 컴퓨터에서는 이미지 파일, 동영상 파일 등을 보내준다. 그렇게 보낸 파일을 여러분의 스마트폰으로 볼 수 있는 것이다.

IP 주소라는 말을 들어본 적이 있을 것이다. IP 주소는 문자 그대로 「주소」이다. 편지를 보낼 때 ‘서울시 마포구 상암동 XX아파트 XX호’라는 주소가 필요하듯 이미지 파일, 동영상 파일, 메시지 등을 보내기 위해서는 해당 컴퓨터가 위치한 주소가 필요하다. 그 주소를 IP 주소라고 한다. 인터넷에 접속하는 순간 여러분의 컴퓨터는 지금 위치에 맞는 IP 주소를 갖게 된다. IP 주소는 12자리 숫자가 마침표(.)로 구분된 모습을 가진다. IP 주소는 위치에 따라 컴퓨터에 따라 고유하다. 즉 집 IP 주소와 카페 IP 주소가 다르다는 것이다. 이동하면 IP 주소는 계속 바뀐다.

당신은 계속 뭔가를 달라고 하고(클라이언트), 누군가는 계속 뭔가를 주는(서버) 카카오톡이 켜놓은 컴퓨터에 여러분처럼 ‘파일 주세요’라는 신호를 수많은 사람들이 동시에 보낸다. 그러면 카카오톡 컴퓨터는 힘들어서 죽는다. 컴퓨터는 맨보우 같은 아이들이기 때문에 스트레스를 받으면 쉽게 사망한다. 파일을 보내달라는 수많은 신호가 한 컴퓨터에 집중되면 그 컴퓨터는 파일을 보내기 위해 보철장치, 메모리, CPU를 사용한다. 파일을 전송하기 위해서는 보조 기억 장치의 파일을 메모리에 업로드하고 CPU가 해당 파일을 전송해야 한다. 그러나 신호가 집중되면 어느 순간 메모리 공간을 소진하거나 CPU가 처리할 수 있는 한계를 넘어서게 된다. 그러면 컴퓨터는 죽는다. 껐다가 다시 켜야 살아.

이런 이유로 카카오톡은 여러 컴퓨터를 연합군으로 만들었다. 카카오톡으로 이 컴퓨터 연합군을 24시간 365일 내내 켜놨기 때문에 우리는 아침에도 새벽에도 저녁에도 카카오톡을 이용할 수 있다. 만약 이 컴퓨터들이 꺼지면 우리는 카카오톡을 이용할 수 없게 된다.

파일을 요구하도록 재촉하는 컴퓨터를 「클라이언트」, 파일을 주는 컴퓨터를 「서버」라고 한다. 개발자의 세계에서 클라이언트는 컴퓨터입니다. 서비스를 사용하는 사용자가 소유한 컴퓨터를 의미한다. 당신의 스마트폰도 컴퓨터도 클라이언트입니다. 반면 고객 입장에서는 클라이언트 컴퓨터를 직접 볼 수 있고 만질 수 있다. 고객의 눈앞에 있는 이 클라이언트 컴퓨터를 다른 말로 프론트 엔드라고 표현한다. 반면 서버는 고객이 볼 수 없는 곳에 있다. 고객에게 보이지 않는 곳, 그래서 서버를 다른 말로 ‘백엔드’라고 부른다.

도대체 우분투가 뭐야?이 질문에 답하려면 리눅스를 알아야 한다. 리눅스는 운영체제(OS)다.

‘아 리눅스는 윈도우, 맥OS 같은 애들이구나’ 아! 그러면 CPU, 메모리, 보조기억장치를 우리가 신경 쓰지 않아도 리눅스가 다 관리해주네. 아아! “그럼 윈도우 위에서 파워포인트를 돌리듯이 리눅스 위에서 이것저것 프로그램을 돌리겠네.

리눅스라는 운영체제 위에서 서버 프로그램을 돌린다. ‘서버 프로그램’이 뭐지? ‘서버’는 ‘클라이언트’의 요구에 응답하는 컴퓨터이다. 카카오톡 컴퓨터 또는 애플 컴퓨터처럼 요청에 따라 파일을 보내준다. 이때 요청의 종류는 다양할 수 있다. 로그인, 회원가입, 상품목록요청, 결제요청 등.

로그인 요청을 생각해보자. 클라이언트에서 서버에 다음과 같이 요청한다.
‘로그인 시켜줘’
그럼 어떤 정보가 필요할까? 아이디와 비밀번호가 필요하다. 통상 이런 정보는 로그인 요청을 보낼 때 함께 온다. 자, 정보를 받았으니 컴퓨터는 생각해야 한다. 어떤 생각을 할까?
‘이 아이디가 존재하나?’ ‘존재한다면 비밀번호는 이게 맞나?’
컴퓨터가 생각한다는 것은 코딩된 프로그램이 작동한다는 것을 의미한다. 프로그래밍 언어로 컴퓨터에 일을 시킨 것이다. 하드웨어를 직접 제어하지 않으려면 운영체제 위에서 프로그램을 돌려야 한다. 즉 리눅스 위에 이런 생각을 하는 프로그램을 24시간 365일 돌려놓는 것이다. 그러면 해당 프로그램이 코딩된 채로 생각하고 응답해준다.-
그럼 왜 서버 프로그램을 리눅스 위에서 돌리는 걸까요? Windows OS, Mac OS, iOS, Android OS에 대해 굳이 Linux를 사용하는 이유는 무엇일까. 그 이유는 리눅스가 기본적으로 ‘공짜’이기 때문이다. Linux가 무료로 배포되면 사람들은

도대체 우분투가 뭐야?이 질문에 답하려면 리눅스를 알아야 한다. 리눅스는 운영체제(OS)다.

로그인 요청을 생각해보자. 클라이언트에서 서버에 다음과 같이 요청한다.
‘로그인 시켜줘’
그럼 어떤 정보가 필요할까? 아이디와 비밀번호가 필요하다. 통상 이런 정보는 로그인 요청을 보낼 때 함께 온다. 자, 정보를 받았으니 컴퓨터는 생각해야 한다. 어떤 생각을 할까?
‘이 아이디가 존재하나?’ ‘존재한다면 비밀번호는 이게 맞나?’
컴퓨터가 생각한다는 것은 코딩된 프로그램이 작동한다는 것을 의미한다. 프로그래밍 언어로 컴퓨터에 일을 시킨 것이다. 하드웨어를 직접 제어하지 않으려면 운영체제 위에서 프로그램을 돌려야 한다. 즉 리눅스 위에 이런 생각을 하는 프로그램을 24시간 365일 돌려놓는 것이다. 그러면 해당 프로그램이 코딩된 채로 생각하고 응답해준다.-
그럼 왜 서버 프로그램을 리눅스 위에서 돌리는 걸까요? Windows OS, Mac OS, iOS, Android OS에 대해 굳이 Linux를 사용하는 이유는 무엇일까. 그 이유는 리눅스가 기본적으로 ‘공짜’이기 때문이다. Linux가 무료로 배포되면 사람들은

‘정확한 장소’에 해당하는 주소는 ‘서버 주소/A’ 형태로 정의되어 있다. 여기서 “서버 주소”는 서버 컴퓨터가 위치한 곳의 주소이다. 네트워크에서 언급한 IP 주소이다. 그 주소 뒤에 어떤 문자를 쓰느냐에 따라 다른 기능을 수행하도록 정의하는 것이다. 예를 들어, “서버 주소/A”라고 신호를 전송하면 서버가 “로그인 기능”을 실행하여 응답한다. 혹은 ‘서버 주소/B’라고 신호를 보내면 서버가 ‘회원 가입 기능’을 실행해 응답한다. 잘 됐는지, 만약 문제가 있다면 무슨 문제가 있는지 등을 알려준다. 이들 기능은 서버 개발자가 작성하고 그 결과가 서버 프로그램이다. 서버 주소의 정의도 서버 개발자의 주도 하에 이루어진다. 그리고 클라이언트 프로그램은 정해진 주소로 요청을 전송한다. 즉, API는 서버 개발자가 개발하고 클라이언트 개발자는 해당 API를 사용한다.

API를 만들 때는 데이터를 주고받는 기능도 함께 넣는다. 로그인 요청을 할 때 아이디와 비밀번호 데이터가 필요하다. 비디오 파일이나 이미지 파일에 대한 응답을 받을 때도 데이터가 함께 와야 한다. 이처럼 API를 통해 요청과 응답을 나눌 때는 데이터도 함께 담는다.

API를 클라이언트와 서버의 관점에서 좀 더 자세히 살펴보자.

우선 클라이언트 시점부터 살펴보자.클라이언트 소프트웨어는 서버에 요청을 송신한다. 타임라인에 사진 올리기 요청이라고 생각하면 이 요청을 크게 네 가지 요소로 나눌 수 있다. CRUD라 불리는 이 4가지 요청은 데이터를 다룰 때 기준이 되는 요청으로 프로그래머에게 매우 중요하다.

데이터를 다룰 때 큰 틀에서 보면 대부분의 요청이 이 네 가지 요청(CRUD)에 속한다.C:CREATE→타임라인에 사진 ‘올리기’ 요청 R:READ→타임라인에 사진 ‘부르기’ 요청 U:UPDATE→’바꾸기’ 요청 D:DELETE→’지우기’ 요청

개발자들은 데이터를 볼 때 항상 CRUD 관점에서 생각한다. 하지만 초보자 기획자는 쉽지 않다. 그래서 실수를 한다. 예를 들어 데이터를 볼 수는 있지만 만들 기획이 없을 수도 있다. 혹은 보거나 만드는 기획은 있지만 수정하거나 삭제하는 기획이 없을 수도 있다. 이러한 실수를 방지하기 위해서는 데이터를 CRUD 관점에서 봐야 한다. 만약 CRUD 중 특정 기능이 없는 기획이라면 그 기획 의도가 명확해야 하고 이유도 설명할 수 있어야 한다.

RESTful API 타임라인의 CRUD 요청은 각각의 주소를 가진다.예를 들어 CREATE 요청은 ‘서버 컴퓨터의 주소/timeline create’로 할 수 있다. READ, UPDATE, DELTE도 각각의 주소를 가진다. 그러면 서버 기능을 원하는 클라이언트는 해당 주소로 요청을 보내면 된다. 이렇게 CRUD마다 주소가 생긴다. 그런데 이렇게 주소를 구성하면 문제가 있다. 주소가 너무 많아져 관리가 어려워진다는 것이다. 프로그래밍은 사람이 하는 일이기 때문에 몇몇 주소는 기능이 겹칠 수 있고 CRUD가 체계적으로 구분되지 않을 수도 있다. 그러면 그 몇 가지 API가 문제를 일으켜 버그가 생긴다. 따라서 사람들은 보다 체계적으로 API를 관리하고 싶어하며, 그 영향으로 좀 더 체계적인 API라는 사회운동이 만들어진다. 그러한 API를 REST(Representational State Transfer)한 API, 즉 RESTful API라고 부른다.

RESTful API가 어떤 체계인지가 중요하다. RESTful API에서는 CRUD를 하나의 주소로 관리하기 때문에 이전보다 주소 수가 줄어든다. 또한 요청을 보낼 때 다음과 같이 어떤 요청을 보냈는지 파악할 수 있는 ‘스티커(=메소드)’를 붙여 함께 전송한다.

이 스티커 5개는 자주 쓰이니까 꼭 알아두자. – CREATE(생성해서): POST-READ(불러와): GET-UPDATE(바꿔): PUT(전체)/ PATCH(일부)-DELETE(지우고): DELETE

*RESTful API는 모든 회사에서 통용되는 절대 규칙이 아닌 일종의 사회운동으로 상황마다 다양한 방식으로 변형해 사용한다.

현업에서는 스티커 대신 메소드라는 용어를 사용한다. 메서드는 ‘방법’이라는 뜻의 영어 단어이지만 개발자 세상에서는 수학의 ‘함수’와 같은 의미로 사용한다. x라는 입력값에 따라 y라는 결과가 나오는 것이 함수인 것처럼 요청을 보내면 결과가 나오는 API의 모습이 함수와 같아 ‘메소드’라는 용어를 사용한다. 함수에서는 x를 ‘변수’, ‘파라미터(parameter)’라고 사용한다. API에서도 마찬가지다. 예를 들어 로그인 요청에서 필요한 아이디와 비밀번호를 ‘로그인 요청에 필요한 요청 변수’ 혹은 ‘파라미터’로 표현한다.
이제 서버 관점에서 API를 생각해보자.클라로부터 요청을 송신하면 서버는 다음과 같이 생각한다.
“요청 보낸 사용자가 가입한 사용자인가?” “비밀번호가 틀렸어!” 확인하라고 말해줘 “야지” “친구 중에 A를 찾아달라고? A는 없는데? 없다고 해주자 ‘친구 리스트 보내달라고? 친구가 없는데?비밀번호를 잊어버렸어? ‘재설정이 필요한지 물어보자’
컴퓨터가 생각한다는 것은 개발자가 코딩했다는 것을 의미한다. 여기서 이러한 코딩은 서버 개발자가 수행한다. 그리고 컴퓨터는 코딩된 대로 생각하고 응답을 보낸다. 회답에는 두 가지 경우가 있다. 하나는 ‘잘됐다’고, 다른 하나는 ‘잘 안 됐다’다. 개발자들은 ‘잘됐다’나 ‘잘 안 됐다’에도 체계가 필요하다고 생각했다. 그래서 다행이다는 200번대 코드(201, 202, … 등)로 표현하기로 했다.
잘 안 됐다는 두 가지 경우가 있다. 크라의 요청 때문에 잘 안 된 경우가 있고 서버 내부에서 잘 안 된 경우가 있다. 이 두 경우를 따로 표현하면 문제가 발생했을 때 원인을 찾기 쉽다. 그래서 쿠라의 요청으로 문제가 있을 경우 400번대 코드(401,404…)로 표현하기로 했다. 반면 서버에 문제가 있을 경우 500번대 코드(500, 501). 404라고 하는 오류 코드는 일반적으로 정의되지 않은 요청을 보낼 때 표시됩니다. 즉 서버는 문제없이 정상적으로 움직이고 있는데 요청이 이상하다는 얘기다.
정리하자면 API는 소프트웨어가 다른 소프트웨어의 기능을 사용하기 위해 중간에 필요한 체계다. 쉽게 말해 기능을 사용하기 위해 주소로 요청을 보내면 응답해주는 소프트웨어 간 체계라고 이해하면 된다.

SDK(Software Development Kit) – API를 제공하는 다른 소프트웨어 API 개념을 좀 더 확장해보자. 우리는 지금까지 클라와 서버, 2개의 시스템을 보았다. 그러나 다른 경우도 있을 수 있다. 하나의 컴퓨터에 복수의 소프트웨어가 함께 있는 경우이다.

예를 들어보자. 내 컴퓨터에서 ‘XX 소프트웨어’를 개발 중이라고 치자. 그런데 문제가 생겼다. ‘XX 소프트웨어’의 한 파트에 ‘한영 번역 기능’이 필요한 상황이 생긴 것이다. 이때 한 소프트웨어가 한영 번역 기능을 갖고 있는데 우리는 그 소프트웨어의 한영 번역 기능을 사용하고 싶다. 다른 시스템의 기능을 사용하기 위해서는 API가 필요하다.

API를 클라이언트와 서버의 관점에서 좀 더 자세히 살펴보자.

이 스티커 5개는 자주 쓰이니까 꼭 알아두자. – CREATE(생성해서): POST-READ(불러와): GET-UPDATE(바꿔): PUT(전체)/ PATCH(일부)-DELETE(지우고): DELETE

*RESTful API는 모든 회사에서 통용되는 절대 규칙이 아닌 일종의 사회운동으로 상황마다 다양한 방식으로 변형해 사용한다.

현업에서는 스티커 대신 메소드라는 용어를 사용한다. 메서드는 ‘방법’이라는 뜻의 영어 단어이지만 개발자 세상에서는 수학의 ‘함수’와 같은 의미로 사용한다. x라는 입력값에 따라 y라는 결과가 나오는 것이 함수인 것처럼 요청을 보내면 결과가 나오는 API의 모습이 함수와 같아 ‘메소드’라는 용어를 사용한다. 함수에서는 x를 ‘변수’, ‘파라미터(parameter)’라고 사용한다. API에서도 마찬가지다. 예를 들어 로그인 요청에서 필요한 아이디와 비밀번호를 ‘로그인 요청에 필요한 요청 변수’ 혹은 ‘파라미터’로 표현한다.
이제 서버 관점에서 API를 생각해보자.클라로부터 요청을 송신하면 서버는 다음과 같이 생각한다.
“요청 보낸 사용자가 가입한 사용자인가?” “비밀번호가 틀렸어!” 확인하라고 말해줘 “야지” “친구 중에 A를 찾아달라고? A는 없는데? 없다고 해주자 ‘친구 리스트 보내달라고? 친구가 없는데?비밀번호를 잊어버렸어? ‘재설정이 필요한지 물어보자’
컴퓨터가 생각한다는 것은 개발자가 코딩했다는 것을 의미한다. 여기서 이러한 코딩은 서버 개발자가 수행한다. 그리고 컴퓨터는 코딩된 대로 생각하고 응답을 보낸다. 회답에는 두 가지 경우가 있다. 하나는 ‘잘됐다’고, 다른 하나는 ‘잘 안 됐다’다. 개발자들은 ‘잘됐다’나 ‘잘 안 됐다’에도 체계가 필요하다고 생각했다. 그래서 다행이다는 200번대 코드(201, 202, … 등)로 표현하기로 했다.
잘 안 됐다는 두 가지 경우가 있다. 크라의 요청 때문에 잘 안 된 경우가 있고 서버 내부에서 잘 안 된 경우가 있다. 이 두 경우를 따로 표현하면 문제가 발생했을 때 원인을 찾기 쉽다. 그래서 쿠라의 요청으로 문제가 있을 경우 400번대 코드(401,404…)로 표현하기로 했다. 반면 서버에 문제가 있을 경우 500번대 코드(500, 501). 404라고 하는 오류 코드는 일반적으로 정의되지 않은 요청을 보낼 때 표시됩니다. 즉 서버는 문제없이 정상적으로 움직이고 있는데 요청이 이상하다는 얘기다.
정리하자면 API는 소프트웨어가 다른 소프트웨어의 기능을 사용하기 위해 중간에 필요한 체계다. 쉽게 말해 기능을 사용하기 위해 주소로 요청을 보내면 응답해주는 소프트웨어 간 체계라고 이해하면 된다.

XX 소프트웨어는 API를 사용하여 정해진 방법으로 다른 소프트웨어에 요청을 보낸다. ‘다른 소프트웨어’는 요청대로 작업을 수행하고 응답을 준다. 물론 API는 응답을 보내는 쪽에서 만들고 요청을 보내는 쪽은 활용할 뿐이다. 즉 해당 API를 미리 만들어 놓아야 사용할 수 있다.

이때 새로운 용어가 하나 더 등장한다. SDK다. API를 제공하는 「다른 소프트웨어」를 SDK라고 부른다. SDK는 소프트웨어를 개발하기 위한 툴이다. 즉, 「XX 소프트웨어」를 개발할 때에 도움이 되는 「다른 소프트웨어」이다. 보통 타사와 협업할 때 SDK라는 말을 듣게 된다.

구체적인 예를 들어보자. 구글 지도는 구글에서 만든 소프트웨어다. 이때 다른 회사도 구글에서 제공하는 지도 SDK를 설치하면 자신의 소프트웨어에 구글 지도 기능을 넣을 수 있다. 이 SDK가 제공하는 API를 통해 구글 지도에 요청을 보낼 수 있다.

JSON-요청과 응답을 주고받을 때의 형식 API에서 우리는 크라가 서버로 보내는 ‘요청(request)’과 서버가 크라에게 보내는 ‘응답(response)’에 대해 공부했다. 그리고 요청과 응답을 할 때는 데이터가 담길 수 있어 데이터를 담을 수 있는 ‘기능’을 함께 개발해야 한다는 것도 배웠다. 그런데 데이터를 넣을 수 있는 ‘기능’에는 여러 형식이 있다.

먼저 형식이 무엇인지 보자. 크라가 서버에 ‘아이디, 요청 일시, 다른 정보’를 보낸다고 가정해보자. 그 정보들은 다양한 형태로 전송될 수 있다.

형식 1 [ID, 요청일자, 기타정보///wychoi0709, 20181022, 세상에]

형식 2 {ID:wychoi0709, 요청일자:20181022, 기타정보:몇시기}

형식 3 [(ID, wychoi0709), (요청일자, 20181022), (기타정보, 몇시기)

…이렇게 무한개의 형식을 만들어낼 수 있다는 것이 문제다. 요청을 보낼 때 혹은 응답을 받을 때 각 요청이나 응답마다 형식이 다를 수 있다. 그럼 그 형식을 처리하기 위한 코드를 다시 써야겠다. 80개의 요청이 모두 다르면 80개의 형식에 대응하는 코드를 써야 한다. 매우 비효율적이다. 그래서 개발자들은 생각했다. ‘유명한 형식을 다 같이 쓰면 안 될까?’

과거에는 XML이라는 형식이 널리 쓰였고 지금도 많이 쓰이지만 현재 가장 유명한 형식은 JSON이다. 그럼 JSON이 어떤 모습인지 보자.

JSON은 중괄호 {}로 시작한다. 클리고키(Key)와 값(value)으로 구성되어 있다. 그 키와 값은 콜론(:)으로 구분한다.

혹시 쇼핑몰 메인 페이지에서 상품 정보를 가져온다고 가정해보자. 이때 상품 정보는 하나만 읽지 않는다. 다양한 상품 정보를 읽어야 한다. 이럴 때는 배열이라는 형식이 필요하다. JSON에서는 대괄호[ ]로 배열을 표시한다. 즉, ‘상품1’, ‘상품2’, ‘상품3’으로 적는다.

이 JSON을 활용해 개발자들은 이렇게 말한다.”그 정보는 JSON에게 보냈습니다” “로그인 API 응답을 보낼 때 JSON 안에 같이 넣어 보냅니다” 그건 JSON에 들어 있습니다”

대화를 보면 JSON이 마치 데이터를 주고받는 주머니 같다. 개발자들이 이렇게 말하는 이유는 JSON이라는 파일이 있기 때문이다. 해당 파일 안에 JSON 형식으로 데이터가 들어간다.

즉, 클라와 서버는 요구와 응답을 주고받고, 그때 필요한 데이터를 JSON 형식으로 주고받는다!

API 문서 열람 서버(백, 백엔) 개발자와 클라이언트(크라, 프론트, 프론트 엔드) 개발자가 협업하고 있는 회사라면 API 문서가 존재할 것이다.

깃북(GitBook)은 깨끗한 API 문서 작성을 지원하는 서비스다. 해당 서비스가 보여주는 예시 문서를 살펴보자. GetCake는 케이크를 달라는 API에 관해 설명하는 문서다. 아마 실제 서비스에서는 「회원 정보」나 「타임 라인」과 같은 데이터일 것이다. 구체적으로 하나씩 살펴보자. 먼저 파란 GET를 보자. 클라가 서버에 요청을 보낼 때 스티커(메소드)를 붙여둔다고 한다. GET 스티커는 READ를 의미한다.

그리고 https://api.cakes.com/v1/cakes/:id라는 주소가 있다. 앞의 https://api.cakes.com/’은 컴퓨터가 있는 위치다. 원래 IP 주소가 들어가는 곳이다. 그 뒤에 v1/cakes/:id가 붙어 있다. 이것은 케이크를 CRUD하기 위한 주소다.

그 아래에 리퀘스트(request)와 응답(response)이 있다. 그림에서는 response가 선택되어 있다. 그리고 우리가 배우지 못한 pathparameters, header, queryparameters가 나와 있다. 이 구체적 구분은 기획자 입장에서는 중요하지 않다. 다만 파라미터는 배웠다. 파라미터는 메서드를 송신할 때의 요구 변수이다. 해당 요청을 보내기 위해 어떤 파라미터가 필요한지 확인할 수 있어야 한다.

그럼 응답(response) 부분을 살펴보자. 답변은 두 가지로 나뉜다. 잘 될 경우 200번대, 잘 안 될 때는 400번대 혹은 500번대의 코드가 필요하다. 그리고 응답 데이터나 메시지를 JSON 형식으로 보내주고 있다.

200번대를 보면 케이크 이름, 케이크 레시피, 이진수 케이크 데이터(Binarycake)를 보내주고 있다.

404는 서버에 없는 정보를 쿠라가 요청했을 때 보내주는 코드다. 따라서 “그런 케이크는 없다(ain’t nocakelikethat)”는 메시지를 보내고 있다.

+ Add Response Example 버튼을 통해 다른 메시지도 추가할 수 있도록 구성되어 있다. API 문서는 이렇게 구성되어 있다.

도메인 이름?IP 주소는 원래의 숫자로 구성되어 있다. 175.345.822.402와 같다. 인터넷에 연결된 모든 컴퓨터는 그런 숫자를 가지고 있다. 요청을 보내려면 그 숫자를 알아야 해. 하지만 숫자는 불편하다. 여러분이 네이버에 접속한다고 생각해보자. 네이버 주소가 숫자로 되어 있다면 우리는 그 숫자를 모두 외워야 한다. 더욱이 네이버 이외에 수많은 서비스에 접속하려면 각 서비스의 숫자를 암기하고 있어야 한다. 새 서비스 주소를 친구에게 전달하려고 해도 숫자를 나열해야 한다. 그래서 사람들은 숫자 대신 도메인 네임이라는 것을 만들었다. www.naver.com 같은 글자다. 의미를 가진 문자는 사람들이 쉽게 외울 수 있으니까. 도메인 네임만 입력하면 우리가 모르는 사이에 IP로 바뀌어 컴퓨터의 위치를 찾는다. 즉 도메인 네임은 IP 주소와 같다.
우리가 지금 당장 볼 수 있는 API 문서는 네이버나 카카오 홈페이지에 있다. 네이버에서는 네이버 서버가 제공하는 다양한 기능을 일반인이 사용할 수 있도록 오픈해놨다. 개발자는 네이버에서 제공하는 API 문서를 보면서 해당 기능을 사용할 수 있다. 이러한 API를 오픈 API라고 한다.
그렇다면 왜 네이버는 서버 기능을 개발자가 사용할 수 있도록 열어놨을까. 다른 개발자가 네이버 기능을 이용해 사용자가 해당 서비스를 사용하면 당연히 네이버 서비스의 영향력이 높아진다. 영향력은 힘이고 돈이다. 더불어 API 사용의 경우 특정 횟수 이상은 돈을 받기도 한다. 비즈니스 모델이 되는 것이다. 프리미엄 기능에 대한 API를 따로 정해두는 방식으로도 돈을 벌 수 있다. 이처럼 다양한 이유로 회사는 서버 API를 오픈한다.
이제 여러분은 API 문서를 읽고 이해할 수 있게 되었다. 이해한다는 것은 협업하는 사람에게 많은 것을 묻지 않고 스스로 진행 상황을 파악할 수 있다는 의미이기도 하다.
예를 들어 협업 중인 프로젝트에서 회원 정보에 생일을 추가하기로 했다. 그러면 회원가입 API와 회원정보 조회 및 수정 API에 대한 변경이 필요하다. 물론 화면도 수정돼야 한다. 화면 수정이 끝났는지는 결과가 확실해서 볼 수 있지만 서버 작업이 완료됐는지는 눈에 보이지 않는다. 이때 API 문서를 읽고 이해할 수 있다면 어느 정도 진행했는지 스스로 예측할 수 있다.
제5장 애플리케이션은 설치해서 사용하는 모든 프로그램이다. 그런데 스마트폰이 등장하면서 ‘앱’, ‘애플리케이션’이라는 말이 퍼지기 시작하면서 데스크톱에 설치하는 프로그램은 ‘응용프로그램’이라고 부르고 스마트폰에 설치하는 프로그램은 ‘앱’ 혹은 ‘앱’ 혹은 ‘애플리케이션’이라고 부르게 됐다. 따라서 운영체제 위로 올라가는 프로그램, 설치해야 하는 프로그램, 애플리케이션, 앱, 앱 모두 같은 그룹이다.
개발자가 앱을 만들 때 ‘1.0.0’처럼 자신이 개발한 프로그램에 번호를 부여한다. 이 번호를 버전이라고 부른다. 점(.)을 기준으로 숫자가 세 부분으로 나뉜다. 보통 오른쪽 끝은 작은 변화를 의미한다. 중간 숫자는 하위 버전과 호환이 가능하지만 큰 변화를, 왼쪽 끝은 하위 버전과 호환되지 않는 큰 변화를 의미한다.
6장. 웹웹은 HTML, CSS, 자바스크립트로 구성되어 있다.일단 HTML부터 보자.HTML(Hyper Text Markup Language)의 시작은 다음과 같다. ‘유럽 입자물리연구소’에서 일하던 ‘팀 버너스리’는 연구소 내 직원들이 수많은 정보를 주고받는 상황에서 문제를 발견했다. 직원이 다른 운영 체제나 애플리케이션을 사용하고 있기 때문에 각각의 운영 체제에서만 호환되는 파일을 주고받을 때 파일을 열 수 없었습니다. 이를 해결하기 위해서는 운영체제나 프로그램에 관계없이 일정한 형식이 항상 동일하게 보이도록 하는 새로운 개념이 필요했다. 그래서 그는 일정한 형식(HTML)으로 작성한 문서를 제안했다. HTML 문서는 운영체제에 관계없이 브라우저만 있으면 스마트폰이든 PC든 노트북이든 윈도우든 맥이든 iOS와 안드로이드든 모두 웹사이트에 접속해 같은 정보를 볼 수 있도록 했다.
이를 통해 모든 정보가 자유롭게 공유되는 세상, 즉 웹을 통해 누구나 쉽게 정보에 접근할 수 있는 오늘날의 위키백과 같은 모습을 꿈꿨다. HTML 코드를 보면 위키백과처럼 정보를 체계화하는 코드가 존재한다. 예를 들어 <h>는 Header(대제목)를 의미하고 <p>는 Paragraph(단락)를 의미하며 <ol>은 Ordered List(순서가 있는 목록)를 의미하며 <ul>은 Unordered List(순서가 없는 목록)를 의미한다. 이렇게 정보를 표현하기 위한 코드를 태그라고 부른다. ‘태그’는 HTML을 구성하는 코드이다. 태그 안에는 어떤 HTML 문서에서 다른 HTML 문서로 이동할 수 있는 <a>라는 태그가 있다. 우리에게 익숙한 링크라는 개념이다. 정보를 자유롭게 나누는 목적에 딱 맞는 기능이다. 여기서 주의해야 할 점은 HTML은 프로그래밍 언어가 아니라는 점이다. HTML은 컴퓨터가 특정한 일을 시킬 수 있는 언어가 아니라 단순히 브라우저가 볼 수 있는 문서를 쓰는 언어다. 이렇게 만들어진 HTML을 이용해 많은 사람들이 정보를 교환하기 시작했다.시간이 지나면서 사람들은 포토샵이나 일러스트레이터 같은 디자인 기능을 원했기 때문에 HTML에 디자인을 입히는 코드인 CSS(Cascading Style Sheets)를 붙였다. 이를 통해 HTML에 디자인을 추가할 수 있게 되었다. 이렇게 코드가 분리되자 HTML 코드는 정보만 표현하고 CSS 코드는 디자인만 표현할 수 있어 깨끗해졌다. 디자인을 수정하려면 CSS만 찾아 바꾸고 정보를 수정하려면 HTML 코드만 바꾸면 된다. HTML과 CSS를 합쳐 퍼블리싱 작업으로 표현한다. 마크업이라는 말도 심심찮게 등장한다. 마크업의 M은 HTML의 M을 의미한다. 즉 HTML 작업을 마크업 작업이라고 부르며 HTML 작업을 주로 하는 분들을 마크업 개발자라고 한다.웹이 더 널리 쓰이게 되면서 ‘장바구니’, ‘로그인’, ‘회원가입’ 등 다른 기능을 원하는 이들이 생겨났다. 상기 기능은 HTML과 CSS에서는 어려운 기능으로 프로그래밍 언어가 필요하다. 그래서 웹 측에서는 ‘자바스크립트’라는 언어가 프로그래밍 언어 역할을 하게 됐다.
검색창에 “a”를 입력해보자. 지금은 ‘a3 스틸 얼라이브’가 맨 위에 있지만 2019년 중순 a를 입력했을 때는 ‘awholnew World 가사’라는 키워드가 맨 위에 있었다. 그리고 어느 순간에는 ‘A형 독감’이라는 키워드가 맨 위에 있었다. 이 말은 무슨 뜻일까. 검색어를 입력했을 때 표시되는 추천 검색어는 실시간으로 이뤄진다는 얘기다. 지금 사람들이 가장 많이 검색하는 키워드를 보여주는 것이다.
그럼 a를 치는 순간 무슨 일이 일어나는지 설명해 보자.a를 치면 자바스크립트가 ‘사용자가 a를 쳤다’는 것을 감지한다. 그리고 그 a에 해당하는 실시간 검색어 목록을 조회하는 API 요청을 네이버 서버로 보낸다. GET 리퀘스트다. 그러면 네이버 서버는 a에 대한 실시간 검색어 목록을 정리하고 응답해준다. JSON 형식으로 날아올 거야. 자바스크립트는 그 응답을 열고 HTML로 바꾼다. 필요하면 CSS도 추가할 수 있다. 그리고 해당하는 부분에 꽂는다. 이 모든 동작은 프로그래밍 언어인 자바스크립트만 할 수 있다. HTML과 CSS에는 이런 기능이 없다.

네이버 홈페이지 한번 허물어보자. HTML 상에서 오른쪽 버튼을 클릭하고 Delete Elements를 누르면 HTML의 일부를 지울 수 있다. 자세히 보면 검색창과 로그인 버튼이 없고 중간에 이미지도 없다. 비디오도 없어졌다. 이렇게 body 자체를 없애면 모든 화면을 띄울 수도 있다. 자, 이제 무슨 일이 벌어질까. 경찰에서 전화가 오려나? 네이버 홈페이지를 망가뜨린 죄로 벌금 낼까? 아니, 아무 일도 일어나지 않아. 내가 HTML을 지운 건 의미 없는 행동이니까. 이 부분이 웹의 가장 큰 특징이다.

HTM, CSS, 자바스크립트 완성본은 모두 서버에 있다. 위에서 GET 요청으로 HTML 문서를 받아 왔다. 서버에 있는 HTML 문서를 임포트한 것이다. 그렇게 HTML을 읽은 후 HTML과 연결된 CSS, avaScript, 이미지, 글꼴, 동영상 등의 파일을 다시 다운로드한다. 즉, 컴퓨터에 있는 HTML, CSS, 자바스크립트는 모두 ‘복사’입니다. 네이버 홈페이지를 망가뜨린 건 서버에 있는 원본을 건드린 게 아니라 내 컴퓨터에 있는 다운로드된 HTML 복사본의 일부분을 지운 것이다. 갱신하면 HTML 원본에서 다운로드한다. 그리고 CSS, 자바스크립트 등도 다시 다운로드한다. 이 부분이 웹과 앱을 나누는 가장 큰 차이다.

앱을 1.0.0에서 2.0으로 변경하려면 업데이트가 필요하다. 모바일이라면 심사도 필요하다. 그렇게 업데이트된 결과를 사용자가 다운로드해야 한다. 그래야 변화가 반영된다. 하지만 웹은 다르다. 웹은 그대로 서버 원본을 바꾸면 된다. 그러면 ‘리로드’할 때 변경된 HTML, CSS, 자바스크립트, 이미지 등의 파일이 다시 다운로드된다. 심사 과정도 없고 사용자 업데이트 과정도 필요 없다. 새로고침하면 자동으로 다 반영된다.

웹과 앱은 각각 장단점이 있다. 우선 웹은 수정이 쉽다. 원본만 수정하면 사용자가 업데이트하지 않아도 리로드하면 반영된다. 빠르게 적용할 수 있다. 하지만 앱은 그렇지 않다. 오래 걸린다. 재미있는 것은 웹의 장점이었던 ‘리로드’가 단점이기도 한다는 점이다. 웹은 항상 업데이트해야 한다. 즉, 매번 HTML, CSS, Java Script를 다운로드 해야 한다. 웹은 네트워크가 빠른 환경이면 괜찮다. 하지만 우리가 사는 세상의 네트워크가 항상 빠른 것은 아니다. 사람이 많은 곳에 가면 인터넷이 마비된다. 웹은 이 네트워크의 영향을 크게 받는다. 반면 앱은 웹보다 효율적으로 네트워크의 영향을 조금만 받도록 할 수 있다. 대표적인 앱이 카카오톡이다. 카카오톡은 여러분의 대화 내역을 여러분의 기기(스마트폰, 노트북 등)에 저장한다. 새로운 대화만을 불러일으키다. 그러다 보니 카카오톡을 쓰다 보면 용량이 너무 커져 채팅방을 나가야 하는 경우가 생기는 것이다. 채팅방을 나가면 저장된 대화를 없애고 용량을 확보할 수 있다. 이런 방식으로 카카오톡은 속도 문제를 해결했다. 다른 대표적인 앱으로는 에버노트가 있다. 에버노트는 오프라인 상태에서도 노트를 만들 수 있다. 그리고 온라인 상태가 되면 ‘동기화’ 인터넷에 관계없이 서비스를 사용할 수 있도록 한 것이다.

웹 개발자들이 못 한다고 말하는 이유는 5개의 브라우저(크롬 익스플로러 오페라 파이어폭스 사파리)가 전 세계에서 가장 큰 점유율을 차지하는 브라우저다. 먼저 이들 브라우저는 HTML, CSS, 자바스크립트를 받아 읽는다. 그리고 HTML에 적힌 대로 정보를 표시하고 CSS에 적힌 대로 디자인을 하고 자바스크립트에 적힌 대로 동작한다. 그것이 브라우저가 하는 일이다.

하지만 크롬과 같은 브라우저는 익스플로러 또는 사파리에 들어가 다운받아 설치할 수 있다. 그래야 크롬을 실행할 수 있다. 다운로드와 설치가 필요하다는 것은 크롬이 ‘애플리케이션’이라는 것이다. 다른 브라우저도 마찬가지다. 모두 애플리케이션이다. 즉, 애플리케이션은 사용하는 사람에 따라 버전이 다를 수 있다. 그리고 브라우저 자체도 다를 수 있다.

이게 왜 문제가 되지? 생각해 보자. 인터넷 익스플로러 4 버전은 CSS2에서 추가된 기능을 알 수 있을까. 혹은 인터넷 익스플로러 8 버전에서 HTML5 기능이 정상적으로 작동하는가?’ 답은 ‘아니오’다. 여기서 문제가 발생한다. 각 브라우저는 서로 다른 애플리케이션이기 때문에 브라우저에 따라 그 안의 구현 방식이 다르다. 즉 HTML, CSS, 자바스크립트의 특정 기능이 버전별, 브라우저별로 동작할 수도, 동작하지 않을 수도 있다. 누군가는 인터넷 익스플로러를 사용하고, 누군가는 크롬을 사용하고, 누군가는 사파리를 사용하는 복잡한 상황에서 웹프런트 개발자는 소비자의 브라우저 버전과 종류에 맞게 정상적으로 작동할 수 있도록 추가로 코드를 작성해야 한다. 이 문제를 ‘브라우저 버전의 파편화’라고 부르며 문제 해결을 위한 코딩을 ‘파편화 잡기’라고 표현한다. 클라이언트, 웹 프론트 엔드, 퍼블리싱 작업을 하는 분들이 힘들어하는 주요 이유 중 하나다.

앞으로는 이런 생각이 들거야.아니, 그 많은 브라우저의 단편화를 어떻게 잡아?사실 모두를 만족시킬 필요는 없다. 중요한 것은 점유율이다. 국내 서비스라면 더욱 국내 사용자 점유율을 조사하고 따져봐야 한다.

반응형으로 코딩하면 더 비싸요?과거 모니터는 엇비슷했다. 그래서 웹을 개발하는 사람들은 “웹페이지를 만들 때 양쪽을 잘라서 적당한 해상도를 맞추면 다 비슷해 보일 거야!”라고 생각했다. 이러한 이유로 과거 웹페이지는 양쪽이 끊어져 가운데 콘텐츠가 모여 있는 형태로 디자인되어 있다. 하지만 시간이 지나면서 스마트폰과 태블릿이 등장하면서 문제가 생겼다. 스마트폰으로 ‘PC 버전 웹’을 볼 때는 화면이 끊겨 보이는 것이었다. 오른쪽으로 돌려 확대/축소해 불편하게 웹을 확인해야 했다.

그래서 네이버, 다음 같은 회사는 m.naver.com, m.daum.net처럼 주소 앞에 m이 붙는 모바일용 웹페이지를 따로 만들었다. 그런데 모바일과 pc버전의 웹을 따로 만들어 출시하는 것은 불편하다. 디자인을 바꾸려면 다른 CSS 파일을 수정해야 하기 때문이다. 내용을 수정해야 할 경우 HTML을 두 번 수정해야 했다. 작업이 중복되기 때문에 비효율적이고 버그가 발생할 수도 있다.

이런 불편함을 해결하기 위해 등장한 기술이 ‘반응형 웹’이다. 브라우저 가로폭으로 ‘반응’해 구성요소가 바뀌는 기술이다. 이전에는 가로폭이 특정 픽셀 이하로 내려가거나 이상으로 올라가면 각기 다른 CSS를 적용해야 했다. 그러나 반응형 기술을 활용하면 공통으로 사용하는 CSS 코드는 그대로 두고 레이아웃 중심으로 나눠 작업해 나가는 기기의 디자인을 구현할 수 있다. 즉 웹페이지 크기(비율)가 사용자의 기기에 맞춰 자동으로 변형된다는 의미다. 이를 위해서는 서로 다른 기기의 넓이에 따른 CSS를 추가로 코딩해야 한다. 당연히 한 넓이로 작업하는 것보다 더 많은 코드가 필요하다. 따라서 반응형으로 웹을 만들려면 작업시간이 오래 걸리고 비용이 더 많이 들게 된다.

어플리케이션 얘기하는데 왜 자꾸 웹 개발자에게 말하라고 해? iOS 프로그램을 개발하기 위한 프로그래밍 언어는 Swift, Objective-C이다. 안드로이드 프로그램을 개발하기 위한 프로그래밍 언어는 자바, 코틀린이다. 이들 언어로 개발한 앱을 네이티브 앱이라고 한다. 원래 정해둔 언어를 사용해 운영체제 자체의 기능을 사용하기 때문에 원주민이라는 뜻을 가진 원어민이 붙게 된다.

하지만 운영체제 안에 브라우저가 내장되자 새로운 방식으로도 앱 개발이 가능해졌다. 바로 앱의 특정 부분에 브라우저를 올리는 방식이다. 그리고 HTML 파일을 가져올 URL을 설정해 둔다. 그러면 브라우저가 나타나고 해당 브라우저는 HTML과 HTML에 연결된 파일을 불러와서 보여준다. 그 부분은 HTML, CSS, Java Script로 구성되어 있다. 네이티브와 브라우저가 혼합된 애플리케이션이다. 이처럼 애플리케이션이 혼합된 앱을 ‘하이브리드 앱’이라고 한다.

이런 하이브리드 앱을 수정하려면 어떻게 해야 할까. 브라우저 위에서 돌아가는 부분은 서버에 있는 원본 HTML, CSS, Java Script를 수정하면 바뀐다. 이 부분은 통상 앱 화면이 표시될 때 바뀐다. 반면 원어민 부분은 운영체제별로 다른 프로그래밍 언어를 통해 수정한 뒤 심사를 신청해야 한다. 심사 신청 후에도 사람들이 바뀐 앱으로 업데이트해야 한다. 아무래도 시간이 걸리고 까다로워.

HTML, CSS, 자바스크립트를 가져와 보여주는 방식은 수정하기 쉽다. 서버의 HTML, CSS, 자바스크립트만 수정하면 따로 심사를 받거나 설치할 필요 없이 업데이트할 때 반영된다. 하지만 네트워크에 종속되기 때문에 와이파이나 모바일 네트워크가 느린 공간에 가면 HTML, CSS, 자바스크립을 모두 내려받는 동안 사용자는 기다려야 한다. 사용자가 불편을 느끼면 서비스를 떠날 수밖에 없다.

반면 원어민으로 만들면 수정하는데 넘어야 할 산이 많다는 단점이 있다. 특히 iOS 심사는 큰 장벽 중 하나다. 아울러 심사가 끝나더라도 사용자가 직접 업데이트해야 한다. 사용자 입장에서는 너무 잦은 업데이트는 귀찮다. 물론 잘 만든 앱은 사용성이 좋다는 장점이 있다. 네트워크를 최소한 이용하도록 코딩하면 인터넷이 느린 환경에서도 빠르게 동작한다.

지금 우리에게 남은 과제는 어느 부분이 웹이고 어느 부분이 원어민 앱인지를 구분하는 것이다. 그래야 문제가 생겼을 때 적합한 개발자에게 물어볼 수 있다. 결론부터 말하면 이 둘을 확실히 구분할 방법은 없다. 하지만 어느 정도 힌트는 있다. API 문서를 살펴보는 것이다. API 문서에는 웹 개발자를 위한 부분과 앱 개발자를 위한 부분이 구분돼 있다. 물론 그 두 사람이 함께 사용하는 API의 경우에는 특별한 표시가 없을 수도 있다.

제7장. 데이터베이스와 화상처리 “클러에 저장됩니다.”구라가 가지고 있어요” 도대체 구라가 가지고 있는 게 뭐야?CPU, 메모리, 보조 기억 장치라는 하드웨어에 대해 배웠다. CPU는 컴퓨터 머리, 보조기억장치는 컴퓨터 창고다. 메모리는 CPU의 개인 작업 공간이다. 그러나 메모리에 저장된 데이터는 전원이 꺼지면 사라진다.

글쎄 생각해보자. 데이터는 CPU, 메모리, 보조 기억 장치 중 어느 쪽에 저장되는가? 당연히 보조기억장치에 저장된다. 반면 데이터베이스관리시스템(DBMS)은 소프트웨어다. 왜냐하면 CPU와 메모리가 있으면 DBMS를 실행할 수 있다는 것이다. 우리는 「네트워크」에서 2개의 다른 컴퓨터 그룹을 배웠다. 「클라이언트」와 「서버」이다. 클라이언트와 서버는 모두 컴퓨터이기 때문에 CPU, 메모리, 보조 기억 장치를 가지고 있다. 그러면 클래와 서버 컴퓨터 위에는 둘 다 데이터베이스 관리 시스템을 돌릴 수 있어 데이터를 저장할 수 있다. 그 때문에, 데이터는 크라에도 보존할 수 있다. 서버에서만 DB를 사용하는 것처럼 아는 사람이 많지만 실제로는 그렇지 않다. 개발 이슈에 따라 크라의 DB도 많이 활용한다.

그렇다면 DB가 클라에 저장되어 있는지 서버에 저장되어 있는지 어떻게 알 수 있을까. 인터넷이 연결되지 않은 상태에서도 동작하면 구라에 있는 DB이다. 서버와 통신하지 않아도 정상적으로 작동하기 때문에. 알람 앱에서는 서버가 필요 없기 때문에 그 데이터도 클라이언트에 있다.

앱스토어를 보자. 앱스토어에도 다양한 데이터가 있다. Adobe Premiere RuchCC라는 텍스트가 있다. 이 데이터는 어디에 있는 데이터일까. 서버인가? 크라인가? 답은 서버다. 왜일까?이 데이터는 어느 스마트폰에서 접속해도 똑같아 보인다. 데이터가 서버에 있기 때문에 데이터를 변경하면 다른 모든 기기에 변경된 데이터가 나타난다.

그러나 개발 결과만 보고 항상 명확하게 구라에 있는 데이터/서버에 있는 데이터와 구분할 수는 없다. 회사 사정에 따라 개발자 상황에 따라 개발 단계에 따라 기능 특성에 따라 경우가 모두 다르다. 그러나 API 문서에는 거의 모든 답이 들어 있다. 이 문서를 읽어보면 데이터를 어디서 읽는지 명확하게 알 수 있다. 우리는 개발팀의 사정과 상황에 무관심해서는 안 되며 회사의 개발 결과를 잘 파악해야 한다. 아울러 현재 개발팀이 어디에 집중하고 있는지, 어떤 부분에서 막혔는지를 파악하고 있어야 한다. 그 시작이 API 문서다.

우리에게 남은 과제는 서비스의 어떤 데이터를 서버에서 가져올지, 어떤 데이터가 클라이언트에 있는지를 구분하는 것이다. 때로는 양쪽에 데이터가 있는 경우도 있다. Like 에버노트. 이러한 앱은 클라이언트의 데이터와 서버의 데이터를 합치는 「동기화」라는 프로세스가 필요하다. 에버노트는 클라에 데이터를 두기 때문에 오프라인 상태에서도 노트를 쓸 수 있다. 그리고 서버에도 데이터를 두기 때문에 다른 기기에서도 같은 노트의 내용을 볼 수 있다.

그럼 이 구분이 왜 중요한가. 그 이유는 정확한 사람에게 정확한 요청을 하기 위해서다. 데이터가 크래에 있는 상황에서 그 데이터를 변경하고자 하는 경우에는 당연히 클라이언트 개발자와 이야기해야 한다. 반면 데이터가 서버에 있는 상황에서 해당 데이터를 변경하려면 당연히 서버 개발자와 이야기해야 한다.

“그 데이터는 로컬에 있습니다” “내부 DB에 저장하고 있습니다” “원어민에서 가져온 건데?이런 말이 들린다면 이는 모두 클라이언트에 데이터가 있다는 표현이다.

API로 가져왔어요.DB에 저장해 놓고 쓰면 안 되나요?반면 서버 API DB 백/백엔 같은 표현은 서버에서 데이터를 가져왔다는 뜻이다. 여기서는 DB와 내부 DB만 잘 구분하면 된다.

배너를 바꾸려고 하는데 자꾸 자기한테 말하면 안 된대요.왜 자꾸 사람이 변해?마케팅 캠페인을 위한 배너 디자인을 완성했다. 서둘러 iOS 개발자에게 간다.이 배너를 새 캠페인 배너로 바꿔주세요. 굉장히 중요하고 급해요!”

그럼 iOS 개발자는 말한다.배너 화상은 서버로부터 수신되고 있습니다. 서버 개발자에게 말해주세요.

얼마 전에는 앱에서 아이콘을 수정하는 작업을 위해 서버 개발자를 찾았다.이 부분의 아이콘을 새로 바꾸고 싶어요.”

그런데 서버 개발자는 이렇게 말하고 있었다.’ 아이콘은 쿠라에 있는 것입니다. 쿠라 개발자에게 말해주세요.

아니, 도대체 왜 사람이 계속 변하는 거지? 무엇보다 어떤 요소가 서버에 있는지, 클라에 있는지 비전공자가 어떻게 알 수 있을까? 그리고 이미지는 도대체 어떻게 관리하는 것일까?윈도우 한번 보자. 데스크톱에 이미지가 있다. 이 이미지의 이름은 myimage.png이다. 이 상황에서 전혀 다른 이미지를 다운로드한다. 그리고 같은 바탕화면에 놓는다. 이름을 ‘myimage.png’로 바꾸면 바뀔까? 변하지 않는다. 이미 그 위치에 존재하는 이름이기 때문이다. 이미지 위에 마우스 오른쪽 버튼을 누르면 속성이라는 메뉴가 있다. 「속성」을 누르면 화상 정보가 표시된다.

그 정보에는 「위치」가 있다.User/young/Desktop/myimage.png 같은 모습이다. 위치는 고유해야 한다. 왜일까?운영체제가 그 고유의 위치를 통해 이미지를 인식하기 때문이다. 이제 우리는 이미지 파일에는 모두 ‘위치’가 있다는 것을 알고 있다. 지금부터 이 위치를 주소라고 표현해보자.

컴퓨터라면 누구나 이미지 파일을 보관할 수 있다. 즉, 크라도 이미지 파일이 있고 서버에도 이미지 파일이 있을 수 있다. 그들은 모두 주소를 가지고 있다는 것도 우리는 알고 있다. 그렇다면 당연히 서버에서 이미지를 공유하고 크라가 이미지 주소를 안다면 서버에 있는 이미지를 크라로부터 불러올 수 있다. 클래로부터 서버상의 화상을 읽는다는 것은 네트워크를 통해 화상 파일을 다운로드하는 것을 의미한다.

이미지 파일 사이즈는 어때? 작은 이미지도 있지만 하나에 100MB가 넘는 큰 이미지도 있다. 그런 이미지를 다운로드하려면 엄청난 시간이 걸린다. 고객은 기다려야 한다. 인터넷이 느린 곳이라면 더 심하겠다. 쿠라에 이미지를 두면 장점이 있다. 이미지를 다운로드하지 않아도 된다. 단순히 클라이언트 프로그램이 이미지 주소를 통해 이미지를 가져옵니다. 네트워크보다 훨씬 빠르다.

그렇다면 왜 서버에 있는 이미지를 불러오는 것일까? 그냥 쿠라에 이미지 놓고 쓰면 안될까? 쿠라의 이미지는 어떻게 바꿀까? 크라의 이미지를 바꾸려면 앱을 업데이트해야 한다. 버전 1.0.0에서 이미지 1을 보여줬다고 가정해 보자. 만약 버전이 1.0.1로 올라가 ‘이미지2’를 보여주기로 하면 고객이 업데이트를 통해 앱 버전을 올려야 한다. 만약 업데이트하지 않고 버전 1.0.0을 사용하는 고객이라면 이미지2는 보이지 않는다.그럼 어떻게 해야 되지?상황에 따라 둘 다 사용해야 한다.최대한 네트워크에 부담이 가지 않도록 많은 이미지를 크라에 둬야 하는데 이미지가 바뀌었을 때 서비스에 영향을 준다면 서버에서 가져와야 한다. 즉 클라에 둘지 서버에 둘지를 결정하기 위해서는 이미지의 성격을 봐야 한다.조금 다른 이미지도 생각해보자. 이미지를 만드는 주체는 ‘회사’일 수도 있고 ‘고객’일 수도 있다. 인스타그램에는 수많은 고객이 매일 수많은 이미지를 업로드한다. 일반적인 다른 서비스에서도 고객은 자신의 프로필 사진을 업로드한다. 이런 이미지는 고객이 만들어낸다. 즉 ‘누가’ ‘어떤 이미지’를 만들었는지 ‘관계’가 생긴다. 서로 관계가 맺어진 데이터는 단 0.000001%의 오류도 허용하지 않는 ‘무결성’ 이슈가 있다. 누가 올린 프로필 사진이 다른 사람 프로필에 찍히면 안 되는 것처럼. 누군가 비공개로 올린 사진이 공개돼서는 안될 것 같다. 관리가 필요하다.

그럼 iOS 개발자는 말한다.배너 화상은 서버로부터 수신되고 있습니다. 서버 개발자에게 말해주세요.

얼마 전에는 앱에서 아이콘을 수정하는 작업을 위해 서버 개발자를 찾았다.이 부분의 아이콘을 새로 바꾸고 싶어요.”

그런데 서버 개발자는 이렇게 말하고 있었다.’ 아이콘은 쿠라에 있는 것입니다. 쿠라 개발자에게 말해주세요.

이런 이미지를 어떻게 관리할까? 이미지는 모두 주소를 갖고 있다. 여기서 주소는 텍스트이다. 관련된 텍스트는 관리하기 어렵다. 그래서 DB에 넣어둔다. 이로써 이미지를 철저히 관리할 수 있다.

정리해 보자.이미지 파일은 클러스터 서버의 어느 한 컴퓨터에 있다. 그리고 각 컴퓨터는 이미지 주소를 통해 이미지에 접근한다. 이러한 이미지를 변경하려면 파일을 변경하거나 다른 주소를 지정해야 합니다. 그리고 또 하나 있어. 프로필 이미지와 같은 파일의 경우 관계가 있기 때문에 관리가 필요하다. 이를 위해 주소를 DB에 넣어 관리한다.

마지막으로 이미지가 크라에 있는지 서버에 있는지 확인하는 가장 좋은 방법은 API 문서를 보는 것이다. API를 통해 이미지의 주소(URL)를 서버로부터 수신하면 해당 이미지는 서버에 있는 이미지로 판단할 수 있다.

8장. 프레임워크와 라이브러리 iOS 앱을 만든다고 생각해보자. 이때 개발자는 버튼에서 일일이 코딩하지 않는다. 버튼은 이미 애플이 만들어 놓았다. 그렇게 해둔 코드를 개발자가 사용한다. 그렇다면 애플은 왜 프레임워크를 만들어 놓았을까. 애플은 앱스토어에 좋은 앱이 올라오길 바란다. 좋은 앱이 많아야지 이 앱들을 쓰려고 아이폰을 사니까. 그런데 만약 애플 앱을 만드는데 버튼 하나하나를 코딩해서 너무 오랜 시간이 걸린다면 어떨까. 이렇게 수많은 앱이 만들어지지 않았을 것이다. 앱스토어에 있는 수많은 앱은 애플이 제공하는 프레임워크 덕분이다.

애플은 이 프레임워크 사용법을 웹페이지에서 제공하고 있다. iOS 개발자에게는 사전 같은 페이지다. 앱킷은 맥OS로 올라가는 애플리케이션을 개발하기 위한 프레임워크, UIKit은 iOS 또는 tvOS로 올라가는 애플리케이션을 개발하기 위한 프레임워크다. 애플은 기기가 많기 때문에 기기별로 프레임워크가 존재한다. 애플에서는 이 프레임워크를 통칭해 코코아 프레임워크라고 부른다. 이처럼 거대 IT 회사들은 개발자들이 자사의 앱을 쉽고 빠르게 개발할 수 있도록 프레임워크를 만들어 제공하고 있다.

그런데 문제는 웹이다. 웹은 특정 회사의 소유가 아니다. 우리 모두의 것이다. 그렇다면 웹 프레임워크와 라이브러리는 누가 만드는 것일까? 많은 사람이 만든다. 이미 시중에는 수많은 프레임워크와 라이브러리가 있다. 그 중 ‘웹프런트 엔드 프레임워크 및 라이브러리 3대장’으로 불리는 가장 유명한 3가지가 있다. Angular.js, React.js, Vue.js다. Angular.js는 구글에서 운영하고 있다. React.js는 페이스북으로 만들었다. Vue.js는 중국인이 만들었다. 이처럼 웹 프레임워크 및 라이브러리는 페이스북이나 구글 같은 회사가 만들거나 개인이 만들기도 한다.

웹과 마찬가지로 서버도 특정 회사 소유가 아니기 때문에 다양한 프레임워크가 존재한다. 그리고 각 언어별로 유명한 프레임워크가 하나씩 있다. 자바(ワジャスプリング)는 스프링이라는 프레임워크가 유명해. 자바와 스프링이라는 프레임워크를 사용하면 서버를 쉽고 빠르게 개발할 수 있다. 파이썬은 장고(Django)라는 프레임워크가 유명하고 루비에게는 레일즈(Rails)라는 프레임워크가 있다. 자바스크립트에서도 서버를 개발할 수 있으며, 이때는 익스프레스(Express.js)라는 프레임워크를 자주 사용한다.

그럼 라이브러리는 무엇일까? 라이브러리도 다른 사람이 만들어 놓은 코드를 이용한다는 측면에서 프레임워크와 같다. 단, 프레임워크가 보다 큰 개념이다. 각종 라이브러리와 코드가 모여 프레임워크가 된다. 또한 하나의 프로젝트에서 프레임워크는 하나만 사용할 수 있다. 한 자동차를 운전하면서 동시에 다른 자동차를 운전할 수 없는 것과 같다. 반면 라이브러리는 더 작은 개념이다. 망치나 가위 같은 도구이기 때문에 하나의 프로젝트에서 함께 사용할 수 있다.

제9장. 협업, 소스 관리, 디자인 커밋?멀어? 개발자가 타임라인 코멘트를 올린다. 버전은 1.0.0으로 했다. 이후 우선순위인 타임라인 수정 기능을 즉시 개발하기 시작했다.완성 후 버전은 1.1.0으로 올렸다. 그러다 갑자기 기획팀에서 분석 기능이 급하게 필요하다고 한다. 즉시 분석 기능을 개발하기 시작한다. 분석 기능을 완성한 후 버전은 1.2.0으로 했다. 그런데 갑자기 기획팀에서 분석 기능이 불필요해졌다고 한다. 개발자는 현재 버전인 1.2.0 상태의 코드에서 1.0.0 상태의 코드로 되돌려야 한다. 만약 분석코드 1,000줄을 100개의 파일로 나누어 넣어두면? 끔찍하다.

“분석 코드는 그대로 두면 안 되나?” Git는 이런 문제를 해결해 준다. 옷깃을 통해 개발자는 개발 단계별로 ‘깃발’을 들 수 있다. 그 행위를 ‘커밋’이라고 한다. 커밋에는 항상 메모가 붙어 있다. 어떤 개발을 했는지 적어주는 메모다. 그 메모를 ‘커밋 로그’라고 한다.

앞선 사례에서 개발자가 타임라인 수정을 완성하면 이제 커밋을 한다. 커밋 로그에는 ‘타임라인 수정 완료’라고 적는다. 그럼 날개는 거기에 깃발을 꽂는다. 날개는 깃발과 깃발 사이의 변화와 누가 언제 커밋하고 어떤 부분을 바꿨는지를 모두 추적해준다. 이어 ‘체크아웃’을 통해 깃발이 꽂힌 부분의 코드로 넘어갈 수 있다. 이것이 바로 깃의 주요 기능인 ‘소스코드 버전 관리’다.

이외에도 옷깃은 다양한 기능을 갖고 있다. ‘브런치’는 ‘분기’, ‘가지’라는 뜻으로 새 가지를 뻗는 것을 의미한다. 개발이 한창일 때 새로운 방향의 개발을 추가해야 할 때 개발자는 기존 개발에 이어 작업하지 않고 새롭게 가지치기 작업을 할 수 있다. 이렇게 하면 기존 브랜치에 커밋하는 것이 새로운 브랜치에 영향을 주지 않으며, 마찬가지로 새로운 브랜치에 커밋하는 것이 기존 브랜치에 영향을 주지 않는다. 이에 따라, 하나의 프로젝트를 진행할 때 동시에 복수의 기능을 충돌 없이 작업할 수 있게 된다. 그런 다음 각각의 브랜치로 작업한 코드를 맞추기만 하면 된다.

코드를 맞추는 기능이 바로 병합(Merge)이다. 날개는 영리하고 작업된 부분이 겹치지 않으면 자연스럽게 맞춰준다. 만약 겹치는 부분이 있다면 옷깃은 충돌(conflict)을 알리고 어느 부분이 충돌했는지를 보여준다. 개발자는 그 부분만 수정하면 된다.

마지막으로 ‘원격 저장소’를 살펴보자. 여러 명의 개발자가 각각 자신의 컴퓨터에 코드를 쓴다. 그럼 각 개발자의 컴퓨터에는 다른 코드가 존재한다. 다른 개발자가 작업한 코드를 맞추려면 그것이 또 다른 것이다. 이에 개발자들은 날개를 기반으로 한 날개 허브, 비트 버킷 등 ‘원격 저장소’라는 것을 만들었다. 개발자가 자신의 컴퓨터(로컬)로 작업한 후 커밋을 하면 그 결과를 원격 저장소로 보낼 수 있고 원격 저장소에서 이미 작업된 결과를 가져올 수도 있다. 구글 드라이브에서 자료를 공유하듯 파일을 다운로드할 수도 있고 새로 작업한 파일을 업로드할 수도 있다.

디자이너와 개발자 디자이너는 주로 포토샵과 일러스트를 사용하여 작업한다. 그러나 이 두 프로그램은 앱이나 웹 디자인에 최적화된 프로그램은 아니다. 따라서 포토샵과 일러스트로 작업을 하면 개발자가 요소의 넓이, 높이, X축에서 얼마나 떨어져 있는지 등의 수치를 하나씩 파악해야 하는 불편함이 생긴다. 이에 개발자들은 가이드를 요구하기 시작한다. 요소 위에 요소가 있는 경우, 그림자가 생기는 경우 등 각각의 사안에 대해 개발자가 이를 어떻게 처리해야 하는지를 일일이 설명하는 것은 보통 어려운 일이 아니다. 또 가이드를 어느 정도까지 자세히 줘야 할지도 모호하다.

이처럼 디자이너와 개발자 간 협업을 위해 스케치, 재플린, 피그마, XD 등의 프로그램이 등장했다. 디자이너의 작업 결과 수치를 보여줌으로써 별도의 디자이너가 가이드를 쓰지 않아도 된다.

동시에 스마트폰은 기종마다 가로세로 비율이 다르다. 이 비율 때문에 디자인 구현에서 큰 차이가 나타난다. 통상 디자이너는 하나의 기기를 기준으로 결과를 준다. 혹은 iOS/Android 각각 하나의 기기를 기준으로 결과를 준다. 수백 대가 넘는 기기의 디자인을 모두 합쳐 제공하는 것은 불가능하다. 따라서 디자이너는 가이드에 관심을 가져야 한다. 개발코드까지는 아니더라도 각 프레임워크에서 제공하는 가이드 문서를 어느 정도 숙지하고 있어야 한다. 애플은 HIG(Human Interface Guideline)를 제공하며 애플의 기기가 어떤 방침을 갖고 있는지 말하고 있다. 구글은 Material Design이라는 가이드를 제공한다.

부록 API 문서를 통해 서비스 분석을 실시하다

앱이든 웹이든 모두 텍스트와 이미지로 구성돼 있다. API 분석의 1단계는 텍스트와 이미지의 출처를 구별하는 것이다.

해당 텍스트는 클라이언트에 있는가? 서버에서 취득했나?2. 해당 이미지는 클라이언트에 있는가? 서버에서 가져왔나?
API 문서 중에는 GET 요청만 있는 것은 아니다. POST, PUT, PATCH, DELETE의 요청도 있다. 하지만 우리가 가장 주의 깊게 봐야 할 정보는 GET다. 어떤 정보를 읽고 있는지 확인하려면 GET 요청을 봐야 한다. 물론 사정에 따라서는 GET가 아닌 POST로 정보를 불러들이기도 한다. API는 개발자 간 약속이어서 회사나 기술 사정에 따라 바꿔 쓸 수 있다. 따라서 API 문서의 설명을 꼭 읽어봐라.