얼마전부터 antirez twitter에서 radix tree 관련 트윗이 올라왔습니다. 얼마 지나지 않아 antirez가 radix tree를 구현한 rax 프로젝트를 공개하고 redis의 cluster hash_slot의 저장구조를 radix tree로 수정 되는것을 보았습니다.그동안 antirez의 코드 읽으면서 배우는 게 많았고, 자료구조에 관심이 많아서 살펴보기 시작했습니다. radix tree를 왜 구현 했는지, 어떻게 구현쟀는지 알아보고 radix tree를 redis에 어떻게 적용하였는지도 알아보겠습니다.antirez는 redis의 hash-slot -> key 구조에서 중복으로 인한 메모리 사용을 줄이기 위해 radix tree 를 만들었다고 합니다. 이 포스트에선 rax를 적용시킨 redis cluster로 이야기를 진행 하겠습니다.“현재는 hash-slot -> key에만 사용되지만 추후에는 다양한 곳에 사용 예정”이라는 트윗redis cluster?redis에는 cluster 기능이 있습니다.6대 이상의 redis 노드를 cluster 구성하면(최소 leader 3대, follower 3대 구성해야 cluster 가능) 16384개의 hash_slot이 노드 갯수에 맞게 분배가 됩니다. 즉 3대의 leader로 cluster 구성하면 각각의 leader는 0 ~ 5460, 5461 ~ 10922, 10923 ~ 16383 hash_slot을 나눠 가집니다.cluster 구성 후 client가 데이터 저장/삭제/조회 명령어를 redis server에 전송할 때 마다 key의 hash값을 구하고 어떤 leader hash_slot에 포함되는지 찾습니다.# example 127.0.0.1:7000> set hello world # hash_slot = crc16("hello") & 0x3FFF 계산된 값이 현재 접속한 leader의 hash_slot 범위에 있다면 그대로 실행 되지만 다른 leader의 hash_slot 이라면 에러를 발생하고 다른 leader로 이동하라고 힌트를 줍니다.cluster 구성 후에 노드를 추가 하거나 제거 할 경우 각 leader의 hash_slot을 재분배 하고, hash_slot에 맞게 key도 재분배 되어야 합니다. 단순하게 생각하면 leader의 hash_slot 재분배한 후 모든 key를 재계산하고 hash_slot에 맞는 leader에 할당 하는 겁니다.[현재까지 저장된 keys].forEach(v => { hash_slot = crc16(v) & 0x3FFF // leader에 할당된 hash_slot에 맞게 분배 }) 하지만 antirez는 redis Sorted set 데이터 타입의 구현체인 skiplist 을 이용하여 문제를 풀었습니다. skiplist는 member와 score를 저장하고, score를 기준으로 정렬합니다. skiplist의 member에는 key를 저장하고 score에는 key의 hash_slot을 저장합니다.(변수명 slots_to_keys)slots_to_keys 정보는 cluster 구성된 모든 노드가 저장합니다. 이후 재분배가 필요해지면 16384개 hash_slot을 leader 갯수에 맞게 재분배 하고 slots_to_keys에 저장된 “key:hash_slot” 정보를 가지고 해당 hash_slot의 key를 조회 및 재분배 합니다. 즉 slots_to_keys에 이용하여 재분배시 발생하는 계산을 없앤것입니다.잘 했구만 뭐가 문제냐?redis에 key가 추가/삭제 될때마다 slots_to_keys에 데이터가 저장되고 지워집니다. redis에 저장되는 key 갯수가 증가 할수록 slots_to_keys의 크기도 커짐을 의미 합니다.(※ 메모리 사용량)또한 leader 갯수에 맞게 16384개 hash_slot을 leader에 재분배하고, 각 hash_slot에 맞는 key를 찾고 할당 합니다. 예를들어 slots_to_keys에서 score 0인(hash_slot 0을 의미) member를 조회해서 0번 hash_slot에 할당, score 1인 member를 조회해서 1번 hash_slot에 할당 하는 방식으로 0 ~ 16383 hash_slot을 진행합니다.앞에서 말한 hash_slot에 속한 key를 조회 하는 GETKEYSINSLOT 명령어가 있는데 여기에 이슈가 있습니다.cluster GETKEYSINSLOT slot count # slot: hash_slot 번호 # count: 특정 hash_slot에서 조회할 key 갯수 # example 127.0.0.1:7000> cluster GETKEYSINSLOT 0 3 # 0번 hash_slot의 key를 3개 조회한다. "47344|273766|70329104160040|key_39015" "47344|273766|70329104160040|key_89793" "47344|273766|70329104160040|key_92937" 사용자가 특정 hash_slot에 몇개의 key가 저장 되었는지 모르기때문에 count에 Integer.MAX 를 대입하는데, redis는 hash_slot에 실제로 저장된 key 갯수와는 상관없이 client가 전달한 count만큼의 메모리를 할당합니다.} else if (!strcasecmp(c->argv[1]->ptr,"getkeysinslot") && c->argc == 4) { /* cluster GETKEYSINSLOT */ long long maxkeys, slot; unsigned int numkeys, j; robj **keys; // ... 명령어의 4번째 인자를 maxkeys에 할당, 즉 사용자가 입력한 count if (getLongLongFromObjectOrReply(c,c->argv[3],&maxkeys,NULL) != C_OK) return; // ... keys = zmalloc(sizeof(robj*)*maxkeys); numkeys = getKeysInSlot(slot, keys, maxkeys); addReplyMultiBulkLen(c,numkeys); for (j = 0; j < numkeys>zmalloc maxkeyscluster GETKEYSINSLOT unnecessarily allocates memory그래서 메모리도 적게 차지하면서(압축 가능) key와 key의 hashslot을 효율적으로 저장 및 조회가 가능한 자료구조가 필요했고 antirez는 radix tree를 선택합니다.※ 뜬금 없는데 2012년, redis 자료형에 Trie를 추가한 P/R이 생각났습니다.radix tree 구현한 rax 알아보기시작하기전 radix tree (Wikipedia) 위키 페이지의 그림을 보고 감을 잡은 후에 아래를 보시면 잘 읽힙니다.자! 이제부터 rax의 주석과 코드를 보면서 어떻게 구현됐는지 알아보겠습니다.Noderax의 노드 구성은 다음과 같습니다.typedef struct raxNode { uint32_t iskey:1; /* Does this node contain a key? */ uint32_t isnull:1; /* Associated value is NULL (don't store it). */ uint32_t iscompr:1; /* Node is compressed. */ uint32_t size:29; /* Number of children, or compressed string len. */ unsigned char data[]; } raxNode; 노드의 정보를 담고있는 32 bit(iskey, isnull, iscompr, size)와 key/value 그리고 자식 노드의 포인터를 저장하는 unsigned char data[]가 있습니다. 특이한 점은 key/value를 동일한 노드에 저장 하지 않고 key가 저장된 노드의 자식 노드에 value를 저장합니다.※ 사진 출처위 그림을 예로 32 bit 정보가 어떤걸 의미하는지 알아보겠습니다.iskey는 노드가 key의 종착역(iskey:1)인지 중간역(iskey:0)인지 나타내는 flag입니다. 1, 3 노드는 iskey:0 이고 2, 4, 5, 6, 7 노드는 iskey:1이 됩니다.isnull은 value의 null 여부를 표시합니다. unsigned char data[]에 key/value 그리고 자식 노드의 포인터를 저장하므로 value를 찾으려면 계산이 들어갑니다. 불필요한 연산을 줄이기 위해 만든 필드 같습니다.Trie는 각 노드에 한글자씩 표현 하지만 Radix는 압축을 통해 한 노드에 여러 글자 표현이 가능합니다. 이를 나태내는 플래그 iscompr 입니다. 노드가 압축된 노드(iscompr:1)인지 아닌지(iscompr:0)를 나타냅니다.size는 iscompr 값에 따라 의미가 다릅니다. iscompr이 1이면 저장된 key의 길이를 의미하고 iscompr이 0이면 자식노드의 갯수(저장된 key의 갯수)를 의미합니다.위 4개 정보를 이용해서 한 노드의 크기를 구하는 코드는 아래와 같습니다.#define raxNodeCurrentLength(n) ( \ sizeof(raxNode)+(n)->size+ \ ((n)->iscompr ? sizeof(raxNode*) : sizeof(raxNode*)*(n)->size)+ \ (((n)->iskey && !(n)->isnull)*sizeof(void*)) \ ) ※ 노드에 value 주소를 저장하거나, 마지막 자식 노드 포인터를 알고 싶을때 사용합니다.FindraxLowWalk 함수를 이용해 key가 존재 하는지 판단합니다.size_t raxLowWalk(rax *rax, unsigned char *s, size_t len, raxNode **stopnode, raxNode ***plink, int *splitpos, raxStack *ts) rax에 “ANNIBALE” -> “SCO” -> [] 로 저장 되어있을때 어떤 값을 리턴하는지 알아보겠습니다.*s 가 “ANNIBALESCO”이고 len이 11 인 경우# splitpos: 0, return value: 11 "ANNIBALE" -> "SCO" -> [] ^ | *stopnode *s가 “ANNIBALETCO”이고 len이 11인 경우# splitpos: 0, return value: 9 "ANNIBALE" -> "SCO" -> [] ^ | *stopnode *s의 길이 len과 return value가 같다면 rax에 key가 존재하는 것입니다. *s의 길이 len과 return value가 다른 경우 어디까지 매칭됐는지 보여주는 return value와 어떤 노드에 어디까지 일치했는지 표현하는 *stopnode, splitpos를 통해 추가 정보를 얻을수 있습니다.InsertraxLowWalk 함수를 이용해서 저장할 위치를 찾습니다. (*stopnode, splitpos, return value)1번에서 구해진 데이터를 이용해서 새로운 노드 생성 및 링크를 연결합니다.rax에 “ANNIBALE” -> “SCO” -> [] 상태에서 “ANNIENTARE”를 저장하는 과정입니다.1. raxLowWalk 함수를 이용하여 저장할 위치 탐색 splitpos: 4, return value: 4 "ANNIBALE" -> "SCO" -> [] ^ | *stopnode 2. *stopnode, splitpos 데이터를 이용하여 노드 분리 "ANNI" -> "B" -> "ALE" -> [] 3. iscompr: 0인 노드 "B"를 기준으로 새로운 key 저장 ("B"와 "E"는 같은 노드) |B| -> "ALE" -> [] "ANNI" -> |-| |E| -> "NTARE" -> [] RemoveraxLowWalk 함수를 이용해서 저장할 위치를 찾습니다. (*stopnode, splitpos, return value)1번에서 구해진 데이터를 이용해서 노드 제거 및 compress가 가능다면2가지 경우가 있습니다.마지막 노드만 iskey: 1이고, 연속으로 iscompr:1인 노드가 된 경우마지막 노드만 iskey: 1이고, iscompr:1 -> iscomplr:0 -> iscomplr:1 노드 구조가 된 경우입니다.첫번째 경우를 알아 보겠습니다. rax에 “FOO” -> “BAR” -> [] 상태에서 “FOO”를 지우는 과정입니다.1. raxLowWalk 함수를 이용하여 저장할 위치 탐색 splitpos: 3, return value: 3 "FOO" -> "BAR" -> [] ^ | *stopnode 2. 해당 key 삭제, 여기서는 자식노드가 있으므로 노드 삭제는 하지 않고 노드의 iskey: 0으로 세팅 "FOO" -> "BAR" -> [] 3. compress가 가능한 경우 진행 "FOOBAR" -> [] 두번째 경우를 알아 보겠습니다.0. "FOOBAR"와 "FOOTER"가 저장된 상황입니다. FOOTER를 지우는 경우입니다. |B| -> "AR" -> [] "FOO" -> |-| |T| -> "ER" -> [] 1. raxLowWalk 함수를 이용하여 저장할 위치 탐색 splitpos: 0, return value: 6 |B| -> "AR" -> [] "FOO" -> |-| |T| -> "ER" -> [] ^ | *stopnode 2. 해당 key 삭제 "FOO" -> "B" -> "AR" -> [] 3. compress가 가능한 경우 진행 "FOOBAR" -> [] cluster 정보는 어떻게 저장되나?기존 skiplist 자료구조를 이용했던게 어떻게 변경 되었는지 알아보겠습니다.server.cluster->slots_keys_count[hashslot] += add ? 1 : -1; if (keylen+2 > 64) indexed = zmalloc(keylen+2); indexed[0] = (hashslot >> 8) & 0xff; indexed[1] = hashslot & 0xff; memcpy(indexed+2,key->ptr,keylen); if (add) { raxInsert(server.cluster->slots_to_keys,indexed,keylen+2,NULL,NULL); } else { raxRemove(server.cluster->slots_to_keys,indexed,keylen+2,NULL); } 먼저 slots_keys_count 변수를 이용하여 각 hash_slot의 key 갯수를 저장합니다.그리고 key는 hash_slot(2 byte) + key, value는 NULL로 rax에 저장하여 특정 hash_slot에 속한 key 조회를 쉽게 만들었습니다.마치며rax 구현과 rax가 어떻게 redis에 적용됐는지 보면서 오랜만에 재밌게 코드를 읽은것 같습니다. 개인적으로 데이터 관련 유용한 무언가를 만드는게 목표인데, 이런 좋은 코드들을 하나 둘씩 제것으로 만드는것도 과정이라 생각하며 진행했습니다.앞으로 rax가 redis에서 어떻게 쓰일지 흥미롭고, Redis를 Saas 형태로 제공하는 업체들이 언제 적용할지도 궁금합니다.긴 글 읽어주셔서 감사합니다.cluster, rax 관련 antirez twitterRedis cluster Insertion cluster Issuesame amount data hash table vs radix treehashset + ziplist -> radix tree + listpack 1/5replace Hashset with Radix treeraxNode에서 사용한 flexible memberflexible memberrax 를 이용한 Redis Streams(2017.12.17일 업데이트)Redis Stream#잔디 #토스랩 #JANDI #기술스택 #도입후기 #Redis #인사이트

