어떤 햄버거를 드시겠어요?


사람들은 웹에서 사용자와 ‘무엇을’, ‘어떻게’ 이야기해야 하는지는 잘 알고 있지만, 말투의 영향력에 대해서는 잘 알지 못합니다. 오늘 포스팅에서는 커뮤니케이션 톤에 따른 사용자 테스트를 진행하여 도출된 결과와, 실제 기업에서 어떻게 커뮤니케이션 톤을 사용하고 유지하고 있는지 소개합니다.


브랜드를 위한 커뮤니케이션 톤 설정은 어떻게 하면 좋을까?

UX 리서치/컨설팅 그룹인 닐슨 노만(Nielson Norman)의 UX 전문가 케이트 메이어(Kate Meyer)는 커뮤니케이션 톤이 사용자의 브랜드 인식(브랜드 친밀도, 신뢰도, 욕구)에 어떤 영향을 미치는지 조사했습니다. 아래는 해당 리서치 결과를 바탕으로 도출된 결론입니다.



1. 신뢰는 필수입니다

여러 번의 검토 결과, 친밀도와 신뢰도는 개별적인 요소로서 욕구(추천 의지)에 상당한 영향을 미치는 것으로 나타났습니다.


하지만 신뢰도가 욕구에 더 강력한 지표로 작용합니다. 평균적으로 신뢰도가 욕구의 변화에 영향을 미치는 정도는 52%였습니다. 반면 친밀도는 약 8%만 영향을 미쳤습니다. 웹사이트 전반에 걸쳐 신뢰감을 확실하게 어필할 필요가 있습니다.


2. 유쾌한 말투가 모두에게 효과적이지는 않습니다


리서치 참가자들은 B(자동차 보험, 진지하고 객관적인 톤)보다 A(재미있고 비격식적인 톤)에 친근감을 느꼈지만, B를 더 추천하고 신뢰했습니다. 전통적인 산업 군(보험)에서 유쾌한 어조는 주목을 끌고 경쟁자로부터 존재감을 부각할 수 있었지만, 신뢰도와 전문성에 대해서는 의문을 남긴 것입니다.


사람들은 자동차 보험에 재미를 기대하지 않으며, 유머러스한 말투가 주제에 맞지 않는다고 생각합니다. “이 말투는 너무 다정하다, 친근함이 신뢰도를 낮추었다”라고 평가한 참가자도 있었습니다. 이해관계자가 “재미있게 만들어달라”, “농담 좀 넣어달라”고 말한다면, 이 경우를 기억하세요. 열정적이고 다정하며 유머러스한 어조가 모든 조직에 적합한 것은 아닙니다.


3. 금융처럼 전통적으로 경직된 느낌의 산업군에도 어느 정도의 대화체가 필요합니다


하지만 진지하기 위해 반드시 차갑고 딱딱할 필요는 없습니다. C(은행, 캐주얼한 톤)는 D(진지하고 객관적인 톤)보다 친밀도가 0.7점(5점 만점) 더 높았으며, 신뢰도 또한 0.3점 높았습니다. 참가자들은 친구에게 C를 더 추천하고 싶다고 응답했습니다. 참가자들은 C를 “접근 가능”하고 “직설적”이라고 묘사했고, D는 “지루”하고 “위협적”이라고 응답했습니다.


4. 유머가 사용자와의 커뮤니케이션을 방해해선 안 됩니다


온라인 조사에서 유머러스한 E(홈시큐리티, 재미있고 캐주얼한 톤)가 더 친근하게 평가되었고, 친구에게 추천할 의향 또한 높았습니다. 한 참가자는 E의 유머러스한 점을 좋아했고, F(정중하고 객관적인 톤)는 너무 진지하다고 답했습니다. 하지만 다른 세 명의 참가자는 E를 매우 싫어했으며, 유머러스한 제목이 “진부하며 요점이 없다”고 평했습니다.

이를 통해, ‘유머’는 경쟁자들 사이에서 차별화할 수 있는 강력한 요소라는 사실을 알 수 있습니다. 단, 정말 재미있을 경우에 해당합니다. 유머는 위험 부담이 매우 크며, 사용자들을 화나게 할 수도 있습니다. 특히 사용자들이 원하는 정보를 제공해야 할 때, 유머가 이를 방해하면 안됩니다.


5. 톤을 선택할 때, 사용자의 감정을 고려해야 합니다



질적 조사에서 H(병원, 캐주얼하고 열정적인 커뮤니케이션 톤)가 그렇지 않은 대조군 G(진지하고 예의 바르며 객관적인 톤)보다 친밀도가 더 높았으며, 신뢰도는 미세하게 높았습니다. 참가자들은 만장일치로 H를 선호했습니다. H의 진지하면서도 친근한 느낌이 사용자들이 처한 스트레스 상황을 이완하는 것으로 보입니다.


한 참가자는 “H는 환자를 대하는 태도가 좋지만, G는 비즈니스적이다”라고 했습니다. 독자의 걱정이나 감정 상태를 고려해 톤을 선택해야 합니다. 사용자가 수술을 앞두고 있다면, 과연 사무적인 톤을 선호할까요? 사용자가 에러 페이지에서 우스갯소리를 보고 싶어 할까요?


6. 콘텐츠에 최적화된 어조는 사용자, 메시지, 브랜드에 달려 있습니다


뭐든지 스튜디오의 톤은 #재미있고 #캐주얼하며 #열의에_찬 정도가 될까요

전체 샘플 테스트를 통해, 캐주얼하고 중간 정도의 열의에 찬 대화체가 가장 효과적이라는 사실을 확인했습니다(이 요소들이 모두 결합할 필요는 없다는 것 또한 알 수 있었습니다). C와 D를 통해서는 진지한 대화체가 은행에 가장 적합하다는 결론을 내렸습니다. 커뮤니케이션 톤의 선택은 브랜드의 성격과 우선순위의 균형을 잘 유지해야 하는 어려운 과업입니다. A와 B에서처럼, 브랜드는 친근하지만 선택받지 못하는 경우도 있으니까요. 무엇보다도 톤을 선택하는 최고의 방법은 사용자와 함께 평가하는 것입니다.


온라인 상의 말투(어조) 사용자의 브랜드 인식(친밀도, 신뢰도, 욕구) 상당한 영향을 미친다는 점을 발견했습니다. 사람들은 캐주얼한(casual) , 대화하는 듯한(conversational) , 열의에 (enthusiastic) 톤에 가장 좋은 반응을 보였습니다.


그렇다면 실제 브랜드에서는 커뮤니케이션 톤을 어떻게 설정하고, 사용하고 있을까요?


스타트업 기업 ‘슬랙’의 블로그에 공개된, 트위터 커뮤니케이션 톤 활용법을 알아봅시다. 아래 글은 본문의 일부를 발췌했습니다.



처음 일 년 간은 몇 명의 사람들만이 SlackHQ 트위터 계정을 사용했습니다. CEO, 설립자, 초창기 직원들입니다. 아주 작은 팀이었고 커뮤니케이션 톤은 사람들 그 자체를 반영했습니다. 대화체에 약간 비정상적이면서 재미있고 유용한 정보를 주는 식이었습니다. 자신감에 차 있되, 자신을 내세우지 않고, 도움을 주지만 약간 이상한.


슬랙이 성장하면서, 몇 명에서 수백 명으로 (가끔은 수천 명으로) 멘션 수가 늘어났습니다. 하지만 우리는 누가 트윗을 하든지 여전히 같은 톤을 유지하려 노력하고 있습니다. 트위터는 슬랙의 목소리가 가장 재미있게 표현되는 곳입니다. 그만큼 부담스러운 것이기 때문에 까다롭기도 합니다.


슬랙의 트위터를 위한 스타일 가이드는 두 파트로 나뉘어 있습니다. 소수를 위한 파트, 다수를 위한 파트입니다. 트위터에서는 많은 사람들이 개인적인 질문에 대답을 하고, 조언을 해주며, 피드백을 주고 받지만, 각각은 약간씩 다른 커뮤니케이션 톤으로 다루어져야 합니다.


1. Step one: @SlackHQ의 계획


무엇을 트윗해야 할까?


이 계정이 무엇을 위한 것인지 명확히 해야합니다. 밖으로 발행되는 트윗(질문이나 코멘트에 대한 대답이 아닌 최초의 포스팅)이 아래의 카테고리에 속해야 합니다.


    • 제품 소식

    • 중대 발표

    • 넌센스


이 카테고리를 가지고, 우리는 항상 생각합니다 “트윗할 가치가 있는 내용인가? 이것이 발행할 만큼 많은 사람들에게 임팩트가 있는 것인가?” 그렇지 않다면 다른 방법을 찾습니다.


중요한 일을 하고 있다는 마음가짐

새로운 릴리즈의 발표


누가 계정을 시작했는지, 이전에 어떻게 해왔는지는 중요하지 않습니다. 인기 계정이라고 중요한 것도 아닙니다. 특별한 단어가 포함되어 있어서도 아니며, 사람들의 일에 매우 중대한 영향을 미치는 것이어서도 아닙니다. 만약 제품 릴리즈와 같은 중대 발표가 있다면, 다양한 프로덕트 매니저, 리서처, 디자이너, 개발자, QA 엔지니어, 마케팅 매니저 등이 발표를 위해 모입니다. 수백 명의 사용자 경험 관계자와 세일즈 매니저들에게는 이 발표를 기점으로 일이 시작됩니다. 수백개의 팀을 대표하여 전 세계로 트윗하고 있는 것입니다. 적어도 맞춤법은 꼭 지키세요.

2. Step two: @SlackHQ의 글쓰기


캐릭터 보다는 내용이 중요합니다


사람들에게 깊은 인상을 주는 것보다 말하고자 하는 바를 정확히, 명확하고 짧게 이해시키는 것이 더 중요합니다. 만약 앱의 새로운 기능이나 업데이트를 발표하는 것이라면, #changelog 해시태그를 사용하세요. 사람들이 다른 것은 신경쓰지 않더라도 해시태그로 해당 내용을 찾아볼 수는 있습니다.

#changelog


이모지가 필수는 아닙니다


절대 절대 이모지를 단어 대신 사용하지 마세요. 이모지를 더할 때는 재밌는 일이 있거나 축하할 때 뿐입니다. 하지만 이때도 필수는 아닙니다. 지금와서 매번 이모지를 사용했던 옛 계정들을 돌아보면 너무 민망합니다. 괴로워요.



사람들이 아는 단어를 사용하세요


동음이의어를 피하세요. 특히 특정 문화나 교육 수준을 고려하여 동음이의어 사용은 피해야 합니다. 몇 사람들은 똑똑하다고 느껴질 수 있겠지만, 그렇지 않으면 소외됩니다.


이벤트는 그냥 보고만 있어도 됩니다


트위터에서 일어나고 있는 사건들이 무엇이건 간, 지금 일어나는 일이든 해적처럼 말하기 날(9월 19일)이든 우리는 참여하지 않습니다. 시간이 지나면 촌스러워질 것이고 쿨해 보이려고 애쓰는 것처럼 보이기 때문입니다. 우리는 쿨해보이기 위해 노력하지 않습니다.



우리는 슬랙 사용자를 생각합니다


