학술 에세이 [인간파트]
개성을 찾는 인간 : Homo-proprietas [Personal color와 Running shoes 사례를 통한 개성 찾기]

* '호모프로프리에타스' 는 제가 만든 어휘입니다.

1. 당신은 개성 있는 사람인가요?

1-1. 무엇이 ‘개성적’인가?

『 내가 그의 이름을 불러 준 것처럼

나의 이 빛깔과 향기에 알맞는

누가 나의 이름을 불러다오 』 _ 김춘수, 꽃

현대와 같은 경쟁이 치열한 사회에 사는 많은 사람은 개성 있는 사람이 되기 위해 노력한다. 학교에서 친구를 사귈 때도, 취업을 위해 면접을 볼 때도, 연애와 결혼을 할 때도, 그 외 모든 순간에서도 말이다. 어떤 사람들은 본인의 개성을 잘 알고 삶에 활기를 더욱 불어넣기도 하지만, 어떤 사람들은 개성 있는 사람이 되어야 한다며 자신을 괴롭히기도 하고, 개성에 대한 고민 없이 그저 살아가기도 한다. 그렇다면 ‘개성’이란 무엇이며, 우리는 어떤 방식으로 개성을 찾을 수 있을까? 그 의미를 ‘남들과는 다른 독특함, 특별함’이라고 오인하는 뭍 사람들에게 필자는 더욱 적극적으로 접근해보자고 제안하고 싶다. 김춘수 시인의 「꽃」에서 볼 수 있듯이, 나의 ‘빛깔’과 ‘향기’, 또 그것에 알맞은 것. 개인을 명명할 수 있는, 개인이 지닌 ‘고유성’으로 돌아가자고 말이다.

사람에겐 누구나 그 사람이기 때문에 갖는 고유한 성질, 정체성이 있다. 개성을 찾는다는 것은 남들과는 다른 독특함을 개발하고 특별함을 추구하는 것이 아니라, 육체와 정신 등이 결합된 존재로서 자신의 진정한 내-외면을 찾아간다는 것이다. 그렇기에 다른 이들과 차별화되려 노력하지 않아도 된다. 내가 지닌 고유한 정체성을 찾아 내가 나인 것에 만족하고 내게 적합한 삶을 살아가면 되는 것이다.

1-2. 나를 찾을 수 있는 시대

‘아니 말은 번지르르한데, 나의 고유성을 대체 어떻게 찾으라는 거야? 아니, 찾을 순 있는건가..?’라고 생각한 당신! 걱정하지 마라. 지금은 충분히 나를 찾을 수 있는 시대이다. 본 글에서 다룰 개성은 ‘신체적’ 개성으로, 신체적 고유성과 같은 의미이다. 이는 본인에게 가장 적합하고 어울리는 것을 파악하고 인지할 줄 아는 것을 말하며 구체적으로는 신체 조건에 꼭 맞은 옷부터 화장품 색조, 신발이나 스포츠 제품, 머리카락 형태와 색, 장신구에 이르기까지 개인의 신체에 어울리는 모든 것을 말한다. 개인의 신체적 고유성에 어울리는 제품을 사용했을 때, 그의 고유성은 더욱 빛을 발한다.

산업구조 및 과학기술의 변화는 신체적 개성의 실현을 가능케 만들었다. 과거의 획일화된 상품군에서 선택의 폭이 넓어진 다양한 제품들과 개인 맞춤형 상품이 생겨났고, 한정적인 정보 공유에서 대량의 일상적이고 개인적인 정보 공유가 가능해졌다. 이처럼 현대 사회는 나에게 적합한 제품을 손쉽게 구할 수 있는, 나를 찾을 수 있는 시대이다. 그러나 모순적으로 나를 찾기 ‘어려운’ 시대이기도 하다. 다양한 사람들을 대상으로 내놓은 제품과 선택지가 너무 많아, 본인의 고유성을 파악하고 있지 못한다면 고유성을 빛내기는커녕 오히려 해칠 수 있게 된 것이다.

2. 개성을 찾는 인간, 호모 프로프리에타스

2-1-1. 무지에서 나오는 무관심

혹시 옷이 예뻐서 샀는데 막상 입어보니 색상이나 재질이 본인과는 어울리지 않는 느낌이 들어 그대로 옷장에 보관해둔 경험이 있는가? 만약 그렇지 않더라도, 어떤 종류의 옷을 입었을 때 매우 예쁜데 어떤 종류의 옷을 입었을 때는 은근히 별로였던 기억이 있을 것이다. ‘옷은 많은데 정작 입을 옷이 없어!’라는 ‘웃픈’ 이야기는 사실, 본인을 제대로 알지 못한 채 뚜렷한 기준 없이 옷을 구매했기 때문에 일어난 현상이다. 이는 비단, 옷에 한정된 이야기가 아니다. 여성이라면 다른 여성이 사용했을 때 너무 예뻐 구매한 화장품이 본인에겐 전혀 안 어울렸던 경험이 있을 것이고, 남성이라면 편하다고 소문난 유명 브랜드의 런닝화, 축구화가 자신에겐 불편했던 경험이 있을 것이다. 이처럼 다수의 사람은 다양한 부분에서 본인의 신체적 고유성에 대해 잘 알지 못하고 살아가며, 그러한 개념 자체에 대해 무지하다. 당신은 정말 ‘나’를 알고 있는가?

삶의 영위에 있어 본인의 개성을 찾아가는 과정은 중요하기에, 필자는 여기서 개성을 새롭게 정의하고자 한다. 개성은 특별한 무언가가 아닌 개인이 가진 고유성이다. 그리고 이를 찾으려 노력하는 사람을 「Homo Propríĕtas : 호모 프로프리에타스」 라 명명하겠다. 그리고 그 반대되는 개념으로, 고유성에 무지하고 무관심한 사람을 「Homo rúdĭtas : 호모 루디타스」라 정의하겠다. 호모 프로프리에타스란 라틴어로 사람을 뜻하는 Homo와 고유성, 개성, 특질, 특색을 뜻하는 Propríĕtas의 합성어이며, 호모 루디타스는 사람을 뜻하는 Homo와 무식, 무지, 경험 없음을 뜻하는 rúdĭtas의 합성어이다. 우리는 다양한, 다각도의 노력과 시간 투자, 이해를 통해 호모 루디타스에서 나아가 호모 프로프리에타스가 되어야 할 것이다.

개성을 찾아가는 과정을 돕기 위해 이제부터 개성을 알아보는 예시 두 가지를 설명해주려 하니 잘 듣고 당신만의 고유성을 찾아보도록! 자신에게 가장 적합한 색감, 재질, 기능이 무엇인지를 안다면 당신의 옷장에는 입고 싶은 옷이 넘치게 될 테니 말이다.

2-1-2. 나를 찾다, Personal Color – Personal color란 무엇인가?

먼저 개인의 고유한 성질 중 하나인 Personal Color를 알아보자. 퍼스널 컬러란 개인의 피부색에 어울리는 색상을 일컫는다. 옷이나 머리카락, 장신구, 화장품의 색상을 본인의 퍼스널 컬러에 알맞게 바꾼다면 쉽고 간단하게 본연의 아름다움을 찾아낼 수 있다. 퍼스널 컬러의 효과는 강력하며 비교를 통해 즉각적으로 알 수 있기 때문에 최근 몇 년동안 핫한 키워드였다. 그러나 다수의 사람은 ‘퍼스널 컬러’라는 개념이 존재한다는 것만 알고 있을 뿐 크게 신경 쓰지 않아 본인의 퍼스널 컬러를 모른 채 살아가고 있다. 심지어 퍼스널 컬러를 상술로 치부하는 사람도 있다.

위의 그림은 퍼스널 컬러의 예시를 잘드러내 준다.

퍼스널 컬러는 크게 ‘봄 웜톤’. ‘여름 쿨톤’, ‘가을 웜톤’. ‘겨울 쿨톤’ 의 네 종류로 나뉘며, 각 분류 하에 페일, 라이트, 브라이트, 비비드, 딥 등의 다양한 형태로 다시금 나뉜다. 개인의 피부색에 맞는 톤을 찾는 것도 중요하지만 신체에 바르거나 걸치는 모든 제품의 색상을 동일 계열의 톤으로 맞추는 것 또한 매우 중요하다. 다른 부분이 모두 웜한 톤으로 맞추어져 있다고 하더라도 한 부분이 쿨한 톤으로 되어있다면, 퍼스널 컬러의 효과는 크게 떨어지기 때문이다.

2-1-3. 나를 찾다, Personal Color – 개성에 맞는 Personal color 찾기

당신의 퍼스널 컬러가 무엇일지 궁금하지 않은가? 그렇다면 먼저 계절 별 톤은 어떤 특징이 있으며 어떻게 다른 것인지 살펴본 후, 정확히 퍼스널 컬러를 알수 있는 방법을 알아보도록 하자.

먼저 ‘봄 웜톤’ 이다. 만약 당신이 복숭아 빛의 밝고 노란 피부를 가졌으며, 밝은 갈색빛의 눈동자와 머릿결이 어울린다면 당신의 퍼스널 컬러는 ‘봄 웜톤’일 가능성이 크다. 봄 웜톤은 말 그대로 봄처럼 생기발랄하고 사랑스러운 분위기가 어울리는 사람으로, 봄의 색깔인 개나리색, 푸릇한 연두색, 벚꽃의 연 핑크색 등의 파스텔톤과 비비드한 색감이 잘 어울린다. 봄 웜톤의 사람은 쉬폰 소재의 가벼운 느낌의 옷이 잘 어울리며, 진하거나 어두운 느낌보다는 밝은 느낌의 헤어 컬러와 화장이 잘 어울린다. 연예인으로는 수지, 아이유, 설리, 이승기 등이 대표적인 봄 웜툰에 속한다.

