스토리 홈

인터뷰

피드

뉴스

조회수 6749

`git push —force` 이야기

안녕하세요. 스타일쉐어 개발팀의 김현준입니다. 훌륭한 엔지니어링 경험을 공유하고 싶어 만든 블로그이지만, 아직까지는 그런 일이 없었던지라, 창피한 장애 경험을 공유하고자 합니다.배경:웹 서비스 디플로이는 프로덕션 웹 서버에서 업스트림 master를 풀 받아 리로드하는 방식으로 진행하고 있습니다.CSS, JS 등의 파일들은 CDN을 위해 매 빌드마다 디플로이 이전에 S3에 업로드합니다. Git 커밋의 SHA1 해시를 키로 사용합니다.장애:어제 새벽 서비스에 긴급한 패치가 있었습니다. 하지만 이 커밋은 8분 후 다시 롤백되는데…오늘 오후 디플로이 이후에 갑자기 웹 사이트의 스타일이 전부 깨져보이기 시작했습니다.심지어 아무리 커밋 로그를 살펴봐도 존재하지도 않는 커밋 해시로 파일을 요청하고 있었습니다.원인:롤백을 git revert 명령으로 하는 대신에, 이전 커밋으로 HEAD를 돌리고 git push --force로 업스트림을 덮어썼습니다.해당 커밋은 이미 디플로이가 되어있었지만, 되돌린 이후에 다시 디플로이를 하지 않았습니다.다음 디플로이할 때 해당 웹 서버 로컬에서 업스트림 master를 풀 받자, (개발자의 로컬이나, GitHub에서 보이는 커밋 트리와 달랐기 때문에) 서로 다른 커밋 해시를 가지게 되었습니다.404교훈:force-push를 (창피한 실수라던지, 지저분한 여러개의 커밋이라던지) 이력을 남기고 싶지 않을 때 사용하는 경우가 있는데요. 이는 위의 사례처럼 해당 커밋을 이미 풀 받은 다른 개발자의 로컬을 꼬이게 하거나, 장애를 유발할 수가 있습니다. 롤백을 하고 싶은 경우엔 revert 명령을, 커밋을 정리하고 싶은 경우엔 각자의 브랜치에서 충분히 rebase를 한 뒤에 올리는 습관을 꼭 가져야겠습니다.#스타일쉐어 #개발 #개발자 #개발팀 #인사이트 #후기 #일지
조회수 1727

Humans of TODAIT : 전설의 전성윤을 만나다

‘Humans of TODAIT’의 두번째 주인공, 투데잇 안드로이드 개발자 전성윤을 만나봤습니다. 투데잇의 전설(★)이 된 그의 이야기를 함께 들어볼까요?(2016.08)✓ 전설윤, 그는 누구인가Q. 자기소개 부탁드려요.안녕하세요! 투데잇에서 안드로이드 개발자를 맡았던 전성윤입니다. 퇴사자 인터뷰를 하려니까 투데잇을 떠나는 게 정말 실감나네요. 작년 2015년 10월 경, ‘SW 마에스트로’ 과정에서 만난 분께서 대표님을 소개해주셨고, 좋은 인연으로 연결되어 투데잇과 함께 일하게 되었어요. 처음엔 안드로이드 개발자로 들어왔다가 지금은 안드로이드 개발 팀장직까지 맡고 있습니다. (당시 2016.08)Q. 투데잇을 떠나는 이유는 무엇인가요?사실 처음 입사할 때도 1년 정도 생각하고 있었어요. 일하다보니 투데잇이 너무 좋아져서 나가고 싶지 않았지만, 아무래도 군문제와 학교 복학 문제가 마음에 걸리더라고요. 그래서 여러 고민 끝에 할 수 없이 나가게 된 케이스예요. 결국 아쉽지만 이번 8월을 마지막으로 투데잇과 헤어지게 되었죠.Q. 별명이 전설윤이라고 하던데, 왜 전설이라고 불리는 건가요?저도 이번 인터뷰를 통해서 생각해보게 된 건데요. ‘전설’이라는 칭호가 지금은 한물 간 사람에게 붙는 것이 아닌가 싶어요. 다른 팀원분들이 들어오시게 되면서 자연스럽게 리즈시절이 지나게 되었죠. (웃음)다른 이유가 아니라, 혼자만 잘하는 것이 아닌 다 함께 잘하기 위해 애썼기 때문인 것 같아요. 업무에 있어 버려야 할 습관 같은 작업 처리 팁에 대해 새 팀원분들께 적극적으로 공유했고 적당한 선에서 체크해드렸어요. 7–8개월의 짬 덕분인지 기획 단계에서부터 개발 단계 때 준비할 것들이나 구현 방법들이 곧장 떠오르는 경지에 이르더라고요. 이런 점들이 다른 팀원분들이 좋은 퍼포먼스를 낼 수 있게 이끌어주는 역할을 했던 것 같아요. 또 그 분들도 잘 하는 방법에 대해 치열하게 고민했고 실제로도 다들 너무 잘해주셔서 결론적으로 이제는 혼자가 아닌 다 함께 잘하게 된 거죠.✓ 보안 전문가에서 투데잇 안드로이드 팀장으로 레벨 업!Q. 투데잇 안드로이드 팀장까지, 성윤님의 입사 초반부터 지금까지 업무 성장과정이 듣고 싶어요!입사 초기에는 솔직히 맘고생 많이 했어요. 내가 지금 당장 회사에 기여할 수 있는 점이 무엇일까 의욕적으로 많이 고민했지만, 그에 비해 개발 능력은 많이 떨어졌죠. 초기에는 무엇보다 제 개발 능력 수준에 대해 정확히 몰랐고 커뮤니케이션하는 방법이 미숙했던 것 같아요. 그 때마다 대표님, 개발팀장님께서 진심어린 피드백과 따끔한 조언을 계속 해주셔서 해결할 수 있었죠. 두 분의 노력덕분에 중반부터는 업무 처리 능력도 커뮤니케이션 능력도 많이 향상됐어요,이후에 본격적으로 개발자분들이 더 들어오고 협업이 시작되면서 1인 개발자에서 2인 개발자 체제로 바뀌게 되었고, 자연스럽게 그에 따른 새로운 이슈들이 생길 수 밖에 없었어요. 다른 개발자분들에게 업무 분담하고 리드하는 부분에서 어려움을 느꼈지만, 함께 잘 해결해나갈 수 있었죠 지금은 기획적인 틀을 잡고 누군가에게 일을 맡기고 내 일을 해내고 하는 여러 부분에서 팀장의 위치에서 역할을 잘 해내는 것 같아요. (웃음)Q. 그렇다면 특별히 힘들거나 어려웠던 일정은 무엇이 있었나요?되게 좋은 질문이에요! 전 개발자다보니까 이런 질문이 너무 좋네요. (웃음)구매페이지와 그룹 기능 작업이 좀 힘들었어요. 그 중에서도 프로버전 구매페이지 작업이 가장 힘들었는데요. 작업 자체가 힘들다기보다는 구매페이지에서 에러가 나면 유저의 신뢰도에 큰 영향을 주기 때문에 한치의 실수도 용납되지 않는 부분이라는 점이 부담이 됐죠. 처음엔 실수도 많았는데, 그 이후에 치밀하게 설계한 덕분에 두 번째부턴 버그가 터져도 바로 대처할 수 있었어요. 개인적으로 개발적으로 많이 성장한 느낌을 받았죠.그룹 기능 개발은 클라이언트 쪽에서 해결해야 하는 부분이 많아서 힘들었어요. 하지만 릴리즈 이후 유저분들이 격렬하게 환호해주신 덕분에 뿌듯하게 잘 마무리할 수 있었죠. 두 작업 다 힘들었지만, 굉장히 보람됐던 작업으로 기억에 남아요.Q. 유저들의 피드백을 보면서 얻은 게 많다고 하던데, 좀 더 말해주세요!“실제 유저와 소통하고 친근한 서비스를 제공하려고 노력하다보니 유저들의 피드백이 얼마나 소중한 건지 알게되더라구요.”투데잇을 다니기 전까지만 해도 저는 별 5개 짜리 리뷰가 당연하게 받아야할 칭찬이라고 생각했어요. 그래서 사실 크게 반응하지 않았었는데, 실제 유저와 소통하고 친근한 서비스를 제공하려고 노력하다보니 유저들의 피드백이 얼마나 소중한 건지 알게되더라구요. 당연히 좋은 피드백은 정말 힘이 많이 되었고, 좋지 않은 피드백도 굉장히 감사했어요. 사실 유저 입장에서 그냥 지워버리면 그만인건데, 우리 앱의 장점을 알아봐주시고, 개선할 점을 말해주시고 또 기다려주시는 거잖아요. 그런 유저분들 보면서 빨리 개선해드리고 싶단 생각이 들죠. 그 어떤 피드백보다 더 큰 동기부여가 되더라고요.✓ 투데잇 TALK“투데잇팀은 서로 부담없이 정말 효율적으로 커뮤니케이션을 해서 어떻게 하면 서로의 업무 컨텍스트를 빠르게 마무리할지 고민해요.”Q. 투데잇의 힘은 이거다!음 투데잇의 힘은 서로를 존중하고 커뮤니케이션을 중시하는 데에서 나오는 것 같아요. 결국 모든 문제의 결착점은 커뮤니케이션이거든요. 사소한 거라도 시기에 맞춰서 커뮤니케이션이 되어야 하는데, 개발팀과 비개발팀간의 커뮤니케이션이 사실 어렵잖아요. 하지만 투데잇팀은 서로 부담없이 정말 효율적으로 커뮤니케이션을 해서 어떻게 하면 서로의 업무 컨텍스트를 빠르게 마무리할지 고민해요. 누군가 못한 부분이 있더라도 절대 무시하지 않고, 서로의 업무를 존중하고 정식적으로 피드백을 공유하면서 문제를 잘 해결하기 위한 고민을 하죠.Q. 투데잇에서 제일 기억에 남는 순간이 있다면?투데잇에서는 많이 힘들었을 때부터 행복했을 때 그리고 소소한 일상들까지 전부 다 기억에 남아요. 워크샵이라고 가평에 가서 일한 적이 있었는데, 정말 놀지도 못하고 거의 일만했거든요. 근데 밖에 나와서 그런지 그 자체가 너무 재밌었어요. 일하면서도 되게 색다르고 즐거웠죠. (웃음) 제주도로 워크샵 갔을 때도 너무 재미있었고, 정말 매일 매순간이 기억에 남아요. 팀 분위기가 너무 좋아서 그런지 특별한 일들 뿐만 아니라 개발팀 회의할 때나 회사 메신저에서 웃고 떠들고 했던 것들처럼 아주 소소한 일상들까지 모두 에피소드였던 것 같아요. 깜짝 생일파티도 그렇고 되게 예정없이 나온 에피소드가 많았거 든요. 그런게 진짜 참된 에피소드 아닐까요?✓ 마지막으로…Q. 애정이 컸던 만큼 투데잇을 떠나기 많이 아쉬울 것 같아요.네 많이 아쉽죠. 전 투데잇에서 10개월 동안 정말 하루종일 개발만 했어요. 일 하는 게 너무 좋아서 거의 자취하다시피 야근도 매일 했었거든요. 좋아하는 사람과 좋은 분위기에서 재밌게 일하기도 했고, 또 어떤 목표를 이루기 위해 정말 치열하게 고민하고 일할 수 있었는데 이 부분들을 더이상 느끼지 못한다는 점이 많이 아쉬워요.음 아쉬운 사건을 말하라면, 맨 처음으로 앱 안에 코틀린을 적용해볼 때 너무 시간을 오래 끌었던 일이 있었어요. 잘 적용시킬 방법에 대해 혼자 고민하고 정리해보다가 늦어졌었는데, 다른 분들 일정에 피해를 준데다가 실수도 한두개가 아니었거든요. 그 때 제가 계획대로 잘 처리했으면 마케팅적으로나 여러 시도들을 해볼 수 있지 않았을까?하는 아쉬움이 들죠. 결국 개발자가 세운 일정에서 해내는 여부에 따라 회사에 큰 영향이 가고, 다른 팀에도 막대한 영향이 갈 수 있다는 걸 뼈저리게 깨달았어요. 그래도 이 사건 덕분에 업무적으로도 많이 성장할 수 있었던 것 같아요. 몸소 당해봤으니 그럴 수 밖에 없죠. (웃음)Q. 투데잇을 떠나며 마지막으로 하고 싶은 말이 있다면?“충분히 치열하게 일했고 다함께 즐겁게 소통하면서 일했기 때문에 언젠가 또 다시 만나지 않을까 싶어요.”개인적으로 아쉬운 점은 있지만, 충분히 치열하게 일했고 다함께 즐겁게 소통하면서 일했기 때문에 언젠가 또 다시 만나지 않을까 싶어요. 모든 투데잇 사람들과 연을 이어가고 싶기도 하고 특히 대표님께 보답하고 싶다는 마음이 크거든요. 처음 들어갔을 때, 아무 준비 안 돼있는 상태였던 절 믿어주시고 함께 일할 수 있는 기회를 주셨어요. 앞서 말한 것처럼 일하면서 초반에 실수도 많이 했는데 꾸준히 믿고 지금의 포지션까지 저를 밀어주셨다는 점이 너무 감사하거든요. 대표님께 보답하자! 투데잇에 보답하자!가 마지막으로 하고 싶은 말이에요. 저 나가더라도 아는 척해주셔야 해요..!Q. 투데잇을 꿈꾸는 개발자에게 한마디!음 투데잇에 들어오는 건 어쩌면 쉬울 수도 있어요. 저 같은 경우 30분 정도 면접을 보고 당일에 바로 함께하기로 했거든요. 하지만 중요한 건 본인이 ‘함께 성장하고 싶은 사람’인가?에 대해 생각해보셔야 해요. 또 투데잇과 방향성이 맞는지 스스로 생각해보고, 성장하기 위해선 어떤 태세를 취해야 하는지 고민해보아야 하죠. 만약 이런 성향이 맞지 않는 사람이라면 아마 들어오시더라도 투데잇과 잘 맞지 않아서 힘들 수도 있거든요. 투데잇에 들어오고 싶은 분들은 이런 부분들에 대해 한 번 깊게 고민해보셨으면 좋겠어요.#투데잇 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #개발자 #개발팀
조회수 1263

클라우드와 운영자의 불안함.