우리는 가벼울지라도, 슬랙을 사용하는 사람들은 그렇지 않습니다. 우리가 “우리 정말 열심히 일했어요” 라고 발표하지 않는 이유입니다. 우리가 말하는 것은 사람들에게 어떤 것을 해줄 수 있는가 입니다. 모든 이야기의 중심에는 사용자가 있습니다.


3. Step three: @SlackHQ의 트윗


트윗하기 적절한 시간인지 확인합니다


트윗하기 전, 트윗하기 적절한 시간이 맞는지 소식이나 트위터를 확인해야 합니다. 만약 어떤 사건이 있다면, 멈추는 것이 좋습니다. 슬랙에서는 고객경험팀과 서비스 문제가 없는지 미리 확인하여 불필요한 공력을 줄입니다.



우리는 대화 톤을 사용하기 때문에, 대화에 열려 있습니다


대화에 참여하세요. 댓글에 응답하세요. 트윗에 사람들이 대답했다면 트위터로 답하세요.



넌센스와 진지한 비즈니스

아무말 대잔치


SlackHQ는 심각한 뉴스만 발표하지 않습니다. 슬랙을 만든 진짜 사람이 슬랙을 사용하는 진짜 사람에게 사람 대 사람으로 말하고 싶습니다. 그래서 때때로 좋은 소리가 나는 단어, 격려, 질문, 초대장들을 무작위로 트윗합니다. 사람들이 대화하고 싶어하면 답할 것입니다. 이것은 마치 길을 지나가는 누군가에게 “오늘 머리가 멋지네요”라고 말하는 것과 같습니다. 아무것도 원하지 않고 기대하지 않는, 그냥 대화입니다. 말을 걸어보세요.


마치며

디지털 카피라이팅의 세계에서 커뮤니케이션 톤은 복잡 미묘한 요소이지만, 연구결과가 보여주듯 브랜드에 상당한 영향을 미칩니다. 다른 UX와 마찬가지로 커뮤니케이션 톤 또한 테스트하고 연구해야 합니다. 또한 슬랙의 트위터 활용법 가이드처럼 자신의 브랜드에 어울리는 톤과 방식을 치밀하게 설정해야 합니다.  



Posted by slowalk

업무와 관련된 학습의 의지는 항상 불타지만, 게으른 자신을 탓하며 미루고 미루다보니 2017년이 되었습니다. 그래서 백엔드 웹 개발자인 저는 2017년 개인 KPI로 ‘새로운 개발 언어를 습득하고 웹사이트 1회 이상 제작하기’를 설정하였습니다.



일단 새로운 언어를 배우겠다고 하긴 했는데, 어떤 언어를 배워야 할지 감이 잡히지 않았습니다. 세상에는 많은 개발 언어가 있고 계속해서 새로운 언어가 생겨나고 있기 때문이죠.


개발 언어의 다양한 종류, 출처: GRIFF'S GRAPH


어떤 언어를 배워야 할까요? 그에 앞서 다양한 통계를 먼저 살펴보도록 하겠습니다.



통계로 보는 개발 언어


1. Developer Survey Results 2016

전 세계적의 많은 개발자들이 활동하고 있는 개발자 포럼인 Stack Overflow에서 전 세계 173개국의 56,033명의 개발자들을 상대로 실시한 설문입니다.


<조사에 참여한 개발자들의 직업 분포>


Full-Stack 웹 개발자(OS부터 서버, 데이터베이스, 백엔드, 프론트엔드 등 전반적인 웹개발을 아우르는 능력을 가진 개발자)라고 응답한 비율이 28%로 가장 많고 백엔드 웹 개발자, 모바일 개발자 등의 순서대로 비중을 차지했습니다.


<가장 대중적인 기술>


설문에 참여한 개발자 중 웹 개발자의 비율이 높은 만큼 50%가 넘는 응답자가 JavaScript를 사용한다고 답했습니다. 그 뒤로 Java와 C#, PHP, Python 등이 주로 사용하는 개발 언어를 차지했습니다.


<가장 사랑받는 & 원하는 기술>


Rust, Swift 등이 응답자가 사용해본 언어 혹은 기술 중에 가장 많이 사랑받고 있다는 결과가 나왔습니다.



현재 사용하고 있지 않는 언어나 기술 중에서 가장 써보고 싶은 것에는 Android, Node.js, Angular.JS 등이 상위권을 차지했습니다.



2.Language Trends on GitHub

버전관리 툴인 깃(Git)을 사용하는 프로젝트를 지원하는 서비스인 GitHub서 2015년에 발표한 통계도 흥미롭습니다.  



아래는 GitHub가 2008 년에 출시 된 이후부터 GitHub.com에서 사용 된 프로그래밍 언어의 빈도를 토대로 그 순위를 보여주는 그래프입니다. Java가 눈에띄는 성장세를 보였고, Stack Overflow의 ‘가장 대중적인 기술’의 결과와 비슷하게 JavaScript와 PHP 등이 높은 순위를 차지했습니다.



통계가 의미하는 것


이런 결과들이 의미하는 것은 무엇일까요? 사실 의미하는 바가 그리 크지 않다고 생각합니다. 물론 일부 개발자들의 생각과 언어 사용 빈도, 추세 등을 볼 수는 있습니다. 그리고 생각보다 재밌었습니다. 학창시절에 Java를 배웠었는데 Java 순위의 변화 추세를 보며 ‘그때 열심히 배워둘 걸’하는 생각도 했습니다.

이러한 통계도 ‘재미로’ 진행하지 않았을까 생각합니다. 온라인 설문 조사의 특성 상 응답자가 제한되어 있고 세계적인 트렌드라고 하기에는 표본 집단의 수가 적기 때문입니다. 또한, Node.js가 10년 전에는 존재하지 않았던 것처럼 빠르게 변화하는 개발 언어의 전망은 쉽게 예측할 수 없기 때문입니다.


왜 배우려고 하는가


사실 ‘어떤 언어가 인기있더라, 이 정도는 알아야 하더라’ 하는 ‘~카더라’ 통신이 난무하라도, 제일 중요한 것은 배우려는 목적입니다. 백엔드 웹 개발자가 스타일과 레이아웃에 더 많은 욕심이 생긴다면 HTML과 CSS를, 프론트 웹 개발자가 DB를 좀 더 잘 다루고 싶다면 SQL, PL/SQL 등을 배워 볼 수 있겠죠.

제가 언어를 배우려고 하는 목적을 생각해 보았습니다. 저는 업무에 도움이 되면서도, 생산성이 높은 언어를 배움으로써 경쟁력을 가지고 싶었습니다. 그래서 Ruby on Rails라는 프레임워크를 사용하여 상대적으로 빠르고 쉽게 웹사이트를 만들 수 있다고 알려진, Ruby라는 개발 언어를 배우기로 하였습니다.



시작이 반이다


새롭게 마음먹은 김에 바로 실행에 옮겨보았습니다. 먼저 AWS에서 리눅스 서버 호스팅을 신청하고, Ruby 가이드Ruby on Rails가이드를 보면서 설치를 했습니다.


그리고 home/hello라는 URL 세팅을 하고  


‘Hello, World!’를 출력했습니다 :)


이제 할 일을 다한 것 같은 기분이 들긴 하지만 시작이 반이라고 했습니다! 저는 개발계의 초석같은 ‘Hello, World!’를 출력함으로써 반이나 나아갔습니다(라고 믿고 있습니다).

어떤 개발 언어를 배울지, 어떤 언어가 요새 트렌드인지 고민하는 사이에 시간은 흐르고 있습니다! 당신이 배우고 싶은 개발 언어는 무엇인가요? 그게 어떤 것이든 개발 언어 공부의 시작을 응원합니다.



참고

What’s the Best Programming Language to Learn in 2017?




Posted by slowalk


구글애널리틱스, 다들 관심이 많으시죠.

저 또한 1년 전 웹 기획자로서 구글애널리틱스를 잘 알아야 한다는 의무적이고도 패기 넘치는 마음으로 구글 애널리틱스 입문 강의부터 활용강의, 책 등을 섭렵했었습니다.

그때의 목표는 최종적으로 GAIQ* 취득하기였습니다. 하지만 막상 강의를 듣고 실무에 적용시켜나가보니 그 목표는 점점 희미해져갔고, 제 기억에서 잊혀갔습니다. 그러다 1년이 흘러 새해가 밝았고, 올해는 제 개인 KPI로 삼아 구글애널리틱스 자격증인 GAIQ를 꼭 취득해보기로 했습니다. (*GAIQ: Google Analytics Individual Qualification의 약자로, 구글에서 시행하는 온라인 자격인증시험입니다.) GAIQ에 도전했던 1인으로서 그 과정과 GAIQ에 도움이 되는 책, 블로그, 강의 등을 소개해드릴까 합니다.

[구글애널리틱스 자격증(GAIQ) 알아보기]

1. GAIQ란?

구글애널리틱스 시험에 합격한 모든 개인에게 실력을 입증하는 것입니다. 왜 공인 전문가 자격을 취득해야 하는지 궁금하실 수 있는데요. 구글애널리틱스는 초보자도 쉽게 이용할 수 있지만, 전문가가 관리할 때 최대의 효과를 발휘하기 때문에 그렇습니다.

2. 시험 응시자격? 조직에서 구글애널리틱스를 활용할 수 있는 사람, 동일한 기능을 수행하는 모든 사람이 응시할 수 있습니다. 응시 자체는 누구나 가능합니다.

3. 시험비용이 따로 있나? 구글 파트너에 가입하면 무료로 구글애널리틱스 시험에 응시할 수 있습니다. 구글 사용자가 아니라면 응시가 어렵습니다.

4. GAIQ, 한국어도 있나? GAIQ는 한국어, 네덜란드어, 독일어, 러시아어, 스페인어, 영어, 이탈리아어, 일본어, 중국어(간체), 체코어, 터키어, 포르투갈어, 폴란드어, 프랑스어로 제공됩니다.

5. GAIQ의 유효기간? 공인 전문가 자격을 최신 상태로 유지하려면 18개월마다 시험에 합격해야 합니다.

6. 시험 응시 방법은? 파트너 계정에서 시험에 액세스하려면 다음 단계를 따르세요.

a. Google 파트너에 로그인합니다.

b. 인증을 클릭하고 시험 상태를 확인합니다. 인증 자격을 얻으려면 몇 개의 시험에 통과해야 하는지 등의 정보가 표시됩니다.

c. 시험 보기를 클릭합니다.

d. 응시하려는 시험 영역으로 마우스를 가져갑니다. 시험 세부정보를 클릭합니다.

e. 시험 응시를 클릭하여 시험에 응시합니다. 또는 이 페이지에 링크된 시험 대비 자료를 학습할 수 있습니다.

*시험에 합격하면 합격 여부가 시험 페이지에 표시되기까지 최대 48시간이 걸릴 수 있습니다. (개인적으로는 바로 시험 합격 여부가 표기되었습니다.)


7. 시험 소요시간은?
시험시간은 90분이고, 시험을 시작하면 하단에 시험 타이머가 작동됩니다. 혹 컴퓨터 전원이 종료되더라도 타이머는 계속해서 작동됩니다. 인터넷 연결이 끊겼을 경우에도 중단된 부분부터 시험을 볼 수 있지만, 타이머는 중단되지 않습니다.