다음으로 ‘여름 쿨톤’이다. 만약 당신이 핑크빛과 붉은빛이 감도는 피부를 가졌으며, 라벤더, 하늘색 등 노란기 없는 차가운 색이 잘 어울린다면 당신의 퍼스널 컬러는 ‘여름 쿨톤’일 가능성이 높다. 여름 쿨톤은 깔끔하고 시원하며 우아한 분위기가 느껴지는 사람으로, 모든 톤에 차갑고 회색 베이스가 섞인 색감에 찰떡이다. 여름 쿨톤의 사람은 차가운 파스텔 새틴 소재의 옷이 잘 어울리며, 옐로우 베이스의 헤어보다는 검은색이나 회색 헤어가 잘 어울린다. 연예인으로는 손예진, 김연아, 이영애, 이종석 등이 대표적인 여름 쿨톤에 속한다.

세 번째, ‘가을 웜톤’이다. 만약 당신이 황색 빛이 도는 피부와 머리카락을 지녔으며 음영, 색조 화장이 잘 어울린다면 당신의 퍼스널 컬러는 ‘가을 웜톤’일 가능성이 크다. 가을 웜톤은 카키, 버건디 등 가을을 연상시키는 차분한 분위기의 사람으로, 황색을 지닌 따뜻한 계열의 머리카락과 색이 잘 어울린다. 완연한 가을, 노랗고 불그스름한 낙엽이 흩날리는 길에 트렌치코트를 입고 벤치에 앉아있는 사람을 생각해보라. 상상 속의 트렌치코트가 굉장히 잘 어울리는 사람이 바로 가을 웜톤이라고 할 수 있다. 가을 웜톤의 사람은 성숙하고 지적이며 섹시한 이미지로, 어울리는 색깔 파레트가 넓어 ‘색조 깡패’로 불리기도 한다. 이효리, 전지현, 원빈이 대표적인 가을 웜톤에 속한다.

마지막으로 ‘겨울 쿨톤’이다. 만약 당신이 푸른빛이 도는 어두운 검정 머리와 눈동자가 잘 어울리며 흰 붉은 빛의 피부를 가졌다면 당신의 퍼스널 컬러는 ‘겨울 쿨톤’일 가능성이 높다. 겨울 쿨톤은 파랑, 흰색, 검정색이 잘 어울리는 묘한 뱀파이어 같은 시크하고 모던한 이미지의 사람으로, 블랙 헤어에 레드립, 핫핑크, 버건디와 같은 색감이 잘 어울린다. 겨울 쿨톤은 사계절 컬러중 한국인에게 가장 보기 힘든 유형으로, 연예인으로는 현아, 김혜수, 아이린, 차승원, 이수혁이 겨울 쿨톤에 속한다.

2-1-4. 나를 찾다, Personal Color – Personal Color 인지 전후의 사례 비교

봄 웜톤인 수지가 본인의 Personal 컬러에 맞게 메이크업을 하지 않았을 때와 했을 때의 비교 사진이다. 봄 웜톤에 해당하는 사람들은 앞서 설명했듯이 검정색 보다는 밝은 느낌의 헤어 컬러와 화장이 어울린다. 진한 스모키 메이크업은 봄 웜톤의 사람에게는 굉장히 어색하다.

여름 쿨톤인 손예진이 본인의 Personal 컬러에 맞게 메이크업을 하지 않았을때와 했을 때의 비교사진이다. 봄 웜톤은 까만 머리색이 어울리지 않았지만, 여름 쿨톤은 까만 머리색을 했을때 굉장히 고급진 느낌을 주는 것을 여실히 느낄 수 있다.

가을 웜톤인 한예슬이 본인의 Personal 컬러에 맞게 메이크업을 하지 않았을 때와 했을 때의 비교사진이다. 여름 쿨톤에게 어울렸던 블루 베이스의 화장과 흑발은 가을 웜톤에겐 독이다. 오히려 헤어와 화장에 갈색빛을 넣어 밝게 해주면 성숙하고 지적인 느낌이 물씬 살게 된다.

겨울 쿨톤인 현아가 본인의 Personal 컬러에 맞게 메이크업을 하지 않았을 때와 했을 때의 비교 사진이다. 겨울 쿨톤에게 노란끼 도는 오렌지 베이스의 메이크업과 헤어 컬러는 촌스러운 느낌을 준다. 흑발과 검정 의상, 레드 립을 발라줬을 때 오히려 겨울 쿨톤의 깨끗함이 빛나게 된다. 봄 웜톤인 수지가 본인의 Personal 컬러에 맞게 메이크업을 하지 않았을 때와 했을 때의 비교 사진이다. 봄 웜톤에 해당하는 사람들은 앞서 설명했듯이 검정색 보다는 밝은 느낌의 헤어 컬러와 화장이 어울린다. 진한 스모키 메이크업은 봄 웜톤의 사람에게는 굉장히 어색하다.

2-2-1. 나를 찾다, Running Shoes – 사이즈는 발 개성의 전부가 아니다

잠시 이 글을 보고 있는 눈을 아래로 내려 당신의 두 발로 시선을 옮겨보라. 그리고 이와 같은 질문에 답해보라.

‘당신의 발은 어떤 개성을 갖고 있나요?’, ‘당신의 개성에 꼭 맞는 신발은 어떤 신발인가요?’

이 질문에 발 사이즈만을 대답한 사람은 개성을 아는 초수, ‘호모 루디타스’, 발 사이즈와 함께 칼발, 평발, 발볼의 폭 등을 답한 사람은 중수, 기본적인 내용을 포함해 (과)내전, 중립, (과)외전 등을 말한 사람은 고수, ‘호모 프로프리에타스’라고 볼 수 있을 것이다. 본인의 족형에 적합한 신발, 런닝화를 신는 것은 달리기 선수뿐 아니라 일반인에게도 중요하다. 족형에 맞지 않는 신발을 신는 것은 사람의 발과 발목, 무릎과 고 관절 등의 신체 건강에 장기적인 악영향을 미치기 때문이다. 만일 당신이 특별한 운동을 하지 않는데도 발바닥과 발목이 자주 아프거나, 신발 밑창의 한쪽 부위만 빨리 닳는다면 당신은 적합하지 않은 신발을 신고 있을 가능성이 크다. 이 경우 하루빨리 본인의 족형에 맞는 신발을 찾아 신어야 한다.

과내전 또는 외전이란 무엇인가? 사람의 신체는 달릴 때 발이 땅에 착지함과 동시에 발목을 적당히 회전시킴으로써 그 충격을 흡수하고 원활히 달리게 한다. 이때 발목이 안쪽으로 과하게 회전하는 것을 ‘과 내전’이라 하며, 발목이 뻣뻣해 회전하지 못하고 발목의 바깥쪽으로 꺾이거나 충격을 주는 것을 ‘외전’이라고 한다. 최적화된 발을 가진 사람은 중립형 족형으로, 이들은 충격흡수에 딱 필요한 만큼만 발목을 회전시켜 발의 피로를 줄인다. 중립형 족형의 사람들은 시중에 판매되는 대부분의 신발을 신어도 무관하나, 과내전/외전 형의 사람들은 본인의 족형을 알고 적합한 신발을 찾아 신는 것이 중요하다.

2-2-2. 나를 찾다, Running Shoes – 개성에 맞는 Running shoes 선택하기

한국인들의 족형은 일반적으로 발 볼이 넓고, 살짝 평발이며, 약간의 과 내전을 가지고 있다. 과내전/중립/외전을 이해했다면 이제 자신의 발이 과 내전인지 외전인지, 아니면 축복받은 중립형인지 알아보도록 하자. 개인의 고유 족형은 아치 모양, 신발 마모 부위, 뛰는 자세의 관찰을 통해 알 수 있다.

1. 아치 모양을 통해 알아보기

발바닥에는 위로 움푹 들어간 ‘아치’가 있는데, 아치의 깊이가 깊을수록(높을수록) 과 외전 족형일 확률이 높으며 낮을수록 과 내전 족형일 확률이 높다. 아치 모양은 다음과 같은 간단한 2가지 테스트를 통해 알 수 있다.

먼저 핑거 테스트 방법이다. 똑바로 서서 손가락 3개를 발바닥의 아치 속으로 넣어보라. 손가락이 안으로 쑥 다 들어간다면 아치가 높아 과 외전일 확률이 높으며, 반 정도 들어가면 중립에서 살짝 과 내전, 손가락이 거의 들어가지 않는다면 평발로서 심한 과 내전이라고 보면 된다.

다음으로 발바닥 찍기 방법이다. 종이를 바닥에 깔고, 발바닥을 물에 적시거나 물감으로 칠한 후 종이를 밟아보라. 그 후 종이에 찍힌 자신의 발 모양을 확인한다. 가장 왼쪽 그림이 아치가 낮은 평발로서 과 내전일 확률이 높으며, 가장 오른쪽 그림이 아치가 높은 요족으로 과 외전일 확률이 높다. 중앙은 중립형이다.

2. 신발 마보 부위를 통해 알아보기

집에 있는 신발들, 특히 런닝화의 밑창을 확인해보라. 족형을 떠나서, 신발은 신을수록 뒷굽이 가장 많이 닳고 다음으로 앞굽이 닳는다. 그러나 과 내전이냐, 외전이냐에 따라 마모의 부위가 조금씩 달라진다. 그림의 색칠된 부분은 신발의 마모 부위를 나타내며, 파란색이 과내전, 분홍색이 중립형, 초록색이 외전 족형의 마모 부위이다.

간혹 신발의 뒷 쪽(아래쪽) 마모만 확인하여 과 내전을 외전으로 착각하는 사람들이 있으나, 뒷 쪽보다는 앞쪽 마모 부위로 확인하는 게 정확하다. 즉, 앞쪽 마모 부위가 안쪽이라면 과내전이며, 앞쪽 마모 부위가 바깥쪽이라면 외전형이라는 것이다.

3. 뛰는 자세를 통해 알아보기

아치 모양과 신발 마모 부위만 확인하여도 어느 정도 자신이 과 내전인지, 외전인지를 알 수 있으나 더 정확하게 알고 싶다면 뛰는 자세를 뒤에서 녹화하는 방법도 있다.