이 포스팅은 총 4부로 이어지며 현재는 4부입니다.1부 : Android, MVC, MVVM, MVP2부 : Android 와 Annotation3부 : AndroidAnnotations 과 MVC4부 : AndroidAnnotations 과 테스트앞선 3개의 포스팅을 통해 AndroidAnnotations 과 MVC 가 view 에 관여하는 동작들이 모두 View 로 분리된 것을 확인할 수 있습니다.이러한 구조덕분에 Model 에 대한 테스트와 View 에 대한 테스트가 명확히 구분지어지게 되었습니다.Test 코드를 작성함에 있어서 View 에 대한 테스트가 다소 어려움이 있다는 것을 감안한다면 Model 에 대한 테스트만 집중할 수 있는 구조가 테스트에 대한 접근을 더욱 쉽게 해줍니다.다음은 앞선 포스팅에서 정의된 코드 중에서 Model 에 대한 테스트입니다.※ 테스트코드는 Robolectric 을 이용하여 작성하도록 하겠습니다.Model Test@RunWith(RobolectricGradleTestRunner.class) public class MainModelTest { private MainModel mainModel; @Setup public void init() { mainModel = new MainModel(Robolectric.application); } @Test public void testGetReleaseState() { // given String version = "3.19" // not yet released // when boolean isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(false)); // given version = "3.18" // released // when isReleased = mainModel.getReleaseState(version); // then assertThat(isReleased, is(equalTo(true)); } }위와 같이 Model 만 별도로 테스트가 용이해졌습니다.Presenter TestPresenter 에 대한 테스트는 Model 에 대한 테스트와 다릅니다.Activity 에 커플링이 높기 때문에 해당 Activity 를 직접 바인딩해야 합니다.@RunWith(RobolectricGradleTestRunner.class) public class MainViewTest { private MainActivity mainActivity; private MainView MainView; @Setup public void init() { mainActivity = Robolectric.buildActivity(MainActivity.class).create().start().resume().get(); MainView = mainActivity.mainView; } @Test public void testGetVersionText() { // given String version = "3.19" // when MainView.versionEditText.setText(version); // then assertThat(MainView.getVersionText(), is(equalTo(version)); } }Jandi Team은 View 를 테스트하기 위해서 Presenter 와 Activity 의 패키지 Level 을 같은 Level 로 유지하고 있습니다.AndroidAnnotations 에서 DI 를 설정하기 위해서는 해당 변수나 메소드는 최소 Package Scope 로 정의해야하기에 위와 같은 형태의 Field 접근을 볼 수 있습니다.정리AndroidAnnotations 를 활용한 MVC 패턴의 전환의 또다른 이점은 이와 같이 테스트를 명확히 분리할 수 있다는 장점을 주었습니다. 물론 이 방법은 MVVM, MVP 로 구현하였을때보다 나은 형태라 할 수는 없으나 View 에 대한 테스트가 좀 더 용이해진 것이라 생각합니다.※ Activity 는 왜 테스트하지 않나요?MVP 패턴에서 Activity는 Controller 의 모습을 지니고 있습니다. 이는 Unit Test 가 아닌 Behavior 테스트에 가까운 모습이며 다른 방식으로의 테스트코드 구현이 필요하다고 생각합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #기술스택 #일지 #후기 #꿀팁 #인사이트

게임 개발자국내 게임 산업에서 모바일 게임의 매출액은 2011년 4235억원에서 2013년 2조3276억원으로 2년 만에 6배 가까이로 늘어났습니다.(출처:한국콘텐츠진흥원) 한국 모바일 게임은 해외에서도 인기를 끌고 있는 추세입니다. 뿐만 아니라 최근 엄청난 인기를 끌고있는 배틀그라운드는 한국 게임 산업의 가능성을 증명합니다. 배틀그라운드는 작년 한 해 7621억원의 수익을 거두면서 2017년 가장 큰 수익을 거둔 PC 게임 패키지 1위를 차지했습니다.배틀그라운드의 일러스트게임을 좋아하는 사람이라면 한번쯤은 게임 개발에 관심을 가져보았을 것입니다. 특히 프로그래밍을 하는 사람이라면 자신의 게임을 만들어보고 싶다는 생각을 해보거나, 게임 회사에서 일 하는 것을 고려해보았을 것입니다. 그러나 한편으로는 압도적인 근무 시간에 대한 부담으로 게임 개발자가 되겠다는 생각을 접게 되신 분들도 많습니다.이번 포스팅은 게임 개발자에게 필요한 역량이 무엇인지 알아보고, 게임 개발자의 두 가지 커리어 종류에 대해 설명하려고 합니다. 또한 지금 당장, 코딩을 전혀 할 줄 모르는 상태에서 게임 개발에 도전해볼 수 있는 방법 또한 소개해드리겠습니다.게임 개발자에게 필요한 역량게임을 만들기 위해서는 그래픽을 다루는 능력, 스토리와 레벨을 기획하는 능력, 3D 모델링, 그래픽 엔진을 다루는 능력 등 많은 영역들에서 전문성을 필요로 합니다. 물론 이 모든 것을 전문적으로 다루는 사람이 되기란 불가능에 가깝습니다. 그렇기 때문에 스토리라인과 컨셉 구성은 기획자가 담당하고, 기획자의 아이디어는 개발자와 그래픽 디자이너의 손을 거쳐 게임의 모습을 갖춥니다. 그래픽 디자이너가 시각적 구현을 맡는다면, 개발자는 PC나 모바일에서 게임이 실행될 수 있도록 만드는 작업을 하게되는 것입니다. 게임 개발자도 결국 개발자 직군의 일환이기 때문에 일반적으로 개발자들이 많이 다루는 언어에 대한 숙련도나 프로그래밍 능력이 필요합니다. 그러나 게임 개발자의 경우 다른 직군의 개발자에게는 필수적이지 않은 지식을 필요로 할 때가 있습니다. 아래에는 특히 게임 개발자들에게 중요한 세 가지 요소입니다. 1. 프로그래밍 언어대부분의 대규모 게임 회사들은 C++을 가장 많이 사용합니다. 모바일 게임이 대세로 더오르면서 C#을사용하는 경우가 많아진 것은 사실입니다. 그러나 PC, 모바일, 비행기 제어 프로그램까지 폭넓게 지원하는 고성능의 3D 게임을 개발하기 위해서는 여전히 C++이 최적이라는 평가를 받습니다. 주의할 점은 C/C++은 계속해서 발전하고 있는 언어라는 점입니다. 언어를 배우기 위한 서적, 인터넷 강의 등은 무궁무진하지만 중요한 것은 최신의 것을 배워야 한다는 점입니다.2. 게임 엔진게임 엔진은 간단하게 말해 게임을 개발하는 과정을 쉽게 만드는 ‘도구’입니다. 중력 같은 기본적인 물리 효과나 오브젝트 사이의 충돌 여부를 판정하는 ‘컬라이더’ 등, 개발에 필요한 기본적인 기능이 탑재되어있기 때문에 게임 엔진은 개발 과정을 획기적으로 단축시켜줍니다. 가장 많이 쓰이는 게임 엔진은 유니티와 언리얼입니다.이 글을 읽고 있을 대부분의 분들이 개발을 배우는 과정에 있다는 가정하에 학습의 용이함을 기준으로 비교해보면, 유니티의 경우 공식적으로 지원하는 교육 프로젝트의 수는 9개입니다. 그러나 공식적인 자료 외에도 한글 서적이나 온라인 강좌들은 매우 풍부합니다. 반면에 언리얼이 제공하는 공식 교육 프로젝트는 수십개입니다. 대부분이 한글 자막을 지원해줄 뿐만 아니라 다양한 주제를 경험할 수 있습니다. 언리얼의 한계라면 공식 채널 외에서 학습할 수 있는 자료나 커뮤니티가 아직까지는 많지 않다는 점입니다. 3. 수학게임 개발자에게 수학은 매우 중요하고도 기본적인 것입니다. 특히 3D 게임을 다루고 싶다면 수학적 지식과 역량은 매우 중요한 부분을 차지할 것입니다. 물론 위에서 말한 게임 엔진이 수학적인 계산이나 물리와 관련된 문제들을 해결해 줄 수는 있습니다. 그러나 게임 엔진을 활용한다 하더라도 기본적으로 그것이 어떻게 작동하는지는 이해해야 합니다. 그렇기 때문에 이산 수학, 즉 벡터, 행렬, 집합, 논리 연산 등에는 능숙할 필요가 있습니다. 게임 개발자의 커리어게임 개발자가 되기 위한 길이 게임 회사에 취직하는 것만 있는 것은 아닙니다. 최근에는 크게 성공하는 인디 게임, 즉 대규모 회사가 아닌 저예산의 1인기업 혹은 작은 팀단위로 만들어 내는 게임들의 사례가 늘어나고 있습니다. 게임 회사에 취직하는 것만큼 확실한 방법이 없다는 생각을 갖고 계신 분들, 혹은 자신만의 게임을 만드는 것에 강한 매력을 느끼시는 분들을 위해 두 가지 커리어 옵션을 비교해 보았습니다.1. 대규모 게임 회사대부분의 게임 개발자가 특정 회사에 소속되어 일을 합니다. 회사에 소속되어 있기에 안정적인 수입이 보장된다는 것이 첫번째 장점이라면, 두번째 장점은 혼자서는 절대 만들 수 없는 규모의 게임을 개발하는 데에 기여할 수 있다는 점입니다. 한 마디로 말해 완성도 있고 유명한 게임에 일조 했다는 자부심을 가질 수 있게 되는 것입니다. 또한 주니어 개발자로서 풍부한 경험을 가진 시니어 개발자를 포함해 배울 점이 많은 사람들로 구성된 팀에 소속될 수 있다는 것 또한 큰 장점입니다.한편 회사의 크기가 큰 경우에는 각 사람이 맡는 개발의 영역이 매우 세분화 되어있기 마련입니다. 자신이 느끼기에는 조금 지루하고 단순한 일이라고 생각되는 일을 맡게 될 수도 있습니다. 그러나 반대로 말하면 디자인, 기획, 마케팅 등 개발 외의 업무 등에 신경을 쓰지 않고 오직 자신의 일에 집중할 수 있는 환경이 제공되는 것이기도 합니다.2. 인디게임 개발규모가 있는 회사에 취직하는 것이 아니더라도 게임을 만들 수 있는 방법은 많습니다. 또한 안정적인 수입이 보장된 것은 아니지만, 성공하는 경우 생각는 것보다 그 수익이 큽니다. 예를 들어 트리오브라이프를 개발한 오드윈게임즈는 1년 간 20억의 매출에 도달했습니다. 단지 한 사람이 2주 동안 만든 게임, 숨바꼭질은 한 달만에 5000만원의 수익을 냈습니다. 물론, 이를 성공 신화에 불과하다고 말할 수도 있기 때문에 분명히 감수해야 하는 위험이 있는 커리어인 것이 사실입니다. 인디 게임 간에도 경쟁이 매우 치열하기 때문입니다.그럼에도 불구하고 소규모로, 혹은 혼자서 게임을 개발하는 사람들은 게임에 대한 애착을 가지고 개발 과정 전체를 아우르며 작업할 수 있다는 점에서 만족감을 느낍니다. 특히 투자 규모나 시기에 구애를 받지 않고 개성적인 게임, 만들고 싶은 게임을 만들 수 있다는 것이 장점이라고 할 수 있습니다. 지금 시작하기게임 개발을 하고 싶은데 어디서 시작해야 하는지를 막막해하고 있다면, 무조건 일단 만들어보기 시작하는 것이 중요합니다. 자신의 아이디어, 혹은 이미 있는 게임들을 가지고 점점 난이도를 높여가며 여러 프로젝트를 실행해 보는 것이 좋습니다. 이는 실력을 쌓는 데에도 도움이 되지만, 이후에 훌륭한 포트폴리오가 되기도 합니다.일단 만들어보라는 조언도 막막하신 분들을 위해 준비한 것은 무료로 사용할 수 있는 게임 개발 프로그램들입니다. 코딩을 전혀 할 줄 모르는 사람부터 완성도 있는 게임을 만들고 싶어하는 사람들까지 다양한 수준에서 접근할 수 있는 도구들을 소개해드리겠습니다.1.Flow CreatorFlow Creator는 코딩을 해본 적이 없어도 간단한 드래그앤드롭으로 게임을 만들 수 있는 웹사이트입니다. 시각적으로 논리적 구조를 짤 수 있기 때문에 어떤 언어도 배워본 적이 없어도 됩니다. 무료 버전의 경우 5개의 레벨, 50개의 개체로 제한이 되어있지만 유료 버전의 경우 앱으로 만들어 스토어에 올릴 수도 있습니다.2. StencylStencyl도 Flow Creator와 마찬가지로 프로그래밍 언어가 아니라 Stencyl의 사용법만 잘 익히면 훌륭한 게임을 만들 수 있습니다. 사용법이 Flow Creator에 비해 좀더 까다로운 것은 사실이지만 결과물의 완성도가 더 높습니다. 또한 이미 만들어져있는 코드블록 외에도 직접 코드를 작성하고 라이브러리를 불러오는 등 확장할 수 있는 가능성도 있습니다.3. Game Maker StudioGame Maker는 위의 두 가지 프로그램처럼 드랙 앤 드롭으로 만들 수 있지만, Game Maker Language(GML)이라는 자체 언어를 활용하여 만들 수도 있습니다. GML을 사용해서 게임을 만드는 것은 프로그래밍을 학습하는 데에도 도움이 될 것입니다.게임 개발자의 종류는 정말 많다.오늘 포스팅에서 언급한 게임 개발자는 일부입니다. 게임 개발자의 종류에는 온라인 게임, 모바일 게임, 콘솔 게임 등 정말 다양하고 무궁무진합니다. 여러분들이 어떤 게임 개발자가 되고 싶든 중요한 것은 게임에 대한 열정인 것 같습니다. 자신이 정말 하고 싶고 좋아하는 게임을 만든다는 것은 세상에 의미있는 프로그램을 만드는 개발자만큼이나 행복한 개발자겠지요. 다음 편에는 더 재밌는 개발자 직군으로 찾아오겠습니다.

올해 2월에 썼던 글을 이제야 올려봅니다. 태블로는 아직 잘 사용하고 있습니다. : )“아무개 님, 지난번에 요청한 자료 언제까지 받을 수 있죠?”다행이다. 꿈 이었다.가벼운 발걸음으로 출근하던 중 일감 하나가 떠오른다. 간밤의 꿈이 꿈 만은 아니었던게다.아뿔싸, 아직 시작도 못했는데.오늘 할 일을 내일로 미룬 자의 아침은 발걸음이 무겁다.Business Intelligence 라는 것이 있다. 뭔가 멋드러진 단어의 조합처럼 보이지만, 현실은 그리 아름답지 않다. 대부분의 시간을 비슷한 일을 반복하며 숫자를 맞춰야하고 엑셀과 SQL 에 빠져 살기 일쑤다. 잘못된 데이터라도 발견되면 이걸 어디서부터 수습해야 하나 고민해야 한다. (끝이 없는 재귀호출)반복, 반복, 반복. 비용을 줄이자.반복은 비용이다. 한두번 반복되는 일을 최적화 하는 것은 최적화 자체가 비용 이겠지만, 매일같이 반복되는 일, 주기적으로 찾아야 하는 데이터들은 그 자체만으로도 최적화의 대상이다.특히나, 아직 성장하고 있는 ‘스타트업’ 이라면 회사의 데이터가 잘 정리되어 있을리 만무하다. 몇몇 데이터는 잘 관리되고 있겠지만, 상당수는 흩어져 있을 것이다. 어느 순간을 지나면 이들을 모으는 게 일이 되어버린다. 임계점을 넘어서버린 일을 한다는 것은 손을 더럽히는 일이 된다는 뜻이기도 하다. 아무쪼록 그대에게 이 임계점을 분간할 지혜가 있기를.시간 비용을 절약하자스타트업의 구성원들에게 가장 중요한 것은 무엇일까? 나의 짧은 생각으로는 사람과 시간이라고 생각된다. 이 중에서 BI 툴이 해결해 줄 수 있는 것은 무엇일까?나 스스로에게 질문해보니 이런 답이 나온다. ‘사람은 쉽게 바뀌지 않는다’ 그럼 시간은? 다행히, 시간은 모두에게 공평하게 주어진다.‘그럼 이 시간을 아껴보자!’여기에 하나 더, 내가 모르는 것이 있었다.앞으로 회사가 데이터를 다루는 스펙트럼을 얘상할 수 없다는 것이다.Zeppelin무엇을 사용할까 고민하던 중 가장 먼저 떠오른 것은 다름 아닌 제플린 이었다.< 이 형님들 말고 >(출처 : http://fortune.com/2016/07/26/led-zeppelin-stairway-heaven-appeal/)아파치 제플린은 한국에서 시작해 아파치 인큐베이터에 들어간 오픈소스 데이터 분석 및 시각화 툴 이다.장점은 개발자에게 익숙한 노트북 기반이라는 것과 강력한 인터프리터를 통해 다양한 데이터 소스에 접근할 수 있다는 것이다.나프다 팟캐스트에서 들은 내용인데, 트위터의 경우 태블로에서 제플린으로 갈아탔다는 이야기도 있었다.기본적으로 프로그래밍이 가능하기 때문에 어떤 형태의 데이터를 요구해도 제공할 수 있다는 장점도 있다.물론, 단점도 있다. 먼저 시각화 부분이 약하다는 것이다. D3.js 를 같이 사용하면 보완할 수 있지만 개발자의 꾸준한 지원이 있어야 할 것이었다.더불어, 비개발자들에겐 노트북 형태로 데이터를 가공하는 것에 진입장벽이 있다고 생각 했다.한번쯤 사용해보고 싶었지만 개발 리소스가 부족한 우리 상황에는 맞지 않다고 생각했기에 다음을 기약해본다.Spotfire, Amazon Quicksight, Google Data Studio다음으로 찾아본 툴 들은 바다 건너에서 잘 사용 되는 몇가지 것들 이었다.Spotfire 는 레퍼런스도 충분했지만 다음에 등장한 강력한 후보로 인해 제외됬다.아마존 퀵사이트는 잠깐 사용해봤지만 회사의 요구사항을 맞추는데 부적절해 보였다.구글의 데이터 스튜디오 역시 기능에 제약이 많았다.아마존과 구글의 솔루션은 무료로 사용할 수 있거나 가격이 합리적이라는 장점도 있었다.Spotfire 역시 비싸지 않은 가격이었다.태블로, 그리고 plotly태블로는 동료 직원의 지인 중 사용해본 분이 있어서 직접 만나서 여러가지를 물어볼 수 있었다. 나중에 알았지만 한국에 공식 총판이 있어서 메일로 문의하면 다양한 안내를 받을 수 있었다.태블로는 장점이 많은 툴이다. 다양한 데이터 소스를 지원하며, 강력한 시각화를 통해 데이터를 분석할 수 있다.데이터를 유연하게 다룰 수 있어서 여러가지 인사이트를 얻는데 도움을 줄 것이라 생각됐다.온라인 튜토리얼도 잘 되어있고, 한국에서 오프라인으로 기초교육도 받을 수 있다.종합적으로 비교해 본 결과 비슷한 성격의 툴 중에선 가장 강력한 툴 이었다.유일한 단점이라면 가격이다.plotly 는 리서치 중 가장 마지막으로 접했는데 대시보드로도 사용할 수 있고 노트북에도 붙일 수 있는 라이브러리 형태로 제공되는 툴 이었다.데이터 분석에 주로 사용되는 파이썬, R, 매트랩에 모두 사용 가능했고 훌륭한 시각화도 가능했다. 학생이라면 아주 저렴한 가격으로도 이용이 가능하다.단점이라면, 개발자에게 더 친화적 이라는 것과 데이터 커넥터가 태블로에 비해 부족하다는 것 이었다.BI 툴, 개발자와 분석가 중 누구에게 더 쉬워야 할까?회사마다 개발자의 비중이 다르다. 스타트업 이라고 해서 개발자들로만 이루어진 것도 아니고, 이미 안정적으로 비즈니스를 운영하는 회사라고 해서 개발자가 적은 것도 아니다.각 회사가 처한 상황에 따라 어떤 툴을 사용할 지는 다를 것이다.나는 우리 회사가 어떤 BI 툴을 써야 최적일지 생각해 봤다.같은 작업을 하는데 있어서 시간을 줄여줄 수 있어야 하고, 앞으로의 변화에 유연하게 대응할 수 있는 툴이었으면 했다.개발자의 지원을 최소화 하면서 비즈니스를 이해하는 분들이 적극적으로 사용하는데 어려움이 없었으면 했다.가격적인 면도 중요했지만, 국내에서 사용하는데 참조할 수 있는 레퍼런스, 교육이 풍부한 것도 선택에 한 축이 되었다.모든 것을 종합해 본 결과 태블로 만한 것이 없다고 생각됐다.< 이제 데이터와 사랑에 빠져 볼까? >(출처 : https://www.youtube.com/watch?v=2onPdVj5zgQ)여러분들의 상황은 어떤가.지금 사용중인 툴이 충분한 효과를 가져다주고 있는가? 혹시 기존에 익숙하던 것을 습관적으로 사용하고 있지는 않나?대부분의 스타트업은 부족한 인원으로 복잡한 이슈를 해결하기 위해 고군분투 중일 것이다.특별히, 데이터를 들여다보고 최적화를 해야하는 업무를 담당하는 사람이라면 지금 이 순간도 머리를 싸메고 고민에 빠져 있을 것이라 생각된다.데이터 때문에 잠이 부족한 그대에게, 비슷한 고민을 하는 분들에게, 아무쪼록 이 글이 조금이나마 도움이 되었기를 바란다.#8퍼센트 #에잇퍼센트 #협업 #업무프로세스 #팀워크 #수평적조직

뭐가 문제였나필자는 현재 HMR(가정간편식) 커머스를 다루는 모 스타트업에서 백엔드 개발자로 재직 중이다. 말이 백엔드지 최근 변화되고 있는 트렌드에 맞춰 열심히 API 작성 셔틀을 하고 있다.API 개발에 주로 사용하는 HTTP 상태 코드는 주로 200 (정상), 400 (잘못된 요청), 401 (보안 토큰 에러), 403 (권한 없음), 404 (찾을 수 없음) 정도가 있었다.문제는 여기에서 발생했는데, API를 계속 개발해 나가다 보니 API 요청 시 데이터가 없을 때 200 상태 코드에 빈 배열을 돌려주어야 하는지, 404 상태 코드를 돌려주어야 되는지 상황에 따라 다를 수 있겠다는 생각이 들었다.만약 '데이터가 없을 수도 있는 상황'과 '데이터가 없으면 안 되는 상황'에서 404 Not Found 에러 코드로 같게 응답할 경우 다음과 같은 애매한 상황이 펼쳐질 수 있다.API를 사용하는 클라이언트가 404 에러에 대한 대응을 에러로 표시할지 데이터 없음으로 표시할지 상황에 따라 다르게 정의해줘야 한다. 결과적으로 클라이언트에서 API 요청에 대한 처리가 복잡해진다.// front-endimport fetch from 'node-fetch'; function fetchUserList() {  // 유저 목록을 가져오는 API를 사용한다고 가정  return fetch('https://api.exmaple.com/users')    .then((response) => {      if (response.statusCode === 404) {        // 이 404 Http 상태 코드를 에러로 처리할 것인가? 데이터 없음으로 처리할 것인가?        // 에러일 경우 : throw new Error('Not Found');        // 데이터 없음일 경우 : return [];      } else if (response.statusCode === 200) {        return response.json();      } else {        throw new Error('Unexpected Http Status Code');      }    })    .then(result => render(successPage, result))    .catch(error => render(failurePage, error));}결국, 어떤 식으로 표시해야 명확하게 표현할 수 있을까 하여 페이스북 존잘 개발자님들에게 의견을 물었다. # 굉장히 많은 분이 의견을 주셨고 나름대로 생각을 정리할 수 있었다.결론적으로는 '데이터 없음'과 '404 Not Found'를 같은 용도로 사용하면 안 된다.그렇다면 뭘 어째야 하나위에서 나온 결론을 조금 더 자세히 풀어보면 다음 내용이다.상황에 따라 데이터가 없는 것이 정상인 상황이 있고, 데이터가 없는 것이 에러인 상황이 있다. 이를 구분 해야 한다.데이터가 없는 것이 정상일 수 있는 상황// server-sideAPI.get('/orders/date/:date', async (request, response) => {  // 특정 날짜의 주문을 검색. 특정 날짜에 주문이 없을 수도 있다.  const { date } = request.params;  const orders = await Repository.Order.findByDate(date);  // 200: OK  // 204: No Contents  response.statusCode(orders.length > 0 ? 200 : 204).json(orders);});데이터가 없는 것이 에러인 상황API.get('/orders/:orderId', async (request, response) => {  // 특정 ID의 주문을 검색. 데이터가 없으면 에러다.  const { orderId } = request.params;  const order = await Repository.Order.find(orderId);  if (order.length > 0) {    response.statusCode(200).json(order);  } else {    // 404: Not Found    response.statusCode(404).json({      message: `${orderId} is Not Found`    });  };});그렇다면 요청한 API 리소스가 없는 경우에는 어떤 에러를 보여줘야 하는가? 일반적으로는 404 Not Found 가 통상적으로 사용되지만 우리는 이미 404를 다른 용도로 사용하고 있다. 다행히도 HTTP 상태 코드에는 501 Not Implemented 이라는 좋은 친구가 있다. 이 친구를 사용할 수 있다.import { Users, Orders } from './Routes'; app.route('/users', Users);app.route('/orders' Orders);app.all('*', (request, response) => {  // 501: Not Implemented (구현되지 않음)  response.statusCode(501).json({    message: 'This Method is Not Implemented',  });})대충 이 정도면 클라이언트는 Http 상태 코드를 보고 다음 로직을 처리할 수 있을 것이다.물론 일반적으로 사용되는 상태 코드들이지만 실제 개발 진행 시에는 클라이언트를 개발하는 개발자와 미리 어떤 상황에서 어떤 상태 코드를 보낼 것인지 정해야 할 것이다.마무리API 개발 시 사용할 법 직한 응답 코드를 정리해보았다.200: OK (정상, 데이터 있음)204: No Contents (정상, 데이터 없음)301: Moved Permanently (리다이렉션)400: Bad Request (실패, 클라이언트에서 넘어온 파라미터가 이상함)401: Unauthorized (실패, 클라이언트에서 넘어온 보안 토큰이 이상함)403: Forbidden (실패, 사용자의 권한으로 리소스를 사용할 수 없음)404: Not Found (실패, 데이터가 있어야 하나 없음)410: Gone (실패, 데이터가 있었으나 삭제됨. 이건 굳이...?)500: Internal Server Error (실패, 서버 로직 문제)501: Not Implemented (실패, 없는 리소스 요청)기타 304나 502, 503 등의 상태 코드의 경우 API Application을 작성하는 개발자의 역할보다는 Server 쪽의 역할에 가깝다고 생각하여 작성하지 않음.뭔가 어렵다고 느껴진다면 다음 짤을 참고해서 쉽게 이해할 수 있다. #플레이팅 #개발 #개발자 #인사이트 #경험공유 #조언 #꿀팁 #HTTP #버그 #버그수정 #문제해결

오프라인 고객 분석 솔루션 워크인사이트를 개발해 온 조이는 최근 온라인 접객 서비스 채널을 런칭했습니다. 이 글은 채널과 관련된 기술 블로그의 첫번째 글로 채널 데스크 프론트엔드(웹, 윈도우, OSX)의 기술 스택 및 개발 환경을 소개하도록 하겠습니다.React채널 개발을 처음 시작할 당시 (지금으로부터 1년 전) 에 워크인사이트 대시보드 및 기타 사내 툴에서는 AngularJS 1을 사용하고 있었습니다. 비교적 적은 코드로 복잡한 애플리케이션을 빠르게 만들 수 있는 점에는 만족했지만 퍼포먼스면에서는 아쉬운 부분이 많았습니다. 따라서 새로운 프레임워크 및 라이브러리를 리서치 했고 매우 가볍고 렌더링 퍼포먼스 면에서 AngularJS 1 대비 우위에 있던 React 를 사용하기로 결정했습니다.컴포넌트의 설계 패턴은 Redux를 만든 Dan이 제안한 Container 와 Presentational 컴포넌트를 구분하는 방식으로 설계하고 있습니다. 따라서 Container 가 data fetch 및 update 등의 액션을 실행하고 Presentational 컴포넌트들을 조합하여 렌더링을 하게 됩니다.React를 실제 1년째 사용해 본 결과 저를 비롯한 팀원들은 매우 만족하고 있습니다. 구조, 스타일, 동작을 한 컴포넌트로 묶어 재사용성이 매우 높아졌으며 React의 휴리스틱한 Dom diff algorithm 덕분에 렌더링 퍼포먼스에서도 많은 이득을 얻을 수 있었습니다.Facebook Flux Utils아키텍쳐는 페이스북이 제안한 flux 철학에 따라 설계되었습니다. flux를 구현하기 위한 기본적인 유틸리티 기능을 제공하는 Flux Utils을 사용합니다. Flux의 많은 구현체 중에 요즘 가장 인기인 Redux도 고려했었습니다. 저희가 프로젝트를 시작할 당시에 Redux는 5~6개월밖에 되지 않은 프로젝트였고 거의 Dan의 1인 프로젝트였기 때문에 향후 메인터넌스를 장담할 수 없다고 판단했습니다. 그보다는 페이스북이 만든 Flux Utils가 그런 면에서는 더 안전할 거라고 생각했던 것이죠.약 1년 정도 Flux Utils로 개발해오며 몇 가지 문제를 겪게 되었습니다. 애플리케이션이 커지면서 관리해야할 State가 많아지고 그들 사이의 의존성 관리 때문에 Store의 복잡도가 빠르게 증가했습니다. 그에 따라 테스트가 어려워지고 올바른 유닛테스트를 위해서는 테스트 코드 역시 매우 복잡해지는 문제가 있었습니다.그래서 Redux를 다시 리서치하게 되었고, 결론적으로 “단일 Store, 다수Reducer” 라는 Redux의 철학을 통해 State 관리 로직(Reducer)을 단순하고 테스트도 쉽게 유지할 수 있겠다는 생각을 하게 되었습니다. 뿐만 아니라 그 동안 설계와 관련되어 고민하고 필요한 경우 저희 스스로 개발해서 사용하던 많은 부분이 Redux의 서브 프로젝트 형태로 (redux-actions, redux-thunk, reselect 등) 개발되어 사용되고 있는 것을 발견해서 Redux로의 마이그레이션을 결정했고 현재 진행 중에 있습니다.Electron이 글의 도입부에서 이야기한 것처럼 채널 데스크는 윈도우용, OSX용 애플리케이션으로도 제공됩니다. 채널 개발 초기 당시 윈도우, OSX 각각 네이티브로 만들 리소스가 부족했기 때문에 웹 기술 기반으로 네이티브 앱을 만들 수 있는 다양한 솔루션들을 리서치했고 그 중 Electron을 선택하게 되었습니다.Electron은 제가 정말 좋아하는 제품인 Slack, Simplenote에서 사용하고 알려져 있고 국내에서는 Remember 등에서 사용하고 있습니다. 초기 개발 당시에는 안정성에 의문을 제기하는 개발자들도 많았고 저희도 여러 문제와 삽질(인증, 패키징, 이슈 레포팅의 어려움, 메모리릭 등등)을 많이 겪긴 했습니다만 개인적으로는 충분히 프로덕션에 쓸 수 있을 정도 수준이라고 생각합니다. 무엇보다 프론트엔드 개발자가 매우 적은 노력으로도 네이티브 데스크탑 앱을 만들 수 있는 장점이 다른 모든 문제점을 상쇄하고도 남습니다.언어개발 언어로는 자바스크립트 ES6를 사용합니다. 언어를 선택할 당시에도 여러 옵션이 있었는데 가능하면 실험적이지 않고 표준을 사용하는 것이 미래 유지보수에 안전하다고 판단했습니다. 또한 다른 자바스크립트 대안 언어를 사용하지 않더라도 ES6 (일부 ES7 포함) 스펙도 충분히 효율적인 개발이 가능하다고 생각했습니다.코딩 스타일은 기본적으로 Airbnb의 코딩 스타일 가이드라인을 따르며 조이의 상황과 맞지 않는 부분은 엔지니어들과 상의 후 수정해서 사용하고 있습니다. 스타일 체크는 ESLint로 자동화한 뒤 Circle CI와 붙여서 모든 풀리퀘스트에 대해 점검하고 있습니다.테스트초기 개발할 때는 테스트 코드를 별도로 붙이지 않았습니다. 고객의 요구와 기타 상황에 따라 기획과 설계가 크게 변경되기도 했고 그 때마다 기민하게 반응하기 위해서, 어느 정도 확립된 제품이 되기 이전에는 테스트 코드는 작성하지 않는 것이 좋다고 판단했습니다. 이제는 많은 부분이 확정되었고 안정성이 중요해지기 시작했으며 애플리케이션이 커지면서 자동화된 테스트는 필수가 되기 시작했기에 최근에 도입을 하고 있습니다.테스트를 위한 도구는 Jest, Enzyme 등을 사용합니다. Presentational 컴포넌트에 대한 테스트는 props에 따라 원하는 형태로 렌더링이 이루어지는지, 이벤트에 따라 콜백이 잘 실행되는지 등의 Spec 을 작성합니다. Container 컴포넌트에 대한 테스트는 각종 이벤트 및 동작을 시뮬레이션하고 그에 따라 Action이 잘 발생하는지 또는 내부 state가 잘 변경되는지를 테스트합니다. 또한 Store (또는 Reducer), Action Creator, Model, Util 등 모든 구성 요소에 대한 테스트를 붙이려고 노력하고 있습니다. 유닛 테스트가 아닌 e2e 테스트 혹은 css 스타일 테스트 등은 하지 않고 있습니다.빌드 및 배포현재 채널 데스크는 Client-side rendering을 합니다. 초기 로딩 속도가 느리다는 단점이 있어서 Server-side rendering으로의 전환도 고려하고 있습니다. 이미 Node.js 를 사용하고 있어서 Isomorphic Javascript의 형태로 어렵지 않게 전환이 가능합니다.작성된 자바스크립트는 Babel로 컴파일되고 Webpack으로 번들화됩니다. css를 포함한 각종 리소스들 역시 Webpack을 통해 처리됩니다. 웬만한 작업은 npm과 Webpack으로만 자동화하려고 했으며, Electron과 관련된 작업(패키징, 인증 등)들만 gulp를 이용해 자동화됩니다. 모든 리소스들은 Node.js + express 서버로 Serving 되고, Node.js 앱은 Docker로 빌드되어 AWS EC2로 배포됩니다.마무리이상으로 채널 데스크 프론트엔드의 기술 스택을 소개해드렸습니다. 앞으로 각 부분 별로 저희 팀이 고민해 온 문제들과 해결 방법을 공유하고자 합니다. 뛰어난 개발자 분들의 많은 관심과 피드백 부탁드립니다!

Q) 안녕하세요 Juan Carlos(환 까를로스)님 자기소개 부탁드려요.네 안녕하세요. 지금 immersive 6기에서 개발자가 되기 위해 열심히 공부하고 있는 환 까를로스라고 합니다. 어쩌다보니 immersive 6기에서 전문 네비게이터로 생활하고 있어요.(웃음) 네비게이터는 페어프로그래밍을 할 때 드라이버가 코딩을 할 수 있도록 큰 그림을 그려주는 거라고 생각하시면 되요. 페어와 같이 코딩을 하면서 Immersive를 헤쳐나가고 있습니다.Q) 코드스테이츠 오시기 전에는 어떤 일을 하셨었나요?해외영업을 했습니다. 이 일을 선택한 이유는 조금 특별해요. 제가 취준생이었을 때 회사를 여러 곳을 지원을 했었습니다. 지원한 기업에서 합격 통보를 받았죠. 근데 막상 그 기업에 입사하려고 보니까 지방에서 근무를 해야 하는 거예요. 그전까지는 이런 것들을 생각도 안 하고 있다가, 막상 닥치니까 곰곰이 생각하게 되었어요.'내가 서울을 떠나서 잘 살 수 있을까?' 지방에서 산다는 거에 대해서 크게 생각하고 있지 않았었는데, 막상 닥치니까 고민이 많이 되더라구요. 제가 서울 토박이인데, 고향을 떠나서 사는 거는 제가 너무 힘들 것 같아서 포기하고 지금 현 직장(지금은 퇴사를 했죠)에 다니게 된 거예요. 그리고 제가 공대 출신인데 공대 출신이 서울에서 직장을 잡으려면 영업 밖에 없더라구요. 그래서 영업직을 선택했었습니다.Q) 그럼 직장을 나오게 된 계기가 있으신가요?새로운 것을 수용할 생각이 없는 경직된 조직문화가 너무 안 맞았어요. 저는 신입을 뽑는 이유는 조직이 시장의 흐름이나 세대의 변화에 맞춰 변하기 위해서라고 생각해요. 근데, 전에 팀은 변할 생각을 안 하더라고요. 야근까지 해가면서 업무개선을 해도 기존 방식을 고수하자는 피드백이 계속되니 열정이 사라지는 것을 느꼈죠. 제가 4년 정도 다녔는데, 퇴사를 고민하고 3시간 만에 결정하고 사표를 내고 나왔어요.저는 뭔가 다양한 경험을 하고 제 스스로가 발전하는 걸 좋아하는데, 발전한다는 느낌이 없었죠. 부서를 여러 곳으로 옮긴 이유도 제가 정확히 뭘 좋아하는지 모르니까 이것저것 해보면 알지 않을까 생각했어요. 영업 파트에서 일하면서도 기획부터 경영지원까지 다양한 일을 맡았었죠.Q) 3시간이면 정말 짧네요! 보통은 여러 번 고민하기 마련인데요. 그럼 퇴사하시고 나서는 무엇을 하셨나요?음... 사실 퇴사하고 나서 제가 맡았던 고객들이 경쟁사로 이직할 수 있게 도와주겠다고 하셔서 고민을 많이 했어요.  근데, 이왕 퇴사했는데 새로운 걸 해보고 싶었어요. 한 군데 계속 있으면 뭐랄까.. 나태해지는 것 같아서요.- 다른 분야의 직장을 잡으신 건가요?일단은 여행 가야지라고 생각해서, 스페인으로 떠났어요.  첫 번째로는 스페인의 순례길을 가기로 했죠. 1000km 정도 되는 길을 걸었던 것 같아요. 순례길을 걸으면서 다양한 사람들을 만나고 생각도 정리도 좀 하고 그랬어요. 거기에는 전 세계 퇴사한 사람이 다 모이는 것 같아요. 숙소에서 만난 친구들에게 물어보면 죄다 회사를 퇴사하고 왔다고 하더라구요(웃음) 그리고 그곳에서 개발자가 돼야겠다는 마음을 먹었습니다.Q) 어떤 경험을 하셨길래 그곳에서 개발자가 돼야겠단 마음을 먹으셨나요?먼저 이 얘기를 해야 하겠네요. 사실 제가 여행경비가 이렇게 많이 들지 몰랐어요. 순례길을 여행하다가 돈도 떨어져 가는데 직업이 있는 채로 순례길을 도는 사람들을 만나게 된 거예요. 세 명을 만났는데, 세 명 다 소프트웨어 엔지니어였습니다. 처음에는 브라질 개발자를 만났어요. 그때까지만 해도 별생각이 없었죠. 다음으로는 러시아 개발자를 만났습니다. 러시아 개발자 친구를 보면서 아 이런 게 디지털 노마드구나라는 생각을 갖게 되었죠. 그리고 마지막으로 스페인 개발자 친구를 만나니까 정말 개발자라는 직업이 부럽게 느껴지더라구요. Q) 디지털 노마드를 보고 개발자가 돼야겠단 결정을 하신 거네요! 그럼 코드스테이츠를 선택해주신 이유가 있으신가요? 아까 제가 생각보다 여행 경비가 많이 드는지 몰랐다고 했잖아요. 순례길만 여행하는데도 여행 경비가 다 떨어진거에요(웃음) 그래서 어쩔 수 없이 세계 여행의 꿈을 접고 한국으로 오게 되었죠. 그리고 한국으로 돌아오는 비행기 안에서 개발자가 되기로 결심을 했습니다. 내가 여행을 다니고 하고 싶은 것을 하면서도 일도 하고 그게 너무 좋아 보이는 거에요. 물론 한국의 현실은 많이 다르겠지만 그래도 개발자라면 가능하지 않을까라고 생각을 했습니다. 그리고 그 비행기에서 핸드폰으로 코딩 관련해서 검색을 하다가 코드스테이츠를 알게 되었어요. 알아보니까 교육철학도 좋고 저에게도 괜찮은 방식을 것 같아서 그 비행기 안에서 바로 결정을 하게 되었습니다. 퇴사할 때와 마찬가지로 일사천리로 결정을 했습니다.- 비행기 안에서 모든 결정이 이루어졌네요! 3시간 만에 퇴사를 결정하신 것 같이요!뭐 망설일 이유가 있나요. 자신감과 결단력 그게 제 장점이니까요(웃음)Q) 그럼 이제 Immersive 얘기를 해볼게요. Immersive에서의 생활은 어떠세요?생각했던 것보다 여유가 있어서 좋아요. 그전에는 되게 불안하고 빡빡하고 그럴 것 같은데 막상 해보니까 할만하더라고요. 그리고 일단 사람들이 너무 좋아요. 같이 지내는 사람들이 좋으니까 Immersive도 할만한 것 같아요.Q) 그러면 지금 Immersive에서는 어떤 것을 배우고 있나요?서버를 배우고 있어요. 프론트 쪽 하구요. 프로젝트를 하고 적용을 해봐야 완전히 내 것으로 만들 수 있을 것 같아요. 역시 직접 적용을 해봐야 정확히 알 수 있을 것 같습니다.서버를 배우고 있어요. 프론트 쪽 하구요. 자바스크립트라는 언어의 다양한 문법을 매일 체험해보고 있어서, 매일매일이 새롭습니다. (뭔가 이해할 만 하면 다른걸 배워서..) 프로젝트를 해봐야 완전히 내것으로 만들 수 있을 것 같아요.Q) 앞으로 어떤 개발자가 되고 싶으세요?거창하게 세상을 바꾸는 개발자! 이런 건 제 스타일은 아니에요(웃음) 저는 제가 하고 싶은 것을 하는 개발자. 만들고 싶은 것을 만드는 개발자가 되고 싶어요. 세상을 바꾸는 개발자도 내가 좋아하는 것, 내가 하고 싶은 것, 내가 만들고 싶은 것을 만드는 개발자가 되었을 때 가능하지 않을까요?Q) 프로젝트를 곧 하게 될 텐데 어떤 프로젝트를 하고 싶으신가요?제 경험에 기반한 프로젝트에요. 우리는 회사에서 주는 돈 그냥 받잖아요. 제가 회사를 나오고 받았던 돈들을 확인해보니 제대로 받지 못했다는 것을 알았어요. 그래서 사람들이 노동의 정당한 보상을 알고 받을 수 있도록 도와주는 프로그램을 만들고 싶어요. 주변만 봐도 대부분의 사람들이 이런 문제로 인해 문제를 가지고 있다고 생각해요.Q) 1년 후에 개발자가 되었다고 생각하면 어떤 모습일까요?개발자가 될 수 있을까요?(웃음) 아마 1년 후엔 야근에 쩔어있지 않을까요? 저는 이게 내 일이다라는 생각을 하면 엄청 파고드는 스타일이거든요. 개발자로 처음 들어간 직장에 남아 있거나 이직을 하고 있을 것 같아요. 사실 저는 계획을 잘 안 세우거든요. 그러니까 아무 준비 없이 퇴사하고 개발을 배우고 있죠. 설마 굶어죽기야 하겠어요?Q) 마지막으로 하고 싶은 말이 있나요?제가 퇴사하면서 방 정리도 같이 하게 됐어요. 정리를 하다 보니까 우연찮게 제 학창시절 생활기록부를 보게 되었습니다. 생활기록부에 장래희망을 적는 칸이 있잖아요. 근데 제가 깜짝 놀란 게 거기에 중학교 때부터 고등학교 때까지 줄곧 프로그래머로 적혀있던 거에요. 그동안 까맣게 잊고 살았는데 신기했어요.그리고 또 생각을 해보니까 대학교 때도 제가 컴공과는 아니지만 공대라서 C++을 해야했는데 그 과목에서 처음으로 A+을 받은 기억이 나더라구요. 이런 생각이 들면서 결국 나는 프로그래머를 선택할 운명이었나? 이런 생각도 들고. 결국에는 돌아돌아 이 길로 온 것 같아요. 그래도 돌아왔다고 해서 늦었다거나 아쉽지는 않아요. 제가 지금까지 걸어온 길이 분명히 프로그래밍을 하는데 도움이 된다고 생각하고 있으니까요.네 지금까지 환 까를로스님과의 인터뷰를 진행했었는데요. 정말 비하인드스토리가 엄청나네요. Immersive 성공적으로 수료하시고 원하시는 개발자가 되기를 바랍니다. 앞으로도 다양한 스토리를 가진 Immersive 수강생분들의 이야기로 찾아뵙겠습니다.