8. 시험 합격 점수 커트라인은? 정답률이 80% 이상이 되어야 합니다. 시험을 본 후 페이지 상에서 정답을 맞춰보거나 틀린 문제가 어떤 것인지 알 수는 없습니다. (정답에 확신을 가질 수 있는 끝없는 공부가 필요합니다)


9. 시험에 떨어지면 언제 다시 응시할 수 있나? 시험에 합격하지 못한 경우 7일 이내에 다시 응시할 수 있습니다. 1주일 간 스터디 가이드를 통한 열공은 필수입니다.



[GAIQ 시험 생생후기]

오랜만에 구글 애널리틱스 공부를 하고, 지난 2월 말 GAIQ에 처음 응시했습니다.



지금 시험 시작하기 버튼을 누르면 그때부터 시험페이지가 등장하고 타이머가 작동됩니다. 온라인으로 진행되고 처음 보는 형식의 문제 형태에 초반엔 조금 당황했습니다. 하단에 타이머가 계속해서 흘러가니 마음도 살짝 조급해집니다.



문제는 객관식으로 사지선다 또는 오지선다 입니다. 이번 시험에서는 다중채널유입경로, 애드워즈 관련 문제가 많이 나온 편이었습니다.


제 개인적인 느낌으로는 답이 딱 떨어지는 시험이 아니라는 생각을 많이 하게 되었습니다. 탄탄한 밑바탕이 있어야 자신 있게 답을 선택할 수 있을 것 같았습니다. 나름 열심히 공부했는데 헷갈리는 문제가 꽤 있다는 느낌을 받았습니다.


또한, GAIQ시험은 기출은행식의 시험입니다. 2번 시험에 응시했는데 같은 문제가 많이 등장합니다. 다만, 내가 이전에 본 시험의 답이나 오답을 알 수 없으니, 확신을 갖고 답을 선택하려면 공부가 필수입니다. 인터넷에 있는 정보 또한 풀이는 100% 믿으면 안됩니다. 꼭 자신이 직접 찾아 공부하는 것이 중요합니다. 기출문제 풀이는 웹로그 분석고객센터에서 직접 찾아서 확인하고 자신의 것으로 만들고 넘어가는 것이 중요합니다. 또한, 오픈북 형식입니다. 시험을 보면서 다른 사이트를 찾아볼 수 있고, 참고할 수 있습니다. 다만 시간 내에 문제를 모두 풀려면 기본 지식이 바탕이 되어야 합니다. 




처음 본 시험은 76점으로 떨어졌지만 7일 동안 다시 공부하여 시험에 응시할 수 있습니다. 시험의 느낌을 공유하자면, 초반엔 약간 생소했고 중간 정도부터는 공부를 어떻게 해야 하는지 알 수 있었습니다. 마지막 부분에서는 시간이 약간 모자란다고 느꼈습니다. 하지만 기출은행식의 시험이기에 여러 번 응시하게 된다면 시간문제는 충분히 해결할 수 있을 것 같았습니다. 공부를 시작하기 전 시험에 응시해보고 공부의 방향을 정하는 것도 도움이 충분히 될 것 같습니다.



시험응시를 끝내고 나면, 메일로 해당 내용이 옵니다. 구글에서는 무료 학습 가이드를 제공하고 합격에 필요한 정보를 굉장히 많이 제공하기 때문에 해당 자료들을 활용하는 것이 매우 도움됩니다. 즉, 구글에서 무료로 제공하는 스터디 정보들이 많기 때문에 누구나 독학으로도 충분히 자격증을 취득할 수 있습니다. 그 외의 다양한 참고 사이트를 소개합니다.



[참고하기]


주로 참고한 사이트는 구글 애널리틱스의 공식 사이트입니다. FAQ 메뉴와 학습 가이드에서도 많은 도움을 받을 수 있고 굉장히 자세하게 많은 정보를 제공하기 때문에 구글애널리틱스 사이트의 FAQ와 학습 가이드, 온라인 강의를 듣는 것이 좋습니다.


1. 구글애널리틱스 제공 학습 가이드

a. GAIQ 학습가이드

b. 애널리틱스 아카데미


2. 커뮤니티

a. 웹분석 커뮤니티

구글애널리틱스 관련 커뮤니티 중 제가 주로 이용하는 사이트입니다. 공부를 하면서 의심이 드는 부분을 내가 생각한 정답과 이유 등을 기술하여 묻고 토론할 수 있습니다. 이 방법 또한 매우 도움이 됩니다.

b. 마케팅-로그분석

GA관련 커뮤니티로 다양한 양질의 정보가 많습니다.


3. 개인 블로그

a. 구글애널리틱스 문제풀이 관련 검색을 하다 보면 개인 블로그에 좋은 강의 내용을 포스팅하는 분들이 많습니다. 저는 개인 블로그를 통해서도 헷갈리던 문제들의 힌트를 얻기도 하고, 공부 의지를 불태웠습니다.

b. 구글애널리틱스 시험, GAIQ, CPC 등 시험 문제에 나오는 키워드로 검색하면 좋은 참고 링크가 등장합니다.


4. 서적

a. 구글 웹로그 분석 - 한빛 미디어

b. 구글 애널리틱스 웹로그 분석의 시작과 끝 - 에이콘


5. 강의

a. 마소캠퍼스

b. 블로터아카데미

*실제 위 두 곳에서 작년에 외부 교육을 듣고 구글 애널리틱스에 대한 기초를 다졌습니다.


[마무리]

입사 초기 구글애널리틱스에 대한 블로그 글을 작성한 적이 있습니다.

당시에는 생소한 단어였지만 이제는 구글애널리틱스에 대해 어느 정도 알게 되었습니다. 공부하면 할수록 배울 것이 많고 실무에 활용하기 좋은 기능들이 많습니다. GAIQ를 취득한다고 완전한 전문가가 되는 것은 아니겠지만, 자격증을 꾸준히 유지하고 발전해간다면 GA 분석을 필요로 하는 사람들에게 더욱 양질의 정보를 제공할 수 있을 거로 생각합니다. 글을 마치며 저는 위 내용을 기반으로 시험에 재응시해 GAIQ를 취득하게 되었습니다.



시험에 합격하게 되면 해당 인증서의 유효기간이 나오고 구글 프로필에 인증 뱃지가 등록되게 됩니다. 유효기간은 18개월이므로 계속해서 GAIQ 갱신을 위해 공부도 게을리하지 말아야 합니다. 그럼 모두 GAIQ 시험에 합격하시길 응원합니다!




Posted by slowalk

1월 말부터 슬로워크 홈페이지에서 실시간 채팅으로 프로젝트 의뢰 및 상담이 가능해졌습니다. 홈페이지 우측 하단의 말풍선을 클릭하면, 슬로워커와 채팅을 할 수 있는데요. 이러한 서비스를 ‘채팅형 고객지원 서비스'라고 합니다. 해외에서는 이미 많은 업체들이 채팅형 고객지원 서비스를 이용하고 있고, 그 종류도 다양합니다. 채팅형 고객지원 서비스에 대해 알아보고, 간단한 방법으로 고객을 사로잡을 수 있는 5가지 메시지를 소개하겠습니다.


채팅형 고객지원 서비스가 뭔가요?

채팅형 고객지원 서비스는 말그대로 ‘채팅'으로 고객을 지원하는 서비스입니다. 홈페이지에 간단한 소스코드를 삽입하여 설치하면, 웹사이트 방문자와 실시간 채팅을 할 수 있습니다. 대표문의를 전화나 이메일 혹은 게시판으로 받는 것처럼, 간편하게 채팅으로 고객과 소통할 수 있게 된 거죠. 게다가 고객이 웹사이트의 어느 페이지를 보다가 문의를 했는지 확인할 수 있고, 고객별로 대화내용을 DB화 할 수 있어 맞춤형 응대가 가능합니다.


이를 테면, “제작 단가를 알 수 있나요?”라고 고객이 질문했는데, 해당 고객이 보고서 프로젝트 페이지를 보고 있음이 확인되면 “어떤 프로젝트의 제작 단가를 말씀하시는 건가요?”라고 묻지 않고, “혹시 보고서 프로젝트의 제작 단가가 궁금하신가요?”하고 물어볼 수 있습니다.




슬로워크는 고객이 보고 있는 페이지에 따라 맞춤형 안내 메시지를 보내고 있습니다. 편집디자인 관련 포트폴리오 페이지를 방문한 고객에게는 ‘편집디자인 견적 의뢰’, 웹사이트 관련 포트폴리오 페이지를 방문한 고객에게는 ‘웹사이트 견적 의뢰'와 관련된 안내를 합니다.



현재 온라인 쇼핑몰부터 웹에이전시, 호텔까지 많은 업체들이 채팅형 고객지원 서비스를 활용하고 있습니다. 그 중 대표적인 서비스는 인터콤입니다. 2011년 출시 이래로, 이미 전세계의 15,000개 이상의 업체들이 인터콤을 통해 수많은 고객들과 소통하고 있습니다. 인터콤은 축적된 경험을 토대로 안정적인 서비스를 제공할 뿐만 아니라, 고객에게 최적화된 경험을 선사할 수 있는 다양한 노하우를 블로그에 공개하고 있습니다. 때문에 슬로워크에서도 인터콤을 사용하고 있습니다.


인터콤 외에도 간편한 UI와 저렴한 비용 덕분에 스타트업이 이용하기에 적합한 Groove, 다소 복잡하지만 다양한 기능을 선보이고 모바일에서도 웹과 비슷한 수준의 기능을 제공하여 대기업에 적합한 Desk, 비용이 저렴하고 한국어로 지원하기 때문에 이용이 편리한 국내 서비스 Channel 등 다양한 서비스가 있습니다.


채팅으로 고객을 사로잡는 5가지 방법

이와 같은 채팅형 고객지원 서비스는 단순히 고객 문의에 ‘대답'만 하는 것이 아닙니다. 잘 활용하면 방문이 뜸했던 고객을 잃지 않고 유지할 수 있고, 고객에게 최적화된 경험을 선사할 수도 있습니다. 인터콤 블로그에 소개된 “5 simple messages to engage your customers” 글을 바탕으로, 채팅으로 고객을 사로잡을 수 있는 5가지 방법을 소개합니다.


1. 온보딩 메시지를 통해 고객에게 정확한 문의 채널을 안내합니다.

웹사이트를 방문한 새로운 고객에게 이용방법을 안내하는 ‘온보딩(Onboarding) 메시지'입니다. 고객을 반갑게 맞이하며, 필요할 때 연락할 수 있는 정확한 문의 채널을 안내합니다. 처음 말풍선 아이콘을 보는 고객들도 당황하지 않고, 간편하게 문의할 수 있도록 도울 수 있습니다.


슬로워크는 온보딩 메시지를 통해 문의 가능 시간을 함께 안내하고 있습니다.


2. 고객의 이용 빈도에 따라 맞춤형 참여 유도 메시지를 발송합니다.