2018년은 정말 클라우드가 일반화되는 해가 될듯 합니다. 클라우드 이전 사업 소식이 이곳저곳에서 들리는 요즘입니다. 스타트업 생태계는 이미 클라우드로 넘어갔지만 올해에는 엔터프라이즈 기업에서 대규모 IT 기업들까지 모두 클라우드로 넘어가고 있습니다. 와탭이 클라우드 최적화를 목표로 하는 모니터링 서비스이다보니 클라우드로 전환하는 시점에 있는 많은 기업들을 만나는데요. 클라우드를 적용하려고 준비중이거나 최근 클라우드로 이전한 기업의 운영팀들은 현업에서 사용하는 과정에서 클라우드 안정성에 대한 불안을 토로하기도 합니다. IT 운영자들이 느끼는 클라우드에 대한 불안감IT 운영의 핵심은 안정화입니다. 클라우드 이전까지 IT 인프라는 변화를 관리하는 대상이 아니였습니다. IT 인프라는 운영중에 변화하지 않으며 초기 설계에서도 최대 부하를 견디기에 충분한 여지를 남겨서 구성하였습니다. 하지만 클라우드에서는 IT 인프라가 운영중에도 변화 가능한 요소가 되면서 IT 인프라 규모 산정에서 부터 커다란 변화가 발생합니다. 최대 부하가 아닌 최소 부하가 규모 산정 기준이 되다. 여지껏 IT 인프라의 구성 기준은 언제나 최대 부하를 견딜수 있도록 설계되어왔습니다. 하지만 IT 인프라를 클라우드로 시작한 스타트업들이 IT 인프라를 구성하는 방법은 기존의 규칙을 무시하기 시작합니다. IT 인프라를 규모를 최소 부하에 맞춰서 구성하는 것입니다. 단지 실시간으로 확장 가능한 서비스 구조와 Auto Scailing을 통해 규모를 맞춰갑니다.IT 인프라 평균 부하의 기준이 높아지다. 클라우드 이전까지 우리는 IT 인프라의 CPU 부하율을 평소 20% 아래로 유지해 왔습니다. 하지만 이 또한 변화가 생깁니다. 제가 만나는 많은 클라우드 기반 서비스 기업들이 CPU 부하율을 50%에서 70%까지 유지하고 있었습니다. 일반적은 운영관점에서 IT 서비스 운영에 익숙하지 않은 기업의 운영 미숙이라 생각할 수 있습니다. 하지만 클라우드에 익숙한 운영팀은 서비스 성능에 문제가 발생하지 않는 범위에서 인프라의 규모를 실시간으로 조절합니다. 기존의 상식으로는 매우 위험해 보이지만 클라우드를 정말 잘 쓰는 기업들은 성능과 안정성을 해치지 않으면서 인프라 자원의 여유를 최대한 줄이는 방법들을 내재화하고 있습니다. IT 인프라 장애를 해결하지 않는다.  모든 IT 인프라는 장애가 발생합니다. 인프라의 장애는 이벤트성으로 발생하지만 운영팀은 장애를 반복 해결해 나가는 과정에서 패턴을 인지하고 대처해 나갑니다. 클라우드에서도 장애는 어쩔수 없이 발생하지만 운영팀은 장애를 인지할 뿐 장애를 물리적으로 해결하지는 않습니다. 대신 클라우드를 사용하는 IT 운영팀은 빠르게 서비스 구성과 환경을 전환하여 서비스를 원활하게 동작시킵니다. 운영자들이 갖는 불안감이 현실이 되다.다시 운영자들의 불안감에 대해서 이야기 해보죠. IT 인프라의 규모를 줄이고 자원 사용률이 평소에서 50%를 넘기는 급박한 사용 환경에서 클라우드 인프라에 장애가 발생해도 할 수 있는 일이 없다는 것은 정말 큰 스트레스를 주는 일입니다. 물론 위에서 설명한 것처럼 클라우드 네이티브한 서비스라면 문제없이 돌아갈 수 있겠지만 기존 레거시를 운영하면서 클라우드로 전환한다면 IT 운영자 입장에서는 앞에 이슈들이 불안감이 아닌 현실이 됩니다. 넷플릭스 7년만에 클라우드 이전을 완료하다.넷플릭스가 클라우드 이전을 결정한것은 2007년이지만 이전을 완료한것은 2016년이였습니다. 이렇게 긴 시간은 투자한 이유에 대해 넷플릭스는 "기존 IDC 기반의 인프라가 가진 문제들을 클라우드로 가져가지 않기 위해서"라고 했지만 다른 한편으로는 클라우드에서 발생하는 문제들을 해결할 수 있는 시스템 구조를 만들기 위해서였습니다. 그렇기 때문에 넷플릭스에서는 클라우드 네이티브 방식을 택하여 사실상 모든 기술을 재구축하고 운영 방식을 근본적으로 바꿨다. 아키텍처 면에서 넷플릭스는 거대한 앱을 수백 개의 마이크로 서비스로 마이그레이션하고 NoSQL 데이터베이스를 사용하여 데이터 모델을 반정규화했다. 예산 승인, 중앙화된 릴리스 관리, 몇 주에 걸친 하드웨어 프로비저닝 주기를 도입해 지속적인 콘텐츠 전달이 가능해졌으며, 느슨하게 결합된 개발운영(DevOps) 환경에서 엔지니어링 팀이 셀프서비스 툴로 독립적인 결정을 내릴 수 있게 되면서 혁신이 가속화되었다. 이 과정에서 새로운 시스템을 여럿 구축해야 했으며, 새로운 기술도 배워야 했다. 넷플릭스가 클라우드 네이티브 기업으로 변신하는 데는 많은 시간과 노력이 필요했지만, 클라우드 마이그레이션을 통해 글로벌 TV 네트워크로서 지속적인 성장을 이뤄나갈 밑거름을 마련할 수 있었다.https://media.netflix.com/ko/company-blog/completing-the-netflix-cloud-migration결론기존의 레거시를 바탕으로 클라우드 마이그레이션을 진행하는 기업들은 클라우드에서 발생하는 다양한 운영 이슈들을 겪을 수 밖에 없습니다. 대부분 클라우드 이전 사업을 진행하는 데 있어서 이전 서비스 성능을 맞추는 데만 집중하다보니 이전 후 운영과정에서 발생하는 많은 문제들은 운영팀이 짊어지게 됩니다. 하지만 이 문제들은 개발팀과 운영팀이 함께 지속적으로 개선해 나가야 합니다. 최종적으로 클라우드 네이티브 구조가 완성되기 위해서는 시스템과 조직 문화 모두가 변화해야 합니다. 클라우드 마이그레이션은 엄청 고난한 일입니다. 만일 클라우드를 도입했는데, 아직 불안함이 있다면 아직 클라우드 마이그레이션이 끝나지 않은것입니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 2278

프로세스 마이닝과 AI를 통한 프로세스 혁신

지난해 이세돌과 알파고의 대결 이후에 인공 지능 (AI)과 기계 학습은 국내에서 많은 대중들의 관심을 얻어 중요한 추진력을 얻었으며, 모든 산업 분야의 기업들이 해당 기술을 빠른 속도로 계속 적용하여 사용하는 비중이 더욱 높아졌습니다. 실제로 Gartner는 2022년까지 스마트 머신과 로봇이 고학년 전문직 분야를 대체할 수 있을 것으로 내다봤으며, 심지어는 인공지능이 경영자 CEO도 대체 가능할 것인지에 대한 논의도 일어나고 있습니다. 이것은 사람이 과거 경험에 의해서 의사 결정을 내리 듯이 인공 지능도 확보한 데이터를 기반으로 의사 결정 모델을 만들 수 있다는 유사성에 기반합니다.  인공 지능에 의한 의사 결정은 사람한테 종종 있을 수 있는 감정이나 개인적 이해관계 및 관례에 의해 불합리한 판단에서 벗어나 데이터의 의한 객관적 판단을 할 수 있다는 장점이 있습니다.여기서 중요한 것은 인공지능이 학습하기 위한 “데이터”입니다.  지금까지 머신러닝이 막대한 이미지, 음성, 영상 데이터를 축적한 후 해당 데이터의 특징을 추출하여 패턴을 학습하여 자연어 처리 등을 통해 사람처럼 인식하여 분류하거나 상황을 판단하였듯이 기업 내 여러 가지 업무 활동에 머신 러닝을 적용하기 위해서는 이와 마찬가지로 관련 데이터가 필요합니다.제조 분야의 공정 관리, 공공 서비스, 물류 공급망 관리 등 전통적인 기업 내 업무 프로세스는 인공 지능에 의한 자동화과 효율화를 통해 혁신이 필요한 분야입니다. 기존에 외부 협력 업체로부터의 납기 예측, 소요되는 자재 인력 등 리소스 산정, 생산 스케줄, 장비 파라미터 입력값 등은 사람에 의해 수작업으로 진행 시 몇 주에서 수개월 소요되었지만, 인공 지능과 기계 학습 기반의 솔루션 도움으로 정확하게 지속적인 추세를 인식하고 인간의 개입 없이 데이터 중심의 결정이 가능해집니다.지금까지 기업 내 축적된 엄청난 양의 데이터를 활용하여 여러 산업 분야에서 숨겨진 패턴과 상관관계, 이상 징후 및 불량 탐지, 고객 수요 예측 등이 시도되었습니다. 하지만 이러한 시도들은 기업 내 문제 요인을 파악하여 우선적으로 어떤 부분에 초점을 맞추어 개선을 해야 하는지 알아야 하므로, 기업 경영 활동 전반에 걸쳐 돌아가는 판세를 읽는 노력이 필요합니다. 하지만, 기업 내에서 이뤄지고 있는 프로세스는 충분히 복잡하여, 개별 단위 작업의 전문가들은 존재하겠지만, 각 개별 부서, 구성원, 시스템 간에서 발생하는 다양한 상호작용과 이에 따른 예외 상황이 존재하여 이를 파악하기가 쉽지 않습니다.프로세스 마이닝은 데이터 기반의 프로세스 분석을 통해 문제 부분을 파악하여, 실제 인공 지능이나 머신 러닝을 적용하여 개선할 부분을 찾을 수 있도록 도와줍니다. 그리고, 프로세스 개선을 위해 머신러닝을 적용하기 위해서는 앞서 말한 것처럼 “데이터”가 학습될 수 있는 형태의 기반을 제공합니다.아래 그림과 같이 이벤트 로그를 기반으로 프로세스 모델을 생성하고, 수집된 패턴들과 각 분기 단계에서의 주요 성과 지표들을 디지털화하여 인공지능이 이해할 수 있는 형태로 축적합니다 이렇게 축적된 프로세스 패턴 데이터를 가지고 알파고가 최적화된 다음의 한 수를 예측하듯이 프로세스 마이닝은 인공 지능 기술과 결합하여 과거 프로세스에 대한 이해뿐만 아니라, 현재 시점에서 앞으로의 프로세스를 예측하여 합리적인 의사 결정을 도와줄 것입니다.#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트
조회수 3095

iOS 아키텍처 패턴(MVC, MVVM, VIPER)

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
조회수 5462

REST 아키텍처를 훌륭하게 적용하기 위한 몇 가지 디자인 팁

