주니어 서비스 기획자에게 필요한 진짜 개발 지식 (2)
아, 개발자가 한 말이 이런 뜻이구나
1편에 이어 데이터베이스, 프레임 워크, 협업과 관련된 이야기를 해보려고 한다.
(1편 https://brunch.co.kr/@newbyeol/11)
4. 데이터베이스와 이미지 처리
쇼핑몰에서 데이터라는 건 대체 뭘까요?
쇼핑몰에서 하는 행동을 포함해 쇼핑몰에서 일어나는 모든 활동이 데이터이다. 예를 들어 무엇을 클릭했는지, 어떤 페이지를 봤는지, 이 페이지 다음에는 어떤 페이지를 봤는지, 장바구니에는 뭘 넣었는지, 뭘 주문했는지, 어떤 페이지에서 창을 닫아버렸는지 이런 것들. 회원 정보, 유입 경로, 사용 디바이스, 구매 내역, 이동 경로 등등이 모두 데이터에 속하며 웹사이트는 이런 데이터를 수집해서 서버로 보낸다. 수집된 데이터들은 마케팅 퍼포먼스를 높이거나 새로운 기능을 기획할 때 등 회사가 필요한 상황에 따라 활용된다.
뿐만 아니라 요청-응답 과정을 통해 주고받는 것도 모두 데이터다. 예를 들어 쇼핑몰에서 특정 상품을 클릭했을 때 상품의 상세 정보나 이미지가 불러와지는 것은, 클라이언트에서 '데이터를 요청했기 때문에 서버에서 응답하여 정보, 이미지를 보내준 것'이다.
"클라(클라이언트)가 들고 있어요." "클라에 저장돼요"
이전 편에서 봤던 클라이언트-서버의 관계를 생각해보면 된다. 클라이언트에만 저장되는 데이터, 서버까지 전송되는 데이터가 다르다는 뜻이다. 서버까지 가지 않는 데이터는 그리 중요하지 않은 데이터, 중간에 없어져도 괜찮은 데이터다. 반대로 서버까지 가는 데이터는 요청-응답에 필요한 데이터뿐만 아니라 영구적으로 오래 저장해야 하는(=중요한) 데이터, 회사가 활용해야 하는 데이터(위에 언급한 데이터 분석에 활용)라고 보면 될 것 같다.
쉽게 이해하기 위해서, 스포티파이 앱을 이용해 노래를 들을 때를 생각해보자. 클라이언트=내 핸드폰이고, 서버는 스포티파이가 가지고 있는 서버다. 내가 스포티파이에서 노래를 다운받았다면 그 노래는 내 핸드폰(=클라이언트)에만 저장된다. 이건 그리 중요한 데이터는 아니다. 다시 없어져도 노래는 다운 받으면 되기 때문에. 즉, 내가 다운로드 받는 노래 자체는 스포티파이 서버까지 가지 않는다. (가는 게 더 이상하다) 반면, 내가 노래를 받기 위해 '다운로드'라는 버튼을 눌렀다는 데이터 자체는 스포티파이로 간다. 마찬가지로 어떤 노래를 스트리밍 할 때마다(재생 버튼을 누를 때마다) 내가 이 행위를 했다는 데이터도 서버로 넘어간다. 스포티파이는 이런 데이터들을 모아 데이터를 분석할 때 활용한다.
참고로 음원 다운로드와 스트리밍의 차이는 클라이언트가 데이터를 어디에 저장하느냐의 차이이다. 전 편에서 아주 살짝 언급했는데, 음원 파일은 장기기억장치(하드디스크)에 저장되지만 스트리밍으로 음악을 들을 경우 해당 파일은 단기 기억장치(램)에 저장된다.
"이미지 좀 바꾸려는데, 자꾸 자기한테 말하면 안 된대요"
우리가 보고 있는 웹사이트는 기본적으로 텍스트로 이루어진 문서이다. 이걸 HTML 문서라고 부른다. 가끔 컴퓨터를 하다 F12를 잘못 눌러서 뜨는 그 외계어 같은 텍스트들.(다들 한 번쯤 본 적 있을 것이다) 그것들이 웹을 이루는 근간이다. 그래서 클라이언트-서버 간 소통도 이 텍스트로 이루어진다.
서버는 이미지를 바로 보내지 않고 URL 형태로 보낸다웹에 업로드되는 이미지도 텍스트 형식의 URL로 표시되어 전송된다. 웹에 이미지를 올릴 경우, 보통은 서버에 이미지를 보낸다. 그럼 서버는 이미지를 받아서 저장한 후 이미지에 URL 주소를 부여하여 클라이언트한테 다시 보내준다. 이 때는 앞 편에서 언급한 JSON이라는 데이터 포맷 형태로 보내는 것이 일반적이다. 그럼 클라이언트는 텍스트 + 서버로부터 받은 이미지 URL을 가지고 소스를 짠다. 서버에서 클라이언트에게 데이터를 보낼 때 이미지 URL를 빼놓고 줬을 경우, 클라이언트 쪽에서는 이미지가 보이지 않는다. 이럴 경우 서버 개발자에게 이미지 URL 정보도 함께 보내달라고 하면 된다. 즉, 웹 개발자가 아닌 서버 개발자에게 요청해야 하는 부분이다.
또 다른 이미지 전송 방법은 CDN을 활용하는 것이다. CDN은 Contents Delivery Network인데 번역하면 '콘텐츠 전송 네트워크'이다. 네트워크(망)로 이루어져 있어서, CDN 서버에 이미지를 올려두면 사용자가 해당 이미지를 불러올 때 사용자와 가장 가까운 네트워크에서 이미지를 전송해준다.
예를 들어 내가 넷플릭스에서 영화 한 편을 보고 싶은데 이 영상을 보내주는 서버가 북미 어딘가에 있다고 생각해보자. 2시간짜리 무거운 콘텐츠가 북미에서 내가 있는 곳까지 오려면 시간도 오래 걸리고 중간에 자주 끊길 확률이 크다. 이를 방지하기 위해 북미에 있는 서버에서 데이터를 보내주는 대신, 내가 있는 곳과 제일 가까운 서버에서 같은 콘텐츠를 보내주는 것이 CDN이다. 이미지, 동영상과 같은 콘텐츠를 빠르고 안정적으로 제공하기 위해 사용하는 네트워크 서버라고 생각하면 된다.
5. 프레임워크와 라이브러리
프레임 워크 & 라이브러리
프레임 워크와 라이브러리는 기본적으로 '이미 만들어져 있는 것, 그래서 프로그램을 쉽게 만들 수 있게 도와주는 것'이라는 공통점이 있지만 주도성이 개발자에게 있느냐, 아니냐를 기준으로 차이가 있다.
프레임 워크는 개발자가 특정 프로그램을 개발할 때 따라야 하는 일종의 가이드라인이다. 이미 정해진 형식이 있고 개발자는 그 안에서 필요한 코드를 짜 넣는다. 앱으로 비유해보면 앱의 뼈대는 결정되어 있고 개발자는 그 안에서 보다 구체적인 앱 서비스를 구현하는 경우이다. 이케아에서 조립용 책상을 샀더라도 거기에 딸려오는 매뉴얼을 따르지 않으면 책상을 조립할 수가 없다. 이때의 조립 매뉴얼이 프레임 워크다.
라이브러리는 한 마디로 개발자가 갖다 쓸 수 있는 도구 모음집이다. 특정 프로그램을 개발할 때 자주 사용하는 코드를 쉽게 가져다 쓸 수 있게 묶어 놓은 집합이다. 개발자는 라이브러리를 써도 되고 쓰지 않아도 된다. 책상을 조립할 때 나한테 편한 공구를 골라 쓰는 건 내 마음인 것처럼.
코코아요? 먹는 거 아니에요?
코코아는 애플이 만든 여러 프레임워크의 집합이다. 맥 OS, iOS 환경에서 애플리케이션을 제작하기 위한 가이드라인 혹은 표준을 제공하는 프레임워크 정도로 생각하면 될 것 같다. UI 쪽 가이드라인도 제공한다고 하는데 그래서 iOS 앱 중 비슷한 UI를 가진 앱들이 있는 건가 보다.
6. 협업, 소스 관리, 디자인
Commit? Merge? 이게 뭐예요?
Commit, Merge를 알려면 Git을 먼저 알아야 한다. Git은 버전 관리 툴인데, 쉽게 말하면 개발자가 프로그램을 개발할 때 코드를 수정하고 더하고 빼는 등의 변경 사항이 모두 기록되는 폴더이다. 우리가 PPT를 만들 때, 내용을 수정, 추가, 삭제하듯이 개발자가 앱, 웹, 게임과 같은 소프트웨어를 개발할 때도 코드를 수정, 추가, 삭제하는 과정을 거치게 된다. 이 모든 변경 사항이 저장되는 게 Git이다.
특이한 점은, 변경 사항을 개발자가 각각 따로 저장하지 않아도 된다는 점이다. PPT를 만들 경우 각각의 수정 버전을 개별적으로 확인하고 싶다면 원본 ver, 수정 ver, 수정 ver2, final ver 등의 파일을 따로 저장해야만 한다. 하지만 Git은 그럴 필요 없이 같은 파일에 대한 여러 버전을 독립적으로 보관한다. 코딩 중 문제가 생겼을 때는 해당 문제가 생긴 버전을 찾아 수정하면 된다.
이때, 작업을 하다 '지금 이 시점까지 ~~~한 작업을 진행했다'라는 표시로 변경 사항을 저장하는 것이 commit이다. 그러면 마치 새로운 변경사항 전부를 스크린샷 찍듯이 박제된다. 이렇게 박제하는 것을 commit 한다고 한다. Ctrl+S를 누르는 것과 비슷하다.
또, Merge를 알기 위해선 Branch 개념을 알아야 한다. 주가 되는 코드, 내가 지금 작업하고 있는 큰 줄기를 메인 브랜치라고 부른다. 메인 브랜치에서 작업을 하다가 새로운 기능 혹은 디자인에 대한 아이디어가 생각날 경우, 가지를 치듯 새로운 브랜치를 생성해 따로 작업할 수 있다. 이때 새로운 브랜치에서 시도한 것을 기존 코드에 합치는 것 즉, 새로운 브랜치를 메인 브랜치에 합치는 것을 Merge라고 한다.
branch, Merge회사 서버의 Git서버나 Github와 같은 서비스를 이용하면 git에 저장된 내용을 공용 공간에 보낼 수 있다. 다른 개발자가 올린 내용을 다운 받고 내가 작업한 것을 전송하는 식으로 여러 개발자가 협업할 수 있는 것이다. 누가 어떤 작업을 했고 지금 시점에서 얼마나 진행됐는지 등을 확인할 수 있다.
Github는 git에 저장할 수 있는 공간을 제공하는 서비스 중 가장 널리 알려진 곳이다. Git을 올려둘 수 있는 곳 정도로 생각하면 된다. 전 세계 개발자들이 작업 중인 프로젝트의 코드를 올리기 때문에, 다른 개발자는 어떻게 코딩하는지 보거나 더 나은 방식은 무엇인지 등을 논의할 수 있는 공간이라고 한다. 비전공자가 봤을 때 Git, Github 모두 매우 흥미로운 내용이다. 이런 건 누가 어떻게 만드는 거지? 넘나 신기한 것.
둘이 싸웠나? 디자이너와 개발자가 부딪히는 이유
비단 디자이너, 개발자만의 문제는 아닐 것 같다. 함께 일하는 기획자도 다양한 갈등 상황을 맞이할 것이다. 광고 기획을 하면서 디자이너, 카피라이터, 기획자가 프로젝트를 바라보는 관점은 참 다르다는 걸 자주 느꼈다. 목표는 같더라도 하는 일이 다르니 당연한 거다. 기획, 디자인, 개발도 비슷할 것 같다. 각자 서비스를 만들 때 중점을 두는 부분이 다르고 실제 업무를 하며 마주치게 되는 문제 상황이 다르다.
예를 들어, 디자이너는 A 부분을 수정하고 싶다. 디자인 관점에서는 사소해 보인다. 개발자가 A를 수정하려고 보니 너무 많은 것을 바꿔야 한다거나 현재 프로젝트 구조상 넣기 어렵다는 걸 알게 되어 수정이 어렵다고 말할 것이다. 이것이 반복되면 '왜 안 된다는 거지?'로 이어질 수도 있다.
이 같은 갈등 상황을 상상해보니 기초 개발 지식, 디자인 지식이 기획자에게 얼마나 중요한지 알 것 같다. 갈등을 무조건 최소화하는 것이 답은 아니다. 마찰이 생겼을 때 올바르게 문제 상황을 파악하고 효율적으로 협의점을 이끌어내는 것이 중요하다. 원하는 결과물과 리소스 등을 균형 있게 고려하여 결국 최선의 방식으로 우리가 원하는 걸 만들어내는 기획자가 되어야 할 것 같다. (너무 교과서같지만... 너무 맞는 말...)
“아 그게 서버에서 이미지 URL을 보내줘야 하는데, API가 미완성인 것 같아요. JSON에 아이콘 URL만 빠져있네요. 클라는 URL이 안 오면 기본값이 뜨게 해 놨어요. 근데 제가 임의로 만들어서 좀 이상하게 보일 겁니다.”
처음에 이 문장을 봤을 때 정말 1도 이해를 못했었다. 한국어인데도 외계어 같았달까. 아직 갈 길이 멀고도 멀지만, 두 편에 걸쳐 간단한 개발 지식을 정리하면서 많은 것을 배웠고 이제는 미약하게나마 저 문장을 이해할 수 있게 되었다. 무작정 프로그래밍 언어를 배우는 것부터 시작했었다면 아마 금방 흥미를 잃고 제 풀에 지쳐 떨어져 나갔을 것이다. 이번에 포스팅한 글 두 편을 시작으로 차근히 또 단단히 기본기를 쌓아가면서 개발자, 디자이너와 원활히 소통하는 기획자, 생산적인 기획 환경을 만드는 기획자가 되고 싶다.
(이번 글에서도 마찬가지로 틀린 부분이 있다면 자유롭게 댓글로 남겨주세요. 부족한 글 읽어주셔서 감사합니다:). 내용 정리에 도움을 준 형준쓰, 나헌쓰, 태성쓰, 동우쓰에게 고맙다는 말을 전합니다...♥︎)
참고
생활코딩
유튜브 얄팍한 코딩 사전
https://private.tistory.com/22
https://galid1.tistory.com/191