고객의 방문 횟수를 이용하여 참여 유도 메시지를 보낼 수 있습니다. 이를테면, 고객이 100번째 메시지를 보냈을 때, “방금 100번째 메시지를 보내셨습니다. 관심 가져주셔서 감사해요! 친구에게도 소개해주시는 것은 어때요?”라고 제안할 수 있습니다. 갑자기 ‘좋아요'를 눌러달라고 하는 것보다 훨씬 낫겠죠?


또한, 제품의 다양한 기능을 알릴 때에도 유용합니다. 처음부터 모든 기능을 한꺼번에 알려주지 않고, 고객의 이용 패턴에 따라 차차 필요한 기능을 안내하면 됩니다. 인터콤에서도 이용빈도에 따라 점차적으로 기능 안내를 하고 있습니다. 분류별로 메시지를 정리할 수 있는 ‘태그' 기능은 신규 사용자에게는 불필요한 기능이기 때문에, 사용자의 수신 메시지가 20페이지를 넘어갈 때 안내하고 있습니다.



이미지 출처: Inside Intercom 5 simple messages to engage your customers


3. 태그 기능을 활용하여 우수고객에게 메시지를 보냅니다.

대다수의 채팅형 고객지원 서비스에서는 ‘태그' 기능을 지원하고 있습니다. 태그 기능을 활용하여 우수 고객에게만 별도의 메시지를 보낼 수 있습니다. 방법은 간단합니다. 우수고객을 선정하고, 해당 고객들의 정보에 “VIP”라는 태그를 설정하여, 우수 고객에게 메일을 보낼 때에는 수신자에 “VIP”라고 적으면 됩니다.



이미지 출처: Inside Intercom 5 simple messages to engage your customers


4. 정기적인 피드백 메시지

일정한 간격을 두고 같은 고객에게 정기적으로 피드백 요청 메시지를 보내면, 문제 해결의 중요한 정보를 파악할 수 있습니다. 예를 들면, 30일, 60일 90일, 180일 단위로 고객에게 ‘이용해보니 어떠신가요? 불편한 점은 없으신가요?’ 라고 메시지를 보내는 것입니다. 이러한 메시지는 고객이 요구하기 전에 먼저 문제를 해결할 수 있도록 돕습니다.


5. 한동안 방문이 뜸했던 고객을 잃지 않기 위한 유지 메시지

고객이 방문하지 않은 기간 동안 업데이트된 정보 혹은 기능을 안내하며 재방문을 유도할 수 있습니다. ‘뭔가 사정이 있으신가보다' 하고 체념하거나, ‘다시 방문해주세요ㅠ'라고 직접적으로 요청하기보다, 고객이 스스로 다시 재방문 하고 싶도록 동기부여를 하는 것입니다.



쉽고 빠르게 실시간 대응이 가능할 뿐만 아니라, 맞춤형 정보를 제공할 수 있는 채팅형 고객지원 서비스. 슬로워크도 점차 적극적으로 활용할 예정입니다. 앞으로 프로젝트 의뢰나 상담, 슬로워크에게 궁금한 점은 슬로워크 홈페이지의 채팅을 통해 문의해주세요!


참고자료

Inside Intercom - 5 simple messages to engage your customers



Posted by slowalk

개인, 기관 또는 단체에서 의뢰하는 웹사이트의 견적 문의에 대응하다 보면, 견적을 어떻게 요청해야 하는지 어려워하는 경우가 있습니다. 신규 웹사이트를 제작하려고 하거나 기존 웹사이트를 좀 더 나은 모습으로 바꾸려고 하는 경우, 웹사이트는 이미 보유하고 있지만 필요한 부분을 고치고 싶은데 스스로 할 수 없어 도움이 필요한 경우까지 다양한데요. 대표적으로 발생하는 상황을 바탕으로 좀 더 편하고 빠르게 견적을 문의하는 방법을 안내해드리겠습니다.


우린 아무런 홍보 채널이 없는데... 홈페이지를 만들어야 하나요? - 왜 만들어야 하는지 생각하고 홈페이지의 필요성을 결정하세요!


신규로 단체가 설립되었거나, 기성 조직이라도 IT기반 마케팅/커뮤니케이션 영역에 전혀 관심을 가지지 않다가 무언가를 하려고 했을 때, 가장 먼저 ‘어떤 목적을 가지고 이것을 시작하려고 하는가’를 생각해 보아야 합니다.


이제 막 시작한 조직이 저렴한 비용으로 존재감을 드러내거나 홍보를 해야 하는 경우를 살펴보겠습니다. 활동내역에 대한 안내와 고객과의 접점을 찾기 위한 수단으로 웹사이트 구축보다 먼저 SNS 페이지나 임대형 블로그 운영, 무료 웹사이트 제작 솔루션과 같은 저렴하지만 효과적인 방식을 고려해 볼 수 있습니다. 비유적으로, 출퇴근을 위해 저렴한 비용으로 구매할 차량이라면 연비가 좋아야 하고, 출력이 조금 낮더라도 크기가 작아 주차비나 수리비와 같은 운영 비용이 적게 드는 경차가 스포츠카나 SUV보다 나은 선택이 될 수 있는 것처럼 말입니다.


각각의 장/단점이 있지만 현재 시점에서 조직의 구성 상태와 투입가능한 인적/물적 자원을 검토할 수 있는 여력이 없어서 어떤 방식을 취해야 할지 모르겠다면, 우선 “구축에 관한 컨설팅”을 요청할 수 있습니다. 범위와 결과물에 따라 비용에 차이가 있지만, 문제를 해결하기 위한 원론적인 부분부터 함께 고민할 수 있기 때문입니다. 이에 따라 정확한 방향으로 작업이 가능하며, 모호한 내용을 가지고 무리하게 사업을 진행하는 것보다 오히려 비용을 절약할 수 있습니다.



서초자원봉사센터 티스토리 블로그 블로그로 기관에 대한 소개와 사업에 대한 홍보 등 제반 업무를 성공적으로 수행하고 있습니다.



블로그나 SNS로 운영하고 있었는데, 이젠 우리의 가치를 담은 웹사이트가 필요합니다! - 사이트를 완성했을 때 모습과, 운영할 때 꼭 필요한 기능이 무엇인지 고민해보세요!


기존에 블로그, SNS 페이지 등의 마이크로 사이트로 운영하던 매체가 있었지만 디자인, 레이아웃, 기능적 한계를 느껴 새로운 매체가 필요한 경우, 또는 새롭게 만들어진 기관이나 단체이지만 고유한 사업방식을 가지고 이를 온라인에서도 특정하게 적용해야 하는 경우입니다.


예를 들면, 1) 보유한 콘텐츠에 특정한 형태정보있어서 독립적인 포맷으로 노출되어야 할 필요가 있거나, 2) 고유한 레이아웃을 통해서 조직이나 사업의 성격을 드러내고 싶은 경우, 또는 3) 캠페인 성격을 지녀 아이덴티티가 확고히 드러나는 매체가 필요한 경우에 사이트가 필요할 수 있습니다. 이보다 더 나아가 4) 사업의 방식이 온라인을 통해 알려지고, 정보가 수집되며 사업의 프로세스가 웹사이트를 이용하는 사업방식이라면 더더욱 고유의 웹사이트가 필요할 것입니다.



에너지 히어로

스스로 웹사이트에서 손쉽게 참여하여 도움이 필요한 곳에 에너지를 기증할 수 있습니다.


‘어떠한 목적을 위해 웹사이트를 만드는가’라는 질문에 대한 답변을 할 수 있는지 확인이 되었다면, ‘어떤 모습의 웹사이트를 만들 것인가’를 찾아보는 과정이 필요합니다.


모방은 창조의 어머니라는 말이 있듯이 내가 원하는 모양, 형태, 구성 등과 유사한 사이트 또는 이상적인 모습을 가진 다른 사례들을 찾아보는 것이 실마리가 될 수 있습니다. 미리 준비된 벤치마킹 자료 및 참고가 될 만한 웹페이지와 같은 정확한 사례조사 자료는 추후 과업을 의뢰할 때 훨씬 빠른 의사소통과 방향성 수립에 큰 도움이 됩니다.



벤치마크 자료 서울시 웹사이트 UX/UI 가이드 개발을 위한 세계 20대 도시의 공식 홈페이지 분석표


이렇게 준비된 사례조사 자료를 토대로 실제 제작할 웹사이트의 “메뉴(Sitemap)”를 구성해 봅니다. 메뉴는 보통 내부에 존재하는 콘텐츠로 접근할 수 있는 경로구조의 집합을 말합니다. 이와 비슷하게 인식되지만 다른 개념으로 “정보구조(IA, Information Architecture)”가 있습니다. IA와 메뉴는 비슷할 수도, 완전히 다를 수 있습니다. IA를 통해 정의된 콘텐츠의 구조를 일목요연하게 사용자에게 제공하는 것이 바로 메뉴이기 때문입니다. 따라서 좀 더 쉽게 접근하기 위해 원하는 형태의 메뉴(Sitemap) 구조를 인지하기 편한 트리(tree)형태로 정의한 뒤 클라이언트와 개발주체가 함께 확인합니다. 이후에 각 메뉴가 연결될 페이지 또는 기능요소들을 정의하여 이를 구체화하거나 실현할 수 있는 방식을 각 개발주체들이 가진 고유의 방법론이나 기술력으로 제공하게 됩니다.



사이트맵(Sitemap)과 정보구조(IA) 예시


따라서 신규 사이트 제작을 위한 견적을 의뢰하기 전 레퍼런스나 참고 웹사이트의 자료들로 구성된 “사례조사” 내역과 이를 통해 도출된 “메뉴구조"를 문서화 하고, 나아가서 각 메뉴별 페이지나 요소가 수행하여야 할 “기능”들에 대해 정의된 문서를 견적 의뢰할 때 전달면 보다 정확한 투입인력에 대한 범위와 기간 산정이 가능합니다.


단, 1) 이러한 “정보구조(IA)"에 포함될 개별 콘텐츠가 미리 준비되어 있는가에 대한 판단과 2) 이를 생산 및 운용, 관리할 인력자원이 확보되어 있는지를 충분히 고려해야 합니다. 웹사이트는 연료를 넣으면 자동으로 움직이는 기계가 아니라 지속적인 운영과 콘텐츠의 생산 관리가 필요한 유기체와 유사하기 때문입니다. 예를 들어, 웹사이트에 한 개의 게시판이 추가될 때에 단순히 문서를 올려두는 공간의 분할에 그치는 것이 아니라 이 공간에 등록할 자료를 지속적으로 생산할 주체가 있는지 여부를 먼저 고려해야 합니다.


웹사이트를 이미 운영하고 있는데 필요한 것들을 좀 더 만들거나 수정해서 쓰고 싶어요. - 무엇으로 만들었는지, 어떤 일을 어느 범위까지 의뢰할 지 알려주세요!


이미 위와 같은 절차와 시간을 들여 웹사이트를 운영하기 시작했습니다. 그런데 실제 운영을 시작한 이후로 미처 고려하지 못했던 부분에서 새롭게 필요한 것이 발견되고 있습니다. 새롭게 부임한 총 책임자의 이력을 변경해야 하거나, 캠페인 신청접수를 받는 게시판을 별도로 만들 필요가 생기게 될 수도 있습니다. 신규 사업에 대한 메인페이지 배너를 만들어야 하는데 내부에는 그래픽 작업을 할 수 있는 사람이 없습니다…