녹화된 영상을 슬로우 모션으로 보면 본인 발의 어느 부위가 지면에 먼저 닿고 어느 부위가 마지막에 떠나는지를 확인할 수 있을 것이다. 왼발의 모션을 나타낸 그림을 참고하자. 위-왼쪽의 경우가 외전 발이며, 뒷굽은 바깥쪽으로 착지하고 앞굽은 새끼발가락 쪽에 체중을 실어 딛는 것을 확인할 수 있다. 위-오른쪽의 경우가 과 내전이며 착지는 과 외전과 같이 바깥쪽으로 하지만, 앞 굽은 엄지 발가락쪽에 체중을 싣고 딛는 것을 확인할 수 있다. 지면에 많이 닿는 부위가 마모가 잘 발생하는 부위이기 때문에, 2번과 동일한 결과를 얻을 수 있다.

cf. 발 유형 별 조심해야 할 부상

[외전] 족저근막염, 정강이 부목, 발목염좌_ 왼쪽사진

[중립] 효과적 충격흡수로 인해 부상 가능성이 상대적으로 낮음_중간사진

[내전] 경골 부목, 족저근막염, 건막류, 발뒤꿈치 통증_오른쪽사진

2-2-4. 나를 찾다, Running Shoes – 개성에 맞는 런닝화 선별하기

생에 처음으로 자신 발의 개성을 알게 된 당신. 호모 프로프리에타스에 한 걸음 다가갔음을 느꼈다. 기쁜 마음으로 새 런닝화를 사기 위해 쇼핑을 하러 갔으나... 당신의 앞에 수많은 브랜드의 수많은 런닝화가 등장했다! 어떤 런닝화를 구매해야 할지 난감할 당신. 족형은 알았다. 그렇다면 좋은 런닝화는 어떻게 골라야 할까?

런닝화의 기본 구성은 크게 어퍼, 미드솔, 아웃솔로 나눌 수 있고, 런닝화 선택 시 체크해야할 요소로는 어퍼의 소재 및 착용감, 쿠션, 반발력, 안정감, 아웃솔의 유연성 및 내구성, 힐 카운터, 무게, 내구성, 힐 드롭 등이 있다. 각 부분마다 중요한 소재 또는 기능이 장착되어 있으며 어떤 재질을 쓰느냐, 어떤 기능을 우선하느냐에 따라 같은 부위더라도 그 쓰임새가 달라진다. 앞서 나열한 요소들은 모두 중요하지만, 이번에는 족형에 있어 특히 알아두면 좋을 부분들과 일반인들이 흔히 잘못 알고 있는 정보에 대해서만 집중적으로 다뤄보겠다.

1. 미드솔

미드솔은 어퍼와 아웃솔 사이에 있는 중창으로 크게 쿠션, 지지대, 반발력의 세 가지 역할을 한다. 대다수의 사람들이 나이키 에어, 아식스 젤, 미즈노 웨이브 플레이트와 같은 푹신한 쿠션이 있는 런닝화를 최고로 여기지만, 쿠션만큼이나 중요한 것이 바로 ’반발력’이다. 쿠션만 있고 반발력이 없는 신발을 신는다면 발바닥은 멀쩡하겠지만 피로가 빨리 찾아오게 된다. 반발력이 없기 때문에 발을 들 때마다 온전한 힘이 소요되기 때문이다. 너무 푹신한 쿠션이 있는 신발보다는 조금 딱딱하더라도 반발력 있는 신발을 선택하여야 한다.

2. 아치 서포트

평발을 가진 사람은 오래 달리지 못하며 심지어 군 면제 대상도 된다. 그 이유는 걷거나 뛸 때마다 아치가 무너져 발바닥에 극심한 통증을 주기 때문이다. 이것이 족저근막염이다. 만일 당신이 평발을 가졌거나 족저근막염이 있거나, 과내전 족형이라면 아치 서포트 기능이 필요하다. 그러나 아치 서포트에 사용된 지지대는 신발의 무게를 증가시키기 때문에 중립/외전 족형의 사람에게는 다소 불필요한 요소이다.

3. 아웃솔

러닝화 아웃솔의 여러 기능 중에는 ‘유연성’과 ‘안정감’ 이 있는데, 아웃솔이 유연하면 더욱 자연스러운 발 구르기가 가능하고 편안한 착용감을 주지만 지나치게 유연성만 강조하고 안정감을 무시한 러닝화는 되도록 구매하지 않도록 주의해야 한다. 특히 아웃솔 중앙의 안정감을 잡아주는 장치는 활동 시 신발의 좌우 뒤틀림을 막아주는 역할을 하는데, 이는 중립과 외전 러너에도 꼭 필요한 장치이다.

3. 글을 마치며

3-1. 호모 프로프리에타스로 살아간다는 것

호모 프로프리에타스의 의미는 ‘주체적인 삶을 염원하는 사람’과 맞닿아있다. 나만의 고유성을 찾으려 노력하는 과정과 그 결과는 주체적이며 자유로운 삶을 영위하기 위한 과정의 일부이다. 유행을 따라가기보다는 유행 속 나의 고유성을 찾는 것, 남들이 하라는 것을 하기보다는 스스로 판단하며 쟁취하는 것, 스스로를 충분히 이해하며 자신을 존중할 줄 아는 것. 이 모든 것은 자신에게 관심을 가지는 사소한 것으로부터 시작되고, 오늘 우리는 그 열쇠를 쥐었다. 주체적인 삶의 열쇠. 그것이 호모 프로프리에타스로 살아간다는 것의 의미라고 생각한다.

안녕하세요 :> 지금까지 Git 알아보기 문서에서 Git 에 대한 기본적인 내용들을 얼추 다뤄보았죠!

그래서 이번에는 Git 으로 실전에서 어떻게 협업을 하는지를 알아보려고 합니다. 프로젝트가 수행되는 과정을 처음부터 끝까지 함께 살펴볼텐데요. 이번 글에서 프로젝트를 수행하는 개발자는 2명(A, B)이라 가정하겠습니다. 

프로젝트 수행과정

수행 0. 기존에 Gitlab 을 이용해 A가 개발하고 있던 프로젝트에 B가 참여하기로 했습니다.

수행 1. 먼저 A 가 B 를 프로젝트에 초대해야겠죠. A는 Gitlab의 프로젝트 페이지 -> settings -> Members -> select members to invite 란에 B의 계정 혹은 이메일을 입력하고 Add to project 를 누릅니다.

수행 2. A는 해당 페이지의 하단 부분의 Existing members RacingGround 에서 프로젝트에 대해 B가 가지는 권한을 수정합니다.

Gitlab 에서는 프로젝트에 참여하는 권한에 대해 멤버 별 여러 등급으로 나누어 관리가 가능합니다.

디폴트값은 가장 낮은 등급인 Guest 인데요, 이 등급으로는 프로젝트에 제대로된 참여가 불가합니다. 프로젝트에 개발자로 참여하려면 최소한 Developer 로 권한을 수정해주어야 합니다. 

참고로, A 의 등급인 maintainer 는 프로젝트에 대한 모든 권한을 갖고있는 최상위 등급을 말합니다. 

* 잠깐! 알고가기 Fork 가 뭘까?

Git을 이용해 협업을 할 때, 크게 두 가지 방법론이 있습니다.

1. Git clone 을 통해 gitlab 서버의 프로젝트를 팀원의 컴퓨터로 복사해와서 코드를 작성하고, git push

이 방법은 기존에 저희가 알아보았던 방법이죠. 이 방법의 단점은, 개발자가 만든 소스코드가 바로 프로젝트의 소스코드에 병합된다는 것입니다. 한 명의 개발자가 만든 소스코드가 늘 완벽하기란 불가능 하지요. 그래서 이 방법은 실전에선 거의 사용되지 않습니다.

2. 원래 프로젝트(원본프젝)와 똑같은 프로젝트(복제프젝)를 gitlab 서버의 팀원의 계정 아래에 별도로 카피해 생성하기.

보통 실전에서는 이 방법을 사용합니다. 원본프젝을 복제해 복제프젝을 내 계정에 갖다두고, 복제프젝을 git clone 으로 내 컴퓨터에 가져온 다음, gitlab 서버의 복제프젝에 git push 를 하는 방법입니다. (주의 : 원본프젝에 push가 아닙니다)

이렇게 내 계정의 복제프젝에 업로드가 되면, 이후 원본 프젝에 merge request 를 합니다. merge request 란, 작업물이 완성되었으니 확인하고 이상이 없다면 우리 프로젝트에 반영해달라고 요청을 하는 것입니다. 이후 프로젝트의 관리자가 해당 merge request를 확인하고, 이상이 없다면 승인, 혹은 거절을 합니다.

자 그러면, 다시 프로젝트 수행과정으로 돌아갑시다.

수행 3. B는 지금까지 A 가 한 최신의 커밋을 가져오기 위해, 웹페이지의 프로젝트의 상단부에 있는 " Fork " 란을 누릅니다.

그러며 Fork Project 창이 뜨는데요, 누구의 계정에 Fork 할지 선택합니다. 이렇게 하면 원본프젝과 동일하지만 별개의 프로젝트인 나의 복제프젝이 생성됩니다. 

수행 4. B는 생성된 내 계정의 복제프젝을 git clone으로 내려받고 확인합니다.

B가 하는 수행4의 세부 과정 예시는 이렇습니다. (VScode 터미널에서 실행한다고 가정)

- cd .\desktop\ : 바탕화면으로 이동

- mkdir {만들 폴더명] : 프로젝트 디렉토리를 넣을 폴더 생성

- cd {폴더명} : 생성한 폴더 안으로 들어가기

- git clone {복제용 프로젝트의 url} : B의 계정에서 gitlab 서버의 (복제)프로젝트를 받아옵니다. (복제프젝은 원본프젝에 비해 사용자 이름부분만 다릅니다.)

- 정보를 요구하는 창에 아이디와 암호를 입력합니다.

- ls : 해당 폴더에 잘 clone 되었는지 디렉토리를 확인합니다.

- cd {이동할 폴더명} : clone 한 프로젝트의 폴더로 들어갑니다.

- git log --all --graph : 지금까지 A가 만든 branch를 확인합니다.

