- IT 산업은 6개월 뒤의 모습만 예측할 수 있어도 대박이 난다고 이야기할만큼 변화의 속도가 너무나도 빠릅니다. 따라서 IT산업은 서비스가 만들어지는 과정 역시 다른 산업과 완전히 다릅니다. 만약 IT 산업에서 자동차를 만들고 싶다면, 자동차의 완벽한 기획에서 출발 해선 안 됩니다. 왜냐하면 지금 떠올린 자동차의 모습이 6개월, 1년 뒤에도 완 벽한 자동차의 모습이라고 장담할 수 없으니까요. 그래서 처음에는 이동수단이라는 '핵심기능'에 중점을 두어서 스케이트보드 형태의 자동차를 만듭니다. 이후 꼭 필요한 기능들을 붙여서 킥보드 형태로 발전시켜 나가죠. 시간이 지날수록 새로운 기술과 기능들이 탄생하게 되고, 이러한 것들을 차차 반영하여 자동차의 모습으로 만들어 나갑니다. IT 산업에서는 이런 식으로 점진적 발전만 있을 뿐입니다. 변화의 속도가 빠르기 때문에 처음부터 완성된 형태를 정해놓고 만드는 것은 위험한 일입니다. 대체로 다른 산업은 A~Z까지 정해진 완벽한 프로세스가 있습니다. 그 프로세스만 잘 따라가면 어려울 일이 없습니다. 하지만 IT 서비스는 그렇지 않 습니다. 완벽한 프로세스가 없고, 고객의 니즈와 회사의 사정에 맞춰 그때그때 서비스가 계속 ‘발전’ 되어 나갑니다. 서비스가 발전하는 이 흐름이 바로 기획입니다. 그래서 기획자는 항상 고객을 포함한 모든 서비스 구성원들과 대화를 해야 합니다.
- 애플의 운영체제 위에 돌아가는 프로그램을 만들려면 Objective-C 혹은 스위프트라는 언어를 사용해야 합니다. 구글 운영체제 위에 돌아가는 프로그램을 만들려면 자바 혹은 코틀린(Kotlin)이라는 언어를 사용해야 합니다. 애플 회사의 운영체제에 올라가는 프로그램은 원래 Objective-C라는 언어로 만들었습니다. 그런데 애플은 스위프트라는 새로운 언어를 만들기로 합니다. 처음 스위프트가 나왔을 때는 언어 자체에 낯선 개념들, 불안정한 요소 들이 많았기 때문에 많은 개발자가 불만을 표했습니다. 물론 시간이 지나면서 버전 2.0, 3.0 등이 나오며 개선되었고 지금은 아주 좋아졌습니다. 하지만 애플이 지금처럼 스위프트를 계속 발전시킨다면 어느 순간부터는 Objective-C에 대한 지원을 점차 줄일 것입니다. 그렇게 되면 Objective-C를 쓰던 프로그래머들은 모두 스위프트로 넘어와야 합니다. 이처럼 운영체제 회사들은 개발자들의 삶에도 큰 영향을 미치고 있습니다.
- 과거에는 운영체제의 종류가 훨씬 다양했습니다. 따라서 개발자가 배워야 하는 프로그래밍 언어도 굉장히 많았죠. 문제는 각기 다른 언어를 모두 배운다고 해도 프로그램 버그를 수정하거나 새로운 기능을 추가할 때면, 해야 할 일이 산더미처럼 늘어난다는 것이었습니다. 10개의 운영체제가 있다고 하면, 같은 작업을 10번씩 해야 하니까요. 이 문제는 자바라는 프로그래밍 언어가 해결합니다. 자바를 만든 팀은 각 운영체제 위에 JVM(Java Virtual Machine)이라는 소프트웨어를 만들었습니다. JVM 위에서 자바 언어로 만든 프로그램이 돌아갈 수 있도록 한 것이죠. 이것은 혁명적인 시도였습니다. 사용자가 자신의 컴퓨터에 JVM을 설치하기만 하면, 운영체제별로 여러 개의 프로그램을 만들 필요 없이 자바로만 만들면 되니까요. 즉, 자바로만 프로그램을 만들어도 모든 운영체제에서 사용할 수 있게 된 것입니다. 물론 사용자가 귀찮게 JVM을 왜 깔지?'라고 생각할 수 있습니다. 하지만 놀랍게도 사용자는 자신도 모르는 사이 JVM을 설치해왔습니다.
- 리눅스에도 다양한 버전이 있습니다. 리눅스의 유명한 버전 중 하나는 우분투(Ubuntu)입니다.
‘우분투는 리눅스다’
즉, 리눅스는 하드웨어를 관리해서 사용자가 프로그램을 사용하기 쉽게 도와주는 윈도우나 맥 OS 같은 운영체제이고, 우분투는 그런 리눅스 버전 중 하나라고 이해하시면 됩니다. 또 다른 유명 버전으로는 레드햇(Red hat) 리눅스가 있습니다. 레드햇은 리눅스를 개량해서 유료로 판매하는 회사입니다. 유료로 판매한다니 조금 의아 합니다.
'아니 리눅스는 공짜니까 서버에서 쓴다고 했는데, 그걸 유료로 팔면 누가 사지?'
생각보다 다양한 회사에서 구매합니다. 하나의 예를 들어보죠. 금융 산업에 종사하는 회사라면 안정적인 서비스가 필수입니다. 서버가 멈춘다거나, 고장나면 어마어마한 손실이 발생합니다. 만약 무료 운영체제를 사용하다 고장이나면 어떻게 될까요? 누군가에게 AS 요청을 하거나 책임을 물을 수 없습니다. 하지만 어떤 회사에서 운영체제의 품질을 보장해주면 어떨까요? 이게 바로 레드햇을 유료로 이용하는 이유입니다. 또 다른 리눅스의 유명한 개량 버전에는 안드로이드가 있습니다. 안드로이드는 구글이 리눅스를 모바일 운영체제 형태로 개량해서 발전시킨 운영체제입니다. 이렇듯 운영체제는 서로에게 영향을 주며 발전합니다. 마치 언어의 발전 과 같습니다. C 언어가 발전해서 C++, Objective-C, 파이썬 등의 언어가 되었던 것처럼, 리눅스가 발전해서 안드로이드가 되었습니다.
- 만약 서버 컴퓨터가 심각하게 고장 나서 저장장치도 복구할 수 없다면 무슨 일이 일어날까요? 전원이 꺼지는 것과는 비교할수 없습니다. 이미 저장된 모든 데이터가 날아갔으니까요. 회원 정보, 결제 정보, 배송 정보, 상품 정보 등을 모두 복구할 수 없습니다. 이처럼 개인이 서버를 운영하면 여러가지 리스크가 발생하게 됩니다. 그래서 이 모든 일들을 대신해주는 서비스가 나타나기 시작합니다. 이런 서비스를 제공하는 업체를 호스팅 업체'라고 부릅니다. 국내에는 대표적으로 Cafe 24, 가비아 등의 회사가 있습니다. 한편 외국에서도 이런 움직임이 있었습니다. 해외의 공룡 기업들이 서버를 제공해주는 서비스에 투자하기 시작했죠. 대표적으로 아마존의 AWS(Amazon Web Services)를 꼽을 수 있습니다.
- API는 클라이언트, 서버와 같은 서로 다른 프로그램에서 요청과 응답을 주고 받을 수 있게 만든 체계입니다. API는 이렇게 진행이 됩니다. 요청을 보내는 쪽과 응답을 주는 쪽이 나뉘어 있습니다. 여러분의 스마트폰은(클라이언트 컴퓨터) 요청을 보내고, 서버 컴퓨터는 요청을 받아서 응답을 줍니다. 이렇게 하려면, 응답을 주는 쪽에서 사전에 여기로 요청을 보내면 이러한 응답을 주고, 저기로 요청을 보내면 저러한 응답을 줄께'라고 정해놔야 합니다. 그래야 요청하는 쪽에서 정확한 곳에 요청을 보낼 수 있으니까요. ‘정확한 곳'에 해당하는 주소는 서버주소/A'의 형태로 정의되어 있습니다. 여기서 서버 주소'는 서버 컴퓨터가 위치한 곳의 주소입니다. 네트워크에서 언급한 IP 주소이죠. 그 주소 뒤에 어떤 문자를 쓰느냐에 따라 다른 기능을 수행하도록 정의하는 겁니다. 예를 들어, ‘서버주소/A'라고 신호를 보내면 서버가 '로그인 기능'을 수행하고 응답합니다. 혹은 서버주소/B'라고 신호를 보내면 서버가 '회원 가입 기능'을 수행하고 응답합니다. 잘 되었는지, 혹 문제가 있다면 무슨 문제가 있는지 등등을 알려주죠. 이러한 기능은 서버 개발자가 만 들며, 그 결과물이 서버 프로그램입니다. 서버 주소 정의 역시 서버 개발자의 주도하에 이루어집니다. 그리고 클라이언트 프로그램은 정해진 주소에 요청을 보냅니다. 즉, API는 서버 개발자가 개발하고, 클라이언트 개발자는 그 ADI를 사용합니다.
- API를 제공해주는 '다른 소프트웨어'를 SDK라고 부릅니다. SDK는 Software Development Kit의 약자로, 소프트웨어를 개발하기 위한 도구입니다. 즉, '○○ 소프트웨어’를 개발할 때 도움을 주는 다른 소프트웨어'입니다. 보통 다른 회사와 협업할 때, SDK라는 이야기를 듣게 됩니다. 구체적인 예를 들어보겠습니다. 구글 지도는 구글에서 만든 소프트웨어입니다. 이때 다른 회사들도 구글에서 제공하는 지도 SDK를 설치하면 자신의 소프트웨어에 구글 지도 기능을 넣을 수 있습니다. 이 SDK에서 제공해주는 API들을 통해 구글 지도에 요청을 보낼 수 있습니다.
- HTML(Hyper Text Markup Language)의 시작은 '유럽 입자 물리 연구소(CERN)' 였습니다. 당시 연구소에서 일하던 '팀 버너스리'는 연구소 내의 직원들이 수많은 정보들을 주고받는 상황에서 한 가지 문제를 발견했습니다. 직원들이 서로 다른 운영 체제나 애플리케이션을 사용하고 있다는 점이었습니다. 윈도우 사용자와 맥 사용자가 각각의 운영체제(OS)에서만 호환되는 파일을 주고받는다면 서로 파일을 열지 못해 문제가 생기겠죠. 이를 해결하기 위해서 는 운영체제나 프로그램에 상관없이 일정한 형식이 언제나 동일하게 보이도록하는 새로운 개념이 필요했습니다. 그래서 그는 일정한 형식(HTML)으로 작성한 문서를 제안합니다. HTML 문서는 운영체제에 상관없이 브라우저만 있으면 스마트폰에서도, PC에서도, 노트북에서도, 윈도우에서도, 맥에서도, iOS나 안드로이드에서도 모두 웹사이트에 접속하여 동일한 정보를 볼 수 있도록 해줬습니다. 이를 통해 팀 버너스리는 모든 정보가 자유롭게 공유되는 세상, 즉 웹을 통해 누구나 쉽게 정보에 접근할 수 있는 오늘날의 위키백과 같은 모습을 꿈꿨습니다. HTML 코드들을 보면 위키백과와 같이 정보를 체계화하는 코드들이 존재합니다. 예를 들면 는 Header(대제목)를 의미하죠.
는 Paragraph(문단)를 의미합니다.
- 은 Ordered List(순서가 있는 목록)를 의미하고,
- 은 (Unordered List(순서가 없는 목록)를 의미합니다. 이렇게 정보를 표현하기 위한 코드를 '태그'라고 부릅니다. '태그'는 HTML을 구성하는 코드입니다. 태그중에는 한 HTML 문서에서 다른 HTML 문서로 이동할 수 있게 해주는 〈a〉라는 태그가 있습니다. 우리에게 익숙한 '링크'라는 개념입니다. 정보를 자유롭게 나눌 목적에 딱 맞는 기능이라고 할 수 있죠. 여기서 주의해야 할 사항은 HTML이 프로그래밍 언어가 아니라는 점입니 다. HTML은 컴퓨터에게 특정 일을 시킬 수 있는 언어가 아닌 단지 브라우저가 볼 수 있는 문서를 적는 언어입니다
- - iOS 프로그램을 개발하기 위한 프로그래밍 언어는 스위프트, Objective-C입니다. 안드로이드 프로그램을 개발하기 위한 프로그래밍 언어는 자바, 코틀린이죠. 이 언어들로 개발한 애플리케이션을 '네이티브 애플리케이션'이라고 합니다. 원래 정해놓은 언어들을 사용해 운영체제 자체의 기능을 사용하기 때문에 '원주민'이란 뜻을 가진 '네이티브'가 붙게 됩니다. 하지만 운영체제 안에 브라우저가 내장되자 새로운 방식으로도 애플리케이션 개발이 가능해졌습니다. 바로 애플리케이션의 특정 부분에 브라우저'를 올리는 방식입니다. 그리고 HTML 파일을 불러올 URL을 설정해두는 거죠. 그럼 브라우저가 뜨고 그 브라우저는 HTML과 HTML에 연결된 파일들을 불러와서 보여줍니다. 그 부분은 HTML, CSS, JavaScript로 구성되어 있죠. 네이티브와 브라우저가 혼합된 애플리케이션입니다. 이렇게 웹과 애플리케이션이 혼합된 애플리케이션을 '하이브리드 애플리케이션' 이라고 합니다. 이런 모바일 애플리케이션을 수정하려면 어떻게 해야 할까요? 브라우저 위에서 돌아가는 부분은 서버에 있는 원본 HTML, CSS, JavaScript를 수정하면 바뀝니다. 이 부분은 보통 앱 화면이 뜰 때 바뀌죠. 반면 네이티브인 부분은 운영 체제별로 다른 프로그래밍 언어를 통해 수정한 뒤 심사를 신청해야 합니다. 심사 신청 뒤에도 사람들이 바뀐 애플리케이션으로 업데이트해야 하죠. 아무래도 시간이 오래 걸리고 까다롭습니다. 애플리케이션에 브라우저를 올리는 것과 네이티브로 개발하는 것의 장단점을 조금 더 살펴보죠. 이는 이전에 말씀드린 웹과 애플리케이션의 차이와 맥락이 닮았습니다. 먼저 브라우저를 통해 HTML, CSS, JavaScript를 가져와서 보여주는 방식의 장점은 수정하기 좋다는 점입니다. 서버의 HTML, CSS, JavaScript만 수정하면 따로 심사를 받거나 설치할 필요 없이 새로 고침할 때 반영됩니다. 하지만 네트워크에 종속되기 때문에 와이파이나 모바일 네트워크가 느린 공간에 가면 HTML, CSS, JavaScript를 모두 다운로드하는 동안 사용자들은 기다려야 합니다. 한 화면이 5~6초 동안 뜨지 않는다면 사용자 입장에서 매우 불편하다고 느끼겠죠. 사용하기 불편해지면 사람들은 떠날 수밖에 없습니다. 반면 네이티브로 만들면 수정하는 데 넘어야 할 산이 많다는 단점이 있습니다. 특히 iOS 심사는 큰 장벽 중 하나입니다. 더불어 심사가 끝나도 사용자들이 직접 업데이트를 해줘야 합니다. 사용자들 입장에서 너무 잦은 업데이트는 귀찮을 수밖에 없습니다. 물론 잘 만든 애플리케이션은 사용성이 좋다는 장점이 있습니다. 네트워크를 최소한으로 이용하도록 코딩한다면 인터넷이 느린 환경에서도 빠르게 동작합니다.