WWDC18 Review (1): Bring the Func! 보기 Introduction지난 글 Bring the Func! 에서 WWDC를 소개했습니다. Keynote와 Platforms State of the Union에서 인상 깊었던 경험도 소개했고요. WWDC 첫째 날은 애플에서 큰 이벤트를 진행했고, 둘째 날부터 마지막날까지는 세션과 랩스, 스페셜 이벤트를 진행했습니다. 이번엔 지난 글에서 미처 쓰지 못했던 것을 소개하겠습니다.SessionWWDC 하면 가장 먼저 떠오르는 건 대개 Keynote입니다. 하지만 다른 세션이나 랩스부터 생각나는 애플 개발자도 있을 겁니다. 저도 처음엔 Keynote만 기대했지만, 행사에 참여하면서 세션과 랩스의 매력(?)에 빠졌습니다.Apple Developer 웹사이트에서 수많은 기술 관련 영상을 볼 수 있다.애플 관련 애플리케이션 개발자는 문제에 부딪히면 Apple Developer 웹사이트에서 도움을 얻는데요. 특히 Development Videos 사이트에 들어가면 그해 발표한 WWDC 세션부터 시작해서 그 동안의 세션들을 모두 볼 수 있습니다. Topics에서는 주제별로 카테고리를 만들어, 해당 주제에 관한 동영상들을 모아서 볼 수 있고, Library에서는 찾고자 하는 내용에 대한 키워드를 검색해서 찾을 수 있습니다.Development Videos - Apple Developer 첫 화면Topics 에서는 주제별 동영상들을 볼 수 있다.Library 에서는 검색하는 키워드에 해당하는 동영상들을 볼 수 있다.WWDC 행사장은 Hall 1 ~ Hall 3, 그리고 Executive Ballroom까지 4개의 방으로 구성되어 있었습니다. 이곳에서 각각의 세션을 들을 수 있었는데요. 시간대별로 3~4개의 세션을 동시에 진행합니다. 듣고 싶은 세션은 해당하는 방에 들어가서 들으면 됩니다. 만약 같은 시간에 듣고 싶은 세션이 두 개 이상이라면 하나만 현장에서 듣고, 다른 세션은 developer 웹사이트 또는 WWDC 앱에서 업로드되길 기다려야겠죠. 물론 24시간이 지나면 세션 영상이 WWDC앱에 업로드됩니다. WWDC 앱에서 제공하는 행사장 지도세션이 진행되는 곳의 내부수많은 개발자의 똑똑한 머리와 지미집세션이 시작되자 개발자들은 무릎 위에 올려 놓은 맥북을 열심히 쳤습니다. 하나라도 놓치기 싫어서 열심히 타자를 치는 개발자들의 모습이 멋있었습니다. 마치 대학 영어 강의를 듣는 기분이었죠.아쉬운 점이 있다면, 에어컨을 너무 강하게 틀어 세션 행사장이 매우 추웠다는 겁니다. 며칠을 견디다 마지막 날엔 결국 행사장 밖에서 라이브로 시청했습니다. 그리고 세션을 진행하는 동안 빠르게 코딩을 하다 보니, 소스 코드를 다 작성하기도 전에 다음 장면으로 넘어가는 부분이 많았습니다. 실시간으로 같이 작업할 예제 소스 코드를 제공하거나 조금 더 효율적으로 세션을 들을 수 있게 해줬으면 좋겠다는 생각이 들었습니다.행사장에서 제공하는 아침 식사와 함께 맥북 프로에서 라이브로 세션 시청What’s new in ARTKit 2지금부터는 인상 깊었던 세션 세 가지를 소개하겠습니다. 첫 번째는 What’s new in ARTKit 2였습니다. 이 세션이 가장 인상 깊었던 이유는 애플이 AR에 중점을 두고 있다는 생각이 들었기 때문입니다. 실제로 Keynote 발표 중에 장난감용 블럭을 만드는 회사 관계자 두명이 AR을 활용한 앱을 실행해 노는 모습을 보여주기도 했습니다.Keynote 발표 중 한 장면. 크레이그 페더리기가 AR 파트에서 Shared experiences에 대해 발표하고 있다.가장 재미있었던 건 현실 공간을 저장해 다른 유저들과 공유할 수 있는 기능이었습니다. ARWorldMap Object를 이용해 사용자가 기기를 움직이면서 현실 공간의 모습을 저장합니다. 나중에 앱을 다시 실행하면 저장했던 현실 공간 맵이 그대로 유지되고, 이전의 모습도 나타나죠. 예를 들어, 노란 테이블 위에 가상의 물건을 올려 놓았다면, 나중에 테이블을 향해 기기를 움직였을 때, 그 자리에 놓여있던 가상의 물건이 다시 나타납니다. 또한, 저장한 맵을 근처의 다른 유저의 기기로 전송할 수 있습니다. 이렇게 하면 서로 다른 기기에서 같은 맵을 보면서, 같은 경험을 할 수 있게 됩니다. 개념을 확장하면 하나의 AR앱으로 다중 유저들이 게임을 함께 즐기거나 멀리 떨어져 있어도 같은 교육을 받을 수 있죠.SwiftShot AR게임을 즐기려고 기다리는 개발자들WWDC18 Keynote에서 잠깐 소개되었던 SwiftShot AR 게임이 이런 특징을 잘 나타난 앱입니다. 실제로 행사장 1층 안쪽에 이 게임을 즐길 수 있는 공간이 따로 마련되어 있었습니다. 개발자들이 직접 게임을 즐길 수 있었고, 마지막 날엔 개인전과 팀전을 진행해 1등에게 선물(AR뱃지)을 주었습니다. 옆에서 구경했는데 재밌었습니다. 아이패드가 있다면 여기를 클릭해 샘플 코드를 다운 받을 수 있습니다. 빌드해서 재미있는 AR 게임을 친구들과 함께 즐겨보세요. A Tour of UICollectionView브랜디 앱은 90% 이상 UICollectionView를 이용해 앱 화면을 만들었습니다. 많은 UICollectionViewCell을 다시 사용할 수 있고, 커스텀 레이아웃도 만들 수 있기 때문입니다. 이전에 포스팅한 ‘테이블이냐, 컬렉션이냐, 그것이 문제로다!’에서 UICollectionView를 공부했지만 더 배우고 싶어서 A Tour of UICollectionView를 들었습니다.이 세션은 UICollectionView에 대해 좀 더 깊은 내용을 다뤘습니다. UICollectionView와 UITableView의 가장 큰 차이점인 레이아웃에 초점을 두었는데요. 단순히 UICollectionView에서 선형 레이아웃 말고 그리드 형식의 레이아웃을 만들 수 있다는 것, 커스텀 레이아웃을 만들 때 고려할 것, 구현에 대한 가이드라인까지 제시했습니다. 애플에서 제공하는 레이아웃 중 하나는 UICollectionViewFlowLayout입니다. UICollectionViewFlowLayout은 line-based 레이아웃 시스템입니다. 일직선 상에서 최대한 많은 아이템들을 채운 후, 다음 행 또는 열로 넘어가 아이템을 채우는 형식으로 컨텐츠들을 배치합니다. 가장 흔한 레이아웃 모습이 바로 그리드 레이아웃입니다.그리드 레이아웃, 또는 UICollectionViewFlowLayout으로 구현할 수 있는 레이아웃Line-based 레이아웃이 아닌 다른 모습의 레이아웃이라면 어떤게 있을까요? 세션에서 예를 든 레이아웃이 바로 모자이크 레이아웃이였습니다. 브랜디 앱, 또는 다른 앱에서 볼 수 있는 모자이크 레이아웃은 일직선상에서 일렬로 정렬하지 않고, 그리드 레이아웃과 조금 다른 모습입니다. 아래의 스크린샷을 보면 어떤 레이아웃인지 감이 잡힐 겁니다.브랜디 앱, 인스타그램 앱, 세션 예제 앱의 모자이크 레이아웃모자이크 레이아웃은 line-based 레이아웃이 아니기 때문에 일반적인 UICollectionViewFlowLayout을 사용하지 않고, UICollectionViewLayout을 상속하여 커스텀합니다. 총 4개의 기본 메소드와 추가적으로 고려해야하는 메소드 하나를 이용하여 커스텀 UICollectionViewLayout을 만들 수 있습니다. 모든 컨텐츠를 담는 뷰의 크기, 레이아웃의 속성 2개, 그리고 레이아웃을 준비하는 기본 메소드들을 구현하고, 레이아웃이 변경해야하는 상황(기기를 가로로 눕히거나 레이아웃의 위치가 변경될 때 등)을 고려하여 메소드를 구현하면 됩니다.open var collectionViewContentSize: CGSize { get } func layoutAttributesForElements(in rect: CGRect) → [UICollectionViewLayoutAttributes]? func layoutAttributesForItem(at indexPath: IndexPath) → UICollectionViewLayoutAttributes? func prepare() func shouldInvalidateLayout(forBoundsChange newBounds: CGRect) → Bool 세션 강연자가 직접 소스를 작성하면서 메소드 구현과 퍼포먼스를 위한 팁을 설명했습니다. 이 세션을 통해서 UICollectionView의 핵심인 레이아웃에 대해 더 깊이 배울 수 있었죠. 레이아웃 말고도 멋진 애니메이션 효과 구현 방법을 설명해주었는데요, 여기를 클릭해 직접 동영상을 보는 걸 추천합니다! 영상을 보고 나면 분명 멋진 UICollectionView를 구현할 수 있을 겁니다.Build Faster in XcodeBuild Faster in Xcode 는 가장 인기 있었던 세션 중 하나였습니다. 한국 개발자들 사이에서도 추천할 세션 중 하나로 꼽혔죠. 물론 혁신적으로 빌드 타임을 줄일 수는 없지만, Xcode의 기능과 빌드 타임이 어떻게 연결되는지 알 수 있었습니다. 프로젝트 세팅과 가독성 있는 코드 작성, 이 두 가지가 빌드 타임과 관련되어 있었습니다. Xcode는 프로젝트를 구성(configure)할 때, 빌드할 targets(iOS App, Framework, Unit Tests 등)와 targets 사이의 종속 관계(dependency)를 따릅니다. Dependency에 따라서 target을 빌드하는 순서도 정해지는데, 순서대로 빌드하지 않고 최소한의 연결을 유지하면서 병렬적으로 빌드하게 됩니다.빌드 시간을 아름답게 줄일 수 있다.이것은 Xcode 10에서 Scheme Editor에서 설정할 수 있습니다. 프로젝트의 Target → Edit Scheme → Build → Build Options에서 Parallelize Build를 체크하면 됩니다.Xcode 10의 Parallelize Build또한 Xcode 10에는 빌드 타임을 계산하는 기능도 있습니다. 빌드할 때 어떤 부분에서 얼마나 걸렸는지 요약해서 보여주는 기능도 있습니다. Product → Perform Action → Build With Timing Summary를 선택하면 빌드 후 요약해서 Xcode에 나타납니다.Build With Timing Summary를 선택하여 빌드하면위 스크린샷처럼 요약해서 보여준다.Xcode 프로그램을 이용해서 빌드 타임을 관리하는 방법도 있고, Swift으로 작성한 소스 코드를 가독성 높은 코드로 바꾸는 방법도 알려줍니다. 또한 Bridging Header로 Objective-C와 Swift를 동시에 개발할 때 도움이 되는 방법도 설명해줍니다. 빌드 타임에 대해 관심을 가질 수 있는 계기가 될 겁니다. 한 번씩 영상을 보길 추천합니다!Labs세션을 듣고 궁금한 점이 생겼다면 Labs(랩스)에서 질문할 수 있습니다. 각 세부 분야별 애플 기술자들이 시간대별로 모여서 개발자의 질문을 받거나 문제점을 해결할 수 있도록 도움을 줍니다.Technology Labstechnology Labs 간판Labs 입구에 있는 부스별 주제짙은 남색 Engineer 티셔츠를 입은 애플 기술자들이 질문을 받고 있다.가장 인기가 많았던 랩스는 Auto Layout and Interface Builder, UIKit and Collection View, Building Your App with Xcode 10 등등이었습니다. 사람이 많아서 줄 서서 기다릴 정도였습니다. 내년에는 랩스 시간이 조금 더 길게 진행됐으면 좋겠다는 생각이 들었습니다.WWDC 기간 중에 랩스에서 시간 보낸 적이 있었습니다. iOS 프로그래밍을 시작한 지 1년도 되지 않아 궁금했던 것들과 새로운 Xcode 10에 대해서 질문했습니다. 아래는 질문했던 내용을 문답형식으로 작성했습니다.애플 기술자와의 문답문: iOS 프로그래밍을 개발한지 얼마 안 된 신입 개발자입니다. 어떻게 하면 프로그래밍 실력을 높일 수 있나요? 답: 앱 하나를 처음부터 끝까지 개발해보면 실력을 늘릴 수 있다. 또한, 애플에서 만든 스위프트 책 보는 걸 추천한다.문: WWDC 기간 동안에 테스팅(testing)에 관심을 가지게 되었습니다. 앞으로 상용하는 앱을 테스트하면서 개발하고 싶은데, 테스트는 어떻게 시작하면 좋을까요?답: 이것에 대한 세션 동영상 을 보는 걸 추천한다. 테스트는 중요한 것이기 때문에 이 동영상을 보면서 테스트에 대해 배우고 난 뒤, 직접 앱을 테스트해보길 권장한다.문: 새로운 Xcode 10에서 앱을 빌드해봤는데 에러가 났습니다. 이런 에러가 나타난 이유는 무엇인가요?답: Xcode 10에 있는 컴파일러 문제다. 소스를 수정하면 앱이 빌드될 것이다. 컴파일러에 대해서 Xcode 팀에게 전달하겠다. (Range 관련된 컴파일러 문제였습니다.)문: 빌드 시간을 줄일 수 있는 방법은 무엇인가요?답: 컴파일하는 소스 코드를 줄이거나 프레임워크를 만들어서 빌드할 때 마다 계속 빌드하지 않도록 하면 시간을 줄일 수 있다. 이와 관련된 세션을 들으면 조금 더 자세한 내용을 확인할 수 있다.Consultation Labs애플 기술자와 일대일 면담식으로 진행하는 랩스도 있었습니다. 예전에는 선착순으로 진행되었는데 올해는 신청을 받고 당첨된 개발자에게만 기회를 주었습니다. 당첨되면 30분 동안 신청한 분야(디자인, 앱 스토어, 마케팅 등)의 전문가와 질의응답을 할 수 있습니다. 가장 인기가 많았던 User Interface Design 랩스를 신청하고 당첨이 되었습니다. 디자인 전문가들과 시간을 보낼 수 있었는데요. 애플 디자이너들이 생각하는 최선의 디자인 가이드라인을 배울 수 있었고, 함께 앱을 관찰하면서 개선되었으면 하는 디자인 요소 등의 팁을 얻었습니다. 아쉽게도 촬영 및 녹음은 불가능했습니다. 시간도 짧게 느껴져서 아쉬웠습니다.Special EventsWWDC 기간 동안에는 세션과 랩스 위주로 진행되지만 중간에 가끔 스페셜 이벤트들도 진행합니다. 점심 시간에 유명 인사들을 초청해서 하는 짧은 강연, 아침 일찍부터 모여서 같이 달리면서 즐길 수 있는 이벤트(WWDC Run with Nike Run Club), 맥주와 함께 음악을 즐기는 이벤트 등 개발 외적인 이벤트들을 많이 진행했습니다. 저는 그 중에서 Bash 이벤트를 소개하고 싶군요.BashBash는 목요일에 진행한 뒤풀이 파티였습니다. WWDC 행사장 근처에 공원을 빌려서 맛있는 음식과 주류를 무료로 제공하고, 초청 가수의 공연도 볼 수 있었습니다. 초청 가수가 공연하기 전에 소개할 때 크레이그 페더리기가 무대에 나왔습니다. 개발로 지친 몸과 머리를 식히고 다른 개발자들과 어울려 놀 수 있는 공간이였습니다. 뒤풀이 파티가 끝나갈 때쯤 진짜로 WWDC가 끝나간다는 느낌이 들어서 괜히 아쉽기도 했었습니다.무대와, 맥주와, bash 입장권한국인 개발자들과 함께 즐긴 뒤풀이 파티초청 가수를 소개하러 무대에 올라온 크레이그 페더러기아름다운 노을!마치며이번 글에서는 WWDC의 세션, 랩스, 스페셜 이벤트를 설명했습니다. WWDC가 한 달 전에 끝났지만 지금 다시 생각하면 두근두근 설레고 또 가고 싶어집니다. 내년 WWDC에 또 갈 수 있을까요? 지금까지 애플 개발자들의 축제였던 WWDC의 Review를 마치겠습니다. 긴 글을 읽어주셔서 감사합니다!글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #이벤트참여 #이벤트후기 #미국

