게임 개발자국내 게임 산업에서 모바일 게임의 매출액은 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을 사용해서 게임을 만드는 것은 프로그래밍을 학습하는 데에도 도움이 될 것입니다.게임 개발자의 종류는 정말 많다.오늘 포스팅에서 언급한 게임 개발자는 일부입니다. 게임 개발자의 종류에는 온라인 게임, 모바일 게임, 콘솔 게임 등 정말 다양하고 무궁무진합니다. 여러분들이 어떤 게임 개발자가 되고 싶든 중요한 것은 게임에 대한 열정인 것 같습니다. 자신이 정말 하고 싶고 좋아하는 게임을 만든다는 것은 세상에 의미있는 프로그램을 만드는 개발자만큼이나 행복한 개발자겠지요. 다음 편에는 더 재밌는 개발자 직군으로 찾아오겠습니다.

소프트웨어 개발자들이 생각하는 ‘성공’이라는 단어와 키워드에는 어떤 것들의 의미를 포함하고 있을까? 한편으로는 단편적이고 획일적인 ‘성공’이라는 단어에 너무 많은 개발자들이 매몰되어 있는 것 아닌가 하는 생각을 해본다. 필자 스스로 실무경력 20년을 넘겨서 소프트웨어 개발을 하고 있는 경험을 바탕으로 주변의 성공한 개발자들에 대해서 혼자 생각해 보았다.일반적으로 의미의 ‘성공’이라는 것이 무엇을 의미하는 것인가에 대한 정의는 이번 칼럼의 말미에서 이야기하도록 하자. 정말 많은지 모를 대한민국에서 성공한 개발회사나 개발된 서비스들을 살펴보는 것부터 시작을 하는 것이 정답인지는 필자도 잘 모르겠다. 성공적인 서비스나 소프트웨어, 프로그램은 세상에 선보인다는 것. 그러한 것을 만들어낸 순수한 아이디어나 원천기술로 무장한 기술로 축적되었고, 그 아이디어를  뛰어넘어, 새로운 기술이라고 할 수 있는 것을 보유한 제품이나 상품들이 얼마나 되는지에 대해서부터 냉정하게 필자는 잘 모르겠다라고 먼저 인지하고 넘어가자. 아니, 다시 말하자면, 냉정하게 국내에서 그런 것을 본적이 별로 없는  듯하다.더욱더 삐딱하게 이야기하자면, 국내에서 성공한 개발 서비스들은 대부분 아류작이거나 남의 아이디어를 도용한 제품과 서비스들이 대부분이 아닌가라고 생각한다. 심지어는 특정 솔루션 시장은 오픈소스를 그대로 제품에 반영해 두고서는 자신의 제품인 것처럼 위장하는 사례까지 보이고 있으니, 과연 대한민국 소프트웨어 시장은 과연 얼마나 ‘성공’이라는 키워드를 그대로 사용해도 되는지에 대해서 매우 의문시된다.(물론, 필자의 삐딱한 시선에서만 그렇게 보일지도 모른다.)대한민국의 소프트웨어 시장에서 1위를 지키고 있다고 하는 서비스와 제품들이 되려면 어떻게 해야 하는가?. 삐딱하게 이야기하자면, 오로지, 대한민국에서 성공한 개발회사나 개발자가 되려면, 창의적인 아이디어나, 독특한 아이디어로 무장하는 승부수를 던지기 보다는, 해외의 서비스 중에 알차고, 괜찮은 것들에 대해서 관심을 가지는 것이 중요하다고 생각한다. ( 그래서, 영어공부를 잘해야 하는지도 모르겠다. )필자가, 대기업과 신규사업기획을 할 때에 작업하는 내용을 보고서는 경악을 금치 못했던 경험을 한적이 있다. 정말 상당한 컨설팅 금액( 수십억을 넘긴 비용 )을 지불해서, 대기업이 유명한 컨설팅업체를 통해서 신규사업에 대한 기획과 아이디어에 대한 컨설팅을 받는 것에 전문가의 한 사람의 참여했었다. 그런데, 그 중요한 작업의 모티브는 해외에서 이미 성공적으로 안착한 서비스에 대한 분석과, 한국에서의 서비스 시에 벌어질 일에 대해서 예측을 하는 일을 하고 있었다는 점이다. 새로운 아이디어가 아니라는 점이다.물론, 성공한 서비스를 도입해서, 로컬 화한다는 것 또한 매우 어려운 일이라고 생각하지만, 대부분의 새로운 기획이나 신규 서비스에 대한 작업들의 대부분을 이런 식으로 진행한다는 이야기를 들었을 때에 받은 충격은 정말 놀라운 경험이었다, 물론, 지나고 나서 생각해보니, 그렇게 놀랄만한 경험도 아니었는지 모르겠다. 대부분의 대기업들이 이런 식으로 한다는 이야기를 듣고 더 놀라기는 했지만. 물론, 이렇게 로컬화 한다는 것 자체도 대단한 도전이고 어려운 점이라는 것은 인정한다고 하지만, 이런 로컬화와 아류작에 대해서 비판적인 시야를 가진 필자의 생각은 그렇다.성공한 서비스들은 대부분 아류작들이다?냉정하게 국내에서 성공한 대부분의 서비스들은 아류작들이고, 복제본들이고, 독창적인 아이디어보다는 해외 서비스를 대부분 국내에 안착한 서비스라고 생각한다. 심지어 독창적인 mp3 플레이어마저도, 아이팟의 생태계가 한층 더 발전적인 시장을 창출했으니, 국내에서 만들어진 디지털적인 요소들 중에 독창적인 것이 얼마나 있는가?필자는 생각한다. 예술에 있어서 복제와 창작의 차이는 매우 크다는 것을. 물론, 소프트웨어 개발이 이런 예술에 비견될 정도의 가치를 부여해서 그런 것 만은 아니다. 소프트웨어 개발은 아이디어와 구현하고자 하는 추진력과 열정이 결합되어져서 만들어지는 최고의 가치 구현을 위한 세계이기 때문에 그렇게 생각할 뿐이다.필자가 좋아하는 만화 중에 ‘맛의 달인’이라는 만화에 나온 표현을 그대로 옮기자면 다음과 같은 장면이 나온다. 프랑스의 유명한 요리를 그대로 일본에서 구현하지만, 그 요리에 대한 평가는 ‘프랑스의 요리를 그대로 구현한 요리이다’. ‘매우 아름답지만 최저의 요리’라는 평가를 받는다. 그러한 최저의 요리라는 평가를 받은 이유는 ‘로컬화 한다는 것은 실정에 맞게 고치고, 연구 개발한 맛이라면 완벽하겠지만. 너무도 프랑스 요리와 똑같이 만든 것은 처절한 아류라는 점이다. 지금 먹은 요리에는 프랑스 요리사의 모습이 그대로 남아있다는 점. 원형이 프랑스의 것을 그대로 답습했다는 것.오리지널을 복사했다는 냉정한 평가는 정말 명확하다. 요즘 가장 국내에서 최근에 성공한 서비스를 이야기한다면, 카카오톡과 애니팡을 예로 들 수 있겠다. 다른 사람들은 어떻게 평가할지 모르지만, 정말 대단한 성공을 가진 것은 사실이다. 하지만, 둘 다 원형을 그대로 복사했을 뿐, 새로운 것은 아무것도 없다는 점이다. 아니, 오히려. 기존의 원형을 대한민국의 안 좋은 통신사의 서비스와 결합한 케이스라고 평가를 해야 정확하지 않을까 한다. 원형을 오히려 퇴보시킨 서비스라고 평가하고 싶다.카카오톡은 WatsApp을 그대로 복제했다. 대표적으로 등록되어진 전화번호로 연계하는 원형의 아이디어를 그대로 받아들였다. 하지만, 카카오톡의 새로운 신규 비즈니스 모델인 게임센터는 자체적인 생태계를 만들어서 통제하려 하는 기존의 통신사의 방식과 그다지 차이가 없다고 보인다. 뭐, 돈을 벌어야 하는 기업의 입장을 반대하는 것이 아니다. 단지, 필자의 삐딱한 시선으로는 진보를 위한 선택이 아니라, 퇴보를 위한 선택이었다는 점이 불편할 뿐이다.애니팡도 마찬가지이다. 기존의 게임방식을 그대로 복제했다. 그리고, ‘하트’라는 이름으로 무분별한 ‘스팸’을 활성화해서, 기존 통신사들이 SMS에서 얻어들이는 대량 SMS 발송을 통한 이익을, 그대로 실현한 점이다.물론, 카카오톡이나 애니팡의 ‘이익 실현 구조’는 매우 성공적으로 국내에 론칭한 것은 사실이고, 이러한 구조로 ‘돈’을 벌어야 한다는 점이 매우 안타까울 뿐이다. 개인적으로는 ‘국내’에서는 어느 정도 ‘돈을 버는 성공은’할 수 있지만, 해외에서까지 성공적으로 론칭할 것인지는 조금 의심스럽다. ( 어차피, ‘돈’을 벌면 성공이라는 관점으로는 매우 대성공이다. )넥슨의 카트라이더와 마리오 카드와 같이 일일이 나열하기에는 너무도 많은 사례들이 있어서 굳이 더 나열하지 않겠다.다만. 정말 중요한 것은 복사보다는 진짜가 더 좋다는 점이다. 가령, 오리지널이 존재하는 영역이나 예술과 같은 고부가가치의 영역에서는 ‘화가나 작가가 다른 사람의 작품을 흉내내면  웃음거리밖에 되지 않는다’는 점을 이야기하고 싶다. 필자 개인적으로는 ‘그런 웃음거리를 통한 수익실현’을 그렇게 높게 평가하고 싶지 않기 때문이다.대표적으로 통신사는 ‘스팸’과 ‘보이스 피싱’을 해결하지 못하는가? 에 대해서 필자는 그렇게 생각한다. ‘대량 SMS수입’을 포기하지 못하고, ‘전화번호를 통한 대량 통화의 수익’을 포기하지 못하는 구조적인 문제 때문에 그렇다고 생각한다.과거에 문제가 된 iOS6로 업데이트가 되면서 SKT 아이폰4S에서 발생한 전화번호 호출의 문제, ‘112 신고가 안 되는 아이폰’이라는 기사와 사건에 대한 문제의 근본적인 원인은 SKT가 국제표준 방식을 따르지 않아서 발생한 문제라는 것을 모르는 사람들이 정말 많다. 이 문제를 더 파고들어가면, 부당한 SMS수입을 얻고 있는 국내 통신사들의 부도덕한 점도 드러난다. 2003년 이후 3G 서비스(WCDMA)가 도입되었지만, 문자 메시지 국제표준이 기존의 80 byte에서 140 byte로 늘어났지만, 정작 통신사들은 국제표준규격을 지키지 않으면서 연간 수백억의 이익을 부당하게 얻어냈다. 다만. 아이폰4s 출시 당시 KT는 140바이트를 맞추었지만, SKT는 아직도 80 byte였다는 점을 예로 들고 싶다.국제표준을 따르거나, 해외의 서비스가 ‘돈’이 되는 것에는 빠르지만, ‘돈’이 안 되는 기준에는 미온적이고, 대처가 느린 것에 대해서는 참으로 훌룡(?)한 성공적인 방법이라고 평가를 굳이 필자와 같은 주변 사람이 할 필요가 있을까 한다. 그런 훌륭한 평가는 비싼 컨설팅 비용을 지불한 뛰어난 전문가들이 할 것이기 때문에...내 주변에 성공한 개발자와 성공한 벤처 사업가...성공한 개발자. 고급 승용차를 몰고, 출근하는 개발자의 모습을 본다면, 성공한 개발자의 향기를 느낄 수 있을까? 물론, 일반적으로 그럴 수 있다고 생각한다.자본주의 사회에서 ‘돈’은 그 사람을 평가하는 가장 기본적인 ‘수단’이기 때문이다. 성공하지 못한 필자는 아니지만, 필자 주변에는 고급 승용차인 BMW나 벤츠를 직접 몰고 다니는 성공한 개발자들이 여럿 있다. 그리고, 상당히 많다. 사업을 하는 사람으로부터, 프리랜서인 사람까지 매우 다양하다.분명, 그들은, 자신만의 서비스와 제품을 실현하였고, 시장에서도 안정적인 자신만의 브랜드를 확립하였고, 후배들로 존경을 받고 있으며, 직원들에게 비전과 꿈을 주고 있으며, 새로운 기술과 시장에 대해서 언제나 도전하고 있는 사람들이 있다.그들은 충분히 ‘성공’한 사람들이다.‘복제’와 ‘아류작’이 아니더라도. 독특한 자신들만의 서비스와 제품을 구현하여 성공한 개발자들이 분명 존재한다.그들의 성공요인을 주변의 사람으로서 살펴본다면, 몇 가지의 요인이 있다고 정의할 수 있다. 그것들을 필자의 주관적인 생각으로 정리해보면, 크게 4가지 정도로 정리할 수 있다고 본다.하나. 그들은 뛰어난 개발자는 아니었다.그들은 아주 탁월한 능력을 소유한 개발자들은 아니었다는 점이다. 그리고, 아주 뛰어난 학벌을 가진 개발자들도 아니었다. 개발자 동호회에서 만난 친구도 있고, 직장생활이나 사회생활에서 만난 사람도 있었지만. 그들은 아주 탁월한 재능을 지녔거나, 엄청난 코딩능력, 뛰어난 직관을 지닌 사람만은 아니었다.순수한 개발 능력만 놓고 본다면, 오히려, 뒤처지는 개발자들이었는지도 모른다. 하지만, 뛰어난 개발자들이나 아이디어를 가진 사람들과 친하게 지냈으며, 그들의 도움을 자연스럽게 얻어내는 소통의 달인은 아니었지만, 개발자 커뮤니티에 매우 즐겁게 활동을 하던 사람들이었다.둘. 그들은 우직하지만, 묵묵하게 자신의 상품과 아이디어를 다듬었다.그들은 하나의 아이디어가 실현되는 것을 쉽게 포기하지 않았다. 사업을 하기 전에는 그 아이디어를 실현하기 위해서 애썼고, 속한 회사가 아이디어에 대해서 낮은 평가를 하는 것에 대해서도 크게 실망하지 않았다. 오히려, 반대를 해도 해당 서비스와 제품, 기술에 대한 애정이 정말 높았으며, 그것을 실현하려고 매우 애썼다.처음에는 언제나 소프트웨어는 단순한 것부터 시작한다.그 단순한 것을 꾸준하게 다듬고, 소프트웨어에서 제품으로 다듬어서 시장에서 가치를 인정받을 수 있도록 수년 이상을 투자하고 노력해야만 얻어진다. 그것은 스티브 잡스도 똑같았다. iOS는 하루 이틀 만에 나온 소프트웨어가 아니기 때문이다.심지어, 몇 년 동안 밥을 굶더라도, 자신이 생각하는 가치를 실현하기 위해서 포기하지 않고 도전했던 우직한 도전이 오히려 성공을 만들어 내었다. 분명, 훌륭한 소프트웨어는 뛰어난 기술로 만들어지는 것만은 아니다는 것을 요 근래에서야 필자도 느낀다.필요한 가치가 적정한 가격에 구현되어진 것이 정말 필요하다는 점이다. 뛰어난 기술이 뛰어난 제품을 만드는 것이 아니라, 뛰어난 제품이 뛰어난 기술을 만든다는 것이다. 그것이 사용자들로 하여금, 또 다른 가치를 얻을 수 있는 기능을 제공한다는 것에 대해서 굳이 설명하지 않더라도, 그들은 그 아이디어와 생각을 실현하기 위해서 자신만의 길을 걸었다.정말 우직할 정도로... 필자 주변의 그들은, 몇 년을 일 년에 몇백만 원을 벌더라도, 그 꿈을 포기하지 않았다.셋. 시장과 세상의 시선을 그렇게 두려워하지 않았다. 자신의 ‘가치’와 ‘비전’을 실현했다.자신의 아이디어와 자신의 서비스, 제품을 지키기 위해서 약간의 주변 사람들에게 욕을  얻어먹는 것을  두려워하지 않는다. 필자가 아는 어떤 기업은 시장에서는 냉혈안이라는 말도 듣고, 불법 복제된 제품에 대해서는 가차 없는 소송도 불사하는 어떤 기업을 알고 있다. 하지만, 그 회사와 그 사장에 대해서 필자는 비난하지 않는다. 왜냐하면, 그는 기업 내부의 직원들에게는 절대 급여를 밀리지 않고, 야근을 시키지 않는 최고의 사장이었기 때문이다.시장과 타인에게는 가차 없지만, 자신이 생각한 비전을 실현한 회사를 만들기 위해서 언제나 최선을 다하는 사람이었을 뿐이다. 그리고, 자기 것을 지키기 위해서 애를 썼고, 직원들과의 거리도 언제나 적절하게 유지했다. 냉정하게 기업과 사업이라는 것은 자선사업이 아니라는 것을 잘 알고 있었다. 충분하게 돈을 벌고, 외제 승용차를 사장은 타고 다니지만 ( 외제 승용차를 타는 것도, 대한민국은 간단하다. 법인세를 충분하게 낼 정도로 수익이 생기면, 그 수익으로 차를 리스해서 타면 간단하다는 대한민국의 세법 구조 때문이다. ), 모든 직원들에게 그 이익을 100% 나누어주지는 않는다. 직원은 직원일 뿐이니까.그들은 회사의 재정이 힘들어지면 소속된 직원을 힘들기 전에 내보낼 줄도 알고, 필요하다면... 해고도 그리 어렵지 않게 결정하는 사람도 있다, 영업기밀을  들고나간 직원과 소송도 불사했다. 차라리, 친구와 따로 술을  마실지언정, 직원들과의 ‘관계’는 냉정하고 쿨한 관계를 유지했다. (물론, 그렇지만. 인간관계가 깨어지는 것을 매우 괴로워하는 사람들이다. 다만, 아래 직원들에게 속시원히 이야기를 못할 뿐이다. )넷. 필요한 기술자나 기술은 기필코 얻으려 노력했다.그들은 자신이 부족한 점을 잘 이해하고 있었다. 부족한 것을 오히려, 더 널리, 많이 이야기를 하였다. 그리고, 그것을 커버하기 위해서 매우 많은 노력을 한다. 다 잘하고자 하는 팔방미인이 되는 것이 아니라, 자신이 부족한 점을, 자신이 가장 잘하는 것으로 커버하려 애쓴 것이다. 전문적인 기술을 소유한 사람에게 도움 요청하는 것을 부끄러워하지 않고, 도와준 사람에게 충분한 대우나 접대를 잊지 않았다. 그래서, 그들이 도와달라고 하면, 주변의 전문가들이 아낌없이 그를 도와준다.그 이외에서 그들은 그렇게 ‘성실’하게 일하는 친구들은 아니었다. 실제, 사장이었던 그들이 직원의 입장으로 회사를 다닐 때에는 근태 문제로 지적을 받은 친구들도 꽤 많다는 점이다. 아마도, 사업이나 자신이 좋아하는 일을 하는 것과, 어떤 일이 주어진 상태에서 일을 하는 것은 분명 다른 지도 모르겠다. 직원일 때에 불성실하지만, 자신의 일을 할 때에 성실한 것은 전혀 상관관계가 없어 보인다. 한편으로는 ‘사장’이나 ‘자신의 일’을 하는 사람의 경우에는 특별하게 ‘근무시간’이라는 것 자체는 큰 의미가 없다는 점이 더 정답일 것이다. 하여간, 그들은 성공한 개발자들이고, 성공한 기업인이 되어 있었다. 자신만의 제품이나 서비스를 만들면 자연스럽게 ‘사장’이 되어버리는 것이 소프트웨어 업계의 현실인 듯하다.그렇다면, 대한민국에서 ‘성공’이란 ‘돈’을 의미하는가?강남의 최고급 아파트와 외제 승용차가 성공을 의미할까?자신의 뛰어난 기술력으로 커뮤니티에서 인정받고, 유명해진 명예를 얻는 것이 성공을 의미할까? 다른 사회현상을 생각하면서 다시 한번 비교해보자.요즘 개발자들도 오디션 프로에 영향을 받은 듯하다. 요즘 연예계 지망자들이나 배우나, 가수를 꿈꾸는 친구들이 선배나 멘토들에게 묻는 것이 언제나 똑같다고 한다.그것은 ‘빠르게 성공’하고 ‘빠르게 명예’를 얻는 방법이 무엇이냐 묻는 것이다.어렵고 복잡하고, 길게 걸리는 방법은 무시하고, 오디션 프로에서 1등을 해서, 빠르게 성공하는 방법만을 생각한다고 한다.물론, 그 방법도 있을 것이다.소프트웨어의 세계에도 똑같은 방법이 있다. 대표적인 방법이 유명대학을 가서, S 멤버쉽이 되고, 대기업에 입사해서 경력을 쌓은 다음, 해외의 서비스를 적당하게 분석하다가, 성공적으로 론칭한 서비스를 재빠르게 국내에 도입해서 성공에 이르게 하는 방법이 아마도 가장 빠른 방법일 수 있겠다.물론, 이 방법으로 ‘성공’을 쟁취하려 하는 개발자라고 하더라도. 비난하지 않는다.분명, 그 길은 대다수 ‘성공’이라고 부른다. 하지만, 그 길을 선택하고 집중하는 것 또한 매우 어렵고 힘든 길이다. 선택한다고 얻을 수 있는 길도 아니다.가령, 이 글을 읽는 독자가 학생이라면. 가장 먼저 명문대학을 가는 것부터 시작해야 할 테니, 당장, 이 내용을 덮어버리고, 국영수를 공부하는 것에 몰두해야 하기 때문이다.사실, 가장 넓게 알려진 성공으로 가는 길은 가장 가기 어려운 길인지도 모른다. 경쟁이란 정말 어렵고 힘들 것이라는 것을 잊지 말자.본론으로 다시 돌아와 보자. 개발자로서 '성공'이란 무엇을 의미하는가? 아니, 개발자로서 비전을  갖는다는 것은 무엇을 의미하는가?  원천적으로 개발자의 삶이란 어떻게 살아야 하나요라고 묻는다면,이 문제는 정말 어렵고, 사람마다 다르기 때문에 최선을 다하는 것이 정답이라라는 교과서적인 답변만 늘어놔야 하는지도 모르겠다.이점에 대해서는 이제는 폐간했지만 오랫동안 개발자들의 벗이 되었던 마이크로소프트웨어 잡지에 대해서 원망을  슬쩍해보자.그것은, 나에게 ‘정말 대단히 큰 재미’를 선사했다는 것이 나에게 가장 처음 다가온 충격이었는지도 모른다. 처음에 가진 꿈은 그냥, ‘소프트웨어 개발’을 통해서 삶을 영유할 수 있는 것만으로 나는 행복했다는 점이다. 그래서, 이 소프트웨어의 세계로 진입하게 된 마이크로소프트웨어에 대해서 원망을 해야 하는지도 모르겠다.하지만 필자는 소프트웨어로써 ‘개발자로서 성공’을 하기 위해서, 이 직업과 삶을 선택한 것이 아니라, ‘개발자로 살기 위해서’이 삶을 선택한 것이었다. 나이를 먹고, 무언가를 목표로 살아온 경험을  되돌아본다면, ‘돈’과 ‘명예’를 선택하지 않았을 때에, 오히려, ‘돈’과 ‘명예’를 얻지 않았는가 하다. 오히려, ‘돈’을 선택하던 시기에 ‘돈’을 더 많이 잃어버린 경험도 가지게 되었다.이제는 주변을  되돌아보면, 필자는 꽤 넓은 스펙트럼을 가지게 되었다는 것을 느끼게 된다. 한때는 고인이 되셨지만 대통령이셨던 분부터, 수천억을 소유한 재벌 총수, 의료재단과 대학법인을 소유하신 분, 병원의 원장님들을 비롯한 분들을 비롯하여, 출판계, 영화계, 물론. 다수의 소프트웨어 개발자들까지. 매우 넓은 사람 관계를 만들어본 것 같다.그중에 소프트웨어 개발자들은 참 착하고 바보스러운 사람들이 많은 것 같지만, 한편으로는 너무도 욕심이 많은 사람들이 존재하는 참, 신기한 동네이다.그리고, 여러 계층을 경험해보니. 모든 계층은 똑같이 피라미드 구조를 가지고 있다는 점이다. 대부분 다 똑같았다. 하층의 사람들은 싼 가격에 노동력과 지식을 제공하고, 상위 레벨에서는 적절한 대우 이상과 재미있고 신기한 일들을 많이 한다는 점이다. 이 부분은 어느 계층이나 똑같다.대표적으로 출판일을 경험했을 때에 자신의 이름이 들어간 편집장이 되는 사람과, 그것을 목표로 기획자로 일하는 직원의 급여 수준이나 처우, 대우는 정말 최고급 아키텍트와 SI 개발자를 비교하는 것 이상으로 그 상대 감은 소프트웨어 개발세 상의 것 이상으로 매우 컸다.행복한 개발자라고 한다면, ‘개발이 정말 재미있고’, ‘개발도 잘하고’, ‘소프트웨어 개발 피라미드의 상층부의 일’을 하고 있다는 사람이 있다면. 그 사람은 정말 행복할 것이다. 뭐, 그런 사람은 이 글을 읽고 있지도 않을 것이다.그러나, 개발이 재미있지 않거나, 개발을 뛰어나게 잘하지도 못하고, 소프트웨어 개발 피라미드의 하층부에서 일하고 있다면, 어떻게 생존해야 하는 가에 대해서 정말 심각하게 고민해야 한다.이 글을 읽는 독자가 이제 개발자의 길을 시작한 사람이라면 고민해라, 소프트웨어 개발을 비롯한 모든 전문적인 직업들은 새로운 것을 배우고, 익히고, 소모하면서 계속 변화되는 것을 즐길 줄 알아야 재미있는 직업이다. 그런 것이 아니라면, 정말 힘들고, 피곤하고 어려운 것이 전문직과 같은 직업이다. 만일 그런 것이 힘들다면 다른 일을 알아보는 것이 현명하다.소프트웨어 개발자들과 가장 비슷하게 일하는 웹디자이너들의 푸념이 있다.‘낮은 급여에 야근은 허구한 날, 거기에. 불투명한 미래’에 대한 그들의 이야기를 들으면서, 흔히 소프트웨어 개발자들은 그 질문에 답변한다. ‘너희들은 모니터라도 크지’라고. 대부분의 프로젝트들은 ‘분석’에 의해서 ‘일정’을 만들지 않고, ‘일정’을 통해서, ‘품질’을 선택한다고 봐야 한다.‘정말 하고 싶은 것이 무엇인가?’개발자들에게 물어보면, 대부분 당황하는 경우가 많다. 이것은 개발자이기 때문에 답변을 못하는 것이 아니라, 자신의 비전이나 꿈에 대해서 명쾌하게 정의하지 못하고 있기 때문이다. 주변의 초보 개발자들에게 이야기하고 싶은 점은...가끔은 수필집이나 여행기, 그리고. 다른 사람의 생각과 꿈에 대한 글을 많이 읽어보라고 권하는 것이다. 그러면, 그 비전과 꿈에 대해서 이야기해달라는 사람들이 꽤나 있고는 하다.문제는 그 비전은 누가 정해주는 것이 아니라, 자신이 생각하거나, 자신이 발견하는 것이 옳지 않냐고 다시 이야기를 해준다. 물론, 이렇게 이야기하는 사람도 있다.‘저는 이번 프로젝트에서 인정을 받아서, 다음 프로젝트를 수행할 때에는 팀장이 되고 싶어요!’라고 이야기할 수 있다. 하지만, 이런 ‘단기적인 비전’을 말하는 것은 아니다. 이런 ‘단기적인 비전’만을 따라가다 보면, 냉정하게 수단만 중요시 여기게 되고, 목적 자체를 잃어버린 인생의 방랑자가 될 가능성이 매우 크다.내가 생각하는 ‘성공’이란 과연 무엇인가?또 하나는, 그 ‘성공’의 목표를 너무 작게 가져도 문제이고, 너무 커도 문제라는 점이지만, 그래도, ‘꿈’과 ‘목표’가 있다는 것 자체가 재미있고, 신기하지 아니한가?‘성공은 자신이 정한 것을 이루는 것’을 의미한다고.그럼 ‘꿈’을 어떻게 정의하나요?1. 10년, 20년, 30년 후의 자신의 모습을 상상해보고 정의해봐라.2. 현재 내가 좋아하는 모든 것들을 적어봐라.3. 내가 가장 잘하고 가장 인정받는 것을 적어봐라.보통은 이렇게 끄적거리다 보면, 무언가가 조금은 구체적인 비전이 나올 수도 있지만, 아무렇지도 않은 것이 나올 수 있다. 하지만, 일단, 끄적이기 시작했다면, 다음번에는 좀 더 잘할 수 있다는 것이 중요하다. 가장 중요한 것은 ‘내가 비전에 대해서 생각하기 시작했다’는 점이다. 일단 작심 3일이라도 중요한 결정이다. 그것은, ‘결정’을 하고 ‘결심’을 하기 시작했다는 것이기 때문이다.일단, ‘써야 한다’. ‘생각은 생각일 뿐이다’주변의 개발자들이 가장 잘 못쓰는 말 중의 하나가 ‘머릿속에 다 있다’라는 말이고, ‘글로 쓰기에 너무 어려운 이야기’이다라는 이야기가 가장 잘못된 것이라는 것을 잘 모르는 경우가 많다.‘머릿속에 다 있다’라는 이야기는 한번 생각은 해봤으나, 결론을 내리지 못하였다는 이야기로 들리고, ‘글로 쓰기 어렵다는 이야기’는 그만큼 정리가 안되고, 그 일에 대해서 잘 모른다는 이야기와 똑같다.10년 20년 특정 도메인에서 일한 베테랑이라고 하는 개발자와 일을 할 때에, 자신이 하는 일은 너무도 복잡하여, 설계도나 다이어그램, 순서도, 타이밍 차트 등을 그릴 수 없다는 사람들이 있다.그들과 이야기하고, 그 업무를 다이어그램과 설계도로 만들어 주어도, 그들은 그것 말고, 설명이 안 되는 그 무언가가 있다고 이야기를 한다. 물론, 필자는 그때에 이렇게  이야기해준다.‘만일 그러한 것이 존재한다면. 그것은 당신만이 생각하는 경험이나 당신이 소중하게 생각하는 가치인지 모른다. 하지만, 그것은 어떤 지식이 되기에 매우 부족한 것일 수 있다. 지식은 설명하기 쉽고, 이해하기 쉬운 것이 지식이다. 설명하기 어려운 경험은 정규화되거나 전달되어지기 매우 어렵다’더 쉽게 이야기하면. ‘쉽게 설명하거나 글자로 남기지 못한다면, 당신은 그것에 대해서 잘 알고 있지 못한 것입니다’비전이나 목표 잡기가 너무 어려워요?!그렇다면, 당장 휴일에 컴퓨터를 내버려두고, 아이폰이나 패드와 같은 스마트하다고 우기는 디지털기기를 집안에 던져두고 여행을 떠나는 것이 현명한 방법이겠다. 그리고, 다른 매체를 들여다보고, 개발자 이외의 사람들을 만나서 이야기해보라라고 권유해야 하는 것이 맞을  듯하다.생각 이상으로 소프트웨어 개발자의 세계는 정말 좁다. 그리고, 단편적인 지식들과 단편적인 경험들만이 존재하는 세상인지도 모른다. 그래서, 소프트웨어 개발자들은 ‘관심의 폭을 넓히고,’ ‘자신을 확장’하는 것이 결론적으로는 더 뛰어난 개발자가 된다는 것을 나중에야 깨달을 것이다. 마지막으로 이야기한 한다면, 소프트웨어 개발자에게 ‘성공’이란 일단... 전혀 해보지 않았던 것을 도전해보는 것, 그리고. 삶은 소프트웨어 개발처럼 버전을 나누어서 설명하기 어렵다는 것을 이해하고. 무언가 계속 새로운 것에 도전한다는 것이 진정한 ‘성공’ 아닌가 한다.#와탭랩스 #와탭 #개발자 #개발 #프로그래머 #성공 #성공한개발자

 지난 10월 20일, 비트윈 PC 버전의 오픈 베타 테스트를 시작했습니다. PC 버전 덕분에 컴퓨터 앞에서 일과 시간을 보내는 직장인들도 편리하게 비트윈으로 연인과 대화할 수 있게 되었습니다. 이 글에서는 PC 버전에 어떤 기술이 사용되었는지 소개하고 약 4개월의 개발 기간 동안 겪은 시행착오를 공유합니다.비트윈 PC 버전 스크린샷개발 플랫폼 선택PC 버전 개발을 본격적으로 시작하기 전에 어떤 개발 플랫폼을 선택할 것인지 많은 고민을 했습니다. MFC나 WinForms 같은 네이티브 플랫폼, Qt 등의 크로스 플랫폼 라이브러리, 그리고 웹 기반 앱 등의 여러 후보를 가지고 토론을 거쳐 웹 앱으로 개발하기로 했습니다.웹 기반으로 개발하게 된 가장 큰 이유는 생산성입니다. PC 버전 팀이 웹 기술에는 이미 익숙하지만 다른 플랫폼은 경험이 많지 않았습니다. 또한, 비교적 자유롭게 UI를 구성할 수 있으며 기존의 각종 개발 도구를 이용하면 빠른 이터레이션이 가능할 것으로 예상했습니다.단, 사용자가 기존에 설치한 웹 브라우저를 통해 접속하는 방식이 아니라 브라우저 엔진을 내장한 실행 파일을 배포하는 방식을 택하기로 했습니다. 여러 브라우저 환경에 대응하지 않아도 되고, 브라우저에서 지원하지 않는 일부 시스템 기능을 직접 확장해서 사용할 수 있기 때문입니다.서버 아키텍처의 변화비트윈 서버의 서비스 로직은 Thrift 서비스로 구현되어 있습니다. 그리고 Alfred라는 자체 개발 라이브러리를 사용하여 Thrift 서비스를 Netty 기반의 서버로 구동합니다.기존의 비트윈 모바일 클라이언트는 채팅 서버와 Thrift의 바이너리 프로토콜로 통신하고 있습니다.1 그러나 웹 플랫폼에서는 서버와 지속적으로 양방향 연결을 유지하려면 WebSocket 프로토콜을 사용해야 하므로 Alfred에 WebSocket 프로토콜 지원을 추가하였습니다. 애플리케이션이 아닌 라이브러리 수준의 변화였기 때문에 기존 서비스 코드에 영향을 거의 주지 않고 새로운 프로토콜을 지원할 수 있었습니다.Alfred에 웹소켓 지원을 추가하였습니다.비트윈 PC 버전 셸비트윈 PC 버전은 크게 HTML과 자바스크립트로 작성된 웹 앱 부분과 웹 앱을 브라우저 엔진으로 구동해주고 플랫폼 API를 제공하는 셸 (Shell) 부분으로 구성되어 있습니다.비트윈 PC 버전 구조PC 버전 셸은 Chromium Embedded Framework (CEF)를 사용합니다. 이름에서도 알 수 있듯이 Chromium 브라우저 엔진을 애플리케이션에 내장하기 쉽도록 감싸놓은 라이브러리입니다. CEF는 Evernote나 Steam 등 웹 브라우저를 내장한 애플리케이션에서 널리 사용되고 있어 선택하게 되었습니다.2자바스크립트에서 셸이 제공하는 플랫폼 API를 호출할 때는 CEF의 Message Router를 사용하였습니다. Chromium은 멀티 프로세스 구조로 이루어져 있어, 렌더 프로세스에서 작동하는 자바스크립트 코드가 브라우저 프로세스에서 작동하는 C++ 코드를 호출하고 결과를 돌려받기 위해서는 별도의 처리가 필요합니다. Message Router는 이 두 프로세스 사이의 비동기 통신을 지원합니다. 이를 통해 창 투명도 조절이나 트레이 알림 표시 등 원래는 웹 플랫폼에서 지원하지 않는 기능을 확장하여 지원할 수 있었습니다.CEF에서는 Chrome 개발자 도구를 사용할 수 있어 디버깅이 용이했고, 디자이너 옆에서 바로바로 좌표나 색상 등을 바꿔볼 수 있어 협업에도 도움이 되었습니다.그러나 PC 버전을 개발하면서 가장 많은 시행착오를 겪은 부분이 CEF를 다루는 것이었습니다.문서화가 잘 되어있지 않습니다. 그래서 실제 작동 방식을 확인하기 위해 직접 소스 코드를 읽어야 하는 경우가 많았습니다일반적인 웹 브라우저에서는 잘 작동하는 API를 CEF가 자원하지 않거나 버그가 있어 다른 방식으로 구현해야 할 때가 있습니다.CEF에 노출된 API에만 접근할 수 있어 Chromium에서 제공하는 플랫폼 추상화 레이어를 활용할 수 없었습니다.비트윈 PC 버전 웹 앱비트윈 PC 버전의 주요 애플리케이션 코드는 HTML과 자바스크립트로 작성되어 있습니다. 자바스크립트로 큰 규모의 애플리케이션을 작성할 때 발생하는 여러 가지 어려움을 피하고자 React 라이브러리 및 최신 자바스크립트 기술을 적극적으로 활용하였습니다.ReactReact는 Facebook에서 개발한 오픈 소스 자바스크립트 UI 라이브러리입니다. 일반적인 웹사이트보다는 비교적 복잡한 인터페이스를 구현해야 했기 때문에 jQuery처럼 간단한 라이브러리로는 부족할 것으로 생각하여 비트윈 PC 버전은 처음부터 React를 사용하였습니다.전통적인 개발 방식에서는 UI를 변경해야 할 때 기존에 렌더링 된 DOM 요소에 명령을 내립니다. 예를 들어 어떤 항목을 삭제하려면 그 요소를 찾아서 삭제 명령을 내리게 됩니다. React를 사용할 때는 이와 달리 해당 요소가 사라진 DOM 트리 전체를 다시 생성하면 React가 이전 트리와 새 트리를 비교하여 바뀐 부분만 반영해줍니다. 전체를 다시 렌더링하기 때문에 기존에 DOM 트리가 어떤 상태였는지 신경 쓰지 않고도 원하는 상태로 쉽게 변경할 수 있어 UI 코드의 복잡도를 줄일 수 있습니다.또한, React의 컴포넌트 시스템은 독립적인 UI 요소들을 서로 영향을 주지 않고 조합할 수 있도록 해주어, 한가지 컴포넌트를 수정했을 때 의도하지 않은 다른 컴포넌트와 간섭하는 문제가 적게 발생합니다. 비트윈 PC 버전에는 약 40가지의 React 컴포넌트가 쓰이고 있습니다.자바스크립트 모듈 시스템모든 코드를 한 파일에 넣으면 코드를 관리하기가 힘들어집니다. 따라서 서로 관련 있는 코드끼리 모듈로 나누어야 하는데, 자바스크립트에는 모듈 시스템이 기본적으로는 제공되지 않습니다. 비트윈 PC 버전에서는 CommonJS 표준을 따라서 모듈을 나누고, 이를 웹 브라우저가 해석할 수 있는 형태로 합쳐주는 Webpack 빌드 툴을 사용했습니다.Webpack은 자바스크립트뿐만 아니라 CSS나 이미지, JSON 파일 등도 모듈로 취급할 수 있고, 플러그인으로 지원하는 모듈 종류를 추가할 수 있습니다. 비트윈 PC 버전을 빌드할 때 실제로 사용하는 플러그인은 다음과 같은 것들이 있습니다.jsx-loader: React에서 사용하는 JSX 코드를 자바스크립트로 변환합니다. 또한, 미래의 자바스크립트 문법을 현재 브라우저에서 지원하는 형태로 변환합니다.less-loader: LESS 파일을 CSS 파일로 변환합니다.css-loader: CSS에서 참조하는 외부 리소스를 인식하여 의존성을 파악해줍니다.url-loader: 파일 크기가 일정 이하인 리소스를 Base64 인코딩으로 내장해줍니다.ECMAScript 6ECMAScript 6는 차기 자바스크립트 표준입니다. 현재 자바스크립트의 불편한 점을 많이 해소하기 때문에 장점이 많이 있습니다. 일부 기능은 이미 브라우저에 구현되어 있지만, 아직 지원되지 않는 기능도 있어서 jstransform을 통해 ECMAScript 5 코드로 변환하여 사용하였습니다.화살표 함수: 익명 함수를 (a, b) => a + b와 같은 문법으로 훨씬 간단하게 선언할 수 있습니다. 또한, this 변수의 스코프를 현재 코드 상의 위치에 따라 결정해줍니다.클래스: 다른 언어와 유사한 클래스 문법을 제공합니다. 상속이나 접근 제한도 가능합니다.해체(destructuring) 대입: 객체의 필드를 바로 같은 이름의 변수에 대입할 수 있습니다. 예를 들어, var {a, b} = {a: 1, b: 2}; 같은 코드를 작성할 수 있습니다.기타 사용된 패키지RSVP.js: Promise/A+ 구현을 제공하는 라이브러리로, Promise 패턴을 사용하여 비동기 로직을 알아보기 쉬운 형태로 작성했습니다.FormatJS: 다국어, 국제화 지원을 위한 라이브러리입니다. UI 메시지 번역이나 날짜, 시간 등의 포매팅에 사용했습니다.정리비트윈 PC 버전은 개발 비용을 줄이기 위해 웹 플랫폼 기반의 네이티브 애플리케이션으로 개발되었습니다.비트윈 서버에서 사용하는 Alfred 라이브러리에 WebSocket 프로토콜 지원을 추가하였습니다.Chromium Embedded Framework를 브라우저 엔진으로 사용하여 웹 앱을 구동하고 웹 플랫폼에서 제공하지 않는 기능을 확장하여 사용했습니다.자바스크립트 코드의 복잡도를 줄이기 위해 React, CommonJS, ECMAScript 6 등의 기술을 활용하였습니다.VCNC Engineering Blog, 비트윈 시스템 아키텍처, 2013년 4월↩Wikipedia, Chromium Embedded Framework - Applications using CEF↩