이미 개발되어 사용중인 웹사이트의 지속적인 “운영”에 필요한 업무를 행하는 것을 “운영-유지보수” 업무라고 칭합니다. 보통의 경우, 웹사이트의 개발 이후 정상적인 계약을 체결하여 진행했다면 계약에 명시된 기간범위 내로 진행되는 “하자보수” 기간이 담보됩니다. 하자보수는 계약 시, 또는 사전 개발계약에서 약속했던 기능의 정상적인 작동이 되지 않아 이를 수정해야 하는 경우와 그래픽 오류, 오탈자의 수정과 같은 정도의 현상유지 업무를 통칭합니다. 반면에 운영-유지보수 업무는 이와 달리 미리 수행하기로 약속되었던 범위인지 아닌지에 따라 구분됩니다.


계약에 명시되지 않은 추가적인 과업이나 기능변경, 수정개발이 필요하거나 웹사이트의 정상적인 운영을 위해 필요한 기술적 용역이 필요하다면 우선 현재 웹사이트가 어떤 상황인지에 대한 파악이 필요합니다.


  1. 웹사이트의 위치: 웹호스팅 서비스 / 웹서버 보유 / 클라우드 서버 등

  2. 개발언어: ASP / PHP / JSP 등

  3. 사용된 프로그램 또는 프레임워크: 단순 HTML / 오픈소스CMS기반 /  상용CMS기반 등

  4. 내부 가용자원: 웹 담당자 존재 유/무 와 담당자의 웹 관련 이해도 수준


웹사이트를 개발한 주체와 운영-유지보수 업무를 의뢰하는 주체가 다른 경우에는 개발되어 있는 웹사이트의 구조를 알 수 없는 경우가 많으므로, 최소한 위 정보를 함께 제공하여 “설계분석”의 가능 여부부터 판단하는 것이 좋습니다. (이는 웹사이트 담당자의 관련 이해도가 낮다면 쉽게 준비하기 어려운 자료이므로 웹사이트 구축을 완료한 당시에 해당 정보를 정확하게 입수해 두는 것이 좋습니다.)


설계분석이란 구조를 파악하고, 수정을 요청하는 부분의 위치를 찾아 원하는 기능이나 형태를 구현하는 것이 가능한지 여부를 확인하는 1차적 단계입니다. 개발주체가 사용한 방법론이나 프로그램을 운영-유지보수 주체가 잘 이해하고 있는 경우에는 설계분석에 드는 비용과 시간이 절약될 수 있습니다. 따라서 기존 개발업체의 성격과 비슷한 수정 주체를 찾게되는 경우가 일반적입니다.


그러나 최초의 개발방식과 환경이 일반화 되어있지 않거나 라이선스를 별도로 가진 상용 소프트웨어로 구축된 경우, 코드를 분석하고 재조립하는 것 자체가 매우 어렵거나 불가능할 수 있습니다. 이런 경우 웹사이트를 새롭게 만드는 것이 수정하는 것 보다 비용을 절감하기도 합니다. 따라서 기존 웹사이트에 대한 정보를 정확하게 파악하고 있는 것이 중요합니다.


설계분석이 가능하고, 진행될 수 있다면 원하는 기능의 추가나 수정을 위해 어떤 곳에 무엇이 필요한지 설명할 수 있는 자료를 준비해야 합니다. 이는 웹사이트를 새로 만들 때의 방식과 유사합니다. 원활한 이해를 위해 사전에 준비한 유사사례를 제시하거나 절차와 로직(Logic)을 일반화시켜 의뢰를 받는 주체가 해석할 수 있는 형태의 문서를 준비하면 됩니다.


그래서, 얼마예요?


견적서의 구성

개발을 담당하는 주체의 방법론에 따라 다소 차이가 있지만, 웹사이트의 구축/수정에 관한 내용은 모두 사람이 수행하는 일이기 때문에, 가장 많은 비중을 차지하는 것이 바로 투입 인력에 관한 “인건비” 입니다. 인건비는 수행하는 인력의 기술수준에 따라 비용에 차등을 주는 것이 일반적이며, 사업 발주처와 수행주체 간 협의에 의해 최종 결정됩니다. 하지만 국내에서는 보통 한국소프트웨어산업협회 SW기술자 노임단가"를 기준으로 하는 경우가 많습니다. 해당 노임단가는 지급되는 임금을 말하며, 실제 견적서에는 투입인력에 대한 제경비와 발생 매출에 대한 부가가치세를 포함하게 되므로 위 단가표에 30~120%의 비용이 함께 추가됩니다.


이와 다른 방식으로 개발이 필요한 기능의 기능점수(FP: Function Point)를 이용한 견적 방식이 있습니다. FP 견적방식은 개발이 필요한 기능을 일괄 목록화하고, 각 개별 기능에 주어진 점수를 부여하여 이를 개발언어와 방식, 난이도, 위험에 따른 안정성 담보 등급에 따라 보정계수를 적용하여 최종 산출하는 방식입니다. 개념 자체는 매우 합리적이지만, 실제 기능목록을 측정하는 방식이 일반화되어 있지 않고, 견적을 냈을 때 기존 인건비 산정방식에 비해 매우 높은 비용차이가 발생한다는 한계가 있습니다. 실제 실무에 적용되기 보다는 공공영역에서의 사업비용 측정과 예산 타당성 측정에서 주로 사용되는 편입니다.



마치며

지금까지 웹사이트뿐만 아니라 일반적인 소프트웨어 개발에서 사용되는 개발 프로세스를 일반화하여 적용시켰을 때 사용될 수 있는 몇 가지의 사례를 들어 보았습니다. 사업범위나 성격에 따라 위 내용과 다른 방식의 접근방법이 사용될 수도 있지만, 가장 중요한 것은 ‘목적'에 따른 ‘기능'의 정의와 이를 ‘운영/관리'할 자원이 충분한지를 고려해야 한다는 점입니다. 우리의 프로젝트는 UX와 UI에 앞서 이를 사용할 대상인 고객 또는 사용자에게 올바르고 정확한 ‘콘텐츠'를 전달하는 매개를 만드는 것이라는 점을 항상 마음에 두고 있어야 할 것입니다.



Posted by slowalk

이 글은 코알못의 스케치 플러그인 개발 도전기 (1) - 시작하기에서 이어지는 글입니다. 지난 글에서는 스케치(Sketch) 플러그인을 개발하기 위해 플러그인의 구조와 플러그인 개발을 위해 필요한 것들을 알아봤습니다.


이제 만들어보겠습니다.


  1. 스케치는 MacOS용 애플리케이션이며 플러그인도 MacOS에서만 개발할 수 있습니다. 이 글도 MacOS를 기준으로 작성됐습니다.
  2. 이 글은 스케치 플러그인 개발 방법을 설명하는 글이 아니라 말그대로 ‘개발 도전기'입니다. 코딩을 모르는 사람도 간단한 스케치 플러그인을 개발할 수 있다는 것을 전달하기 위한 것입니다.
  3. 코알못의 스케치 플러그인 개발 도전기 (1) - 시작하기를 먼저 읽어보는 것을 권장합니다.



뭘 만들지?


개발 과정이 순탄하지 않겠지만, 가장 먼저 뭘 만들지 정해야 합니다. 가장 쉬운 방법은 내가 불편했던 것에서부터 시작하는 것입니다. 적어도 나한테는 필요한 것을 만드는 것이기 때문에 순탄하지 않은 개발 과정에서 동기부여가 될 뿐만 아니라 스스로가 사용자로서 기능에 대한 정확한 피드백을 줄 수 있기 때문입니다.


물론 더욱 많은 사람에게 필요한 게 무엇인지 생각해보면 좋겠지만, 이건 어디까지나 개발을 해본다는 것이 목적이기 때문에 너무 깊은 고민은 하지 않았습니다.


스케치를 사용하면서 불편하다고 느꼈던 것 중 하나는, 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export(내보내기) 할 수 없다는 것이었습니다. 다른 것들도 많았지만 그리 복잡한 로직이 필요하지 않아보였기 때문에 플러그인 개발 도전기의 대상으로 낙점했습니다. (물론 모든 기획이 이렇게 단순한 발상과 근거로 진행되지 않거니와, 이렇게 단순한 발상과 근거로 진행된다고 해서 꼭 좋은 결과로 이어지는 것도 아닙니다.)


그럼 “복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다"는 문제를 좀 더 자세히 알아보겠습니다.


우선 제가 저런 작업을 해야했던 이유는 다음과 같습니다.


스티비 런칭을 위한 초기버전 개발이 한창이던 때, 스케치로 와이어프레임을 만들고 이를 인비전(Invision)으로 Export 해서 디자이너, 개발자와 커뮤니케이션을 했었는데, 세부적인 기능이나 시나리오에 대한 정의를 전달하기 어렵다고 느꼈습니다. 그래서 스케치로 와이이프레임을 만들되, 인비전이 아닌 다른 도구를 활용하여 세부적인 기능이나 시나리오에 대한 정의를 전달하기로 했고, 결과적으로는 보편적인 방식인 - 벗어나고 싶었던 - “화면기획서"를, 구글 프레젠테이션으로 만들기로 했습니다.



누구를 위한 화면기획서인가



정리하면 다음과 같습니다.

  1. 스케치로 와이어프레임 제작 (1개 화면 = 1개 아트보드)
  2. 화면 단위인 아트보드를 이미지 파일로 Export
  3. 이미지 파일을 구글 프레젠테이션에 삽입하고 기능, 시나리오 등에 대한 상세 정의를 추가


이런 상황에서 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다는 것은 큰 불편을 초래했습니다. 아트보드를 복수 선택하는 것은 가능하지만 페이지를 복수 선택할 수는 없었기 때문에, 20여 개의 페이지를 하나씩 선택한 뒤 아트보드를 선택해서 Export 해야했습니다.


그래서 페이지를 하나씩 선택하지 않고 모든 아트보드를 한 번에 Export 할 수 있다면 좋겠다는 생각이 든 것이죠.



근데 이걸 꼭 내가 만들어야 하나?


이미 솔루션이 나와있다면 굳이 고생해서 만들 필요는 없겠죠. 그래서 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다는 문제를 해결할 수 있는 다른 솔루션은 없는지 찾아봤습니다.


  1. 이런 기능을 제공하는 플러그인이 있는지 찾아봤습니다. Export를 편리하게 하는 플러그인들이 있긴 했지만 복수의 페이지에 속한 모든 아트보드를 한 번에 Export하는 플러그인은 찾지 못했습니다.
  2. 스케치에 유사한 기능 - “Export Artboards to PDF”- 이 있다는 걸 알게됐습니다. 하지만 1) PDF로 저장된다는 점과 2) 선택한 페이지에 있는 아트보드만 Export 하기 때문에 결국 페이지를 하나씩 선택해가면서 Export해야한다는 점에서, 제가 느꼈던 문제를 완전히 해결해줄 수는 없었습니다.


1에서 유사한 플러그인이 있는지 찾아보는 것이 중요한 다른 이유는, 이런 플러그인에서 유사한 기능을 어떻게 구현했는지를 알면 내가 필요한 플러그인을 개발할 때도 도움이 되기 때문입니다.