최근의 서비스/애플리케이션의 개발 흐름은 멀티 플랫폼, 멀티 디바이스 시대로 넘어와 있습니다. 단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응해야 합니다. 그렇기 때문에 매번 서버를 새로 만드는 수고를 들이지 않기 위해선 범용적인 사용성을 보장하는 서버 디자인이 필요합니다.REST 아키텍처는 Hypermedia API의 기본을 충실히 이행하여 만들고자 하는 시스템의 디자인 기준을 명확히 확립하고 범용성을 보장하게 해줍니다. 이번 글에선 현대 서비스 디자인을 RESTful하게 설계하는 기초적인 내용에 대해 정리하려고 합니다.REST란 무엇인가?REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍처스타일입니다. 2000년에 Roy Fielding에 의해 처음 용어가 사용되었는데, 이 분은 HTTP/1.0, 1.1 스펙 작성에 참여했었고 아파치 HTTP 서버 프로젝트의 공동설립자이기도 합니다.REST는 HTTP/1.1 스펙과 동시에 만들어졌는데, HTTP 프로토콜을 정확히 의도에 맞게 활용하여 디자인하게 유도하고 있기 때문에 디자인 기준이 명확해지며, 의미적인 범용성을 지니므로 중간 계층의 컴포넌트들이 서비스를 최적화하는 데 도움이 됩니다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.” 라고 흔히 표현합니다.무엇보다 이렇게 잘 디자인된 API는 서비스가 여러 플랫폼을 지원해야 할 때, 혹은 API로서 공개되어야 할 때, 설명을 간결하게 해주며 여러 가지 문제 상황을 지혜롭게 해결하기 때문에 (버전, 포맷/언어 선택과 같은) REST는 최근의 모바일, 웹 서비스 아키텍처로서 아주 중요한 역할을 하고 있습니다.중심 규칙REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지입니다.URI는 정보의 자원을 표현해야 한다.자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.1번 사용자에 대해 정보를 받아야 할 때를 예를 들면, 아래와 같은 방법은 좋지 않습니다.GET /users/show/1 이와 같은 URI 방식은 REST를 제대로 적용하지 않은 구 버전의 Rails에서 흔히 볼 수 있는 URL입니다. 이 URI은 자원을 표현해야 하는 URI에 /show/ 같은 불필요한 표현이 들어가 있기 때문에 적절하지 않습니다. 본다는 것은 GET이라는 HTTP Method로 충분히 표현할 수 있기 때문이죠. 최근의 Rails는 아래와 같이 변경되었습니다.GET /users/1 자원은 크게 Collection과 Element로 나누어 표현할 수 있으며, 아래 테이블에 기초한다면 서버 대부분과의 통신 행태를 표현할 수 있습니다.ResourceGETPUTPOSTDELETERESTful Web Service HTTP methodsCollection URI, such as http://example.com/resources/컬렉션에 속한 자원들의 URI나 그 상세사항의 목록을 보여준다.전체 컬렉션은 다른 컬렉션으로 교체한다.해당 컬렉션에 속하는 새로운 자원을 생성한다. 자원의 URI는 시스템에 의해 할당된다.전체 컬렉션을 삭제한다.Element URI, such as http://example.com/resources/item17요청한 컬렉션 내 자원을 반환한다.해당 자원을 수정한다.해당 자원에 귀속되는 새로운 자원을 생성한다.해당 컬렉션내 자원을 삭제한다.이 외에도 PATCH 라는 HTTP Method에도 주목하시기 바랍니다. PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있습니다. Rails도 4.0부터 PATCH가 update 이벤트의 기본 Method로 사용될 것이라 예고하고 있습니다.입력 Form은 어떻게 받아오게 하지?위의 예시를 통해 많은 행태를 표현할 수 있습니다만 새로운 아이템을 작성하거나 기존의 아이템을 수정할 때 작성/수정 Form은 어떻게 제공할지에 대한 의문을 초기에 많이 가집니다.정답은 Form 자체도 정보로 취급해야 한다는 것입니다. 서버로부터 “새로운 아이템을 작성하기 위한 Form을 GET한다”고 생각하시면 됩니다. Rails 에선 기본적인 CRUD를 제공할 때 아래와 같은 REST 인터페이스를 구성해줍니다.HTTPVerbPathactionused forGET/photosindexdisplay a list of all photosGET/photos/newnewreturn an HTML form for creating a new photoPOST/photoscreatecreate a new photoGET/photos/:idshowdisplay a specific photoGET/photos/:id/editeditreturn an HTML form for editing a photoPUT/photos/:idupdateupdate a specific photoDELETE/photos/:iddestroydelete a specific photo모바일 환경에 따라 다른 정보를 보여줘야 한다면?접속하는 환경에 따라 다른 정보를 보여줘야 할 때가 있습니다. 가령 모바일 디바이스에서 볼 때 다른 사용자 인터페이스를 제공한다든지 하는 경우인데요. 일부 애플리케이션은 독립적인 모바일 웹서비스를 개발한 후 단지 이를 이동시켜주기만 할 때가 있는데, 이는 어떤 경우에 좋지 못한 사용성을 보여줍니다. 모바일 뷰와 일반 웹페이지 뷰의 URI가 달라서 같은 정보를 공유할 때 각 환경에 적절한 디자인과 인터페이스로 보이지 않기 때문입니다.모바일에서 블로그를 구경하던 도중, 컴퓨터를 이용하고 있는 친구에게 자신이 보고 있는 내용을 보내주고 싶을 때가 있습니다. 티스토리 블로그는 모바일 뷰의 URI가 기존 URI와 달라서, 친구가 해당 URI를 데스크탑에서 열어도 모바일에 최적화된 정보를 받을 수밖에 없게 됩니다. 이 URI를 데스크탑에서 열어보시기 바랍니다.REST 하게 만든다면 URI는 플랫폼 중립적이어야 하며, 정보를 보여줄 때 여러 플랫폼을 구별해야 한다면 Request Header의 User-Agent 값을 참조하는 것이 좋습니다. 예를 들어 iPhone에서 보내주는 User-Agent 값은 아래와 같습니다.Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 대부분 브라우저, OS 플랫폼은 HTTP Request를 보낼 시 보내는 주체에 대한 설명을 User-Agent에 상세하게 포함하여 통신하고 있기 때문에 요청자의 환경을 정확히 알 수 있습니다.버전과 정보 포맷을 지정할 수 있게 해야 한다면?오픈 API를 제공하거나, 클라이언트가 항상 최신 버전을 유지할 수 없는 환경이라면 서버에서 버전 협상을 지원해야 합니다. 서버가 버전 협상을 지원한다면 최신 버전으로 업데이트가 되더라도 구 버전의 정보 요청에 하위 호환하게 하여 서비스 적용범위를 넓게 유지할 수 있습니다. 이와 함께 클라이언트가 html로 정보를 받을지, json으로 받을지, xml로 받을지 선택할 수 있다면 더욱 좋을 것입니다.Header의 Accept 헤더를 이용해서 요청 환경에서 정보의 버전과 포맷을 지정할 수 있게 합니다. 아래는 Github API에 요청 시 쓰는 Accept 헤더입니다.application/vnd.github+json vnd.는 Vendor MIME Type으로, 서비스 개발자가 자신의 독자적인 포맷을 규정할 수 있게 HTTP 표준에서 제공하는 접두어입니다. vnd. 이후에 서비스 제공자 이름을 쓴 후, +로 문서의 기본 포맷을 표현해줍니다.이에 더해, Accept 헤더는 파라미터를 받을 수 있습니다. 많은 REST 지지자들은 이 파라미터를 이용해 버전 명을 지정하는 것을 권장합니다.vnd.example-com.foo+json; version=1.0 Ajax와 REST최근 빠른 속도의 웹서비스를 구현하기 위해 서비스 전체를 Ajax 통신으로 구동되게끔 HTML5 애플리케이션을 만드는 일이 많습니다. 서비스 전체를 Ajax 기반으로 구동되게 개발한다면 중복된 콘텐츠를 여러 번 전달하지 않아도 되고, 브라우저 렌더링 과정이 간소화되므로 더욱 빠른 서비스를 구축할 수 있습니다. 하지만 Ajax 기반의 서비스는 초기에 URL에 관련된 문제가 있어 REST한 서비스를 만들 때 애로사항이 있었습니다. 콘텐츠가 바뀌어도 URL은 그대로여서 친구에게 내가 보고 있는 콘텐츠를 보여줄 방법이 불편했기 때문이죠.최근엔 두 가지 방법으로 이를 보완할 수 있습니다. 첫 번째는 #! 기법으로, 구형 브라우저에서도 # 이하의 URL을 Javascript로 자유자재로 변경할 수 있다는 점을 이용한 방법입니다. 방법은 아래와 같습니다.Ajax 통신을 통해 이동되는 페이지의 URI는 현재 URI의 #! 이후에 붙인다.페이지가 처음 열릴 때, #! 이후로 URI가 붙어있다면 해당 URI로 redirect를 해준다.이와 같은 방법으로 Ajax 서비스를 만들면, 페이지를 이동한 이후에 URL을 친구에게 복사해서 전달해주어도 친구가 내가 보고 있는 콘텐츠를 볼 수 있으며, 구글에서 수집할 때 해당 #! 이하의 URL을 판별해서 제대로 수집해주기 때문에 검색엔진에도 성공적으로 노출될 수 있습니다.하지만 위 방법의 단점은 1. 상대방이 Javascript를 지원하지 않는 브라우저를 이용하거나 Javascript 기능을 꺼 놓았을 때 제대로 된 콘텐츠를 볼 수 없다는 것이며, 2. URI가 몹시 보기 지저분해진다는 것입니다. 두 번째 방법은 pushState라는 새로운 표준을 이용한 방법으로, javascript의 pushState를 통해 Ajax 통신 후에 변경된 컨텐츠의 URI을 제대로 바꿔줄 수 있습니다. 하지만 최신 표준을 지원하는 브라우저에서만 정상적으로 구동되기 때문에, 하위 호환에 신경을 써야 한다는 단점이 있습니다. pjax같은 프로젝트들이 하위 호환을 포함하여 이런 구현을 쉽게 하도록 도와주고 있습니다.언어언어별로 다른 URI의 서비스를 가지는 서비스들을 종종 볼 수 있습니다. 역시 좋지 못한 설계입니다. 한국어로 작성된 컨텐츠를 보고 있는 중 해당 콘텐츠를 미국인 친구에게 보여줄 일이 생겼다고 가정해봅시다. 단순히 URI를 복사해서 주는 것으로는 미국인 친구에게 내가 보고 있는 정보를 제대로 전달해줄 수 없다면 아주 불편할 것입니다.Request Header의 Accept-Language는 받고자 하는 언어를 명시하고 있습니다. 대부분 브라우저, OS 플랫폼은 사용자가 즐겨 쓰는 언어를 이 Header에 포함하여 요청을 만들고 있기 때문에, 해당 Header를 참조하여 그에 걸맞은 언어를 제공해주는 것이 가장 정확한 서비스를 제공해줄 수 있습니다.물론 이 방법만으로 부족한 점이 있습니다. 자신의 주 언어와 다른 언어의 세팅을 가지고 서비스를 이용하는 사용자도 있으며, 몇 가지 이유 때문에 해당 사이트만, 해당 순간에만 다른 언어로 정해서 보고 싶을 수 있기 때문입니다. 아쉽게도 일반적인 브라우저에서 언어 변경을 하는 인터페이스는 매우 불편하고 찾기 어렵게 되어있기 때문에, 서비스에서 이에 대한 추가 인터페이스를 제공해주지 않으면 일부 사용자를 잃거나 불편하게 할 수 있습니다. 보통은 Accept-Language보다 우선해서 적용하는 언어 옵션을 세션에 저장할 수 있게 하고, 이에 대한 변경 인터페이스를 서비스에서 제공해주는 식으로 문제를 해결할 수 있습니다.마치며REST는 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해주고, HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다. 이번 글에서는 REST하지 않은 서버 설계를 통해 생길 수 있는 실질적인 문제들을 제시하고 REST 아키텍처가 이를 어떻게 해결해주는지 함께 보았습니다.‘REST가 완전한 정답이냐?’라고 한다면 이에 대해서는 아직 논의가 남아있습니다. 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 분명히 있으며 (PUT, DELETE를 사용하지 못하는 점, pushState를 지원하지 않는 점) 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값은 왠지 더 어렵게 느껴지기도 합니다.만일, 만들고 있는 서비스의 API가 널리 쓰여야 한다면 REST를 완전하게 적용한 디자인이 더 독이 될 수 있습니다. 많은 개발자는 별로 똑똑하지 못하며, HTTP 프로토콜에 대한 이해가 부족하여서 API가 어렵게 느껴질 수 있기 때문입니다. 그러므로 Google을 포함한 많은 기업의 서비스 API가 REST 스타일을 완전히 따르고 있진 않습니다.하지만 그럼에도 REST가 중요한 점은, 이를 제대로 구현하는 것이 서비스 디자인에 큰 부가이익을 가져다 줄 수 있으며, 많은 현대의 API들이 REST를 어느 정도로 충실하게 반영하느냐를 고민할 뿐이지 REST를 중심으로 디자인되고 있다는 점은 분명하기 때문입니다. REST를 얼마나 반영할 지는 API가 어떤 개발자를 범위에 두는지, 개발 기간이 얼마나 되는지, 함께 하는 동료의 역량은 어떠한지 등을 고려해서 집단마다 다르게 반영하게 될 것입니다.#스포카 #개발 #개발자 #개발팀 #꿀팁 #인사이트 #REST
조회수 1859

우리는 비정상인걸까?