‘이직’이라는 화두는 샐러리맨에게는 매우 무섭게 다가온다. 평생직장이라는 의미가 사라진 현대 시대에 있어서 직장생활 중에 많이 만나게 되는 단어이다. 더군다나, 소프트웨어 개발자들에게는 매우 일상적으로 발생한다. 그러니, 이직을 너무  두려워하지 말자. 오히려 평소에 이직에 필요한 스킬과 준비를 매우 당연하게 해야 한다.개인적으로 소프트웨어 관련 학과에서는 '이직'과 관련된 커리큘럼을 하나 만들어 두거나. 아니면, 교양과목이라도 있어야 하나 가르쳐야 한다고 생각한다.필자도 여러 기업에 입사하고 이직을 고민하는 과정을 똑같이 경험했다. 더 큰 경험으로는 기업을 창업하고 직원을 채용하고, 퇴사하는 과정도 같이 경험했다. 돌이켜 생각해 보면 직원의 입장과 중간관리자의 입장, 경영진과 최고 경영진의 입장에서의 ‘이직’을 바라보는 관점이 정말 매우 다르다.이번 이야기에서는 이런 ‘이직’의 관점을 ‘소프트웨어 개발자’의 입장에서  이야기해보자.이직이란 단어는 언제 만나게 될까? 이직이라는 단어를 머릿속에 떠올리게 되면서 당연하게 고민할 것이다. 더 좋은 조건을 제시하는 회사로 자리를 옮기거나, 또는. 현재 있는 직장에서 하는 일이 마음에 들지 않거나, 특정한 사람이나 환경 때문에도 이직이라는 단어는 언제나 떠올릴 수 있다.소프트웨어 개발자들이 이직을 고민하고  생각할 때에 어떤 부분들을 고민하고 생각해야 하는지 알아보자. 물론, 이번 이야가의 내용은 전적으로 필자의 주관적인 경험을 바탕으로 만들어진 내용들이기 때문에 매우 주관적이라는 것을 먼저 이야기해야겠다.다만, 작지 않은 경험을 적은 기업의 신입직원이었을 때부터, 벤처기업의 CEO, 중견기업의 CIO의 역할을 해보고 느낀 점 들을 몇 가지 정리하여 본 것이다.자, 이 글을 읽는 독자들은 ‘이직’을 고민하는가?혹은 이직이라는 단어에 대해서 어떻게 생각하는가?일단, 직장은 너무 쉽게 바꾸거나, 특정한 이유에 너무 집착하여, 너무 쉽게 결정하지 않기를 바란다. 일반적으로 한 회사에서 정년퇴직한다는 전설을 만난다는 것은 이제 거의 불가능에 가깝다. ( 필자역시, 딱 한사람 만났다. )소프트웨어 개발자들은 한 회사에 오래 근무할 수 있는 여건이 되는 사람들은 매우 극소수에 해당된다고 생각해야 한다. 대부분은 프로젝트가 종료되거나 의미가 없어지면서 이직에 대해서 고민을 시작 하게 된다.너무도 자주 만나게 되는 이 단어에 대해서 사람들마다 각자의 의미와 나름대로의 기준점을 잡아두는 것이 매우 좋다고 설명하겠다. 각자 자신이 걸어가야 할 로드맵이나 기본적인 원칙을 한, 두 가지쯤은 정해 두는 것이 좋다. 이 기준은 정말, 개인적인 기준들이다. 이 기준을 각자 가져야 한다.필자의 경우에는 초보때에 세웠던 원칙이 몇 가지 있었고, 나름 경험이 많아지면서  이러한 원칙들은 조금씩 그 기준을  추가하게 된다. 필자의 사례를 들어보자필자는 가장 먼저 사회생활 초년병의 시작을 병역특례로 시작하였다. 그래도. 나름 기준은 있었다. 그것은 앞으로 소프트웨어 개발일을 계속하기 위해서 내가 어떤 기준으로 회사를 찾아야 하는가에 대한 것이었다. 내가 세운 대원칙은 딱 하나였다. 하드웨어 작업을 병행하는 일을 한다는 것을 원칙으로 했다.그래서, 선택한 기업에서 처음 내게 할당된 일은 Z80으로 음성보드를 만들고, 적외선 센서로 터치스크린을 만드는 파트에서 Z80과 i8051의 크로스 어셈블리로 프로그래밍하는 일이었다. 내가 세운 큰 대원칙에는 맞는 일이었고, 일 자체에 대해서도 매우 큰 매력을 가졌다.하지만, 그 업체에서 병역특례 일을 하다가 부당한 노동현장(?)의 부조리를 맞이 하게 되면서 회사를 그만두게 됐다. 그 당시 얻은 경험 중의 하나는 ‘부조리한 노동현장’은 빨리 떠나라는 개인적인 원칙도 세웠다. 그 기준은 나중에 기업을 운영하면서도 가장 부끄러워할 경영진의 몫이라는 것을 인지하게 된 것도 가장 큰 경험이었다고 하겠다. ( 이런 경험은 차라리 초보나 신입 때에 경험하는 것이 그나마 불행 중 다행이며, 사회의 쓴맛을 제대로 보았다고 하겠다. 무료 법률상 담도 해보았고, 노무담당 문의도 해봤다. )그 후에 경력직 프로그래머로써 제대로 된 취업을 할 때에도 나름대로 원칙을 세웠다.병역특례 일을 하다가 그만두고 군대를 다녀왔을 당시에는 윈도우즈 애플리케이션의 개발이 매우 어렵던 시절이었기 때문에 나름 몸값을 요구할 수 있었다. 그래서, 프로그래밍을 하는 데 있어서 조금은 특이한 솔루션을 활용하는 경험을 하고 싶었고 그것을 중요한 원칙으로 삼았다.당시에 선택할 수 있는 기업은 3곳이었다. 하나는 용산 근처의 게임 개발사. 건대 부근의 한국전력에 소프트웨어를 개발해서 판매하던 회사, 그리고. 하나는 건축 소프트웨어 개발을 하는데 Auto-Cad의 ARX아키텍처 기반의 프로그래밍과 윈도즈 개발을 하는 일이었다.3군데의 회사에 면접이 다 통과된 이후에 고민하였다. 가장 적극적이었던 회사는 게임회사였다. 지금 기억으로도 90년대 중반에 팔레트 애니메이션을 능숙하게 조작하는 내 스킬을 보고 매우 탐을 내었던 게임업체의 사장이 기억난다. 그 먼 거리에서 인천의 집까지 나를 태워다 주면서, 같이 일하자고 차를 타고 오는 도중에 많은 이야기를 나누면서, 같이 일하자고 설득했다.하지만, 결정적으로 그 당시에 결혼을 한 필자의 입장에서는 ‘급여’가 가장 큰 걸림돌이었다. 전혀 엉뚱하게도 ‘급여’를 가장 많이 준다는 ‘회사’를 선택했다. 바로, 건축 소프트웨어 개발회사였다. ( 당연하지만, ‘급여’는 언제나 샐러리맨에게는 최고의 선택 기준이 될 것이다. )아마도, 필자가 그 당시에 급여는 매우 적지만, 그 게임업체에 들어갔다면 운명이 매우 많이 바뀌었을 것으로 생각한다. 당시, 병역특례를 하다가 군대를 다녀오면서 네트워크 프로그래밍에 대한 스킬까지 겸비한 필자가 게임업계로 들어갔으면 나름 재미있는 미래가  진행되지 않았을까 한다.하지만, 그래도 그 당시에 급여도 나름 가장 많았지만. 최고의 선택 기준은 ‘독특한 기술’에 대한 호기심이었다. 더군다나, 윈도즈 개발자로서 나름 이름을 알리기 시작하던 시기였기 때문에 필자의 선택은 옳았다고 생각한다.이때 중요한 화두는 ‘급여’와 ‘윈도즈 개발환경’, ‘독특한 콘셉트’이었다. 당시, 그 회사는 AutoCad에서 동작되는 한글 소프트웨어와 설계용 지원 유틸리티를 개발하는 업체였기 때문에, 선배 개발자들과의 경험이 매우 좋았다. 선배 개발자와 개발실장으로 계시는 분들이 20대 중반이었던 필자를 매우 아껴주었던 기억이 난다.최소한 그 계통에서 5년 이상 일을 했던 선배들이 몇 분 계셨고,  그분들에게 생각보다 많은 것을 얻을 수 있었다. 정말, 훌륭한 선배들은 언제나 초보와 신입들에게는 큰 도움이 된다.필자가 신입시절에 크게 결정한 것은 ‘장래성’도 아니고, 오히려 찾은 것은 ‘독특한 개발’을 경험할 수 있는 환경을 찾았고. 그것은 또 하나, 새로운 개발환경을 초기서부터 세팅하는 것도 포함되어 있었다.‘개발자가 이직을 결정해야 할 때’는 언제 인가하고 후배들이 가끔 질문을 해오거나 자문을 구해올 때가 있다. 그렇다면, 소프트웨어 개발자가 이직을 생각하는 때에 대해서 어떤 것을 고민해야 하고, 이직을 결정하기 위하여 중요한 사항은 어떤 것이 있을까?물론, 이직은 모든 분야에서 공통적으로 발생하는 요소이기 때문에 전부를 이야기할 수 없겠지만, 가장 좋은 이직이란 무엇인지 필자의 경험을 중심으로 이야기해보자. 다음에 나열하는 요소들은 ‘이직’을 고민하게 될 가장 큰 가능성을 가지고 있다.첫째. 자신의 전문성에 대해서 고민하기 시작할 때...보통은 자기계발에 충실한 사람의 경우에 자신이 제대로 된 전문성을 확보하고 있는지에 대해서 의문점이 생기는 시점에 '이직'을 고민하게 된다. 이 일을  계속하는 것이 미래에 ‘전문성’을 가질 수 있느냐에 대해서 의문을 가지기 시작할  때부터이다.둘째. 조직원들 간에 트러블이 발생하거나, 말도 안 되는 상사의 권위에 질렸을 때이 부분은 일반 직장과 동일하다. 아무리 전문성이 보장되고, 일이 괜찮다고 하더라도. 동료들과의 문제가 발생되는 부분은 어느 직종이나 동일하다.필자는 소프트웨어 개발일을 하면서도 벤처기업의 경영진 역할과, 중견병원그룹의 CIO생활을 하면서 다양한 직종의 사람들과 일을 해보고 인사권을 가지고 있었지만. 모두 동일하게 문제가 발생하는 것은 ‘직원들’ 간의 문제나, 중간 관리자의 전횡 등이 가장 큰 이유가 되었다.셋째. 프로젝트가 종료되었을 때에생각보다 하나의 프로젝트가 종료되면서, 소프트웨어 품질이나 개발에 대한 연속성이 제대로 이어지지 않는 경우에는 이직을 생각하게 된다.재미있고 즐거운 개발을 필자가 주창하는 이유 중의 하나가 이러한 ‘프로젝트 종료’ 시의 이직에 대한 고민을 하지 않기 위해서이다. 하지만, 대부분의 프로젝트들은 실패하거나 어려움을 겪는 경우가 다반사이기 때문에, 프로젝트가 종료될 때에 이런 충동을 느끼게 된다.이상 3가지의 기본적인 이슈들은 직장생활을 하면서 매번 만나게 되는 고민이고. 3가지의 고민이 모두 발생한다면, 당연하게 ‘이직’을 오히려 권해야 할 사항이 될 것이다.자, 이직에 대해서 고민하고, ‘이직’을 결정하였다면, ‘미련’없이 ‘이직’을 준비하자.‘이직’을 준비하는 것에 있어서 가장 중요한 것은 옮겨갈 회사를 잘 고르는 것이 가장 큰 것이다. 그리고. 퇴사를 하는 회사의 경우에는 최소한 1개월 정도의 업무 인수인계 작업은 당연하게 고려하자. 물론, 제대로 된 체계가 있는 회사는 당연하지만, 직원들의 이직 프로세스가 잘 잡혀있기 때문에 너무 걱정할 필요 없다.대부분의 조직은 누구 한 사람이 나간다고 하더라도, 그 프로젝트가 잘못되는 경우는 거의 없다. 그냥, 본인의 마음이 떠난다면 ‘이직’을 진행하는 것이 맞을 것이다.너무 걱정하지 말고 이직을 결심하고 진행하라고 조언하고 싶다.다만, 필자는 ‘이직 시에 적합한 회사’를 찾기보다는, ‘이직 시에 안 좋은 회사’를 피하는 방법을 먼저 터득하라고 조언하고 싶다.이직 시에 안 좋은 회사를 피하는 방법개발자들이 이직을 고려하고, 이직을 결심하게 되었을 때에는 신입의 입장과는 매우 다르다. 어느 정도 경력도 생겼고, 일에 대한 경험도 풍부해지고, 나이도 한두 살 더 먹었으며, 사람들과의 스킨십이나 커뮤니케이션 능력도 좋아지기 시작하는 시기가 된다.또한, 과거에는 ‘취업’과 ‘작은 목표’가 중요하였지만, 이제는 같이 일할 동료들에 대해서도 생각하게 되고, 일하는 회사의 비전이나 다른 부분들도 같이 고님할 것이다. 이런 어느 정도의 경험과 시야가 생겼을 때에 ‘이직 시에 좋지 않은 회사’를 골라내는 방법은 어떤 것들이 있을까?필자의 경험으로는  다음의 사항들을 고려하여 ‘이직’하려는 회사들을 평가했다.하나. 고급 개발자가 있는가?회사의 CTO나 개발실장이 고급 개발자이며, 그 분야의 '구루'급에 해당되는 사람인가? 존재한다면,  그분들이 회사 내부에서 '존경'받으며, '대우'를 받고 있는지 확인해보라. 그 회사에서 꾸준하게 엔지니어로 성장한다면..  그분들과 같은 대우를 받을 수 있는 인사 환경을 갖추고 있는지 확인하면 된다.대부분 허접한 회사이거나 일반 기업체에서 전산실의 역할이 부실한 경우라면 IT기술을 최고로 습득해도 계장 이상 올라갈 수 없는 곳이라면, IT기술을 중요시하는 기업이 아니라는 것이다. 이런 경우에는 '직장인'으로써의 비전만을 따지면 된다. ( 정치적인 것이 아니면, 급여, 복지일 것이다. )'개발자'로써의 삶이나 목표, 비전과는 전혀 상관없는 기업이기 때문에 일반적인 '직장생활'에 충실한 것이 좋을 것이다. 이와 관련된 처세술이나 비교자료는 인터넷에 많으니 검색해서 참조하자.둘. 개발자들이 오랫동안 근무한 사람들이 있는가?회사가 성장하고 발전하는 과정에서 사람들이 들어오고 나가는 것을 반복한다. 이런 경우에 회사에 오랫동안 근무한 개발자나 엔지니어가 존재하는지 확인해보는 것이 좋다. 대부분 경력이 올라가면 '급여'가 오르게 되고, 이렇게 경험이 풍부한 사람들이 많이 존재하는 개발 조직이나 회사가 발전 가능성이나 시장을 가지고 있는 경우가 많다.하지만, 회사는 충분하게 돈을 벌고 있지만, 회사 경력에 비해서 적은 경력의 개발자들이 2~3년 차들로 대부분 도배되어 있다면, 특정 시점에 직원들이 물갈이가 되거나, 개발자들이 죄다 못 버티고 나간 경우라는 뜻이다.'소프트웨어 개발자'들도 대부분 '직장인'에 가깝다. 이 회사가 정말 좋은 곳이고, 계속 다닐만한 가치가 있는 회사라면. 오래된 개발자들이 많이 있을 것이다. 이런 오래된 개발자가 없는 곳이라면 분명, 인사 문제나 처우에 문제가 있는 회사이다.셋. 사무실의 환경을 살펴라.큰 사무실이건 작은 사무실이건 '실제 일하는 사람들'이 사용하는 '책상'이라면 사용하는 흔적들이 있다. 공간은 있지만, 빈 책상에 사용되지 않는 물품들만 있다면. 인력파견업체가 대부분일 것이고, 처우나 사무실의 환경은 그다지 좋지 않을 것이다.대부분 팀장이고 이사이고 아웃소싱 일을 대부분 하고 있는 사람들일 것이고, 당연하지만, 근로환경도 최악이고, 월급이 때인다던 지, 프로젝트 진행이 개판이 되는 경우가 많다.넷. 신입직원 연수나 트레이닝 프로그램이 있는지 확인하라대부분, 이직 시에 이러한 것들을 고려하지 않는다. 하지만, 대부분의 중소기업이나 대기업들의 경우에 자체적인 솔루션이 있거나 나름 시장 지배력이 있는 회사의 경우에는 ‘사전에 교육’ 해야 할 내용들이 많아진다.당연하지만, 신입직원들에게 짧으면 2주, 길면 4주 이상의 트레이닝 코스가 존재하게 된다. 나름 시장 지배력이 있는 회사라면 이러한 코스가 당연하게 있다. 만일 이러한 코스가 없다면, 해당 기업은 의미 있는 솔루션을 만들거나, 의미 있는 서비스를 하고 있는 회사라고 보기 어렵다.그것은 중소기업들은 대부분 적당한 인력을 구인해서 적당하게 사용한다고 보면 된다.이처럼 소프트웨어 개발자가 이직을 생각할 때에 이러한 조건들도 있지만, 오히려 개발 경력이 3~4년 차를 넘기는 개발자에게 필자가 가장 중요하게 질문하는 것이 있다. ‘소프트웨어 개발이 적성에 맞는가?’라고 묻는다.굳이, 소프트웨어 개발이 아니더라도 자신의 자아실현이나 사회생활이 충분하게 실현되는 경우도 많다. 억지로, 소프트웨어 개발자의 길을  걸어가면서 주변을 괴롭히거나, 오히려. 안 좋은 중간 관리자가 되면서 IT업계의 원흉이 되는 것도 이 시기에 잘못 결정한 선배들이나 후배들도 많다.필자가 만난 여러 후배 개발자 중에는 소프트웨어를 설계하고 만드는 일이 그다지 적성에 맞지 않는 경우도 상당수 있었다. 또는, 저 사람은 아예 소프트웨어 개발을 하지 않았으며 좋겠다는 생각을 하게 된 사람도 있었다. 그래서, 오히려 조언을 하거나 유도를 해서 다른 일을 선택하고 그 길을 잘 걸어가는 후배들도 여럿 있다.하지만, 대한민국의 SI개발에만 있었다면 다른 직종도 가능할까?라는 질문에는 사실, 정답이 없다고  이야기한다. 갑을병정 이무기라고 불리는 먹이사슬의 과정 속에서 SI현장에서 다른 분야로 진출하는 것은 정말 어려운 일이다.대기업이나 중소기업의 SI에 입사해서, 프로젝트 관리자의 길을 걸어가는 사람이 아니라면, 매우 어려운 자리가 될 것이다. 하지만, SI나 SM의 이직 시에도 제대로 된 선택을 하면 매우 수월하고 편안한 자리로 이직을 할 수 있다.실제 후배들 중에는 많은 급여보다는 안정적인 자리를 원하는 도메인이 특화된 SM자리를 잘 차지하고 편안하게 일하는 개발자들도 간혹 발견할 수 있다. 하지만, 그런 환경이 아니라면 필사적으로 이직 시의 조건을 따져봐야 한다.최소한 ‘피해야 할 회사의 조건’을 따져봤다면, 이제는 가장 현실적인 ‘조건’을 나열하여 회사와 조직의 환경을 살펴보자. 다음의 조건들을 살펴봐라.야근수당을 받는가?2015년을 기준으로 나이 30세 초반에 연봉 3000~4000이라면 소프트웨어 개발자로서 만족하는 삶을 살 수 있을까? 하지만, 사회생활에 있어서 야근수당을 받거나 주말에 근무하면 추가 페이를 계산받는가? 냉정하게 계산하고 매일 야근과 주말근무를 하고 있다면, 실질적인 연봉은 무려 5~6000만 원을 받아야 정상이다.필자가 중견그룹의 CIO 역할을 하던 시절에 인사팀에서 가장 많은 경고와 안내를 받았던 것 중의 하나가 '야근'근무를 가능한 하지 않도록 유도하는 안내였다. 야근을 하게 되면 자연스럽게 지출되는 야근을 위한 식사와 연장근로수당, 그리고. 주말까지 일하게 되면 2배를 넘어가는 수당의 지급은 상당히 부담스러웠던 것이기 때문에, 인사팀에서는 이러한 근무를 하지 않도록 유도하는 것이 최선의 방법이었을 것이다.대부분 괜찮은 기업들은 '야근'근무를 유도하지 않는다.단지, 근무조건이 탐나는가?냉정하게 SI는 전문성이 매우 높은 분야인데, 대한민국에서는 그러하지 않고, 거의 막장에 가까운 환경을 가지고 있다. 매우 슬픈 일이다. 일본이나 미국과 같은 선진국에서 근무하는 SI 개발자들의 처우나 근무조건은 매우 좋은 조건들이고, 연봉 또한 매우 높다.제대로 된 SI분야의 경우에는 대체인원이 그렇게 많지 않고, 어느 정도 경력을 가진 개발자로 성장하기 매우 어려운 분야이기 때문에 경력자와 경험자를 매우 우대한다. 하지만, 대한민국의 SI현장은 정말 열악한 환경으로 변화하였고, 그 현장은 매우 절망스러운 곳들도 많다.대한민국의 SI가 이렇게 된 이유에 대해서는 여러 가지 이유와 근거와 설이 존재하는데, 필자가 생각하는 몇 가지 이유는 다음과 같다.하나. 대기업의 전산실에서 분리된 IT조직의 태생적 한계둘. 전산/IT를 제대로 전공으로 한 '선배'들이 실제 부재하다.셋. 대정부의 SI 관련 프로젝트가 갑을병정 프로세스만으로 진행되면서 만들어진 흑역사넷. 소프트웨어 품질을 모르는 PM/PL들이 아직 수두룩하다. ( 이론만 아는 방법론자들 투성이다. )다섯. 책임지는 소프트웨어 개발 조직과 개발인력이 그다지 SI현장에 없다.여섯. 소프트웨어 개발은 '자격증'과 아무 상관없고, 개발 경력과도 그다지 연관성이 없다.그래서, 대한민국의 SI현장은 주변에 잘 수소문하여 ‘괜찮은 곳’을 찾아가는 센스를 발휘하지 못하면, 암흙의 이직을 경험할 수 있다.물론, 이렇게 이야기하는 ‘이직’의 대부분은 ‘스타트업’이나 ‘도전적인’ 기업을 선택하는 것과는 다른 기준들이다. 대부분은 ‘조직’이라는 틀에서 움직이는 ‘작업자’들을 구인하고 그 공간이 나에게 맞는지에 대해서 잘 따져야 하는 것이다.결국, '조직'의 틀로 생각한다면, 일반 샐러리맨의 회사 선택의 기준과 그다지 차이가 없을 것이다.하지만, 소프트웨어 개발자의 세계에서 '이직'을 제대로 할 수 있는 방법은 말 그대로 '스카우트'을 받고 이동하는 것이다. 그런 대우를 받으려면, 제대로 평가된 ‘나의 인식’과 ‘나의 브랜드’가 있어야 가능하다는 것을 염두에 두자.결론적으로 '이직'을 제대로 하려면, 자신의 '브랜드'를 만들 수 있어야 한다. 그것이 핵심이다.그렇다면, 성공적인 이직을 하려면 무엇을 갖추어야 하는가? 그것은 다음의 6가지로 정리할 수 있다.하나. 자기만의 장점을 가져야 한다.둘. 자신만의 전문성을 가져야 한다.셋. 절대다수는 하지 못하는 희소성을 가져야 한다.넷. 내 경력과 전문성을 증명할 프로젝트를 가져야 한다.다섯. 포트폴리오를 구성하라여섯. 외부활동과 내 브랜드를 만들어라이 6가지 중에 2~3가지만 충족한다고 하여도, 소프트웨어 개발자는 제대로 된 대우나 평가를 받으면서 즐거운 이직을 경험할 것이다. 말 그대로 헤드헌팅이나 개발자 커뮤니티에서 당신에 대한 평가가 좋을 것이다.매우 당연한 것이지만, 준비된 사람에게는 언제나 기회가 만들어진다. 기회가 만들어지지  않는다는 것은 ‘준비가 부족하기 때문이다’라고 이야기할 수 있다.직업 이직을 권유받았는가? 아니면. 이직을 꿈꾸는가?그렇지만, 그렇게 브랜드나 명성을 얻기 전에 권유를 받았건, 상사가 괴롭혀서 떠나건, 이직에 대해서 고민하고 결심했다면 다음의 몇 가지를 고민하자.후배들에게 이야기하는 몇 가지 충고의 이야기가 있다. 이것은 정말 최소한의 기준이다.최소, 이 기준에 대해서는 고민하고 '이직'을 결심했으면 좋겠다.하나. 소프트웨어 개발자들이거나 SI현장에 있는 개발자라면 최소한 하나의 도메인이나 전문분야를 택했다면 최소 5년은 버텨야 한다.둘. 프로젝트나 포트폴리오는 5년 이하 경력은 세상이 제대로 인지하거나 인식하지 않는다.셋. 직장이 중요한 것이 아니라, 직업과 도메인이 중요하다.넷. 경력과 브랜드는 ㅇㅇ회사의 누구가 아니라. 누가 다니는 ㅇㅇ회사가 더 좋다는 평가를 받아야 한다.SI현장에 있건, SM현장에 있건, 대기업이나 중견기업은 파견 나온 개발자를 좋아한다. 어떤 분야이건 어떤 특수하거나 일반적인 분야이건 대부분은 교육이 필요하고, 경험이 필요하다. 그리고, 그 조직과 회사에 적응하는 기간이 필수적이다. 대부분 이러한 '비용'은 기업을 운영하는 입장에서는 어떻게든 최소화하기를 원한다.대부분 이런 신입 비용을 어떻게 줄이느냐가 관건이기 때문에, 대부분의 회사들은 가능한 '경험'자와 '경력자'를 선호하는 것이 매우 당연하다. 특히나, 관련된 일과 조직에 익숙한 사람이라면 회사 입장에서는 신입의 교육비용이 들어가지 않는 파견된 개발자들을 선호하게 된다.바로 업무에 투입하고 결과물을 얻을 수 있기 때문에, 이러한 파견된 개발자들을 선호할  수밖에 없다. 그래서, 보통 갑, 을의 조직들은 자신의 일을 위해서 파견 나온 SI, SM개발자들을 참 매력적으로 인식한다.특히나, 이렇게 일하는 SI, SM 개발자들은 함께 일하고, 같은 조직에서 일하는 사람들이기 때문에 눈으로 확인한 이러한 사람들을 좋아할  수밖에 없다. 당연한 것이지만, '면접'을 통해서 사람을 뽑는 것보다 직접 함께 일한 사람을 뽑는 것이기 때문에 해당 기회비용과 교육을 위한 시간 비용들이 모두 절약된다.그래서, 대부분은 고객 회사에서 이런 개발자들에게 먼저 이직을 권유하게 된다. 고객의 입장에서는 바로 실전에 투입할 수 있는 개발자를 얻을 수 있고, 권유를 받은 개발자 역시 중소기업이나 파견직에서 일하다가 더 높은 연봉과 복지제도를 제공하는 기업으로 옮겨갈 수 있는 기회를 얻는다.다만, 이러한 권유를 받는 것은 '인력파견'업체를 통해서 SI현장에 나가서 일하는 경우에는 이러한 '기회'를 얻기 어렵다. 실제, 이러한 '제의'를 받는 경우는 '고객'의 기업에 직접 나가서 일하는 경우를 의미한다고 봐야 한다.물론, 이러한 것을 중소기업 입장에서는 인력 빼가기?라고 볼 수 있다. 필자도 중소기업을 운영해봤지만, 중소기업에서 4~5년 이상 일을 하고 있는 직원이 아니라면, 이러한 이야기도 하기 힘들것이고, 실제, 중소기업의 일이라는 것이 '일을 배우고 가르치는 이유가 어느 정도 업무에 필요한 수준'까지만 가르치기 때문에, 이를 중소기업의 인력 빼가기라고 이야기하기 어렵다. 가르친 것도 없이 일만 시켰는데 무슨 ‘인력 빼가기’인가?다만, 가장 최악의 이직 회사를 피하는 방법은 정말 고려하다. 하지만, 이직을 할 때에 순간적인 선택에 의해서 정말 좋지 않은 선택을 하는 경우가 종종 있다. 하지만, 아래와 같은 회사로 이직을 하였다면, 재빠르게 '사표'를 내는 것이 가장 현명하다. 필자의 경험을 기반으로 이런 회사는 빨리 떠나야 한다고 생각한다.하나. 회사의 사무실의 인테리어가 영 허접하다현재의 소프트웨어 개발자들의 인테리어는 대부분 훌륭하다. 특히, 이제 막 시작한 스타트업의 경우라면 직원이 아니라, '동료'의 입장으로 참여하는 것이기 때문에 이 조건은 해당이 안될 것이다. 하지만, '직원'의 입장에서 그 회사에서 일을 하는 경우라면 '회사 인테리어'는 매우 중요하다.그것은 초라한 사무실에 초라한 책상에 기본적으로 제공되는 도구도 깔끔하지 않다면, 정말 간단하다. 그 회사에서 직원들에 대한 처우나 근로환경은 최악이라고 보면 된다. 아마도, 입사를 한지 한 달 후에 바로 급여나 근로형태에 대해서 불만이 생길 것이다.대부분 이런 회사의 특징은 인력파견 회사일 확률이 높다. 당연한 것이지만, 내부에 축적된 지식도, 솔루션도 없는 조직이다. 그냥, 싼 개발자를 구하고, 파견을 보낼 개발자를 구했을 것이고, 그것에 당신이 걸려들은  것뿐이다. 빨리 탈출하는 것이 현명하다.둘. 직원들의 얼굴 표정이 매일 야근한 것 같다.근무조건과 처우에 대해서는 그 회사에서 근무하는 직원들의 모습을 보면 된다, 깔끔한 복장에 자유롭고, 자신에 찬 얼굴을 하고 있는 경우라면 상관없다. 하지만, 세탁한지 며칠 된 복장에 연일 야근에 찌든 듯한 얼굴, 사무실에 난로도 제대로 안 때워서 매번 감기에 걸려있는 상태인듯한 모습이라면, 그 회사도 빨리 탈출하는 것이 현명하다.필자는 개인적으로 소프트웨어 개발자들을 제대로 처우하는 곳이라면 키보드와 마우스, 그리고. 의자는 최대한 자신이 원하는 도구를 구해주는 곳이라고 생각한다. 그리고, 최소한의 근무환경을 구성해줄 수 있어야 한다. 다만, 같이 고생하고 같이 나눌 동료가 아니라면 이런 회사는 빨리 탈출하다.셋. 오래된 선배 개발자의 경력이 얼마나 되는가?좋은 조직과 좋은 회사. 그런 곳은 좋은 회사다. 고로, 당연하게 좋은 회사는 계속 다닐만한 가치가 있기 때문에 오래된 개발자들이 존재한다. 회사 업력이 10년이 넘었다면, 10년을 다닌 개발자가 있을 것이고, 5~6년 차 개발자들이 여러 명 존재해야 한다.하지만, 회사 경력이 10년을 넘었는데도 그 회사 경력 2년 차가 팀장이고, 병특들로 모두 구성되어 있는 회사라면, '결코 좋은 회사는 아니다'.분명하게 회사의 사장에게 문제가 있거나, 똘아이 같은 개발이사가 있거나, 막 나가는 팀장이 있을 수 있다. 또는, 처우나 급여문제 등등 문제가 분명 존재할 것이다.넷. 가족과 같다는 이야기를 반복하는 사장의 이야기회사는 '이익'을 위하여 존재하는 곳이고, '돈'을 벌어야 급여가 나오는 회사이다. 회사는 '가족'이 아니다. 그리고, '사장'처럼 일하라고 반복하는 '사장'들이 가끔 있다. 그럼, 이렇게 반문해보자, '사장'같이 일하면, '그 회사'를 물려줄 것인가?아니다. 처우는 '노예'처럼 하면서 일은 '사장'처럼 하기를 원하는 것이다. 이런 회사도 떠나라. 또 이런 회사의 특징은 이렇다.'회사 사정이 어려워서...', '요즘 경기가 안 좋아서...', '다음에...', '이거 끝나면 뭔가 있을 거야...'부끄럽지만 필자도 이런 이야기들을 20대 후반 사장 시절에 반복했었다. 결론적으로 '지키지 못할 약속'을 그냥 반복할 뿐이다. 이런 이야기의 99%는 뻥이고, 그냥.  '립서비스'일뿐이다. 포상은 합리적이어야 하는 것이다. 또한, 엄청난 투자를 받는다고 해서  밀어붙인 일일 경우도 많다. 하지만, 언제나 '과실'중에 '이익'은 경영진만이 가지고 간다는 것을 잊지 말자.다섯. 인건비는 무조건 싼 개발자만 찾는 회사.간단하다. 경력 10년 차 개발, 고급 개발자가 할 수 있는 일을 하거나, 품질이 높은 일이 필요 없는 일이 대부분이다. 임금이 비싸고 경력이 풍부한 사람이 비싼 이유는 당연하게 있다. 하지만, 단지 급여가 싼 사람을 찾는 이유는 간단하다.'일'에 대한 가치를 알지도 못하고, '개발자'에게만 탓을 돌리는 사장이나 경영진일 경우에 대부분 이렇다. 경력 1년 차가 할 수 있는 일이라고만 생각하기 때문에, 경력 4~5년 차도 그에 합당한 급여를 줄 수 없는 것이다.당연한 것이지만, 실제 일은 단순 SM이기 때문에 그런 경력을 가진 개발자가 필요 없다고 인지하기 때문이다. 이런 회사들이야말로 정말 비전이 없다.여섯. 급하게 뽑는데 면접도 제대로 안보는 회사정말 엉터리 같은 인력파견업체의 경우가 이렇다. 자신들이 면접을 보는 것이 아니라, 고객사로 보내서 면접을 본다.만일 위에 언급한 6가지 내용 중에 한 개 이상으로 해당되는 회사나 조직에 있다면, ‘이직’을 고려하는 것이 정말 당연하다 하겠다. 하지만, 자신의 능력과 이직에 대한 준비가 되어 있지 않다면, 어쩔 수 없다. ‘샐러리맨’의 기본자세로 돌아가서, 내 능력에 합당한 현재의 자리에 만족하는 법을 배워야 할 것이고, 처세술이나 그 조직에서 버티기 위한 정치력을 발휘해야 할 것이다. 이러한 글들은 주변 서점에 널려있으니, 그런 책 한두권 읽어보기를 권장한다.‘이직’은 소프트웨어 개발자 생활을 하면서 계속 유혹과 한계를 경험하게 할 때마다 머릿속에 떠오를 것이다. 그때에 실수하지 않고, 좋은 판단을 하기 바라며. 가장 중요한 것은 ‘후회’ 하지 않고, 이미 결정한 것은 잊어버리는 것이 속 시원하다는 것이다.마지막으로 좋은 스타트업을 골라달라고 조언하는 경우에는 다음과 같이 답한다.스타트업은 좋은 동료가 될 생각이 있을 때에 들어가라는 것이다. 스타트업은 초기 멤버로서 합류하면서 고생도 같이 하고, 이익도 같이 나누는 동업자가 되는 것이다. 샐러리맨으로써 직장을 택하는 것과는 정말 다른 것이다.물론, 스타트업이 투자를 받고, 초기 멤버가 아닌 경우에는 위에서 언급한 내용과 별로 차이가 없다고 설명할 수 있다. 어느 규모나 별로 차이가 없었다.'이직'은 소프트웨어 개발자들에게는 매번 경험하게 된다. 그리고, 그 경험을 좋은 결과로 얻기를 바란다. 그리고, 언제나 좋은 선택이  필수이며, 인생 선배나 동료에게 좋은 조언을 구해보자.

