SmartLink

[스마트링크 2019년 하반기 채용] 은하철도 탑승인원 2차 대모집

yoonjinho — Tue, 5 Nov 2019 14:14:19 +0900

은하철도 탑승인원 2차 대모집 시작!

스마트링크에서 올해부터 시작한 은하철도 프로젝트가 매우 훌륭하게 돌아가고 있습니다! 지난 1차 모집 이후로 2019년도 하반기 채용, 은하철도 탑승인원 2차 대모집을 통해 각 분야의 멋진 동료들을 찾아보려 합니다! 크게 개발자, 디자이너, 기획자 를 모집 합니다.

아~ 은하철도 프로젝트가 뭔지 잘 모르시겠다구요? 지난 상반기 채용공고에 저희들의 고민이 고스란히 녹아있습니다. 아래 페이지를 보시면 궁금증을 해소할 수 있을 거에요.

아래 채용정보를 확인해주세요! (그리고 지난 1차 탑승자들이 어떻게 살아가는지도 보실 수 있습니다 ㅎㅎ)

자~ 한번 보러 가볼까요?!!!

은하철도 탑승인원 2차 대모집

스마트링크 2019년 하반기 채용 안내

www.notion.so

더불어 홈페이지도 오픈~!!!

SmartLink Communications

스마트링크 커뮤니케이션즈

www.notion.so

채용공고 보러 가즈아~!!!!

[스마트링크 시즌2 채용공고] 은하철도 탑승인원을 모집합니다!

yoonjinho — Mon, 3 Jun 2019 17:30:02 +0900

스마트링크 시즌2 채용공고에 보내주신 뜨거운 반응 감사합니다!! 정말 많은 분들의 열정과 관심에 분주하지만 즐거운 만남들을 여럿 가질 수 있었습니다. 그리고 드디어!! 은하철도에 함께 탑승할 5명의 동료가 최종 선발되셨습니다. 뜨거운 관심과 지원에 다시 한번 감사드리며 아쉽지만 이번에 함께하지 못한 분들도 저희가 좌석을 보다 넉넉하게 꾸리게되면 함께할 수 있는 날이 오면 좋겠습니다.

여기서 잠깐!

그렇다고해서 스마트링크 시즌2 채용이 완전히 완료된 것은 아닙니다. 스마트링크는 언제나 좋은 분들과 함께할 준비가 되어있습니다. 상시채용 형태로 계속 이어나갈 예정이니 스마트링크 은하철도에 관심있는 분들은 언제나 문을 두드려 주시면 감사하겠습니다. 그럼 새로운 동료들과 슬슬 날아갈 준비를 하러 이만 :)

- 2019. 6. 25 어느 기분좋은 화요일

안녕하세요. 스마트링크의 Mike 라고 합니다. 기획과 마케팅을 담당하고있죠. 스마트링크는 작년부터 저희와 함께할 분들을 애타게 찾고 있습니다. 그 사이에 많은 분들을 뵙고 기회를 도모하기도 했습니다. 여러 다양한 경험을 축적하기도 했구요. 이렇게 여러 과정을 거치던 와중에 그동안 아기다리고기다리던, 그리고 열심히 준비했던 성과들이 하나둘 나오기 시작했습니다. 마치 미드에서 시즌이 바뀌는 것처럼 우리에게 근본적인 패러다임의 변화가 있었다랄까요? 이런 변화를 염두하며 지난 채용공고를 봤는데...

안되겠어. 다시 써야겠어!

그래서 이렇게 시즌2 만을 위한 채용공고를 작성하는 중입니다. 스마트링크의 시즌2는 어떻게 진행되고 그래서 어떤 분들과 함께하고 싶은지 지금부터 이런저런 이야기를 해보도록 하겠습니다.

뭐하는 회사임?

스마트링크는 소프트웨어 개발사 입니다. 끝. 참 쉽죠? 그런데 세상은 넓고 소프트웨어 개발사는 넘치고 넘칩니다. 그런데 뭐가 그렇게 다른가? 라고 물으신면! MVP(Minimum Viable Product) 소프트웨어 개발 컨설팅 전문 업체라고 말씀드릴 수 있겠습니다. 이게 뭔말이냐 하면 덩치 큰 SI도 진행하지만 주로 스타트업 또는 초기 사업 아이디어가 빠르게 시장에 진입할 수 있도록 기획, 디자인, 개발, 테스팅, 데브옵스까지 (~~물론 견적에 따라 달라집니다! 단호! ㅋㅋ~~) 풀 패키지로 작업하는걸 좋아하는 업체라고 보시면 되겠네요. 그래서 프로젝트 기간이 짧고 굵은게 많죠. 늘어지는 프로젝트 별로 안좋아 합니다. AtoZ로 빠르게, 효율적으로, 효과적으로! 일하는걸 선호하고 실제로 그렇게 일을 진행합니다. 그런데 아마 이런 의문이 드실거에요. 왜 작은일 맡는걸 좋아하지? 사실, 규모가 중요한게 아니라 AtoZ 라는게 중요합니다. (~~심지어 예산 높은 큰 프로젝트 요청을 까기도 합니다. 꽤 자주;;~~) 그 이유는? 면접때 질문 주시면 신나게 답해드리도록 하죠 ㅎㅎ 다 이유가 있습니다!

누가 일하고 있는데?

AtoZ, 풀패키지로 일하는걸 좋아한다는 대목에서 아시겠지만 있을 사람은 다 있습니다. 기획, 디자인, 개발 인력 모두 있구요. 그래야 일이 되겠죠? 다만 현재 사람수가 많지는 않아요. 소수정예! 하지만 모두 각 분야에서 베테랑들이라 자부합니다. 특히 개발사이니만큼 모든 분야는 개발을 중심으로 돌아가구요, 각 영역을 생판 모르는 분야로 치부하지않고 서로를 끊임없이 알아가고 파악하고 융화되는 방식으로 일합니다.

예를 들면 기획과 개발은 DB구조나 Convention을 공유하고, 디자인은 Front-end 최적화된 디자인과 UI/UX를 뽑아냅니다. 여기서 일일이 언급하기는 뭐하지만 일 잘하는 사람들이 모여있다고 자부하고 있고, 앞으로 동료들도 일 잘하는 사람을 가장 원하고 바라고 있습니다. 일을 잘한다는 기준이 절대적일 수는 없겠지만, 예를 들면 이런거죠. 최대한 정확하고, 낭비나 누수없이, 빠르게 문제를 해결하기 위해 계속 꼼수를 쓰는 사람들! 이랄까요? 세상에 (~~노는것 포함~~) 할일이 얼마나 많은데! 극단적 효율을 추구하는 집단이라고 보시면 되겠습니다.

제대로된 꼼수는 사실 탄탄한 정석 바탕에서 나올 수 있다죠.

다만 아직 목마릅니다. 일을 더 잘하고 싶어요. 그래서 우리는 시즌1을 보내면서 내부를 다지는 일도 지속적으로 탄탄하게 ~~단내 나도록~~ 해왔습니다. 그리고 슬슬 그 결과들이 눈 앞에 펼쳐지고 있네요. 그래서 결심할 수 있었습니다. 이제 확장의 시기가 왔다! 시즌2로 나아갈 때가 되었다!

시즌2라...시즌1엔 어떻게 했고, 시즌2에서는 어떻게 할건데??

시즌1에서 스마트링크 작업방식을 정의내리자면 이렇습니다.

천상천하유아독존!!

네, 그렇습니다. 각자 부여된 일을 독자적으로 수행해서 최종 결과물을 내는 방식이었죠. 내부적으로 진행하는 일이야 Agile 방법론을 적극 도입한다해도 외부 프로젝트를 진행하는 경우에는 어쩔 수 없는 Waterfall 방식이었습니다. 기획 작업을 마무리하면, 받아서 디자인 작업을 하고, 마지막으로 개발을 완료하는 방식이었죠. 특히 개발은 Ownership을 기반으로한 책임개발제(~~라 쓰고 독박이라 읽는다~~)로 운영되고 있었습니다. 이 방식으로 운영했던 이유는 모호한 업무분담과 그로 인한 누수를 최소화하기 위한 방책이었죠. 사공이 많으면 배가 산으로 간다는 속설을 극복할 방법이기도 했구요. 실력있는 개발자를 중심으로 이 방법은 한동안 잘 유지되는듯 했습니다. 그런데 계속 이렇게 운영하다보니 이런 상황이 발생했습니다.

될놈될, 안될안 ㅠ 개발 결과물의 빈부격차 ㅠ

책임개발제는 결과물이 사람에 의해 결정된다는 의미 입니다. 실무자의 경험이나 실력에 따라 천차만별일 수 밖에 없는거죠. 그러다보니 퀄리티 확보를 위해서는 결국 다시 여러 사람들의 손을 거쳐야하는 이슈들이 종종 발생했습니다. 사실 이는 필연적인 부분일지도 모르겠습니다. Full-Stack 개발을 추구한다해도 결국 저마다 가지고있는 개성과 강점은 다르니까요. 그럼에도 불구하고 지금까지는 딱히 문제 없었습니다. 다만 미래를 염두하면 걱정되는 부분들이 있더군요. 인력이 늘어나고 보다 다양한 사람들이 함께하게된다면 과연 이 시스템이 버틸 수 있을까? 라는 근본적 의문이 드는겁니다. (그래서 이번 채용은 Front-end와 Back-end를 구분해서 진행합니다.) 그리고...

Ownership이고 뭐고 다 좋은데 왜 외롭냐...

외롭기도 하더군요. 기획, 디자인, 개발 모두가 그랬고 특히 개발자들은 그냥 말 그대로 굉장히 외롭게 되었습니다. 복작이며 한 팀으로 일하는 방식이라기보다는 프리랜서들 조합과 같은 이 상황은 구성원들을 각자 개인의 울타리로 고립시키는 결과로 이어졌습니다. 기획, 디자인, 개발은 각자 나름의 방식으로 일하면 결국 서로 Sync를 맞추기 위한 작업이 추가될 수 밖에 없습니다. 효과적인 분업도 좋지만 결국 우리는 함께 일하는 회사라는 공동체 안에 있습니다. 능률, 효율과 더불어 협업도 굉장히 중요하죠. 적당한 균형점을 찾는게 중요해졌습니다. 앞으로 사공은 엄청 많아질거거든요. 그것도 다양한 특징과 강점을 가진 각양각색의 사공들이 말이죠. 이렇게 사공이 많아져도 배가 산으로 가면 안되죠.

우주로 가는건 괜찮을지도... 사공이 많은 배라면 차라리 이런걸 만들면 어떨까?

사공이 많은 멋진 배를 만드는 방법이란 뭘까? 누수 없는 업무처리와 능률을 모두 잡는 방법은 무엇일까? 이런 고민을 하던 와중에 우리에게 필요한건 엔진이란걸 알게 되었습니다. 이 엔진은 이런 조합으로 구성되어야 했습니다.

목표한 기능을 정확하고 안정적으로 구현할 수 있는 동력
자칫 시야를 좁힐 수 있는 미시적 요소들을 과감하게 skip할 수 있는 돌파력
누수없이 매끄럽게 진행되는 안정적 업무 전달계통
그리고 이 과정을 우리 모두 함께하고 있다는 응집력

뭔가 뜬구름 잡는 이야기들로 보일지도 모르겠습니다. 하지만 이 조합은 연역적이라기보다는 귀납적입니다. 실제 우리가 고민해온 부분을 해결하고자한 일들의 결과물이 위와 같은 역할을 하고있다는 것이 보다 정확한 표현이겠네요. 그리고 이 엔진은 한 단어로 귀결됩니다.

그렇습니다. 컴포넌트.

그리고 우리는 Components 를 엔진 삼아 ~~우주전함 대신~~ 은하철도 시스템을 구축했습니다. 이른바 스마트링크 시즌2 은하철도 프로젝트!

은하철도 프로젝트라니... 뭥미?? - 스마트링크 시즌2 은하철도 프로젝트

보통 스타트업이 성장하는 모습을 로켓에 비유하기도 합니다. 빠르고 가파르게 수직상승하는 모습을 본딴 것이겠죠. 하지만 우리는 조금 다르게 생각합니다. 한가지 아이템으로 절체절명의 상황을 이겨내고 급성장하는 방법도 좋겠지만 우리는 오히려 안정성과 지속가능성에 더 초점을 맞추고 있습니다. 이를 위해서 스마트링크는 꽤 오랜시간 공들여 Component 구축을 진행했고 그 결실이 드디어 빛을 봤습니다! 장기적으로 효율적이고도 생산적인 구조를 위해 이제까지의 내부 프로세스를 과감하게 변경하고 새롭게 아래와 같은 구조로 진행합니다.

반영구적 Components 엔진을 돌리면서 모두를 리딩하는 곳, 기관실
우리의 엔진 Components를 계속 다듬고 발전시킵니다. 내부 프로젝트도 진행하죠.
실무자들의 즐거운 놀이터, 1등석
이미 잘 구축된 Components로 안락하고 쾌적하고 빠르게 할당된 프로젝트를 진행합니다. 특히 개발자에게는 상용 서비스에서 활용 가능한 React Skill을 마음껏 연마하는 과정이기도 합니다 :)
초심자들의 탄탄한 학습의 장, 일반석
숙련도와 경험이 적은 초보자들은 체계적인 교육과 안정적인 Components 활용법을 익히고 1등석에 옮겨탈 준비를 합니다.

뭔가 괜찮은 열차죠? 은하철도 프로젝트는 크게 이런 구조로 작동하게 됩니다. 이번 채용공고를 통해 모시고자하는 자리는 1등석과 일반석 입니다. 베테랑들은 탑승한 동료들을 위해 열심히 기관실을 돌리면서 최대한 안정적이고 쾌적한 작업환경을 위해 움직입니다. 물론 내부적인 방향과 비전을 위한 고민, 세팅도 주도하겠지만 최종적으로는 모든 구성원들과 함께 공유하고 의견을 모아 진행합니다. 기관실과 객석들 역시 유기적이고 탄탄하게 연결돼야 하니까요.

