[ IT ] IT 용어 정리 5탄(9장)

안녕하세요. 녀기입니다!

 

오늘은 마지막 용어 정리입니다.

 

결국 올 것이 왔군요.

 

이 책도 이제 빠이빠이 입니다.

 

저의 훌륭한 지식 공급원이 됐겠죠.

 

(핥짝)

저는 이 포스팅을 마치고 책을 반납하고 오겠습니다!

 

그럼 시작❗

 

언제나 사전적 의미 출처는 위키백과!

 

(음 사전적 의미 출처가 위키백과라 조금 켕기는 느낌이 들 수도 있으니,

 

댓글에 반박문은 언제나 환영입니다~😊)

---

목차

1. 깃(Git)
2. 커밋(Commit)
3. 머지(Merge)
4. 브랜치(Branch)
5. UI(User Interface)
6. UX(User Experience)

---

1. 깃(Git) : 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 스냅샷 스트림 기반의 분산 버전 관리 시스템 또는 명령어

2. 커밋(Commit) : 저장소에 소스 코드의 일부 최신 변경사항을 추가함으로써, 변경사항을 저장소의 최상위 리비전의 일부분으로 만들어주는 것

3. 머지(Merge) : 버전 관리에서 버전 관리를 받는 파일들에 주어지는 여러 변경사항을 조화시키는 중요한 작업, 파일이 2개의 독립적인 브랜치에서 수정된 뒤 최종적으로 병합될 때 필수적, 결과물은 두 변경사항을 모두 담고 있는 하나의 파일 모임

4. 브랜치(Branch) : 버전 관리와 소프트웨어 구성 관리에서 버전 관리 하에 놓인 오브젝트(소스 코드 파일 또는 디렉토리)를 복제하는 과정 또는 복제된 오브젝트, 각 오브젝트는 별도로 병렬 수정이 가능하므로 이 오브젝트들은 구별이 됨

 

개발자가 돼 보는 상상을 해 봅시다.

 

회의를 통해서 "AAA"라는 기능을 추가하기로 했습니다.

 

저는 AAA 기능을 추가하고 1.0.0 버전으로 지었습니다.

 

그 다음 AAA 기능에 업그레이드 기능인 "AAAa" 기능을 추가하고 1.1.0 버전으로 만들었습니다.

 

아 순조롭군요. 다음 기능인 "AAB"를 추가하고 1.2.0 버전으로 만든 순간,

 

기획팀에서 연락이 왔습니다. AAB 기능을 안 쓰게 됐다는 군요....(마음이 아픕니다.)

 

기획이 바뀌는 일은 비일비재한 일이라고 하니 낙심하면 안 됩니다.

 

이제 저희는 무엇을 해야 할까요?

 

현재 1.2.0 버전의 코드를 1.1.0 버전의 코드로 돌려놔야 합니다.

 

근데 AAB 기능의 코드 1,000줄을 100개 파일에 나눠 넣어 놨습니다.

 

너무 끔찍합니다.

 

이를 문서 작업이라고 생각해 보죠.

 

새로운 내용을 추가할 때 '덮어 쓰기'를 하고,

 

만약 잘못 됐다면, 뒤로 되돌려서 수정합니다.

 

문제는 오래 걸릴 수도 있고, 100% 예전 버전으로 돌아간다는 보장이 없습니다.

 

그렇다고 최종의 최최종의 진짜 마지막 찐막 버전까지 여러 개를 만들기도 참 뭐합니다. 

 

파일 수가 많아지니까요.

 

100개 파일을 일일이 다 돌려 놓을 수 있을까요?

 

깃은 이런 문제를 해결해 줍니다.

 

깃을 통해 개발자들은 본인이 개발한 버전을 커밋합니다.

 

제가 개발한 버전의 변경사항이 저장되는 느낌입니다.

 

그리고 이 버전에 깃발을 꽂는다고 생각되죠.

 