편집자 주: 함께 보면 좋아요!애플리케이션 개발부터 배포까지, AWS CodeStarOverview: 작성 환경AWS CodeStar를 사용하면 애플리케이션의 서버, 언어 , 형상관리, 배포, 빌드까지 한꺼번에 관리할 수 있습니다. AWS를 사용하는 개발자라면 꼭 필요한 도구이기도 합니다. 이번 글에서는 CodeStar를 초기 설정할 때의 도움이 될 내용들을 소개하겠습니다.-서비스: AWS CodeStar-템플릿: Python Webservice, AWS Lambda목차파라미터 바인딩람다 환경변수 설정람다 레이어 설정xray 모니터링 설정람다 함수명 설정Global 섹션로컬 개발환경에서의 SAM 실행CodeStar 프로젝트 생성 후CodeStar로 프로젝트를 생성하면 소스코드와 배포를 위한 Code 시리즈 리소스들이 함께 만들어집니다. CodeCommit, CodeBuild, CodePipeline 등이 있습니다. 우선 기본으로 구축된 파이프라인부터 살펴보겠습니다.CodeCommit 리포지토리의 마스터 브랜치 코드를 변경하면 CodeBuild와 CloudFormaton 서비스를 통해 빌드, 테스트, 배포를 진행할 수 있게 설정되어 있습니다. 생성된 리포지토리의 template.yml 파일을 이용하면 프로젝트 리소스도 관리할 수 있는데, 특히 template.yml을 통해 CloudFormation으로 관리하는 리소스까지도 관리가 가능합니다.기본으로 생성된 template.yml 파일을 자세히 살펴보겠습니다.AWSTemplateFormatVersion: 2010-09-09 Transform: - AWS::Serverless-2016-10-31 - AWS::CodeStar Parameters: ProjectId: Type: String Description: CodeStar projectId used to associate new resources to team members CodeDeployRole: Type: String Description: IAM role to allow AWS CodeDeploy to manage deployment of AWS Lambda functions Stage: Type: String Description: The name for a project pipeline stage, such as Staging or Prod, for which resources are provisioned and deployed. Default: '' Globals: Function: AutoPublishAlias: live DeploymentPreference: Enabled: true Type: Canary10Percent5Minutes Role: !Ref CodeDeployRole Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Handler: index.handler Runtime: python3.7 Role: Fn::GetAtt: - LambdaExecutionRole - Arn Events: GetEvent: Type: Api Properties: Path: / Method: get PostEvent: Type: Api Properties: Path: / Method: post LambdaExecutionRole: Description: Creating service role in IAM for AWS Lambda Type: AWS::IAM::Role Properties: RoleName: !Sub 'CodeStar-${ProjectId}-Execution${Stage}' AssumeRolePolicyDocument: Statement: - Effect: Allow Principal: Service: [lambda.amazonaws.com] Action: sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole PermissionsBoundary: !Sub 'arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/CodeStar_${ProjectId}_PermissionsBoundary' 파라미터 바인딩Parameters 섹션에서는 ProjectId, CodeDeployRole, Stage 등 템플릿에서 사용할 파라미터를 지정할 수 있습니다. yml 파일 안에서는 ${ProjectId} 와 같이 사용할 수 있고, CodePipeline 환경에서 파라미터를 전달할 수 있습니다.CodePipeline → Deploy → GenerateChangeSet → Advanced → Parameter overrides람다 환경변수 설정람다 함수에서 사용할 환경변수를 설정할 수 있습니다. 아래와 같이 람다 환경변수 TZ(timezone)를 지정하면 실행 환경의 표준 시간대 설정이 가능합니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Environment: Variables: TZ: 'Asia/Seoul' 람다 레이어 설정람다 레이어를 적용하면 패키지 관리가 훨씬 편리해집니다. 함수의 패키지 크기가 3MB를 넘지 않으면 콘솔에서 코드를 직접 확인 및 수정할 수 있습니다. 람다 레이어는 zip 파일로 관리되고, /opt 폴더에 압축 해제되며 생성됩니다.람다는 250MB의 제한이 있습니다. 만약 레이어를 사용해 분리하더라도 람다함수패키지와 람다 레이어의 합으로 걸려있으므로 크기 제약에서 벗어날 수는 없습니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Layers: - arn:aws:lambda:{region}:{id}:layer:{layer-name}:{version} xray 모니터링 설정Tracing Property를 이용하면 람다 함수의 Enable active tracing 설정을 할 수 있습니다. CloudFormation 템플릿 메뉴얼엔 TracingConfig로 안내하고 있어도 빌드에 실패하여 확인해보니 SAM 템플릿의 AWS::Serverless::Function 의 스펙에선 Tracing으로 안내되고 있는 걸 볼 수 있었습니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: Tracing: Active 람다 함수명 설정람다 함수는 기본적으로 아래와 같은 이름을 부여합니다.awscodestar-{brandi-test(프로젝트명)}-lambda-{HelloWorld(template함수ID)}-{NZ6YXLZ8XD0O(RANDOM_ID)}만약 함수 간의 호출이 필요할 때는 아래와 같이 함수 이름의 지정도 가능합니다.Resources: HelloWorld: Type: AWS::Serverless::Function Properties: FunctionName: !Sub '${ProjectId}-HelloWorld-${Stage}' Global 섹션Global 섹션을 이용하면 리소스마다 동일하게 적용할 항목들을 관리할 수 있습니다.Globals: Function: Runtime: python3.6 Environment: Variables: TZ: 'Asia/Seoul' VpcConfig: SubnetIds: - subnet-a1111111 - subnet-b2222222 SecurityGroupIds: - sg-c2222222 로컬 개발환경에서의 SAM 실행API Gateway 환경 실행sam local start-api 람다 함수 직접 실행echo ‘{}’ | sam local invoke —parameter-values=‘ParameterKey=ProjectId,ParameterValue=brandi-test’ HelloWorld Conclusion지금까지 CodeStar 초기 설정에 도움이 될 내용들을 살펴봤습니다. 강력한 기능들과 함께 업무를 진행한다면 조금이라도 더 나은 개발 환경을 구축할 수 있을 거라 생각합니다.글이상근 실장 | R&D DO실[email protected]브랜디, 오직 예쁜 옷만