안드로이드에서는 입력한 날짜를 변환 및 검증하는 로직을 간단하게 구현하기 위해 SimpleDateFormat 클래스를 종종 활용하게 되는데 이 클래스는 규칙에 관대하다(lenient)는 재미난 특성이 있습니다. java.text.SimpleDateFormat 클래스의 근간이 되는 java.text.DateFormat 클래스의 다음 API 문서를 살펴봅시다.By default, parsing is lenient: If the input is not in the form used by this object’s format method but can still be parsed as a date, then the parse succeeds. Clients may insist on strict adherence to the format by calling setLenient(false).파싱 기본 동작은 관대합니다. 이 객체의 날짜 포맷과 일치하지 않는 입력이 주어지더라도 날짜 형태만 유지한다면 파싱이 성공합니다. 클라이언트 코드에서는 setLenient(false) 메소드를 호출해 파싱 규칙을 여전히 엄격하게 가져갈 수 있습니다.lenient 라는 흔하지 않은 단어 때문에 의미가 잘 와닿지 않습니다만, 캠브릿지 영영사전에 따르면 ‘관대하다’ 라는 뜻이 있다고 하네요.lenient /ˈliː.ni.ənt/ ▶ adjective ▶ Level C2(Mastery Proficiency)A lenient punishment is not severe.Thesaurus: allowing, forgiving, merciful, permissive, tolerant하지만 규칙에 관대하다는 말이 무슨 의미인지 여전히 와 닿지 않습니다. 잠시, 아래의 소스코드를 읽고 그 결과를 한번 예측해 볼까요? parse 메소드는 기본적으로 lenient 하다는 특성에 주의합시다./* * 2017년 13월 32일 이라는 입력에 대해 어떤 결과가 나타날까? * 1. 2017-13-32 * 2. 2018-02-04 * 3. 2017-01-01 * 4. 2018-01-01 * 5. ParseException 이 발생 */ val userDate = "2017-13-32" val date = SimpleDateFormat("yyyy-MM-dd").parse(userDate) val localDate = LocalDateTime.ofInstant(date.toInstant(), ZoneOffset.UTC) println ("사용자의 ISO-8601 Date 입력 결과는 ${localDate.year}년-${localDate.month}월-${localDate.dayOfMonth}일 입니다.") lenient 라는 사전 hint 없이 바로 문제를 낼 경우 사람들이 제일 많이 선택한 결과는 ParseException 이 발생한다 였습니다. 하지만 lenient 한 특성으로 인해 실행 결과는 의외로 두번째, 즉 2018년 2월 4일 입니다. 막상 글로 풀어 쓰려니 별 것 아닌 내용처럼 보입니다만, 필자가 담당하는 서비스에서 이 특성을 제대로 파악하지 못해 특정 사용자의 생년월일을 제대로 인식하지 못한 문제가 있었습니다.또한 우리가 흔히 아는 달력을 쓰지 않는 국가도 있다는 점 까지 고려한다면 날짜 변환이라는 것이 간단한 문제가 아니게 됩니다. 즉, 한국인의 관념 속의 ‘달력’ 이란 Gregorian calendar 를 기반으로 한 ISO-8601 달력 입니다. 그런데 이 달력을 쓰지 않는 문화권도 있습니다(한국도 흔하진 않지만 ‘단기’ 라는 별도의 달력을 쓰기도 합니다). 이런 문제 때문에, 글로벌 서비스를 준비하고 계신다면 날짜 변환 문제를 꼭 점검해 보셔야 합니다.Android 에는 이 문제를 해결해 주는 클래스가 있습니다만 불행히도 API Level 이 26이나 되어 2018년 현재에는 제대로 쓰긴 어렵습니다. 다행히도 이 문제를 보완한 joda-time 라이브러리의 안드로이드 포팅 버전도 있으니 이 라이브러리의 도입을 검토해 보는 것도 좋은 문제 해결 방법이 될 것입니다.#개발 #인사이트 #하이퍼커넥트 #개발자 #안드로이드 #개발후기