1.0.0 버전을 만들 때 커밋, 거기에 1.0.0 깃발 하나.

 

1.1.0 버전을 만들 때 커밋, 거기에 또 깃발 하나.

 

1.2.0 버전을 만들 때 커밋, 깃발 또 하나.

 

깃은 이 깃발과 깃발 사이의 변화와 누가 언제 커밋했고, 어떤 부분을 바꿨는지 추적해 줍니다.

 

그리고 체크아웃(Check Out)을 통해 깃발이 꽂힌 부분을 옮겨 다닐 수 있습니다.

 

이것이 바로 깃의 주된 기능인 소스코드 버전 관리입니다.

 

저희는 1.2.0 버전의 깃발에서, 1.1.0 버전의 깃발로 옮겨 가면 됩니다. 

 

코드를 수정할 이유가 없죠.

 

 

다시 개발자의 상상으로 돌아가 봅시다.

 

회사는 내부적으로 큰 변화를 주기 위해 "CDE" 기능을 추가하기로 합니다.

 

거기에 취소했던 "AAB" 기능을 다시 넣기로 합니다.

 

즉, CDE와 AAB를 동시에 진행해야 합니다.

 

어떻게 할까요?

 

이 때 브랜치를 만듭니다.

 

1.1.0 버전에서 하나의 분기점, 브랜치를 만드는 거죠.

 

그 브랜치 버전에서는 CDE 기능을 개발하고,

 

분기점이 아닌 메인에서는 AAB 기능을 계속 만듭니다.

 

그 후, 둘을 머지(Merge)합니다. 하나로 합치는 것이지요.

 

만약 겹치는 부분이 있다면, 깃은 충돌(Conflict)을 알려주고, 그 부분을 보여줍니다.

 

그러면 그 부분을 수정하면 되죠.

 

물론 머지를 했다고 성공이 아니라 테스트를 해야 하며 어느 정도의 시간이 필요합니다.

 

어떤 분들은 그저 다른 부분을 각자 작업하면 되는 거 아니냐고 생각하실 수도 있습니다.

 

근데 그것이 마냥 그렇지만은 않습니다.

 

책에는 마케팅 기획서를 쓴다고 가정합니다.

 

3명의 마케터가 각자 다른 분야를 적습니다.

 

한 명은 소비자 조사 결과, 한 명은 프로모션 기획, 나머지는 기대 효과를 씁니다.

 

서로 겹치는 부분이 없고, 맥락이 잘 맞는다면 잘 합쳐지겠지만

 

실제로는 그렇지 않죠. 모든 분야라는 것은 유기적으로 맞물려 있으니까요.

 

개발자도 일종의 문서를 적는 사람이니, 하나의 프로젝트를 여러 명이서 함께 작업하면 같은 이슈가 발생할 수도 있습니다.

 

 

깃을 기반으로 한 원격 저장소가 있습니다. 깃허브(GitHub), 비트버킷(Bitbucket) 등이 있습니다.

 

로컬에서 작업한 뒤, 커밋을 하면 결과를 원격 저장소에 보내고, 그것을 다른 사람들이 다운 받을 수 있습니다.

 

구글 드라이브 같은 것이라고 생각하면 될 듯 합니다.

---

5. UI(User Interface) : 사람(사용자)과 사물 또는 시스템, 기계, 컴퓨터 프로그램 등 사이에서 의사 소통을 할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체를 뜻함, 사람들이 컴퓨터와 상호 작용하는 시스템

6. UX(User Experience) : 사용자가 어떤 시스템, 제품, 서비스를 직/간접적으로 이용하면서 느끼고 생각하게 되는 총체적 경험

 

개발자와 디자이너가 싸우고 있습니다.

 

디자이너가 포토샵이나 일러스트로 작업을 해 갔는데, 개발자는 수치를 알 수 없습니다.

 

각 요소의 너비나, 높이, 넓이가 x축/y축을 기준으로 얼마만큼 떨어져 있는지

 