Overview애플(Apple) 제품을 한 번도 써본 적이 없습니다. 3주 전, 입사하고 받은 맥북(MacBook Pro)이 첫 애플 제품이었죠. 사실 개발 업무를 하면서 ‘한 번쯤은 애플 제품을 써 봐야겠다’는 생각을 하고 있었습니다. 단지 쉽사리 용기가 나지 않았을 뿐이었죠. 하지만 여러 개발 환경이 존재하는데도 개발자가 한 가지 환경만 고집하는 건 스스로의 잠재 능력을 좁히는 거라 생각했습니다. 그래서 이번 기회에 새로운 환경과 친해지려고 APM 웹서버 구성에 도전해봤습니다. (아자!) OS 설치 완료 후 환경Sierra 10.13apache 2.4php 5.6mysql 5.6 APM 설치 과정MAC 환경에서 APM 설치하려면 MAMP 방법도 있지만 기본적으로 apache, php가 설치되어 있으므로 패키지관리자 Homebrew를 이용하여 설치하겠습니다. 1.apache 설치 버전 확인$ httpd -v 명령어를 실행해서 아래와 같이 버전이 나오면 설치가 되어있는 상태입니다. $ httpd -v Server version: Apache/2.4.27 (Unix) Server built: Jul 15 2017 15:41:46 2.php 설치 버전 확인php -v 명령어를 실행해 아래와 같은 버전이 나오면 설치가 된 것입니다.$ php -v PHP 5.6.32 (cli) (built: Oct 27 2017 11:55:27)  Copyright (c) 1997-2016 The PHP Group  Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies 참고: MAC Sierra 10.13 버전에는 php7 상위 버전으로 설치되어 있습니다. Homebrew로 php5.6 하위 버전을 추가적으로 설치해야 합니다.3.Homebrew 설치Homebrew 명령어1)패키지 검색하기 -> $ brew search 패키지명 2)패키지 설치하기 -> $ brew install 패키지명 3)패키지 삭제하기 -> $ brew uninstall 패키지명 4)설치된 패키지 목록확인 -> $ brew list 5)패키지 정보보기 -> $ brew info 패키지명 6)패키지 업그레이드 하기 -> $ brew upgrade 패키지명 7)패키지 저장소 추가하기 -> $ brew tap homebrew/패키지명 8)패키지 저장소 삭제하기 -> $ brew untap homebrew/패키지명 9)패키지 링크 삭제하기 -> $ brew unlink 패키지명 가.설치파일 다운$ /usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” 나. Homebrew wget 설치 (Apple에서 제공하지 않는 패키지를 설치하기 위한 것이다.) $ brew install wget다. 심볼릭 링크 연결 $ ls -l /usr/local/bin/wget ../Cellar/wget/1.19.2_1/bin/wget bin/wget -> ../Cellar/wget/1.19.2_1/bin/wget 라. 패키지 저장소 추가 $ brew tap homebrew/dupes $ brew tap homebrew/php $ brew update 4.php56 설치가. Homebrew php56 설치 $ brew install php56 –with-apache 나. Apache에 PHP 설정 수정하기 아파치에 php7 모듈이 연결되어 있어 주석 처리 후 설치한 php5 경로로 연결한다. $ vi /etc/apache2/httpd.conf LoadModule php5_module /usr/local/php5-5.6.31-20170817-164511/libphp5.so #LoadModule php7_module libexec/apache2/libphp7.so 다. apache 재시작 apachectl restart라. phpinfo 확인 phpinfo 확인5.mysql56 설치가. Homebrew mysql56 설치$ brew install mysql56나. mysql 시작$ /usr/local/Cellar/[email protected]/5.6.38/bin/mysql.server start다. mysql 버전확인$ /usr/local/Cellar/[email protected]/5.6.38/bin/mysql –version명령어를 실행해서 아래와 같이 버전이 나오면 설치가 되어있는 상태입니다.$ sudo /usr/local/Cellar/mysql\@5.6/5.6.38/bin/mysql --version  /usr/local/Cellar/[email protected]/5.6.38/bin/mysql  Ver 14.14 Distrib 5.6.38, for osx10.13 (x86_64) using  EditLine wrapper 6.가상호스트 설정로컬에 다수의 프로젝트를 세팅하기 위한 것이다. 가. httpd.conf 파일 수정Include /private/etc/apache2/extra/httpd-vhosts.conf <- 주석제거 $ vi /etc/apache2/httpd.conf  # Virtual hosts Include /private/etc/apache2/extra/httpd-vhosts.conf 나. httpd-vhosts.conf 파일 수정NameVirtualHost : 아파치 2.4 이전 버전일 경우 80 포트에서 이름 기반 가상 호스트를 사용하겠다는 의미로 반드시 적어줘야 한다.DocumentRoot : 해당 프로젝트 소스 경로ServerName : 해당 프로젝트 접속 도메인주소 $ vi /etc/apache2/extra/httpd-vhosts.conf NameVirtualHost *:80       DocumentRoot "/Users/comkjs/Sites/ex1"     ServerName ex1.brandi.co.kr     ErrorLog "/private/var/log/apache2/error_log"     CustomLog "/private/var/log/apache2/access_log" common               Options FollowSymLinks         AllowOverride All         Order allow,deny         Allow from all         Require all granted         DocumentRoot "/Users/comkjs/Sites/ex2"     ServerName ex2.brandi.co.kr     ErrorLog "/private/var/log/apache2/error_log"     CustomLog "/private/var/log/apache2/access_log" common               Options FollowSymLinks         AllowOverride All         Order allow,deny         Allow from all         Require all granted     7. hosts 설정해당 도메인으로 접속시 DNS 서버를 사용하기 이전 로컬에 지정된 IP로 맵핑된다.$ vi /etc/hosts ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost  ::1             localhost   127.0.0.1 ex1.brandi.co.kr 127.0.0.1 ex2.brandi.co.kr Conclusion물론 오랫동안 맥북을 사용했던 개발자에겐 쉬운 내용일 수 있지만 MS와 리눅스에 익숙했던 저에겐 ‘두려움’이었습니다. 리눅스 구조와 명령어가 비슷해서 리눅스를 이용했던 이용자에겐 어렵지 않을 것입니다. 한 번 세팅해두면 환경이 바뀌지 않는 이상 잘 건드리지 않기 때문에 나중에 세팅을 바꾸는 일이 있으면 또 다시 볼 수 있도록 기술 블로그에 남겨둡니다. 분명 언젠가는 도움이 되지 않을까요. 글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #기업문화 #조직문화 #업무환경 #인사이트 #경험공유 #Mac #개발자 #신입개발자 #조언

 안녕하세요. 크몽개발팀 입니다.오늘 포스트 주제는 Android Studio JCenter 이용하기입니다.JCenter????  JCenter에 대해 처음 들으시는분들도 있을거같은데요.JCenter는 라이브러리들이 모여있는 저장소라고 보시면 되겠습니다.그렇다면 JCenter를 이용하여 무엇을 할까요?바로 외부 라이브러리들을 가져와서 프로젝트안에 Import 할려고 합니다. JCenter 사이트 링크 : https://bintray.com/bintray/jcenterJCenter 페이지에 접속하시면 위와 같은 페이지를 볼 수 있는데요.여기서 사용하고 싶은 라이브러리를 검색해보겠습니다.제가 검색한 라이브러리는 ImageLoder 라이브러인 'Glide'를 검색했습니다.빨간색으로 표시되있는게 제가 찾던 라이브러리 입니다.검색한 라이브러리를 클릭하면 위와 같이 상세페이지를 볼 수 있는데요.라이브러리 Github 주소 와 버젼에 대한 정보를 확인할 수 있습니다.그럼 이제 검색한 라이브러리를  Android Studio Gradle에 Import 하겠습니다. Android Studio에서 프로젝트를 생성하게 되면 위와 같이 3개의 그래들 파일을 볼 수 있는데요.자주 사용할 그래들 파일은 app폴더에 있는 그래들 파일입니다.그래들 파일을 열어보면 낯익은 코드들이 보이는데요.ADT에서는 매니페스트에서 버젼관리를 햇었는데 Studio에서는 그래들로 빠진거같습니다.그리고 빨간표시를 해둔곳이 바로 JCenter에서 검색한 라이브러리를 Import 하시면 되겠습니다.  위에 JCenter에서 찾은 라이브러리명을 입력하고 뒤에 버젼번호도 같이 입력합니다.그리고 Sync 버튼을 눌러주면 라이브러리가 Import 됩니다. External Libraries를 확인해보시면 라이브러리가 추가된걸 확인할 수 있습니다.---------------------------------------------------------------------------------------이렇게 JCenter를 이용하여 간단하게 라이브러리들을 Import를 할 수 있습니다.그리고 그래들 과 JCenter를 이용하여 라이브러리를 적용할때 가장 좋은점은'com.github.bumptech.glide:glide:3.+' 이런식으로 버젼에대한 값을 주면라이브러리 상위버젼이 나올경우 자동으로 최상위 버젼으로 라이브러리를 Import 해준다는 점입니다.이로써 라이브러리 버젼관리도 많이 편해질거 같습니다.이것으로 Android Studio JCenter 이용하기 포스트를 마치겠습니다.#크몽 #개발팀 #인턴 #인턴생활 #인사이트