수행 5. B는 커밋을 작성한 후, 자신의 계정의 복제 프젝에 올립니다.

- git checkout develop : master branch에 위치한 HEAD를 develop branch 로 옮깁니다.

- git config user.name {B의 이름} : 커밋을 누가하는지 기재해줍니다.

- git config user.email {B의 이메일} : 커밋한 사람의 연락처를 기재합니다.

<< B가 작업1 시행 >>

- git add . develop : develop branch의 staging area에 새로운 파일을 추가합니다.

- git commit -m {"파일1이름"} : staging area에 넣은 파일들을 커밋합니다. (develop branch에 커밋됩니다)

<< B가 작업2 시행 >>

- git add . : staging area에 새로운 파일을 추가합니다.

- git commit -m {"파일2 이름"} : staging area에 넣은 파일들을 커밋합니다.

- git push : gitlab의 B계정의 복제프젝에 지금까지 커밋한 내용을 반영합니다.(현재 헤드는 develop branch를 가리키고 있습니다. 자동으로 develop branch에 해당하는 신규 커밋들만 복제용 프젝에 업로드 됩니다. 여기서, 그 외의 것도 모두 업로드 하고싶다면 개별적으로 지정해줘야 합니다. 예를 들어, master branch도 업로드 하고싶다면 git push origin master 라고 하면 됩니다.)

수행6. B는 gitlab 서버에서 merge request를 요청합니다. 

- gitlab의 복제프젝 페이지에 가서, Create merge request 버튼을 클릭해 요청합니다.

- 바로 뜨는 New merge project 창에서 Change branches 를 눌러 업로드할 branch를 변경합니다. 아래의 그림에 보이는 From ~ into ~ 를 확인하고 변경해주면 됩니다. 현재 원본프젝의 master branch로 되어있는데, develop으로 변경합니다.

- Title 과 Description 란에 지금껏 작성한 커밋에 대한 설명을 적습니다. merge request 를 적는 규칙은 회사마다 다릅니다. 이후 Assignee 를 설정해 내가 한 merge request 를 가장 먼저 점검할 담당자를 지정해줍니다. 이 경우 A를 지정해주면 되겠지요. (이후 나오는 Milestone 과 Labels 는 일단 넘어가겠습니다.)

- 페이지의 하단에서 신규 commit 들과 commit으로 인한 변경 사항을 확인하고 submit 합니다.

수행7. A는 gitlab 페이지에서 B가 보낸 request를 확인합니다. 커밋과 체인지에서 변경사항을 한눈에 확인할 수 있으며, merge request 에 대해 논의하고 싶다면 discussion 카테고리에 질문을 남기면 됩니다. 이후 B가 확인하고 답장을 해주겠죠?

수행8. A는 논의 및 검토가 끝난 후 Merge 버튼을 누릅니다. 원본 프로젝트를 확인하면, B가 올린 커밋들이 새롭게 업로드 된 것을 확인할 수 있습니다. B의 커밋과 함께, 새로운 커밋이 만들어진것도 확인할 수 있죠. 다른 복제본 프로젝트에서 보낸 매 Merge Request 마다 그에 대응되는 Merge commit이 생성되기 때문에, 우리는 정확한 이력을 파악할 수 있습니다.

MergeRequest 정책

여기서 한 가지 의문이 들 수 있는데요, B가 업로드 한 branch에 대해 Fast-Foward merge 를 하면 되는데, 왜 굳이 새로 커밋을 생성하였는가 하는 것입니다. Fast-forward 머지를 할 수 있는 경우에도 새 Merge Commit을 만들게 되면 커밋 히스토리의 가독성이 다소 떨어지게 되겠지요.

새로운 커밋을 생성할지, Fast-forward merge를 할지는 적용한 MergeRequest 정책에 따라 달라집니다.

gitlab 페이지의 settings 카테고리에 가면, MergeRequest 설정 부분을 확인할 수 있는데요. 

위의 그림을 보면, 현재 merge commit 정책이 적용되어있는 것을 볼 수 있습니다.

Merge commit 정책은 어떤 경우라도 항상 merge를 할 때, 새로운 commit 을 생성하겠다는 것입니다. 

맨 아래의 Fast-forward 정책을 선택하면, Fast-forward merge 가 가능할 때 새로운 commit을 생성하지 않고, 실제로 fast-forward merge 를 해줍니다. 이외 나머지 두 정책은 fast-forward 가 가능해도 항상 새로운 merge commit을 생성합니다.

더 알아보기

git push 를 해줄때, 내 commit이 gitlab의 원본 프로젝트를 포함하지 않는다면 push가 되지 않는다고 했었죠. 

그러면, 그런거에 상관없이 지금까지 gitlab 서버에서 진행된 commit log 들을 내 컴퓨터에 있는 commit log로 몽땅 덮고 싶을땐 어떻게 해야할까요? 

그런 경우엔 git push --force 명령어를 입력해 강제로 업로드를 해주면 됩니다. 이 명렁어는 내 commit이 gitlab 프로젝트의 commit을 다 포함하지 않더라도 무조건 push 해라 라는 명령어 입니다.

사실 이 명령어는 실무에서 절대 쓰지 않는다고 볼 수 있습니다. 만일 불가피하게 사용할때는 반드시 주의하시길 바랍니다.

오늘의 포스팅이 git을 이용해 협업해보려하는 초보 분들께 도움이 되었으면 좋겠네요.

다음 글에서는 기타 Merge 정책 이해, Git Rebase 해보기, Detached HEAD 이해하기 등의 내용을 다뤄보겠습니다.

감사합니다.

Branch 란 ?

Branch 란 우리말로 나뭇가지, 분기된 흐름 등의 뜻을 가진 단어이죠. 깃에서는 특정 커밋을 가리키는 '포인터'를 의미합니다. Branch는 최신 커밋을 가리키는 흐름이며, 하나의 프로젝트에서 특정 목적으로 서로 다른 개발 흐름을 병렬적으로 가져가기 위해 사용합니다. 이러한 브랜치를 통해 여러 개발자 혹은 여러 개발팀이 한 프로젝트의 세부 과제를 병렬적 진행하며, 각 목적에 맞는 개발 흐름을 관리할 수 있습니다.

위의 그림처럼, master branch(기본으로 셋팅되는 main branch) 에서 개발 분야를 feature-A 와 feature-B로 나눠 각각의 팀이 개발을 진행하기로 했을 때, branch 를 나누어 관리할 수 있는 것이죠. branch는 나누거나 합치기가 가능합니다.

 git log를 입력할 때, HEAD -> master 라는 문구를 보셨을겁니다. master 란, 앞서 말했듯이 Master branch 의 master 이고, 현재 3번째 커밋을 가리키고 있는 것을 알 수 있습니다. HEAD 는 branch를 통해 특정 커밋을 가리킵니다. 즉, 여기서 master branch를 통해 3번째 커밋을 가리키는 것 입니다. 

지금 깃 랩 서버에 연동시키지 않은 상태라 보이지는 않지만, 깃 랩 서버(이름 : origin)에 연동하게 되면 origin/master 라는 붉은 단어가 뜨는데요, 이것은 깃 랩 서버에 존재하는 master 브랜치를 의미합니다. 만약, HEAD -> master, origin/master 라고 되어있디면 지금 컴퓨터의 master branch 와 gitlab 서버의 master 브랜치가 모두 3번째 커밋을 가리키고 있다는 의미이죠.

Branch 만들어보기

1. 한 갈래로 나누기

git branch {branch_name} 입력

git branch develop 를 입력해 develop branch를 생성해주도록 하겠습니다.

기존에 있던 master branch 에 더해, develop branch 가 생겼네요. branch 를 생성할 때는 나누기를 원하는 기점(커밋)으로 이동해 HEAD를 옮겨주고 생성해주면 됩니다. 

보통 master branch 에는 배포할 정도로 완성된 커밋들만 넣고, develop branch 에는 개발하는 중에 사용할 커밋들만 넣습니다.

커밋 간 HEAD를 옮기는 법은 살펴봤는데, 브랜치 간 HEAD를 옮기려면 어떻게 해야 할까요?

git checkout {branch_name} 을 입력해주면 됩니다.

git checkout develop 를 입력해주면,

HEAD 가 develop branch 를 가리키는 상태로 바뀐 것을 확인할 수 있지요. 이 상태에서 commit 하면 이제 새 커밋들을 develop 브랜치가 가리키게 됩니다.

지금까지 순서를 정리해보면, 분기점이 될 커밋으로 이동해 Branch 생성(git branch), 해당 Branch로 HEAD 이동(git checkout), Branch 에서 commit(git add, git commit) 로 정리할 수 있겠습니다. 위의 코드를 보면 분기점이던 세번째 커밋을 포함한 이전은 master branch 에, 이후의 커밋은 develop branch 에 속해있는 것을 볼 수 있죠. 나무의 기둥에서 뻗어나온 나뭇가지 같습니다. 이렇게, 병렬적으로 나눠서 개발할 필요가 있을때 각 작업에 별도의 브랜치를 할당해줌으로써 수행이 가능해집니다.

지금까지는 master branch 에서 다른 한 갈래로 뻗어나가는 branch를 다뤄봤는데요, master branch 에서 두 갈래로 나뉘어 버전관리를 하는 것도 실습해볼까요?

2. 두 갈래로 나누기

우리가 지금까지 만든 코드에, attack method 와 defend method 를 추가 개발할 것이라 해봅시다. 그리고 각 method 는 다른 팀이 하나씩 맡아 개발하여 관리할 것입니다. 

그러면 분기점이 될 가장 최신 커밋으로 HEAD를 이동하고, feature-attack branch 와 feature-defend branch를 생성해주면 되겠지요. 그리고 attack method를 담당하는 팀은 HEAD를 feature-attack branch 에 이동시켜 attack method 소스코드를 커밋해 버전을 관리하고, defend method 를 담당하는 팀은 HEAD를 feature-defend branch 에 이동해서 defend method 소스코드를 커밋해 버전을 관리하면 될 것입니다. 

3. 모든 branch 확인하기

