개발 피드 목록

1.intro: 애정하는 iOS, 애증의 Xcode프론트엔드 개발자가 가장 기쁠 땐 언제일까요? 여러 가지가 있죠. 직접 만든 스무스한 애니메이션을 볼 때, 고생해서 작업한 하드코어 고난도 레이아웃이 잘 작동할 때, 작업한 화면을 사람들이 ‘예쁘다ʼ고 말해줄 때 등등. 그러므로 iOS는 모든 프론트엔드 개발자가 동경하는 OS라고 말할 수 있습니다. 대부분의 굵직한 Transition들을 알아서 Animate해주고, 프레임레이트가 복잡한 레이아웃 효과도 부드럽게 표현해주기 때문에 ‘예쁘다ʼ, ‘쾌적하다ʼ는 말이 절로 나오는 OS이기 때문이죠. 물론 그만큼 손도 많이 갑니다. 사실 iOS는 신기한 점이 많습니다. Xcode를 사용하다 보면 Interface Builder에서 ctrl+드래그를 사용하여 Code로 Reference를 가져오는 방법부터 String값으로 찾아가는 Xib/StoryBoard 파일까지.. 다른 플랫폼 및 IDE에서는 겪어보지 못한 새로운 경험들을 만나죠. 덕분에 다년차 개발자의 멘탈도 Xcode-iOS를 만나면 탈탈 털립니다. 시간이 지나면 이 독특하고도 불편한 Xcode를 사랑하고, 저주하는 상황까지 생깁니다.그래서 오늘은 많은 iOS 루키들이 겁내고 괴로워하는 iOS의 Graphic Interface를 살펴보고자 합니다. 맨땅에 헤딩할 때 헬멧이라도 쓰고 있으면 그나마 덜 아프니까요.2.Point, PixelAndroid에서는 다양한 기종의 스크린을 지원하기 위해 자체적으로 dp라는 수치 개념을 만들어 사용합니다. 파편화된 디바이스들을 모두 지원하는 레이아웃을 구성하려고 고안한 효율적인 방법이죠. iOS에도 이와 같은 개념이 있습니다. 바로 포인트(Point)인데요. Xcode의 ImageAsset 파일을 열면 이런 것을 찾을 수 있습니다. 1X, 2X, 3X바로 이 화면에서 볼 수 있는 1x,2x,3x라는 문구가 포인트 개념을 설명하고 있습니다. 포인트는 디바이스의 물리적 픽셀을 2배, 3배로 압축해 사용하는 iOS 만의 독특한 단위입니다. 이 개념이 처음 쓰인 건 iPhone 4, 즉 레티나 디스플레이가 등장하면서부터 인데요, 기존의 iPhone 3Gs와 물리적 화면 크기는 동일한데, 4배의 픽셀 수를 가지는 레티나 디스플레이에 기존의 앱들을 그대로 보여주자니 픽셀 단위로 정의된 기존의 모든 이미지/레이아웃이 절반 크기로 줄어드는 문제가 발생했습니다. 따라서 별도의 작업 없이 디스플레이하기 위한 방법으로 고안된 게 바로 포인트입니다.포인트는 픽셀을 2배, 3배로 압축해 1포인트라는 단위로 규정하고, 그 단위를 Nib(Xib) 에디터 및 개발 과정에서 사용합니다. 앞으로 여러분이 iOS 개발을 하면서 접할 기본 단위는 바로 포인트가 될 겁니다. 2X 혹은 3X는 단어는 픽셀을 2배, 3배로 압축했다는 의미입니다. 개발자의 편의를 위해서 만들어진 개념이 오히려 개발자에게 혼동을 주는 아이러니한 상황이 펼쳐졌습니다. 사실 이 픽셀-포인트의 개념이 처음 등장했을 때는 꽤 편리했을 겁입니다. 당시만 해도 iPhone4와 iPhone3Gs의 해상도를 구분하지 않고 작업할 수 있는 획기적인 방법이었으니까요. 하지만 지금은 iPhone5, iPhone7 Plus, iPhone X 등 다양한 장비들이 등장했습니다. 그래서 iOS 개발자는 포인트를 단지, 픽셀의 또 다른 이름처럼 느낄 뿐입니다. 애플도 자신들이 이렇게 다양한 해상도의 iPhone을 출시하게 될 줄은 몰랐을 겁니다.애플의 해상도 춘추전국시대 / 출처: paintcodeapp3.Storyboard, Nib (Xib)iOS UI 디자인의 꽃이 무엇인지 묻는다면 그것은 단연 Storyboard와 Xib일 것입니다. Storyboard는 기획자들이 사용하는 그것과 유사한 개념입니다. 하나의 큰 틀에 화면 단위로 여러 장의 기획안을 놓고, 그것들의 시퀀스를 한 눈에 알아볼 수 있도록 하는 보드입니다.Storyboard는 Segue와 같은 시퀀스 설정을 직접 할 수 있고, 연결된 하나의 Flow를 시각적으로 펼치기 좋습니다. 프로토타이핑을 위한 적절한 툴인 셈이죠.UIStoryboard 예시 - 브랜디 iOS의 Main StoryboardNib(혹은 Xib, 이하 Xib로 지칭)는 조각조각 단위의 화면이나 재활용을 많이 하는 CollectionViewCell 등의 화면 작업에 적합합니다. 이 점이 Storyboard와는 다르죠. (CollectionViewCell에 대한 자세한 포스팅은 여기를 클릭하세요.)물론 Storyboard에서 할 수 있는 작업은 대부분 Xib로도 가능하지만, 각각의 용도를 다르게 해서 사용하는 경우가 많습니다. 예를 들어, 브랜디 iOS 프로젝트는 Storyboard에선 큰 틀의 화면을 다루고, Xib에서는 CollectionView Cell과 ReusableView, Custom Component등을 다루고 있습니다. UICollectionViewCell.xibStoryboard와 Xib로 인터페이스 작업을 할 때는 파일의 컨텐츠가 너무 비대해지지 않도록 조심해야 합니다. Storyboard가 비대해지면 많은 작업자가 동시에 파일을 수정할 수도 있는데, VCS를 사용하면서 Storyboard나 Xib 파일의 충돌이 발생하면 병합하는 과정이 매우 고통스럽습니다. 그러므로 Storyboard는 서로 충돌하지 않도록 더 큰 그림을 그리고, 해당 Storyboard를 Senior 개발자가 관리할 수 있도록 안전장치를 두도록 합시다. 야 이거 소스 건드린 사람 나와 Storyboard와 Xib는 기본적으로 XML 기반의 파일입니다. 혹시라도 충돌이 발생하면 UI로 확인이 불가능하기 때문에, Xcode에서 해당 Storyboard, Xib 파일을 우클릭한 후 Open As > Source Code 메뉴를 클릭하면 XML 형식으로 브라우징할 수 있습니다. 해당 충돌 부분을 찾아가서 수정하고 다시 확인하면 UI로 볼 수 있습니다.소스코드로 스토리보드 보기4.From Storyboard, to CodeStoryboard와 Xib에서 구현한 컴포넌트들을 ViewController의 SourceCode에서 다룰 일이 분명 생길 겁니다(언제나 그렇죠). 그럴 땐 Outlet이라는 개념을 이용해서 Storyboard 와 SourceCode를 연결하는데요.네, 코드가 아닙니다. 포토샵하는 기분으로 ctrl + 마우스 좌클릭 드래그를 해주시면 됩니 다. 이 기능은 다른 IDE에서 보기 힘든 건데요. 나름 쓸만합니다. 익숙해지면 여러 가지 컴포넌트, 유닛들을 Outlet으로 처리할 수 있습니다. 코딩을 자유롭게 할 수도 있고요. 예를 들어, LayoutConstraint를 Outlet으로 처리하면 해당 Constraint를 코드 시퀀스에 따라 자유자재로 변경할 수 있게 되는 것처럼 말이죠.물론 이보다 선행되어야 할 작업은 Storyboard에서 해당 ViewController가 연결될 ViewController를 지정하고, 해당 ViewController의 파일을 미리 만들어야 합니다.5.Extraction of ViewControllerStoryboard에서 ViewController A를 연결했는데, ViewController B 에서 ChildViewController로 ViewController A 를 사용하고 싶다면 어떻게 할 수 있을까요? (간장공장공장장) 당연한 이야기지만 코드를 통해 구현 가능합니다. 필요한 것은 Storyboard 파일명과, Storyboard에서 미리 지정한 ViewController A 의 Identifier, 두 가지입니다. Storybo/rd에서 ViewController A를 연결했는데, ViewController B 에서 ChildViewController로 ViewController A 를 사용하고 싶다면 어떻게 할 수 있을까요? 당연한 이야기지만 코드를 통해 구현 가능합니다. 필요한 것은 Storybo/rd 파일의 이름과, Storybo/rd에서 미리 지정한 ViewController A 의 Identifier, 두 가지입니다. instantiateViewController From Storyboard/** 현재 화면에 디스플레이중인 UIWindow 객체로부터 UITabBarController를 반환받는 메 소드 - parameter window: UIWindow - returns: UITabBarController */ fileprivate func tabBarControllerFromStoryboard() -> BRTabBarController { let storyBoard = UIStoryboard(name: "mainStoryboard", bundle: nil let viewController = storyBoard.instantiateViewController(withIdentifier: "mainTabBarController") return viewController as! BRTabBarController // 잘못된 viewController를 추출한 경우 nil exception } 비슷한 방법으로 Xib에 작성된 View도 추출할 수 있습니다. Xib파일 하나에 여러 View가 정의되어 있다면, 각각의 View를 필요에 따라서 사용할 수도 있습니다.Extraction From Xiblet nib = UINib(nibName: NSStringFromClass(BRDropdownSelector.self) let components = nib.components(separatedBy: ".").last!, bundle: nil) let view = components.instantiate(withOwner: nil, options: nil).last as! BRDropdownSelector // 잘못된 view를 추출한 경우 nil exception 6.LayoutConstraints For Flexible UI더 유연한 레이아웃 동작을 원한다면, Static하게 선언된 수치보다는 LayoutConstraint로 제한적 범위 안에서 유동적으로 동작할 수 있도록 View를 주물러 주는 게 좋습니다. 예를 들어, 어떤 두 컴포넌트 사이의 최대 너비를 100으로 지정하되, 컨텐츠 사이즈에 따라 더 작아질 수도 있도록 하려면, LayoutConstraints의 Less than or Equal기능을 사용하는 것처럼 말이죠.Less than or equalLess than or Equal뿐만 아니라 Greater than or Equal도 존재합니다. 상황에 맞게 사용하는 지혜가 필요하죠. LayoutConstraint에는 Multiplier라는 개념도 있습니다. 만약 컴포넌트 A 절반 너비의 컴포넌트 B를 작성하고 싶다면, 그리고 이 조건이 화면 크기와 관계없이 동일하게 적용되기를 원한다면, 컴포넌트 B의 너비를 컴포넌트 A와 동일하게 Constraint로 지정하고, Multiplier를 0.5로 지정하면 됩니다. Multiplier는 단어 그대로 ‘배수ʼ라는 의미입니다.이처럼 화면 해상도에 구애받지 않는 유연한 UI를 작성하고 싶다면 LayoutConstraint 의 사용은 필수입니다. 브랜디 iOS 앱이 다양한 해상도의 iOS 디바이스에서 동일한 비율 로 출력되는 것도 이러한 LayoutConstraint를 사용했기 때문이죠.7.View를 핸들링할 그곳앞서 정리한 방식들을 사용해서 Storyboard, Xib 파일을 훌륭하게 작성했다면, 이제는 ViewController의 소스코드로 돌아올 차례입니다. View Size를 이벤트에 따라 변경하거나, 숨겼던 View를 보여주는 등의 작업들을 할 차례입니다.Storyboard나 Xib에서 작업한 View를 코드 상에서 다룰 일은 많습니다. 99.78% 이상 ViewController에서 View를 다루어야만 하죠. 무조건입니다.viewDidLoad() 에서 View는 대부분의 초기화 작업을 합니다. 그것은 소스코드를 다루는 개발자에게도 마찬가지죠. Storyboard에서 연결한 Outlet들도 이 Function에서부터 nil값이 아니게 됩니다. 따라서 뷰에 필요한 초기화 작업 (Button의 Title 지정, ImageView의 이미지 지정 등) 을 viewDidLoad()에서 모두 하면 됩니다. viewDidLoad()는 그 이름처럼 ViewController가 생성되었을 때 단 한 번 호출됩니다. 다시 거치지 않는 코드이기 때문에 ViewController에서 사용할 변수들을 초기화하는 등의 작업도 이 자리에서 할 수 있습니다. viewDidLoadoverride func viewDidLoad() { super.viewDidLoad() /* do 초기화 in 여기 */ } 다만 여기서 아무리 해도 안 되는 작업이 있습니다. View 사이즈를 해상도에 맞게 변경하는 작업 같은 것 말이죠. LayoutConstraint를 통해 지정된 사이즈를 가져올 때, 화면을 꽉 채우도록 Constraint를 지정해도 로그를 찍으면 엉뚱하게 더 적은 값 이나 큰 값이 나올 수도 있습니다. 이런 경우에는 아무리 viewDidLoad()에서 열심히 Constraint의 값을 가져와도 결과가 똑같을 겁니다.개미지옥override func viewDidLoad() { super.viewDidLoad() // 백년동안 코딩해도 화면 해상도가 다르게 나와요 } viewWillAppear() 에서는 viewDidLoad()에서 작동하지 않던(?) 코드를 적용할 수 있는 자리입니다. Constraint들로 지정된 사이즈들은 viewWillAppear()에서부터 각 디바이스의 해상도에 맞게 적용됩니다. 여기서부터는 화면 크기에 맞춘 SubView들의 사이징이나 Constarint들로부터 추출한 값이 의미가 있습니다.viewWillAppearoverride func viewWillAppear() { super.viewWillAppear() // 이제 아마 화면이 나올 차례인가봐요 } viewDidAppear()는 출력된 화면에 실행할 코드를 작성하는 자리입니다. 화면이 등장한 이후 보여줄 팝업창이나, 튜토리얼을 출력하는 건 여기서 해야 합니다. viewWillAppear()는 예상되는 출력 화면에서 호출되기 때문에, 실제로는 화면이 없는 상황에서도 호출될 수 있습니다. 만약 해당 viewController의 출력이 확실히 완료된 후 에 실행되어야 하는 이벤트라면, 이 Function에서 코드를 작성해야 합니다. viewDidAppearoverride func viewDidAppear() { super.viewDidAppear() // 화면 출력이 끝났답니다. 마음껏 코딩하세요! } 네, 지금까지 루키들을 위한 GUI 만들기의 기본 과정은 다 알려드렸습니다. 많은 개념과 기능, 방법론이 존재하지만 일단 이 정도면 알아도 첫 번째 iOS 앱 UI를 만들 준비는 어느 정도 마친 겁니다. 그럼 마지막으로 UI를 구성하면서 유용하게 사용할 수 있는 팁을 알려드리겠습니다. 8.Little Tricks1) Clip it, or not Clip it.ImageView를 다루다 보면 자주 발생합니다. 지정된 ImageView의 사이즈보다 이미지가 크면 이미지가 ImageView의 영역을 빠져나가버리는 건데요. 이것은 Label이나 View에서도 동일합니다. 작성한 컨텐츠가 부모 View보다 큰 경우 부모 View의 프레임을 벗어납니다. 이런 경우, 재부팅하세요. clipsToBounds 값을 true로 지정해주면.. view.clipsToBounds = true 매-직! 이 작업은 코드뿐만 아니라 Storyboard상에서도 가능합니다. Xib에서도 동일합니다. Storyboard에서 클리핑2)Circular View요즘 많이 사용하는 동그라미 모양 프로필 이미지 때문에 고생하는 고심하는 개발자들이 많을 겁니다. iOS에서는 이 작업을 view의 Layer를 편집하는 방식으로 아주 간단하게 처리할 수 있습니다.self.layer.cornerRadius = self.frame.size/2.0 self.layer.masksToBounds = true self.clipsToBounds = true 위의 코드를 사용하면 아래와 같은 이미지를 출력할 수 있습니다.둥글게 클립핑된 최신 트렌드의 ImageView를 간단하게 출력했습니다. 물론 위에서 언급한 clipsToBounds 값을 true로 지정해주는 것도 잊지 마시고요. 이 코드를 응용하면 모서리가 둥근 직사각형 뷰도 만들 수 있습니다. 원하는 곡률을 적용할 수 있죠. view의 Layer를 다루는 방법을 공부한다면 다양한 상황에서 유용하게 사용할 수 있을 겁니다.3)NSAtrributedString 클라이언트가 다양한 형태의 Font, Color의 텍스트를 한 문장에 넣어달라고 한다면 어떻게 작업해야 할까요? 스타일마다 Label 묶음을 만들어서 각각의 단어를 지정해주는 방법이 있습니다. 하지만 텍스트 또는 문장 구성이나 스타일이 서로 다른 묶음으로 변경된다면 어떨까요? 또 다시 새로운 기준으로 Label 묶음을 만들어야 할까요? 이럴 때 사용하기 좋은 녀석이 바로 NSAttributedString입니다. 볼드체, 보통체가 혼합된 텍스트에 색상이 다른 텍스트가 혼재되어 있는 Attributed String이렇게 다양한 형태의 텍스트를 한 문장에 담을 수 있고, 변경되는 내용이 있더라도 코드로 간단하게 수정하면 됩니다. 브랜디 앱에서도 NSAttrributedString을 많이 사용하고 있습니다. 브랜디 iOS 앱의 간지나는 UI 속 요소요소를 차지하고 있는 중요한 녀석이죠. 4)Debug Wirelessly 각종 케이블이 난잡하게 널부러진 책상을 보면 한숨이 나옵니까? 걱정하지 마세요. 이제 하나는 줄일 수 있을 겁니다. Xcode로도 무선 디버깅을 할 수 있기 때문이죠. 먼저 디바이스를 맥에 연결하고, Xcode가 활성화된 상태에서 Window > Devices And Simulators 항목을 클릭합니다. Devices and Simulators그런 다음 출력된 화면에서 원하는 디바이스를 선택하고 Connect via Network를 체크 합니다. (디바이스에 암호가 설정되어 있어야 합니다.) 지구본 모양이 디바이스 오른쪽에 있다면 무선 디버깅이 가능한 상태입니다. 무선디버깅체크9.Outro: 긴 글을 마무리하며아장아장 걸음마 시절이던 첫 개발 프로젝트 작업이 생각납니다. 클라이언트는 끝도 없이 요구를 하는데 구현하는 방법을 몰라 막막했던 적이 많았습니다. 여러 실수를 겪고 나서야 많은 것을 알게 되었죠. 그때를 생각하면 이제 막 iOS 개발을 시작하는 분들께 하나라도 더 도와주고 싶답니다. 지금 막 iOS 개발자가 되었나요? 그렇다면 이 포스팅은 분명 당신의 검색 한 번, 실수 한 번을 줄여줄 수 있을 겁니다.글이정환 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #iOS

지난 1월 말, 새해를 맞아 잔디에 새로운 기능이 업데이트되었습니다. 바로 잔디 커넥트에 관한 내용인데요, 협업에서 많이 쓰이는 몇 가지 외부 서비스를 잔디와 쉽게 연동해서 더욱 효율적인 업무 커뮤니케이션을 할 수 있게 되었습니다. 많은 고객분들이 이번 업데이트를 기다려주신 만큼, 저희 개발팀 또한 기대에 보답하고자 지난 몇 주의 스프린트 동안 열심히 준비했습니다. 이번 글에서는 커넥트 동작 방식을 설명하고 그 개발 과정에서 저희가 겪은 시행착오를 비롯한 여러 값진 경험들을 공유하고자 합니다.Integration? Webhook!연동: [기계] 기계나 장치 따위에서, 한 부분이 움직이면 다른 부분도 함께 잇따라 움직임.앞서 말한 대로 잔디 커넥트는 여러 웹 서비스들과 잔디를 연동할 수 있는 기능입니다. 서로 다른 웹 서비스를 연동하기 위해선 한 서비스 내에서 특정 이벤트가 발생 했을 때 다른 서비스로 해당 이벤트를 알려주는 연결 고리가 필요합니다. 이때 해당 연결 고리 역할을 위해 대표적으로 사용되는 기법이 웹훅(WebHook) 입니다. 웹훅은 user-defined HTTP callbacks, reverse APIs 등으로 불리는데, 간단히 설명하자면 웹 서비스에서 공개한 API가 아닌 사용자가 직접 지정한 주소(URL)로 특정 이벤트가 발생 시 HTTP Request를 보내주는 기법입니다. 예를 들어,새로운 일정이 등록된 경우(Google Calender)요청한 Pull Request가 Merge된 경우(GitHub)카드에 새로운 코멘트가 작성된 경우(Trello)이러한 이벤트가 발생했을 때 사용자가 매번 이벤트가 발생했는지 확인하지 않아도 서비스가 먼저 알려줄 수 있도록 일종의 알림을 등록하는 것이죠. 잔디 커넥트는 이와 같은 특징을 이용해서 각각의 웹 서비스에서 제공하는 웹훅을 잔디의 메시지 형태로 전달하는 기능입니다.일반적으로 웹훅은 이벤트에 대한 알림을 외부로 전달하는 것을 말합니다. 이 부분에서 중요한 것은 전달 방향인데, 서비스 내부에서 외부로 전달하기 때문에 이를 Outgoing Webhook으로 부르기도 합니다1. 같은 맥락에서 반대로 생각해보면 외부에서 서비스 내부로 특정 데이터를 전달하는 경우이니 Incoming Webhook이 됩니다. 앞서 웹훅을 reverse API라고 했는데 이를 다시 뒤집으니 결국 서비스 내부로 통신하는 제한적인 API와 같은 역할을 합니다. 굳이 용어를 구분한 이유는 API와 달리 접근하려는 서비스의 별도 인증 절차를 거치지 않고도 사용자가 생성한 웹훅의 URL을 인증 토큰으로 사용하며 약속된 Request Body 포맷만 알고 있다면 자유롭게 사용할 수 있기 때문입니다.개념 설명이 다소 길어졌지만, 이번 잔디 커넥트 기능에 대해 용어나 개념이 낯설다는 피드백이 생각보다 많았기 때문에 이번 글을 통해 더 많은 분들이 웹훅을 이해하는 데 도움이 될 수 있으면 좋겠습니다.구현에 앞서서비스를 운영한지 1년 정도 지난 시점에서 저희 내부적으로는 백엔드의 기술 스택 변경 및 각 서비스 분리에 대한 갈증이 있었습니다. 하지만 이미 서비스를 운영 중이기 때문에 안정성이 최우선시 되는 만큼 꽤 부담스러운 숙제로 미뤄둘 수밖에 없었고요. 때마침 커넥트 기능은 숙제를 시험해볼 만한 좋은 기회임에는 분명했지만, 새로운 기술 스택을 바로 서비스에 적용하기엔 오히려 개발 효율이 떨어질 것이라는 판단하에 일단 서비스 분리에만 집중하기로 했습니다.기본적으로 API와 DB를 기존 서버와 분리하고 웹훅 데이터를 저장하기 위한 큐와 해당 데이터를 처리하는 배치 서버 또한 모두 기존 서비스와 분리해서 최대한 결합도를 제거했습니다. 이런 설계 덕분에 추후 사업 전략이나 각 국가의 특성에 맞춰 커넥트 기능을 어렵지 않게 포함하거나 제외할 수 있게 되었습니다. 전반적인 저희 잔디 백엔드 아키텍쳐에 대해서는 아직 한 번도 소개 해드린 적이 없으니 다음에 따로 주제로 선정해 집중적으로 다뤄보도록 하겠습니다.동작 방식잔디 커넥트가 동작하는 방식은 기본적으로 다음과 같습니다.Incoming Webhook URL 생성 - 외부 서비스 웹훅 등록 - 웹훅 수신 - 메시지 작성 연동 대상 서비스마다 조금씩 차이가 있지만, 기본적으로 모두 위와 같은 방식으로 동작하기 때문에 단계마다 나누어 설명하겠습니다.1. Webhook URL 생성Webhook URL은 https://wh.jandi.com/connect-api/webhook/{teamId}/{webhook-token}와 같은 형태로 생성됩니다. hostname을 별도로 설정함으로써 기존 API 서버와의 분리는 물론이고, nginx의 Limiting the Request Rate 설정을 이용해서 호출되는 웹훅 요청 수를 효과적으로 제한할 수 있었습니다. webhook-token은 중복을 피하면서 각 웹훅에 대한 유효성을 검증할 수 있도록 여러 키를 조합한 md5 hash 값을 이용했습니다.이렇게 생성된 URL은 Incoming Webhook 뿐만 아니라 Google Calendar 등의 서비스에 등록하는 콜백 URL로 사용합니다.2. 외부 서비스 웹훅 등록웹훅을 등록하는 방법은 서비스에 따라 API를 이용하거나 수동으로 직접 등록할 수 있습니다. 사용자가 직접 웹훅을 등록하는 방법은 웹훅 URL만 생성해서 전달하면 등록 과정의 추가 처리가 필요 없어서 간단하지만, 서비스마다 등록하는 방법이 조금씩 다르고 다소 복잡하게 느껴지는 문제가 있습니다. 반대로 각 서비스에서 제공하는 API를 이용해 웹훅을 등록하면 사용자의 부담을 많이 줄일 수 있지만, 그만큼 내부적으로 처리해야 할 작업이 많아집니다. 그래서 구현 초기에 꽤 많은 시간을 투자할 수밖에 없었고 그 과정에서 아래와 같은 어려움을 겪었습니다.웹훅 관련 API를 사용하려면 먼저 인증을 받아야 하는데 서비스마다 제공하는 인증 방식이 조금씩 달라서 이를 통합하는 모델을 만들기가 쉽지 않았습니다. 요약하자면 기본적으로 accessToken을 사용하지만, 인증 방식에 따라 부가적으로 필요한 데이터가 서로 조금씩 다른것이죠. 가령, 구글캘린더는 만료 일시와 토큰 갱신을 위한 refreshToken 값을 별도로 갖고 있어야 합니다. 또 한가지 놓치기 쉬운 부분은 인증 폐기(revoked) 관련한 데이터 처리인데 저희가 경험한 바로는 인증이 폐기되었을 때 별도로 웹훅 알림을 주지 않기 때문에 반드시 인증의 유효성을 확인하는 추가 로직이 필요합니다.대부분의 사무실이 그렇듯이 저희 또한 공유기를 이용해 내부 네트워크를 구성하고 있습니다. 게다가 백엔드 파트는 개개인의 로컬 가상 서버에 동일한 환경을 설정해놓고 개발을 하므로2보통 경우엔 외부(public network)에서 들어오는 요청을 받을 수 없습니다. 그렇다고 매번 외부 네트워크에 있는 서버에 배포 후 테스트하기가 어려우니, 저희는 각 로컬 서버마다 고유 포트 번호를 나눠 갖고 WAN이 물린 공유기의 포트 포워딩을 알맞게 설정한 뒤에 네트워크 터널링 유틸리티인 ngrok을 이용해 내부와 연결되는 public 주소를 생성해서 외부 서비스와 문제없이 통신할 수 있었습니다.3. 웹훅 수신웹훅을 통해 들어오는 Request는 일단 정상 응답을 하는 게 좋습니다. 서비스마다 최초 웹훅 등록 시 유효한 URL인지 확인하는 테스트 요청을 하는데 이때 정상 응답을 하지 못하면 아예 등록조차 처리되지 않습니다. 또한, 정상적으로 등록된 이후 특정 이벤트에 해당하는 웹훅 요청에 대한 응답에도 주의할 필요가 있는데, 만약 에러 응답이 반복되면 일정 시간 동안 각 서비스에서 아예 해당 웹훅을 발송하지 않도록 제한이 걸려 더 이상 테스트를 진행할 수 없는 경우도 있었습니다.따라서 일단 웹훅 요청이 들어오면 teamId와 webhook-token 값으로 올바른 웹훅인지 검증한 후 서비스별 큐에 Request header와 body를 포함한 데이터를 전달한 뒤 바로 응답하고, 큐에 쌓인 데이터는 커넥트 종류별로 배치 서버가 돌면서 처리하게 됩니다. SQS를 사용함으로써 늘어나는 데이터에 대한 안정성을 확보하고 각각의 배치 서버를 독립적으로 분리해서 구현함으로써 자연스레 확장성(scalability)도 보장할 수 있게 되었습니다.4. 메시지 작성웹훅 데이터를 잔디의 메시지로 변환하는 역할은 배치 서버가 담당합니다. 서비스별로 데이터 포맷이 다르므로 해당 데이터를 파싱 및 처리하는 Worker 또한 각각 구현했습니다. 사실 커넥트 기능에서 가장 핵심적인 역할을 하는 부분인 만큼 가장 많은 공수가 드는 작업이였던 것 같습니다.서비스마다 정해놓은 웹훅 이벤트와 잔디 커넥트에서 제공하고자 하는 알림이 서로 완전히 일치하지 않아서 이를 서로 연결하는 작업연동 서비스의 문서가 잘 정리되어 있지 않아서 일일이 필요한 동작을 취하고 그에 따라 들어오는 데이터를 정리하는 작업잔디 계정 언어에 따라 메시지 L10N3을 적용하는 작업커넥트 메시지를 전달하기 위해 기존 멤버와 다른 커넥트 봇을 구현하는 작업등 요약하기 어려울 정도로 크고 작은 이슈들이 많았습니다. 그 내용이 너무 다양해서 모두 상세히 기록하긴 어렵지만, 개중에 도움이 될만한 내용을 추려서 아래 따로 정리했으니 관심 있으신 분들은 참고하시면 좋을 것 같습니다.서비스별 집중 탐구커넥트 구현 일정을 최대한 앞당기기 위해 저희는 개발자들끼리 각각의 커넥트 종류 별로 전담해서 작업하는 전략을 취했습니다. 제가 대표로 글을 작성하기는 하지만 보다 정확하고 구체적인 정보를 전달하는 것이 좋겠다는 생각에 개발을 담당하신 분들과의 짧은 인터뷰 형식을 빌려 공유하겠습니다.- Google CalendarQ. 기술적으로 난이도가 높았던 작업을 소개해달라.전반적으로 어려운 작업이 있었다기보단, 캘린더 특성상 세세하게 처리할 부분들이 많아 설계와 구현이 어쩔 수 없이 복잡해졌다. 가장 골치 아팠던 작업은 일정 알림을 타임존(Time Zone)에 따라 각각 알맞은 시간에 전달하는 작업인데, “잔디 계정의 타임존”, “구글 캘린더의 타임존”, “개별 일정의 타임존” 이렇게 3가지를 모두 고려해서 경우마다 기준이 되는 타임존을 결정하는게 엄청 까다로웠다. 심지어 구현 후 테스트를 하는 과정에서도 출력된 시간이 올바로 표시된 것인지조차 헷갈려서 디버깅하는데 한참 고생할 수 밖에 없었다.웹훅을 등록하고 관리하는 부분도 꽤 복잡했는데, 구글 답게(?) 웹훅에도 만료 기간이 존재한다는 것이 포인트다. 때문에 만료되기 전에 반드시 재등록 및 과거 웹훅 삭제 작업을 하는데, 효과적으로 처리하기 위해 “웹훅을 받을 때마다 만료 기간을 확인”, “등록된 일정이 많지 않아 웹훅을 받지 못하는 경우도 있으니 별도의 배치서버가 하루 단위로 확인” 이렇게 두 가지 로직을 넣어서 자동으로 웹훅을 유지하도록 구현했다.또한, 다른 연동 서비스와 달리 구글은 웹훅 콜백으로 들어오는 요청에 해당 이벤트에 대한 데이터를 직접 담아주지 않기 때문에 key를 가지고 한 번 더 API 호출을 통해 필요한 데이터를 가져와야 한다는 점도 주의해야 한다. 요청해야 할 API 문서는 비교적 잘 정리된 편이지만, 같은 요청에 대해서도 인자를 어떻게 보내는지에 따라 그 응답이 제각각이기 때문에 응답 값에 대해 무조건 신뢰하고 처리해서는 안 된다. 당연히 존재할 것으로 생각한 필드 값에 빈 배열이 들어와서 일정 관련된 데이터를 일부 날리고 나서야 깨달았다.. -_-Q. 가장 처리해야 할 이슈가 많았다고 알고 있는데, 그중에서도 기억에 남는 이슈가 있을 것 같다.너무 많은 이슈를 동시에 처리하다 보니 특별히 기억에 남는 이슈는 없다. 다만 아직도 왜 그랬는지 확실한 이유는 알 수 없지만, 언젠가 한 번 구글에서 웹훅을 아예 전달해주지 않았던 경우가 있었다. 과도한 요청으로 limit이 걸린 것도 아니었는데, 갑자기 웹훅이 안들어오니깐 우리로서는 어떻게 풀어볼 방법이 없었다. 그러다 나중에 확인해보니 대략 12시간쯤 지나고 나서 그동안 밀려있던 웹훅 데이터가 한 번에 밀려서 들어와 있더라. 다행히 그 이후로 지금까지 한 번도 재현되지 않는걸 보니, 혹 동일한 증상을 겪는다면 당황하지 말고 기다려 보시라.반복 일정을 다루는 것도 꽤 골치 아픈 이슈인데, 왜냐하면 일정이 있을 때 마다 웹훅 알림을 주지 않고 처음 등록된 시점에서 한 번만 정보를 알려주기 때문에 등록된 시점 이후의 일정은 내부적으로 계속 등록해줘야 한다. 기본적으로 구글 캘린더는 RFC-55454 표준을 따르지만, 실제 전달되는 데이터 중 일부는 표준과 조금 다른 부분이 있었다. 특히 반복 일정(recurrence) 관련 데이터 포맷이 조금 다르므로 캘린더 데이터를 파싱하기 위해 만약 외부 library를 사용한다면 별도의 예외처리가 필요하다. 더욱 더 까다로운 건 사실 등록된 반복 일정이 수정되거나 삭제되는 경우인데, 이때 “특정 일정만 삭제”, “지금 시점 이후의 일정 모두 수정” 등 워낙 케이스도 많고 각각을 테스트 하는 것도 쉽지 않기 때문에 작업 시간이 꽤 오래 걸렸다. (심지어 아직 확인하지 못한 드문 케이스에서는 잠재된 버그가 있을 수도…)Q. 그 밖의 도움이 될만한 노하우나 꿀팁이 있다면?구글 캘린더 API는 Webhook 보단 Push Notification 키워드를 많이 사용한다. 푸시 노티라는 게 좀 다른 카테고리에서 많이 쓰이는 용어이기도 하다 보니 코드 리뷰 등의 커뮤니케이션을 할 때 혼동이 좀 있었던 것 같다.물론 서비스 요구사항마다 다르겠지만, 잔디 같은 경우엔 요구사항에 맞춰 계속 설계를 변경 및 개선하다 보니 결과적으로 너무 복잡해져 효율이 떨어지는 코드를 작성할 수밖에 없었다. 처음부터 연동을 생각하기보다는 아예 캘린더 자체 기능을 베이스로 설계하고 데이터만 구글에서 가져온다 생각했다면 개발 생산성이 더욱 좋았을 것 같다.- TrelloQ. 기능을 구현하면서 느낀 아쉬웠던 점과 좋았던 점을 짚어달라.트렐로 공식 API 문서가 더 명확했다면 좀 더 개발이 수월했을 것이다. 문서가 RESTful하게 end-point path는 간결하게 잘 정돈되어 있지만, 각 요청 parameter에 대한 설명이나 response 데이터 등이 명확하게 정리되지 않아서 적합한 API를 찾거나 불명확함을 걷어내기 위한 테스트를 하다 보니 전반적으로 시간이 길어지고 비효율적이었던것 같다.그에 반해 트렐로에서 웹훅 이벤트를 발생시키기 위한 유저 액션들이 비교적 간단하고, 그에 따른 콜백 리퀘스트 또한 누락 없이 빠르게 잘 들어와서 그나마 쉽게 테스트를 할 수 있었다.Q. 기능 구현을 위해선 반드시 알아야 할 웹훅 이벤트 종류 및 데이터에 대한 문서는 정리가 전혀 안 되어있다고 하던데 정말인가?그렇다. 처음엔 좀 당황했지만, 그래도 방법이 없으니 일일이 경우마다 테스트해보면서 직접 정리를 하려고 했다. 하지만 각 웹훅마다 큰 구분만 있고 세세한 데이터는 너무 다양해서 깔끔하게 정리하기가 어려워 따로 공유를 위한 문서를 만들지는 못했다. 예를 들자면 트렐로에서 updateCard 라는 action type의 웹훅 데이터를 보내주는데, 그 데이터만 보고 “Card Archive”, “Description 수정/삭제”, “Due date 등록/수정”, “카드 이동” 등의 여러 가지 서로 다른 이벤트를 구분해야 한다. 근데 그 구분하는 방법이 특정 flag가 있는 게 아니라서 각 data를 모아놓고 역으로 분리하다 보니 코드를 깔끔하게 작성하기가 어려움은 물론, 추후 트렐로 측 데이터의 변동이 있을 때의 품질을 보장할 수 없는 리스크를 안고 구현할 수밖에 없었다.Q. 그 밖의 도움이 될만한 노하우나 꿀팁이 있다면?만약 트렐로와 어떤 형태로든 연동하려고 한다면, 설계 전에 모든 API에 대해 꼼꼼히 살펴보고 웹훅 이벤트 또한 직접 테스트해서 일단 전체적으로 리스트업을 정리하는 게 보다 생산성에 도움이 될 것이다. 트렐로를 잘 알고 있더라도 서비스 내부에서 “보드”, “리스트”, “카드”가 어떤 상관관계를 가지는지 미리 정리해보는 것도 좋다.사소하지만 좀 특이했던 점은 웹훅을 처음 등록할 때 해당 URL로 확인 요청을 한번 하는데, 이때 요청은 HTTP method가 POST가 아닌 HEAD로 들어온다. 그래서 반드시 동일한 URL의 HEAD 요청에 대해서도 정상 응답을 할 수 있도록 구현해야 한다.마무리잔디 커넥트를 구현하면서 특히 서비스 품질과 개발 속도 간의 밸런스에 대한 고민을 많이 했습니다. 초반에 서비스 종류별로 작업을 분리하고 각각의 방식으로 설계한 뒤 나중에 정리하는 전략이다 보니 공통으로 가져갈 수 있는 DB 모델이나 서비스 로직이 많아서 이를 통합하기 위해 반복 작업을 할 수밖에 없었는데 이 부분이 저희 내부적으로 느낀 가장 아쉬운 부분이 아니었나 생각합니다. 기능 중 많은 부분이 외부 서비스에 의존적이다 보니 생각하지도 못한 크고 작은 이슈들이 발생해서 일정 산출에도 꽤 어려움을 겪었습니다.커넥트 기능을 출시한 이후로 꽤 시간이 지났음에도 불구하고 이슈 백로그(Backlog)를 보니 아직도 개선할 부분이 많이 남아있는 듯 합니다. 그렇지만 이번에 기반이 되는 작업을 최대한 튼튼히 하기 위한 많은 시행착오를 거쳤기에, 추후 연동되는 커넥트 종류를 늘려나가는 시점5에 보다 효과적으로 개발할 수 있을 것이라 기대하면서 이번 글을 마치겠습니다.Slack API 문서 참고 ↩vagrant의 box로 서로의 로컬 개발 환경을 동일하게 유지하고 있습니다. 참고로, 현재 저희 서버 환경은 Local - Dev - Staging - Production으로 구성되어 단계별로 상황에 알맞게 배포하고 있습니다. ↩Localization의 약어. 잔디는 아시아 시장에 최적화된 서비스를 제공하고자 한국어, 일본어, 중국어 간체자(중국), 번체자(대만/홍콩), 영어 총 5가지 언어를 지원합니다. ↩아이캘린더(iCalendar)로 불리는 인터넷 캘린더의 데이터 포맷에 관한 표준. IETF 문서참고 ↩구체적인 시점은 말씀드리기 어렵지만, 더욱 좋은 사용성을 제공하고자 유저분들의 설문조사를 진행하고 있으니 많은 참여 부탁드립니다. ↩#토스랩 #잔디 #JANDI #개발후기 #일지 #인사이트