경영학과 학생 윤수는 요즘 주변에서 이런 말을 자주 듣는다."앞으로는 코딩을 모르면 문맹이다.""4차 산업혁명 시대에 대비해야 한다.""소프트웨어가 세상을 잡아먹고 있다."정확히 뭔 소리인지는 모르겠지만 일단 프로그래밍을 배우기로 결심한다. 그런데 '프로그래밍 언어'라는 게 또 뭐가 이렇게 많은지... 어떤 걸로 시작해야 할지 도무지 감이 안 잡힌다.그래서 공대생 친구들에게 물어본다. 친구 1: "일단 가장 기본인 C부터 배워."친구 2: "한국에서 제일 많이 쓰는 자바부터 배워."친구 3: "파이썬이 배우기 쉬워."친구 4: "요즘은 자바스크립트가 대세지."누가 정답일까? 사실 이 중에 "틀린" 사람은 없다. 각자 관심 분야와 목적이 다르기 때문이다. 만약 다음 달에 아이폰 어플을 개발해야 한다면 어쩔 수 없이 곧장 스위프트를 배워야 한다. 내일모레까지 사이트 레이아웃을 완성해야 한다면 더 물을 것도 없이 그냥 HTML과 CSS를 시작하면 된다. 그러나 일반적으로 첫 프로그래밍 언어를 추천하라면 내 톱 초이스는 단연 파이썬, 그다음은 HTML/CSS + 자바스크립트일 것이다. 이 3개의 기준으로 평가하였다:1. 배우기에 얼마나 어려운 언어인가?2. 이 언어에 대한 수요가 얼마나 있는가?3. 나는 프로그래밍으로 뭘 하고 싶은가?*우연히 보게 된 CSDojo라는 유튜브 채널에서 너무 훌륭하게 정리해줘서 참고하였다.1. 배우기에 얼마나 어려운 언어인가?나는 고등학교 때 C를 독학하는 것으로 프로그래밍에 입문했다가 금방 질려서 그만두었다. 창업에 관심이 생겨 다시 시작했는데 이번에는 파이썬으로 배워보았다. 그제야 흥미를 느꼈고, 프로그래밍이 마냥 어렵기만 한 게 아니라는 걸 깨달았다.어떤 차이가 있는 걸까?파이썬은 C보다 쓰기 쉽다. C로 수백 줄을 써야 하는 프로그램을 파이썬 몇십 줄로 쓸 수 있다. 파이썬 코드 몇 줄이면 쓸모 있고 흥미로운 결과물을 만들어낼 수 있다는 뜻이다. "Life is short, use Python"이라는 말이 있을 정도다. 물론 파이썬이 무조건적으로 C보다 좋은 건 아니다. 파이썬 프로그램은 C 프로그램보다 느리기 때문에 특정 업무에는 적합하지 않다. 하지만 그런 건 지금 신경 쓸 필요가 없다. 첫 프로그래밍 언어로 "컴퓨터적인 사고력"을 익히고 나면 새로운 언어를 배우는 것은 어렵지 않기 때문에, 일단은 배우기 쉬운 언어로 시작해라.비교적 배우기 쉬운 언어:    - Python    - Ruby    - JavaScript2. 이 언어에 대한 수요가 얼마나 있는가?시장에서 필요로 하는 언어를 배우는 게 좋다. 세계에서 가장 큰 웹사이트들은 어떤 기술을 사용하는지 살펴보자:출저: 위키피디아위 테이블에는 미국의 웹 서비스들만 정리되어 있다. 지역과 직군에 따라 요구하는 언어가 다르기 때문에 로켓펀치, 더팀스, 위시켓, 링크드인, 인디드, 사람인, 잡코리아 등의 구인/구직 사이트에서 직접 살펴보는 걸 추천한다.인기가 많은 언어일수록 커뮤니티가 크기 때문에, 도움을 받을 수 있는 자료들이 많고 가져다 쓸 수 있는 코드가 많다는 장점도 있다. 세계 최대 규모의 프로그래밍 커뮤니티인 스택오버플로우의 언어 점유율을 참고해보자.출저: 스택오버플로우이 중에서 HTML/CSS(웹 레이아웃), SQL(데이터베이스), Bash/Shell(Unix)은 아주 특수한 경우에 쓰이는 언어이기 때문에 제외하고 보자. 수요가 높은 언어:    - JavaScript    - Java    - Python3. 나는 프로그래밍으로 뭘 하고 싶은가?분야별로 자주 사용되는 언어가 있다. 간단하게 정리하자면:1. 데이터 과학, 공학 => Python, R, MATLAB2. 웹 프런트엔드 => HTML/CSS + JavaScript3. 웹 백엔드 (서버) => Python, Ruby, JavaScript, Java, Go, C, C++, PHP 등4. 아이폰 어플 => Objective-C, Swift (이제는 거의 Swift로 넘어갔다)5. 안드로이드 어플 => Java, Kotlin (슬슬 Kotlin으로 넘어가고 있다)6. 게임 개발 => C#, C++7. 임베디드 시스템 => C, C++결론: 왜 파이썬, 자바스크립트인가?앞서 이야기했듯 당장 급히 배워야 하는 언어가 있으면 그 언어를 배우면 된다. 교수님이 연구실에서 다음 주부터 C언어를 쓴다고 하면, 뭐 어쩌겠나? 그냥 당장 C를 배우는 수밖에. 하지만 조금 더 여유롭게, 제대로 프로그래밍을 배우고 싶다면 이 포스트에 나와 있는 세 가지 기준을 고려해서 결정하는 걸 추천한다. 배우기 쉬운 언어로는 파이썬, 루비, 자바스크립트를 선정했고, 수요가 높은 언어로는 자바스크립트, 자바, 파이썬을 선정했다. 두 기준에 모두 부합하는 언어는 파이썬과 자바스크립트이다. 이 중 무엇을 택할지는 3번 기준으로 결정하면 된다. 데이터 분석에 관심 있으면 파이썬부터, 웹 개발에 관심 있으면 자바스크립트부터 시작하면 된다. 참고로 자바스크립트를 하기 위해서는 기본적으로 HTML과 CSS를 알아야 한다!데이터 과학과 웹 개발 둘 다 관심 없으면 자바스크립트보다는 파이썬으로 시작하는 걸 추천한다. 개인적인 의견이지만 초보자 입장에서 파이썬 언어가 자바스크립트보다 깔끔하다고 생각하기 때문이다. 또한 HTML과 CSS를 미리 배워야 하는 수고를 덜 수 있다.어디서 배우지?온라인으로 프로그래밍을 가르치는 사이트가 굉장히 많다. 해외에는 Codecademy, Treehouse, Coursera, MIT OpenCourseWare 등이 있고 한국에는 인프런, 엘리스, 코드잇, 생활코딩 등이 있다. 국내외 서비스를 통틀어서 가장 추천하는 곳은 코드잇이다. 영어로 된 수업이 당연히 더 좋을 것이라 생각한다면 큰 오산이다. Codecademy나 Treehouse는 쉽고 재미있지만 막상 수업을 다 들어도 직접 무언가를 할 수 있겠다는 생각이 들지 않는다. 반면 Coursera나 MIT OpenCourseWare는 대학 수업과 흡사하기 때문에 지루하고 어려워서 이수율이 5% 정도밖에 되지 않는다. 코드잇은 내용의 깊이와 재미를 모두 잡았다. 심도 있는 내용을 난해하지 않고 간결하게 풀어내어 졸업률이 60%나 된다. 코드잇 수업 안 들은 사람은 있어도 하나만 들은 사람은 없다는 말이 있을 정도인데, 수강 후기를 보면 정말 수강생들의 애정이 드러난다. 무료로 샘플을 들어볼 수 있으니 일단 한 번 해보도록.Python으로 배우는 프로그래밍 기초 수업, HTML/CSS로 배우는 웹 퍼블리싱 수업, JavaScript로 배우는 인터랙티브 웹 수업을 모두 들으면 자신감을 갖고 프로그래밍 커뮤니티에 입문할 수 있을 것이다.이제 어떤 프로그래밍 언어를 어디서 배워야 하는지 알았으니, 주저 말고 시작해보길 바란다!#코드잇#코딩교육 #개발자양성 #교육기업 #인사이트 #경험공유

