전체 피드 목록

지난 1월27일 오전10시 애플스토어가 상륙했지요. 몇몇 기사에서 볼 수 있듯 진풍경이 연출되었습니다. 인간복도, 끝도없는 줄, 한겨울노숙투혼, 가즈아 제창, 박수세례 등 사실 애플제품을 사용하지 않는 사람들 입장에선 저게 뭔데? 왜 저래? 라는 의문이 들 수 있는 장면들이었을 겁니다. 이와 같은 브랜드팬심은 사실 애플제품뿐만은 아니었습니다. 2015년 명동에서 발망과 H&M의 콜라보레이션 라인이 등장했을 때에도 노숙투혼 사진이 심심치 않게 올라왔습니다. 심지어 닷새가 넘게 기다린 사람도 있었죠. 뭐 이 때는 중고나라 되팔러들의 열정과 혼을 느낄 수 있는 이슈였다고 치지만, 그럼에도 뭔가 일반적인 경우는 아닌 것 같습니다. 쉐이크쉑버거가 처음 오픈 했을 때도 그러했고, 명동 유니클로는 히트택 세일할 때마다 사람들이 발을 동동 구르며 줄을 섭니다.어떤 브랜드에 열광하고 관심을 가지는 것은 그 정도의 차이가 다를 뿐 사실 누구에게나 하나쯤 애정하는 브랜드가 있기 마련입니다. 우리는 이를 취향이라고 부르기도 하고, 팬심, 덕심 등이라고 부르기도 하죠.애플스토어가 오픈했을 당시에는 역대급 추위가 대한민국을 휘감았던 날이었습니다. 거리엔 비둘기조차 돌아다니지 않는 거친 날이었죠. 하지만 덕심은 추위보다 강했던 모양입니다. 단순히 취향...이라고 하기엔 사람들의 행동이 뭔가 일반적이진 않았던 것 같습니다. 기사에 달린 댓글을 보니... 얼마 전 있었던 애플의 깜짝 배터리 이벤트 때문이었는지는 모르겠지만 대부분 부정적인 댓글들이 많더군요. 저는 개인적으로 디자인을 할 때 맥이 여러모로 편한 점이 있어서 사용하긴 하지만, 뭐 그렇게 덕력이 있다라거나 그런 것은 아닌터라 그저 '흠....' 하는 기분이었습니다. 오늘은 왜 사람들은 추위를 견뎌가며 줄을 서는가에 대해 생각해보도록 하죠 :)당시 33살이었던(나와 동갑...) 김정온 대표는 혼자 카페를 시작했습니다. 그리고 그곳은 1년만에 4개의 점포를 더 냈고, 2017년 10월 기준 32명의 직원이 있는 핫한 곳이 되었습니다. 당초엔 김포 본점으로 시작했습니다. 그러나 주말이면 사람들이 너무 많아 와서 문제(?)가 되어버렸죠. 폭풍입소문에 인스타에는 온통 인증샷으로 가득했고, 주변 도로가 마비되고 불법주차 때문에 경찰까지 나와서 교통정리를 해야하는 해프닝도 생겼습니다. 바로 '카페, 진정성' 의 이야기죠.카페, 진정성에 대한 이야기는 이미 너무 많은 인터뷰와 기사를 통해 등장한 터라 더 이상의 자세한 설명은 생략하도록 하겠습니다. 이 곳의 최대무기는 이름 그 자체입니다. 사람들을 줄 서게 만드는 힘은 '진정성'이죠. 먹거리는 정직함을 기반으로 합니다. 그 힘은 누구도 부정할 수 없죠. 품질과 서비스관리를 위해 100% 직영점으로만 운영하겠다는 철칙과, 재료선택, 제조방식 등 어느 것 하나도 타협하지 않는 고집스러움은 이 시대의 브랜드에게 새로운 메시지를 던져줍니다. 우리의 브랜드는 진정성이 있을까?... 그 진정성은 얼마나 고집스럽고 정확한 포인트를 향해있는지. 말입니다. 대부분의 사업은 모두 진정성있게 시작됩니다. 메시지가 있고 철학이 있죠. 그러나 문제는 그것을 유지하고 다른 색과 섞이지 않게 만드는 것입니다. '카페,진정성'이 밀크티가 대박쳤다고 해서 갑자기 밀크티 프랜차이즈 제품을 내버리고, 굿즈를 만드는데 신경쓰고 매장확장에 올인을 했다면 지금과 같은 곳이 될 수 있었을까요. 물론 앞서 말한 것들이 나쁜 것들은 아닙니다. 하지만 사람들이 우리 브랜드의 어떤 점을 사랑하는 지에 집중해야하죠. 카페,진정성의 매력은 그 고집스러움입니다. 내 몸에 들어가는 음식물이 무엇보다 정직한 것들로 정직하게 만들어졌다는 믿음. 저도 밀크티를 무척좋아합니다만, 진정성의 밀크티는 확실히 담백하고 맛있습니다. 그러나 마시는 순간 갑자기 용이 날아다니고 관자놀이에서 번개가 치는 비룡의 맛이 아닙니다. 그냥 맛있네~ 정도랄까요. 다만 24시간 내내 제조한 그 밀크티를 천천히 음미하는 그 자체에서 의미가 생깁니다. 특별한 밀크티를 마신다는 그 기분이랄까요. 그리고 그 기분이 거짓이 아니라는 데에서 만족감을 얻게 되죠. 인지부조화로 인한 묘한 불편함을 느낄 필요가 없다는 것. 브랜드의 힘은 여기에 있습니다.개인적인 의견입니다만 저는 맥북을 좋아합니다. 그러나 정확하게 무엇이 좋은지를 설명할 수 있죠. 음 물론 디자인적으로 예쁘고 패키지를 뜯는 과정에서 기대감을 증가시키는 등 뭐 그런 것들도 있을 수 있겠습니다만...사실 중요한 건 아닙니다. 만약 맥북이 여자친구고 그녀가 '내 어디가 좋아?' 라고 물어본다면 겁나 시크한 표정으로 '트랙패드' 라고 말할 것 같네요. 사실 맥프레를 샀다가 한 번 되팔았었는데 다시 구매하게 된 유일한 이유는 맥OS도 아니고 레티나디스플레이도 아닙니다. 트랙패드의 부들부들한 느낌이지요. 물론 스케치를 맥에서만 쓸 수 있고, 맥OS특유의 편리함들도 있겠지만 그건 부차적인 문제였습니다. 애플스토어 오픈이 난리가 났던 것도 한편으론 이해가 가긴합니다. 확실히 맥은 불편한 것과 단점투성이긴 하지만, 진짜 놓칠 수 없는 단 한가지를 만들어내는 묘한 매력이 있죠. 일반 삼성, LG, 레노버 노트북도 나쁘지 않습니다. 지금 이 글도 LG그램으로 쓰고 있으니 각자의 장단점이 있달까요. 하지만 확실히 일반 업체의 노트북은 평이하게 그럭저럭 좋은 수준입니다. 딱히 나쁜 것도 딱히 좋은 것도 없는 느낌이랄까요. 그램이 처음 출시됬을 땐 그 가벼움에 상당히 놀랐습니다만, 요즘엔 뭐 1kg 미만의 랩탑이 너무 많은터라 그램의 경량성이 크게 돋보이진 않더군요.우린 이것을 킬링포인트라고 불러야겠습니다. 제품과 서비스는 절대 완벽할 수 없습니다. 모든 사람을 모든 면에서 만족시킬 수도 없지요. 하지만 확실한 팬층을 만드는 것은 아주 강력한 하나의 킬링포인트가 있는가? 하는 것입니다. 떠났던 고객조차도 미련이 남아 다시 돌아오게 만드는 그 강력한 힘은 어디에서도 찾아볼 수 없는 독보적인 것이어야 하죠. 그리고 또 하나!단순히 독보적인 것 뿐만 아니라, 그것의 당신의 행동을 어떻게 바꿔놓을 수 있는지가 중요합니다! 가격이 싸다. 가볍다! 배터리가 오래간다! 이러한 각각의 특징들은 물론 있습니다. 모든 제품과 서비스엔 각자의 강점이 있기 마련이죠. 다른 제품보다 1,000원 싸다. 100g가볍다. 배터리가 2시간 더 오래간다....는 식의 포인트는 사실 큰 의미가 없습니다. 근소한 차이이거나 딱히 소비자에게 큰 변화를 줄 수 없는 포인트라면 Strength 에 적기 좀 애매한 감이 있죠.애플에서 맥프레를 설명할 때 마우스가 없어도 된다!...라는 걸 막 전면적으로 내세우진 않습니다. 매직마우스도 팔아야 하니까요. 하지만 써 본 사람들은 트랙패드가 얼마나 편한 지 몸으로 알고있죠. 그리고 노트북을 들고 다닐 때 마우스를 놓고 왔어도 전혀 불편하지 않다는 것에서 감화를 받습니다. 가방에 챙겨야 할 것이 하나 줄어드는 것이죠. 소비자는 이러한 행동을 통해 '든든하다.' '걱정없다.' 라는 생각을 합니다. 팩트여부를 떠나 본인에겐 그렇게 느껴지는 것이죠. 물론 맥프레는 고장나면 자비없는 나쁜놈이 되긴 하지만... 소비자 입장에서 이미 구매한 제품에 대해서 '고장나면 꽝이잖아!?' 라는 생각을 하진 않으니까요.(그래야 속이 편하거든요)유사한데 조금 더 나은 강점이 아니라... 우리만의 독보적인 킬링포인트는 무엇일까요? 떠나간 고객마저도 헤어진 전애인이 되어 '아직 파니...?' 라고 문자를 보낼만한 강력한 매력을 지니고 있나요?우리의 특별한, 올바른 가치관을 응원하는 브랜드가 있습니다. 자연파괴와 과도한 소비에 경종을 울리며 자신의 제품을 사지 말라고 캠페인 했던 파타고니아입니다. 2013년 한국시장에 진출한 이래 꾸준한 매출성장을 기록하고 있습니다. 저도 그 꾸준한 매출에 기여하고 싶었는데 가격이 후덜덜해서 파타고니아 조끼를 사지 못했습니다. 아니 사지 않는게 아니고 못사게 만들어버리면 어떻합니다 스탠리옹씨..ㅠㅠ 어쨌든 이는 저의 통장상태에 기인한 것이므로 각설하고, 파타코니아의 국내진출은 합작법인이 아닌 직진출로 진행되었는데 이에 대해 파타고니아의 빈센트 스탠리 CEO는 “장기적으로 보면 기존의 합작법인 보단 우리가 직접 시장을 책임지는 것이 낫다고 생각했다. 마케팅에 돈을 쓰기 보다는 구전으로 제품의 진정한 가치가 전달되도록 하고 인위적인 수요 창출보단 자연적인 성장을 기다리면 시장은 좋아질 것" 이라고 언급했습니다. 물론 우리 옷을 사지말라는 캠페인은 정말 멋진 캠페인일 수도 기막힌 마케팅 테마일수도 있겠지만 둘 중 어느 쪽이든 기업입장에선 자신의 철학을 노골적으로 드러냈다는 데에서 그 의의를 찾을 수 있겠습니다. 영국의 핸드메이드 화장품 브랜드인 러쉬는 화장품의 동물실험을 반대하며 천연재료로만 제품을 만들고, 심지어 동물실험 반대 엑스포를 열어 동물복지라는 진정성으로 소비자의 두터운 신뢰를 쌓으며 글로벌 브랜드로 성장했습니다. 개인적으론 향이 강려크해서 구매는 하지 않고 있고... 러쉬매장하면 떠오르는 게 매장앞에 거품가득한 세숫대야밖에 없으므로 짧게 줄이도록 하겠습니다. 저도 진정성있는 글을 쓰고싶...이처럼 요즘의 소비자들은 자신의 철학과 가치관을 드러내고 싶어합니다. 당신의 제품과 서비스를 이용하는 것을 통해서 말이죠. 난 돈관리를 철저히 하는 사람이야!...라는 걸 가계부앱을 사용하는 것으로 드러내고 싶어하고, 자기관리에 민감해~ 라는 가치관을 쥬스솔루션이나 밀스3.0을 쉑잇쉑잇하면서 드러냅니다. "너 그거 하는 사람이구나!"라는 말을 듣는 것이죠. 특별해지고 싶습니다. 아이덴티티를 드러내고 싶어하죠. 그리고 자신의 가치관을 대변해주는 브랜드가 생겨나면 그것을 찾습니다. 그리고 이 브랜드가 성장하고 함께하는 사람들이 많다는 데에서 희열을 느낍니다. 나와 같은 생각과 가치관을 지닌 사람들이 있는 곳이니까요.우리의 브랜드는 어떤가요? 우리 서비스/제품을 사용하는 사람들은 어떤 사람들인가요? 그들의 가치관과 철학을 대변해주고 있나요? 같이 만들어나간다는 것의 힘은 굉장합니다. 배민의 팬클럽인 '배짱이'는 초기 배민의 마케팅에서도 큰 역할을 했습니다. 팬클럽 내부 공모를 통해 당선된 문구들이 한 때 버스와 지하철을 휩쓸었잖아요. 2016년 상반기엔 배민의 흑자전환을 축하하기 위해 배짱이가 직접 '흙자 선물'을 선사하기도 했습니다. 기업의 흑자전환을 팬들이 축하해주는 이런 장면은 확실히 일반적인 일은 아니죠. 보통은 이 회사가 성장을 하는 지 안하는 지 관심도 없는 경우가 많으니까요. 팬클럽/소수마니아를 중심으로 한 함께하는 경영은 물론 리소스와 노력이 많이 들어가지만 그 파급효과는 정말 엄청납니다. 오히려 인플루언서나 연예인과 같은 공인들을 활용한 마케팅보다 훨씬 효과적일 때도 있죠. 참고 : http://blog.naver.com/PostView.nhn?blogId=smartbaedal&logNo=220910423476 롯데리아에선 지난 해 11월~12월까지 앱을 이용해 특정 햄버거 3종을 포함해 1만5000원 이상 구매한 소비자 중 134명을 추첨해 워너원 팬 사인회에 초대하는 행사를 열었습니다. 물론 이러한 노력은 확실한 결과를 맺었습니다. 라인프렌즈도 방탄소년단을 활용했고, 이니스프리도 워너원이 모델로 등장했던 ‘화산송이 컬러 클레이 마스크’로 300% 이상의 매출효과를 봤으니까요. 그러나 이러한 매출효과는 확실히 장기지속성을 띠기엔 좀 무리가 있습니다. 물론 제품자체도 좋고 연예인도 잘 활용한다면야 좋겠지만, 워너원 행사가 끝난 후에도 롯데리아를 갈지는 모르겠네요. 긁적이런 점에서 따끔한 소리와 응원을 함께 해주는 회사의 팬클럽은 연예인 못지않은 강력한 에너지원입니다. 수많은 사람들이 지켜보고 있는 만큼 단순히 순간적인 매출상승을 노린 노림수등은 통하지 않죠. 투자자보다 더 무서운 존재들이자, 연예인보다 더 든든한 존재랄까요. 우리 브랜드는 어떤가요? 애미야 여기 먼지가 있구나!를 외쳐줄 팬클럽이 있나요?