여전히 과연 나 말고 누가 이런 기능을 필요로 하겠냐는 의구심이 들고 있지만, 어쨌든 나는 필요하고, 다른 솔루션은 없으니, 일단 만들어보기로 했습니다.



그럼 본격적으로 만들어보겠습니다.


일단 위에서 얘기한 복수의 페이지를 선택해서 그 페이지들에 속한 아트보드를 한 번에 Export 할 수 없다는 문제를 해결할 수 있는 논리적인 과정을 생각해봤습니다.


  1. 플러그인을 실행합니다.
  2. 페이지를 조회합니다. (조회한 모든 페이지에 대해 A, B를 반복 실행합니다.)
    1. 페이지를 선택합니다.
    2. 선택한 페이지의 아트보드를 조회합니다. (조회한 모든 아트보드에 대해 I, II를 반복 실행합니다.)
      1. 아트보드를 선택합니다.
      2. Export 합니다.
  3. 플러그인을 종료합니다.


요는 2와 2-B의 반복실행 단계를 자동화한다는 것입니다.


그럼 먼저 위의 내용으로 구성한 코드를 살펴보겠습니다. 이해를 돕기위해 위의 내용을 그대로 주석으로 옮겼습니다. (스케치 플러그인의 파일 구조를 잘 모르겠다면 스케치 플러그인 개발 도전기 (1) - 시작하기를 먼저 읽어보세요.)



위 코드는 아직 동작하는 코드는 아닙니다. 일단 기본적인 내용으로 구성해본 것입니다. 실제로 동작하게 하려면 몇 가지 고려해야 할 것들이 있습니다.


  1. 스케치 플러그인으로 실행되기 위한 함수를 정의합니다. (모든 스케치 플러그인의 스크립트에 공통적으로 필요한 내용입니다.)
  2. 열려있는 스케치 문서를 조회합니다. (모든 스케치 플러그인의 스크립트에 공통적으로 필요한 내용입니다.)
  3. 아트보드에 미리 정의된 Export 설정값을 초기화합니다. (사용자가 Export 설정 값을 따로 정의해놨다면 저장되는 이미지마다 크기가 다를 수 있기 때문에, 이를 무시하기 위한 것입니다.) 방법은 다음과 같습니다.
    1. 선택한 아트보드를 복제합니다.
    2. 복제한 아트보드의 Export 설정값을 초기화합니다.
    3. 복제한 아트보드를 삭제합니다.
  4. 이미지를 저장할 경로를 정의합니다. 방법은 다음과 같습니다.
    1. 저장 경로에 사용하기 위해 페이지 이름을 조회합니다.
    2. 저장 경로에 사용하기 위해 아트보드 이름을 조회합니다.


그럼 위의 내용을 코드에 추가해보겠습니다. 역시 이해를 돕기위해 위의 내용을 그대로 주석으로 옮겼습니다.



아직 한 가지 빠진 게 있습니다. 바로 이미지를 저장할 경로를 정의하기 위해 사용자가 경로를 선택하는(파일을 저장할 때 파인더에서 폴더를 선택하는) 과정입니다.


완성된 코드입니다.



완성된 플러그인 패키지는 여기에서 내려받을 수 있습니다. 이미지 저장 경로 선택 및 호출과 Export 부분의 코드는 Quick Export를 참고했습니다.



스케치 플러그인 개발을 통해 얻은 것


안타깝게도 글을 쓰기 시작했던 시점과 달리, 지금은 스티비 팀의 개발 프로세스가 바뀌었고, 화면기획서를 만들고 있지 않고, 스케치로 작업한 모든 UI/GUI 관련 산출물은 제플린(Zeplin) 또는 인비전 인스펙트(Invision Inspect)로 Export 해서 확인하고 있습니다. 그래서 이번에 만든 플러그인은 이제 쓸 일이 없어졌습니다 (누군가에겐 쓸모가 있었으면 하지만 애초에 나 말고 누가 쓸까 하는 마음이었기 때문에 기대는 하지 않습니다.)


그럼에도 의미가 있었던 건, 코드에 대한 거부감을 줄일 수 있었다는 것입니다.


간단하게나마 스케치 플러그인을 개발해보면서 코드를 구성하는 논리적인 사고의 과정을 경험해볼 수 있었습니다. 문제점을 해결하기 위한 아이디어를 “문장의 나열"이 아닌 “논리적인 구조"로 만들어본다면, 개발자와의 커뮤니케이션이 한층 수월해지지 않을까요?


꼭 스케치 플러그인일 필요는 없습니다. 비개발자가 코딩을 비교적 쉽게 경험해볼 수 있는 다양한 도구가 존재합니다. 프레이머(Framer)도 그중 하나입니다. 자신의 필요에 맞게 - 화면기획서를 만들기 위해 스케치를 사용하면서 느꼈던 불편함에서 출발했던 이 글처럼 - 선택하면 됩니다. 일단 시작해보세요!



참고

The Beginner’s Guide to Writing Sketch Plugins Part 2 — User Notifications

Sketch Developer Reference

Quick Export


작성: 임호열

Posted by slowalk



슬랙(Slack)은 다양한 협업이 이루어지고 있는 슬로워커의 메시지 툴입니다. (참고: 업무용 메신저 슬랙(Slack), 슬로워크는 이렇게 사용합니다.) 슬랙은 멤버들끼리의 자유로운 협업을 도모하는 다양한 기능을 탑재하고 있는데요. 지난 슬랙봇으로 슬랙 200% 활용하기에 이어, 이번에는 슬랙의 기본 기능인 커뮤니케이션 측면에 중점을 두어 슬로워커가 사용하고 있는 슬랙봇(Slack bots)을 소개합니다.


여러 번 물어보지 않고 결정하기: 폴리(polly)





Polly를 이용해 빠른 설문이 필요한 이슈들을 대화창에 만들어 공유할 수있습니다. 슬랙 검색창을 통해, 슬로워커들은 Polly를 주로 어떻게 사용하고 있는지 검색해봤습니다. 약 70% 정도가 약속 시간을 정할 때 유용하게 사용하고 있습니다.





슬로워크xUFOfactory의 시각디자인 프로젝트로 진행된 <다양력>프로젝트를 진행하면서도 Polly를 통해 간편하게 투표를 진행했습니다. 세트 이름을 선정할 때, 내부 투표를 진행했습니다. 이처럼 다소 가벼운 주제에 대해서는 구글 설문을 만들어 이메일로 요청하기보다 간단하게 봇을 사용하여 참여율을 높일 수 있습니다.



‘완료했습니다!’ 말하지 않고 완료하기: 지라(JIRA)





JIRA(소프트웨어를 개발하는 팀에 특화된 프로젝트 관리 툴) 봇을 슬랙과 연동하면, 팀원들의 테스크 진행상황들을 메시지로 받아 볼 수 있습니다. 또한 개인이 어떤 테스크를 진행하고 있는지, 완료했는지 공유 않아도 JIRA 봇이 알아서 진행상황들을 공유해 주기 때문에, 번거로움이 사라집니다.


제가 속해 있는 웹 개발팀은 외주개발자와 협업을 하는 경우도 있습니다. 외주개발자와의 협업은 서로의 대한 신뢰와 책임감이 프로젝트의 완성도를 좌우하는데요. 완성도를 높이기 위해서는 프로젝트 기간동안 소통이 가장 중요합니다. JIRA 봇을 사용하면, 디자이너와 웹개발자가 진행되고 있는 스텝들을 공유할 수 있고 서로 진행했는지 여부를 묻지 않아도 되기 때문에  프로젝트를 원활하게 진행할 수 있습니다.



이메일은 메시지로 간편하게 확인하기: 이메일(email)




Email 봇을 통해 이메일 알림도 슬랙 메시지로 받아볼 수 있습니다. Email 봇은 팀 이메일 계정을 팀 채널과 연결해 함께 이메일을 확인하고, 이슈 대응을 빠르게 할 수 있게끔 도와줍니다. 슬로워크 슬랙 채널 중에 #inbox 채널이 있습니다. 슬로워크 대표메일인 slowalk@slowalk.co.kr 로 수신된 이메일을 메시지로 받아볼 수 있는 채널입니다. 슬로워크 대표메일로 도착한 이메일을 한 명의 담당자가 처리하는 구조가 아니라, 모두가 열어보고, 팔로업 할 수 있도록 지원해준 셈입니다.



Star 버튼 클릭으로 웹레퍼런스 관리하기: 포고(Pogo)



우리는 유용한 웹 레퍼런스를 발견하면, 내 슬랙 계정으로 보내두거나, 이메일로 보내두거나, 에버노트에 저장하거나 다양한 방법으로 그때그때 웹 레퍼런스를 관리했습니다. (참고 : 웹에서 찾은 레퍼런스, 어떻게 관리하세요?) Pogo는 계속 나와 멀어지고 있는 웹 레퍼런스를 늘 나와 가까이 있도록 도와줍니다.






Pogo는 단순히 star 버튼을 클릭함으로, 아카이브가 됩니다. 슬랙 채널에서 /Pogo-find ‘text’ 를 입력하면, 아카이브된 내용 중에서 검색한 텍스트를 가진 레퍼런스를 찾아줍니다. 메시지 내용 이외에 웹레퍼런스를 저장하고 싶다면,  /Pogo-save ‘text’ 로 쉽게 저장 가능합니다. 아카이브된 웹 레퍼런스들은 @Pogo DM 화면에서 쉽게 볼 수있으며, Pogo 웹에서도 확인 가능합니다.



이제는 회의시간 잘 지키기: 구글 캘린더(Google Calendar)





구글 캘린더(Google Calendar) 봇은 매일 아침 10시, 저의 오늘 일정들을 메시지로 공유해줍니다. 매일 아침 10시에 daily summaries 메시지를 받고 업무를 시작하면, 우선순위를 다시 한번 더 생각하고 업무를 처리할 수 있어 유용합니다.




구글 캘린더 봇은 Weekly summaries도 원하는 요일/시간에 슬랙 메시지로 받을 수있습니다.



우리 모두의 시간은 소중합니다. 구글 캘린더 봇을 설정할 때, 이벤트 리마인더는 꼭 설정하고, 회의에 늦지 않게 준비하면 좋습니다.



슬랙 뉴스레터 받아보기: 슬랙 플랫폼 뉴스(Slack Platform News)




Slack Platform News

슬랙은 슬랙의 소식까지 슬랙으로 보냅니다. 2주에 한 번 정도 보내는 슬랙의 소식은 슬랙의 다양한 이용 팁이나, 슬랙 블로그에 발행되고 있는 포스팅을 메시지로 보내줍니다. 현재 메시징 툴로 슬랙을 이용하고 있다면, 슬랙의 뉴스레터는 꼭 받아보세요. 새로 출시된 슬랙봇의 정보나 슬랙을 다양한 방법으로 사용하고 있는 유저의 스토리를 확인 할 수있습니다.



(출처 - Slack)