이 때, attack method를 맡아 작성하는 팀은 HEAD가 attack branch에 가있을때 defend branch 의 내용이 보이지 않습니다. defend method를 맡아 작성하는 팀도, HEAD가 defend branch에 가있을때 attack branch 의 내용이 보이질 않죠. (master branch의 내용을 보입니다.)

위의 코드를 보면, HEAD가 feature-defend 로 가있을때 master branch와 defend branch의 commit log는 보이지만, feature-attack branch가 보이지 않는 것을 확인할 수 있습니다. (현재 attack method 가 커밋된 상태입니다)

만약, 현재 내가 있는 branch 가 아닌 모든 branch를 보고싶다면 기존의 git log 에 다른 옵션을 추가해 명령해주어야 합니다.

git log --all --graph 입력

--all 은 HEAD 가 가리키는 branch 뿐 아니라 모든 branch를 보겠다는 명령어입니다.

--graph 은 브랜치와 커밋간의 관계를 그래프 형식으로 보여달라는 명령어 입니다.

해당 명령어를 입력해보니 왼편에 나무와 비슷하게 생긴 graph가 생긴 것을 볼 수 있습니다. develop branch 에서 두 갈래로 갈라져 있는 것을 확인할 수 있고, 모든 branch 가 보이지요.

개발 실무에서는 여러 작업을 분담해 처리하기 위해 보통 develop branch 에서 여러 개의 하부 branch 를 생성할때가 많습니다. 그리고 하나의 branch 위에서 팀이 버전을 관리하며 작업해가는 형식이지요.

4. branch 의 병합

이제 각 branch 의 개발이 끝나고, 각각의 feature 브랜치에서 했던 작업을 병합하고 싶습니다. (즉, develop branch에 작업의 결과를 모두 반영하고 싶다는 것입니다) 그러면 어떻게 병합해야 할까요?

먼저 develop branch(결과를 반영하고싶은 branch) 로 이동합니다.

git merge {합쳐주고싶은 branch이름} 입력

git merge feature-attack 을 입력합니다. 이 명렁어의 의미는, HEAD 가 가리키고 있는 브랜치(현재 develop)에 feature-attack 에서 했던 작업을 병합해달라는 것입니다. 보다 상세하게는, 1. 현재 HEAD 가 브랜치를 통해 가리키고 있는 커밋 과, 2. merge 뒤에 쓴 브랜치가 가리키고 있는 커밋을 합쳐달라는 것입니다.

HEAD 가 가리키던 develop branch 와 feature-attack bracnh 가 병합된 걸 알 수 있습니다. 특히 develop branch 의 위치가, six commit 에서 Add attach method 의 위치로 이동해온 것을 볼 수 있는데요, 이 경우를 Fast-Foward Merge 라고 합니다. 

Merge 로 branch 가 병합되는 경우에는, 두 가지의 경우가 있습니다. 

- 기존의 branch(develop)가 merge를 당하는 branch까지 쭉 당겨져 오는 경우

- 두 branch를 병합한 새로운 커밋이 생성되는 경우

이 중 전자의 경우를 Fast-Foward Merge 라고 하는 것이지요.

Comfilict 발생시 대처

feature-attack branch의 병합을 완료했으니, 이제 feature-defend branch 도 병합해줍니다.

그런데, 이런! 병합 중에, 오류가 발생했습니다.

Auto-merging myfile.txt CONFLICT (content): Merge conflict in myfile.txt Automatic merge failed; fix conflicts and then commit the result.

이러한 오류 문구가 발생한 이유는, merge 중 충돌이 발생했기 때문입니다.

그림을 보면, feature-attack branch 와 feature-defend branch 의 일부 소스코드(attack 와 defend) 가 같은 라인에 위치해있다는 것을 볼 수 있지요. 여기서 문제가 발생합니다. 파이썬이 같은 라인에 다른 코드를 병합하려다보니, 어떤 라인을 선택해야 할 지 모르겠다는 것입니다. 이게 conflict 오류 발생의 원인이 됩니다. 이 경우에 파이썬은 각 파일에 표시를 남겨줍니다. 

해결법은 간단한데요, 파일에 파이썬이 남겨준 오류 코드를 확인하고, 이 파일이 가졌으면 하는 최종 코드를 남겨두면 되는 것입니다. 예시의 경우처럼 둘 다 남기고 싶다면, 필요없는 부분을 지우고 원하는 코드의 모습으로 고쳐주면 됩니다. (괄호 수정)

코드의 수정이 완료되었다면, git add . 와 git commit 명령어를 사용해 커밋하면 되는 것이지요.

 이제 각 branch 들이 develop branch로 합쳐지면서 새로운 커밋이 만들어진 것을 볼 수 있습니다. merge를 할 때, 새로운 커밋이 만들어지느냐 Fast-Forward merge가 발생하느냐는 대개 "흐름의 분기"의 차이에서 발생합니다. 가령, 기존 branch 와 병합하고픈 최신 branch 의 로그가 직선 모양으로 앞뒤로 위치한다면 merge를 할 때 최신 커밋을 가리키는 쪽으로 이동합니다.(Fast-Forward) 그러나 흐름이 중간에 갈라진 branch 끼리를 merge하면 새로운 commit 이 하나 더 생기는 것입니다.

point

저번에 branch 관련 내용이라며 넘어간 코드를 한번 살펴보죠.

git push -u origin master

이 명령어를 기억 하시나요? gitlab 서버에 프로젝트를 올리라며 push 해주는 명렁어라고 했었지요.

사실 이 명령어를 더 자세히 설명하자면, master branch 를 origin 이 의미하는 gitlab 서버 프로젝트에 올리라는 뜻입니다. push 나 pull 은 "branch 단위"로 작업이 이루어집니다. 즉, push 나 pull 뒤에는 branch 의 이름이 적혀집니다.

가령 git push -u origin develop 하면 gitlab origin 서버에 develop 브랜치가 올라갑니다.

-u 는 "--set-upstream" 의 약자로, 내 컴퓨터의 master branch가 항상 gitlab서버의 master 브랜치를 바라보게 하라는 의미입니다. 그래서 처음에 저렇게 적어주면, 이후 push를 할 때 git push 라는 간단한 명령어만 사용하면 되는 것이죠.

오늘 살펴본 branch 는 깃 전체를 관통하는 내용입니다.

branch가 무엇일까? 왜 필요할까? 어떻게 병합할까? 어떻게 외부 저장소에 올릴까?  등을 잘 알고 있어야 합니다.

생각보다 글이 조금 길어져서 원래 쓰려고 한 다른 내용을 못 썼네요.. 글이 너무 길면 읽기 부담스러우니..^^;

다음 글에서는 프로젝트의 전반적인 과정에서 git과 gitlab 을 어떻게 쓰는지, Fork/Clone, MergeRequest하는 법 등 실전편을 가져오도록 하겠습니다.

저번 시간에 우리는 작업에 대한 이력을 내 컴퓨터에 남길 수 있는 commit 하기를 알아봤습니다.

우리가 commit 하는 이유는 뭘까요? 작업 이력을 남겨두고, 원하는 시점으로 자유롭게 돌아다니기 위해서라고 할 수 있죠.

이번에는 저장한 commit 간 이동하는 방법에 대해 알아보려 합니다.

그리고 외부 저장소에 push/pull 해보는 것까지 다뤄보도록 하죠!

Git history 관리 방법

저번에 git log 를 통해 본 커밋 이력에서, HEAD 란 문자를 본 적이 있으실 겁니다.

HEAD 는 현재 내가 위치해있는 커밋을 가리키는 식별자 입니다. 보통 가장 최신의 커밋을 가리키고 있죠.

커밋과 커밋을 이동할때는 git reset 을 사용해줍니다.

1. 커밋 간 이동하기 

git reset --{option} {commit_id} 입력

예시로, git reset --hard 8564 를 입력해주면, 워킹 디렉토리의 모습이 HEAD 가 가리키는 commit 의 모습으로 변하는 것을 확인할 수 있습니다.

git reset 명령어를 이용해, 우리는 언제든지 원하는 커밋으로 돌아갈 수 있는 것입니다.

명령어 중 --hard 의 부분은 옵션인데요, 옵션에 따라 working directory, Staging Area, Repository의 지정 커밋이 바뀝니다. 가령 위의 예시에서 워킹 디렉토리가 함께 바뀌는 이유는 hard 를 옵션으로 설정해주었기 때문입니다.

조금 헷갈리시나요? 옵션 별 차이를 간단하게 정리해보겠습니다.

2. 옵션 별 차이 

- 공통 : Repository 에서 Head 가 특정 commit을 가르킴.

- Hard : Staging Area 와 워킹 디렉토리가 특정 commit 으로 바뀜.

- Mixed : Staging Area 가 특정 commit 으로 바뀌나, 워킹 디렉토리는 바뀌지 않음 (가장 최근 커밋으로 유지)

- Soft : Staging Area와 워킹 디렉토리가 바뀌지 않음 (가장 최근 commit 으로 유지)

그렇다면 soft, mixed 옵션은 언제 사용하면 유용할까요?

예를 들어, 팀원A가 커밋1~6 을 만들었습니다. 그리고 지금은 워킹 디렉토리에서 커밋 6 에 대해 많은 작업을 했습니다.

작업을 하고나니 커밋 1~3은 괜찮지만, 4~6 은 너무 조금씩만 고쳐서 굳이 업로드 하지 않아도 될 것 같습니다.

이런 경우에, mixed/soft 옵션을 사용해서, 현재 작업한 워킹 디렉토리의 내용을 남기고 커밋3으로 이동합니다.

이 상태에서 커밋을 새로 하게 되면, HEAD 가 가리키는 커밋3 위에 새로운 커밋6이 쌓이기 때문에 불필요한 커밋을 없애고 필요한 커밋만을 보여주는 것이 가능합니다.

위의 그림을 보면, mixed/soft 옵션을 사용해 HEAD 만을 변경하고 커밋해 커밋7을 올리는 과정을 알 수 있지요.

git reset 의 옵션 중, hard 옵션을 사용할때는 특히 주의해야 합니다.