친숙한 MVC 패턴개발자라면 누구에게나 친숙한 MVC (모델 - 뷰 - 컨트롤러) 패턴은 꽤 오랜 시간 동안 사용됐고 아직까지 많은 개발자들에게 사랑받고 있는 패턴이다. 그 이유로는 이 패턴이 일단 진입장벽이 낮기도 하지만 코드 재사용성, 동시 개발의 용이성 때문이다. 만약 당신이 초보 iOS 개발자라면 높은 확률로 MVC 패턴을 쓰게될 것인데 그 이유는대부분의 예제 및 튜토리얼이 MVC 패턴을 쓰고 있고iOS의 IDE인 Xcode에서 (Swift 는 예외지만) 클래스를 생성할때 기본으로 이름에 ViewController라고 들어간다.위와 같은 이유로 많은 iOS 개발자에 영향을 주리라 생각된다. (2011년도부터 iOS 세계에 빠진 저자도 사실 iOS에서는 software architectural design pattern으로는 MVC가 넘사벽이라고 생가하고 있었기에) 문제는 상대적으로 복잡도가 높아지거나 코드의 양이 많은 제품의 개발에서는 생산성이나 가독성에 그다지 도움을 주지 못하는 데 있다고 생각한다. 예를 들어, 한 페이지의 복잡도가 높아지면 ViewController 파일 한 개의 코드 라인이 기하급수적으로 증가한다. 또 (코드 관리에 매우 신경을 쓰지 않는 이상) 객체 간의 통신 및 데이터의 통일성이 없어져서 가독성이 떨어지기 쉽고, 기능을 추가할 때 생산성이 점점 떨어지게 된다.왜 MVC 패턴은 이렇게 문제가 생기는걸까라는 질문에서부터 시작해보자.MVC 패턴, 도대체 뭐가 문제인가?!그림 1. 보편적인 MVC 패턴의 구조보편적으로, MVC 패턴의 구조는 위의 그림과 같다. 그림을 간단히 설명하자면:뷰에서 이벤트가 발생하면 컨트롤러에 알린다컨트롤러는 그것을 처리하고 모델에 업데이트를 하라고 전달한다.모델은 업데이트를 하고 컨트롤러에 다시 알린다컨트롤러는 모델이 업데이트되었다는 것을 뷰에 알린다뷰는 모델의 업데이트된 값에 따라 다시 뷰를 그린다그림 1과 위의 설명만 놓고 보면 각각의 역할이 명확하다고 생각한다. 구조가 복잡하지 않기 때문에 초보자들도 쉽게 이해하고 적용 가능하다는 것이 장점이다. 하지만 MVC 패턴은 객체 간에 어떤 방향으로 커뮤니케이션 해야 하는지에 대해서는 강제하지 않기 때문에 파생된 패턴들이 많이 있다. 실제로 구글에서 “MVC pattern”이라고 검색을 하면 위 그림과 다른 MVC 패턴 이미지들을 볼 수 있다. 그 한 가지 예가 밑에 그림 2이다.그림 2. 또 다른 MVC 패턴의 구조그림 2를 보면 그림 1과는 다른 커뮤니케이션 방향을 나타내고 있다. 바꿔 말하면 개발자가 원하면 언제든지 세 가지 구조 안에서 방향을 유동적으로 바꿔 써도 무방하다는 것이 된다 (그것이 원하는 MVC 패턴이든 아니든지 간에). MVC의 변형으로써는 여러 가지가 있지만, 대표적인 것들은 아래의 그림과 같이 MVP, MVVM 같은 것들이 있다.그림 3. MVC, MVP, MVVM 패턴의 비교실제 저자도 MVC 패턴이 커뮤니케이션 방향을 강제하지 않는 것과 관련해 문제를 겪은 경험이 여러 번 있었던 것을 기억한다. 한가지 예를 들어보자.ViewA.swift (뷰)protocol ViewADelegate { func updateA() } class ViewA : UIView { var delegate: ViewADelegate? //update through protocol func didClickOnA() { self.delegate?.updateA() } //update through notification //maybe same kind of update can happen in other views func didClickOnAA() { NotificationCenter.default.post( name: NSNotification.Name(rawValue: “updateFromA”), object: nil ) } func render(_ model: product) { //update based on model } } ViewController.swift (컨트롤러)class ViewController : UIViewController, ViewADelegate { Var viewA: ViewA? Var product = Product() func viewDidLoad() { self.viewA = ViewA() self.viewA.delegate = self // ... self.view.addSubview(self.viewA) } func updateA() { self.product.update(name: “aa”, version: “123”) self.viewA.update(self.product) //re-render viewA } } Product.swift (모델)class Product { var name = “” var version = “” init() { NotificationCenter.default.addObserver( self, selector: #selector(self.doSomething), name: “updateFromA”, object: nil) } deinit { NotificationCenter.default.removeObserver(self) } func update(name: String, version: String) { self.name = name self.version = version } func doSomething() { //do something… //notify viewA or any objects through notification } } 조금 극단적인 예처럼 보이긴 하지만 실제 개발을 하다 보면 충분히 일어날 수 있는 상황이다. 코드에 대해 간략하게 설명하자면:ViewA에서는 delegate와 notification으로 각각 ViewController와 Product에 이벤트를 날리고 있고ViewController에서는 delegate method를 구현해서 Product를 업데이트 후, 다시 ViewA를 그리라는 로직을 가지고 있다.Product 에서는 객체를 업데이트 할 수 있는 메소드가 있고 notification을 통한 업데이트를 하고 있다.이건 아주 간단한 예이지만 프로젝트가 커진다면 특정 이벤트에 대해 데이터가 업데이트되는 경로가 달라질 수 있다. ViewA -> Product -> SubProduct -> Product -> ViewA 의 경로라던가, ViewA -> Controller -> Product -> SubProduct -> Controller -> ViewA 의 경로 등이 가능하다. 이처럼 특정 이벤트에 대해 여러 가지 체인형식으로 업데이트가 이루어질 경우 그 경로를 일일이 추적하는데 시간이 걸릴 수밖에 없는 구조를 가지고 있는 것을 볼 수 있다.(프로젝트의 크기가 어느정도 커지게 된다면 이렇게 될지도 ㅎㅎ)이런 케이스가 발생하는 근본적인 이유는 결국 MVC 패턴의 장점이라고도 말할 수 있는 유연성과 양방향 커뮤니케이션 때문이다. 이 패턴 자체가 문제가 있는 것은 아니지만 결국 코드는 사람이 작성하는 것이기에 생산성과 가독성을 떨어뜨리는 결과를 초래할 가능성이 높다. 여기에서 우리는 기존 웹 개발에서 쓰이고 있던 Redux 도입을 생각하게 된 것이다.Redux는 무엇인가?Redux 로고Redux는 Facebook의 Flux 를 모태로 삼고 있고 예측 가능한 상태를 자바스크립트 프로그램에서 구현하기 위한 애플리케이션 아키텍쳐이다. Redux는 본래 자바스크립트에서 시작한 오픈소스 프로젝트이지만 다른 개발자들에게 영감을 주었고 2015년 말쯤 iOS 플랫폼에서는 ReSwift(Redux + Swift)가 생겨났다. ReSwift는 결국 Redux랑 크게 다르지 않고 Redux의 세 가지 법칙을 따른다.Single source of truth — 애플리케이션의 전체 상태(State, 또는 데이터)는 트리 형태의 하나의 저장소(Store)로 저장된다.Changes with pure functions — 상태 트리를 변경하는 리듀서(Reducer)는 순수 함수(pure function)이어야한다.Read-only states — 상태는 오직 액션(Action, 어떤 일이 일어날 것인지 설명할 수 있는 객체)으로만 변화가 가능하다.쉽게 말하자면 “Redux는 한 개의 상태 저장소를 가지고 있고 그 안에 있는 데이터만이 신뢰할 수 있으며 저장소의 상태는 오직 순수 함수인 리듀서를 통해서만 변화가 가능하다” 라고 축약 할 수 있다.그림 4 Redux 패턴의 구조위의 그림 4을 보면 충분히 프로그램의 흐름이 어떤 식으로 흐르는지 감이 왔으리라 생각한다.이벤트가 뷰에서 생성되면 그에 해당이 되는 액션을 통해 알린다.액션은 특정 리듀서에서 처리한다.리듀서는 액션에 따라 저장소를 업데이트한다.저장소에 변화가 오면 구독(Subscribe)을 하고 있는 모든 객체에 알린다.이것이 Redux의 커뮤니케이션 사이클이다. Redux만으로도 충분히 여러가지 블로그 주제가 나올 정도로 할 이야기가 많지만 여기까지만 하고, 좀 더 자세한 디테일을 알기 원한다면 옆의 링크를 클릭하시면 된다. :) -> 리덕스 공식 링크Redux vs. MVCMVC와 Redux에 대해 소개를 했으니 간단히 비교해 보자.The Flow — Redux는 데이터 및 애플리케이션의 흐름을 강제한다. 저장소의 변화는 오직 액션을 통해서만 가능하기 때문이다. 이와 다르게 MVC는 강제성이 없기 때문에 여러가지 파생 패턴이 생길 수 있다.Unidirectional flow — Redux에서 흐름은 액션으로만 변화가 일어나기 때문에 오직 한쪽으로만 흐른다. MVC에서는 양방향이 될 수도 있고 한 방향이 될 수도 있지만 보통 양방향이다.Stores — Redux에서는 상태 및 데이터가 하나의 저장소에 있기 때문에 관리하기가 쉬운 반면, MVC에서는 여러 군데에 상태가 분리되어 있기 때문에 동기화에 신경을 써야 한다. (로컬 데이터 스토리지를 쓴다면 문제가 해결되기는 하지만 패턴 이외에 추가적인 노력이 필요함)그 이외에 여러가지 다른 점이 있겠지만, 위의 3가지가 가장 다른 점이라고 저자는 생각한다.채널 데스크 iOS에 Redux를 적용하게 된 이유이제 MVC와 Redux의 차이점을 알게 되셨으리라 생각한다. 우리 팀이 채널 데스크 iOS에 Redux를 적용한 이유를 소개하려고 한다. 아직 모든 부분에 완벽히 적용한 상태는 아니지만 (부분적으로 Notification, Delegate 그리고 Reactive를 쓰고 있다) 그럼에도 Redux를 적용함으로써 얻는 이점이 많다고 느끼고 있다.Explicit data flow — 새로운 개발자가 왔을 때나 여러 명이 작업을 할때 애플리케이션의 전체 흐름을 파악하고 이해하기 쉽다.Unidirectional flow — 데이터 관련 부분을 전부 Redux로 대체하니 모든 데이터 흐름이 한 방향으로 강제되었다. 덕분에 데이터가 어디에서 왔고 어디로 가는지를 파악하기 매우 쉽다.Single storage — 한 곳에서만 데이터를 관리하기 때문에 데이터에 관한 부분은 리듀서만 잘 짜 놓으면 관리하기 쉬워진 점이 있다. Redux를 적용하기 전에 CoreData를 데이터 저장소로 쓰고 있었는데, 어느 시점에 어떻게 저장되는지 눈에 들어오지 않아 불편한 점을 Redux를 사용함으로써 해결할 수 있었다.Immutability and data consistency — 변경 가능한(Mutable) 객체는 보통 iOS 개발에서나 다른 플랫폼 개발에서 장점일수도 있다. 하지만 데이터의 일관성이 깨지기 쉽다. 만약 A에서의 데이터와 B에서의 데이터가 다르면 어떤 것을 신뢰해야 하는지의 문제도 생길 수 있다. 우리는 Redux의 저장소에 있는 데이터를 모두 변경 불가능한 객체(Immutable, Swift에서는 Struct을 쓴다)로 구현하여 이 문제를 해결하였다. 이 부분은 코딩할 때 불편한 점이 조금 있지만, 그 불편함을 감수할만한 가치가 있다고 생각한다.Predictability — 저장소는 오직 액션을 통해서만 변경할 수 있다는 점이 무엇보다 장점인 것 같다. MVC와 같이 데이터를 어디서든 변경할 수 있다면 데이터와 관련된 버그를 찾는 데 소비하는 시간이 길어지곤 한다. Redux는 어떤 액션이 어디에서 불리는지 아는 것만으로도 그 시간을 비약적으로 단축할 수 있다.Maintainability — 저장소, 상태, 액션 그리고 리듀서로 역할과 레이어를 분리하게 되니 보통 코드 라인이 100줄을 넘지 않는다. 그만큼 유지보수 비용이 적어졌다.Organized Code — MVC 패턴에서는 비지니스 로직이 뷰에 들어가는 경우가 있기도 했었는데 Redux의 가이드라인을 따름으로써 자연스럽게 대부분의 뷰는 그저 데이터를 받고 시각화하는 dummy 뷰의 형태가 되었다. 비즈니스 로직이 완전히 뷰와 분리됨으로써 뷰의 복잡도와 코드를 관리하기가 쉬웠다.ReSwift 도입 시 주의할 점ReSwift 도입을 고려하는 분들을 위해 몇 가지 주의할 점을 소개하겠다.Performance — ReSwift에서는 저장소가 변경될 때마다 newState: 메소드가 호출이 되어 화면을 업데이트할 수 있게 되어있다. 채널 데스크 같은 경우는 실시간 애플리케이션(Real-time application)이라서 API 이벤트와 Socket 이벤트가 자주 발생해서 저장소가 변경되는데, 도입 초기 단계에 이 부분을 간과해서 화면이 거의 멈출 정도로 퍼포먼스가 나오지 않았었다. 만약 ReSwift를 적용했는데 퍼포먼스가 나오지 않는다면 newState: 함수 부분을 최적화하거나 미들웨어(middleware)를 만들어서 batch 형식으로 액션을 처리하는 방식을 고려해봐야 한다.Not thread safe — ReSwift는 thread-safe 하지 않아서 초반에 알 수 없는 crash들이 자주 발생했었다. 저자 같은 경우는 ActionWrapper를 만들어서 액션은 항상 메인스레드에서 처리되도록 강제했다.글을 마무리하며..Redux는 이미 자바스크립트 개발에서는 React와 함께 많이 쓰이고 있지만 iOS에서는 아직도 생소한 아키텍쳐이다. ReSwift는 아직 2년도 되지 않은 프로젝트이고 자바스크립트에서 처럼 유용한 Redux 미들웨어도 많지 않다. 또한 인지도도 MVC, MVVM, MVP에 아직 미비한 편이다. 프로덕션에 참고할 만한 예제도 찾기 어려웠기에 초기 러닝 커브는 조금 있었던 것으로 회상한다. 그럼에도 불구하고 우리 팀은 ReSwift를 적용해 보다 깨끗하고 유지보수하기 쉬운 프로그램을 만들 수 있었고 만족하며 사용하고 있다. 기존 MVC의 불편함을 아시는 분들은 충분히 도입할 가치가 있다고 생각한다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지 #Redux

스토리 홈

인터뷰

피드

뉴스

나는 이 조직의 문화다, 나는 이 조직의 성장하는 문화다

누구에게 맞출 것인가?

미국 상표 등록을 무료로? 선착순 이벤트!

"안정적인 서비스 운영으로 더 나은 코인원의 가치를 고객들에게 전달합니다:D" - 플랫폼셀 김영민

이직 후, 어떤 변화가 있었을까

린더를 만들고 있는 이유 1.0

알버트 비어만 사장이 말하는 현대차그룹의 현재, 그리고 미래

태그솔루션의 투명디스플레이 이야기 (1)

[모바일 앱분석] Step1. MARKETING (마케팅 분석)

[인공지능 in IT] 인공지능과 저널리즘

마음속의 브랜딩: 우리는 왜 맥북을 살까

로봇 공학의 새로운 패러다임! 한화정밀기계의 협동 로봇을 만드는 로봇사업부 인터뷰!

채널 iOS에 Redux를 적용하게 된 7가지 이유.

변화하는 웹 플랫폼 따라가기

30CUT의 탄생, 그 모든 이야기

사내 공동구매는 더럽입니다!