슬랙의 브랜드 슬로건 ‘Be less busy’는 제가 슬로워크에서 일하면서 실현되고 있습니다. 이 슬로건은 저에게 소모적인 일들을 단순하게 처리해준다는 의미로 다가왔습니다. 저는 이 글을 쓰면서도 다양한 슬랙 메시지를 받아보고 있습니다. 그 중에는 동료가 보내는 메시지도 있지만, 슬랙봇이 보내는 메시지도 있습니다. 슬랙봇은 세팅하는 데 번거로움이 조금 따르지만, 업무를 조금 더 즐겁게 해줍니다.




출처 및 참고 사이트


슬랙 공식 홈페이지 www.slack.com


슬랙 블로그 www.slackhq.com


슬랙 앱 디렉토리 www.slack.com/apps




*슬로워크에서 웹기획자 겸 프로젝트매니저를 채용하고 있습니다(~채용시까지). 슬랙봇을 활용한 업무 커뮤니케이션 그 이상을 직접 경험해보세요! [채용공고 확인하기]


Posted by slowalk

혹시 git(깃)이라고 들어보셨나요? IT에 종사하거나 프로그래밍을 업으로 삼고 계신 분들은 알고 계실 텐데요. 오늘은 git을 처음 들어보신 분들이나, 써보려 했으나 진입장벽이 너무 높아 엄두가 안나셨던 분들을 위해 간략하게 git을 소개하고 활용하는 방법에 대해 알아보도록 하겠습니다(초보자 분들의 조금 더 쉬운 이해를 돕기 위해 git의 개념을 제 나름대로 재해석하였습니다).



git?

git은 분산 버전(이력)관리 시스템 입니다. 두 가지 기능이 합쳐져 있는데요. 바로 분산과 버전관리입니다. 자, 그럼 먼저 버전관리란 무엇일까요?

우리는 일상에서 알게 모르게 버전관리를 하고 있습니다. 간단한 예로, 학교 발표자료나 리포트를 작성한다고 했을 때, 여러분의 폴더 모습은 아마 아래와 같을 것입니다.

 

작성 중간중간 다른 이름으로 자주 저장해 두어야 정전과 같은 사태로 자료가 유실되는 불상사를 막을 수 있고, 잘못 수정된 자료가 있다면 과거 기록을 바탕으로 복원할 수 있겠죠? 위와 같이, 특정 시점을 기억하고 이를 재활용할 수 있게 규칙을 정해 파일을 관리하는 것을 버전(이력)관리라고 합니다.

그렇다면 분산은? 말그대로 내가 관리하는 문서를 여러 장소로 나누어 저장한다는 뜻입니다. git은 아래 그림과 같이 네트워크를 통해 연결된 다른 컴퓨터에 문서를 분산하여 관리할 수 있는 기능을 제공합니다.



문서를 분산하여 저장하면 어떤 장점이 있을까요? 만약 하나의 컴퓨터에서 문서를 저장/관리하는데 그 컴퓨터가 고장난다면, 해당 문서는 다시 볼 수 없게 될지도 모릅니다. 따라서 문서를 여러 장소에 나누어 보관한다면 위와 같은 상황이 발생해도 안전하게 문서를 복구할 수 있지요. 하지만 git의 분산 기능은 문서의 안정성만을 위한것이 아닙니다. git이 분산기능을 통해 구현하고자 하는 바는 바로 ‘협업’입니다.

예를 들어 1000페이지 분량의 논문이 있고, 이를 검수 및 수정하는 작업을 진행한다고 하겠습니다. 한 명이 하루에 검수 할 수 있는 양이 100페이지라 했을 때, 이 작업은 10일이 소요됩니다. 이를 5명이 나누어 진행한다면, 2일의 시간만이 소요될 겁니다.

또한, 5명 각자 동등하게 200페이지씩, 검수를 진행한다면 git을 쓰지 않아도 아무 문제가 없습니다. 다만 문서를 동등하게 분배하는 과정과 분배된 문서를 다시 하나의 문서로 합치는 불편함이 발생하겠네요! 그리고 동등한 200페이지라고 말은 하였지만, 작업의 양이 모두에게 공평하게 돌아가지 않았을 것입니다. 대부분의 문서는 처음과 끝부분에 목차와 색인 등이 있어서 분량이 적을 수도 있으니까요.

이렇듯 누군가는 조금 더 빠른 시간에 작업을 끝낼 수도 있고, 그 사람은 모든 작업이 끝날 때까지는 하나의 문서로 합치는 작업 또한 진행하지 못할 겁니다. 그 사람은 시간을 허투루 소모하고 있는 것이죠. 그렇다고 중간에 다른 사람이 작업하던 것을 다시 쪼개서 일을 하자니 그 비용이 더 들지도 모릅니다. 이렇듯 문서(작업)의 분배와 병합, 그리고 다른 사람의 작업 진행 정도를 파악하는 것이 협업의 가장 큰 걸림돌이라면 이를 손쉽게 만들어 주는 것이 git의 역할입니다!

git은 분산 기능을 통해 5명 모두가 하나의 문서를 동시에 편집할 수 있게 지원하고, 각자의 작업 내용을 기록으로 남겨 모두가 공유할 수 있습니다. 더 멋진 점은 동시 편집 중에 동일한 내용을 서로가 다르게 수정하였다면, 이를 자동으로 감지하여 `누구의 것으로 최종 병합할 것인가?`와 같은 기능을 제공하여 보다 손쉽게 협업을 진행할 수 있습니다.

git 기초 개념

git이 파일을 관리하는 단위는 “폴더(디렉토리)” 입니다. 특정 폴더를 저장소(repository)로 지정하면, 해당 폴더에 저장되는 파일과 하위 폴더들이 git이 관리하는 대상이 됩니다. 앞서 말씀드린 발표자료 예시처럼 하나의 파일만 이력관리를 하는 것이 아니라 여러 파일과 폴더를 묶어서 이력을 관리할 수 있습니다.

자 그럼 이제부터 git이 파일을 어떻게 추적하고 관리하는지 알아보도록 하겠습니다. git은 파일을 untracked, tracked, unstaged, staged 네 가지 상태로 관리합니다.

특정 폴더를 저장소(repository)로 지정하고 나면, 그 시점부터 해당 폴더에 생성(외부로부터 복사/이동 포함)되는 모든 파일들은 untracked 상태로 관리됩니다. untracked는 git이 “해당 파일은 이력관리 대상에서 제외된 파일이다.” 라고 생각하는 상태입니다. 따라서 untracked 상태의 파일 중, 이력관리를 하고싶은 파일이 있다면 git의 특정 명령어를 통해 tracked 상태로 변경해주어야 합니다(쉽게 말해, git에게 ‘앞으로 이 파일은 내가 이력을 관리할 파일이니까 변화를 잘 감시하고 있어!’ 라고 요청하는 것입니다).

이후, tracked로 변경된 파일은 staged 또는 unstaged의 상태만을 갖게 됩니다. tracked 상태의 파일이 수정이 되면 git은 이를 자동으로 감지하여 unstaged 상태로 변경시킵니다. unstaged 상태는 git이 해당 파일을 이력관리 대상으로 포함하고 있으나, 이력저장(commit) 행위를 할때는 제외되는 상태입니다. 이력저장(commit) 행위를 할때 저장되는 파일은 오직 staged 상태의 파일만 저장되는 점을 기억하시기 바랍니다.

다시 한 번 요약하자면,

  • untracked: git이 이력관리대상에서 제외한 파일

  • tracked: git이 이력관리대상으로 포함한 파일이며 다음과 같은 상태를 가진다.

    • staged: 이력저장(commit)을 할때 저장되는 파일

    • unstaged: git이 관리대상으로 포함한 파일이나 staged 상태가 아니므로 이력저장(commit)을 할때 저장 대상에서 제외되는 파일


앞서, git이 파일을 관리하는 네 가지 상태에 대해서만 말씀을 드렸는데요, 좀 더 중요한 개념이 있습니다. 바로 이력저장(commit)이라는 행위인데요. 이후 나오는 이력저장(commit) 행위에 대해서는 커밋 또는 commit이라고 통칭하겠습니다.

커밋을 설명하기 앞서, 혹시 나비효과 라는 영화를 아시나요? 그 영화에서 주인공은 자신이 쓴 일기를 통해 과거로 돌아갈 수 있습니다. 여기서 일기를 쓰는 행위가 바로 커밋입니다. git에서 커밋이란 그 당시 저장소의 폴더 및 파일 내용을 그대로 저장해 두는 행위이며, 당시 상황을 기억하기 위해 메모를 함께 기술합니다. 예를 들면 “A라는 파일에 B라는 내용을 추가했음”과 같이요. 그리고 나비효과 영화의 주인공 처럼 과거의 일기(커밋)를 보고 과거로 돌아갈 수 있습니다. 따라서 우리는 이러한 커밋을 통해 과거 시점으로 돌아가 삭제된 파일을 복구하거나, 과거로 부터 파일의 내용이 어떻게 변화되어 왔는지 추적 및 관리할 수 있습니다.

git 설치

그럼 이제부터 git을 본격적으로 사용하기 위해서 git을 설치해보도록 하겠습니다. git은 윈도우, 리눅스, 맥 등 대부분의 OS에서 설치하여 사용할 수 있게 개발되었지만, 이 글에서는 윈도우를 기준으로 설명 드리도록 하겠습니다.

윈도우에서 git을 사용하기 위한 다양한 프로그램이 존재합니다. 그 중 대표적인 것이 Git for Windows 입니다. 저는 이 프로그램을 사용하여 git을 설치해 보도록 하겠습니다.

먼저, 해당 사이트를 방문 하시어 프로그램을 다운받아 주세요. 다운로드가 완료되면 셋업파일을 더블클릭하여 설치를 진행합니다.저는 디폴트 옵션(무조건 Next)으로 설치를 진행하였습니다. 설치가 완료되면, 바탕화면이나 폴더 내에서 마우스 우클릭을 해봅니다.

[그림 1] Git 메뉴가 추가된 컨텍스트 메뉴



[그림 1]과 같이 컨텍스트 메뉴에 “Git GUI Here”와 “Git Bash Here”가 보이면 설치가 정상적으로 완료된 것입니다.

git 사용법

git을 사용하는 방법에는 두 가지가 있습니다. 바로 GUI 프로그램을 이용하거나 git 명령어를 이용하면 됩니다.

둘 중, 저는 git 명령어를 통해 사용법을 설명드릴 것입니다. 그 이유는 git GUI 프로그램은 다양한 이름으로 개발되어 있으며, 어떤 프로그램을 설치 하느냐에 따라서 사용법이 조금씩 다를 수 있기 때문입니다. 그리고 이런 GUI 프로그램들 또한 명령어를 기반으로 동작하기 때문에, git 명령어를 숙달하신다면 어떤 환경에서든 동일한 방법으로 git을 사용하실 수 있을 것입니다.

 

자, 그럼 지금부터 명령어를 통해 git의 사용법을 알아보도록 하겠습니다.

1. 저장소 생성

git을 사용하기 위해서 가장 먼저 선행되어야 하는 일은 저장소 생성하기 입니다.

git은 폴더(디렉토리) 단위로 저장소를 생성할 수 있습니다.

그럼, 지금부터 실습을 위해 애국가라는 저장소를 생성해보도록 하겠습니다.

첫번째로 내가 원하는 경로에 “애국가” 라는 폴더를 생성합니다.