가즈아~ 기관실은 구비되어있다!!

기관실과 객석이 ~~설국열차처럼~~ 꽉 막혀있지 않습니다. 본인이 원한다면 일정정도 열정과 의지로 기관실에 옮겨탈 수도 있습니다. 이건 순전히 본인의 취향에 달려있다고 생각해요. 세상은 넓고 사람은 다양하고 가치관도 제각각입니다. 그저 선택의 문제일 뿐이죠. 우리는 그저 보다 많은 사람들이 우리의 은하철도에 올라탈 수 있기를 바랄 뿐입니다. 그래서 선택할 수 있는 자리를 마련한 것 뿐이구요. 실무자들이 실무에만 집중할 수 있는 구조는 회사라는 공동체에서 매우 중요하다고 생각합니다. 선택은 여러분의 몫입니다.

1등석과 일반석이라... 좀 더 설명해보지?

고민의 공간, 기관실.

1등석과 일반석을 설명하자면 먼저 기관실 설명을 하지 않을 수 없습니다. 기관실은 끊임없이 소프트웨어 Core를 생산하는 곳이라고 보시면 되겠습니다. 그 중심은 당연히 Components 겠죠. 세상의 모든 서비스를 커버하겠다는 야심과 함께 사용자에게는 쾌적한 경험을, 개발자들에게는 효율적이고 신속한 개발환경을 선사하는 영역입니다. 그래서 개발언어를 잘 이해하고 보다 핵심적인 영역을 손대고 싶은 사람에게 적합합니다. 실력도 당연히 동반되어야겠지만 이제까지 경험으로 보자면 자기주도적인 취향도 핵심이더군요. 기관실은 이런 사람들이 모여있습니다. 사용자경험 뿐 아니라 내부 개발진들의 의견을 끊임없이 추적하고 해결하는 고민의 공간 입니다.

기관실이 잘 할테니까 팔로팔로미~ ㅎㅎ

효율의 공간, 1등석

위에서 '취향'에 대해 언급했는데요. 1등석은 취향에 따라 자신의 업무방향을 선택할 수 있는 공간 입니다. 잘 짜여진 Components와 Convention에 따라 실제 상용서비스를 만들거나 관리하는 역할을 합니다. 고민의 폭은 줄이고, 실질적인 결과물에 초점을 맞추는 효율의 공간이라고 보시면 되겠어요. 새로운 결과물을 세상에 선보이고, 이들을 잘 작동시키는 사람들이 모여있는 곳입니다. 그러다가 지금 쓰고있는 Components 개선이 좀 더 필요할거 같다 싶으면 자체적으로 해결해도되고 기관실로 넘길 수도 있습니다. 이 부분이 바로 취향의 영역이라고 볼 수 있는데요. 본인의 실력과 더불어 이 취향에 따라서 기관실로 갈지, 1등석에서 작업할지 결정할 수도 있습니다.

학습의 공간, 일반석

일반석은 다른 말로 초심자의 영역이라고 보시면 되겠습니다. 세상은 급변하고 소프트웨어 변화 역시 엄청나죠. 우리는 끊임없이 학습하고 발전해야만하는 영역에서 일하고 있습니다. 그래서 이 부분을 절대 간과해선 안된다고 생각하고 있어요. 다만 취미 정도의 학습이라면 각자 개인의 소양 정도로 진행하는 것이 적절하겠죠. 일반석은 실제 상용 서비스에 적용 가능한 수준의 학습이 이뤄지는 공간입니다. 그 핵심은 React, Meteor, MongoDB 라고 보시면 되겠구요. 고퀄 서비스들을 실제로 만들어낼 수 있는 핵심 역량을 키울 수 있는 곳입니다.

사람들은 각자 일하는 방법이나 인생설계 방향을 가지고 있습니다. 그리고 여기에 따라 너무 다양한 나름의 스타일을 가지고있죠. 우리는 이 부분을 간과해서는 안된다고 생각해요. 우리가 말하는 취향은 바로 이런 것입니다. 취향에 따라 내가 주도적인지 수동적인지, 스스로 설계하는 스타일인지 주어진 과제를 잘 해결하는 스타일인지 나뉘는게 당연하겠죠. 이 부분은 실력과는 또 다른 축인거 같습니다. 한가지 방식을 강요해봤자 상황이 제대로 돌아갈리는 만무하고 또 그래서도 안됩니다. 일을 잘 하고싶은 스마트링크는 그래서 우리가 운영 가능한 범위 내에서 최대한의 공간과 가능성을 만들고 싶었습니다. 그래서 이런 구조를 생각해낸거구요.

좀 더 솔직히 말하자면, 네. 이거 준비하는데 힘들었습니다 ㅠ 그냥 실력있는 사람들이 머리를 맞대고 모이기만 한다면야 이런 고민과 구상이 필요 없을지도 몰라요. 오히려 그게 편하기도 하구요. 척 하면 척~ 착 하면 착~ 아시죠? 그리고 이 은하철도 프로젝트를 채용공고에서 공개하는 것이 과연 좋을까? 라는 고민이 있었던것도 사실입니다. ~~우리 자뻑모드로로 보자면~~ 중요한 영업비밀일지도 모른다고 생각했거든요. 하지만 채용공고가 다소 길지라도 가능한 범위 내에서는 충분히 미리 공유하는게 좋겠다고 생각했습니다. 사실 이런 생각까지는 쉬운데 실제로 이렇게 구조를 잡는건 생각보다 매우매우 오래걸리고 어렵거든요. 그리고 그 어려운걸 우리는 해냈습니다.

Components를 잘 구축해놨다 이겁니다 ㅎㅎㅎ

다시 한번 말하자면 스마트링크는 로켓이 아니라 은하철도 입니다!!

날아오른다!!! 이거시 바로 은하철도!!!

알겠고, 그렇다면 구체적인 채용정보를 내놓아라!

그래서 누굴 뽑는것인가? 라고 물으신다면 개발자 0명 찾습니다! 0명은 무엇이냐? 좋은 사람이 있으면 있는만큼 욕심을 낼것이다! 이런 욕구와 목마름이 있다는 것이죠! 많이 지원해 주세요! 공통적으로 체크해보실 수 있는 정보를 우선 드릴까요?

현재 사용중인 기술 스택 및 도구

공통: Google Drive, Trello, Slack
기획: FramerX, Adobe XD
디자인: FramerX, Adobe XD 포함 Adobe 모든 제품군, Zeplin
Front-end: Semantic UI, React, React Native
Back-end: Meteor
Testing: Mocha, Jest
DevOps: Jenkins, Docker, Phusion Passenger, Nginx, AWS
Database: MongoDB

근무환경

최상의 사무 환경 및 공간 제공 (넓고 쾌적한 책상! 빵빵하고 쾌적한 냉난방시설! 막 엎어져서 작업하는 소파! 등)
식대 지원 (중식/석식)
4대 보험
주5일 근무
Refresh 휴가
출근시간 선택제 (8-5 / 9-6 / 10-7 / 11-8)
경조사비 지원
근무지: 서울시 강남구 신사동 520-5 삼오빌딩 3층

워크샵이라 하면 적어도 뷔페와 함께하는 야간 요트 유람 정도는 해줘야하는거 아닙니까? (사실 명목은 지스타…)

알겠고, 개발자 채용요건을 내놓아라!

네, 드...드리겠습니다. 아래를 봐주세요. 참고로 위에서 충분히 설명했듯 우선 1등석과 일반석에 모셔요~ ㅎㅎ Global Spec과 실무경험을 국내에서 탑재할 수 있는 기회를 놓치지 마세요! 이제 개알못 기획자는 아웃!

React 코드를 보고 이렇게 반응하는 사람이라면

우리는 이렇게 됩니다 ㅎㅎ

기술 스택

스마트링크는 2001년 부터 C > C++ > Java > Object Pascal > PHP > JSP > Rails > Python 등의 개발 언어 기반으로 많은 프로젝트를 수행하여 왔습니다. 현재는 Javascript, Nodejs, React, React Native, Meteor, MongoDB의 매력에 흠뻑 빠져 있지만, 프로젝트 진행의 효율을 더(even more productive) 개선할 수 있는 새로운 기술이나 방법론에 대한 목마름으로 언제든 Early Adapter가 될 준비가 되어 있습니다.

모집분야 : 각 영역의 Front-end 혹은 Back-end 개발자를 모십니다.

Javascript/Nodejs/Meteor 기반의 웹/모바일 애플리케이션 개발자
React + Meteor + MongoDB 기술 기반의 Web Application 개발
React Native + Meteor + MongoDB 기술 기반의 Mobile Native Application 개발

자격요건 : 개발에 미친 사람!!!

자유로운 소통과 공유의 가치를 잘 이해하고, 자기주도적인 환경에서 최대의 능력을 발휘하며, 긍정에너지 발산이 가능한 분 논리적이고 체계적인 문제해결 능력 및 오픈 마인드 커뮤니케이션 능력
전산 관련학과 학사 이상 또는 동일한 자격 (경력 무관)

우대조건

React, React Native 등의 JavaScript SPA(Single Page Application) 프레임워크 경험
Nodejs + MongoDB 기반 Micro Service Architecture 서비스 개발 경험
영어 커뮤니케이션 능력 (특히, 영문서 이해 능력: 해외 최신 기술을 주로 이용하다보니 한글 자료가 없는 경우가 많습니다.)
AWS 등 클라우드 서비스 운영 경험
Git 포트폴리오: 직접 작성한 패키지, 오픈소스 기여 경험
Docker 컨테이너 기반 서비스 구축 및 운영 경험
CI 시스템 구축 및 운영 경험
Mocha, Jest 등의 테스팅 프레임워크 또는 TDD(Test Driven Development) 경험

어떻게 지원하면 되는거임?

아래 루트로 지원해주시면 서류검토 후 면접일정을 직접 안내해 드립니다. 이메일과 핸드폰 연락처가 모두 기재되어있으면 참 좋겠죠? 면접이 진행되면 스마트링크에 궁금한 것, 알아보고 싶은 모든 것을 물어보실 수 있습니다! 함께 대화하는 자리라고 생각하시는게 가장 좋을거 같네요.

1. 이메일로 지원하세요! support@smartlink.io

해당 정보들도 함께 보내시면 금상첨화!

이력서 (희망연봉포함)
포트폴리오
개발 경력 자료 (github 주소 환영합니다!)

2. 로켓펀치에서도 지원하실 수 있습니다!

일반석 채용공고 https://www.rocketpunch.com/jobs/57496
1등석 채용공고 https://www.rocketpunch.com/jobs/57499

3. 잡코리아도 됩니다!

스마트링크 은하철도에 탑승할 개발자 정규직 채용(신입&경력)

http://www.jobkorea.co.kr/Recruit/GI_Read/28711079?Oem_Code=C1

4. 사람인도 됩니다!

스마트링크 은하철도에 탑승할 개발자 정규직 채용(신입&경력)

http://www.saramin.co.kr/zf_user/jobs/relay/view?rec_idx=36338553&view_type=etc

지금 망설이고 있다면???

국내에서는 중소기업, 특히 신생기업이나 스타트업에 대한 인식이 그렇게 좋지않죠. 이런 현실적인 부분도 감안해서 저희는 직접적인 코딩테스트나 압박면접 같은건 진행하지 않습니다. 차분하고 진실된 마음의 대화가 가장 중요하다고 생각해요. 본인의 평소 생각을 그저 편안하게 나눈다 생각하고 부담없이 관심만 가지고 다가와주세요 :)

이 짤처럼 무서운거 아니에요 ㅋㅋㅋ 편하게 드루와 드루와~

지금까지 소개해드린 스마트링크 시즌2, 은하철도 프로젝트 느낌이 어떠신가요? 저희의 설렘과 기대가 잘 전달이 되었을지 모르겠어요. 같은 설렘과 기대가 느껴지신다면 망설이지 마세요! 우리의 은하철도에 탑승할 분들을 그야말로 간절한 마음으로 기다리고 있습니다.

지금 당신은 지원 메일을 보내고있다~!!!

AWS S3/CloudFront CORS 세팅

grooveslap — Mon, 3 Jun 2019 11:12:28 +0900

다른 도메인(Cross Origin)에 존재하는 이미지를 HTML Canvas에 로딩시 아래와 같은 Access-Control-Allow-Origin Header 세팅이 되지 않아 이미지 로딩 자체가 block 되었다라는 브라우저의 오류 메세지를 종종 접할 수 있다.

Chrome 브라우저의 CORS 오류

AWS의 파일 스토리지 서비스인 S3와 CDN 서비스인 CloudFront를 조합해서 파일 스토리지 및 캐싱을 구현하는 경우 매우 흔하게 접하는 문제중 하나이다. 스마트링크의 Uploader 컴포넌트 또한 브라우저에서 사용자가 선택한 이미지를 S3로 업로드하고 CloudFront를 통해 캐싱된 파일을 다운로드 하는 방식이기 때문에 Uploader 컴포넌트를 사용하는 서비스에서는 필수적으로 세팅해야하는 부분이다.

많은 웹 개발자들이 파일 처리 관련 개발시 빈번하게 접하는 이슈이나 근본적인 해결책을 찾지 못해 Stack Overflow등을 검색하여 간략한 how-to만으로 임기응변하는 경우를 자주 목격한다. (네이버에서 CORS 키워드로 검색해 보면 형편없는(?) 한글 검색 결과들만 보이는 것도 이유중에 하나일까? IT 강국의 1등 검색포털엔진의 개발관련 검색 결과는 참으로 놀랍다!)