필자는 스팀헌트라는 스팀 블록체인 기반 댑 프로젝트를 진행하고 있다. 스타트업을 하면서 저마다의 관점과 철학이 다른 문제이겠으나, 내가 지금까지 약 1년간 경험해본 이놈의 "블록체인"이라는 업계는 뭔가 정상적이지 않다. 그간 나름 "스타트업"이라는 업계 전반의 경험에 비추어 봤을때 이바닥 관행들이 뭐가 내게는 비정상적으로 보이는지 간략히 살펴보면 다음과 같다.1.대부분의 "블록체인" 태그를 달고 나오는 프로젝트들은 가장 처음 하는 일이 펀딩이다. 아직 제품은 커녕 그냥 프로젝트 소개하는 랜딩페이지에 수십명의 팀원, 어드바이저 리스트, 현실성이 있을까 싶은 각종 기업 로고들이 파트너사로 나열되어 있다.2.그들에게 "제품"이란 마치 수십 수백페이지의 엄청난 공을 들인 "화이트페이퍼"인듯 하다. 왜냐하면 위에서 얘기한 랜딩페이지 맨 위에 항상 가장 대문짝 만한 자리를 차지하고, 이미 3개국어는 기본, 5개국어 버전까지 준비해 놨기 때문이다.3.이런 제품도 없고 요상한 랜딩페이지만 있는 프로젝트들이 수십, 수백억의 ICO, IEO, 프라이빗 세일 등등의 단어로 치장된 "토큰 세일"을 진행한다. 이들이 초기에 들이는 자원중 99% 이상은 카톡방 관리, 텔레그램방 관리, 코인판 (사이트 이름이다) 마케팅, 각종 밋업, 컨퍼런스 참여, 유투버들 마케팅 등등이다. 물론 이런 행동들은 성공적인 펀딩을 위해 필요한 일들이긴 하다. 다만, 일반적인 스타트업이라면 초기에 99%의 자원이 제품과 유저들에게 쏟아야 마땅한 단계에 그게 아니라는게 내겐 비정상적인걸로 보일 뿐.4.아직 제품도 없는 팀이 팀원 리스트를 꾸린걸 보면 거의 중견급 스타트업 레벨이다. 아직 유저도 없고 비즈니스도 없는 팀이 CEO, CTO, CMO, CSO, C.... 레벨이 5명은 기본, 개발자 5-6명을 리스트에 박아놓는다. 일반적인 스타트업에서는 MVP가 어느정도 검증되고 나서 스케일을 낼때 하는 일들이다. 마치 삽도 뜨기 전에 삽질할 사람들 수십명을 모아놓은 그림이다. 이 중 십중팔구는 삽을 뜨려고 보니 땅바닥이 콘크리트 바닥이라 팔 수가 없거나, 애초에 팔 의지도 없었던게 대부분이지만...5.어드바이저 리스트... 내가 가장 요상하게 여기던 관행인데, 어느 프로젝트를 들어가도 이력이 화려해 보이는 어드바이저들 5명 이상은 기본으로 갖고 들어가더라. 내가 맨 처음 이바닥 들어갈때는 나름 "뭐, 아무도 가본 길이 아니니 조언해줄 사람들이 많이 필요할수도 있겠지.."라고 착각했었다. 알고보니, 그들은 그저 위에 자리를 채워주는 역할과 아주 약간의 투자자+거래소 인맥을 소개시켜주는 역할을 하는 사람들이더라. 이렇게 이름만 팔아주고 대부분 총 발행량의 0.5 ~ 2, 3%까지 토큰을 받아가는데, 대부분 상장과 함께 가장 먼저 덤핑될 토큰들이라는게 업계의 공통된 시각이다. 사실, 이 바닥이 그리 넓지 않아서 거래소 인맥 소개시켜주는건 인맥이 넓으신 1-2명으로도 충분히 커버 가능하다. 아예 제대로된 엑셀러레이터 들어가면 그들이 백배는 더 전문적으로 잘 해주는 영역이기도 하다. 아무리 생각해도 삽도 안떠본 스타트업이 저 많은 어드바이저 리스트를 꾸려야 할 이유를 지금도 못찾았고, 앞으로도 모를것 같다.6.지금이야 STO니 해서 증권형 토큰들이 하나둘씩 나오지만, ICO하는 대부분의 코인들은 본인들이 "유틸리티" 코인이라고 주장한다. 뭐, 토큰 모델 디자인상 유틸리티 토큰일 수 있다. 그런데 문제는, 이를 배포할 때 초기 토큰 홀더들은 100% "투자자"라는데에 있다. 그들이 주장하는 토큰의 유틸리티, 유저 페르소나와 1도 관계 없는 사람들이 대부분 토큰을 갖게 되고, 시장 상장 후 차익 실현을 위해 보유하는 경우가 거의 백프로다. 마치 사탕 사먹으라고 발행한 백원짜리 동전을 손에 쥔 백명의 사람들이 사실 사탕 사먹으려는게 아니고 모두 이백원, 삼백원에 팔기위해 손에 쥐고 있는것과 같은 논리다. 이러니, "유틸리티" 토큰이라는게 작동할리가 없다.7.백서... 어드바이저와 함께 내가 가장 요상하게 여기는거다. 대부분의 프로젝트가 삽도 뜨기 전에 수십, 수백장짜리의 백서부터 쓴다. 읽어보면 완전 세상을 바꿀 의지가 넘쳐 흐르는 철학적 도입부 + 본인들의 기술이 세상에 없던, 혹은 현존하는 기술은 거의 쓰레기 수준이라는 설명 + 삽도 떠본적 없는데 3-5개년 중장기 계획이 세워져 있고, 3년후에는 이미 이 시장을 평정해 있는 이야기들로 점철되어 있다. 제품도 없고 유저도 없는 상태에서 쓰여지는 수십페이지짜리 백서라는건, 그냥 대학교에서 팀플 리포트 A학점정도 맞을 만큼 잘 써진 그냥 소설 페이퍼정도인데, 이걸 무슨 신주단지마냥 만들어서 돌리는지 도무지 이해할수가 없다.8.투자자 생태계가 진짜 엄청나게 요상하게 꾸려져 있다. 일반적인 스타트업에서 보통 시드펀딩을 위해 VC들을 만나보면, 그들은 이 제품이 진짜 어떤 문제를 해결중인건지, 그 문제 해결에 열광하는 유저들이 얼마나 존재하는지, 이게 스케일이 가능한 형태인지, 스케일 했을때 시장규모가 얼마나 될건지, 이놈들이 그중 얼마나 먹을 수 있는 팀원들인지... 보통 이런걸 본다. 이런걸 봐야 나중에 스케일에 성공해서 엑싯이 되든 상장이 되든 해서 투자 수익을 얻을 수 있기 때문이다. 한편, 이바닥 투자자들이 가장 중요시 여기는 것들을 나열해 보면 다음과 같다.1) 백서가 얼마나 있어빌리티하게 작성되어 있는지 (본인들이 잘 모르는 개념들이 잔뜩 들어가 있을수록 높은 점수를 받는다)2) 흥행성 - 이 프로젝트가 얼마나 "호재"를 잘 타서 토큰 가격 펌핑이 가능한 구조인건지. 파트너사들, 각종 MOU, 화려한 이력이 있는 팀, 어드바이저 등등이 보통 활용된다.3) 토큰 분배 - 프라이빗 세일에서 디스카운트 먹은 투자자들 규모가 얼마나 되는지, 팀/어드바이저들은 얼마를 던질 준비가 되어 있는지4) 토큰 상장 - 소위 "대형" 거래소에 처음부터 상장될건지, 얼마나 많은 거래소에서 유통될건지...이 어디에도 "제품"이나 "유저"와 관련된 내용은 하나도 없다. 즉, 투자자들이 진짜 그들 제품의 성공 가능성에 대해 점쳐보며 투자할 분위기도, 그럴 생태계도 아닌게 이 판이다.9.원래 비트코인도, 이더리움도, 이런 탈중앙화 퍼블릭 블록체인 프로젝트의 강점은 오픈소스 프로젝트라는데에 있다. 모든 소스코드가 깃헙에 투명하게 공개되어 있고, 누구나 개발에 기여할 수 있다. 그런데, 이 후에 쏟아진 수 많은 블록체인 프로젝트들이 개발이 이루어지지 않거나, 본인들 소스코드는 비공개라고 하는 경우가 허다하다. 심지어 깃헙 링크가 아예 없는 프로젝트도 수두룩 하다.10.글로벌 프로젝트라는데 물론 아직 "글로벌" 유저도 없고, 레딧이나 트위터 등의 활동도 전무하고, 공식 커뮤니케이션 채널은 카카오톡 오픈챗이나 텔레그램 채널이란다. 가끔 싱가포르나 어디 글로벌 컨퍼런스에서 머리 노란 사람들과 사진 몇방 찍고 이걸 블로그나 신문기사로 찍어내면 글로벌 프로젝트가 되는 분위기다.이렇게 요상한 관행들이 어떤 결과를 가져왔는지 한번 살펴보자. 뭐, 가격 폭락하고 거품 빠지고... 이딴걸 얘기하려는게 아니다. 일반적인 스타트업 업계에 비해 이바닥의 현 성적표가 얼마나 초라한지를 보는거다.1. 전체 ICO의 78% 이상은 스캠으로 판명, 7%는 실패하거나 프로젝트가 사멸하였다 (블룸버그).2. 가장 큰 네트워크 규모를 자랑하는 이더리움 블록체인에서 돌아가는 1,375개의 댑 (DApp - 블록체인에서 돌아가는 앱을 뜻하는 단어)들 중 86%는 유저가 단 한명도 없으며, 93%는 아예 온 체인 트랜잭션이 단 한 건도 발생하지 않은 댑이다 (크립토글로브).3. 이더리움 지갑 보유자 전체의 고작 2%만이 이더리움 댑을 사용하는 유저이다 (dapp.com)4. CoinGecko에 리스팅 되어 있는 전체 4,139개의 프로젝트 중 과거 30일 동안 단 한번이라도 개발 커밋이 이루어진 프로젝트는 단 64개 밖에 없다 (2019년 2월 28일 기준).이걸 스타트업 상황에 비교해서 설명해보면 이렇다.전체 스타트업 중 78%는 사기를 쳤고, 7%는 삽도 못떠보고 망했다. 86%는 유저를 1명도 못만들었고, 93%는 유저는 있는데 유저들의 사용 이력이 1도 없다. 특정 운영체제를 쓰는 스마트폰 보유자들의 고작 2%만이 실제 앱 스토어에서 앱을 다운받아 사용하는 유저이다. 전체 스타트업 중 고작 1.5%만이 과거 30일동안 단 한번이라도 개발 커밋이 이루어졌다. 정말 요상하지 않는가? 그런데 더 충격적인건... 이걸 요상하게 여기는 우리 팀이 더 비정상이라고 보는 이 업계 시각이다. 내가 하는 스팀헌트라는 프로젝트에 대해서는 다음 글에서 상세히 소개할 예정이지만, 우리는 처음에 제품부터 만들어서 유저를 모으고, 가설을 검증하고, 사업모델을 모색하고... 그 다음 펀딩을 추진하는, 지금까지 스타트업에서 있었던 아주 일반적인 트리를 타고 있었다.백서? 물론 없었다. 제품 운영도 안해보고 저런 소설을 내 스스로 쓰는거에 대한 오글거림도 있었고, 솔직히 수만명의 커뮤니티 유저들을 상대하다 보면 그런짓에 시간을 쓸 여유도 없었다.웹사이트에는 그냥 이렇게 끄적여 놨었다...ㅎㅎ그런데, 우리는 아주 일반적인 단계라고 여기며 요즘 펀딩을 준비하고 있는데, 거의 모든 관계자들이 그놈의 "백서"를 요구한다. 제품부터 열어봅시다, 유저부터 한번 봅시다 하고 말꺼내는 사람들이 거짓말 안보태고 10에 1명 찾아볼까 말까였다. 우리도 얼마전까지는 "우린 그런 소설책 쓸 시간이 없어요~~" 이랬었는데... 결국 우리도 백기를 들고 일주일만에 백서를 써버렸다. 근데 사실 써보고 나니, 우린 제품도 1년이나 운영하면서 나름 가설 검증을 많이 해 놓은 단계라 그런지 백서가 쉽게 써지긴 하더라. 로드맵도 3-5년 후 이야기는 있지도 않다. 1년 앞에 어떻게 될지 모르는게 일반적인데 굳이 3-5년후를 쓸 가치를 못느낀다.사실, 위에서 소개한 뭔가 이 바닥에서는 "비정상"처럼 여겨지는 일반적인 스타트업들이 타는 트리를 타고 있는 블록체인 프로젝트들이, 스팀헌트가 만들어진 스팀 블록체인에는 수두룩하게 많다. 아니, 스팀에서는 오히려 위에서처럼 백서만 들고와서 펀딩하는 프로젝트들을 더 까는 경향이 있다.스팀이 코인의 시총만 따지면 40-50위권 수준이라 유명새를 타지 못한 상태이지만, 그 블록체인을 기반으로 움직이는 60여개의 댑들은 이미 실제 유저들을 어마어마하게 거느리고, 이더리움이나 EOS마냥 메타마스크나 스캐터를 깔지 않으면 로그인조차 할 수 없는 상태가 아닌, 일반적인 앱을 쓰는것과 동일한 UX에 모바일에서도 100%로 돌아간다. 코인판의 수 많은 사람들이 거래소에서 pump and dump에만 열을 올리고 있는 사이 스팀에서는 실제 소셜 앱들을 만들기 위한 스타트업 다운 스타트업 생태계가 만들어지고 있던 거다.출처 - https://stateofthedapps.com (2019년 1월 7일 기준)https://stateofthedapps.com라고, 이더리움, EOS등 2,500개 이상의 댑들의 유저수, 트랜젝션을 기반으로 순위를 매기는 공신력 있는 사이트가 있다 (무슨 돈만내면 별점 매겨주는 ICO레이팅 그딴 사이트가 아니다). 거기 차트에 들어가보면 이미 스팀기반 댑들이 상위권을 차지하고 있다. 스팀헌트도 항상 상위 10-20위사이에서 왔다갔다 하면서 최상위권을 유지중이다. 또한, 대부분이 도박, 게임등인 이더리움/EOS와는 달리 스팀기반 댑들은 소셜 서비스라는게 엣지이다. 스팀헌트 역시 테크 얼리어답터들의 "커뮤니티" 플랫폼이다.오늘을 기점으로 다시 브런치 활동을 시작하려고 한다. 내가 직전에 연재하던 시리즈가 "기획돌이의 스타트업 고군분투기"였는데, 이건 일반적인 스타트업에서 좌충우돌하던 깨달음에 대한 글들이였다면, 오늘부터 연재할 글들은 이 "비정상"이 "정상"처럼 여겨지는 블록체인판에서 내가 스팀헌트 프로젝트를 운영하면서 겪게되는 좌충우돌에 대한 이야기들을 소개할 예정이니, 많은 관심과 구독 부탁드린다.글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기
조회수 2581

비트윈 PC 버전 개발기 - VCNC Engineering Blog

 지난 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↩
조회수 2257

왜 차세대 SaaS는 페이스북처럼 될 것인가.  