트레바리는 독서모임을 운영하는 회사다. 멤버들이 책을 읽고, 독후감을 쓰고, 아지트에서 여러 사람들과 다양한 대화를 나눌 수 있도록 만들어준다. 아날로그적이려면 한없이 아날로그 할 수 있는 회사가 바로 트레바리다. 그러다 보니 트레바리의 첫 빌트인(?) 개발자 겸 디자이너인 나는 가끔 이런 질문을 받기도 한다. "트레바리에 개발자나 디자이너가 필요한가요?" 작년 11월과 12월, 개발과 디자인을 총동원해서 멤버십 신청 페이지의 UI/UX 개선 작업을 진행했다. 원래의 홈페이지보다 편하게 신청하도록 토스 결제를 연동하는 등 프로세스를 재편하였고, 판매할 프로덕트가 의도대로 보이도록 레이아웃을 다시 구성하였다. 컨텐츠의 가독성을 위해 컴포넌트들의 디자인도 깔끔하게 변경했다. 개선된 프로세스와 인터페이스라면 멤버십에 신청하는 사람들이 늘어날 거라고 확신했다. 홈페이지를 방문만 하고 멤버십에 신청하지 않은 이유는 '홈페이지가 불편하고 안 예뻐서'라고 생각했기 때문이었다.결론부터 말하자면 내 가설은 완전히 틀렸다. 개선된 홈페이지를 런칭했지만 방문 유저 대비 신청한 유저의 비율에는 큰 변화가 없었다. 다급히 주변에 조언을 구하기 시작했고 마켓컬리의 이지훈 님이 해주신 조언이 한참을 머릿속에 멤돌았다. "트레바리는 오프라인 경험이 메인이므로 홈페이지의 변화가 큰 효과가 없을 수 있음을 인정하고 시작해야 해요. 홈페이지는 광고를 보고 온 유저들이 독서모임에 가기 전까지 거쳐 가는 곳이에요."그렇다. 트레바리 홈페이지는 오프라인 독서모임에 참여하기 위한 건널목일 뿐이였다. 건널목이 아무리 좋다 한들 목적지가 탐탁지 않으면 사람들이 건너가지 않을 것이었다. 마찬가지로 홈페이지가 아무리 편하고 예뻐도 아지트에 와서 나누는 대화가 무의미하고 재미없다면 사람들이 트레바리를 찾지 않을 것이다.덕분에 트레바리 특성상 홈페이지를 위한 개발자나 디자이너 크루(=직원)가 필요한지 자문하게 되었다. 건널목 역할을 수행하는 홈페이지가 필요한 것이라면 이미 충분하다고 생각했다. 추가로 필요한 기능이 있다면 그때그때 적당한 프리랜서를 고용하는 게 합리적일 수도 있었다. 그렇다면 맨 위의 질문에 대한 대답은 "아니요. 필요 없어요. 프리랜서면 충분해요."가 되는 것이었다.내가 크루로서 잘 쓰일 수 있는 일은 무엇일까?얼핏 생각하기에 프리랜서면 충분해 보이지만 분명 내가 크루로서 잘 쓰일 수 있는 일이 있을 거라 생각했다. 그리고 그것을 오프라인 트레바리와 온라인 트레바리 사이에 간극이 있다는 점에서 찾았다.오프라인 트레바리는 꽤나 매력적이다. 한 시즌을 경험한 두 명의 멤버 중 한 명은 다음 시즌에도 멤버십을 신청한다. 물론 나머지 한 명까지 신청하게 만들게끔 개선할 부분들이 남아있지만 그래도 60%가 넘는 리텐션은 트레바리가 다시 올 만한 서비스라고 말해준다.온라인 트레바리는 사정이 다르다. 많은 사람이 방문하지만 금세 나가버린다. 지금의 트레바리 홈페이지는 트레바리가 뭐 하는 곳인지, 트레바리를 하면 어떤 사람이 될 수 있는지, 트레바리에서는 어떤 사람들을 만날 수 있는지 잘 알려주고 있지 않다. 미리 지인이나 미디어를 통해 트레바리의 매력을 알고 온 사람들만이 홈페이지를 샅샅이 뒤져본 후에나 어떤 곳인지를 엿볼 수 있다.이 불협화음을 잘 조율하는 일을 내가 잘 할 수 있겠다는 생각이 들었다. 나는 원래 작년 초까지 멤버였다가 트레바리 매력에 빠져 입사까지 하게 된 진성 유저였다. 덕분에 트레바리가 얼마나 좋은지, 어떻게 트레바리를 통해 예전보다 멋진 사람이 될 수 있는지, 트레바리에서 얼마나 좋은 사람들을 만날 수 있는지를 알고 있었다. 그리고 이것들을 동네방네 열심히 소문을 내고 싶은 사람이었다.트레바리 홈페이지가 오프라인 트레바리에 오기 위한 건널목이라면 건널목 입구에 삐까뻔쩍한 간판도 크게 달고, 안내판도 만들어 건널목 너머에 얼마나 멋진 곳이 있는지 넘어오고 싶게끔 기대감을 심어주고 싶다. 우리의 비전인 '세상을 더 지적으로 사람들을 더 친하게'처럼 내가 트레바리에 온다면 더 지적이고 멋진 사람이 될 수 있고, 사람들과 더 친하게 지낼 수 있음을 잘 설명해주고 싶었다. 사람은 자기가 정말 좋아하는 것을 설명할 때 지치지 않고 그 어느때보다 열심히 목소리를 높일 수 있다고 생각한다.물론 나 혼자서는 힘들 것이다. 그래서 다른 크루들과 같이 어떻게 잘 전달할 수 있을지 치열하게 고민해보기로 했다. 그 일례로 최근에 영훈님과 같이 사내 스터디를 시작했다. 이런 점들이 단순히 시키는 일만 해내는 프리랜서보다 훨씬 더 잘 쓰일 수 있는 크루로 만들어 줄 것이라고 믿는다. 아직 '그래서 구체적으로 어떻게?'까지는 고민을 끝마치지 못했지만, 드디어 어떤 방향으로 무슨 역할을 하는 사람인지를 결정하였다. 이 결정을 시작으로 올해는 '회사에 더 많은 기여를 할 수 있는 크루가 될 수 있지 않을까'하는 설렘과 '그러려면 훨씬 더 잘해야겠다'는 부담이 가득한 채로 일 년을 맞이하게 되었다.올 한 해 '세상을 더 지적으로 사람들을 더 친하게' 만들어줄 우리 크루들!#트레바리 #기업문화 #조직문화 #스타트업 #인사이트