우선, CORS에 대한 개념부터 제대로 알고 접근하자.

CORS란?

Cross Origin Resource Sharing의 약자로 사실상 더 설명이 필요없지 않은가? ~~더 이상의 설명은 생략한다!!!~~

현재 웹페이지가 이 페이지를 제공한 서버(Origin)가 아닌 다른 서버(Cross Origin)에게 자원(이미지, 파일, 스크립트 등등)을 요청/호출하는 것을 의미한다. 가장 쉬운 예로 CDN에 배포되어 있는 이미지등을 단순 link를 통해 <img>태그로 로딩하는 것도 CORS라고 할 수 있다.

가장 흔한 악용 사례를 생각해보자면, 현재 페이지에서 다른 서버의 자원 중 단순 이미지 또는 파일이 아닌 악성 스크립트를 로딩한다라는 상황을 상상해보면 CORS가 왜 살짝 까다로울 수 밖에 없는지 금방 이해될 것이다.

일반적인 경우는 브라우저의 기본 기능을 통해 이미지(또는 파일)를 직접 다운로드를 하거나 DOM을 이용해 (<img> 테그나 CSS) 이미지를 표시하기 때문에 문제 되는 경우가 거의 없다. 하지만 XHR을 통해 데이터를 받아서 처리해야하는 특수한 경우(예: Smartlink의 Uplaoder 컴포넌트의 Cropper)에는 웹앱이 제공되는 도메인과 CloudFront 서비스의 도메인이 다르기 때문에 CORS 관련 문제가 발생한다. 물론 AWS S3에서 CORS 관련 설정을 제공하나, 브라우저와 CloudFront의 캐쉬기능과 엮이면서 재대로 동작하지 않는 경우가 빈번하다.

AWS에서의 CORS 세팅 방법

1. S3 > Permissions > CORS configuration

S3에 접속하여 CORS를 설정하고자 하는 Bucket의 Permissions (탭) > CORS configuration을 선택한다. 아래 그림에서와 같이 <AllowedHeader> 태그를 추가한다. 특정 Oring에 대해서만 허용하는 경우 해당 도메인을 입력하고 모든 Origin의 요청에 대해 CORS를 허용할 경우 "*" 를 입력한다.

2. CloudFront > Origin Access Identity

CloudFront의 접속하여 Origin Access Identity를 하나 생성 후 Amazon S3 Canonical User ID를 복사해 둔다.

3. S3 > Permissions > Bucket Policy