사람들이 매일 사용하는 서비스 중 가장 유용한 것은 무엇일까?대부분의 경우에 있어, 그것은 Slack, Gmail 혹은 Excel 같은 SaaS 툴이 아닐 것이다. 그것은 바로 페이스북이다.페이스북으로 할 수 있는 모든 것들에 대해 생각해보자.친구들에게 메시지 보내기 영상 통화 하기 뉴스 보기 이벤트 기획하기 사진과 동영상 공유하기사람들은 페이스북에 얼마나 많이 의지하고 있는 지 종종 잊어버리지만, 페이스북은 이미 우리의 일상 생활에 아주 깊숙이 자리잡고 있다. 오늘날에는 수 백만 개의 서비스가 존재하지만, 그들은 그럼에도 만족할 줄을 모른다. 그리고 페이스북은 SaaS 회사들이 할 필요가 있는 것들을 정확히 집어서 하고 있다.On-premise(인하우스 서비스)에서 SaaS(클라우드 컴퓨팅)로SaaS는 “Software as a Service.” 의 약자이다. 페이스북은 사실 기술적으로 SaaS라기 보다는, 일종의 소비자 네트워크 서비스라고 할 수 있다. 하지만 페이스북만큼 많은 서비스를 제공하는 곳은 존재하지 않는다. 페이스북이 이렇게까지 성공한 것은 그 서비스 내에서 유저들의 이용률을 크게 늘렸기 때문이다. 다른 SaaS 기업들은 이 부분을 더 신경 써야 될 필요가 있다. 이용률이야말로 지금 SaaS 비즈니스의 생존에 있어 그 어느 때보다 중요하기 때문이다.그 이유는 다음과 같다. 예전에, 소프트웨어는 회사의 컴퓨터 네트워크에 실제 물리적으로 깔려야만 했다. 소프트웨어 판매업자들은 대기업에 라이선스를 팔기도 했고, 그런 기업들은 해당 소프트웨어 이용을 위해 Accenture나 CSC 같은 회사에 돈을 지불하기도 했다. 당시 판매업자들은 라이선스를 많이 팔기만을 원했지, 얼마나 많은 사람들이 그 소프트웨어를 쓸 지에 대해선 관심이 없었던 것이다.그리고 1999년, Salesforce의 공동 창업자인 Marc Benioff는 새로운 모델을 소개하며 다음과 같이 말했다.“설치하는 데만 수 개월이 걸리고 하드웨어와 네트워킹에 엄청난 투자를 요구하는 비싼 CD-ROM 소프트웨어를 기업들에게 파느니, 우리는 클라우드 컴퓨팅이라고 알려진 모델을 통해 Software-as-a-Service(SaaS)를 팔기로 했다. 기업들은 이제 유저의 수에 맞춰 서비스를 이용한 만큼 비용을 지불해야 할 것이고, 그런 서비스들은 인터넷, 클라우드를 통해 즉시 제공될 것이다.”구독 기반(subscription-based) 소프트웨어는 회사 내부의 데이터 센터가 아닌 웹 브라우저를 통해 제공된다. 이는 소프트웨어 개발자로 하여금 언제든지, 즉각적으로 그들의 고객에 접근할 수 있게 해주었다. 어느 순간, 유저를 만족시키는 일은 CIO(Chief Information Officer)나 시스템 통합업체의 책임이 아니게 된 것이다. 그 일은 이제 소프트웨어 판매업자가 하게 되었다.이러한 클라우드 컴퓨팅 방식은 SaaS 소프트웨어로 하여금 생존을 위해 끊임없이 자신들의 가치를 어필하게끔 만든다. 그리고 SaaS 회사들은 계속해서 자신들의 소프트웨어를 이용하는 소비자들을 확보하기 위해 많은 양의 돈을 쓰고 있다. 이는 과거 기업 고객들에게 소프트웨어 라이선스를 팔러 다니던 때와는 180도 달라진 상황인 것이다. 오늘날의 SaaS 회사들은 예전처럼 높으신 몇몇 분들을 만나 무언가를 사라고 설득할 필요가 없다. 그저 이용자들이 자신들의 제품을 계속 사용하게끔 유도하면 되는 것이다.페이스북은 SaaS의 새로운 모델이다이제 페이스북을 한 번 살펴보자. 페이스북은 클라우딩를 통해 지속적으로 서비스를 제공한다. 그들은 광고를 통해 돈을 벌기 때문에, 그들의 가장 중요한 목표는 사람들로 하여금 계속 서비스를 이용하게 하는 데 있다. CIO들을 만나서 큰 계약을 체결하는 데 시간을 쓸 바에야 그 100분의 1초도 안 되는 시간에 12억 명의 사람들에 서비스를 파는 것이 더 낫다는 것이다.페이스북이 딱 한 가지 신경 써야 될 것이 있다면 그것은 사람들이 지금보다 더 적극적으로 페이스북을 이용하게끔 만드는 것에 있다.“우리의 최우선 목표는 모바일 장치나 개인용 컴퓨터를 통해 사람들을 연결시켜주고 공유하게끔 하는 유용하고 매력적인 서비스를 창조하는 것에 있습니다.” – 미국증권협회 기업정보 페이지의 페이스북 파일에서페이스북이 사람들의 관심을 많이 받을수록, 그들은 더 많은 광고를 사람들에게 보여줄 수 있다. 페이스북에게 있어서, 그러한 관심은 아주 중요한 것이다. 더 많은 관심을 받는 다는 것은 더 많은 성장과 확장의 기회를 갖는 다는 것을 의미하기 때문이다. 이것은 드롭박스나 Slack과 같이 바텀업 방식으로 성장한 SaaS 기업들이 새겨들어야 할 점이다. 유저들이 서비스를 쓰는 시간이 많아진다면, 앞으로 그들에게 더 많은 다른 서비스를 쓰게 만들 수 있기 때문이다.앞으로 페이스북이 더 성장하고 발전하려면 유저의 관심이 필요하다. 그래야 여러 방면에서 이용률을 늘릴 수 있는 방법을 찾을 수 있기 때문이다. 이제 여기서 페이스북이 그들 서비스의 이용률과 성장을 이뤄낸 3가지 방법에 대해서 소개해 보도록 하겠다. 모든 SaaS 기업들은 비슷한 방법으로 자신들의 이용률과 성장을 이뤄낼 수 있을 것이다.페이스북은 이용률을 측정하여 현재 운영하는 서비스를 최적화 시켰다페이스북은 이용률을 늘리기 위해 새로운 서비스를 내놓는다페이스북은 다른 앱들과 통합하는 과정을 거쳤기 때문에 페이스북을 쓰지 않는 사람들조차 페이스북을 쓰게 되었다페이스북이 이용률을 어떻게 늘렸는지에 대해 좀 더 깊이 이야기해 보도록 하겠다. 그러고 나면 페이스북의 노하우를 다른 SaaS에 어떻게 적용할 수 있을 지 분명하게 보여줄 수 있을 것이다.이용률 측정을 통해 서비스의 최적화를 이뤄낸다지금 사람들이 어떻게 서비스를 이용하고 있는 지 모르고 있다면 그들에게 당신의 서비스를 사용하게 만들 수도 없을 것이다. 페이스북은 이용률을 늘리는 방법에 대해 집요하게 연구해왔기 때문에 좋은 사례로 들기에 적합하다.핵심은 사람들이 지금 하고 있는 것, 그리고 그들이 원하는 것을 정확하게 아는 것에 있다. 페이스북은 단순히 월 이용자 수나 일 이용자 수를 알아보려 애쓰지 않는다. 왜냐하면 그런 수치들은 사용자들이 그 서비스를 통해 무엇을 하는지를 전혀 설명하지 못하기 때문이다. 대신 페이스북은 서비스 이용의 질적인 부분에 집중한다. 사람들이 페이스북을 통해 무엇을 이루려고 하는 지와 그들이 실제로 그렇게 할 수 있는 지에 대해서 말이다.이 부분에 있어 페이스북의 대표적인 전략 중 하나가 바로 10일안에 친구 7명 만들기이다. 일찍이, 페이스북은 10일안에 7명의 친구를 만드는 사람은 페이스북을 계속 사용할 확률이 훨씬 더 높다는 사실을 알게 되었다. 일단 이것을 알게 되자, 그들은 신규 유저들이 7명의 친구를 만날 수 있게 하기 위해 가진 모든 수단을 쓸 수 있게 된 것이다.바로 지금도, 페이스북은 새로운 친구를 추가할 것을 사람들에게 계속해서 권장한다. 왜냐하면 이것이야 말로 네트워크를 이루는 데 있어서 가장 가치 있는 부분이기 때문이다.페이스북 계정을 만들자마자, 유저들은 뉴스 피드 상단에 새로운 친구를 추가하시겠냐는 메시지가 뜨는 것을 볼 수 있다.아래 사진은 유저들이 다른 페이지를 둘러 보는 동안 뜨는 사이드바인데, 보다시피 그들이 알 수 있을 법한 사람들을 친구로 추가하게끔 권장하고 있다.또한 페이스북은 뉴스 피드와 같이 그 기능을 최대한 활용하기 위해 더 많은 친구들을 추가할 것을 권장하고 있다.페이스북은 이런 전략을 앞으로도 고수할 것이다. 2017년, 페이스북은 “Discover people” 이라는 새로운 기능을 출시했다. 이는 당신으로 하여금 프로필을 업데이트 하게끔 유도하고 기존에 친구가 아니더라도 같은 이벤트에 참여하는 경우 서로를 연결시켜 준다.페이스북은 사람들이 자신들의 서비스를 계속 이용하게 만들기 위해 기나긴 세월 동안 노력해왔고 앞으로도 그럴 것이다. 그들은 친구 최적화를 빠르게 해줄 뿐만 아니라 흥미를 잃은 사람들도 쉽게 다시 돌아올 수 있도록 여러 요인들을 제공해준다. 페이스북의 성장 전담 부서를 이끌고 있는 Chamath Palihapitiya은 “당장의 단기적인 이익에만 집중하지 않기 위해서는 절제력이 필요하다.” 라고 말한다. 페이스북은 초창기부터 무엇보다 사람들의 이용률이야말로 그들의 성패를 좌우한다는 것을 알고 있었다. 사람들의 주된 목표를 파악해서 이용률을 장기적으로 늘리는 것이 그들의 제1과제 였던 것이다.Trello는 어떻게 유저들이 쉽게 직장 동료를 추가하도록 만들었는가페이스북과 똑같이, Trello는 유저들이 무엇을 하는지를 이해하고 그들이 원하는 걸 더 많이 하게 도와주는 방식으로 이용률을 올렸다. Trello의 핵심적인 가치는 사람들이 프로젝트를 협력하게끔 만드는 것이었기 때문에, 그들이 그렇게 하도록 도움을 줘서 자신들 서비스의 가치를 보여줘야 했다.그래서 Trello가 직장 동료를 추가하는 방식은 놀라울 정도로 쉽게 되어 있다. 이는 페이스북이 친구를 추가하는 방식과 정확히 똑같다. 페이스북이 사람들로 하여금 쉽게 친구를 추가하게 하여 소셜 네트워크의 가치를 입증했다면, Trello는 쉽게 동료들을 추가하게 하여 프로젝트 협업 툴로써의 가치를 입증했다.Trello는 유저들로 하여금 이름이나 이메일 주소로 아는 사람들을 등록할 수 있게 만들었다. 유저들은 코드나, ID, 링크 같은 것 없이도 사람들을 쉽게 추가할 수 있다. 심지어 다른 사람들이 Trello를 사용하는지도 알 필요가 없다. 어찌 됐든 Trello를 통해 사람들을 찾아보고 확인해 볼 수 있는 것이다.또 만약 Trello를 한 번이라도 썼던 사람이라면 더욱 쉽게 목록에 추가할 수 있다.이런 방식을 통해 이용자들은 아무런 마찰 없이 많은 동료, 협력자들을 통해 프로젝트를 공유할 수 있다. 즉, Trello의 핵심 가치를 이루게 되는 것이다. 이는 사람들에게 Trello가 얼마나 유용한 서비스인지를 빠르고 쉽게 이해시켰다. 또한 이는 더 많은 사람들이 더 많은 프로젝트를 하게끔 유도했고, 결국 모두가 Trello를 더 많이 이용하게 되었다.Slack은 어떻게 이용률을 늘려왔는가이렇게 사용자의 이용률에 집중해서 성장을 이루고 있는 유명한 SaaS 기업이 또 하나 더 있다. Slack이 바로 그 기업인데, Slack은 메시지를 매끄럽게 전송하는 역할 하나에만 전념하고 있다.Slack은 자신들의 서비스를 이용해 2000개 이상의 메시지를 보낸 적 있는 팀들은 Slack의 가치를 알고 있기 때문에 앞으로도 계속 서비스를 사용할 것이라고 예측한다. 왜냐하면 Slack의 통계에 따르면, 다른 요소들이 어떻든 간에, 2000개 이상의 메시지를 보낸 팀들 중 93%가 지금까지도 Slack을 사용하고 있기 때문이다. 그래서 이용률을 늘리기 위해선, 메시지를 보내는 것을 더 쉽게 만들어야 하는 것이다. Slack의 공동 창업자인 Stewart Butterfield 역시도 이 목표를 위해 사람들이 실제로 어떻게 Slack을 쓰고 있는가에 대해서 생각해보았다.“처음으로 Slack을 쓰려고 온 사람이 되었다고 생각해 보는 겁니다. 특히 진짜 사회생활을 하는 사람들 말이죠. 상사에게 Slack을 쓰라고 해서 쓰게 된 사람, 아침 먹을 시간도 없어서 짜증이 난 사람, 주말이 오기 전에 프로젝트를 끝낼 수 있을지 걱정하는 사람… Slack을 면밀히 살펴봐서, 이런 사람들에게 먹히지 않을 것 같은 요소들을 생각해 내는 겁니다. 냉정하게 보는 거에요. 최고의 서비스를 주기 위해서 말이죠.”Slack은 메시지 전송에 따르는 불편함을 개선하면서 이용률을 늘려왔다. 그러한 개선의 예를 들어 보자면, 누군가가 Slack에서 링크를 걸었다고 했을 때, Slack은 그 링크에 대한 간단한 정보를 미리 보여준다. 즉, 사람들은 링크를 보려고 앱에서 빠져나와야 될 필요가 없는 것이다. 나중에 다시 그것을 확인해보기도 편하고 말이다.이런 시스템상의 개선점들이 Slack을 성장하게 만들었다. 메시지를 보내는 것에 있어서 사람들이 원하는 부분을 아주 쉽게 할 수 있게 만들었기 때문이다.이렇듯 페이스북, Trello, Slack은 모두 실제 이용자들이 원하는 것을 이해하고 그들이 그것을 쉽고 빠르게 할 수 있는 서비스를 제공하고 있다. 아래에 이런 SaaS 기업들이 어떻게 자신들의 서비스를 통해 이용자들에게 도움을 줬는지 요약해보았다.페이스북의 10일안에 친구 7명 만들기, Slack의 2000개 이상의 메시지 보내기, Dropbox의 파일 한 개 업로드 하기 등과 같이 그들은 수치로 표시되는 목표를 세웠다. 이러한 목표는 당신의 팀으로 하여금 무엇이 가장 이용률을 끌어오는데 중요한 지를 확인시켜줄 뿐만 아니라 그들에게 목표 달성을 위한 구체적인 숫자를 알려준다.핵심적인 기능들을 사람들이 이용하게 하려면 그것을 직관적으로 만들어야 한다. Raymond Loewy(미국의 전설적인 산업 디자이너)에 따르면, 성공적인 서비스는 사람들이 당장 사용하기에 편해야 한다고 한다. 예를 들어, 페이스북이 처음 “On this day” 서비스를 도입한 것은 유저들로 하여금 무언가 새로운 것을 하는 걸 권하기 위해서였다. 하지만, 이 서비스는 여전히 유저들에게 친숙한 태그, 공유하기 기능들을 사용하고 있다.유저들의 참여를 막을 만한 요소들을 찾아서 없애야 한다. 사용자들이나 얼리 엑세스 베타 테스터 등과 이야기를 해봐서 무엇이 서비스에 있어 가장 짜증나는 요소인지 알아내야 한다. “이거 어떻게 하는 건지 모르겠어요” 라던가 “이게 좀 쉽게 됐으면 하는데…” 와 같은 불만들에 귀기울여야 한다. 이런 장애물들을 제거하면 유저들이 서비스를 이해하기 더 쉽고 그 서비스의 가치를 파악하는 것 역시 쉬워진다.즉, 현재 가지고 있는 서비스 내에서 이용률을 끌어올리려면 유저들에게 무엇이 가장 도움이 되고 의미가 있는지 파악하는 것이 가장 중요하다고 할 수 있다.이용률을 늘리기 위해 서비스를 추가한다이용률을 끌어올린다는 것은 단순히 사람들로 하여금 기존의 서비스를 계속 쓰게 만드는 것 만을 의미하지는 않는다. 당신은 끊임없이 실험을 해보고 새로운 서비스를 제공해서 유저들이 서비스를 통해 더 많은 것들을 얻을 수 있도록 해야 한다.페이스북은 기존에 그들이 가진 서비스가 수명이 다할 것을 걱정해서 계속 실험을 하고 이용자들이 앞으로 무엇을 원할지를 예상해왔다.페이스북의 직원 가이드북을 보면, 새로운 직원들은 그들의 팀이 계속 새로운 생각을 하게끔 자극 할 것을 권장하고 있다.그 결과, 페이스북은 끊임없이 혁신하고, 또 그만큼 실패를 경험하고 있다.페이스북은 스냅챗으로부터 이용자들을 뺏어오기 위해 2012년 별도의 앱인 Poke를 출시한다. 그런데 이 앱은 대실패작이 되었고 페이스북은 얼마 지나지 않아 앱스토어에서 이 앱을 삭제하게 되었다.2014년에 페이스북은 이용률을 늘리기 위한 일환으로 슬링샷이라는 앱을 출시했다. 이 앱은 사진과 함께 메시지를 보내면 스냅챗과 같이 몇 초안에 사라지는 것이 특징인데 불과 1년만인 2015년에 앱스토어에서 내려가게 되었다.또 페이스북은 2016년 Quick Update라는 것을 시도했다. 이는 스냅챗과 비슷한 기능을 페이스북 앱에 추가시키는 것이었는데, 이런 기능을 유저들을 대상으로 그룹테스트 해 본 결과 반응이 좋지 않아 결국 공식적으로는 출시되지 못하게 되었다.이런 좋지 않은 결과들은 페이스북이 혁신에서 실패하고 있다는 소문을 자아냈다. Jason Calacains 같은 논평가는 이에 대해 “페이스북의 앱 플랫폼은 망하기 위해서 혁신을 하는 것인가?” 라고 하기도 했다.하지만 페이스북의 이런 계속되는 시도는 결국 그들을 새로운 기회로 인도했다. 그들은 스냅챗의 스토리 기능을 페이스북과 인스타그램에 도입하려고 시도해 왔는데 이 과정에서 마침내 페이스북 라이브라는 새로운 서비스를 만들어냈다. 이 서비스는 대히트를 쳤고, 이제 회사, 미디어, 그리고 유명인사들까지 모두 페이스북의 라이브 스토리를 사용하고 있다.이렇듯 페이스북이 큰 성공을 거둘 수 있었던 이유는 그만큼 실패도 많이 해봤기 때문이다. 그들은 그저 사람들이 관심 가질 만한 새로운 무언가를 계속 만드는데 집중할 뿐이다. 왜냐하면 이런 시도야말로 궁극적으로 이용률을 더 많이 올릴 수 있는 방법이기 때문이다.드롭박스 역시 이용률을 높게 유지하기 위해 새로운 서비스를 만들고 있다SaaS 기업들은 현재의 서비스보다 한 걸음 더 앞선 서비스 제공을 통해 이용률을 끌어올릴 수 있다. 그들은 지금 하는 것 이외에 이용자들이 무엇을 더 원하고 더 신경 쓸까를 생각해 볼 필요가 있다.그 예로 드롭박스의 드롭박스 페이퍼를 들 수 있다. 드롭박스는 원래 파일 공유 서비스였다. 하지만 오늘날, 드롭박스는 파일을 공유하는데 있어 다양한 방법을 제공해준다. 만약 드롭박스가 처음 서비스 이외에 유저들이 뭘 더 원할 것인 지를 생각해보지 않았다면 결국 이용률을 올릴 방법이 바닥나서 망하게 됐을 것이다.즉 드롭박스는 단순한 파일 공유 서비스에서 사람들이 함께 일하는 걸 더 쉽게 만들어 주는 일종의 팀 협업 툴로 자신들의 브랜드를 쇄신한 것이다. 이러한 재브랜딩 과정과 함께, 드롭박스는 2015년에 “창조적인 업무를 위한 새로운 형태의 파일 편집 툴” 이라는 신규 서비스인 드롭박스 페이퍼를 런칭했다.드롭박스 페이퍼는 단순히 문서와 파일을 저장하는 데 드롭박스를 쓰는 것이 아니라, 이제 문서와 파일을 만드는 데에도 드롭박스를 쓸 수 있게 만들어 주었다. 드롭박스 페이퍼는 사람들이 더 많이 서비스를 이용하게 만들었는데, 이는 파일 공유를 넘어 사람들간의 협업을 더 쉽게 해준다는 추가적인 옵션을 제공해줬기 때문이다.드롭박스가 이렇게 새로운 서비스를 만들려는 이유는 생존하기 위해서이다. 이 산업에 있어 망하는 일은 너무나 쉽게 일어나기 때문이다. Intercom의 Des Traynor는 다음과 같이 이를 설명한다.“원래 이쪽 산업이란 게 이런 겁니다, 기술이란 것의 특성 자체가 이런 것이죠. 모든 서비스가 결국 다 죽어 없어지게 되어있습니다. 만약 내 말이 사실이 아니라고 생각한다면 저에게 그렇지 않은 경우를 알려주세요. 한때는 SaaS 비즈니스가 절대 안 망할 것 같은 시절도 있었습니다. 하지만 더 이상은 아니에요.”만약 당신이 유저들이 당장 원하는 것에 대해서만 생각하고 있다면, 이미 망하고 있는 것이다. 성공적인 SaaS 기업들은 항상 유저들이 미래에 뭘 원하게 될 지에 대해서 생각한다. 아래에 SaaS 기업들이 어떻게 소비자들의 미래 욕구와 새로운 서비스에 대해 예측하려 하는 지 정리해보았다.당신의 경쟁자들, 그리고 왜 유저들이 그들의 서비스를 이용하는지 이해하라. 온라인 포럼 등을 보고 사람들이 경쟁사의 서비스를 어떻게 평가하는지를 알아내라. 이를 통해 당신은 사람들이 무엇을 원하는지, 그 방향이 어디로 향하게 되는지에 대한 통찰력을 얻게 된다. 이런 과정은 서비스의 확장과 새로운 서비스를 실험해 볼 수 있는 기회도 제공해준다.당신의 서비스를 사용했을 때 유저들이 무엇을 할 수 있을지를 생각해 봐야 한다. 유저들이 당장 요구하는 것만 만드는 것이 아닌 그들이 앞으로 원할 것이 무엇인지를 한 발 앞서 생각해 보는 것이다. 예를 들어, 아마존이 최근 개시한 새로운 서비스인 “Your idea” 리스트를 보자. 이 서비스는 유저들이 쇼핑을 하면서 비록 구입 하진 않더라도 커뮤니티에 자신이 생각한 리스트를 보여주고 싶은 욕구를 미리 연구해서 나온 결과물이다.가장 효과적이면서도 남들이 쉽게 예상하기 힘든 기능들을 우선순위로 짜는 것이 좋다. Gusto의 Tomer London은 서비스를 만들고 그것을 개선시킬 때, 가장 좋은 기능은 타인이 예측하기 어려움에도 불구하고 사용자 경험을 개선시키는데 가장 효과적인 것들이라고 한다. 사람들이 서비스를 통해 무엇을 가장 하고 싶어하는 지를 이해하고 그들을 도와줄 더 쉽고 나은 방법들을 생각해본다면 가장 효과적인 기능에 대한 단서를 잡을 수 있다. 남들이 예측하기 어려운 방법들은 당신이 처한 경쟁 지형에 대해 이해함으로써 알아갈 수 있다. 서비스 이용률을 늘리기 위해 다른 서비스와 통합한다우물 안의 개구리처럼 서비스를 홀로 제공하려 한다면 최대한의 이용률을 얻기란 요원하다. 당신은 새로운 서비스를 내놓음으로써 이용률을 늘릴 수 있지만, 그것으론 충분하지 않다. 유저들은 항상 다른 서비스 역시도 사용하고 있다. 당신이 이길 수 있는 방법은 당신의 서비스를 다른 서비스에 포함시킴으로써 사람들이 그 서비스를 쓸 때, 당신의 서비스도 쓰게 만드는 것이다.당신이 페이스북 웹사이트나 앱을 통해 페이스북을 쓰고 있지 않더라도, 당신은 페이스북을 사용하고 있는 것이나 마찬가지이다.페이스북을 이용해서 다른 서비스에 로그인 할 수 있다당신은 다른 웹사이트의 컨텐츠를 페이스북에 공유할 수 있다당신이 작업하는데 쓰는 서비스를 페이스북에 연결시킬 수 있다.티켓마스터를 통해 공연 티켓을 구매하는 것 역시도 페이스북으로 할 수 있다.페이스북은 다른 서비스들과도 완전히 통합이 되었기 때문에 사람들은 페이스북 인터페이스를 다른 서비스에서 보더라도 전혀 이상하게 생각하지 않는다. 심지어 어떤 경우에는, 페이스북 계정이 없다면 다른 사이트에 가입하기 어려울 때도 있다.페이스북이 다른 서비스와 더 통합이 될수록 당신은 더 페이스북을 쓰게 되고 그것을 필요로 하게 된다. Social Capital LP의 공동 경영자인 Arjun Sethi는 이점에 대해 다음과 같이 말한다.“페이스북이 권장하는 행동들이 일종의 문화가 되고 있어요. 페이스북은 그냥 가만히 앉아서 다른 서비스가 자신의 특징들을 베끼는 걸 보고만 있지 않았습니다. 자신들의 서비스를 다른 곳에 아주 쉽게 통합될 수 있게 만들었고 그 과정에서 핵심적인 이득은 다 챙겨갔습니다.”이것은 페이스북의 신중한 성장 전략의 일환이다. 다른 서비스의 개발자들이 페이스북을 쉽게 그들의 서비스에 통합할 수 있게 만듦으로써, 그냥 자신들의 서비스 내에만 머물러 있는 것에 비해 훨씬 더 많이 사람들이 페이스북을 사용하게끔 만들었다.Slack 역시도 다른 툴과 쉽게 통합이 가능하다페이스북이 다른 소셜, 라이프스타일 서비스들과 통합해서 유저들을 끌어모은 것처럼, Slack 역시도 자신들의 서비스를 다른 관련된 툴들과 통합할 수 있게 만들었다.Front와 같은 이메일 클라이언트와의 통합은 사람들로 하여금 Slack에서 바로 이메일을 관리할 수 있게 하였다.Slack은 또 Stripe와 통합을 하였는데, 이로 인해 사람들은 Slack 내에서 고객 결제 데이터를 보고 관리할 수 있게 되었다.Google Docs와의 통합으로 Slack 앱을 나가지 않고도 구글 문서 활동들을 볼 수 있게 되었다.Slack은 서드 파티의 통합을 장려하기 위해 거대한 앱 생태계를 구축하고 있다. 2015년에, 그들은 앱과 관련해서만 8천만 달러의 벤처 펀드를 만들었다. 2016년에, Slack은 자신의 플랫폼 내에 600개 이상의 앱을 보유하게 되었다. 그래서 이메일을 관리하거나, 고객과 커뮤니케이션을 하거나, 제품 분석 결과를 보는 것 등을 하러 다른 곳으로 일일이 가는 대신에 Slack 유저들은 기존 자신들의 서비스를 통해서 그 모든 것들을 할 수 있게 되었다.페이스북과 Slack은 그들 서비스의 유저들이 사용할 만한 다른 서비스들과 통합을 통해 이용률을 올렸다. 당신 서비스의 이용자들도 알고 있는 이런 기술의 생태계 속에 당신의 서비스를 끼워 넣는 방법에 대해 아래에 정리해 보았다.당신의 서비스를 사용하는 유저들의 워크플로우 대해 생각해보고 그것을 개선시킬 수 있는 점들에 대해서 추측해보라. 예를 들어, HubSpot을 이용하는 기업들의 궁극적인 목적은 사람들을 광고로 유인해서 실제 고객으로 만드는 데 있다. 그래서 HubSpot은 그 목적을 더 잘 수행하기 위해 자신들의 CRM 툴을 페이스북의 광고 관리 프로그램인 Adespresso와 통합할 수 있 게 만들었다. 즉, 사람들이 페이스북 광고를 클릭하게 되면 그 유저의 정보는 자동으로 그들의 CRM에 업로드가 된다.다른 유명 서비스들과의 통합을 통해 그들의 규모가 가진 이점을 가져오는 것이 좋다. 눈에 잘 띄는 서비스와의 통합은 당신의 서비스 역시도 눈에 잘 띄게 만들어준다. 잠재적 유저들에게 당신의 서비스를 소개할 수 있는 기회를 더 얻을 수 있을 뿐만 아니라, 다른 유명 서비스가 가진 브랜드 신뢰성 역시도 가져올 수 있다. 만약 당신의 회사가 아직 작다면, 유명하고 접근하기도 쉬운 Slack이나 페이스북과 같은 서비스와 함께 시작하라.Zapier를 활용해서 다른 서비스들과의 통합을 도모해라. Zapier에 호환이 되도록 앱을 만든다면, 유저들로 하여금 당신이 아직 직접적으로 통합을 제안하기 어려운 다른 앱들과 통합할 수 있는 옵션을 제공해 주는 것과 다름이 없다. 이 방법은 당신의 서비스가 아무리 독특하다 할지라도 그것을 유저들의 워크플로우에 집어넣는 데 도움이 된다.서비스를 개선시키는 데 있어 한 가지 방법만 써서는 이용률을 끌어올리는 데 한계가 있다. SaaS 기업들이 정말로 유저들로 하여금 그들의 서비스를 계속 좋아하고 이용하게끔 만들려면, 할 수 있는 모든 방면에서 이용률 최적화를 해야 한다. 기존의 서비스 내에서 할 뿐만 아니라, 새로운 서비스, 다른 유저들에게 이미 필요한 다른 서비스와의 통합을 해서라도 말이다.차세대 SaaS를 만드는 것에 대해SaaS 서비스들은 점점 더 무용지물이 되어 가는 경우가 많고 사라지는 서비스들도 많다. 만약 SaaS 기업들이 왜 사람들이 그들의 서비스를 쓰는 지 이해하지 못한다면, 그들은 계속 성장할 수 없을 것이고 유저들도 이탈할 것이다.지금까지의 내용을 정리하자면 페이스북은 이용률과 성장을 도모할 수 있는 매우 포괄적이면서도 단순한 방법 3가지를 생각해냈다. 사람들이 현재의 서비스를 더 많이 사용하게 만드는 것, 새로운 서비스를 통해 더 많이 사용하게 만드는 것, 그리고 다른 서비스와의 통합을 통해 자신의 서비스를 더 이용하게 만드는 것. 이 3가지이다. 그리고 이렇게 이용률을 올린다는 것은 성공을 의미한다.미래에 가장 성공적인 SaaS 기업 역시 이용률에 중점을 두게 될 것이다. 지금까지 페이스북을 모델로 삼아 설명한 것처럼, 이것들이 SaaS 기업이 앞으로 더 나은 서비스를 만드는 방법이 될 것이다.원문 : 프로덕트해빗#더팀스 #THETEAMS #SaaS #인사이트 #페이스북
조회수 1852