그 다음, 해당 폴더를 마우스로 우클릭을 한 뒤, 표시되는 컨텍스트 메뉴에서 “Git Bash Here” 를 선택합니다.

[그림 2] 애국가 폴더로 이동 후, 마우스 우클릭 -> Git Bash Here



[그림 3] Git Bash Here CLI 명령어 창



마지막으로 [그림3]과 같은 CLI 창이 생성되었으면, 아래의 명령어를 입력합니다.

git init

“Initialized empty Git repository in …” 과 같은 출력이 나오면 정상적으로 저장소가 생성된 것입니다. 윈도우 탐색기로 해당 폴더를 보면, 숨김폴더로 .git이라는 폴더가 생성되어 있는 것을 확인하실 수 있습니다.

[그림4] git 저장소가 생성된 애국가 폴더

2. 파일의 생성

생성된 저장소에는 일반 폴더와 마찬가지로 파일을 생성, 수정, 삭제할 수 있습니다.

하지만 일반 폴더와 저장소의 차이점은 무엇일까요?

바로 저장소내에 생성된 파일은 git이 관리해준다는 점입니다.

저장소에 파일이 처음 생성되었을 경우, git은 해당 파일을 untracked 상태로 관리합니다.

정말 그런지 확인해 볼까요? 그럼 애국가 저장소내에 “애국가1절.txt” 이라는 텍스트 파일을 생성해 보도록 하겠습니다.

[그림 5] 애국가 저장소에 생성된 애국가1절.txt 파일



파일이 생성되었다면 아래의 명령어로 파일의 상태를 조회할 수 있습니다.

git status

[그림 6] git status 명령어로 확인해본 애국가1절.txt


예상대로 untracked 상태로 나오네요. 그럼 “애국가1절.txt” 파일을 git의 버전관리 대상(tracked 상태)으로 만들어 보겠습니다.

파일의 상태를 tracked 상태로 변경하고 싶다면, 아래의 명령어를 사용하면 됩니다.

git add [untracked 상태의 파일명]

[그림 7] git add 명령어를 통한 파일 상태 변경


add 명령어를 통해 파일의 상태를 변경하였다면 status 명령어로 파일의 상태를 다시한번 확인해보시기 바랍니다. 아마도 [그림 7]과 같이 “애국가1절.txt” 파일이 초록색(tracked 상태)으로 변경되었을 겁니다.

3. 파일의 수정

이제 “애국가1절.txt”는 git의 이력관리 대상이 되었습니다. 그럼 이 상태에서 파일을 수정하면 어떻게 될까요? 현재는 아무 내용도 없는 “애국가1절.txt”파일에 애국가 1절 가사를 입력한 뒤 저장해 보겠습니다.

[그림 8] 애국가1절 추가 및 저장


status 명령어를 통해 상태를 살펴보니 unstaged 상태로 변경되었네요.

[그림 9] 파일 내용이 변경되어 unstaged 상태가 된 애국가1절.txt

4. 일기를 쓰자: 커밋

tracked 상태의 파일은 수정이 되면 git이 자동으로 감지하여 unstaged 상태로 변경시킵니다.

따라서 해당 파일은 커밋 대상에서 제외가 됩니다.

수정된 파일을 다시 커밋 대상으로 포함시키기 위해서는 앞서 untracked 파일을 tracked 파일로 변경시킬 때 사용하였던 add 명령어를 다시 사용하면 됩니다.

git add [unstaged 상태의 파일명]

[그림 10] git add 명령어를 통하여 다시 staged 상태로 된 애국가1절.txt

지금까지 애국가를 1절을 작성하는 고된 작업이 끝나고나니 이 상태를 보관하고 싶어졌습니다.

앞서 나비효과 영화로 예로 들었던, 지금 이 순간을 일기로 남겨서 나중에 과거로 시간여행을 할 수 있게 말이죠!

커밋은 git이 현재 추적(tracked)하고 있는 파일중 staged 상태의 파일만 골라서 일기로 남기는 행위입니다.

자! 그럼 아래의 명령어를 통해 일기를 남겨 보시죠~

git commit -m ‘오늘의 일기~ 날씨 맑음

애국가 1절 작성 했음, 매우 힘들었음.’

커밋을 할때는 -m 옵션을 반드시 명시 하셔야 됩니다. 해당 옵션은 일기 내용이라고 생각하시면 되는데요. 일주일전 내가 뭘했는지 기억하실 수 있나요? 네, 저같은 평범한 사람들은 엊그제 먹은 점심도 기억 안 나기 마련이니까 과거를 되짚어 보기 위해서는 -m 옵션으로 로그를 반드시 기록해주셔야 합니다. 꼼꼼하고 자세하게 기록할 수록 기억이 좀더 명확해지겠죠?

이렇게 commit 명령으로 저장된 현재 상태는 커밋아이디가 부여되고 이를 통해 다른 커밋과 구분할 수 있는데요. 아래의 명령어를 통해 확인하실 수 있습니다.

git log

[그림 11] git log 명령어로 커밋메세지와 commit id 확인


커밋아이디는 git이 중복되지 않게 생성 및 부여하므로 여러분은 신경 쓸 필요가 없습니다. 그리고 이 커밋아이디를 통해 우리는 과거로 돌아가는 마법을 부릴 수 있습니다.

5. 마법의 주문: 체크아웃

앞서 “애국가1절.txt” 문서를 생성하고 커밋을 했죠? 만약에 제가 전날 과음을 하여 실수로 어렵게 작성한 “애국가1절.txt”를 삭제하고 말았습니다. 그럼 다시 “애국가1절.txt”를 새로 작성해야 할까요? 아닙니다. 우리에게는 git이 있으니까요!

일단, 실험을 위해 저장소내의 “애국가1절.txt”를 삭제해 보도록 하겠습니다.

[그림 12] 사라진 애국가1절.txt


“애국가1절.txt” 파일이 사라지면 git은 어떻게 판단할까요? status 명령어로 확인해보겠습니다.

[그림 13] git status로 확인된 deleted 상태의 애국가1절.txt


[그림 13]과 같이 “애국가1절.txt”가 지워졌다고 하네요.

이 상태에서 “git add 애국가1절.txt” 명령어를 수행하고, commit을 하면 “애국가1절.txt” 파일이  사라진 상태를 커밋으로 남기게 됩니다.

해볼까요? “애국가1절.txt”가 사라진 시점을 커밋해 보도록 하겠습니다.

[그림 14] git add & commit 명령어를 통해 애국가1절.txt가 사라진 시점을 커밋


만약 앞으로도 “애국가1절.txt”가 필요없다고 하면 이상태를 유지하면서 작업하면 되겠죠? 하지만 실수로 인해 “애국가1절.txt”이 사라졌다고 가정하였으니 이를 복원해 보도록 하겠습니다.

“애국가1절.txt”를 복원하려면 과거로 돌아가야겠죠?

과거로 돌아가기 위해서 필요한 것은 checkout 명령어와 가고싶은 시점의 커밋아이디 입니다.

git checkout [커밋아이디]

돌아가고 싶은 커밋 시점을 알기 위해서 git log 명령어를 통해 커밋아이디를 확인해보도록 하겠습니다.

[그림 15] git log 명령어로 조회해본 커밋 기록들


git log 명령어로 조회해본 결과 저희는 두건의 커밋 기록이 있네요.

“애국가1절.txt” 문서가 삭제된 커밋과 1절을 위키피디아에서 작성하여 저장한 시점의 커밋이 있습니다. 제가 돌아가고 싶은 시점은 문서가 생성되고 저장된, 커밋아이디 ebf484...가 되겠네요.

git checkout [커밋아이디] 명령어를 쓰실 때, 꼭 커밋아이디 전체를 입력하지 않아도 됩니다.

앞부분의 몇자리만 입력하여도 겹치는 아이디가 없으면 git이 알아서 판단하여 해당 시점으로 파일 상태를 되돌립니다.

[그림 16] git checkout 명령어로 커밋 시점 되돌리기


git의 커밋 시점이 변경되었습니다. 그럼 윈도우 탐색기로 해당 폴더를 다시 볼까요?

[그림 17] git checkout 명령어를 통해 과거 커밋 시점으로 돌아가 파일이 원복된 모습



checkout 명령어를 통해 과거 커밋 시점으로 되돌아가니 파일이 그대로 존재합니다!

하지만 이것은 임시로 과거 시점으로 돌아가 “애국가1절.txt”가 복원된 것이지 현재 작업하고 있는 시점으로 되돌아간다면 다시 사라지게 될 것입니다. 따라서 과거 시점으로 돌아가 되살리고 싶은 파일을 확인하였다면, 다음과 같은 명령어로 과거 커밋시점의 파일을 현재 작업 시점으로 되살릴 수 있습니다.

git checkout [커밋아이디] [파일명]

위 명령어로 파일을 복원하기 앞서, 우리는 과거 커밋시점인 ebf484...에 있습니다.


그렇다면 과거 커밋으로 돌아가기 전인, 마지막 작업 시점으로 돌아가려면 어떻게 해야 할까요? 이때는 다음과 같은 명령어로 현재로 돌아갈 수 있습니다.

git checkout master

여기서 master는 git의 커밋아이디를 뜻하는 것은 아니고, 브랜치라는 개념인데요. 이 부분까지 설명드리자면 글의 분량이 너무너무 길어지기 때문에 다음에 자세히 다루도록 하겠습니다. 그냥 마지막으로 ‘작업하던 시점으로 돌아갈때는 git checkout master를 사용한다!’ 라고 기억해 두시기 바랍니다.

[그림 18] git checkout master 명령을 통해 마지막 작업 시점으로 복귀


마지막 작업 시점으로 돌아오고나니 받아들이고 싶지 않은 현실이 있습니다. “애국가1절.txt”가 다시 사라져 있습니다. 그렇다고 당황하지 마시고, 위에서 설명드린 git checkout <과거commit id> <복원하고픈 파일명> 으로 파일을 되살려 보겠습니다.

[그림 19] checkout <과거commit id> <복원하고픈 파일명> 명령어로 되살린 파일


위의 명령어를 수행하고 나니 “애국가1절.txt”가 복원되었습니다! git status 명령어로 파일 상태를 확인하니 unstaged네요. 그렇다면 git add 명령어로 파일을 staged 상태로 만든 뒤, 커밋한다면 지금 상태 또한 새로운  커밋으로 저장할 수 있겠습니다!

이렇듯, git은 파일의 백업 및 복구 뿐만아니라 과거 이력을 조회하고 재사용하는 등, 다양하게  활용될 수 있습니다.

마무리

지금까지 git에 대한 가장 기초적인 명령어와 개념에 대해 설명드렸는데요, 사실 git을 제대로 활용하려면 꽤 많이 공부해야 합니다. 이번 글에서 설명드린 git의 기능은 정말 빙산의 일각에 불과한 데요. 그만큼 제대로 공부하면 무궁무진하게 활용 가능한 것이 git입니다!

초기 진입장벽이 높아 초보자 분들께서는 사용할 엄두를 못내고 계신 분들도 많은데요. 이 글을 통해 조금이나마 장벽이 낮춰졌으면 하고, 조금 더 나아가 git에 대해서 호기심을 가지고 공부를 시작하셨으면 좋겠습니다!


작성: 이학진

Posted by slowalk