2016년 4월에 에잇퍼센트에 합류해서 2016년을 에잇퍼센트와 함께 보냈다. 1년을 다 채운건 아니지만 에잇퍼센트의 성장과 발전에 개발자로서 어떤 기여를 했는지 한 번 정리해 보려고 한다. 나에게 있어서는 물론이고 에잇퍼센트에도 의미가 있을 것이다.1. 대출 개설 내역 신용평가사 공유대출자에게 대출이 실행되면 이 내역을 신용평가사의 시스템으로 공유하는 것을 개발했다. 에잇퍼센트에서 받은 대출 내역이 공유되면 타 금융권에서 대출 개설 내역을 확인할 수 있으므로 추가 대출이 쉽게 이루어지지 않을 것이다. 우리의 고객은 대출자도 있지만 투자자도 있다는 측면에서 투자자의 소중한 투자금을 안전하게 지켜내기 위한 안전 장치 중 하나가 될 수 있다.  2. 성능 개선에잇퍼센트는 빠르게 성장하고 있는 스타트업이다. 스타트업이 비즈니스적으로 빠른 실행을 하며 달리다 보면 성능의 벽에 부딪힐 때가 있는데 마침 내가 합류하고 얼마 되지 않은 시점이었다. 주로 우리의 개발 환경인 Python Django 코드를 개선하는 방향으로 진행을 했고 추후에는 사용자 브라우저단 성능 개선도 진행했다. Python Django 코드 개선에 대한 자세한 내용은 내가 쓴 블로그 포스팅에서 확인할 수 있다.3. 서버 인프라 서울 이전에잇퍼센트는 서버 인프라로 Amazon Web Services(이하 AWS)를 사용하고 있다. 서비스를 처음 시작할 때에는 AWS 도쿄 리전이 가장 가까운 곳이어서 도쿄 리전을 사용하고 있었다. 그러다가 2016년이 되어 서울 리전이 생겼고 도쿄 리전에 비해 네트워크도 빠르고 비용도 저렴해서 사용하지 않을 이유가 없었다. 그래서 도쿄 리전에서 서울 리전으로 이전하는 작업을 진행했다. 밤샘 작업을 함께 해준 개발팀원들에게 고맙다는 얘기를 다시 한번 하고 싶다.그 날의 풍경과 작업 기록, 그리고 django-storages 서울 리전 연동에 대한 글까지 남겨두었다.4. Python Django 버전 업그레이드에잇퍼센트에 합류했을 때 Python 3.4 , Django 1.8을 사용하고 있었고 Python 3.5 Django 1.9로 버전 업그레이드를 진행했다. 버전 업을 하면서 발견된 큰 문제는 없었고 Django admin 의 UI 에 flat 디자인이 적용되어 화면이 이뻐졌다. 내가 직접 한 건 아니지만 화면이 이뻐졌다고 다들 좋아해 준 기억이 난다.참고로 현재의 최신 버전은 Python 3.6 Django 1.10이다.5. 테스트 개선개발을 빠르게 하는 것도 중요하지만 안정적으로 잘 동작하는 것도 그에 못지않게 중요하다. 안정적인 서비스 개발과 운영을 위해 테스트가 중요하다. 특히나 돈을 다루는 금융회사라면 더욱 중요한 것이 테스트이기에 에잇퍼센트 개발팀에도 테스트는 매우 중요하다. 테스트 코드를 잘 작성해야 하고 테스트 코드가 실제 코드를 얼마나 커버하는지에 대한 측정도 필요하다. 에잇퍼센트는 코드를 개발해서 push 하고 pull request를 할 때마다 travis를 통해서 테스트를 수행하고 커버리지를 측정하고 있다. 커버리지 측정을 처음 시작할 때와 비교해보면 기존 대비 10% 포인트 가량 커버리지가 올라갔다. 커버리지가 떨어지면 pull request를 승인하지 않는 것을 정책으로 가져가고 있다.테스트 수행 시 커버리지 측정과 함께 PEP8 준수 확인, migration 체크, 템플릿 검증 등을 하도록 개선했다. 또한 기존에는 테스트 수행 시 sqlite3을 DB로 사용했는데 개선 후에는 실제로 사용하고 있는 PostgreSQL을 사용하도록 했다. 성능을 위해 raw SQL을 사용하는 경우가 가끔 있는데 이때 테스트가 제대로 안 되는 문제를 개선할 수 있었다.6. 개발 환경 개선유지 보수가 용이하고 효율적으로 개발하기 위한 환경을 만들기 위해 노력했다. smarturls, django-debug-toolbar, factory boy 등의 패키지를 적용했으며 로컬 서버 외에 개인별로 배포해서 테스트할 수 있는 서버 환경을 만들어서 테스트를 용이하게 했다. django 설정 분리, 모델 분리, 상수 분리 등의 리팩토링도 진행했다.7. NH핀테크 오픈플랫폼 적용 (진행 중)NH 농협 은행에서 제공하는 API를 사용해서 금융 관련 작업을 자동화하고 효율화하려고 한다. NH에서 요구하는 정보보호 및 보안 기준에 맞춰 시스템을 정비하고 만들어 나가는 중이다. 올해 상반기 안에 API 연동이 되어 에잇퍼센트에 NH핀테크 오픈플랫폼이 알맞게 녹아들어 가기를 기대해본다.8. 서비스 개선에잇퍼센트의 서비스적인 개선도 몇 가지 진행했다.- 채권 상세 페이지 개선 : 투자한 채권에 대한 지급 현황, 지난 내역을 볼 수 있게 되었다.- 로그인 상태 유지 : 기본 30분 로그인이 유지되고 30일 유지를 선택할 수 있게 되었다.- Ada 챗봇 연동 : 금융권 챗봇 중 유일하게 학습하는 Ada가 서비스와 연동하기 위한 개발을 진행했다.1~7번까지의 작업은 주로 눈에 보이지 않거나 개발팀 내부적인 개선이었고 8번은 사용자에게 바로 보이는 서비스적인 개선이었다. 위에 언급한 것 외에 코드 리뷰를 열심히 한 것이 기억에 남는다. 코드 리뷰를 통해 유지보수가 용이하고 효율적인 코드를 만들어 나가고 싶었다. 어떤 코드가 유지보수가 용이하고 효율적인지 리뷰를 통해 토론하고 배워나가는 과정이 나뿐만 아니라 개발팀 모두에게 도움이 되었으리라 본다.개인적으로는 이음에서 Ruby on Rails로 개발을 재밌게 하다가 에잇퍼센트에서의 Python Django를 사용한 개발로의 도전과 전환이었다. 새로운 언어를 접하고 배워나가는 과정 또한 개발자에게는 즐거움이 아닐까 싶다. Ruby, Python 둘 다 엄청나게 잘 하는 건 아니지만 기회가 되면 Ruby와 Python 각각의 장단점을 비교해보는 것도 재미있을 것 같다.2016년은 내가 2006년 첫 회사에 들어간 지 10년이 된 해였다. 10년 전 신입 사원 시절에는 서비스적인 개선을 주로 하고 다른 팀원에게 도움을 주기보다 내 할 일에만 충실했었다. 10년이 지난 지금 작년 한 해를 이렇게 돌아보니 서비스에 직접적인 개선도 하고 다른 팀원들이 개발을 더 잘할 수 있도록 환경을 만들고 도움을 주는 데에도 제법 역할을 했다는 생각이 든다. 나 자신이 엄청나게 변화한 건 아니지만 10년이 헛된 시간은 아니었다는 생각이 들어서 내심 뿌듯하다.2016년을 이렇게 정리하고 보니 2017년에는 더 잘 해야겠다는 생각이 든다. 에잇퍼센트 모든 구성원들과 함께 엄청나고 멋지게 성장해 보고 싶다. 화이팅!2016년 처럼 올해도 해맑게 화이팅!#8퍼센트 #에잇퍼센트 #조직문화 #기업문화 #2016년 #돌아보기 #스타트업개발자 #개발자