TDD(파이썬) : 테스트 잘하고 계신가요?

Overview반복적인 테스트에 지쳐가고 있던 무렵, TDD방법론을 접하게 되었습니다. TDD(Test Driven Development)는 테스트 주도적인 개발로 소스코드 작업 전에 테스트 코드를 먼저 작성해 소스수정에 대한 부담을 덜고 디버깅 시간을 줄일 수 있습니다. TDD 장점소스코드의 품질이 높다.재설계 및 디버깅 시간이 절감된다.TDD 단점단기적 코드일 경우 생산성이 떨어진다.실제 코드보다 테스트 케이스가 더 커질 수 있다.파이썬에서 TDD가 필요한 이유1) 파이썬에는 정적 타입 검사 기능이 없다. (Python 3.6 에서는 정적 타입 선언 가능)2) 동적언어이기 때문에 TDD를 하기에 적합하다.3) 파이썬은 간결성과 단순함으로 생산성이 높은 반면 런타임 오류가 발생할 수도 있다.4) 파이썬을 신뢰할 수 있는 유일한 방법은 테스트를 하는 것이다.파이썬 테스트 모듈 unittest이번 글에서는 unittest를 사용해 단위 테스트를 해보겠습니다. unittest는 이미 내장되어 있어 따로 설치하지 않아도 되는 표준 라이브러리입니다. 사용방법1) import unittest 2) unittest.TestCase 상속받는 하위 클래스 생성3) TestCase.assert 메소드를 사용하여 테스트 코드를 간략화4) unittest.main() 실행그럼 간단한 예제로 단위 테스트를 해보겠습니다.1.사칙연산 함수를 추가합니다.def add(a, b):     return a + b   def substract(a, b):     return a - b   def division(a, b):     return a / b   def multiply(a, b):     return a * b 2. unittest.TestCase 상속받아 테스트 클래스를 생성합니다. 아래는 각각의 함수 결과값을 비교해 텍스트를 출력하는 코드입니다.import unittest class TddTest(unittest.TestCase): def testAdd(self):         result = lib_calc.add(10, 20)         if result == 30:             print('testAdd OK')      def testSubstract(self):         result = lib_calc.substract(20, 30)          if result > 0:             boolval = True         else:             boolval = False if boolval == False:             print('testSubstract Error')      def testDivision(self):         try:             lib_calc.division(4, 0)         except Exception as e:             print(e)      def testMultiply(self):         result = lib_calc.multiply(10, 9)          if result < 100>             print('testMultiply Error') if __name__ == '__main__':     unittest.main() 3.결과: 해당 조건에 만족해 작성한 텍스트가 출력됩니다.이번에는 unittest에서 지원하는 TestCase.assert 메소드를 사용해 간략하게 소스를 수정해보겠습니다.TestCase.assert 메소드1) assertEqual(A, B, Msg) - A, B가 같은지 테스트2) assertNotEqual(A, B, Msg) - A, B가 다른지 테스트3) assertTrue(A, Msg) - A가 True인지 테스트4) assertFalse(A, Msg) - A가 False인지 테스트5) assertIs(A, B, Msg) - A, B가 동일한 객체인지 테스트6) assertIsNot(A, B, Msg) - A, B가 동일하지 않는 객체인지 테스트7) assertIsNone(A, Msg) - A가 None인지 테스트8) assertIsNotNone(A, Msg) - A가 Not None인지 테스트9) assertRaises(ZeroDivisionError, myCalc.add, 4, 0) - 특정 에러 확인1. TestCase.assert 메소드 사용TestCase.assert 메소드를 사용하여 에러를 발생시켜 보겠습니다.import unittest class TddTest(unittest.TestCase): def testAdd(self):         result = lib_calc.add(10, 20)          # 결과 값이 일치 여부 확인         self.assertEqual(result, 31)      def testSubstract(self):         result = lib_calc.substract(20, 10)          if result > 10:             boolval = True         else:             boolval = False # 결과 값이 True 여부 확인         self.assertTrue(boolval)      def testDivision(self):         # 결과 값이 ZeroDivisionError 예외 발생 여부 확인         self.assertRaises(ZeroDivisionError, lib_calc.division, 4, 1)      def testMultiply(self):         nonechk = True result = lib_calc.multiply(10, 9)          if result > 100:             nonechk = None # 결과 값이 None 여부 확인         self.assertIsNone(nonechk) if __name__ == '__main__':     unittest.main() 2. 결과1) 테스트가 실패해도 다른 테스트에 영향을 미치지 않음2) 실패한 위치와 이유를 알 수 있음다음으로 setUp(), tearDown() 메소드를 사용하여 반복적인 테스트 메소드 실행 전, 실행 후의 동작을 처리해보겠습니다.TestCase 메소드1) setUp() - TestCase클래스의 매 테스트 메소드가 실행 전 동작2) tearDown() - 매 테스트 메소드가 실행 후 동작 1. setUp(), tearDown() 메소드 사용- setUp() 메소드로 전역 변수에 값을 지정- tearDown() 메소드로 “ 결과 값 : ” 텍스트 출력import unittest class TddTest(unittest.TestCase): aa = 0     bb = 0     result = 0 # 매 테스트 메소드 실행 전 동작     def setUp(self):        self.aa = 10        self.bb = 20 def testAdd(self):         self.result = lib_calc.add(self.aa, self.bb)          # 결과 값이 일치 여부 확인         self.assertEqual(self.result, 31)      def testSubstract(self):         self.result = lib_calc.substract(self.aa, self.bb)          if self.result > 10:             boolval = True         else:             boolval = False # 결과 값이 True 여부 확인         self.assertTrue(boolval)      def testDivision(self):         # 결과 값이 ZeroDivisionError 예외 발생 여부 확인         self.assertRaises(ZeroDivisionError, lib_calc.division, 4, 1)      def testMultiply(self):         nonechk = True self.result = lib_calc.multiply(10, 9)          if self.result > 100:             nonechk = None # 결과 값이 None 여부 확인         self.assertIsNone(nonechk)      # 매 테스트 메소드 실행 후 동작     def tearDown(self):         print(' 결과 값 : ' + str(self.result))   if __name__ == '__main__':     unittest.main() 2. 결과- setUp() 메소드로 지정한 값으로 테스트를 수행 - tearDown() 메소드로 각각의 테스트 메소드 마다 “ 결과 값 : ” 텍스트 출력실행 명령어 여러 옵션을 사용하여 실행 결과를 출력해보겠습니다.실행 명령어python -m unittest discover [option]1. -v : 상세 결과 2. -f : 첫 번째 실패 또는 오류시 중단3. -s : 시작할 디렉토리4. -p : 테스트 파일과 일치하는 패턴5. -t : 프로젝트의 최상위 디렉토리1. 상세 결과테스트 메소드명 및 해당 클래스명 출력 2. 첫 번째 실패 또는 오류시 중단첫 번째 테스트에서 오류 발생하여 중단3. 여러 옵션 실행현재경로 디렉토리 안에 tdd_test*.py 패턴에 속하는 모든 파일의 상세 결과Conclusion지금까지 파이썬에서 unittest 모듈을 이용한 테스트 코드를 작성했습니다. 처음에는 귀찮고 번거롭지만 테스트 코드를 먼저 작성하는 습관을 길러보세요. 분명 높은 품질의 소스코드를 만들 수 있을 겁니다!참고Python 테스트 시작하기파이썬 TDD 101글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #파이썬 #Python
조회수 1721

