전체 피드 목록

[뒤늦게 170624에 글 마무리. 20160701~20161231에 대한 이야기]지구의 초기 모습은 어땠을까? 우리가 현재 화성의 모습을 보는 그런 맨살의 행성의 모습이였을 것이다. 하지만 지금 우리가 우주에서 보는 지구의 모습은 매우 청롱한 색깔을 띄고 있고 그 지구 안에는 아주 다양한 생물들이 한데 얽혀 살아가고 있다. 이 지구를 현미경 렌즈로 들여다보자.지구안의 여러 생물들을 현미경으로 바라보면 서로 다른 원자물의 구성 결합으로 이루어져있다. 즉 서로 다른 여러 원자물 그리고 그로 인한 결합들이 다양한 생물 혹은 지구의 다른 모든 것을 만들어낸 것이다. 분명 초기에는 아무것도 없던 상태에서 원자 하나 둘이 생겨났었을 것이다. 그리고 각각 독립되어 원자들이 서로 연결되고 합쳐지며 (A, B, C가 있었다면 A+B, (A+B)+C .. 이런식) 더 다양한 원자들이 만들어질 수 있었을 것이다. 근데 이 각각의 A, B, C 들은 독립적으로 합쳐질 수 있었던 것이 아니라 이 서로 다른 원자들이 매개가 될 수 있는 매개체 원자가 필요했다. 그 원자가 바로 탄소다. 즉 탄소는 지구가 다양한 생태계를 가질 수 있도록 초기에 캄브리아기 대폭발 같은 촉매 역할을 한 것이라고 생각한다.필자에게는 이런 탄소가 바로 2016년이였던 게 아닐까 생각한다. 2016년은 탄소 원자처럼 앞으로의 나의 미래를 엄청난 다양성으로 만들어줄 그 기반(기초)를 제공해준 해였다고 볼 수 있다. 의식의 흐름 기법으로 쭉 글을 써가며 한 해를 정리해보려고 한다.필자는 매년 한 해에 두번의 평가(상반기/하반기)를 스스로 한다. 올해도 역시 2016년 상반기 평가를 하였고 지금은 하반기 평가를 하는 중이다. 16년도에 전반적인 평가를 본다면 숫자 위주로 단점을 개선하는 부분이 약했던 것 같다. 예를 들면 중요하게 생각하는 운동/책/영어에 대한 점진적인 개선들을 숫자로 파고들며 하지 못한 점이 아쉽다. 16년의 상반기 평가에서 하반기 목표를 1.영어 2.마케팅 퍼포먼스 3.회사 문화 개선 4.아버지 사업과 관련된 소통 크게 이렇게 4가지로 정리했는데 성공적이지 못했던 것 같다. 1번 2번은 스스로가 좀 더 신경쓰지 못했던 부분이라고 생각하고 3번 4번은 노력했지만 환경이 잘 따라주지 않았다.하반기를(7월~12월) 월별로 정리하면 7월/8월/9월은 Brich라는 스타트업에서 일을 하고 있었던 시기고 10월/11월/12월은 미래창조과학부가 지원금을 주고 독일 소프트웨어 기업 SAP가 주관하는 글로벌 창업 프로그램에 참여하여 반려견 분양 O2O플랫폼 프로토타입을 만들어 나갔고 그 서비스를 현재 계속 개발 중이다.[7월/8월/9월] - 10가지 느낀점1) 스파크랩 출신 JAME 대표님과 미팅. 대표가 어떤 철학을 가지고 있느냐에 따라 그 회사에서 내가 얼마나 성장할 수 있는지를 가늠할 수 있다. 실력은 나이에 영향을 받지 않는다. 매일 자신의 삶에서 몰입을 하고 있냐 못하냐가 중요하다.2. 고객 만족은 숫자를 증가시키지만 숫자의 증가는 고객만족과 일치하지 않는다. 회사는 고객의 만족을 위해 일을 하고 있는지 투자를 받기 위해 예쁜 그래프를 그리고 있는지 끊임없이 질문을 던져야 한다. 무엇을 위해서 일하고 있는가?3. 매출 압박은 금지다. 고객의 만족을 가지고 토론해야된다. 단순히 숫자가 커지고 있고 Q1 - Q2 그래프가 1차 증가함수 인지가 중요한 것이 아니다. 우리 고객들이 진심으로 만족하고 있는지를 생각해야된다.4. 자체 제품만으로 바이럴이 일지 않는다는 것은 그 제품 자체가 그만큼 가치가 없기 때문이다. 기본적으로 NPS의 개념이 전사적으로 공유되어있어야 한다. 새로운 고객이 회원가입하고 이 고객의 매출이 증가하고 그 숫자 자체가 중요한 것이 아니다. 우리 핵심 타겟층이 어떻게 자사 제품에 대해서 반응하고 있고 피드백을 주고 있는지 귀를 기울여야된다. 한달에 수백만원씩 결제하는 고객을 문전박대 하는 경우가 생긴다. 어이없게도 우리의 핵심 고객과 거리가 먼 신규 고객 유치를 위해서.미국의 advertising executive인 Jon Bond는 다음과 같이 말한다. 제품 그 자체만으로 바이럴할만큼 가치가 있어야 한다.Marketing in the future is like sex. Only losers will have to pay for it.5. 비즈니스에서는 피드백이 생명이다. 사내에서 아이디어 제안에 대한 피드백, 고객이 우리 제품에 주는 피드백, 파트너사가 우리에게 주는 피드백... 그 피드백에 느려지면 느려질수록 병들고 고여 썩는다.6. 제품의 팬심은 내부에서부터 출발해야된다. (힘들겠지만) 회사 동료들이 그 자체를 매우 사랑하고 그 친한 친구들 또한 매우 사랑하고 있어야된다. 그러면 더 깊이 있는 니즈를 반영한 프로덕트를 만들어갈 수 있다.7. 늘 질문해야 된다. 날마다 우리의 차별화는 더 우리의 존재를 더 두드러지게 하고 있는가? 경쟁사를 보고 매출을 단순히 증가시키기 위해 다른 제품들과 동질화 되고 있는가?8. 직장에 좋은 동료와 좋은 상사가 있는 지를 봐라. 그리고 그들을 성공시키고 그들을 박수받게하라. 그들이 당신의 성장의 키포인트다.9. 내부, 외부 모든 것은 영업이다. 그 영업도 내가 이기는 판을 만들어놓고 영업하면 이기는데 이길 수 있는 것도 지는 판에서 영업을 하면 진다. 완벽한 판을 만들고 승부하라.10. 팀원들이 업무에 몰입하는 라이프 스타일을 이해하고 그것의 맞춰서 질문 및 도움을 요청해라. [10월/11월/12월] - 10가지 느낀점1. 내가 힘을 빼야지 리더십이 생긴다. 그래야 포용할 수 있는 여유가 생긴다.2. 리더는 마지막에 먹는다. 제품과 팀원들이 더 돋보이게 하라.3. 동료를 어떻게 도울 수 있을지 어떻게 기분 상하지 않게 질문과 대답을(피드백) 할지 많이 고민해라.4. 살면서 정말 말도 안되는 최악의 사람을 만나는 일이 생긴다. 그냥 그것을 받아들여라. 그리고 그곳에 에너지를 쏟지 말고 더 좋은 생각에 에너지를 투자하라.5. 소통은 자주 할수록 좋고 솔직하게 할수록 좋다. 오해는 결국 소통되지 않은 것에서 생겨나는 것이다. 시각적인 도구를 사용하는 것도 좋은 방법이다.6. 복잡하면 안된다. 단순해야된다. 심플함에 집착해야된다. 말할 때 설득할 때 항상 명료해야한다.7. 성공적인 스타트업은 2가지다. 1) right problem을 누구보다 치밀하게 깊게 고민한다. 2) 그리고 이것을 풀어가는 모든 과정을 끝까지 learning이라고 생각한다. 어제보다 오늘, 오늘보다 내일 배우고 성장하는 것이 중요하다. 늘 우리는 틀릴 수 있다. 우리는 목표는 늘 '덜 실수'하고 '덜 잘못'되는 것이다. 8. 좋은 결과물을 내는 것은 좋은 사람을 먼저 모으는 것에서부터 시작한다.9. 매일 매일 매일 나 자신을 반성하고 돌이켜보아라 최선을 다하고 있는지. 내일은 어떻게 더 나은 사람이 될 것으로 다짐하고 있는가?10. 이 세계는 굉장히 큰 세계다. 글로벌한 마인드셋을 절대 잊지 마라. 목표는 반드시 글로벌이어야 한다.처음부터면 더욱 좋고 이를 수록 더욱 좋다. 실리콘밸리를 그 기억을 잊지 마라. 17' 에는 Peopet과 운동에만 집중할 생각이다. 나 또한 강아지 비즈니스를 할 줄은 정말 꿈에도 몰랐다. 물론 지금 단계에서는 사실 비즈니스라기보단 검증의 단계이긴 하지만 말이다. 난 언제나 패션을 사랑하는 사람이였고 패션에서 큰 판을 벌려 보려고 했기 때문에 지금 내가 '입고 있는 옷'은 조금 어색하게 느껴지기도 하다. 그러나 무척 다행히도 이 산업에 대한 동기부여와 문제 의식을 가지고 있고 움직이고 있고 내가 패션에 대한 열정이 이 산업에서 새로운 시너지를 발휘할 것으로 기대한다. 인생은 정말 정글짐인가보다 !운동(건강),영어,책 게을리 하지 않기.숫자로 최현일 라이프를 측정하며 예전처럼 더 체계적인 삶을 살아가기.제거하고 몰입하기.끝으로.. #페오펫 #peopet #2016년 #돌아보기 #운영 #스타트업 #성장 #인사이트

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