빅 데이터 엔지니어는 무엇을 하나요?빅 데이터가 부상하면서 그와 관련된 직업군도 함께 주목받기 시작했습니다. 빅 데이터 엔지니어, 빅 데이터 애널리스트, 빅 데이터 사이언티스트 등 다양한 직업군이 생겼습니다. 오늘은 개발자 직군 중 데이터와 관련된 빅 데이터 엔지니어에 관해 이야기해 볼 것입니다. 빅 데이터 엔지니어는 무엇을 할까요? 빅 데이터 엔지니어가 무엇을 하는지 알기 위해서는 먼저 빅 데이터가 뭔지 알필요가 있겠습니다.빅 데이터는 기존 데이터베이스 관리도구의 능력을 넘어서는 대량의 정형 또는 심지어 데이터베이스 형태가 아닌 비정형의 데이터 집합조차 포함한 데이터로부터 가치를 추출하고 결과를 분석하는 기술입니다(위키 참조).빅 데이터의 특징은 방대한 데이터와 더불어 비정형 데이터까지 포함한다는 것입니다. 많은 양의 데이터와 정형화 되지 않은 데이터를 수집하는 일은 보통 일이 아닙니다. 빅 데이터를 통한 새로운 알고리즘를 만들거나 인사이트를 발견하기 위해서는 빅 데이터가 존재해야 합니다. 빅 데이터 엔지니어는 이러한 빅 데이터를 수집하고 관리하는 프로그래머입니다. 일반적인 데이터 수집과 달리 수십테라 정도의 정보를 수집 하게 됩니다. 또 그런 데이터를 어떻게 효율적으로 관리할지 고민해야합니다.데이터는 미래의 석유라고 합니다. 빅 데이터 엔지니어는 빅 데이터 분석가나 과학자들에게 이러한 석유를 가져다 주는 송유관을 설치하고 관리하는 역할을 한다고 볼 수 있습니다. 빅 데이터 활용을 위해서라면 빅 데이터 엔지니어의 역량이 반드시 필요합니다.데이터 과학자와 데이터 엔지니어는 다르다.위에서 빅 데이터 엔지니어는 데이터를 수집하고 관리하는 업무를 한다고 했습니다. 하지만 구체적으로 빅 데이터 과학자(Big Data Scientist)와 빅 데이터 엔지니어(Big Data Engineer)는 무엇이 다를까요?어떤 직업의 업무라는 것이 무 자르듯 쉽게 나눌 수 있는 것은 아니지만 확실히 그 직업만의 특징은 존재합니다. 각 직업 별로의 특징을 통해 빅 데이터 엔지니어가 빅 데이터 과학자와 어떻게 다른지 알아보도록 하겠습니다.1. 빅 데이터 엔지니어(Big Data Engineer)빅 데이터 엔지니어는 위에서도 언급 했지만, 데이터를 수집하고 관리하는 일을 합니다. 빅 데이터 엔지니어를 통해 '빅 데이터'가 만들어진다고 해도 무방하죠. 숫자나 규칙이 있는 정형 데이터는 물론이고 글자나 불규칙적인 비정형 데이터까지 수집하고 관리합니다. "그냥 데이터를 수집하고 관리하는 일인데 별거 있나?"라고 생각하실 수도 있습니다. 빅 데이터라는 개념 이전에도 데이터는 수집되었고 분석을 통해 비즈니스 문제를 해결해 왔으니까요. 그렇지만, 빅 데이터라는 개념이 부상하고 실현 가능할 수 있었던 이유는 방대한 데이터를 수집할 수 있는 퍼널(funnel) 설계과 그 데이터를 관리하고 알맞게 사용할 수 있는 시스템을 구축할 수 있었기 때문입니다.그렇기 때문에 빅 데이터 엔지니어는 프로그래밍에 아주 능숙해야합니다. 빅 데이터를 수집하고 관리할 수 있는 방법을 짜야하니까요. 또한, 개별적인 정보가 아닌 큰 틀에서의 정보를 다루고 통합하고 나누어 볼 수 있는 설계 능력이 따라주어야 합니다.정교하게 짜여진 빅 데이터가 아니라면 빅 데이터 과학자가 그것을 분석하고 사용하는데 상당한 자원이 들거나 최악의 경우 아예 이용하지 못하게 될 것입니다.2. 빅 데이터 과학자(Big Data Scientist)빅 데이터 엔지니어가 빅 데이터를 수집하고 관리한다면 빅 데이터 과학자는 그것을 요리하는 역할을 합니다. 데이터보고 직면한 비즈니스 문제를 해결할 새로운 인사이트를 도출해 내는 것입니다. 혹은 현재 가지고 있는 프로세스를 개선할 알고리즘을 만들어 낼 수도 있습니다.빅 데이터 과학자는 데이터를 분석할 수 있는 통계학적 지식뿐만 아니라 그 데이터를 다룰 수 있는 프로그래밍적 지식도 요구됩니다. 일반적인 데이터가 아닌 '빅' 데이터다 보니 그것을 쉽게 운용하고 자유자재로 이용하게 해줄 툴을 익혀야합니다. 또한, 빅 데이터 과학자에게 요구되는 핵심 역량 중 하나는 바로 머신러닝에 대한 지식입니다. 이 또한 프로그래밍 지식과 알고리즘 지식이 필요합니다. 빅 데이터 엔지니어가 되기 위한 Key Skills그렇다면 빅 데이터 엔지니어가 되기 위해서는 어떤 기술 스택들을 익혀야할까요? 빅 데이터 엔지니어는 데이터와 관련된 직군인만큼 데이터베이스와 관련된 기술스택들이 중요합니다.1. SQL데이터 관리를 하시는 분들이면 다들 알고 계시는 SQL입니다.  SQL은 관계형 데이터베이스 관리 시스템의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어입니다(위키참조).2. MapReduce(맵리듀스)맵리듀스는 구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작하여 2004년에 발표한 프레임워크입니다.(위키참조).3. Apache Hadoop(아파치 하둡)Apache Hadoop은 대규모 데이터 세트를 효율적으로 처리하는 데 사용할 수 있는 오픈 소스 소프트웨어 프로젝트입니다. 하나의 대형 컴퓨터를 사용하여 데이터를 처리 및 저장하는 대신, 하둡을 사용하면 상용 하드웨어를 함께 클러스터링하여 대량의 데이터 세트를 병렬로 분석할 수 있습니다.4. Apache Cassandra(아파치 카산드라)Apache Cassandra 자유-오픈 소스 분산형 NoSQL 데이터베이스 관리 시스템의 하나로, 단일 장애점 없이 고성능을 제공하면서 수많은 서버 간의 대용량의 데이터를 관리하기 위해 설계되었습니다. 카산드라는 여러 데이터센터에 걸쳐 클러스터를 지원하며 마스터리스(masterless) 비동기 레플리케이션을 통해 모든 클라이언트에 대한 낮은 레이턴시 운영을 허용합니다(위키참조).5. Java(자바)빅 데이터 엔지니어는 기본적으로 프로그래머이기 때문에 프로그래밍 지식있어야 합니다. 빅 데이터 엔지니어를 목표로 처음 프로그래밍을 시작한다면 자바를 추천합니다. 물론, 다른 언어를 통해 프로그래밍 실력을 쌓아도 됩니다. 그렇지만, 아파치 하둡과 아파치 카산드라가 자바를 베이스로 만들어졌기 때문에 자바를 배운다면 이 기술스택들을 습득하는데 훨씬 효율적일 것입니다.다른 포스팅에서도 항상 말씀드려왔지만 기술스택만 익힌다고 해서 그 직업을 가질 수 있는 것은 아닙니다. 기술스택은 기본이고 개발자로써의 역량이 뒷받침 되어야 시장에서 환영받는 빅 데이터 엔지니어가 될 수 있습니다.Photo by Ehud Neuhaus on Unsplash빅 데이터 엔지니어가 되기 위한 학습 콘텐츠시중에서는 완성된 단계로써 빅 데이터 엔지니어를 양성하는 프로그램은 많지 않습니다. 따라서 개인이 빅 데이터 엔지니어에게 필요한 기술 스택들을 하나씩 익혀 나가야 합니다.무료 온라인 콘텐츠도 많겠지만, 비싸지 않으면서도 잘 정제된 콘텐츠를 소개하려고 합니다. 유튜브 강좌보다는 보기 편하고 학습 환경이 잘 갖춰져 있어서 공부하기에 좋은 콘텐츠를 추천합니다.1. SQL - SQL 프로그래밍 : SQL을 무료로 학습할 수 있는 사이트(한글)2. Hadoop - 유데미 The Ultimate Hands-On Hadoop - Tame your Big Data! (영어)3. Cassandra - 유데미 From 0 to 1: The Cassandra Distributed Database (영어)데이터 엔지니어는 예전부터 있었다.오늘은 빅 데이터 엔지니어에 대해 알아보았습니다. 사실, 빅 데이터 엔지니어는 어느 날 갑자기 생겨난 직업이 아닙니다. 데이터베이스를 관리하는 프로그래머가 더 나은 기술 스택을 익히고 더 좋은 방법으로 데이터를 수집하고 관리하면서 생겨난 것입니다.세상은 빠르게 변한다고 하지만 그 안을 들여보면 서서히 발전한 것들이 다르게 네이밍(Naming) 되면서 새롭게 다가오는 것이라 생각합니다. 그렇다고 해서 그것이 변하지 않는 것이 아닙니다. 새롭게 변하는 기술들을 익히고 자신의 역량을 갈고 닦아야만 새롭게 다가오는 변화에 휩쓸리지 않고 주도할 수 있는 것 같습니다.