스타일쉐어 커머스 시스템 리빌딩 회고 1

스타일쉐어 스토어 소개스타일쉐어 스토어(이하 커머스)는 2016년 4월 출시되어 지금까지 나날이 성장하고 있습니다. 작년 초, 커머스 시스템을 리빌딩하기로 했고 현재까지 진행 중입니다. 어떤 이유로 리빌딩을 하는지, 어떤 고민을 했는지, 어떻게 진행하고 있는지 몇 자 적어보려 합니다. 이 글은 문제 인식, 목표, 계획에 대한 내용입니다.리빌딩을 결정한 이유커머스 프로젝트를 시작할 당시 커머스 시스템을 경험해본 개발자가 없었습니다. 이 상황에서 새로이 구현하기엔 위험 부담이 크다는 판단을 했습니다. 때문에 커머스 솔루션을 도입했고, 적은 비용으로 커머스 기능을 출시할 수 있었습니다. 거래량이 점점 늘어나면서 솔루션이 감당할 수 있는 한계치를 벗어나자, 예상치 못했던 기술적인 이슈가 발생했습니다. 사내 MD팀, CS팀은 물론, 입점사들과 유저들에게까지 불편한 경험을 주고 있었습니다. 개발팀은 솔루션 유지 보수와 운영 이슈에 집중했지만, 끝이 없는 문제들에 점점 지쳐갔습니다. 개발팀의 퍼포먼스는 저하되고 있었고, 새로운 기능 개발에 집중하지 못하는 상황까지 발생했습니다. 이 시점에서도 거래량과 매출은 꾸준히 늘어났으며, 더 늦기 전에 리빌딩을 진행해야겠다고 판단했습니다.리빌딩의 목표당장 눈앞에 생겨나는 문제들로, 서비스가 해결하고자 하는 본질적인 문제들에 집중하지 못하는 상황입니다. 궁극적으로 이 상황을 개선하고 싶었습니다. 그리고 선택의 기로에 섰을 때 좋은 기준을 제시하기 위해, 언제 끝날지 모르는 리빌딩이 산으로 가는 걸 막기 위해 목표를 몇 가지 세웠습니다.유지보수 및 운영 이슈에 소모되는 개발 리소스 최소화커머스 시스템과 연계되는 기능들을 공격적으로 개발할 수 있도록 함개발 리소스 대비 높은 퍼포먼스를 낼 수 있어야 함튼튼한 커머스 시스템목표 1. 유지보수 및 운영 이슈에 들이는 개발 리소스 최소화기존 솔루션의 큰 레거시는 소모될 개발 리소스의 양과 일정을 예측하기 어렵게 만들었고, 개발자에게도 큰 스트레스를 안겨줬습니다. 서비스의 성장을 방해하는 큰 걸림돌 중 하나이며, 개발팀의 움직임을 느리게 만드는 주된 원인이었습니다. 리빌딩을 완료하더라도 유지보수와 운영 이슈는 끝이 없을 테지만, 더 이상 같은 문제를 반복하고 싶지 않았습니다. 효율적인 개발 리소스 운용을 위해선 가장 신경 써야 하는 부분이라고 생각됩니다.목표 2. 커머스 시스템과 연계되는 기능들을 공격적으로 개발할 수 있도록 함기존 솔루션 레거시가 너무 복잡하여 기능을 추가하거나 개선하기 어려워 반려한 요구사항이 많았습니다. 매력적인 요구사항에도 조심스럽게 대응했습니다. 서비스 성장을 위해 다양한 시도를 해야 하는 상황인데, 기술적인 이유로 진행이 까다롭다고 말하는 게 항상 아쉬웠습니다. 개발팀에서도 좋은 기능을 공격적으로 구현하고 싶으나, 실제로도 작업하기 까다로워 항상 답답했습니다. 어떤 방법이던 괜찮으니 지금보다 훨씬 더 공격적인 기능 구현으로 서비스 성장에 좋은 영향을 주고 싶었습니다.목표 3. 개발 리소스 소모 대비 높은 퍼포먼스를 낼 수 있어야 함스타일쉐어 팀은 기존 서비스 운영과 동시에 항상 새로운 무언가를 찾으려 합니다. 개발팀은 이 움직임에 맞춰 개발 리소스를 효율적으로 운용해야 합니다. 하지만 개발 리소스는 한정적이며, 다양항 상황에 따라 유동적으로 변해 예측하기 어렵습니다. 이런 상황에서 커머스 관련 작업 시, 언제나 평균 이상의 높은 퍼포먼스를 내고 싶었습니다.목표 4. 튼튼한 커머스 시스템커머스 시스템의 장애는 매출에 직접적인 악영향을 줍니다. 어떤 작업을 하더라도 커머스 시스템은 잘 운영되어야 합니다. 높은 가용성은 개발팀의 숙명이며, 공격적인 기능 개발에도 높은 가용성을 유지하려면 더욱 신경 써야 합니다.모두 꿈에 가까운 목표들입니다. 이 목표들에 조금이라도 더 가까이 다가갈 수 있도록 노력한다면 보다 좋은 결과를 얻을 수 있을 거라 생각했습니다.현실 반영과 계획당연하게도 현실적인 부분을 생각해야 했습니다. 이미 예정된 작업들이 많아 리빌딩에 필요한 개발 리소스를 확보하기 어려웠고, 개발 성공 여부 또한 불확실해 팀원들을 설득하기 어려웠습니다. 유지보수와 운영 이슈는 끝이 없었고, 회사 방향에 따라 추가 기능 개발과 개선 작업을 진행해야 했습니다. 이 상황을 고려해 리빌딩을 성공적으로 진행할 수 있도록 계획을 세워나갔습니다.개발 리소스에 여유가 생길 때까지 서브 프로젝트로 진행기존 커머스 시스템과 리빌딩된 시스템을 동시에 운영할 수 있어야 함적절한 단위로 서비스를 나눠 안전하고 효율적으로 개발 진행계획 1. 개발 리소스에 여유가 생길 때까지 서브 프로젝트로 진행다들 리빌딩이 필요하다고 느꼈지만, 선뜻 진행하기엔 큰 부담이었습니다. 시간이 흘러 여유가 생길 때 리빌딩을 진행해도 되지만, 그땐 너무 늦을 것 같았습니다. 최대한 빨리 작업을 시작하고 싶었고, 그러기 위해선 서브 프로젝트 수준으로 진행하는 게 제일 빠른 방법이라 생각했습니다.계획 2. 기존 커머스 시스템과 연동되어 동시에 운영할 수 있도록 함리빌딩의 완료 시점을 예측하기 어려웠습니다. 때문에 기존 커머스 시스템을 운영하며 리빌딩을 진행해야만 했습니다. 그리고 리빌딩된 시스템은 점진적으로 기존 커머스 시스템을 교체해 나가야 하므로, 두 시스템이 서로 연동되어야 했습니다. 또한 리빌딩된 시스템이 잘 동작할지에 대한 확신이 없어, 언제나 후퇴 계획을 세워야 했습니다. 이런 이유로 기존 커머스 시스템의 DB와 스키마를 그대로 사용하고, 두 시스템의 로직이 서로에게 문제가 되지 않도록 조심스럽게 개발하기로 했습니다.계획 3. 적절한 단위로 서비스를 나눠 안전하고 효율적으로 개발 진행커져가는 개발팀과 복잡해져 가는 커머스 시스템을 생각하면 요즘 자주 들리는 마이크로 서비스 구조(이하 MSA)를 도입해도 되지 않을까 싶었습니다. 솔직히 이런저런 이유보다, 재미 때문에 도입해보고 싶었습니다. 처음 도입하는 구조라 조심스러웠지만, 적절한 단위로 서비스를 나눈다면 충분히 좋은 효율을 낼 수 있을 것이라 생각되었습니다. 재미와 만족은 덤이고요. 서비스를 나누는 기준은 2가지로 잡았습니다.개발 안정성/개발 속도 둘 중 어느 것에 집중해야 하는가?서비스를 사용하는 주체는 누구인가?—개발 안정성/개발 속도 둘 중 어느 것에 집중해야 하는가?개발 안정성과 개발 속도에 대해 생각한 이유는 시스템 안정성과 작업 퍼포먼스 모두 잡고 싶은 마음 때문이었습니다. MSA는 서비스 별로 다른 언어를 사용해도 괜찮다는 장점이 있습니다. 덕분에 상황 별로 각기 다른 언어를 사용할 수 있고, 이를 통해 개발 안정성 혹은 개발 속도에 잘 집중할 수 있을 것이라 기대했습니다. 나중에 기술 스택을 설명하면서 얘기를 하겠지만, 개발 안정성을 추구해야 하는 부분은 java8로, 개발 속도를 추구해야 하는 부분은 node나 python으로 구현됩니다.서비스를 사용하는 주체는 누구인가?서비스를 어떤 기준으로 나눌지 고민이 많았습니다. 처음엔 상품 관리, 주문 관리, 출고 관리 등 DB 테이블에 가까운 기준으로 나누려고 했으나, 서버 운영이 큰 부담으로 다가올 것 같다는 의견 때문에 다른 기준을 세워야 했습니다. 서비스를 사용하는 주체 별로 나누면 어떨까라는 말이 나왔고, 이 기준이라면 큰 부담이 없을 것 같았습니다. 서비스를 사용하는 주체는 유저, 관리자, 입점사, 다른 서비스 이 4가지라고 정의했고, 이에 따라 서비스를 구성했습니다.—앞서 말한 두 기준으로 나눴을 때에 대한 예시입니다.유저 커머스 서비스 (node 혹은 python)관리자 커머스 서비스 (node 혹은 python)입점사 커머스 서비스 (node 혹은 python)커머스 핵심 기능 서비스 (java8)위 두 기준 말고도 서비스 운영에 큰 부담이 없다면 상황에 맞춰 다른 기준을 세워 서비스를 나누기도 했습니다.이 고민이 끝난 후, 현실적으로 실행 가능한 계획이 나온 것 같아 만족스러웠습니다. 이 계획을 토대로 아키텍처를 구성하고 개발을 진행했습니다.마무리어떤 문제 때문에 리빌딩을 결정했고, 어떤 목표와 계획을 세웠는지 주저리주저리 적어봤습니다. 앞에서 말했듯이 리빌딩은 아직 진행 중입니다. 현재 정식 일감으로 진행되고 있고, 상황에 맞게 계획을 다시 세워 조금씩 목표에 다가가고 있습니다. 처음엔 3부로 계획했지만, 아직 리빌딩 중이란 걸 까먹고 있었나 봅니다. 이 프로젝트가 완료되기 전까진 회고록으로써 글을 계속 쓸 것 같습니다. 앞으로 풀어야 할 문제들이 많으니 하소연할 것들도 많을 거고요. 아무쪼록 다음 편에선 시스템 구성도와 기술 스택에 대해서 한번 이야기해보려 합니다.스타일쉐어 개발팀의 고민과 생각들이 부디 도움이 되었길 빕니다. :)#스타일쉐어 #개발팀 #리빌딩 #인사이트 #조언
조회수 4048