hard 옵션은 워킹 디렉토리를 다른 커밋의 버전으로 바꿔주기 때문에, 자칫하면 워킹 디렉토리에서 새롭게 작업하던 내용이 다 날라갈 수 있기 때문입니다.

3. 추가적인 명령어

- git status 

git status 는 파일 상태를 알아볼 수 있는 명령어 입니다. 아래의 코드를 볼까요?

캡쳐에 포함되지 않아서 보이지 않지만, 제 디렉토리의 커밋1(이름 : 8564) 에는 BasicCar1 파일이 있고, 커밋2(이름 : aa08) 에는 현재 BasicCar1 파일과 BasicCar2파일이 있습니다.

코드를 보면 가장 처음에 hard 옵션을 이용해 커밋2의 워킹 디렉토리와 스테이징 공간을 불러왔습니다. 그리고 mixed 옵션을 이용해 커밋2의 워킹 디렉토리를 그대로 둔 채 커밋1의 스테이징 공간만을 불러왔죠. 이 때, git status를 입력해 파일의 상태를 알아보면, 빨간색으로 BasicCar2.js 파일의 이름이 나타나며, 커밋되지는 않았지만 워킹디렉토리에 있다. 커밋할거면 get add 명령어로 커밋해라고 말해줍니다. 즉, 워킹디렉토리에는 이 파일이 있는데 스테이징 공간에 없다는 것입니다. 당연하겠죠? 왜냐면 커밋1의 스테이징 공간에는 BasicCar2.js 파일이 없으니까요! 

다음으로 다시 hard 옵션을 사용해 커밋2의 워킹 디렉토리와 스테이징 공간을 불러옵니다. 그 후 soft 옵션을 이용해 다른것을 그대로 둔 채 HEAD 가 커밋1을 가리키도록 하였죠. 이 때 git status 를 입력해 파일의 상태를 알아보면, 초록색으로 BasicCar2.js 파일의 이름이 나타납니다. 워킹 디렉토리에도 있고, 스테이징 아리아에도 있으니 이렇게 나타나는 거지요.

이제 각 옵션들의 차이, 그리고 git status 의 기능이 조금 이해가 되시나요?

- git reflog

일전에 알아본 git log 는 사실, HEAD 가 가리키는 커밋을 기준으로 그 이전에 커밋한 이력만을 보여줍니다.

그러면 문제가 있죠. 만약 내 디렉토리에 커밋1, 2, 3 이 있는데, git reset 명령어를 이용해 커밋1 로 갔습니다. 그리고 이제 커밋3으로 다시 돌아가고 싶어요. 그러면 커밋3의 이름을 어떻게 알죠? git log 명령어를 이용해도, 지금 나는 커밋1을 보고있기 때문에 커밋3의 이름을 확인할 수 없습니다.

이 때 사용할 수 있는게 바로 git reflog (reference log) 입니다. get reflog 는 이때까지 HEAD 가 가리켰던 commit 들을 순서대로 보여줍니다. HEAD@{n}  의 숫자가 작을수록 최근의 기록입니다. 각 커밋의 이름 대신에 head@{n} 을 사용해 지정할 수 있습니다.

지금까지는 Git 으로 버전 관리를 하며, 내 컴퓨터에만 저장을 했죠. 하지만 협업을 위해서, 그리고 프로젝트의 복구를 위해서 외부의 저장소에 우리의 파일을 업로드 할 필요가 있습니다.

외부 저장 서비스는 Github, GitLab, Bitbucket 등 다양하고, 서비스마다 각각의 특성과 장단점이 있지만 하나만 능숙히 사용할 수 있으면 다른 것들도 쉽게 사용이 가능합니다. 저희는 Gitlab 을 위주로 다뤄보겠습니다.

외부 저장소로 Push하기

1. 외부 저장소와 연결

git remote add origin {프로젝트의 gitlab url} 입력

git remote 명령어는 내 컴퓨터에서 내 컴퓨터에서 외부 저장소에 관한 작업을 할 때 사용하는 명령어입니다. 뒤에 다양한 종류의 명령어를 추가로 붙여서 다양한 명령을 수행 가능 합니다. 코드의 의미는 " url 이 가리키는 외부 서버의 프로젝트를 원격 저장소로 추가하는데, 이름을 origin 으로 하겠다."는 것입니다. (매번 긴 url을 쓸 수 없으니, origin 이라는 이름을 등록해주는 것.)

2. 디렉토리 내용 업로드

git push -u origin master 입력

git push 명령어는 "현재 내 프로젝트 디렉토리의 내용(.git 디렉토리 내부에서 관리되던 Repository 영역을 업데이트 한 것) 을 전부 origin 에 업로드 해라." 라는 것입니다. (-u , master 는 브런치 관련 내용으로, 추후 다뤄보겠습니다)

입력하면 아이디와 패스워드를 등록하라는게 나오는데, 프로젝트가 등록되어있는 자신의 gitlab 의 계정을 등록해주면 됩니다. url 만 입력해서 수정할 수 있었다면 url을 아는 팀원이 아닌 다른 사람이 함부로 수정할 수 있으니 꼭 필요한 부분이겠죠.

이렇게 외부 저장소와 연결하고, push 해준 후 gitlab 페이지에 가서 확인해보면, 지금까지 내가 한 commit 들이 시간순으로 다 보이는 것을 확인할 수 있습니다.

그리고, 처음에 이렇게 한번 push 를 해주면, 이후 명령시 디렉토리가 처음부터 origin 의 해당 프로젝트를 바라보고 있기 때문에 git push 만 입력해주면 됩니다.

.

외부 저장소에서 Pull 하기

그렇다면 반대로 Gitlab의 프로젝트에서 새로운 커밋이 Push 됐을 때 내 컴퓨터로 가져오려면 어떻게 해야할까요? 

혹은 새롭게 팀에 합류하게 되어 기존에 팀이 만들던 프로젝트를 가져오려면 어떻게 해야 할까요?

1. 처음 가져올 때

git clone {가져올 프로젝트의 url} 입력

이 명령어를 입력해주면, 페이지에 올라가 있던 커밋들을 하나의 디렉토리 형태로 그대로 복사해 가져옵니다.

주의할점은 우리가 clone 한 프로젝트 폴더는 지금 있는 폴더가 아니라 가져온 폴더이기 때문에,

리눅스 명령어 cd 를 이용해 clone 한 프로젝트 디렉토리로 이동한 뒤 git 명령어를 실행해야 한다는 점입니다. 

앞서 잠깐 언급한 적이 있었죠?

이후, #1 문서에서 다뤘던

git config user.name , git add , git commit -m "{commit설명} 을 써주고

git push 를 이용해 push 해주면 됩니다.^^ 

( 이때는 원격 저장소에 있던 프로젝트를 clone 한 것이기 때문에 별도로 git remote 를 쓰지 않아도 됩니다.)

2. 새로운 커밋을 가져올 때

 git pull 입력

이 간단한 명령어를 통해 현재 디렉토리가 바라보고 있는 gitlab 서버의 최신 커밋을 가져올 수 있습니다.

쉽게 버전을 관리하며 협업이 가능하겠죠?

포인트

1. 이름으로 origin 을 사용하자

git을 사용할 때, 관습적으로 외부 프로젝트 저장소의 이름을 origin 으로 합니다. 앞서 봤던 git remote add origin {url} 에서 봤듯이 말이에요. 그리고, 보통 여러 개발자가 함께 개발할때 새롭게 참여한 팀원은 다른 팀원에게 소스코드를 넘겨받는것이 아니라, git clone {url} 을 통해 가져옵니다. 내부 저장소에서 가져오는 것이 항상 가장 최신의 커밋을 가져온다는 보장을 하기 때문이죠. 이처럼 항상 기준이 되고, 근원이 되는 것은 gitlab에 있는 파일이기 때문에 origin 이라는 이름을 붙입니다.

2. Push 이전에 Pull 이 있다.

새로운 작업의 시작 전에는, 항상 내 컴퓨터에 있는 프로젝트가 gitlab 서버에 있는 최신 프로젝트를 포함하는지 확인하고 작업해야 합니다. 예를 들어 gitlab 의 최신 프로젝트에는 commit1, 2, 3, 4 가 있는데 내 컴퓨터에 commit 1, 2, 3 이 있어서, 이를 작업해 commit 1, 2, 3, 5 를 만들어 Push 하면 안되겠죠. 이렇게 되면 commit 끼리 충돌하며 Fail 할 수도 있습니다. 내 프로젝트로 gitlab 의 프로젝트를 덮어 씌우는 것은 보통 허용되지 않습니다. 포인트는 새 작업을 하기 전에는 무조건 git pull 로 최신 버전을 가져오자는 것입니다. Push 이전에는 Pull 이 있습니다.

오늘로 Git 과 Gitlab 에 대한 기본적인 내용이 마무리된 것 같습니다..

다음 글에서는 중요한 주제인 Git branch 만드는 법, Merge하는 법, Comflict해결 등을 알아보도록 하겠습니다. 

총총..

안녕하세요. 오늘은 소프트웨어에 관심있는 사람이라면 누구든 한번쯤 들어봤을 " Git " 에 대해 알아보는 시간을 갖도록하겠습니다 :> 

Git 을 처음 시작하는 분들을 위한 글로, 기초적인 부분만 다룬다고 생각하시면 되겠습니다^.^

#1 부터 #6 까지 업로드 될 예정이니 차근차근 같이 알아가보아요!

먼저 Git 이란 무엇일까요?

Git은 프로젝트의 개발단계에서, 팀원 모두와 함께 하나의 프로젝트에서 수월하게 코딩할 수 있도록 도와주는 도구입니다. 여러 사람이 하나의 프로젝트를 코딩한다면 여러 문제가 발생할 수 있는데, 그 문제를 쉽게 해결해줄 수 있는 마법같은 도구인것이죠. 오늘날 개발 실무에서는 Git과 GitHub/GitLab 등을 함께 사용함으로써 1. 프로젝트의 버전 관리와 2. 협업을 체계적으로 수행합니다.