안녕하세요, 개발 2팀에서 단아함을 맡고 있는 오연주입니다. 평소에 관심이 많았던 깃(Git)을 공부하면서 알게 된 내용들을 글로 쓰려고 합니다. ‘어떤 닝겐이 만들었나’ 궁금할 정도로 천재적인 깃은 도대체 누가 만든 것일까요? 바로 리누스 토발즈(Linus Torvalds)입니다. 이름에서부터 OS의 느낌이 가득합니다. 네, 맞습니다. 그는 리눅스(Linux)의 창시자이기도 합니다. 리누스는 말했죠. “My name is Linus, and I am your God.” 리누스 토발즈 (Linus Torvalds)그가 깃을 만들기 전에는 보통 중앙집중식 VCS(Version Control System)를 사용했었습니다. 예를 들면 다음과 같은 도구들로요. CVSSVN(Subversion)…반면에 깃은 분산 버전 관리 시스템(DVCS, Distributed Version Control System)입니다. 그렇다면 중앙집중식의 대표주자인 Subversion(VCS)에 비해 무엇이 더 좋을까요? 속도가 빠르다. snv log svn diff -rN svn commit 등 대부분의 명령어가 네트워크 연결이 되어야 실행 가능한 명령어입니다. 그러나 git push git clone 등 몇몇 명령어를 제외하고는 네트워크에 연결되어 있지 않아도 로컬에서 실행할 수 있습니다. 용량이 적다. Mozilla의 SVN Repository는 126GB인데 반해 Git Repository은 420MB입니다. 왜냐하면 해쉬, 스냅샷을 이용한 효율적인 파일 변화 관리가 가능하기 때문입니다. 브랜치를 만드는 작업이 수월하다. SVN은 diff를 전부 적용해서 파일을 생성한 뒤 네트워크에서 내려받는 반면, 깃은 스냅샷을 가리키는 링크(Commit Object)만 만들면 됩니다.어떠한 특징을 가지고 있길래 이런 차이점이 생기는 걸까요?분산 저장소로, 로컬에서도 중앙 저장소와 연결되지 않은 상태에서 지지고 볶기가 가능하다니! 여러 개의 다른 저장소를 생성할 수 있고 서로서로 연결되어 독립적으로 개발 프로젝트를 진행할 수 있고 유기적인 업데이트가 가능합니다. 델타 기법이 아닌 스냅샷 방식을 사용합니다. SVN의 경우 파일 변화를 diff로서 추적한 반면, Git은 각 시점의 파일 상태를 모두 스냅샷을 찍어 관리합니다.변화를 기억했던 기존 방식변화된 소스를 커밋할 때 스냅샷을 찍는 방식두 가지 특징을 살리려면 깃이 여타 다른 VCS와는 다른 방식으로 정보를 관리할 필요가 있습니다. 예를 들어 Revision number로 히스토리를 관리했던 Subversion으로 분산된 저장소의 히스토리를 관리하려고 하면 ‘시점 충돌’ 문제가 발생합니다.그..그려봤습니다..금융 프로젝트에 참여했을 때의 일입니다. VCS 중 H사 툴을 사용하였는데 한 소스의 버전을 받고 개발하는 과정에서 커밋의 횟수가 많아지니 중앙 저장소 입장에서는 ver 1 → ver 9로 갑자기 타임워프하는 일이 생겼습니다. 그래서 개발자 스스로 본인의 버전을 모두 삭제한 후 ver 9였던 파일을 수동으로 ver 2로 바꿔주는 것이 관례였습니다. 소스가 모두 날아가는 경우가 있어 소스 commit 과정이 공포스러웠죠. 깃은 해쉬(hash)를 이용한 정보 관리를 통해 이런 문제를 말끔하게 해결합니다.Git의 핵심, 정보 Hashing! git reset --hard 3269aecad9ffea81763a42b9fff34c76a0aa4cf0 브랜디 소스 코드를 pull 했는데 특정 시점으로 돌아가 할 일이 생겨 위의 명령어를 입력했던 적이 있습니다. 명령어로 깔끔하게 원하는 시점으로 되돌아올 수 있었죠. 뒤에 붙는 40자리의 기괴한 문자열은 바로 깃이 정보를 관리하는 데에 사용하는 해쉬값입니다. 해쉬값이 제일 많이 보이는 곳은 git log 가 아닐까 싶은데요. commit 옆에 나열된 일련번호같은 문자열이 궁금하진 않으셨나요?깃은 소스 코드를 포함해서 히스토리를 관리하는데 필요한 모든 정보를 이런 해쉬로 저장 및 관리합니다. 이 해쉬값은 40자리 16진수 숫자이며 SHA-1 알고리즘으로 생성됩니다. SHA-1 알고리즘은 보안 표준 해쉬 알고리즘 중 하나입니다. 충돌할 확률은 1 / 10^45로, 매우 매우 낮기 때문에 수많은 정보를 저장 및 관리하기에 안전하고 적합합니다. 4GHz CPU로 SHA-1 해쉬 중복값을 찾아내려면 4000년이 걸린다.앞서 SHA-1 해쉬값으로 모든 정보를 저장한다고 말씀드렸는데, 과연 어떤 정보를 어디에, 어떻게 저장하고 있는 것일까요? 각 해쉬 값은 깃이 내부적으로 저장하는 파일 이름이 되기도 하는데, 이 파일들은 .git/objects 경로에서 전부 찾아볼 수 있습니다. 해쉬값 40자리 중 앞 2자리를 디렉토리 이름으로 따고, 뒤 38자리를 파일 이름으로 지정합니다. 각 파일 안에는 서로 다른 정보가 담겨 있습니다. 해쉬값으로 표현되는 이 파일들은 정보의 종류에 따라 3가지 객체로 분류됩니다. Blob ObjectTree ObjectCommit Object폴더나 파일명이 어떤 오브젝트인지 힌트를 주지 않기 때문에 세 가지의 오브젝트 파일 내용의 캡처를 위해 복불복으로 열어봤는데요, 하나의 파일을 열 때마다 포춘쿠키를 까듯 심장이 쫄깃쫄깃했습니다. Blob Object란 실제 파일을 뜻하며, 실제 소스파일을 가지고 있는 실세 오브젝트같은 느낌입니다. Blob Object - 열어보면 내가 작성한 소스 코드가 들어있다.Tree Object 내부에는 프로젝트 구조의 각 디렉토리에 대한 정보가 담겨 있습니다. 하위에 어떤 폴더와 파일을 가지고 있는지 알려주고, 객체 해쉬 값을 저장하고 있습니다. 이 Tree Object의 제일 상위 객체는 root이며, 프로젝트의 최상위 폴더에 대한 정보를 담게 됩니다.앞서 깃은 각 시점별 스냅샷을 찍어 관리한다고 했습니다. 스냅샷을 찍는 행위는 새로운 Root Tree Object를 만들고, 각 시점에 가지고 있는 Tree Object와 Blob Object로 새로운 트리 구조를 만드는 과정입니다. Tree Object - 하위에 php라는 폴더와 README.md라는 파일이 들어있는 것을 볼 수 있다.Commit Object는 커밋 시점의 Repository Root Directory의 해쉬 값을 가지고 있는 녀석입니다. Parent는 내 커밋 전에 커밋이 누구인지를 뜻하는데요. 또한, 커밋할 때의 committer(user), commit message등의 정보도 가지고 있습니다.Commit Object - 해당 commit 시점의 root tree object와 이전 커밋, 작성자 등에 대한 정보를 담고 있다.세 종류의 객체는 깃이 분산된 Repository 간의 소스 히스토리를 쉽게 관리하도록 도와줍니다. 해쉬값으로 관리되기 때문에 특정 스냅샷에 이동하거나, 히스토리를 변경 또는 추가하는 데에 적은 리소스만 필요합니다. 또 분산된 저장소 사이에 상호 시간 순서에 대한 모호함도 해결할 수 있었습니다. 이 정도면 갓누스….깃을 공부하기 시작한 이유는 Git UI Tool을 쓰면서 습관적으로 commit, push 버튼을 눌렀기 때문입니다. 깃에 대한 이해도가 있는 상태에서 사용한다면 실수가 줄어들 거라 생각합니다. 다음 글은 Git branching Model을 다루겠습니다. ps. Git, 협업과 원활한 커뮤니케이션을 위해 알고 씁시다! 우리 함께 깃빨 받읍시다!! 참고 Scott Chacon and Ben Straub, ⌈Pro Git, 2nd Edition⌋, Apress(2014)Schneier on SecurityProbability of SHA1 collisions, stack overflowSVN 능력자를 위한 git 개념 가이드, Insub Lee, Slide Share글오연주 사원 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유