PHP Codeigniter 환경에서 VUE 사용해보기

Overview이번에는 PHP Codeigniter 기반의 서비스에 VUE를 적용시키려고 고민했던 것들을 나누려고 합니다. VUE JS는 가상 DOM을 활용하여 실시간으로 반응 컴포넌트를 제작할 수 있는 프레임워크입니다. 또한, VUE-ROUTER 및 VUEX라는 컴페니언 라이브러리를 통해 url 라우팅 및 전역상태를 관리하기에도 탁월하죠. VUE와 다른 프레임워크와의 비교 부분은 여기를 참고해주세요. 브랜디의 관리자 서비스는 PHP Codeigniter 프레임워크로 제작되었습니다. 하지만 관리자 서비스의 규모가 점점 커지고 기능이 다양해지면서 “자주 사용하는 기능을 묶어 컴포넌트화하자!”라는 숙제가 남아 있었죠. 요즘 잠깐의 여유가 생겨 이때다 싶었습니다. 관리자 서비스에 VUE를 도입하기 위한 시도를 시작했는데요. 얼마 지나지 않아 문제점에 봉착했습니다. 바로 IE9.0…. 개발자의 숙적 IE가 또 한 번 발목을 잡았습니다. 임포트가 되지 않아….VUE를 좀 더 편리하게 사용하려면 JS의 모듈화가 필요했지만, ES2015에서는 import 혹은 require 구문을 지원하지 않아 불편하고, arrow 함수 또한 사용할 수 없습니다. 게다가 VUE의 JAX 탬플릿 구문을 사용할 수도 없었죠!! 뭔가 배보다 배꼽이 더 커질 것 같은 조짐이 보였습니다.결국 Webpack의 도움 없이 VUE를 적용하려던 시도는 여러 가지 난관을 만났고, Codeigniter 프로젝트 내부에서 Webpack을 사용하는 방법을 연구하기 시작했습니다. Webpack은 모듈 번들러입니다. Webpack의 메인 페이지를 방문하면 아래 네 개의 슬로건이 빙글빙글 돕니다.Bundle your scriptsBundle your imagesBundle your stylesBundle your assets아래의 이미지는 Webpack이 무엇을 하는 녀석인지 잘 설명해줍니다.Webpack은 실제로 번들러라고 광고하는것 처럼 Only Webpack 빌드만으로는 소스 파일들을 모아줍니다. 만약 webpack-dev-server로 실행하면 websocket을 통해 소스가 변경됐을 때 실시간으로 화면을 갱신해주는 개발 툴 제공 정도의 역할 밖에 없습니다. (…충분히 훌륭하잖아?)대부분의 기능은 엄청난 확장성을 가진 webpack의 설정으로 모듈로서 작동할 수 있죠. 예를 들면 Babel은 우리의 발목을 잡았던 IE를 위해 ES6로 작성된 js 문법을 IE에서 사용할 수 있는 ES5문법으로 너무나 쉽게 트랜스컴파일할 수 있습니다.하지만… 관리자 서비스는 위에서 언급했듯이 Codeigniter 기반입니다. 따라서 완벽히 VUE와 API서버를 분리하려면 로그인, 메뉴구성, 헤더, 푸터 등 PHP 기반으로 제작된 모든 기능들과 인증 등 기존 방식을 전부 새로 만들어야만 VUE를 온전히 사용할 수 있습니다.문제점들을 모두 해결하고 넘어가기엔 여유가 부족하기 때문에 조금씩 적용하자고 생각했습니다. 덕분에 webpack-dev-server의 실시간 소스 반영 기능을 포기해야만 했죠.(눈물) 우리의 서버는 node기반이 아닌 apache-php 기반이었기 때문입니다.자, 그럼 Codeigniter 프로잭트 하위에 웹팩을 포함시켜 Hello World까지 가는 짧은(?)여정을 시작해봅시다.Hello world로 가는 여정Node, npm 설치맥에서도 유사한 명령어로 제작할 수 있도록 CMD 위주로 진행하겠습니다. 먼저, 여기를 클릭해 Node를 설치합시다. 8.11.3 LTS버전으로 진행했습니다.맥에서는 Homebrew를 통해 간편하게~brew install node 설치 확인npm 잘 설치되었네요.web pack 폴더 생성 및 이동mkdir webpack cd webpack nom init으로 초기화npm init webpack, vue, babel 설치npm install -D webpack webpack-cli webpack-dev-server npm install -D vue-loader vue-template-compiler npm install -D babel-core babel-loader babel-preset-es2015 여기서 VUE는 설치하지 않습니다! 왜냐하면 VUE.js는 로딩만 하면 되고 필요하지 않습니다! (읭?) VUE는 Codeigniter view에서도 사용해야 하기 때문에 해당 view에서 import 해줍니다. 따라서 VUE 컴포넌트가 들어가는 시점에는 이미 전역에 vue.js 가 있습니다. 따라서 굳이 각 모듈마다 VUE를 import 했다가 webpack 설정에서 다시 vue.js를 제외할 필요는 없습니다.VUE와 template 태그를 로딩할 수 있는 로더도 설치하고, 트랜스컴파일을 위한 바벨, IE9를 지원하기 위한 es2015프리셋도 함께 설치합니다.webpack 빌드명령어 package.json의 script부분에 추가"scripts": { "build": "webpack --mode production", "build-dev": "webpack --mode development",   } 이제 VUE를 빌드할 명령어를 작성합니다. 위처럼 두 가지 명령어를 제작해두면, 추후 env를 통해 webpack.config.js를 분기시켜 원하는 환경으로 빌드할 수 있습니다. 또한 production 모드로 빌드할 땐 자동으로 옵티마이저 - uglify 내장 플러그인이 적용되어 익숙한 min.js형태로 빌드되며 development를 빌드할 땐 사람이 알아볼 수 있는 형태로 빌드되고, debugger 코드 또한 살아있습니다.weboack.config.js 작성const { VueLoaderPlugin } = require('vue-loader'); module.exports = {   entry: {     HelloWorld: './src/main.js'   },    module: {     rules: [       {         test: /\.vue$/,         loader: 'vue-loader',       },       {         test: /\.js$/,         loader: 'babel-loader',       }     ]   },    resolve: {     alias: {       'vue$':'vue/dist/vue.esm.js'     }   },    plugins: [     new VueLoaderPlugin()   ]  } webpack.config.js 가 없다면 생성한 후 위와 같이 작성합니다..babelrc 작성{     "presets": ["es2015"] } 테스트용 파일 작성1)main.js 작성import HelloWorld from './HelloWorld.vue' Vue.component('hello-world', HelloWorld); 2)HelloWorld.vue 작성 [removed] export default {   name: 'app',   data: () => {     return {       word1: 'Hello',       word2: 'World'     }   }  } [removed] 테스트 빌드npm run build-dev 빌드를 할 땐 기본적으로 ‘/dist/’ 하위에 소스코드가 떨어집니다. 자, 여기까지 진행하셨다면 폴더 구조는 다음과 같을 것입니다.지금까지 진행한 파일 모습입니다.뷰 컴포넌트가 잘 제작되고 등록되는지 확인하려면 기본 빌드 폴더인 dist 폴더에 Test.html을 작성해 브라우저로 열어봅시다.확인용 html 파일 작성<!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <title>VUE Test</title>     <!-- VUE 플러그인 -->     [removed][removed] </head> <body>                     [removed][removed]     [removed]         new Vue({             el: '#vue'         })     [removed] </body> </html> 잘 나옵니다.정상적으로 VUE가 적용된 것을 확인합니다.코드이그나이터 설치이제 코드이그나이터 프로젝트 내부에서 VUE 컴포넌트를 출력해보기 위해 코드이그나이터 프로젝트를 생성합시다. 먼저 Codeigniter와 XAMPP를 다운로드 받습니다.Codeigniter 받으러 가기XAMPP 받으러 가기프로젝트 폴더 하위에 Codeigniter 프로젝트용 폴더를 생성합니다.mkdir codeigniter-with-vue-webpack cd codeigniter-with-vue-webpack 다운받은 Codeigniter를 해당 폴더에 압축 해제하면 Codeigniter 설치가 끝납니다.XAMPP 설치 및 DocumentRoot 변경XAMPP를 설치하고 DocumentRoot를 테스트 프로젝트 폴더로 설정한 뒤 아파치를 실행합니다.Codeigniter 프로젝트가 생성되었고, 서버 실행이 완료되었습니다. webpack 폴더를 Codeigniter 프로젝트 하위로 이동node-modules는 너무 크기 때문에 기본 파일만 복사하고, npm install로 설치합니다.Codeigniter에서 VUE를 사용하기 위한 webpack dist설정기존의 프로젝트에서 스크립트를 모아두는 폴더 하위로 빌드 결과 파일을 보내기 위하여 webpack 빌드 시 dist 폴더가 아닌 /application/scripts/vue/hello_world 하위로 빌드 결과 파일이 생성되도록 설정합니다.// 기존 module.exports = {   entry: {     HelloWorld: './src/main.js'   },    //... 생략 } // 변경후 module.exports = {   entry: {     '../../application/scripts/vue/hello_world/HelloWorld.js': './src/main.js'   },    //... 생략 } Codeigniter의 load->view 기능을 활용하여 파일 작성1)header.php// application/views/common/header.php <!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <title>VUE Test</title>     <!-- VUE 플러그인 -->     [removed][removed] </head> 2)실제 view// application/views/vue/hello_world/vueTestPage.php <?php $this->load->view( 'common/header' ); ?> <body>                 [removed] [removed]     [removed]         new Vue({             el: '#vue'         })     [removed] </body> <?php $this->load->view( 'common/footer' ); ?> 3)footer.php// application/views/common/footer.php </html> 실제 프로젝트 구성과 유사하게 header, body, footer로 나누어 파일을 작성해봅니다. 실제로는 더 복잡하지만 이 정도만 나누겠습니다.Codeigniter 테스트용 컨트롤러 작성// application/controllers/Vue.php <?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');   class Vue extends CI_Controller {      public function index()     {         $this->load->view('vue/vueTestPage');     }  } 정말 심플(?)한 테스트용 파일 작성이 모두 끝났습니다! 이제 잘 작동하는지 확인해볼까요?코드이그나이터에서 helloworld 출력짜잔이번엔 문제의 IE에서 확인해봅시다.IE9.0 환경에서 확인IE에서도 무사히 출력되는군요. 이제 코드이그나이터 환경의 프로젝트에서도 IE까지 지원하며 무사히 VUE를 사용할 수 있게 되었습니다! (시간이 없어서 가상머신에 IE9가 설치된 윈도우7까지 테스트하진 못했습니다!) 모든 작업이 완료한 후, 파일 폴더 구조는 아래와 같습니다.붉은 네모 부분이 실제로 제작하거나 수정한 파일들입니다.Conclusion여기까지가 Codeigniter 프래임워크 환경에서 webpack + vue를 사용하기 위한 웹팩의 설정 과정 및 테스트 결과였습니다. php 서버를 사용해야 하기 때문에 webpack-dev-server의 핫리로드 기능을 사용하지 못하는 건 매우 안타까운 일입니다. 하지만 짧은 시간에 신기술을 도입하면서도 수많은 리스크를 회피할 수 있다는 건 나쁘지 않은 선택이라 생각합니다.위의 웹팩설정을 조금만 활용한다면 다른 프레임워크 프로젝트에서도 무리없이 VUE를 사용할 수 있을 겁니다! 비슷한 고민을 하셨던 개발자님들… 집에 가기 전 말고 오전에 Webpack을 설치해보세요. 안 그러면 저처럼 집에 못갈 수도 있으니까요!참고.gitignore 작성, index.php 제거 등은 내용에 포함하지 않았으며, 아래의 링크로 자세히 알 수 있음.Codeigniter index.php 없애기글강원우 과장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만 #브랜디 #개발자 #개발팀 #인사이트 #경험공유 #PHP

기업문화 엿볼 때, 더팀스

로그인

/