다음으로는 Bucket Policy를 선택하고 아래 내용을 입력한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Grant a CloudFront Origin Identity access to support private content",
            "Effect": "Allow",
            "Principal": {
                "CanonicalUser": "b4a159fd...b9a236f1841c3470a188ed80b53d77edd3ce69f"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::home.image/*"
        }
    ]
}

중요 부분은 조금 전 복사한 CloudFront의 Origin Access Identity 값을 CanonicalUser 키의 value로 세팅해야 하고, Resource키의 value 부분은 상기에서 CORS를 설정한 버킷이름으로 세팅해야 한다. 저장하고 난 뒤 다음과 같은 결과를 확인할 수 있어야 한다.

4. CloudFront > Origin Setting

CloudFront의 Origin Setting으로 이동하여 Origin Access Identify를 'Use an Existing Identity'로 선택 후 이미 생성해 두었던 Origin Access Identity를 선택하여 설정한다.

5. CloudFront > Behavior

이번엔 CloudFront의 Behavior 탭을 선택한 후 CORS 설정을 한 S3 Origin을 선택한 후 Edit 버튼을 눌러 CloudFront의 Caching 처리 방식을 변경해야 한다.

Cache Based on Selected Request Headers를 "None"에서 "Whitelist"로 변경하고 아래와 같이 3개의 헤더를 추가한다.

6. Testing

curl CLI를 통해 해당 버킷 내에 캐싱된 파일의 URL을 테스트하여 header 응답이 아래와 같이 200 값을 반환하면 세팅이 제대로 완료된 것이다.

[스마트링크 채용공고] 너, 내 동료가 돼라!

yoonjinho — Tue, 3 Jul 2018 17:41:24 +0900

2019년 5월 1일 부로 스마트링크 시즌1 채용공고는 마무리되었습니다.

시즌2 채용공고를 확인해주세요!!!

https://smartlinkio.tistory.com/78

지난 시즌1 채용공고를 보고싶으시다면!

안녕하세요. 저는 스마트링크에서 일하고있는 Mike 라고 합니다. 기획과 마케팅을 맡고있죠. 영문 이름이라 낯설 수 있는데 저 토종 한국사람 맞구요 :) 다만 스마트링크에서는 서로를 이렇게 영문 이름으로 부른답니다. 그래서 서로 한국이름을 잘 모르는 상황이 벌어지기도 하는데;;; 네, 저는 이렇게 이름세탁(?)이 용이한 공간에서 일을 하고 있어서 행복합니다(?!!). 뭐 여튼 사족이 길어졌지만 사실 중요한건 이 글은 채용을 목적으로 한다는 것이죠! 네, 그렇습니다. 동료를 구하고 있습니다. 너, 내 동료가 돼라!

식상하지만 이만한 짤이 없음. ㅇㅇ

뭐 하는 회산데?

스마트링크는 소프트웨어 개발사 입니다. 끝. 참 쉽죠?

하지만 세상은 넓고 소프트웨어 개발사는 넘치고 넘칩니다. 그런데 뭐가 그렇게 다른가? 라고 물으신다면! MVP(Minimum Viable Product) 소프트웨어 개발 컨설팅 전문 업체라고 말씀드릴 수 있겠습니다. 이게 뭔말이냐 하면 덩치 큰 SI도 종종 하지만 주로 스타트업 또는 초기 사업 아이디어가 빠르게 시장에 진입할 수 있도록 기획, 디자인, 개발, 테스팅, 데브옵스까지 (물론 견적에 따라 달라집니다! 단호! ㅋㅋ) 풀 패키지로 작업하는걸 좋아하는 업체라고 보시면 되겠네요. 그래서 프로젝트 기간이 짧고 굵은게 많죠. 늘어지는 프로젝트 별로 안좋아 합니다. AtoZ로 빠르게, 효율적으로, 효과적으로! 일하는걸 선호하고 실제로 그렇게 일을 진행합니다. 그런데 아마 이런 의문이 드실거에요. 왜 작은일 맡는걸 좋아하지? 사실, 규모가 중요한게 아니라 AtoZ 라는게 중요합니다. (심지어 예산 높은 큰 프로젝트 요청을 까기도 합니다. 꽤 자주;;) 그 이유는? 면접때 질문 주시면 신나게 답해드리도록 하죠 ㅎㅎ 다 이유가 있습니다!

누가 일하고 있는데?

AtoZ, 풀패키지로 일하는걸 좋아한다는 대목에서 아시겠지만 있을 사람은 다 있습니다. 기획, 디자인, 개발 인력 모두 있구요. 그래야 일이 되겠죠? 그렇다고 사람수가 많지는 않아요. 소수정예! 개발사니까 개발자가 절대적으로 많은건 당연하구요. 동료로서는 최우선이 개발자고, 개발자가 최고시다 라는 다른 파트(예를 들어 기획/마케팅 파트의 저 같은 사람? ㅋㅋ)가 있는만큼 개발자를 중요하게 생각하고 우대하는 회사 입니다. 개발자를 좋아하고 지지하는 든든한 기획자가 있다는걸 저는 어필하고 싶네요!

개발자의 코드를 보며 동경하는 기획자의 모습

하지만 개발자들은 언제나 다른 기술스택이나 코드를 바라보고있지…(응?!)

여기서 일일이 언급하기는 뭐하지만 일 잘하는 사람들이 모여있다고 자부하고 있고, 앞으로 동료들도 일 잘하는 사람을 가장 원하고 바라고 있습니다. 일을 잘한다는 기준이 절대적일 수는 없겠지만, 예를 들면 이런거죠. 최대한 정확하고, 낭비나 누수없이, 빠르게 문제를 해결하기 위해 계속 꼼수를 쓰는 사람들! 이랄까요? 세상에 (노는것 포함) 할일이 얼마나 많은데! 극단적 효율을 추구하는 집단이라고 보시면 되겠습니다. 하지만 어설프게 일하는건 싫어합니다. 어설프게 일하면 꼭 후폭풍이 오더라… (후폭풍 시져시져) 여튼 그런 사람들이 함께 일하고 있다고 보시면 되겠습니다. 사람 구경하러 오시는 면접도 환영합니다!

그래서 누굴 뽑는거야?

개발자 0명 찾습니다! 0명은 무엇이냐? 좋은 사람이 있으면 있는만큼 욕심을 낼것이다! 이런 욕구와 목마름이 있다는 것이죠! 많이 지원해 주세요! 공통적으로 체크해보실 수 있는 정보를 우선 드릴까요?

목마름이 있으면 해소하면서 일해야죠. ㅇㅇ

현재 사용중인 기술 스택 및 도구

기획: Adobe XD
디자인: Adobe XD 포함 Adobe 모든 제품군, Zeplin, Sketch
Front-end: Semantic UI, React, React Native
Back-end: Meteor
Testing: Mocha, Jest
DevOps: Jenkins, Docker, Phusion Passenger, Nginx, AWS
Database: MongoDB

근무환경

최상의 사무 환경 및 공간 제공 (넓고 쾌적한 책상! 빵빵하고 쾌적한 냉난방시설! 막 엎어져서 작업하는 소파! 등)
식대 지원 (중식/석식)
4대 보험
주5일 근무
Refresh 휴가
자율 출근 시간 (탄력 근무제)
경조사비 지원
근무지: 서울시 강남구 신사동 520-5 삼오빌딩 3층 (얼마 전 가로수길로 이사왔어요!)

워크샵이라 하면 적어도

뷔페와 함께하는 야간 요트 유람 정도는 해줘야하는거 아닙니까? (사실 명목은 지스타…)

알겠고, 개발자 채용요건을 내놓아라!

네, 드...드리겠습니다. 아래를 봐주세요. 이제 개알못 기획자는 아웃! 참, 한가지만 말씀드리자면 풀스택이 아니어도 들어오면 풀스택이 될 수 있도록 교육 및 세미나(라 쓰고 굴린다라 읽는다. 그리고 궁극적인 공부는 결국 본인이...ㅋㅋ)가 충실하게 진행된다는건 말씀드리고 싶군요. 우흐흐…

React 코드를 보고 이렇게 반응하는 사람이라면

우리는 이렇게 됩니다 ㅎㅎ

기술 스택

모집분야 / 담당업무

Javascript/Nodejs/Meteor 기반의 풀스택 웹/모바일 애플리케이션 개발자
React + Meteor + MongoDB 기술 기반의 Full-stack Web Application 개발
React Native + Meteor + MongoDB 기술 기반의 Full-stack Mobile Native Application 개발

자격요건

개발에 미친 사람!!!
자유로운 소통과 공유의 가치를 잘 이해하고, 자기주도적인 환경에서 최대의 능력을 발휘하며, 긍정에너지 발산이 가능한 분
논리적이고 체계적인 문제해결 능력 및 오픈 마인드 커뮤니케이션 능력
전산 관련학과 학사 이상 또는 동일한 자격 (경력 무관)

우대조건

React, React Native 등의 JavaScript SPA(Single Page Application) 프레임워크 경험
Nodejs + MongoDB 기반 Micro Service Architecture 서비스 개발 경험
영어 커뮤니케이션 능력 (특히, 영문서 이해 능력: 해외 최신 기술을 주로 이용하다보니 한글 자료가 없는 경우가 많습니다.)
AWS 등 클라우드 서비스 운영 경험
Git 포트폴리오: 직접 작성한 패키지, 오픈소스 기여 경험
Docker 컨테이너 기반 서비스 구축 및 운영 경험
CI 시스템 구축 및 운영 경험.
Mocha, Jest 등의 테스팅 프레임워크 또는 TDD(Test Driven Development) 경험

하악하악! 그래서 어떻게 지원하면 되는거임?

사실 여기서 다 말하지 못한 이야기들이 스마트링크에 많습니다. 앞으로 재미있는 일들이 무궁무진하게 펼쳐질 거에요. 만나서 이야기해요! 관심있는 분이라면 꼭 지원해 주세요! 이메일로 자유롭게 지원해 주시면 됩니다! 만 아래 내용이 있으면 이야기 나누기가 훨씬 수월하겠죠? :)

이메일 보낼때 함께 보내주시면 감사하겠습니다!

이력서 (희망연봉포함)
포트폴리오
개발자라면 개발 경력 자료 (github 주소 환영합니다!)

이메일을 보내주시면 인터뷰 일정을 위해 개별적으로 성심성의껏 연락드리도록 하겠습니다. 면접까지 함께하게 된다면 편안한 마음으로 사람과 사람이 대화한다는 진솔한 마음가짐만 가지고 오시면 됩니다 :)

목빠지게 기다리고 있을게요오~

참, 이메일 주소는 여기!

support@smartlink.io

[Xcode] Production 환경에서의 Debugging 팁

grooveslap — Sun, 28 Jan 2018 21:07:38 +0900

React Native나 Cordova 등의 하이브리드 기반의 모바일앱을 개발하는 경우, 네이티브 개발에 비해 여러가지 많은 이점들을 누리는 것이 사실이다. 반면, 개발이 완료되고 배포단계에 이르러서는 그동안 편하게 개발했던 하이브리드 환경이 아닌 각 모바일 플랫폼의 네이티브 개발 환경인 Android Studio나 Xcode등을 통해 배포를 진행해야만 하는데, 특히 배포 전후의 디버깅 환경에 대해서는 필수적으로 익숙해져야만 한다. 사실상 제대로된 하이브리드 모바일 앱 개발이 쉽지만은 않은 이유 중 하나이며, 네이티브 개발의 기본 메커니즘과 환경에 대한 지식이 있어야 비로소 제대로된 하이브리드 개발이 가능하다고 할 수 있다.

여기서는, iOS 모바일 앱 개발에서 필수인 Xcode의 배포 단계에서 유용한 두 가지 디버깅 관련 기능에 대해 소개하고자 한다.

1. Scheme 설정

Xcode의 디버깅 환경에서는 오류 없이 실행이 잘 되다가 앱스토어나 Test Flight에 업로드 한 경우 예상치 못한 런타임 오류나 ANR(App Not Responding)이 발생하는 경우가 있다. 이럴 때 Xcode에서 Scheme 설정을 통해 디버깅 환경에서도 배포(Release) 환경과 동일하게 앱을 실행할 수 있는 방법이 있어 소개하려고 한다.

Xcode에서는 기본적으로 아래와 같이 5개의 Scheme을 가지고 있다.

일반적으로 많이 사용하는 Run의 경우 Xcode에서 실행 버튼을 클릭하여 시뮬레이터나 아이폰에서 애플리케이션을 실행할때 사용되는 Scheme이고, Archive는 앱스토어에 배포할때 사용되는 Scheme이다. 위 스크린샷을 통해, 개발 도중 흔히 사용하는 Run Scheme의 경우 Debug, 앱스토어 배포시 사용하는 Archive의 경우 Release로 기본값이 선택되어 있음을 알 수 있다.

아래와 같은 설정 변경을 통해 Run Scheme을 Debug에서 Release로 변경할 수 있다. 먼저 Xcode 메뉴에서 Product > Scheme > Edit Scheme 을 선택한다.

앞서 설명한 5개의 Scheme중 Run을 선택하고 Build Configuration의 값을 아래와 같이 Debug에서 Release로 변경한다.

이제 Xcode의 실행 버튼을 누르게되면, Debug 모드로 빌드가 되는 것이 아니라, Archive에 사용하는 Release 모드로 빌드가 된다.

자, 이렇해서 간단하게 Scheme 설정을 변경하는 방법에 대해 알아 보았다. 개발 환경에서는 문제 없었으나 Production 환경에서 문제가 생길 때 개발 환경을 Production 환경과 동일하게 설정하는 방법이 필요한 경우 유용하게 사용하길 바란다.

2. Crash Report

다음으로 소개할 기능은 앱 스토어나 Test Flight에 배포 이후 사용자의 실제 단말기에서 발생하는 앱의 Crash 리포트를 확인하는 방법에 대해 살펴보자. Xcode의 > Window > Organizer를 선택하여 Organizer창이 실행되도록 하자.

Organizer 화면에서 상단의 Crashes를 선택하면 배포 이후 발생한 Crash 리포트에 대해 조회가 가능하다. 현재 예제 앱의 경우 최신 빌드(18012803)에서는 Crash가 리포트되지 않았음을 알 수 있다.

아래 화면과 같이 빌드 버전을 영역을 클릭해보면 이제까지 Archive된 빌드 목록을 볼 수 있다. 예제 앱의 경우 1.2.9 버전에서 Crash가 발생하였었으므로, Crash 리포트에서 Build 18012802를 선택하여 상세 내용을 보도록 하자.

실제로 Crash가 생긴 경우, 아래와 같이 Crash의 종류와 간단한 통계 정보를 볼 수 있다. 화면의 왼쪽은 Crash의 종류를 볼 수 있고 화면의 오른쪽 영역은 Crash의 발생 빈도, 리포드된 단말기의 OS버전, 발생 일자, 앱의 빌드 버전 정보 등을 확인할 수 있다.

스마트링크의 스마트한 프로젝트 진행 방식

grooveslap — Sun, 21 Jan 2018 20:50:32 +0900

스마트링크에서 다양한 분야의 클라이언트로부터 다양한 주제의 웹/모바일앱 서비스를 의뢰받아 기획, 디자인, 개발을 진행하면서 가급적 더 효율적으로, 같은 기간 같은 비용 내에서 더 좋은 결과를 만들기 위해 나름 많은 고민과 시행착오를 경험 했었던 것 같다.

이런 고민과 시행착오는 대부분 스마트링크 내부 기술 스택의 효율성 재고 뿐만 아니라 기획, 디자인, 검수 단계를 포함하는 전반적인 프로세스 개선 그리고 대내외 커뮤니케이션 노하우로 귀결 되었고, 이런 노력의 결과들로 인해 프로젝트 완료 후 많은 고객들로 부터 좋은 평가를 받을 수 있었다.

[출처: 위시켓]

프로젝트를 진행함에 있어 가장 조심스럽고도 중요하다고 판단되는 부분은 역시나 커뮤니케이션! 특히, 스마트링크가 그동안 많은 프로젝트를 진행하면서 쌓아온 노하우를 가지고 처음으로 웹/모바일 프로젝트를 시작하는 초보 고객들(스타트업 또는 초기 창업자)과 프로젝트를 진행해야 할 때 가장 고민스럽고 가장 조심스럽다. ~~사실 답답해 미치겄다!~~

웹이나 모바일 앱 개발 프로젝트의 라이프사이클을 이해하거나 기획, 디자인, 개발, 검수 단계에 대한 경험이 있는 고객과 프로젝트를 진행하는 경우 오히려 스마트링크의 비교우위를 인정 받기가 쉽고 (타업체에서 프로젝트를 진행하다 호되게 당하고 오신 분들은 특히 더!) 실제 그런 사례들이 많았다. 문제는 이제 막 부푼 꿈을 안고 사업을 시작하는 스타트업의 대표나 아직 법인 설립도 하지 않은 대한민국의 수 많은 초기 창업자들이 스마트링크의 주요 고객층이라는 것!

물론, 여기에는 Non-IT 분야에서 사업적 성공을 거두고 이제 막 IT 분야로 뛰어든 연쇄 창업자도 포함된다. 특히 이 부류의 고객들이 가장 커뮤니케이션이 힘들긴하다.

앞으로 스마트링크의 비전이 바뀌지 않는 한 스마트링크의 주요 고객 층은 쉽게 바뀔리 만무하고, 이런 스마트링크와 스마트링크의 미래 고객과의 간극을 조금이나마 좁히기위해 스마트링크의 프로젝트 진행 방식과 왜 그런 방식이 도입 되었는지에 대해 이글을 통해 가급적 쉽게 그리고 충분히 설명 하고자 한다. 물론 프로젝트 특성이나 환경에 따라 진행 방식이 조금씩 달라지는 경우가 있으나 큰틀에서는 대동소이 하다고 할 수 있다.

린 스타트업과 MVP

프로젝트 진행 방식에 대한 이야기에 앞서, 린 스타트업, 린 방법론에 대해서 먼저 이야기를 하고자 한다. 창업자가 되기 위한, 최소한 IT 기술기반의 새로운 서비스를 시장에 내놓고 사용자의 유입으로 무언가를 해보려고 하는 대부분의 서비스 창업자라면 무엇보다 꼭 필수적으로 알아야 하는 개념이다.

그렇다고 아래 Lean 관련 서적 2권을 빠른 시일내에 꼭 정독 하라고 말하는 것은...음...맞다!

사업하시는 분들이라면 공감하시겠지만 종종 답답한 마음에 용하다는 무당을 찾아가 사업의 미래를 점치고 싶은 욕구가 굴뚝 같은때가 있다. 그럴때 그 복채를 아껴 이 책 두권을 꼭 사길 추천 드린다. 사업의 실패 확률을 줄이고 성공 확률을 높일 수 있는 비법이 소개되어 있으니, 책 2권 정도를 구입해서 정독하는 수고 정도는 아끼지 말아야 할 것이다.

실리콘밸리에서 용하다고 소문난 스타트업 토종비결이니 꼭 보셔야할 비서이다. 스타트업 모임이나 meet-up에서 피봇(Pivot)이나 MVP같은 Lean관련 용어들을 입에 담는 분들은 많이 보았으나 막상 프로젝트에서 필요한 기본 Lean 소양을 제대로 갖춘 창업자 분들을 보기 힘든 것이 안타까운 현실이다.

왜 갑지기 린스타트업이냐? 사실 MVP에 대한 이야기를 하고 싶어서이다. 여기서 말하는 MVP는 흔히 스포츠 경기에서 선정하는 MVP(Most Valuable Player)가 아니라 스타트업이 어떤 제품이나 서비스를 시장에 런칭함에 있어 반드시 측정/판단해야만 하는 핵심가정(Hypothesys)을 시험해 볼 수 있는 최소존속제품(Minimum Viable Product - 최소기능제품으로도 번역되는 경우가 있다.)을 의미한다.

초기 창업자분들이 생각보다 흔하게 저지르는 실수가 몇가지 있는데, MVP에 대한 개념 부족에 기인하는 경우가 많다. 스마트링크에서 프로젝트를 진행하면서 경험한 초기 창업자들의 흔하지만 치명적인 실수 몇가지를 먼저 소개한다.

흔하지만 치명적인 실수 1 - 다재다능

어차피 외주 개발이니 나중에 혹시 쓸지도 모르는 기능들을 우겨 넣는다! 이러 접근 방법으로는 시장에서 승부를 걸수 있는 제품이나 서비스가 나오기 힘들다. 현재 유명한 메이저 플레이어들의 초창기 서비스 모습을 생각해 보면 금방 이해가 될 것이다. 예를들어, 카카오톡의 경우 처음엔 단순한 인스턴트 메세징 앱이었다. 전혀 버티컬 플랫폼을 꿈꾸지도 않았을 뿐더러, 지금 줄줄이 붙어 있는 카카오스토리, 카카오드라이버, 카카오택시, 등등 많은 후속 기능이나 제품들이 처음엔 당연히 존재하지 않았다. 그저 기존 유료 서비스인 SMS를 대체하고자 하는 인스턴트 메세징 앱이었을 뿐이다.

카카오톡의 초기 핵심가정은 아마도 "무료이며, 연락처의 친구를 자동으로 인식할 수 있는 메세징 앱이 있다면, 사용자들은 기존 SMS 문자 메세지 기능을 사용하지 않고 그 무료 앱을 사용할 것이다." 였을 것이다. 그리고 카카오톡은 이 하나의 단순한 핵심가정을 시장에서 시험하고 증명하기 위해 엄청난 노력을 했다.

그렇다. 실제로는 하나의 핵심 기능을 엣지있게 잘 기획하고 개발해서 사용자에게 전달하는 것도 굉장히 어려우며, 사실상 제대로된 마케팅적 접근 없이는 사용자에게 도달하는것 자체도 모든 리소스가 제한된 스타트업으로서는 매우 힘들다. 시장에 이제 진입하는 듣보잡 서비스나 제품은 무조건적으로! 절대적으로! 많은 기능을 가지고 있어서는 안된다. "이런 저런 기능들이 많으니 사용자가 적어도 하나 정도는 써주겠지?"라고 생각하는 순간 그냥 망한 서비스나 마찬가지이다. Fat 하면 안된다! Lean 해야한다!

흔하지만 치명적인 실수 2 - 장인정신

앞서 소개된 "Running Lean" 서적의 부제를 보자. Lean 개념을 한마디로 잘 설명한 문장이다.

Iterate from Plan A to a Plan That Works

초기 제품이나 서비스 아이디어를 Plan A라고 보았을때, 스타트업 대표로서 꼭 주지해야 하는 사실은 시장에서 검증이나 피드백을 받지 않은 창업자의 머리속에서 이제 막 쏟아져 나온 아이디어(Plan A)를 계속해서 개인적인 상상력과 추측 그리고 장인정신으로 깍고 또 깍아서 예술작품으로 승화 시키려고 하지 말고, Plan A, 즉, MVP가 완벽하지 않더라도 빨리 시장에 출시하여 실제 고객이나 사용자들로 부터 피드백을 받아 개선된 Plan B 또는 Plan C, 또는 Plan Z가 되는 한이 있더라도 시장에서 먹히는 Plan(a plan thant works)을 최대한 빨리 찾는것이 Lean 방법론의 핵심이라는 것.

대부분의 클라이언트는 프로젝트 계약전 일정이 급박하며 제일 중요하다고 설레발을 치다가, 막상 스마트링크에서 일정에 맞춰 결과물을 내놓으면, 갑자기 일정은 뒷전으로 미뤄지고, 디자인 검수 단계에서 그렇게 좋고 이쁘다고 칭찬했던 모든 컬러와 선, 버튼, 아이콘, 텍스트 크기 등등을 가다듬으며 며칠 아니 몇주를 소비하는 경우가 허다하다. 스마트링크에서 진짜 일정을 맞춰 드려서 많이 놀라신건지? 물론, 제품이나 서비스의 외형과 심미적인 부분도 중요하다. 그러나 이러한 클라이언트들의 수정 요청 사항 중 대부분은 서비스의 핵심과 무관하며, 굉장히 사소한 부분들이다. 실제 사용자는 폰트의 사이즈가 자신이 좋아하는 10px이 아니라 12px이라서 앱을 지우거나 또는 그반대로 하지 않는다.

중요한 것은, 시장에서 이미 성공한 비즈니스 모델을 카피캣(copycat)한 서비스가 아닌 경우라면, 내가 제품이나 서비스를 통해 해결하고자 하는 문제(핵심가정)와 솔루션(MVP)이 시장에서 먹히는지와 시장 자체가 실제로 존재하는지를 검증하는 것이 더 중요하다. 자신만의 완벽한 Plan A가 아니라 시장에서 먹히는 Plan X를 찾는 것이다. 그것도 최대한 빨리...

흔하지만 치명적인 실수 3 - 변덕

Lean 방법론에서 시장의 피드백에 따라 제품이나 서비스를 변경(Pivot) 할지 또는 지속(Persevere) 할지를 결정하게 되는데, 이때 중요한 것은 결정과 판단의 근거이다. 반드시 시장의 피드백 즉, 사용자들의 제품 사용 행태 등을 Google Analytics와 같은 분석 도구로 측정하고 측정된 데이터를 지표화해서 이를 근거로 판단해야 한다. 대표의 사업적 변심이나 주위 사람들의 의견에 의해서 판단해서는 안된다. 많은 대표님들이 이제 막 태어난 새 생명이 세상에 나가 첫걸음을 떼기도 전에, 성형 수술을 준비하는 경우가 많다. 대부분 이런 경우는 MVP 선정이 제대로 되지 않아서이다.

시장에서 검증하고 싶은 내 제품, 내 서비스의 핵심 가정이 명확 하다면, 이런 가정을 빨리 검증하고 싶은 마음에 시장에 어떻게든 빨리 출시를 하고 싶은게 정상이겠으나, MVP 선정이 제대로 되지 않아 제품의 핵심 가정과 그것을 시장에서 효과적으로 시험, 측정 해볼 장치가 제품에 제대로 녹아 있지 않은 경우 출시 시점이 되어서야 냉혹한 시장의 피드백에 대한 막연한 공포와 자기 검열 또는 "아~ 이 기능을 넣었어야 했는데"라는 근거 없는 후회로 인해 차일피일 출시를 미루는 경우가 생각 보다 많다.

충격적인 사실은, 초기 창업자 프로젝트의 경우 제품 개발 완료 이후 평균적으로 10개중 반 이상의 프로젝트가 자체적으로 완벽하지 않다는 미명하에 시장 출시를 포기하거나 무기한 연기한다 라는 것이다.

흔하지만 치명적인 실수를 피하는 방법

상기에 소개된 Eric Ries의 Lean Startup은 저자 본인의 연쇄 창업 경험과 실리콘밸리 초기 스타트업의 많은 사례 연구(Case Study)를 통해 Lean에 대한 개념과 필요성을 설파하고 있다. 창업자라면 누구나 이 책을 읽으며 무릎을 몇번 칠 정도로 공감하지 않을 수 없는 내용들로 가득하다.

Ash Maurya의 Running Lean에서는 구체적으로 MVP를 어떻게 도출하는지에 대한 상세한 실전 방법들이 소개가 되어 있다. 제품이나 서비스에서 풀고자 하는 문제(Problem)와 그에 대한 제품(Solution)을 인터뷰를 통해 찾아가는 방법, 일반적으로 초기 창업 시 엄청난 공을 들여 작성하게 되는 수십에서 수백 페이지의, 아무도 보지 않을 사업계획서가 아니라 단 한 장의 Lean Canvas(Business Canvas가 Lean 방식으로 변형된 형태)를 그리고 이를 기반으로 MVP를 도출하는 상세한 과정에 대해 소개되어 있다.

개인적으로는 꼭 두권을 꼭 다 읽어야 하는 이유이다. 아무리 개념적으로 좋은 방법론이라 할지라도 구체적으로 나의 주어진 상황에서 어떻게 실행 할지에 대한 감이 없다면 탁상공론에 불과하기 때문이다.

사업의 주체인 자신이 직접 도출한 MVP가 있어야만 사실, 스마트링크든, 다른 업체든, 외주 개발에 관한 이야기를 시작할 수 있고 본격적인 기획과 그 이후의 소프트웨어 개발 과정에 대한 이야기가 성립될 수 있다. 아무리 잘난 스마트링크일지라도 사업을 대신해줄 수는 없지 않은가? 가끔씩 사업에 도움이 되시라는 취지에서 린스타트업에 대한 소개를 드리면, 스마트링크와 같이 MVP를 찾아가고 싶어하는 고객분들이 종종 있다. 한마디로 불가능하다!

참고로, MVP의 구현이 꼭 소프트웨어 개발을 통해서만 가능한 것이 아니다. Eric Ries의 Lean Startup에 소개된 수많은 사례들: Groupon, Zappos, Open Table 등 무수히 많은 성공 케이스에서 볼 수 있듯 번듯한 홈페이지 하나 없이도 충분히 사업적 아이디어에 대한 검증과 실행은 가능하다. 하나의 좋은 예로, Zappos는 온라인 신발 전문 쇼핑몰을 실제로 개발하기에 앞서, 초기 사업모델의 핵심가정("사람들은 온라인으로 신발을 살 것이다")을 검증하기 위해 단순 웹사이트만을 오픈한 후 타 오프라인 신발매장에서 촬영한 신발 사진을 올리고 실제 구매 요청이 들어오면 그 매장에서 신발을 구매하여 택배로 발송하였다. 국내에서는 카닥이 좋은 예이다.

협업도구들

프로젝트 킥오프 미팅 이후부터 고객의 머리 속에서 흘러 넘치는 아이디어를 하나의 웹 서비스나 모바일 앱으로 탄생시키기 위해서는 기획, 디자인, 개발, 검수 단계에서 만만치 않은 에너지와 상호 작용(커뮤니케이션)이 요구된다. 물론 필요에 따라서는 유선 전화, 이메일, 대면 미팅 들도 당연히 동반되나, 어떤 프로젝트도 피해갈 수 없는 꼭 공유되어야 되는 정보들과 프로젝트 진행중 발견되는 이슈들 그리고 스마트링크에서 기본적으로 채택하고 있는 애자일 스크럼(Scrum) 방식의 프로젝트 진행 현황을 제대로 파악 하기 위해서는 아래의 협업 도구들이 필수이다.

가끔 이메일로이나 카톡(특히, 단톡) 사용을 선호하는 고객들이 있어, 이에 맞춰 프로젝트를 진행한 경우가 몇차례 있었으나 결국 소프트웨어 개발 프로젝트라는 것이 하루이틀 진행되는 것도 아닐 뿐더러, 고객 스스로도 정리되고 추적되어야 하는 현안이나 이슈들이 제대로 정리되지 않아 오히려 불편을 호소하며 끝내 항복(?)하는 사필귀정을 많이 목격하게 된다.

협업도구 1 - 트렐로 (Trello)

What is Trello?

Trello is a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what's being worked on, who's working on what, and where something is in a process.

모든 강이 바다로 흘러 모이듯 스마트링크에서는 프로젝트 관련 모든 공유 정보나 대고객 커뮤니케이션을 트렐로를 통해 관리하고 있다. 심지어는 이메일 사용도 자연스럽게 구시대적인 커뮤니케이션 유물로 취급받고 있어 내외부 커뮤니케이션에서 이메일 의존도가 매우 낮다. 사실, 매우 낮은 정도가 아니라 개발, 디자인 팀은 업무중에 거의 이메일을 사용하지 않는다.

스마트링크와 프로젝트를 진행하든 하지않든 IT 기반의 프로젝트를 진행하기 위해서는 꼭 사용해보시기를 적극 추천한다. 사실 트렐로 정도는 이미 알고 계시는 분들도 많다. 스마트링크에서는 아래와 같이 크게 6개의 리스트를 통해 프로젝트를 관리한다. 수십개의 프로젝트를 거치면서 나름 최적화된 것이니 프로젝트 진행 시 우선은 따라주시면 감사하겠다. 이 링크를 통해 무료 회원가입 및 사용이 가능하다.

1. Information

프로젝트 시 필수적인 아래 정보들이 주로 공유된다.

클라이언트의 초기 기획/정책 문서
서비스의 브랜드 정책 및 아이덴티티
클라이언트 및 스마트링크 참여 팀의 연락처
도메인 설정
레퍼런스 또는 벤치마크
Apple/Android 앱스토어 배포용 계정
Amazon Web Service 계정
SMS, Email 등 프로젝트별 연동 외부 서비스 계정

2. Client Communication

클라이언트와의 대면 미팅 관련 미팅 노트 및 유선 통화 내용을 주로 정리한다.

3. Issues

프로젝트 진행 중 발견되는 이슈들을 공유한다.

4. Backlog

프로젝트 개발을 위해 스마트링크에서 진행해야 할 업무 목록. 기획, 디자인, 개발, 검수 업무들이 프로젝트 초기에 모두 나열된다.

5. In Progress

진행 중인 작업들 목록.

6. Done

완료된 작업들 목록.

협업도구 2 - 지라 애자일 (Jira Agile)

Jira는 원래 프로젝트 이슈 트래킹 툴로 시작하였으나, 최근 애자일 스크럼 방식의 프로젝트 관리 기능이 지원 되고 있다. 스마트링크에서는 애자일 스크럼 방법론을 채택하여 모든 프로젝트를 진행하고 있기 때문에 Jira Agile을 적극 활용 중이다. 고객 내부에 기술 관련 책임 인력이 있는 경우 공유해서 프로젝트를 진행하기도 하나, 주로 비기술 기반 스타트업 고객의 경우 앞서 설명된 트렐로만으로도 충분하다.

협업도구 3 - 깃허브 (Github)

소프트웨어 개발 과정에서 개발자간 협업과 형상 관리에 필수적인 협업 도구이다. 최종 결과물이 산출될때까지 소스코드를 잘 보관하고 최종적으로 고객에게 잘 전달하기 위한 저장소(Repository)라고 보시면 된다. 또한 고객과 스마트링크의 지적재산권에 해당하는 소스코드를 비공개(Private) 저장소에 보관함을 원칙으로 하고 소스코드에 대한 리뷰나 접근이 필요한 경우에 한해 해당 고객을 초대하기도 한다.

협업도구 4 - 구글 드라이브 (Google Drive)

사실 구글 드라이드만 단독으로 협업 도구로 사용하지 않는다. 주로 항목이 많은 기획/정책 문서 또는 검수단계에서 QA 시트등을 트렐로를 통해서 구글 드라이브의 링크를 공유하고 실제 내용은 구글 드라이브 문서를 참조하도록 진행한다.

다양한 이슈들이 탭으로 분리되어있으나 기본적으로 하나의 문서로 집중한다.

협업도구 5 - 재플린 (Zeplin)

디자인 단계에서 산출되는 결과물을 고객과 공유할 때 사용하며, 내부 개발팀이 프론트엔드 개발시 참고하도록 공유한다. 기존에 디자이너가 디자인 작업과는 별도로 만들어서 공유하던 디자인 가이드를 생략할 수 있고 여러가지 측면에서 꼭 필요한 디자인 협업 도구이다. 스마트링크에서는 프로젝트 진행시 디자인 시안부터 이미지 파일을 압축해서 공유하지 않고 재플린 링크를 공유한다. 이것 또한 트렐로를 통해서...

협업도구 6 - 오븐 (Oven)

기획단계에서 일반적으로 많이 사용하는 파워포인트식의 장표를 만들지 않고, 실제 최종 결과에 근접한 목업(mock-up) 형태의 프로토타입을 만들어 클라이언트와 내부 팀과 공유한다. 전통적인 장표 형식 기획서의 다음과 같은 문제를 개선하기 위함이다.

기획자가 만든 이차원 평면위에 펼쳐진 와이어프레임이 하나의 웹 서비스나 모바일 앱으로 살아움직이기 시작할때 기획서를 만든 기획자와 실제 사용자가 느끼는 경험은 매우 다를 수 있다. 비록 목업이 디자인이 배제된 와이어프임으로 구성되었다 할지라도 서비스의 전체적인 랜딩이나 흐름 등을 경험함으로서 전통적인 기획서 보다는 좀더 실체에 가까운 UX를 미리 경험할 수 있다.

기획서 작성 후 내부 팀회의나 클라이언트 리뷰에서 수정이나 개선 사항이 생겼을때 그리고 이런 수정 사항이 서비스의 전체 구조(Information Architecture)에 큰 영향을 주는 경우 전통적인 기획서 작업 방식의 경우 연관된 페이지들을 일일이 찾아다니며 수정을 해야하고 이런 수정이 몇번 반복되다 보면, 서로 참조하고 있거나 연관된 랜딩에서 누수가 생기기 마련이다. 기획 단계에서 발생하는 이런 오류들은 개발을 포함하는 기획 이후의 모든 단계에 치명적으로 작용한다. 농담 같겠지만, 가끔은 개발 마무리 단계에서 기획적인 누수가 발견되어 고생해서 개발한 소스코드를 갈아엎는 경우도 종종 발생한다.

프로젝트 1단계 - 기획

스마트링크에서 책임지는 기획이란?

위에서 설명하였듯, 기획 단계로 들어가기에 앞서 명확한 MVP가 존재해야 한다. 린 방식을 따르던, 개인적인 영감으로 MVP를 선정하건 MVP는 필수이다. 클라이언트 측에서 도출한 MVP를 사업적 기획의 결과물이라고 본다면, 스마트링크에서 진행하는 기획은 그 사업적 기획의 결과를 토대로 UX를 포함한 구체적인 서비스 또는 제품 기획을 진행한다.

클라이언트 측에서 구체적인 서비스/제품 기획서까지 만들어서 프로젝트 의뢰를 하시는 경우도 있으나, 스마트링크에서는 이런 경우라 할지라도 기존 기획서를 처음부터 검증하거나 아예 새로 만드는 경우가 대부분이다. 물론 잘 만들어진 기획서가 종종 있기도 하나 대부분은 기본적인 MVP로서의 모델링이 제대로 되어 있지 않거나, 실제 사용할 사용자의 경험(UX)에 대한 배려가 부족하거나 아예 없는 경우가 대부분이다.

아무리 사업 모델이나 시장성이 좋다할지라도 제품이나 서비스가 시장에서 인정받기 위해서는 그 제품이나 서비스를 최종적으로 사용할 사용자들의 경험(UX)이 결정적으로 중요하단 사실도 간과 해서는 안된다. 대부분의 사용자들은 (성별, 연령, 국가에 따라 다르긴 하나) 이미 다른 많은 서비스를 통해 익숙해져온 UX 경험을 가지고 있다.

아무리 독창적인 비즈니스 아이디어 일지라도 그것이 너무 독특한 또는 일반적이지 않은 UX 경험으로 사용자에게 전달이 된다면, 사용자 입장에서는 기존의 익숙함을 버리고 또 다른 학습과 인지적인 탐험을 강요 받게 되는 것이다. 대부분 이런 상황이 주어지면 사용자들은 학습과 탐험을 선택하기 보다는 회피를 선택한다. 즉, 해당 사이트를 다시 방문하지 않거나 모바일 앱을 삭제한다.

일반적으로 사용자는 (실제로 그렇지 않다하더라도) 무지하고, 게으르고, 냉정하다 라고 가정하는 것이 좋다. 내 가족이나 친구가 아닌 이상, 나의 복잡한 또는 일반적인 인식 경험을 벗어나는 제품/서비스를 끝까지 붙들고 이해하기 위해 연구해가며 사용하지 않는다.

프로젝트의 전체 진행 과정에서 가장 중요하고 클라이언트들과 가장 많은 커뮤니케이션이 필요하고, 스마트링크의 에너지를 가장 소모하는 단계가 바로 이런 기획 단계이며, 특히 이런 UX적 요소를 기획에 잘 반영하기 위해 클라이언트와 끊임없이 협의하고 타협해 가는 과정이 힘들지만 가장 중요하다.

기획 소요 기간

다른 업체에 소프트웨어 개발을 의뢰하였다가 몹쓸 경험을 하고 난 뒤 스마크링크를 찾아오시는 클라이언트 분들이 종종 계신다. 이런 클라이언트 분들에게는 죄송하나 실패한 프로젝트 경험이 스마트링크와의 프로젝트 진행에서는 많은 도움이 되는 경우가 있다. 특히 기간 산정 관련해서는 말이다.

스마트링크에서는 기본적으로 기획 기간을 한 달(4주)로 산정한다. 프로젝트 의뢰 당시 만들어진 기획서 있건 없건 말이다. 프로젝트를 진행하면서 최소 한달의 기획 기간이 보장되어야 전체 프로젝트가 어려움 없이 진행된다는 스마트링크 나름의 생활 통계적인 기간 산정이다.

어떤 클라이언트의 경우 "무슨 기획 하는데 한달이나 걸리나요?"라고 물어보시는 경우가 종종 있는데, 사실 질문을 거꾸로 하신 경우이다. "제 고민을 대신해서 한달 동안이나 해주시나요?"

실제로 프로젝트를 진행해보면, 그 길 다던 한달도, 스마트링크측에서 발견하거나 미비 하다고 판단되는 정책적인 결정을 요청하며 커뮤니케이션을 주고 받다보면, 오히려 클라이언트 측의 결정 장애나 딜레이로 인해 한달 이상이 걸리는 경우가 대부분이다.

최종 결과물

실무적으로 스마트링크의 기획 단계에서는 위의 협업도구에서 언급 하였던 오븐을 사용하여 빠른 프로토타이핑을 진행한다. 예외적인 경우가 아니라면, 전통적인 기획서를 지양하고 상호 효율을 추구하고 있다. 전통적인 기획서를 작성하는데 소모적으로 소요되는 시간을 클라이언트의 핵심 요구사항을 더 깊이 이해하고 UX 경험을 잘 기획하는데 사용하려는 의도이다.

프로젝트 2단계 - 디자인

백문이 불여일견

초기 디자인 미팅에서 클라이언트들에게 "어떤 디자인을 원하세요?"라고 물어보면 (사실 질문자체가 그런 답을 유도 하기도 하는것 같다.) 10명 중에 9명은 "심플하고 깔끔한 디자인이요!"이라고 답한다. 더 이상의 질문과 답변이 의미 없어지는 순간이다. 사실 디자인 단계에서 모든 클라이언트들이 원하는 그 심플하고 깔끔한 디자인을 만들기 위해 디자이너는 클라이언트와 많은 커뮤니케이션을 한다. 백마디 말보다 클라이언트가 원하는 디자인에 가장 가까운 디자인 레퍼런스를 찾는 것이 가장 효율적인 시작점이다.

디자인 리뷰의 중요성

디자인 미팅과 레퍼런스를 분석을 통해 도출된 디자인 시안에 대해 클라이언트의 컴펌을 득하고 나면 이후에는 각 화면별 세부 디자인 진행한다. 디자인이 완료되는 시기에 다시 클라이언트에게 리뷰를 요청한다. 스마트링크의 경험 상 이 순간이 향후 프로젝트의 운명을 결정 짓는 기획 단계 다음으로 중요한 순간인데, 클라이언트 분들에게 사전 공지를 많이 드리고는 있으나 그 중요성을 잘 인식하지 못하는 경우가 많다.

기획단계에서 치열하게 쌓아 올린 서비스의 구조와 정책과 모든 디테일들이 실제로 사용자에게 어떤 모습으로 전달될지가 확정되는 아주 중요한 순간이다. 아마도 기획 단계에서 무채색의 선과 면으로만 만들어진 프로토타입을 경험하고 난 뒤라 그런지, 디자인이 예쁘게 적용된 결과물을 보는 순간 모든게 다 좋아 보일 수도 있음을 충분히 이해한다. 그러나 이후 개발까지 모두 완료된 정말 살아 움직이는 최종 결과물을 접할때 의외로 많은 클라이언트들이 그제서야 디자인에 대한 피드백을 하기 시작한다.

문제는 디자인에 대한 수정이 사실상 디자인 자체의 수정만으로 끝나지 않는 경우가 많다는 것이다. 기획상의 정책 변경이 수반되거나, 개발 단의 각종 처리 방식이나 핵심 로직이 변경된다면 서로 난처해지기가 일수 이다. 그러므로, 디자인 단계가 완료되어 클라이언트가 디자인을 리뷰하는 시점에서 클라이언트 분들께 당부 드리고 싶은 것은, 디자인 검수의 중요성을 인지하고 최종적인 제품 UI의 마지막 버전을 리뷰한다라는 가정으로 임해주시기를 바란다. 디자인 단계 내에서 몇 차례의 수정은 당연히 필요하나, 개발이 완료되고 난 이후의 디자인 수정은 정말 남감하다. 의외로 기차 떠나고 난 다음 손 흔드시는 분들이 많다.

프로젝트 3단계 - 개발

스마트링크는 2001년 부터 C, C++, Object Pascal, PHP, Java, JSP/Servlet, Ruby on Rails, Python 등의 개발 언어와 다양한 플랫폼, 프레임워크, 라이브러리들 이용해 프로젝트를 수행해왔다. 스마트링크의 주요 고객층인 스타트업의 소프트웨어 개발에서 필요한 유연성과 time-to-market을 보장하기 위해 아래와 같은 원칙으로 구현 기술을 선택하고 있다.

Full-stack: Front-end에서부터 Back-end 까지 일관된 언어로만 개발을 진행
Schemaless Database: 잦은 기획 변경 및 초기 아이디어의 런칭 전후 시장 학습을 빠르게 반영할 수 있는 Schemaless 데이터베이스 만을 사용
State & Declarative: 모바일 네이티브 앱은 물론 웹 개발 시에도 전통적인 Stateless 방식이 아닌 State 방식과 선언적 패러다임의 프레임워크 및 방법론을 사용

소프트웨어 개발 분야는 기술 변화의 속도가 매우 빠르다. 또한 프로젝트의 진행에서 요구 사항에 따라 어떤 기술 스택을 사용하느냐에 따라 향후 프로젝트 진행 양상이 크게 영향을 받기 때문에, 소프트웨어 개발팀은 프로젝트 효율을 개선할 수 있는 새로운 기술이나 방법론에 대한 목마름이 항상 있어야 된다. 스마트링크의 개발팀은 이런 부분에 있어서는 기본적으로 오픈엔드(open-ended)이며 언제든 앞선 기술의 Early Adapter가 될 준비가 되어 있다.

현재 스마트링크에서는 다음과 같은 기술 기반으로 프로젝트를 진행하고 있으며, 동시에 효율을 더 끌어올릴 수 있는 새로운 기술이나 방법론을 계속해서 찾고 있다.

Front-end: Semantic UI, React, React Native
Back-end: Meteor, Nodejs
Testing: Mochajs, Jest
DevOps: AWS, Jenkins, Docker, Phusion Passenger, Nginx
DB: MongoDB

프로젝트 개발 진행시는 스크럼(Scrum) 방식을 도입하여 1주 단위의 스프린트를 진행하고 있다. 또한 협업도구에서 소개된 Jira라는 툴을 사용하여 프로젝트를 진행한다.

프로젝트 4단계 - 검수

버그 없는 소프트웨어는 존재하지 않는다. 기획 단계에서 부터 꼼꼼히 누수가 발생하지 않도록 많은 노력을 기울이고는 있으나 소프트웨어 특성상 개발 완료 이후 검수 단계에서 이런 저런 버그가 발생하기 마련이다. 하자와 관련된 이슈에 대해서는 기본적으로 계약에 명시된 하자보수 기간 동안 스마트링크에서 책임을 진다. 단, 기능상의 개선과 개발 완료 이후 변경에 대해서는 유지보수로 분류한다.

스마트링크 내부에서 자체적으로 기본적인 검수를 진행한 이후 클라이언트 검수가 진행되는데, 아래와 같이 QA 시트를 작성하여 내부 검수 단계에서 부터 발생한 버그들을 클라이언트와 모두 공유한다.

프로젝트 5단계 - 출시

DevOps

최근 클라우드 인프라 서비스가 보편환되고, 스타트업에서도 많이 활용하게 되면서 스마트링크에서는 아마존 웹 서비스(Amazon Web Service, AWS)를 기본 배포 인프라로 채택해서 쓰고 있다. 초기 운영 비용에 민감한 스타트업의 주머니 사정을 고려하여, 사용자가 많지 않은 초기 시험 운영단계에서는 무료로 사용할 수 있는 AWS의 프리티어(Free Tier)에 배포를 진행한다. 물론 이후 본격적인 운영단계로 접어들면, Elastic Load Balancer, Auto Scaling, MongoDB Replica Set등을 통해 Production 레벨로 설정을 변경하기도 한다.

최근 린 방법론이나 애자일 방법론 등에서 공통적으로 주장하는 "가볍고", "빠르고", "반복적인" 제품의 개발과 배포의 라이프사이클 주기가 중요하다라는 업계의 인식이 생겨나면서, 더 이상 개발과 운영을 별개의 독립적인 팀이나 프로세스로 구분하지 않고 개발과 운영을 합쳐 DevOps(Development + Operations) 라 부른다.

스마트링크에서는 프로젝트 배포 단계에서, DevOps 개념을 도입하여 개발 완료 후 AWS와 같은 클라우드 인프라에 지속적인 통합과 배포가 가능하도록 Mocha나 Jest같은 테스팅 프레임워크와 Jenkins등의 CI (Continuous Integration), CD(Continuous Deployment)를 적용하고 있으며, 빠른 릴리즈를 보장하고 Time-To-Market을 줄일 수 있도록 노력하고 있다.

운영 < 지표 측정

출시 시점 부터 클라이언트가 본격적으로 바빠지는 시간이다. 사업에 필요한 무기가 생겼으니, 이제 이 무기를 활용해서 사업을 성공 시켜야하는 본 게임이 시작되는 것이다. 운영 단계에서는 기술적인 지원과 기능적인 유지보수도 중요하지만 실제로 중요한 것은 제대로 된 지표 측정과 이에 대한 분석이다.

앞선 린 스타트업 섹션에서 언급하였듯 잘 개발된 제품(MVP)을 시장에 내놓는 이유는 너무 명확하다. 시장의 반응을 측정해서 MVP를 변경(pivot) 할지 또는 지속(persevere) 할지의 여부를 결정하는 것이다. 초기 계획(plan A)이 시장에서 먹히는 제품이나 서비스(a plan that works)가 될때 까지! 물론, 단 한번의 Pivot도 없이 출시하자마자 곧 바로 하키스틱 성장곡선을 그릴 수도 있겠지만 이런 예는 극히 드물다. 지표 측정과 분석에 대해서는 Lean Startup과 Running Lean에서 구체적인 방법을 학습하시기를 추천 드린다.

출시 이후의 유지보수

최종적으로 프로젝트가 완료되어 운영이 시작되면 클라이언트의 또다른 걱정이 시작된다. 스마트링크 덕분에 개발은 잘 되었는데, 이제 유지보수는 어떻게 해야할까?

이 질문은 받는다는 것은 스마트링크 입장에서는 행복한 경험의 순간이다. 대부분의 작은 영세 개발 외주 업체에서는 클라이언트와 협의된 일정이나 퀄리티 기대 수준을 만족하며 프로젝트를 성공적으로 아니 무사히(?) 마무리하는 경우가 생각보다 드물다. 프로젝트를 퀄리티 있게 잘 마무리 할수록 클라이언트는 이후 유지보수가 더 고민 된다. 내부 인력을 뽑을 것인가? 계속 외주로 진행할 것인가?

모든 리소스가 제한적인 스타트업의 경우 답은 명확하다. 당연하게도, 런칭 이후 지표 측정과 분석을 통해 사업의 성장 추이를 민첩하게 모니터링하면서 향후, 운영 및 유지보수 계획을 수립해야 한다. 비즈니스의 성장 추이와 발맞춰 내부 개발 인력을 구성하거나 기존 개발 업체를 통한 유지보수를 진행해야 한다.

스마트링크에서는 앞서 "개발" 섹션에서 언급되었듯이, 프로젝트 개발시에 사용하는 기술 스택을 선택함에 있어 기술의 난이도보다는 개발의 효율성 및 결과물의 퍼포먼스를 위주로 판단하기 때문에, 자연스럽게 최신 기술 또는 난이도가 높은 기술 기반으로 프로젝트가 진행되는 경우가 많다. 클라이언트 측에서 내부 개발인력 구성시 이에 대한 고려가 필요하다.

맺음말

여러 클라이언트와 함께 다양한 제품과 서비스를 한 팀 처럼 개발하며 그 동안 스마트링크는 많은 성장을 해왔다. 그리고 또 앞으로도 계속해서 좋은 클라이언트와 좋은 프로젝트를 만나 성장하고 진화하기를 고대하고 있다.

대부분의 클라이언트가 스마트링크 팀원들의 프로페셔널과 열정적인 노력에 항상 지지와 감사로 응원을 해 주었지만, 어떤 경우에는 급한 일정으로 인해 주말 밤낮을 가리지 않고 무리하게 프로젝트를 진행하여 결과물이 나왔으나, 클라이언트 측의 반복되는 흔하지만 치명적인 실수로 인해 귀한 노력의 산물이 빛을 보지 못하는 경우도 많았다.

스마트링크의 미래 클라이언트에게 스마트링크의 스마트한 프로젝트 진행 방식을 미리 소개함으로써 상호 신뢰 기반의 효율적이고 효과적인 프로젝트를 진행할 수 있기를 희망하며 이 긴 글을 맺는다.

AWS - Elastic Load Balancing (ELB)

grooveslap — Sun, 31 Dec 2017 05:37:41 +0900

1. Load Balancer란?

DevOps에서 핵심이라고 할 수 있는 서버 배포 관련 내용 중 가장 기본이라고 할 수 있는 로드 밸런서(Load Balancer)에 대해 알아보자. 스마트링크에서 개발 완료된 서비스를 배포할 때 기본적으로 사용하는 클라우드 인프라인 Amazon Web Service (AWS)에서 제공하는 Elastic Load Balancer를 기준으로 설정 방법을 설명하려고 한다.

우선, 먼저 Amazon의 Elastic Load Balancer 설명을 보도록 하자.

Elastic Load Balancing이란 무엇입니까?
Elastic Load Balancing은 여러 가용 영역에서 수신되는 애플리케이션 트래픽을 여러 EC2 인스턴스에 자동으로 분산합니다. 이렇게 하면 애플리케이션의 내결함성이 향상됩니다.
로드 밸런서는 클라이언트에 대해 단일 접점의 역할을 하여 애플리케이션의 가용성을 높입니다. 애플리케이션에 대한 요청의 전체적인 흐름을 방해하지 않고 필요에 따라 로드 밸런서에서 인스턴스를 추가 및 제거할 수 있습니다. 애플리케이션에 대한 트래픽이 시간에 따라 변화하므로 Elastic Load Balancing이 로드 밸런서를 자동으로 확장하며 대다수의 워크로드를 자동으로 확장할 수 있습니다.
로드 밸런서가 정상적인 인스턴스에만 요청을 보낼 수 있도록 등록된 인스턴스의 상태를 모니터링하는 데 사용되는 상태 확인을 구성할 수 있습니다. 또한 인스턴스가 주요 작업에 집중할 수 있도록 암호화 및 복호화 작업을 로드 밸런서로 오프로드할 수 있습니다.

"가용 영역", "단일 접점", "워크로드, 암호화 및 복호화 작업을 로드 밸런서로 오프로드 할 수"... 혹시 이 설명을 읽고 Load Balancer가 무엇인지 바로 이해가 되시는 분은 주저하지 말고 우리 회사 채용공고에 지원하시라. 채용은 따놓은 당상이니!!! ㅎㅎ

그렇다. Amazon이 무수히 많은 인프라서비스를 제공하지만 그 어떤 서비스도 한글로 제대로 설명하는 서비스가 없다. 물론, 다국적 서비스답게 원어(영어)로 설명하는 경우는 설명이 제대로다. 이런 이유로, 아래의 세부 설정 방법에서 사용되는 모든 용어와 스크린샷은 원어(영어) 기준으로 설명을 진행할 것이다!

좀 더 인간적인 설명을 찾아보자.

*로드밸런싱의 정의 :
로드밸런싱이란(Load Balancing)이란 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량, 속도저하등을 고려하여 적절히 분산처리하여 해결해 주는 서비스입니다.

*로드밸런싱 서비스 방식 :
네트워크 상단에 L4스위치 가상서버가 존재하여 서버로 들어오는 패킷을 리얼 서버로 균일하게 트래픽을 부하 분산시킵니다.
만약 리얼 서버 중 정상적으로 작동하지 않는 경우가 발생하면 이를 감지하여 정상적으로 작동하는 서버로 부하 분산시킵니다.

*로드밸런싱의 장점 :
1. 고가의 서버로 확장하지 않고 저렴한 비용으로 다수의 서버를 증설하여 경제적으로 비용절감 할 수 있습니다.
2. 대량의 트래픽으로 1대의 서버로 집중적인 부하율이 높아지면 L4 스위치가 이를 감지하여 합리적으로 부하분산 처리 할 수 있습니다.
3. 1대의 서버 장애가 발생하여도 서비스 중단없이 다른 서버로 적절히 자동으로 분배하여 서비스가 계속 운용가능하게 할 수 있습니다.
4. 추후 사용량이 많아 서버 확장으로 서비스 중단없이 서버 증설이 가능 합니다.

한마디로 말해서 Load Balancer는 여러대의 서버로 로드(요청 또는 트래픽)를 "적절하게" 분산해주는 역활을 하는 서버 또는 서비스이다. 아래의 그림을 보자.

위에서 말한 "적절하게"의 방식에 따라 로드 밸런스는 아래와 같이 크게 2가지로 나뉜다.

L4 Load Balancer: OSI 7 Layer 중 Layer 4를 지원하는 Load Balancer이다. TCP나 UDP등이 대표적인 Layer 4 프로토콜이며, IP 주소와 포트 번호를 기준으로 트래픽을 분배한다.
L7 Load Balancer: OSI 7 Layer 중 Layer 7를 지원하는 Load Balancer이다. HTTP가 대표적인 Layer 7 프로토콜이며, HTTP 헤더의 내용을 기준으로 트래픽을 분배한다. 사용자의 Session에 따라 부하 분산을 하기 위해서는 L7 Load Balancer가 필수이며, AWS Elastic Load Balancer에서는 Application Load Balancer라는 이름으로 L7 Load Balancer를 서비스하고 있다.

추가로, Elastic Load Balancer의 동작 알고리즘은 기본적으로 Round Robin 방식(요청이 들어올때 마다 다른 서버로 부하 분산)을 사용하는데, 옵션으로 Sticky Session을 설정하는 경우 Session이 연결된 이후에는 다른 서버로 분산하지 않고 HTTP 헤더에 기존 Session이 설정된 서버로 요청이 가도록 할 수 있다.

사실 예전에는 부하 분산과 고가용성을 지원 하려면 별도의 L4/L7 장비나 서버를 구입해야 했기 때문에, Load Balancer가 일반 개발자들의 영역은 아니었다. 네트워크 전문가 또는 System Administration 담당자가 서비스의 부하를 측정하여 장비를 늘리면서 설정하는 경우가 대부분이었으나 클라우드 서비스 시대가 오고 DevOps가 일반화 되면서 상황이 많이 바뀌었다. AWS와 같은 클라우드 서비스에서 가장 빛을 발하는 부분이 바로 고가의 하드웨어를 구매하지 않고 손쉽게 사용할 수 있는 Elastic Load Balancer나 Auto Scaling이 아닌가 싶다.

2. AWS Elastic Load Balancer의 특징

AWS의 Elastic Load Balancer를 제대로 설정하기 위해서는 AZ(Availability Zone) 개념을 이해해야 한다. 또한 AZ 개념을 제대로 이해하기 위해서는 Region에 대한 개념을 이해하고 있어야 한다. 사실 Region과 AZ에 대해서는 개념도 단순하고 잘 설명한 글들이 워낙 많으니 쉽게 찾아 보고 이해할 수 있을 것이나, 간략히 설명하자면, Region은 AWS가 입점(?)한 나라 또는 대륙이라고 보면되고, AZ는 각 Region내의 물리적인 데이터센터라고 이해하면 된다. 참고로, 몇년전까지만 해도 우리나라에는 AWS Region이 존재하지 않았었기 때문에, AWS로 서비스를 배포할때 마다 일본 Region이 네트워크 부하나 속도가 괜찮을지, 싱가폴 Region이 괜찮을지를 쓸데없이 고민하곤 했었다.

아무튼 Elastic Load Balancer를 제대로 설정/활용하기 위해서는 다음을 꼭 기억하자!

"최소 2개 이상의 인스턴스가 각기 다른 AZ에 존재해야 한다."

생각해보면 너무나도 당연한 말이지 않는가?! AZ는 물리적인 데이터센터 이기 때문에 하나의 데이터센터가 테러, 화재, 천재지변 등으로 인해 서비스 불능 상태가 되더라도 다른 데이터선터가 하나라도 살아 있고 Load Balancer가 그쪽으로 트래픽을 전달해주기만 한다면, 나의 서비스가 중단되는 일은 없을 것이기 때문이다. 사실 이런 이유 때문에 이후 Load Balancer설정에서 Target에 대한 Health check를 설정한다.

3. 설정방법

AWS에서 L7 Load Balancer를 지원하는 서비스 명은 Elastic Load Balancer, 줄여서 ELB라 부른다. ELB 또는 다음 블로그에서 설명할 Auto Scaling의 경우 Elastic Cloud Computing (EC2)에 속한 기능이므로 ELB와 Auto Scaling을 사용하기 위해서는 AWS의 많은 서비스들 중에서 EC2를 선택하여 EC2 Dashboard 화면으로 진입한다.

ELB세팅을 하기 위해서는 너무나도 당연하게 로드를 분산할 EC2 인스턴스가 최소 2개 이상이 있어야 한다. 또한 앞서 언급한 것과 같이 고가용성(High Availability)을 위해서는 두개의 AZ(Availability Zone)에 EC2 인스턴스를 분산해야 한다. 그래야 하나의 AZ가 죽더라도 다른 AZ에서 운영중인 EC2로 인해 서비스 전체가 죽어버리는 일이 없기 때문이다. 아래는 예제로 보기 위한 최근 런칭한 서비스의 대쉬보드이다. 보이는 바와 같이 현재는 ELB나 Auto Scaling이 적용되어 있지 않으며, 아래와 같이 기본적인 Web 서버와 DB 서버가 동작중이다.

MongoDB의 경우 일반적인 Web Server와는 다른 방식으로 고가용성을 지원해야 하므로, 이 블로그에서는 Web Server의 고가용성을 위한 ELB 설명에만 집중하기로 한다. MongoDB의 고가용성에 대해서는 별도의 블로그 포스트를 통해 설명할 예정이다.

3.1. 사전작업 (EC2 인스턴스 2개 만들기)

앞서 설명한 것과 같이 서로 다른 AZ에 EC2 인스턴스를 만들어야 한다. 쉬운 방법은 기존에 만들어진 EC2 인스턴스 동일한 세팅을 그대로 적용하되, AZ 존만 다르게 설정하는 것이다. EC2를 선택한 다음 Actions 메뉴에서 "Image"를 선택하거나 "Launch More Like This" 이용하여 동일한 인스턴스를 생성하는 할 수 있는데, 여기서는 "Launch More Like This" 방법으로 진행해 보자.

아래와 같이 기존 EC2와 동일한 세팅으로 인스턴스가 생성될 수 있도록 모든 설정값이 자동으로 입력되고, 인스턴스를 실제로 런칭할 수 있는 마지막 단계인 Review 단계로 넘어가게 된다.

잠깐, 여기서 바로 "Launch" 버튼을 누르지 말고 화면 상단의 "3. Configure Instance" 단계로 돌아가 AZ 설정을 변경한다. 앞서 설명한 대로 기존 EC2와는 다른 AZ를 선택한다.

기존 EC2의 AZ는 "ap-northeast-2a" 였으므로, 이번에는 아래와 같이 "ap-northeast-2c"로 변경 후 화면 하단의 "Review and Launch" 버튼을 클릭한다.

다음 단계로, 새로운 EC2 인스턴스를 Launch 하기전에 Key Pair를 새로 생성할 것인지 기존 Key Pair를 재활용할 것인지 물어보는데, 기존 Key Pair를 사용하도록 설정하고 "Launch Instance"를 클릭한다.

이후 런칭 상태를 보여주는데, "View Instance" 를 누르면 EC2 인스턴스 목록화면으로 돌아간다.

결론적으로, 아래와 같이 기존 EC2인스턴스와 AZ 설정만 다른 새로운 인스턴스가 생성된 것을 볼 수 있다. 다시한번, 기존 EC2의 AZ는 ap-northeast-2a 이며, 새로 생성된 EC2 인스턴스의 AZ는 ap-northeast-2c 인것을 확인한다.

3.2. Load Balancer 생성하기

이제까지는 Load Balancer를 적용하기 위한 사전 작업이었다면, 지금 부터는 본격적으로 ELB를 생성하고 다루는 본게임이다. 아래와 같이 EC2 인스턴스 목록 화면의 좌측 메뉴에서 "LOAD BALANCING" 섹션의 "Load Balancers"를 선택한다.

"Create Load Balancer"를 클릭해서 다음 화면으로 넘어간다.

ELB에서 지원하는 Load Balancer는 총 3가지 이며 Application Load Balancer는 L7 Load Balancer로, Network Load Balancer는 L4 Load Balancer로 이해하면 되겠다. 우리는 향후 Sticky Session 지원을 위해 HTTP head를 통한 트래픽 분산이 필요하니 당연 L7 Load Balancer인 Application Load Balancer를 선택한다.

Load Balancer의 이름을 입력한다.

다음으로 Load Balancer가 트래픽을 분배할 AZ를 선택한다.

다음은 SSL(HTTPS)에 대한 설정을 하지 않는 경우 나오는 Warning이므로, 지금은 패스~

Security Group을 새로 만드는것을 추천한다. 기본적으로 일반 80 포트로 서비스하는 경우에는 80포트만 inbound 접속 가능하도록 설정해준다.

3.3. Target Group 생성

여기서 부터가 기존 Load Balancer와 비교시 조금 달라진 부분이다. 기존에는 Load Balancer내에 Target Group이 포함되어 있었으나, 지금은 두개가 분리되었다. 일반적으로 DNS에 세팅된 Load Balanacer의 DNS를 변경하지 않고 Target Group을 여러개로 구성할 수 있으니 편의성이 더 올라갔다고 볼 수 있다.

Target Group의 이름을 쓴 후 Target Group의 Health Check 옵션을 변경할 수 있는데, 보통 기본값을 쓰면 무난한다.

Target Group 설정에서 가능 중요한 부분이다. 앞서 설정한 Load Balancer의 설정에서 선택된 AZ에 포함된 모든 EC2 인스턴스가 Instances 목록으로 나타나고 선택한 EC2 인스턴스를 Load Balancer의 Target으로 등록할 수 있다.

MongoDB 서버를 제외한 Web Application 서버가 동작중인 10X Web1과 10X Web2를 선택하고 "Add to registered"를 클릭한다.

아래와 같이 선택된 EC2 인스턴스가 "Registered targets"로 등록된 것을 확인 할 수 있다. 하단의 "Next: Review" 버튼을 클릭하여 다음 단계로 넘어간다.

마지막 단계 리뷰 단계이다. 앞서 설정된 값들이 모두 제대로인지 확인 후 "Create" 버튼을 누르자.

기분좋은 초록색 성공화면!

3.4. Sticky Session

자, 이제 거의 마지막! 로그인 서비스가 있는 경우 단순 Round Robin 방식의 트래픽 분산인 경우 브라우저에서 예상했던 대로 동작하지 않고 여러 이상 증상을 경험할 수도 있다. 특히 Meteor와 같이 기본 Web Socket 기반의 기술인 경우는 무조건, Sticky Session을 설정해야 한다. 우선, 왼쪽 메뉴에서 LOAD BALANCING > Target Groups를 선택한다.

Target Group 화면에서 앞서 생성한 "10xELB"를 선택하면 아래 화면과 같이 Stickiness를 선택할 수 있다.

화면에서 원하는 세션을 길이 설정할 수 있다. 기본값인 하루로 둬도 무방하다.

설정 후 아래와 같이 변경된 적용 값을 확인 할 수 있다.

4. 맺음말

이렇게 해서 AWS의 ELB를 세팅하는 방법에 대해 알아 보았다. 기존 L4/L7 장비 구입부터 까다로운 네트워크 세팅 들을 잘 추상화해서 몇번의 클릭 만으로 Load Balancer를 뚝딱 세팅할 수 있으니 Production 환경에서 매우 유용한 서비스이다. 사실 각 Region 별로 Target Group을 추가하는 등, 본격적인 Production 환경에서는 더 세분화된 세팅이 필요하나 기본적인 Load Balancer의 개념과 ELB 사용법은 충분히 설명이 되지 않았나 생각한다.

다음 블로그에서는 한발 더 앞선 기술이자 AWS와 같은 클라우드 인프라에서만 가능한 Auto Scaling에 대해 알아보도록 하겠다.

Xcode-Select - 여러 버전의 Xcode 관리하기

grooveslap — Thu, 7 Sep 2017 13:25:53 +0900

불친절한 Xcode씨

Hybrid 방식이든 Native 방식이든 iOS 애플리케이션을 개발하는데 필수적인 Apple의 IDE(Integrated Development Environment), Xcode. 좋은 도구 임에는 분명하나 가끔은 Apple의 철학(고집?)이 너무 많이 반영된 것이 아닌가 하는 부정적인 시각으로 바라보게 되는 순간들이 종종 있다.

대표적인 예는 최근 업데이트된 Xcode 8버전이다. Xcode 8버전에서는 iOS8 버전 이상만을 지원 한다. 물론 Apple답게, iOS 8 버전이하는 과감(?)하게 버렸다!.

최근 유지보수를 진행 중인 연합뉴스TV 모바일앱 (https://itunes.apple.com/kr/app/연합뉴스tv/id1084591457?mt=8)은 Xcode 7 버전으로 개발이 되었고, 이후 여러 프로젝트를 진행하면서 최신 버전의 iOS를 지원하기 위해 Xcode 8 버전으로 업그레이를 한 상황이었다.

Xcode 7 버전으로 개발된 연합뉴스TV 프로젝트를 Xcode 8 버전에서 로드하여 빌드하는 과정에서 (Xcode 버전 차이로 인해 발생하는 문제라는 힌트를 전혀 주지 않은 채) 수많은 알 수 없는 빌드 오류 들이 발생하였다.

개발자로서 Xcode 정도 수준의 IDE에 기대하는 기본적인 편의 기능들이 여러가지가 있을텐데, 그중 기본적이며 필수적이라고 할 수 있는 것은 Backward Compatibility 관리 기능 일 것이다. Xcode 7 버전이든, 8 버전이든 어떠한 Warning도 없이 프로젝트 파일이 로드가 된다면, 당연 개발자는 Backward Compatibility가 보장된 것이라고 믿지 않을까? (나만 그럴 수도 ㅎㅎ) 만약 Backward Compatibility가 보장되지 않는다면, 최소한 프로젝트 로드 시 경고 정도는 뱉어줘야 되지 않을까?

아무튼 Xcode 7 버전으로 개발했다는 사실을 망각하고 Xcode 8 버전에서 빌드가 잘 되기를 바란 순진한 나 자신 부터 반성을 해야... ㅜㅜ

여러개의 Xcode 설치하기

우선 여러 개의 Xcode를 설치하기 위해서는 다음과 같이 Xcode의 실행 파일명 변경이 선행되어야 한다.

먼저, Xcode가 실행 중이라면 종료.
/Applications/Xcode.app 을 /Applications/Xcode_8.x.x.app 로 변경
관리자 비밀번호 팝업에서 비밀번호 입력
추가로 설치할 Xcode의 .dmg 파일 준비 (https://developer.apple.com/download/more/ 에서 다운로드)
새로 설치된 Xcode의 실행 파일 이름 변경: /Applications/Xcode.app 를 /Applications/Xcode_7.x.x.app로 변경

Xcode-Select로 Xcode 설정하기

이와 같이 여러 개의 Xcode 버전이 설치되어 관리가 필요한 경우, xcode-select라는 CLI(Command Line Interface)를 통해 쉽게 관리가 가능하다. 별도의 설치 과정은 필요없다. Xcode가 설치될 때 번들로 설치되는 CLI 도구들 중 하나이기 때문이다. 두 개의 이상의 Xcode 버전에 대해 xcode-select를 통해 전환(switch) 및 설정이 가능한다, 기본적인 xcode-select 사용법은 아래 링크를 참고하자.

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/xcode-select.1.html

언제나 그렇듯, 기본적인 사용법은 --help 옵션을 통해서도 확인이 가능한다.

먼저 현재 설정된 Xcode를 화면에 출력하기 위해서는 아래와 같이 -p (또는 --print-path) 옵션을 사용한다. 아래 예시 화면에서는 7.3.1 버전으로 설정이 되어 있는 것을 확인할 수 있다.

이번에는 다른 버전의 Xcode로 전환하기 위해 -s (또는 --switch) 옵션을 사용해보자. (설정 변경에는 root 권한이 필요하다.)

설정이 제대로 변경되었는지 확인하기 위해 다시 -p 옵션을 이용하여 결과를 확인한다.

To Dear Smartlink Developers: Meteor에서 Cordova를 이용하여 iOS 하이브리드 프로젝트를 진행할때 meteor build 컴맨드 실행시 현재 설치되어 있는 Xcode 버전 중에서 xcode-select로 설정된 CLI 빌드 도구를 이용하여 build가 진행된다. 그러므로, 기존 Xcode 7 버전 이하 프로젝트를 meteor build를 통해 iOS 앱을 빌드할 때는 반드시 xcode-select를 통해 해당 Xcode 버전이 설정해야만 한다.

라우터 모듈 react-navigation VS react-native-router-flux

알 수 없는 사용자 — Sun, 2 Jul 2017 13:58:32 +0900

리액트 네이티브의 시드를 만들면서 가장 고민이 되는 부분이 라우터 모듈을 선택하는 부분이었다.

리액트 네이티브 앱도 기본적으로 spa로 동작하게 된다.

spa에서는 페이지 전환이 일어날 때마다 서버로 페이지를 요청하는 대신 클라이언트 사이드에서 페이지를 바로 전환해준다.

이것을 가능하게 해주는 것이 클라이언트 사이드의 라우터 모듈이다.

보통 앵귤러나 리액트의 라우터 모듈들을 보면 브라우저의 url 변화를 인식하여 그 url에 해당하는 페이지를 동적으로 변화시켜준다.

그러나 리액트 네이티브 앱은 url로 라우팅하지 않는다.

(딥링킹을 통해서 특정 페이지의 url을 지정하여 외부 웹브라우저 등에서 myRnApp://login 로 접근할 수 있도록 할 수 있지만 기본적으로는 url이 존재하지 않는다.)

리액트 네이티브 앱에서는 특정 페이지에 키를 부여하여 라우팅한다.

1. 페이지 라우팅

react-navigation와 react-native-router-flux의 두 경우 키를 가지고 어떻게 라우팅하는지 살펴보자.

1
2
this.props.navigation.navigate('Login');
 
Colored by Color Scripter
cs

(react-navigation)

1
2
3
4
import { Actions } from 'react-native-router-flux';
 
Actions.login();
 
Colored by Color Scripter
cs

(react-native-router-flux)

react-navigation은 Login이 키가 되고 react-native-router-flux는 login이라는 키를 사용하여 페이지 이동을 한다.

페이지를 이동하는 코드만 봐도 두 라우터 모듈은 극명하게 갈린다.

react-navigation은 컴포넌트의 프로퍼티로 navigation 객체가 전달되고 navigation에 있는 navigate 함수를 통해서 이동한다.(non-flux)

반면 react-native-router-flux는 Actions를 임포트하여 Actions 객체에 있는 login 함수(액션 트리거)를 통해서 이동한다.(flux)

non-flux는 navigation 객체를 받은 해당 컴포넌트에서만 사용할 수 있고 flux는 어디서든 Actions를 임포트하여 사용할 수 있다는 특징이 있다.

여기까지만 보면 react-native-router-flux를 사용하지 않을 이유가 없다.

2. 페이지 전환 효과

페이지가 전환될 때마다 전환효과를 줄 수 있는데 react-navigation은 안드로이드에서는 아래에서 위로 올라오는 전환효과를 가지고 있고 ios에서는 오른쪽에서 왼쪽으로 오버랩되는 전환효과를 가지는게 디폴트로 되어 있다.

react-navigation에서의 전환효과는 안드로이드와 ios가 각각 다른 것이다.

이런 전환효과를 원치 않을 때는 이것은 굉장히 성가시게 된다.

react-navigation에서는 페이지별 전환효과를 주기가 까다롭게 되어 있기 때문에 더욱 그렇다.

반면 react-native-router-flux는 안드로이드와 ios의 전환효과가 같고 페이지별로 전환효과를 주기가 굉장히 편하다.

여기에서도 여전히 react-native-router-flux의 승이다.

3. 버그들

react-native-router-flux를 쓸 때 약간의 버그가 있었다.

스냅샷 테스트를 진행할 때 flux 패턴을 사용하면 알 수 없는 에러가 발생했다.

하지만 엑스포 sdk 18.0.0으로 버전 업되면서 이부분이 해결된 듯 하다.

react-navigation은 리액트 네이티브에서 공식적으로 지원하는 모듈 답게 버그는 없는 듯하다.

4. 페이지로 모달 구현

모달은 모든 페이지에서 접근할 수 있게 만들어야 한다.

그렇게 하려면 라우팅되는 페이지로 모달을 만드는 것이 적절하다.

react-navigation은 라우팅될 수 있는 페이지 스코프가 한정되어 있기 때문에 페이지로 모달을 구현하기 어렵다.

react-native-router-flux은 라우팅 가능한 페이지의 스코프가 굉장히 넓기 때문에 모든 페이지에서 접근 가능한 라우트 페이지를 구현하기 쉽다.

그래서 react-native-router-flux는 모든 페이지에서 접근 가능한 모달 페이지를 만들기 쉽다.

5. react-native-drawer과의 통합

react-native-router-flux에서는 가장 많이 쓰는 drawer 메뉴 모듈인 react-native-drawer과의 통합을 지원한다.

6. 퍼포먼스

퍼포먼스에 대해서는 지금 당장은 결론을 내리기가 어렵다.

팀블로그 스킨을 교체했습니다 :)

알 수 없는 사용자 — Mon, 5 Jun 2017 18:18:54 +0900

여러 세팅들을 고려했지만 역시 이 테마가 가장 깔끔하고 사용성이 좋아 보입니다.

그래서 나름 거금 21,000원을 들여서 스킨을 구입^[각주:1]했습니다. (ㅋㅋ)

보다 쾌적한 환경이 조성된만큼 잘 활용해서 우리와 클라이언트 모두에게 유용한 장이 되면 좋겠네요.

앞으로 풍성하게 가꿔가보도록 하죠!!

회사에 보내는 제 선물 :) [본문으로]