안녕하세요. 스티비팀 서버 개발자 이학진 입니다. 저희는 최근 서비스에서 사용 중이던 MySQL DB를 RDS로 이관하는 작업을 진행하였습니다. 무엇 때문에 이관을 결정하게 되었는지와 어떻게 이관을 진행하였는지에 대해 글을 써보도록 하겠습니다.배경stibee.com은 작년 11월에 정식 오픈한 새내기 이메일 마케팅 서비스 입니다. 사실 오픈 초기부터 얼마전까지만 해도 AWS EC2의 m4.large 인스턴스 하나로 운영되던 서비스였습니다.(사실 웹+API 서버 1대, 메일발송서버 1대)그리고 이 싱글 인스턴스에 무려 6개의 서버, mysql 1개, kafka 1개, redis 1개가 돌고 있었습니다. 그럼에도 불구하고 cpu사용률은 20%를 넘지 않았습니다.하지만 최근 사용자도 점점 늘어났고, 네이버에서 메일 수신정책을 변경하면서 메일발송서버에 대한 요청이 급증했습니다.스티비에서 네이버로 대량메일을 발송했을 때 해당 메일의 본문 링크를 자동검사하는 것을 발견했는데요, 따라서 네이버로부터 비정상적으로 많은 요청이 들어오고 있었습니다. (어떤 기준으로 이런 검사를 하는 것인지 정확한 정책은 아직 모릅니다. 담당자분 이 글을 보신다면 연락주세요. 친하게 지냈으면 합니다#슬로워크 #스티비 #개발 #서버개발 #개발환경 #MySQL #인사이트

Overview“글 한 번 써보실래요?” 입사하고 일주일이 지나 기술 블로그에 글을 써 보라는 제안을 받았습니다. 여러 고민 끝에, 아이폰 앱(이하 ‘iOS’) 주니어 개발자로서 프로젝트 경험과, 공부한 내용을 바탕으로 글을 쓰기로 했습니다. 적절한 짤이라고 생각하는 중iOS 개발자 사전 준비iOS 개발자의 길에 들어섰다면 이미 앱 개발과 개발 언어에 대해서는 알고 있을 겁니다. 개발 프로그램 Xcode와 프로그램을 지원하는 macOS 환경, 개발 언어 Swift 또는 Objective-C, iOS 앱 프로그래밍 등 iOS 앱을 개발하기 위해 필요한 내용까지도요. 우선 ‘iOS 주니어 개발자라면 꼭 알고 있어야 할 것’들을 아래 목록과 같이 정리했습니다. 글을 읽기 전, 목록 중에서 공부가 더 필요한 것이 있다면 꼭! 검색해보세요. Xcode, macOSApple Developer ProgramSwift or Objective-CCocoa TouchUIKitAuto Layout…iOS Architecture Patterns(아키텍처 패턴)“Viper 패턴 들어보셨어요?” Viper는 단순히 ‘독사’를 의미하는 줄 알았는데, MVC 패턴와 같이 디자인 패턴의 한 종류라는 건 입사하고 나서 알게 됐습니다. MVC와 SingleTon(싱글톤) 패턴은 익숙했지만 Viper 패턴은 생소했습니다. Viper 패턴을 3일 안에 분석하겠다는 저의 부끄러운 과거를 반성합니다... ㅜㅜ검색해보니 다양한 디자인 패턴을 찾을 수 있었습니다. iOS 개발자는 앱 프로젝트를 시작하기 전 또는 이미 진행되고 있는 프로젝트에서 개발을 시작한다면 우선 어떤 패턴으로 설계되어 있는지 파악해야 합니다. 그러므로 오늘은 iOS 개발에 주로 사용되는 패턴인 MVC, MVVM, VIPER를 간단하게 살펴보겠습니다.MVCMVC 패턴Model(모델), View(뷰), Controller(컨트롤러). Model에서는 애플리케이션에서 사용할 데이터들을 관리하고, View는 유저 인터페이스를 표현 및 관리합니다. Controller는 View와 Model의 다리 역할을 해 View의 입력을 Model이 반영하고, Model의 변화를 View에 갱신하는 역할을 합니다. 하지만, 애플의 MVC 패턴은 기존 MVC 패턴과 다릅니다. View와 Controller가 강하게 연결되어 있어 View Controller가 거의 모든 일을 합니다.1) 애플 MVC 패턴MVVMMVVM 패턴Model(모델), View(뷰), ViewModel(뷰모델). Controller를 빼고 ViewModel을 추가한 패턴입니다. 여기서 View Controller가 View가 되고, ViewModel이 중간 역할을 합니다. View와 ViewModel 사이에 Binding(바인딩-연결고리)가 있습니다. ViewModel은 Model에 변화를 주고, ViewModel을 업데이트하는데 이 바인딩으로 인해 View도 업데이트됩니다. ViewModel은 View에 대해 아무것도 모르기 때문에 테스트가 쉽고 바인딩으로 인해 코드 양이 많이 줄어듭니다.import Foundation // ViewModel var gameScore: Int? var gameScoreLabel: UILabel func updateGameScoreLabel() {   var text = ""   if let gameScore = gameScore, gameScore == 100 {       text = "Excellent!!"   } else if let gameScore = gameScore, gameScore >= 90 && gameScore < 100>       text = "Great Job!"   } else if let gameScore = gameScore, gameScore < 90>       text = "Not Bad~"   }   gameScoreLabel.text = text } // View Controller gameScoreLabel.text = viewModel.updateGameScoreLabel간단한 예를 들면, 게임 점수에 따라서 textView에 보여줄 내용을 담당하는 함수 등, View에서 변화가 일어나는 함수들이 View Controller에 정의되어 사용하는 경우가 많을 겁니다. 이런 함수들이 점점 많아지면 View Controller가 Massive, 많은 코드를 담게 됩니다. 그래서 이런 함수들을 ViewModel에 옮기고, 값들을 미리 세팅한 다음에 view controller에서 viewModel을 선언하고 viewModel의 함수를 불러오는 식으로 사용하면 됩니다. 매우 간단한 예제이기 때문에 대략 viewModel과 view controller에서 어떻게 사용하는지만 보시면 될 것 같습니다. 이 패턴은 주로 Reactive programming(ReactiveCocoa, RxSwift 등)을 할 때 많이 사용하는 패턴이어서 다음에 설명하겠습니다.VIPERVIPER 패턴View(뷰), Interactor(인터렉터), Presenter(프리젠터), Entities(엔티티), Router(라우터). MV(X) 패턴과 다른 패턴으로 MVC 패턴을 대체하기 위해 만들어진 패턴입니다. 먼저 Entity는 그저 모델 객체입니다. 단순하게 어떤 모델의 속성들만 있는, Dumb Model이라고 부를 수 있습니다. 이 모델 객체를 조작하는 것이 바로 Interactor입니다. 어떤 행동(behavior or use case)에 따라서 모델 객체를 조작하는 로직이 담겨 있습니다. 작업이 완료되어도 View에 아무런 영향 없이 오로지 데이터 작업만 합니다.Presenter는 데이터를 Interactor에서 가져오고, 언제 View에 보여줄지 결정합니다. View에 보여주기 전 내용을 준비하는 로직을 담당한다고 생각하면 됩니다. View는 Presenter에서 어떻게 보여줘야 할지 요청대로 디스플레이하고, 사용자의 입력을 받으면 다시 Presenter로 넘깁니다. Presenter는 View/ViewController, Interactor, Router와 상호작용합니다. Interactor로부터 조작된 데이터를 가져오고, 디스플레이하기 위해 데이터들을 준비한 다음 View/ViewController에 보냅니다.Router 또는 Wireframe은 화면 전환(navigation information)을 담당합니다. Presenter가 “언제” 화면을 전환해야 하는지 안다면, Router는 화면 전환을 “어떻게” 하는지 알고 있습니다. Router는 화면 전환 애니메이션을 구현하고, View Controller를 생성하여 Presenter와 연결합니다.항목내용ViewPresenter의 요청대로 디스플레이하고, 사용자 입력을 Presenter로 보내는 작업을 합니다.InteractorUse case에 따라서 Entity 모델 객체를 조작하는 로직을 담고 있습니다.PresenterInteractor로부터 데이터를 가져오고, View로 보내기 위해 데이터를 준비하여 “언제” View에 보여줄지를 결정합니다.Entity모델 객체. Dumb Model.Router(Wireframe)화면 전환(navigation information)을 담당하며, Presenter가 “언제” 화면 전환해야하는지를 안다면, Wireframe은 화면 전환을 “어떻게” 하는지를 알고 있습니다.하...지금까지 설명한 내용들은 막상 프로젝트 만들어 소스를 작성하려고 하면 막막해집니다. 역할이 잘 분할되어 있기에 앱의 기능을 하나 정하여 interactor, entity, presenter, view, router 만들고, 또 앱의 기능에 따라서 다시 interactor, entity,…. 고민을 많이 해야 해서 다시 MVC 패턴으로 돌아가고 싶은 마음이 생깁니다.크게 보면 Add Module와 List Module, 그리고 공통적인 모델(데이터)을 잘 분리한 앱 구조Conclusion도대체 우리는 왜 다양한 앱 디자인 패턴을 알아야 할까요? 그 이유는 바로 앱의 특성에 따라 적합한 설계를 가지고 작업해야 하기 때문입니다. 간단한 앱 프로젝트는 쉽게 개발하고 적용할 수 있는 MVC 패턴이 더 적합합니다. 반대로 MVVM 패턴이나 VIPER 패턴을 적용하면 점점 커지는 앱 프로젝트에 잘 대응할 수 있습니다. 또는 어떤 디자인 패턴이 적용된 앱 프로젝트에 참여하면, 그 디자인 패턴에 대해 알아야 앱 구조를 이해하고 기능을 추가하거나 수정할 수 있고, 작업하는 시간을 줄일 수 있을 겁니다.가장 좋은 패턴은 사람마다 차이가 있습니다. 패턴마다 장단점도 있습니다. 다만 어떤 패턴이든지 간에 구조화되고 정리된 코드는 쉽고, 직관적입니다. 이 글 하나만으로 앱 패턴을 완벽하게 마스터할 수는 없어도 패턴의 종류와 특징을 알게 되었다면 본전입니다. 다음 편도 기대해주세요! :-) 도움말 1) View Controller에서는 Controller가 View의 life cycle(라이프 사이클)에 관여하기 때문에 View와 Controller를 분리하기 어렵습니다. 개발자들 사이에서는 Massive View Controllers라고도 불립니다. 앱을 테스트할 때, Model은 따로 분리되어 테스트를 할 수 있어도 View와 Controller는 강하게 연결되어 있기 때문에 각각 테스트하기 어렵습니다. 참고문헌 iOS Architecture Patterns: Demystifying MVC, MVP, MVVM and VIPER글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #iOS

 Game culturalization, the process of cultural adaption, is the key to successfully launching video games in foreign markets. The main aspects are to make content suitable, understandable, and meaningful for the gamers of the targeted markets. To achieve these objectives, it is necessary to look into the five central pillars of culturalization: history, religion, ethnic and cultural tensions, geopolitical situations, and in-game elements.One in-game element that must be considered is music. To learn more, we interviewed the video game music expert and composer Pierre Langer, founder and managing director of Dynamedion based in Mainz, Germany. Pierre will tell us more about his internationally renowned company, the video game music business, and the culturalization process of video game soundtracks.  Pierre Langer  Dear Pierre, please let us know more about you and your company and the key services that you provide.  Pierre Langer: Dynamedion was founded by Tilman Sillescu and me in early 2000. We started with work-for-hire audio in the German games industry doing music composition, sound design and later also interactive audio integration and Live Orchestra production. We were the first to produce with live orchestra for a German game, and we eventually rolled this out as a service for other composers and game developers all over the world.Today we are one of the biggest game audio studios in the world with nearly 50 people doing music composition, music licensing, sound design, source sound recordings, audio integration, audio software development, live orchestra and live choir recording, and orchestration and arrangement for all sorts of media. We are still very much focused on video games, having worked on more than 1,800 games, but we also do a lot of movie trailers, TV series, and films.In 2009 we started a sub company of Dynamedion called BOOM library, which produces original sound effects collections as products that can be licensed by audio professionals throughout the world. BOOM Library is today recognized as one of the most popular and high-quality sound effects libraries in the world. Apart from that we also run two side labels with royalty-free stock music in a unique adaptive format (SmartSound) and a new product line of virtual software instruments (SONUSCORE). Our latest addition to our services is that we have become well known for high end vehicle recordings (cars, airplanes, helicopters, bikes, tanks, etc.) – that is a lot of fun, but also a huge challenge to source all sorts of rare or weird or super expensive vehicles.So, in short: we are specialists for everything that has to do with music & sound for games – everything except voice overs, and our music or sound effects or live productions have been used and heard in nearly every large game worldwide. As an example, we recently have been involved in these titles: Assassin’s Creed Series, Elder Scrolls Online, Monster Hunter Online, Battlefield V, League of Legends, Destiny 1 & 2, Lineage II, Horizon Zero Dawn, Fortnite, Mortal Kombat Series, World of Tanks, Hitman Series, Total War Series.Currently we are working on five super large unannounced titles, all international.  What part of the world do your requests mainly come from?  Pierre Langer: It is very international, really. Up until 2009 we had a very strong (overly strong I would say) position in Germany, working on nearly every German game title, quite some in France and some occasional overseas projects. Meanwhile this has completely changed: we are doing a good amount of German titles, but the major part comes from the US, UK, Scandinavia, Japan, Korea and China – China being one of the most important markets now.  Have you experienced a shift or a change over the years in game creation from Western countries to an international mix?  Pierre Langer: Absolutely! It seems that the five big “individual” markets (North America, Europe, China, Japan / Korea) are getting closer to each other. Even very self-sustaining markets, like the Japanese market, are opening up for more international projects coming in, but they are also looking into getting their own games distributed internationally, and of course into becoming as successful as possible worldwide. And then there is a huge amount of projects coming from all the emerging markets, so it seems that there is really no end to a lot of new great games. The biggest challenge with a new game certainly is to make yourself “heard” or do something special that your competition does not do, in order to stand out in a new market.  Orchestral Session - Dynamedion  What is culturalization in terms of video game soundtracks and sound effect production?  Pierre Langer: It is actually a very straightforward thing and kind of a no-brainer, since audio is a rather inexpensive asset for a game, while it has a huge emotional and atmospheric impact. Culturalization of a game means that you adapt the game to the specific requests of a new market. Western world audiences are used to different things than Chinese players, for example. So, if a Chinese game developer wants to push a game into the Western market, the game should be “westernized” so to say. This certainly already happens with gameplay mechanics and with graphics and – of course – with the localization. But simply changing the texts and voice over from Chinese to English doesn’t adapt a Chinese game to an EU or US audience. The look and feel of a game need to change as well, and this is where music and sound “culturalization” comes in: adapting the music and sounds (and the way of implementation and audio functionality in the game) to the specific audience that is being targeted. This does of course work in all directions – Japan to China, China to Europe, Europe to Korea, etc.  Can you give us some examples of audio culturalization in specific markets? (E.g. MENA, South America, China/Asia)  Pierre Langer: Let me go back a few years, to our very first larger game title we did music and sound culturalization for. It was “Runes of Magic” by Runewaker Entertainment, a developer based in Taiwan. The game was not extremely successful in Taiwan and Mainland China, but a German publisher by the time (Frogster) saw some great potential in that game. So, they licensed the title and got the rights to publish it in Europe and the US. In some respects, the game was a mess for a Western audience, partly due to the music and the sound + the implementation of all audio. The marketing people at Frogster understood this very quickly and started working on all these issues. The music and sound side was done in a matter of a few weeks: they asked us to replace the soundtrack by using music we had in our back catalogue (music for games that we had written, that either failed, or that had been unsuccessful – which we kept the rights to) and write a few new themes that would work as the iconic main themes of the game, so that the audience has something new and recognizable. We did that, with a full focus on writing and licensing music that would be ideal for the target audience. Then we did a similar thing with the sound effects: we simply threw out all the stuff that was in there and replaced it with sounds that where produced to fit a Western audience. To give you a very quick example: Asian players are used to high frequency sounds, very aggressive, very loud, the whole sound atmosphere being very crowded. European and US players are used to low frequency sounds – sub-bass, deep impacts, rumbling and more focused sound design (you hear one thing prominently, and everything else gets balanced down to make space for the one important sound going on). This is a very clear and super important difference – and it is also easy to fix with some new content and some new mixing.  What are typical issues that occur in sound culturalization?  Pierre Langer: Typical issues are that there needs to be some trust from the developer to the sound team. In most cases, the developer asks for culturalization from their home market to a foreign market. So, a US developer asking us to adapt the sound to fit a Chinese audience better needs to trust us that we know what we are doing, since the US developer doesn’t know themselves (otherwise they wouldn’t need us). Then there is always a big challenge with the correct audio integration. The most important bit is certainly to replace music and sound effects, to get a fitting new set of assets for the target market. However, even the best assets do not help if they are poorly integrated. Simply swapping them is not enough if the way they are being played back is not fitting. This then needs some more time and attention and focus, since we need to work with the developer directly to e.g. add some audio functionality, balance mix and master the audio, or introduce an interactive music system. It can be a very elaborate thing, but you can achieve a lot of additional quality with the most basic strategies that only cost a lower 5 digit budget.  Dear Pierre, thank you for your time and effort in providing us such enlightening insights into your work!About Pierre:Pierre was born near Frankfurt / Germany. After years of playing in bands as a guitar player in his teens, he decided to take his studies in classical music at the Johannes Gutenberg University in Mainz..A few months before his final exams he met Tilman Sillescu in early 2000, Dynamedion was founded a few weeks later. In the first years of Dynamedion Pierre worked on basically every single bit of the job you can do as an audio person in the games business: music composition, sound design, audio integration, audio management, design of audio tool chains, recording, mixing, mastering, project management, etc.As the thing grew and all the other guys joined in, Pierre focused more and more on the business side of things, leaving the creative work to the really focused experts.Nowadays Pierre enjoys keeping in touch with all the different clients of Dynamedion, thinking up new product lines and business ideas to further expand the reach and prominence of Dynamedion and all related sub-labels such as BOOM Library, Sonic Liberty, Sonuscore... and more to come.The Interview was conducted by Moritz Demmig.