수치를 하나하나 확인해야 하는 불편이 생깁니다.

 

그래서 시간이 오래 걸리고, 실수가 나오고, 원래 디자인과 다르게 나오는 경우가 생길 수 있습니다.

 

책임은 개발자가 지게 되죠.

 

이 때 개발자는 '가이드'를 요구합니다.

 

수치를 전부 기입해 달라는 것이었죠.

 

가이드가 나오게 되면 이제 책임은 디자이너가 집니다.

 

개발자는 수치대로 입력하기만 하면 되기 때문이죠.

 

근데 문제는 디자이너가 힘들어집니다.

 

디자인 작업을 하고, 각각의 사안에 대해 가이드를 만드는 것은 쉬운 일이 아니고

 

어느 정도 자세히 설명해야 하는지도 애매하게 되죠.

 

결국 결과물에 대한 수정이 많아지고 지연되고....

 

둘의 사이는 멀어져 갑니다.

 

 

이 둘의 사이를 멀어지지 않게 만들어줄 프로그램이 있습니다.

 

스케치, 재플린, XD 등 입니다.

 

디자인한 결과물의 수치를 프로그램이 보여줍니다. 

 

이미지 요소를 개발에 필요한 형식으로 다운로드하거나

 

해당 디자인을 위한 소스 코드도 추천해주고,

 

수정이 필요한 부분에 코멘트를 남길 수 있습니다.

 

 

스마트폰의 화면 비율은 대부분 다릅니다.

 

디자이너가 그 비율에 맞는 모든 디자인을 만들 수는 없습니다.

 

그렇기 때문에 클라이언트 개발자는 UI를 바라보는 감각이 중요해 계속 공부를 해야 합니다.

 

반대로 디자이너는 프레임워크에서 제공하는 가이드 문서를 어느 정도 숙지해야 합니다.

 

왜냐면 특정 프레임워크에서 자잘한 디테일을 구현할 수 없을지도 모릅니다.

 

프레임워크에서 구현 가능한 기능 이상의 것을 요구하기 힘들다는 것을 어느 정도 인지하고 있어야 합니다.

 

결국 두 전문가 사이에 정답은 없지만,

 

서로가 서로의 분야에 대해 어느 정도 지식이 있다면

 

이해 가능한 부분이 많아지기에 협업이 더 잘 될 가능성은 있을 것 입니다.

---

드디어 끝났습니다ㅠㅠㅠㅠ

 

완전 기본 중의 기본이 끝났네요!!

 

비전공자로서 가야할 길이 멀었지만

 

지도 정도는 쓱 훑어본 느낌이 납니다.

 

저는 항상 느끼는 것이

 

그 분야에 대해 안다는 것은

 

그 분야의 용어를 자유롭게 구사하는 것이라고 생각합니다.

 

(그것은 마치 마법 주문이라 생각했지만 실제로는 식당 주문이었을지도 모른다는 그런 느낌)

 

수학으로 따지자면 저는 이제 사칙 연산을 다 한 것이라 생각합니다.

 

이것을 기본으로 여러 학문을 익혀 나가야겠죠!

 

(재료 공부할 때는 미적분 열심히 했는데, 데이터 분야 오니까 선형대수와 통계를 해야 하는....😱)

 

공부는 끝이 없습니다.

 

원래 인생이 그렇죠 뭐....

 

얼만큼 버닝해서 하느냐에 차이겠지만ㅋㅋㅋㅋ

 

저는 그냥 꾸준히 해 보려구요.

 

스프린터보다는 마라토너의 느낌으로!!

 

인간이 야생에서 살아남을 수 있었던 이유 중 하나는 

 

다른 동물들보다 지구력이 좋다는 것이라고 하니까 저는 그것을 믿고 달리겠습니다!!

 

마지막이니 사담이 길어졌습니다.

 

이제 이것이 저의 정체성이라는 것을 받아 들여주시고

 

다음 포스팅에서 뵙겠습니다!!

 

그럼 뿅