하나씩 살펴볼까요?

1. 프로젝트의 버전관리

보통 여러분이 작업을 할 때, 한번에 완성되지는 않지요.

• 1차 작업물 -> 2차 작업물 -> 최종본 -> 최종최종본.... 

의 과정을 거쳐 한 프로젝트가 완성 될 것입니다.

하나의 파일에 계속 업데이트 하지 않고, 이렇게 따로 버전을 나눠 저장해두면 히스토리가 남아 언제든지 이전 버전을 활용할 수 있고, 프로젝트가 어떤 모습을 거쳐 현재의 모습이 되었는지 파악할 수 있다는 장점이 있지요. 이는 협업을 할 때도, 중간에 들어온 다른 개발자가 해당 프로젝트의 히스토리를 아는데 도움을 줄 것입니다.

이렇게 한 프로젝트를 여러 작업물로 나눠 관리하는 것을 버전 관리라고 합니다. 업데이트를 통해 기능을 추가한다던지, 버그를 수정한다던지 등 버전 관리는 소프트웨어 개발자에게 중요하며, 많은 개발자가 깃으로 협업 중입니다.

2. 원활한 협업

Git 은 원활한 협업을 지원합니다. 가령 팀원A가 프로젝트 버전1, 2, 3 을 만들고 외부 서버에 올리면, 다른 팀원B가 버전을 확인하고 버전 3를 다운받아 버전 4, 5 를 만들어 다시 서버에 올리는 것이 가능합니다. 추후 또 다른 팀원C가 버전 6, 7 을 만들겠지요. 이런식으로 깃은 다른 사람이 만든 코드를 받아, 업그레이드 하는 것이 수월합니다.

이 때, 프로젝트의 각 버전을 올릴 '서버'가 필요하겠죠? 이 Git 기반의 저장소 서비스가 바로 Github, GitLab 인 것입니다. Git 과 Github, Gitlab 은 다른 것이라 할 수 있죠.

Git 이용해보기

그렇다면 깃을 어떻게 이용할 수 있을까요? (윈도우)

먼저 아래의 링크에서 깃을 설치합니다.

https://git-scm.com/

설치를 하면 아래와 같이 Git bash 프로그램이 생긴것을 확인할 수 있습니다. 

Git-bash를 여니 터미널창이 보이네요

이렇게 Git을 다운받아주면, Git-bash 터미널창을 열지 않아도, VScode 등 프로그램의 내장 터미널에서 깃을 다룰 수 있게 됩니다.

파일 Commit 해보기

VScode를 실행하고, 깃에 올라갈 폴더와 파일을 만들어봅시다. 저는 예시로 BasicCar 파일과, README 파일을 만들었습니다.

파일을 커밋(commit) 한다는 것은 "특정 버전을 저장"하는 것을 말합니다.

커밋은 크게 3 가지영역을 바탕으로 작동합니다.

- Working Directory : 실제로 다루고 있는 프로젝트 디렉토리 폴더 자체 (우리의 경우 Racing Ground)

- Staging Area : 특정 버전으로 관리하고싶은 버전들을 모아둔 폴더

- Repository : 특정 시점의 Staging Area의 모습을 커밋으로 남기면, 커밋들이 저장되는 영역

우리는 Working Directory 에 파일을 생성하고, Staging Area에 업로드 하여, Commit 명령어를 통해 Repository 에 하나의 commit 으로 저장하여 버전 관리를 할 수 있습니다.

여기서 하나의 의문이 들 수 있는데요, Working Directory 에서 바로 Repository 로 올리면 되지, 왜 Staging Area를 거쳐 올리냐는 겁니다.

그 대답은 지금 당장 commit 하고싶지 않은 파일이 있을 수 있기 때문입니다. 즉, commit 하기 애매한 파일이 있으면, 제대로 수정한 파일만 Staging Area 에 업로드 하여 업로드된 파일에 대해서만 commit 을 하는 것입니다.

이제 파일을 직접 commit 해볼까요? 앞서 언급했듯이, 우리는 git 을 다운로드했기 때문에 VScode의 내장 터미널에서 commit 이 가능합니다. 

1. 준비

VScode 터미널에 git init 입력 (주의 : commit 하길 원하는 working Directory 폴더에서 해야합니다.)

2. commit 한 사람에 대한 정보 입력

git config user.name "{yourname}"

git config user.email "{youremail}" 

3. Staging Area 에 업로드

VScode 터미널에 git add {BasicCar.js} {README.md} 입력 (파일 이름)

파일 이름을 하나하나 넣기 번거롭다면, git add . 을 통해 모든 파일을 add 할 수 있습니다.

4. Repository 에 업로드

VScode 터미널에 git commit -m "{원하는 메모}" 입력

-m 은 메세지를 의미합니다. 메세지는 이전 파일과 비교해 어떤 내용이 변경되었는지, 어느 부분이 변경 되었는지 등 자세하고 친절하게 적습니다.

5. commit 이력 확인하기

VScode 터미널에 git log 입력

git log 를 입력하면, 지금까지 커밋한 이력을 확인할 수 있습니다. 이 이력은 커밋한 사람의 이름과 이메일 주소, 해당 커밋에 할당된 이름, 커밋한 시간 등의 내용을 포함합니다.

6. commit 파일 비교하기 

VScode 터미널에 git diff {커밋이름1} {커밋이름2} 입력

해당 코드를 입력함으로써 commit 한 파일간의 다른 점을 확인할 수 있습니다. 가령 어떤 파일이 추가되었고, 어떤 코드가 바뀌었는지를 친절하게 알려줍니다. 복잡하고 긴 커밋 이름을 모두 적을 필요는 없습니다. 파이썬이 알아볼 수 있도록 커밋 이름의 앞의 4 자리만 입력해도 알아서 찾아줍니다.

오늘의 Git알아보기는 여기서 마무리하도록 하겠습니다! 다음은 Commit 관리 및 Gitlab 에 대해서 간단히 다뤄보도록 하겠습니다.

리눅스.. 리눅스를 사용하며 한 학기를 보내보라는 조언을 처음 들었을때는 불안감이 앞섰습니다. 가상 머신이라는 것도 처음 들어봤고, 리눅스도 언뜻 들어본 것 같을 뿐이지 알 지 못하는 것이었기 때문입니다. 리눅스에 프로그램을 다운 받는 것이 윈도우에서의 다운 받는것과 다르다는 얘기를 들었을때는 상상이 안가기도 했습니다. 클릭하고, 다운받고.. 이게 어떻게 바뀔 수 있다는 것인지. 리눅스가 제 삶에 들어왔을 때 검색을 많이 해보았습니다. 대체 리눅스는 어떻게 프로그램을 다운로드 받는 것인가! 윈도우를 두고 리눅스를 쓰는 또 다른 이유는 무엇이 있을까.

다양한 이유들이 있었습니다. 말하자면 오픈 소스이기 때문에 완전한 무료이고, 이는 곧 개발 작업은 물론 홈 레코딩이나 그래픽 디자인 등에 최적화된 강력한 워크 스테이션 환경을 완전히 무료로 구축할 수 있다는 점, 리눅스를 돌리는 많은 서버는 리눅스 말고는 대안이 딱히 없다는 점, 등이 있겠지요. 개발에, 특히 서버에 리눅스가 좋다는 얘길 많이 들었습니다. 정보를 찾다보면 서버 개발자 분들이 리눅스를 매우 좋아하시더라구요. 저에게는 운영체제를 공부하고 명령어를 배울 수 있다는 큰 장점이 있었습니다. 과거 한번 라즈베리파이를 다뤄보며 운영체제를 조금 알게되어 터미널창에 작성해본 것이 처음이라 흥미로웠었는데, 이번에 리눅스를 하며 명령어들에 더 친숙해지고, 터미널 창과 더 대화를 나눠봐야지, 했었습니다.

그렇게 저는 총 10 가지의 프로그램을 다운받았습니다. 다운받은 프로그램의 기준은 이 프로그램을 리눅스에 다운 받음으로써, 리눅스가 나에게 더 매력적이게 되고, 늘 리눅스를 사용하지는 못하더라도 리눅스를 사용하는 것에 큰 불편함을 느끼지 않게끔 하는 것이었습니다. 먼저 개발 코드를 푸시, 풀 하기위한 깃과, 리눅스의 화면을 캡쳐하고 사진을 편집해줄 툴, 자바 개발환경을 위한 JDK와 이클립스, 간간히 즐길 미니게임 같은 SuperTuxKart, 보다 편리하게 웹 서핑을 할 수 있게 해줄 크롬, 우분투를 더 예쁘게 꾸며주고 편의성을 높여줄 Unity Teak Tool, 시스템 내의 프로그램과 환경을 관리해줄 Stacer, 노래를 들을 수 있는 Amaroc, 영상 편집이 필요하여 다운받은 shoutcut, 그리고 사람과 연결되는 공간인 Kakao talk 까지. 프로그램을 다운 받는데에 예기치못한 에러도 많이 뜨고, 가상머신 자체의 에러도 있어 한번은 다 지우고 다시 시작했지만, 이렇게 12주를 알차게 채우니 기분이 좋습니다.

아무래도 어릴 적부터 쓰던 운영 체제를 바꾸는 것이다 보니, 리눅스는 제게 어려웠습니다. 하나 하나 세부적인 모든 것들이 다 달라서 초반에 적응이 안되어 더 어렵게 느껴졌던 것 같습니다. 사실 어렵다기 보단 불편했다고 해야 할까요. 그러나 초기에 불편함을 느끼는 것은 당연한 과정이라는 생각이 듭니다. 리눅스에 프로그램을 다운 받으며, 쉬우면 알아가는 재미가 없다는생각으로 구글링하며 공부하였더니 이제는 리눅스에게 조금 거리낌이 없어진 것 같습니다. 간간히 리눅스를 다루다보니 운영체제를 다루는, 명령어를 입력하는 것에 친숙해졌고, 다른 운영체제에 대한 막연함이 사라졌습니다. 이제는 다른 운영체제에도 한번 (간단히) 써보겠다고 스스로 도전할 수 있을 것 같습니다.

---> 지금은 Lab에서 지원해주는 리눅스 기반 연구용 서버가 있어서, MovaXterm 이용해서 리눅스 잘 쓰고 있습니다.!! 

-      Kakao Talk 이란?

카카오톡은 주식회사 카카오가 2010년 서비스를 시작한 글로벌 모바일 인스턴스 메신저이다.

스마트폰 사용자들을 대상으로 프리웨어로 제공되며, 안드로이드, 애플, 블랙베리, 노키아, 오비스토어, 윈도우 폰 등의 다양한 운영체제에서 사용이 가능하다.

국내 대화 메신저 중에서는 단연 카카오톡이 가장 널리 쓰이고 유명하기에, 이번 리눅스에서도 카카오톡을 다운받아놓고, 필요시에 연락을 확인하기 위함으로 이번에 다운을 받아야 겠다고 생각을 하게 되었다.

다만… 리눅스에서 다른 프로그램에서처럼 카카오톡을 쉽게 받을 수 있는게 아니었다. 따라서 조금은 복잡한 과정을 거쳐 카카오톡을 다운 받게 되었다.

프로그램 설치(간략하게만 작성하였다.)

1.     Sudo dpkg –add-architecture i396

Sudo apt install wine playonlinux -y 를 입력하여 32 비트를 활성화하고 와인을 다운 받아준다. 카카오톡은 리눅스에서 안되기 때문에 와인을 통해 다운받아야 한다고 한다.

2.     playOnlinux 를 실행하여 Wine 버전 관리를 확인한다. 만약 최신 버전이 없다면 버전을 찾아 설치해준다..

wine mono 설치창이 나오면 설치한다.

윈도우 10을 선택하고, gdiplus, gecko, mono28을 선택한다.

3.     실행할 파일을 선택하라는 창이 나오면, 미리 다운로드 해둔 카카오 설치파일을 선택하여 카카오톡을 다운로드 한다. 마침을 누르고, 카카오톡의 바로가기를 만들어둔다.

-      후기

카카오톡을 어찌저찌 다운로드 받기는 했는데,… 로그인 시에 오류가 발생했다.  

구글링을 했더니 동일한 증상을 가졌던 사람이 해결한 문서가 있어, 터미널에 winetricks 의 설치와 관련된 코드와 ufw 에 관련된 코드를 입력해주었다. 그 이후 한 번 재부팅을 해줬다.

다행히 다른 것을 건들일 필요 없이  로그인에 성공했다..    (그래도 안된다는 사람도 있던데.. 다행이다) 바탕화면에 바로가기를 저장하는 방법은, PlayOnLinux 에서 Create a shortcut 바로가기를 만들면 된다고 한다.

이번주를 마지막으로, 약 12주에 걸친 리눅스 사용기가 끝이난다. 학기 초만해도 리눅스에 대해 아는 것이 없었는데…, 다양한 프로그램들을 다운 받으며 막연한 불안감만 가지고 있던 다른 운영체제와 많이 가까워진 기분이다.

마지막 12주차, 최종 후기 글에서는 리눅스를 데스크톱 OS로 사용했을때의 (내가 느낀) 장단점 등을 얘기해 볼 생각이다.

-      Shotcut 이란?

Shotcut은 오픈소스로 공개된 MLT framework 기반의 영상 평집 프로그램이다. 샷컷의 경우 템플릿 파일이 XML 기반으로 저장되어 편집이 간단하고, 멀티플랫폼에서 모두 실행되며, GUI, CLI 툴 또한 모두 지원되고 있다.

이번에 간단한 영상 편집을 할 일이 생겨서 영상편집 소프트웨어를 찾다 발견했다. 내가 원했던 사항인 다음의 1~ 4번을 모두 만족 시키는 소프트 웨어이다.

-1. 시간에 따른 멀티 편집 기능

2. 손쉬운 템플릿 조작 (편집 툴이 있어야 함)

3. 제작된 파일을 읽어들인 후, 경로 설정 값등을 프로그램 등으로 자유롭게 변경할 수 있어야 한다.

4. 윈도우와 리눅스 모두에서 실행이 가능해야 한다.

-      프로그램 설치

1.     Sudo apt-get update 와, Sudo ape-get install 을 해 공유 라이브러리를 설치한다.

2.     Sudo snap install shotcut –classic 을 입력하여 어플리케이션을 설치한다.

3.     잘 실행되는 것을 확인할 수 있다.

샷컷은 윈도우에서 종종 쓰던 곰믹스 영상 편집기와 기능이 비슷하여 조금은 프로그램이 익숙하다. 원하는 이미지나 text 를 원하는 값으로 설정하여 영상을 만들거나, 아이템들(스티커들)을 추가할 수도 있었다. 이렇게 하나하나 쌓아간 파일을   인코딩하여, 최종적인 동영상을 생성할 수 있었다.

-      후기

앞서 언급한 영상편집 해야할 일 중 하나는 남자친구와의 1주년을 맞아 축하하는 영상을 만드는 것이었다.

직접 노래를 녹음하여 음성 파일로 넣고, 텍스트 파일을 넣고, 가사에 맞는 그동안의 우리의 사진으로 구성된 영상을 만들었다.

샷컷을 조금 만져 보다 곰 믹스를 만져보다 샷컷을 조금 만져보다 하며 두 소프트웨어의 사용을 익혔다. 샷컷으로도 어느정도 만들었으나 역시 곰 믹스에 있는 폰트가 예뻐서 최종 완성본은 곰 믹스로 만들어두었다.

(오른편의 사진은 최종 영상 완성본의 5초 정도쯤이다.)

이번에 사용법을 꽤 익혔으니, 다음번엔 오로지 샷컷으로만 영상을 만들어볼 셈이다.

리눅스 명령어에 점점 익숙해지는 것 같은 요즘이다.

-      Amaroc 이란?

Amaroc 은 리눅스 우분투 사용자들이 애용하는 무료 음악 플레이어 중 하나이다. KDE 의 기본 플레이어이며, 재생 목록을 관리할 수 있고, 사용자가 듣는 앨범 커버를 보여주고, 노래 가사와 탭, 기타 연주법 등 다양한 서비스를 제공한다. Amaroc은 설치 또한 쉽다고 하여 리눅스를 사용하면서 노래를 듣기에 괜찮은 소프트웨어 인 것 같아 다운을 받기로 하였다.

-      프로그램 설치

Amaroc 은 우분투 터미널을 통해 쉽게 다운받을 수 있다.

Sudo apt-get install amaroc 을 입력해 설치를 진행한다.

잘 설치된 것을 확인할 수 있다.

 Amaroc 을 실행해 보았다. 설명대로 플레이 리스트 저장, 파일 열기, 인터넷 연결, 팟캐스트, 가사 보기 등의 기본적인 작동이 가능한 것을 볼 수 있다.

-      후기

가상머신을 처음 써보는 중인데, 가상 머신에서 처음으로 노래가 흘러나오는 것을 들었을 때 꽤 놀랐다. 노래가 흘러나오긴 할까..? 하는 반신반의한 마음을 갖고 있었기 때문이다.

정말 간단히 amaroc을 다운로드 받았지만, 더 최신 버전으로의 업데이트와 더 많은 기능을 위해선 mySQL을 설치하고 유니코드 환경으로 만들어주어야 한다고 한다.

Amaroc은 음악 정보를 저장하고 검색하는 데이터 베이스로서 SQLite, MySQl, 등을 사용하기 때문이다. 실제로 지금 내가 다운받은 기능만으로는 음악을 듣기에 충분하지 않을 것 같았다.

또, Amaroc은 실시간 가사를 이용할 수 있지만 우리나라 음악에 대해서는 이를 지원하지 않아,

한 개발자가 만든 실시간 가사 플러그인을 따로 다운로드 받아야 한다고 한다.

조만간 mySQL을 다운 받아,

최신 버전의 amaroc을 다운받아봐야 겠다.

오늘도 내 리눅스는 사용하고 싶어지는 중이다!

-      Stacer 이란?

Stacer 는 컴퓨터의 상태를 체크해주는 프로그램이다. CPU 와 HDD 의 상용량의 확인이 가능하며, 시작 프로그램 설정, 프로그램 삭제, 시스템 캐시 삭제, 시스템 진단 기능을 제공한다.

주로 쓰는 윈도우에서도 프로그램과 컴퓨터를 관리해주는 프로그램을 사용하며 종종 관리중인데, 리눅스도 관리 프로그램을 하나 다운받아 놓는게 좋을 것 같아 설치를 진행했다.

-      프로그램 설치

Stacer는 Ubuntu 저장소에서 사용할 수 없다고 한다. 따라서 sourceforge 에서 다운로드 하였다.

Sudo dpkg -i stacer_1.0.9_amd64.deb

를 입력해 설치하면, 정상적으로 다운로드 된 것을 확인할 수 있다.

현재 CPU 사용량이 15%, MEMORY가 556.9 mib, DISK 가 6.1 gib 가 사용중이다.

불필요한 파일들을 선택해서

Clean-up 할 수 있고, start-status, running-status 를 온 오프 할 수 있다. 그 외에도 시스템에 다운로드 되어져있는 패키지들을 확인한다거나,

CPU 의 현황, 과거 이력 등을 확인할 수 있다. Unity Settings, Appearance 등도 별도의 설정이 가능하다.

-      후기

점점 리눅스가 사용하기 용이해 지는 것 같다.

운영체제 꾸미기 툴, 사진 캡쳐 및  편집 툴, 시스템 내 프로그램 관리 툴, 개발 언어와 환경 다운로드, 짠 코드를 오픈소스에 푸시, 풀 할 수 있는  깃, 쉴 때 할만한 간단한 게임, 웹 개발에 도움이 되며 평소 서칭하기도 좋은 웹 브라우저 까지..

다음에는 내 리눅스에 또 어떤 프로그램을 다운 받을까. 사용하기 좋은 환경을 만들어서, 나 스스로가 리눅스에 거리낌 없이 자주 들락날락 거리게 되었으면 좋겠다.