안녕하세요, Hyper-X에서 AI Camera Picai를 개발 중인 Android 개발자, Trent 입니다. 저는 지난 5월 8일부터 5월 10일까지 JH 님, Evan 님과 함께 다녀온 Shoreline Amphitheatre 에서 열렸던 Google I/O 2018 에 대해서 전하려고 합니다. Google I/O는 Mountain View, California에서 매년 6월에 열리는 Developer Festival로서, Sundar Pichai의 Google Keynote를 시작으로 Google의 새로운 기술들과 프로덕트를 선보이는 Session들이 3일에 걸쳐 진행되었습니다. 놀라운 AI 기술의 발전이 돋보였던 올해의 행사였습니다.SessionsKeynoteSundar Pichai의 Keynote로 시작된 올해의 행사에선 AI 기술의 발전과 그 활용이 단연 돋보였습니다. Google Duplex 가 Keynote의 가장 큰 화제였는데요, Google Assistant가 직접 헤어샵이나 식당 같은 업체에 전화하여 예약을 수행해주는 기능입니다. ‘음…‘같은 소리들을 포함하며 매우 자연스럽게 종업원과 전화를 하는 모습을 보였는데요, 어려운 질문들도 척척 대답하는 모습이 놀라웠고, Google의 ML 기술에 놀라움을 금치 못했습니다.또한 Google의 독보적인 AI 기술은 Google의 기존 서비스들에도 큰 변화와 개선점들을 가져왔는데요, Gmail 의 Smart Compose 기능이 그 중 하나입니다. 이메일 작성 시 문장 전체를 AI가 autocorrect 해주는 기능인데요, 반복적인 이메일 업무를 획기적으로 줄일 수 있을 것으로 기대되었습니다. 역시 Google의 엄청난 양의 데이터를 통해 이뤄낸 기술로 보입니다. 그 외에도 Google News의 자동 뉴스 큐레이션 시스템, Google Lens를 활용한 Google Maps의 AR 기능 등으로 기존 서비스들에 큰 변화를 선도해가는 면모를 보였습니다.Android P는 Adaptive Battery, Adaptive Brightness, App Actions, App Slices 등의 새로운 AI 기반 기능들을 Android에 가져왔습니다. 배터리를 30% 절약하고, 밝기를 자동으로 조절해주며, 시간 및 행동에 따라 연관된 앱들을 추천해주는 등 전반적으로 Android가 매우 똑똑해지는 부분을 보여 줬습니다. 이런 직관적인 AI 를 활용한 API 를 활용하면, 앱 개발자가 효율적으로 자기 앱의 접근성을 높일 수 있을 것으로 보입니다.또한 Android P 는 소소한 UX 개선 점들과 더불어 스마트폰 중독 방지 기능들을 탑재했습니다. 서양에서는 과도한 스마트폰 사용이 많은 사회적 문제가 되고 있는데요, 이를 방지하기 위해 App들에서 보낸 시간을 트래킹하고, App 시간 제한을 스스로 설정한다던가, 핸드폰을 뒤집어서 중요한 연락처의 전화가 아니면 받지 않는 등의 기능을 탑재하였습니다.What’s new in AndroidAndroid App Bundle 이 소개되었습니다. 하나의 패키지를 Google Play에 업로드 함을 통해 Android 디바이스가 필요한 리소스만 다운받을 수 있게 해주는 시스템인데요, 이미 Twitter, LinkedIn 등의 어플리케이션에 적용되어 20% 가 넘는 APK 사이즈 개선을 이뤄냈다고 합니다. 저희 팀이 개발 중인 Picai에도 APK 사이즈 문제가 있는데, 이를 통해 해결 가능할 것이라 생각하고 큰 기대를 하는 중입니다. 차후 버전인 Android Studio 3.2 버전부터 지원합니다.Android Jetpack 이 소개되었습니다. Support Library, Architecture Components, KTX 등의 라이브러리를 통합한 모양새 인데요, 이와 함께 AndroidX 로의 패키지 명 변경이 이뤄지었습니다. 그 외에도 새로운 Navigation 라이브러리, WorkManager 라이브러리 등이 소개 되었습니다. Google의 새로운 Android 개발 Best Practice 제시라고 할 수 있겠습니다. Picai에서 이미 적극적으로 사용하던 기술들이라 큰 감흥은 없었는데요, Google이 직접 나서서 Android 개발자 에코시스템을 정리하려는 노력은 좋았습니다.또한 Kotlin의 전반적인 지원 확대와 다양한 라이브러리들에 대한 소식, Android Studio 의 많은 내부 변경 및 Energy Profiler, Google Assistant와 관련된 다양한 API 들 제공, Android P에 변경된 Background 카메라 및 마이크 권한 제한 및 ImageDecoder 등에 대한 뉴스 및 다양한 안드로이드 최적화에 관한 세션이 있었습니다. 특히 Android Testing 관련 세션이 매우 인상깊었는데요, 모든 Android 테스팅에 관련된 불편함을 해결해 줄걸로 기대했지만 아쉽게도 런칭이 아직 안됬는지, 컨퍼런스 밖에서는 자취를 찾을 수 없었습니다... And MoreFirebase ML Kit 및 TFLite(TensorFlow Lite) 에 대한 발표가 인상깊었습니다. 머신러닝에 대한 접근성을 높여 어떤 개발자라도 ML을 활용한 콘텐츠를 쉽게 만들게 할 수 있도록 노력하는 모습이 돋보였습니다. 컨퍼런스 후 팀원들과 함께 자세하게 검토를 해보았으며, 아직 여러가지 제약사항이 있어 적극적으로 쓰고 있진 않지만, 앞으로의 간편한 ML 활용에 대한 기대를 불러일으키는 세션들이었습니다.Google의 새로운 Cross-Platform Framework Flutter 에 대한 세션도 참가하였는데, 개발 난이도가 쉬워 보이고 좋은 애니메이션의 UI Component 들이 제공됨은 동의 함에도 기능 분리 적인 면에서 노력이 많이 필요하겠다는 생각이 들었습니다. Hyper-X의 여러 팀들에서 도입을 검토로 하고 있지만, 아직 실무에서 적용하기는 시기 상조로 보였습니다.Snapchat Camera API 에 대한 설명을 들었는데, 기기 및 유저 데이터 기반으로 두 버전의 Camera API 및 캡쳐 메커니즘을 전부 지원하는 백엔드를 세세히 설계한 부분이 매우 인상 깊었으며, 차후 Picai에 직접 적용해보고 싶다는 생각을 가지게 되었습니다. 특히 관련하여, Fragmentation이 심한 Android Camera의 Testing을 어떻게 진행하나 궁금하여 강연 후 연사에게 찾아가 여쭤보았는데요, 만족할 만한 수준의 대답은 아니었지만 향후 Picai를 개발 함에 있어 자신감을 가질 수 있게 하는 답변을 받았습니다.Office Hour개인적으로 Google I/O 참가하면서 기대했던 것은 Office Hour 인데요, Jake Wharton, Kotlin 개발팀, Flutter 팀, TFLite 팀 등을 직접 만나서 질문을 할 수 있었다는 것이 기대되었습니다. Kotlin 개발팀과 바람직한 Kotlin 코드 스타일(Effective Kotlin 유무) 및 Jetbrains가 지향하는 패러다임(FP vs OOP), Kotlin Native의 런칭 일정 및 Coroutine 후 추가 목표 피쳐 등에 대해 토의하였으며, Flutter 팀에게는 Dart 채택 이유와 Flutter가 적합한 어플리케이션 타입이 무엇이냐에 대해 물었고, TFLite 팀에게는 회사 동료의 ML에 관한 질문을 슬랙으로 전달하고 답변 받는 등 뜻깊은 시간을 보냈습니다. Google I/O TipsUber 사용법을 숙지하라Silicon Valley 답게 차를 렌트하지 않은 경우 Uber를 통해 대부분 이동하게 되는데, Shoreline Amphitheatre 근처에서는 주차가 금지되어서 특정한 Uber 존으로 이동하여 차를 잡아야 합니다. 이 위치를 인지 못하고 앱만 보면서 돌아다니게 되면 길을 잃기 쉬우니, 주의하여 미리 탑승 존을 인지하면 좋습니다. 특히 야간에는 사람이 몰려서, 주의하여야 합니다. 오히려 더 아래쪽으로 내려와서, Google Campus 내에서 잡는 게 좋을 수도 있습니다.또한 Uber 운전사한테 얻은 정보인데요, Ride-sharing을 하는 Uber 플랜을 사용하면 운전사들이 쉽게 취소한다고 하니, 조금 비싸더라도 개인으로 탑승하는 Uber 플랜을 사용하는 것이 좋다고 합니다.복장을 조심하라(?)캘리포니아는 6월에 더울때는 엄청 덥고, 추울때는 엄청 춥습니다. 특히 야외에서 오래 돌아다녀야 하기 때문에, 충분한 대비가 필수 입니다. 후디같은 옷을 입으시거나, 얇은 외투를 입는 등 충분히 준비해가면 좋습니다. 저는 행사장에서  CODE 가 젹혀진 후디를 구입해서, 매일 입고 다녔는데요, 매우 유용했습니다. 선크림 같은게 제공되긴 하지만, 그래도 제때 실내에서 휴식을 취하고 물을 많이 마시는 것이 좋습니다.마치며행사장을 돌아다니며 구글의 생태계에 푹 빠져 볼 수 있었던, 뜻깊은 경험이었습니다. 특히 그들이 곧 완성되고 릴리즈 된다고 자신하는 새로운 기능들은 상상하지 못했던 것들이라 놀라웠고, 이 시점에 직접 볼 수 있다는 것이 감사했습니다. Hyperconnect에서도 Mobile AI의 심화된 적용을 위해 많은 노력을 하고 있는데요, Azar 및 새로 시도하고 있는 Picai 같은 앱들을 통해 더 특별한 가치를 제공할 수 있도록 노력하고 있으니, 많은 기대 바랍니다!링크Android PApp BundleAndroid JetpackAndroidXML KitTFLiteFlutter#하이퍼커넥트 #개발자 #이벤트 #구글 #참여후기 #꿀팁 #인사이트 #이벤트참여 #미국 #캘리포니아

초기에는 kube-aws가 만들어준 관리자 인증서를 통해 Kubernetes를 관리했는데 역시나 대내외적으로 여건이 바뀌니 변화가 필요했다. 내부적으로는 개발 인력이 늘고 여러 프로젝트가 동시 진행되니 Staging 환경이 급격히 바뀌는데 계정이 하나이니 누가 무슨 작업을 했는지 확인하기 어렵고 외부적으로는 경쟁사의 보안사고 등에 영향을 받아 보안을 강화할 필요가 생겼다. 하여 보안 관련 작업을 여럿했고 그 중 하나가 바로 GitHub와 Kubernetes를 OAuth로 엮는 일이다.기본적으로는 개발자 각자가 자신의 GitHub 계정으로 인증 토큰을 받고 이를 이용해 Kubernetes API에 접근하는 것이다. 전체적인 흐름은 How I built a Kubernetes cluster so my coworkers could deploy apps faster 등을 참고하면 이해하기 그리 어렵지 않다.1. Admin time should be saved (since they are also our developers)2. New users can generate their own credentials without needing the admin3. User credential is always private for security reasons4. Developers have their own space to experiment5. Project spaces can be accessed and changed by multiple users6. In the future, we may want to enable auditing to track changes다만 저들과 달리 Webhook 토큰 인증 플러그인을 직접 짜지 않고 coreos/dex를 이용했다. Dex를 이용하면 GitHub를 비롯해 다양한 OpenID, OAuth 2.0 인증 서비스와 Kubernetes 클러스터를 엮기 쉽다. 더욱이 kube-aws에 Dex가 통합되어서 설치하기도 쉽다.설치하기구구절절 어떻게 설정하는지 설명할 생각은 없는데 회사와 프로젝트에 따라 세부적인 차이가 꽤나 클 수 있기 때문이다. 그러니 대략적인 작업 순서를 간략히 기술하고 끝내려 한다.우선 kube-aws의 cluster.yaml를 보자.# # Enable dex integration - https://github.com/coreos/dex # # Configure OpenID Connect token authenticator plugin in Kubernetes API server. # # Notice: always use "https" for the "url", otherwise the Kubernetes API server will not start correctly. # # Please set selfSignedCa to false if you plan to expose dex service using a LoadBalancer or Ingress with certificates signed by a trusted CA. # dex: # enabled: true # url: "https://dex.example.com" # clientId: "example-app" # username: "email" # groups: "groups" # selfSignedCa: true # # # Dex connectors configuration. You can add configuration for the desired connectors suported by dex or # # skip this part if you don't plan to use any of them. Here is an example of GitHub connector. # connectors: # - type: github # id: github # name: GitHub # config: # clientId: "your_client_id" # clientSecret: "your_client_secret" # redirectURI: https://dex.example.com/callback # org: your_organization # # Configure static clients and users # staticClients: # - id: 'example-app' # redirectURIs: 'https://127.0.0.1:5555/callback' # name: 'Example App' # secret: 'ZXhhbXBsZS1hcHAtc2VjcmV0' # # staticPasswords: # - email: "admin@example.com" # # bcrypt hash of the string "password". You can use bcrypt-tool from CoreOS to generate the passwords. # hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W" # username: "admin" # userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"우선 GitHub의 Organization Settings 메뉴로 가서 OAuth Apps에 Dex를 추가한다. 이때 Authorization calllback URL은 https://dex.example.com/callback가 된다.GitHub가 준 Client ID와 Client Secret를 cluster.yaml에 적어넣는다.dex: enabled: true url: "https://dex.example.com" clientId: "example-app" username: "email" groups: "groups" selfSignedCa: false # # # Dex connectors configuration. You can add configuration for the desired connectors suported by dex or # # skip this part if you don't plan to use any of them. Here is an example of GitHub connector. connectors: - type: github id: github name: GitHub config: clientId: "GITHUB_OAUTH_APP_CLIENT_ID" clientSecret: "GITHUB_OAUTH_APP_CLIENT_SECRET" redirectURI: https://dex.example.com/callback org: DailyHotel # # Configure static clients and users staticClients: - id: 'example-app' redirectURIs: 'https://kid.example.com/callback' name: 'Example App' secret: 'ZXhhbXBsZS1hcHAtc2VjcmV0'staticPasswords: - email: "admin@example.com" # # bcrypt hash of the string "password". You can use bcrypt-tool from CoreOS to generate the passwords. hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W" username: "admin" userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"여기서 dex.example.com은 kube-aws가 띄울 dex Deployment와 연결되는 서비스(ELB)의 도메인주소가 되어야 한다. 그런데 kube-aws는 Dex의 External service를 생성해주지 않으므로 아래와 같이 직접 서비스를 생성해야 한다. GitHub가 이쪽으로 콜백을 보내야 하므로 방화벽을 열어야 하고 회사 도메인 인증서를 붙일 것이므로 `selfSignedCa`값은 `false`로 한다.apiVersion: v1 kind: Service metadata: name: dex namespace: kube-system labels: app: dex component: identity dns: route53 annotations: domainName: dex.example.com service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:blahblah service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https spec: ports: # the ports that this service should serve on - name: https port: 443 targetPort: 5556 protocol: TCP selector: app: dex component: identity type: LoadBalancer loadBalancerSourceRanges: - 0.0.0.0/0staticClients / example-app는 Dex에 포함된 예제 프로그램이다. 이를 이용하면 웹 브라우저를 통해 GitHub에 인증하고 토큰을 내려받을 수 있다. DailyHotel/kid 등의 도커 이미지를 사용하면 쉽게 띄울 수 있다. kube-aws는 이 예제 프로그램을 띄우지 않기 때문에 직접 올려야 한다.apiVersion: v1 kind: Service metadata: name: kid namespace: kube-system labels: app: kid dns: route53 annotations: domainName: "kid.example.com" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:blahblah service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https spec: ports: - name: https port: 443 targetPort: 5555 protocol: TCP selector: app: kid type: LoadBalancer loadBalancerSourceRanges: - 사무실IP/32 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kid namespace: kube-system spec: replicas: 1 template: metadata: labels: app: kid spec: containers: - name: kid image: dailyhotel/kid:latest livenessProbe: tcpSocket: port: 5555 timeoutSeconds: 120 ports: - containerPort: 5555 env: - name: CLIENT_ID value: example-app - name: CLIENT_SECRET value: ZXhhbXBsZS1hcHAtc2VjcmV0 - name: ISSUER value: https://dex.example.com - name: LISTEN value: http://0.0.0.0:5555 - name: REDIRECT_URI value: https://kid.example.com/callback이때 example-app의 REDIRECT_URI는 Dex의 REDIRECT_URI와는 다르다는 점에 주목하자. 옵션의 이름이 비슷하기 때문에 헷갈릴 수 있다. 또한 CLIENT_ID와 CLIENT_SECRET은 cluster.yaml 중 GitHub connector 설정이 아닌 staticClients 설정에서 쓴 값이라는 점도 눈여겨볼 필요가 있다.이 정도만 주의하면 dex를 설치하고 설정하는 것은 어렵지 않다. 이제 인증하는 방법을 알아보자.인증하기웹브라우저로 kid에 방문해서 토큰을 받는다. 첫 화면에서 Login 버튼을 누른 후 GitHub 로그인을 하면 토큰이 나온다.GitHub Public profile 메뉴로 가서 Public email 설정을 확인한다. 공개 이메일이 없다면 하나 추가한다. 로그인시 사용자 아이디로 쓰기 위함이다.kubeconfig 파일을 열고 kubeconfig 파일을 열고 MY_PUBLIC_GITHUB_EMAIL에는 GitHub 공개 이메일 주소를 적고 VISIT_KID_EXAMPLE_COM_AND_GET_TOKEN에는 앞서 받은 토큰을 적는다.apiVersion: v1 kind: Config clusters: - cluster: certificate-authority: credentials/ca.pem server: https://MY_KUBE_CLUSTER name: kube-aws-cluster contexts: - context: cluster: kube-aws-cluster namespace: default user: MY_PUBLIC_GITHUB_EMAIL name: kube-aws-context users: - name: MY_PUBLIC_GITHUB_EMAIL user: token: VISIT_KID_EXAMPLE_COM_AND_GET_TOKEN current-context: kube-aws-context인증 파일의 설정이 정확한지 확인하려면 kubectl --kubeconfig=./kubeconfig version을 실행해보자. 아래와 같이 Client/Server의 버전이 둘다 나오면 정상이다.$ kubectl --kubeconfig=./kubeconfig version Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate:"2017-04-03T20:44:38Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.2+coreos.0", GitCommit:"79fee581ce4a35b7791fdd92e0fc97e02ef1d5c0", GitTreeState:"clean", BuildDate:"2017-04-19T23:13:34Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}참고 자료johnw188/dex-exampleKubernetes / Authenticating#데일리 #데일리호텔 #개발 #개발자 #개발팀 #기술스택 #도입후기 #일지 #경험공유 #Kubernetes #Github

Overview안녕하세요. 저는 브랜디 R&D 본부 개발1팀의 기둥을 담당하는 이상근입니다. 오늘은 SQS(Simple Queue Service)와 Lambda를 간단한 예제와 함께 정리해보려고 합니다. 각 서비스에 대한 설명은 이미 매뉴얼로 쉽게 정리되어 있으므로, 이번 글에서는 서비스 간 구성을 집중적으로 살펴보겠습니다.1)SQS와 Lambda에 대하여SQS(Simple Queue Service)는 마이크로 서비스와 분산 시스템, 그리고 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있는 ‘완전관리형 메시지 대기열 서비스’입니다. 그리고 Lambda는 ‘이벤트 처리 방식의 서버리스 컴퓨팅 서비스’입니다. 아래 그림은 SQS와 Lambda Function을 이용해 메시지를 등록-조회-처리하는데 필요한 구성요소를 정리한 것입니다. SQS, Lambda ArchitectureProducer - 처리할 작업 메시지를 SQS에 등록Trigger - 큐(Queue) 대기열에 있는 메시지들을 조회하기 위해 CloueWatch의 스케줄 이벤트를 이용하여 매 분마다 Lambda Consumer 실행Consumer - Lambda Consumer는 큐 대기열에 있는 메시지 목록을 조회하여 각 메시지를 Lambda Worker에서 처리할 수 있도록 실행Worker - Lambda Worker는 메시지를 받아 작업을 처리하고 해당 메시지를 삭제큐 생성하기이번에는 큐 생성에 대해 살펴보겠습니다. ‘Create New Queue’를 클릭했을 때 지역(Region)에 따라 각각 다른 화면이 노출됩니다. Create New Queue Button타입 선택 화면항목 입력 화면두 번째 이미지와 같이 SQS에서는 Standard, FIFO 두 가지 타입을 제공하고 있습니다. 표준 대기열은 순서에 맞지 않게 메시지가 전송될 수 있습니다. 만약 순서를 반드시 유지해야 한다면 FIFO 대기열을 사용하거나, 순서 정보를 추가하고 사용해야 합니다. 하지만 FIFO 대기열의 경우 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤) 및 EU(아일랜드) 지역(Region)이서만 제공되고 있기 때문에 다른 곳에서는 사용할 수 없습니다. 2) 3) 1.Create New Queue ‘Create New Queue’에는 여러 항목이 있습니다. 우선 아래를 참조하여 각 항목에 적절한 내용을 기재합니다. Default Visibility Timeout : 대기열에서 조회한 메시지가 중복 조회되지 않기 위한 시간Message Retention Period : 메시지 보관 기간Maximum Message Size : 메시지 최대 사이즈Delivery Delay : 신규 메시지 전달 지연 시간Receive Message Wait Time : 조회된 메시지가 없을 경우, 사용 가능한 메시지를 기다리는 long polling 시간 설정Dead Letter Queue Settings : 정상적으로 처리되지 못한 메시지를 보관하기 위하여 메시지 수신 최대 수를 지정, 지정한 수신을 초과할 경우 지정한 큐에 메시지 저장2.큐 등록 확인 기본 값으로 설정한 큐 등록을 확인합니다. Queue List3.SQS 메시지 등록 import boto3, json sqs_client = boto3.client(     service_name='sqs',     region_name='xxxxxx' ) SQS 메시지 등록  response = sqs_client.send_message(     QueueUrl='https://sqs.xxxxxx.amazonaws.com/xxxxxx/sqs-test-1',     MessageBody='메시지 내용' )   print(json.dumps(response))   {"MD5OfMessageBody": "xxxxxxx", "MessageId": "xxxxx-xxxx-xxxxxx", "ResponseMetadata": {"RequestId": "xxxxxxx", "HTTPStatusCode": 200, "HTTPHeaders": {"server": "Server", "date": "Fri, 09 Feb 2018 08:01:13 GMT", "content-type": "text/xml", "content-length": "378", "connection": "keep-alive", "x-amzn-requestid": "xxxxxxx"}, "RetryAttempts": 0}} 4.AWS Console 메시지 등록 확인 View MessageDetail Message5.조회와 실행 1)SQS 메시지를 조회합니다.2)LambdaWorker 함수를 실행하고 > InvocationType으로 동기, 비동기 등의 실행 유형을 설정합니다. import boto3, json   def handle(event, context):     queue_url = 'https://sqs.xxxxxx.amazonaws.com/xxxxxx/sqs-test-1' sqs_client = boto3.client(         service_name='sqs',         region_name='xxxxxx'     )      lambda_client = boto3.client(         service_name='lambda',         region_name='ap-northeast-1'     )      # SQS 메시지 조회     response = sqs_client.receive_message(         QueueUrl=queue_url,         MaxNumberOfMessages=10,         AttributeNames=[             'All'         ]     )      print(json.dumps(response))      # {"Messages": [{"MessageId": "xxxxx-xxxx-xxxxxx", "ReceiptHandle": "xxxxx-xxxx-xxxxxx", "MD5OfBody": "xxxxxxx", "Body": "\uba54\uc2dc\uc9c0 \ub0b4\uc6a9", "Attributes": {"SenderId": "xxxxxxx", "ApproximateFirstReceiveTimestamp": "1518163931724", "ApproximateReceiveCount": "1", "SentTimestamp": "1518163466941"}}], "ResponseMetadata": {"RequestId": "", "HTTPStatusCode": 200, "HTTPHeaders": {"server": "Server", "date": "Fri, 09 Feb 2018 08:12:11 GMT", "content-type": "text/xml", "content-length": "1195", "connection": "keep-alive", "x-amzn-requestid": "xxxxxxx"}, "RetryAttempts": 0}}      for message in response['Messages']:         payload = {'message': message, 'queueUrl': queue_url}          # Lambda Worker 함수 실행         lambda_client.invoke(             FunctionName='lambda_worker',             InvocationType='Event',             Payload=json.dumps(payload)         ) 6.Lambda Consumer 함수 등록 Execution role : SQS ReceiveMessage, Lambda InvokeFunction, CloudWatchLogs7.확인-실행-삭제 1) 이벤트로 넘어온 메시지 내용을 확인하고2) 메시지 프로세스를 실행한 후3) SQS 메시지를 삭제합니다. import boto3, json   def handle(event, context):     sqs_client = boto3.client(         service_name='sqs',         region_name='xxxxxx'     )      message_body = json.loads(event['message']['Body'])      queue_url = event['queueUrl']     receipt_handle = event['message']['ReceiptHandle']      ###############     # 큐 메시지 처리     ############### # SQS 메시지 삭제     sqs_client.delete_message(         QueueUrl=queue_url,         ReceiptHandle=receipt_handle     ) 8.Lambda Worker 함수 등록 Execution role : SQS DeleteMessage, CloudWatchLogs9.CloudWatch의 Event Rule 등록 Event RulesCreate Rule10.1분에 한 번씩 지정한 Lambda 함수를 실행하여 SQS 메시지 확인 참고)이것만은 꼭 알아두세요! 여러 대의 서버에 메시지 사본을 저장하기 때문에 가끔씩 메시지 사본을 받거나 삭제하는 중엔 저장 서버 중 하나를 사용할 수 없을 수도 있다고 합니다. 이 경우, 해당 문제가 발생하면 사용할 수 없는 서버의 메시지가 삭제되지 않아, 메시지를 다시 가져와야 하는 문제가 생길 수 있습니다. 그러므로 애플리케이션에서 동일 메시지를 두 번 이상 처리하는 것도 대비해야 합니다.Conclusion지금까지 AWS 환경에서 SQS, Lambda, CloudWatch EventRule을 이용한 메시지 대기열 등록과 처리에 대한 기본 예제들을 실행해봤습니다. AWS의 다른 서비스들과 같이 아주 간단한 방법으로 메시지 대기열을 이용할 수 있었습니다. 오늘 살펴본 방법들을 활용하면 동영상 트랜스 코딩 등의 작업을 비롯해 분산 애플리케이션 간의 데이터 처리에도 유용하게 사용할 수 있을 겁니다. ps.아마존 형님들의 IT 인프라를 이용하여 편하게 개발에만 집중합시다. 참고 1) 각 서비스 매뉴얼은 아래 페이지 링크 참조하면 된다.SQSLambdaboto3 2)2018년 2월 기준이다. 3)표준 대기열과 FIFO 대기열의 특징은 아래와 같으며 자세한 내용은 매뉴얼에 정리되어 있다. 표준 대기열 : 무제한 처리량, 최선 정렬FIFO 대기열 : 높은 처리량, 선입선출 전송 글이상근 팀장 | R&D 개발1팀leesg@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

VCNC에서 엔지니어링 블로그를 시작하고 벌써 새로운 해를 맞이하였습니다. 그동안 여러 글을 통해 VCNC 개발팀의 이야기를 들려드렸습니다. 이번에는 엔지니어링 블로그 자체를 주제로 글을 적어보고자 합니다. 저희는 워드프레스나 텀블러와 같은 일반적인 블로깅 도구나 서비스를 사용하지 않고 조금은 개발자스럽다고 할 수 있는 특이한 방법으로 엔지니어링 블로그를 운영하고 있습니다. 이 글에서는 VCNC 개발팀이 엔지니어링 블로그를 운영하기 위해 이용하는 방법들을 소개하고자 합니다. 그리고 블로그를 운영하기 위해 방법을 다루는 중간중간에 개발팀의 문화와 일하는 방식들에 대해서도 간략하게나마 이야기해보고자 합니다.블로그에 사용하는 기술들Jekyll: Jekyll은 블로그에 특화된 정적 사이트 생성기입니다. GitHub의 Co-founder 중 한 명인 Tom Preston-Werner가 만들었으며 Ruby로 작성되어 있습니다. Markdown을 이용하여 글을 작성하면 Liquid 템플릿 엔진을 통해 정적인 HTML 파일들을 만들어 줍니다. VCNC 엔지니어링 블로그는 워드프레스같은 블로깅 도구를 사용하지 않고 Jekyll을 사용하고 있습니다.Bootstrap: 블로그 테마는 트위터에서 만든 프론트엔드 프레임워크인 Bootstrap을 이용하여 직접 작성되었습니다. Bootstrap에서 제공하는 다양한 기능들을 가져다 써서 블로그를 쉽게 만들기 위해 이용하였습니다. 덕분에 큰 공을 들이지 않고도 Responsive Web Design을 적용할 수 있었습니다.S3: S3는 AWS에서 제공되는 클라우드 스토리지 서비스로서 높은 가용성을 보장합니다. 일반적으로 파일을 저장하는 데 사용되지만, 정적인 HTML을 업로드하여 사이트를 호스팅하는데 사용할 수도 있습니다. 아마존의 CTO인 Werner Vogels 또한 자신의 블로그를 S3에서 호스팅하고 있습니다. VCNC Engineering Blog도 Jekyll로 만들어진 HTML 파일들을 아마존의 S3에 업로드 하여 운영됩니다. 일단 S3에 올려두면 운영적인 부분에 대한 부담이 많이 사라지기 때문에 S3에 올리기로 하였습니다.CloudFront: 브라우저에서 웹페이지가 보이는 속도를 빠르게 하려고 아마존의 CDN서비스인 CloudFront를 이용합니다. CDN을 이용하면 HTML파일들이 전 세계 곳곳에 있는 Edge 서버에 캐싱 되어 방문자들이 가장 가까운 Edge를 통해 사이트를 로딩하도록 할 수 있습니다. 특히 CloudFront에 한국 Edge가 생긴 이후에는 한국에서의 응답속도가 매우 좋아졌습니다.s3cmd: s3cmd는 S3를 위한 커맨드 라인 도구입니다. 파일들을 업로드하거나 다운로드 받는 등 S3를 위해 다양한 명령어를 제공합니다. 저희는 블로그 글을 s3로 업로드하여 배포하기 위해 s3cmd를 사용합니다. 배포 스크립트를 실행하는 것만으로 s3업로드와 CloudFront invalidation이 자동으로 이루어지므로 배포 비용을 크게 줄일 수 있었습니다.htmlcompressor: 정적 파일들이나 블로그 글 페이지들을 s3에 배포할 때에는 whitespace 등을 제거하기 위해 htmlcompressor를 사용합니다. 또한 Google Closure Compiler를 이용하여 javascript의 길이도 줄이고 있습니다. 실제로 서버가 내려줘야 할 데이터의 크기가 줄어들게 되므로 로딩속도를 조금 더 빠르게 할 수 있습니다.블로그 관리 방법앞서 소개해 드린 기술들 외에도 블로그 글을 관리하기 위해 다소 독특한 방법을 사용합니다. 개발팀의 여러 팀원이 블로그에 올릴 주제를 결정하고 서로의 의견을 교환하기 위해 여러 가지 도구를 이용하는데 이를 소개하고자 합니다. 이 도구들은 개발팀이 일할 때에도 활용되고 있습니다.글감 관리를 위해 JIRA를 사용하다.JIRA는 Atlassian에서 만든 이슈 관리 및 프로젝트 관리 도구입니다. VCNC 개발팀에서는 비트윈과 관련된 다양한 프로젝트들의 이슈 관리를 위해 JIRA를 적극적으로 활용하고 있습니다. 제품에 대한 요구사항이 생기면 일단 백로그에 넣어 두고, 3주에 한 번씩 있는 스프린트 회의에서 요구사항에 대한 우선순위를 결정합니다. 그 후 개발자가 직접 개발 기간을 산정한 후에, 스프린트에 포함할지를 결정합니다. 이렇게 개발팀이 개발에 집중할 수 있는 환경을 가질 수 있도록 하며, 제품의 전체적인 방향성을 잃지 않고 모두가 같은 방향을 향해 달릴 수 있도록 하고 있습니다.VCNC 개발팀이 스프린트에 등록된 이슈를 얼마나 빨리 해결해 나가고 있는지 보여주는 JIRA의 차트.조금만 생각해보시면 어느 부분이 스프린트의 시작이고 어느 부분이 끝 부분인지 아실 수 있습니다.위와 같은 프로젝트 관리를 위한 일반적인 용도 외에도 엔지니어링 블로그 글 관리를 위해 JIRA를 사용하고 있습니다. JIRA에 엔지니어링 블로그 글감을 위한 프로젝트를 만들어 두고 블로그 글에 대한 아이디어가 생각나면 이슈로 등록할 수 있게 하고 있습니다. 누구나 글감 이슈를 등록할 수 있으며 필요한 경우에는 다른 사람에게 글감 이슈를 할당할 수도 있습니다. 일단 글감이 등록되면 엔지니어링 블로그에 쓰면 좋을지 어떤 내용이 포함되면 좋을지 댓글을 통해 토론하기도 합니다. 글을 작성하기 시작하면 해당 이슈를 진행 중으로 바꾸고, 리뷰 후, 글이 발행되면 이슈를 해결한 것으로 표시하는 식으로 JIRA를 이용합니다. 누구나 글감을 제안할 수 있게 하고, 이에 대해 팀원들과 토론을 하여 더 좋은 글을 쓸 수 있도록 돕기 위해 JIRA를 활용하고 있습니다.JIRA에 등록된 블로그 글 주제들 중 아직 쓰여지지 않은 것들을 보여주는 이슈들.아직 제안 단계인 것도 있지만, 많은 주제들이 블로그 글로 발행되길 기다리고 있습니다.글 리뷰를 위해 Pull-request를 이용하다.Stash는 Attlassian에서 만든 Git저장소 관리 도구입니다. GitHub Enterprise와 유사한 기능들을 제공합니다. Jekyll로 블로그를 운영하는 경우 이미지를 제외한 대부분 콘텐츠는 평문(Plain text)으로 관리 할 수 있게 됩니다. 따라서 VCNC 개발팀이 가장 자주 사용하는 도구 중 하나인 Git을 이용하면 별다른 시스템의 도움 없이도 모든 변경 내역과 누가 변경을 했는지 이력을 완벽하게 보존할 수 있습니다. 저희는 이런 이유로 Git을 이용하여 작성된 글에 대한 변경 이력을 관리하고 있습니다.또한 Stash에서는 GitHub와 같은 Pull request 기능을 제공합니다. Pull request는 자신이 작성한 코드를 다른 사람에게 리뷰하고 메인 브랜치에 머지해 달라고 요청할 수 있는 기능입니다. 저희는 Pull request를 활용하여 상호간 코드 리뷰를 하고 있습니다. 코드 리뷰를 통해 실수를 줄이고 개발자 간 의견 교환을 통해 더 좋은 코드를 작성하며 서로 간 코드에 대해 더 잘 이해하도록 노력하고 있습니다. 새로운 개발자가 코드를 상세히 모른다 해도 좀 더 적극적으로 코드를 짤 수 있고, 업무에 더 빨리 적응하는데에도 도움이 됩니다.어떤 블로그 글에 대해 리뷰를 하면서 코멘트로 의견을 교환하고 있습니다.코드 리뷰 또한 비슷한 방법을 통해 이루어지고 있습니다.업무상 코드 리뷰 뿐만 아니라 새로운 블로그 글을 리뷰하기 위해 Pull request를 활용하고 있습니다. 어떤 개발자가 글을 작성하기 위해서 가장 먼저 하는 것은 블로그를 관리하는 Git 리포지터리에서 새로운 브랜치를 따는 것입니다. 해당 브랜치에서 글을 작성하고 작성한 후에는 새로운 글 내용을 push한 후 master 브랜치로 Pull request를 날립니다. 이때 리뷰어로 등록된 사람과 그 외 개발자들은 내용에 대한 의견이나 첨삭을 댓글로 달 수 있습니다. 충분한 리뷰를 통해 발행이 확정된 글은 블로그 관리자에 의해 master 브랜치에 머지 되고 비로소 발행 준비가 끝납니다.스크립트를 통한 블로그 글 발행 자동화와 보안준비가 끝난 새로운 블로그 글을 발행하기 위해서는 일련의 작업이 필요합니다. Jekyll을 이용해 정적 파일들을 만든 후, htmlcompressor 통해 정적 파일들을 압축해야 합니다. 이렇게 압축된 정적 파일들을 S3에 업로드 하고, CloudFront에 Invalidation 요청을 날리고, 구글 웹 마스터 도구에 핑을 날립니다. 이런 과정들을 s3cmd와 Rakefile을 이용하여 스크립트를 실행하는 것만으로 자동으로 이루어지도록 하였습니다. VCNC 개발팀은 여러 가지 업무 들을 자동화시키기 위해 노력하고 있습니다.또한, s3에 사용하는 AWS Credential은 IAM을 이용하여 블로그를 호스팅하는 s3 버킷과 CloudFront에 대한 접근 권한만 있는 키를 발급하여 사용하고 있습니다. 비트윈은 특히 커플들이 사용하는 서비스라 보안에 민감합니다. 실제 비트윈을 개발하는데에도 보안에 많은 신경을 쓰고 있으며, 이런 점은 엔지니어링 블로그 운영하는데에도 묻어나오고 있습니다.맺음말VCNC 개발팀은 엔지니어링 블로그를 관리하고 운영하기 위해 다소 독특한 방법을 사용합니다. 이 방법은 개발팀이 일하는 방법과 문화에서 큰 영향을 받았습니다. JIRA를 통한 이슈 관리 및 스프린트, Pull request를 이용한 상호간 코드 리뷰 등은 이제 VCNC 개발팀의 문화에 녹아들어 가장 효율적으로 일할 수 있는 방법이 되었습니다. 개발팀을 꾸려나가면서 여러가지 시행 착오를 겪어 왔지만, 시행 착오에 대한 반성과 여러가지 개선 시도를 통해 계속해서 더 좋은 방법을 찾아나가며 지금과 같은 개발 문화가 만들어졌습니다. 그동안 그래 왔듯이 앞으로 더 많은 개선을 통해 꾸준히 좋은 방법을 찾아 나갈 것입니다.네 그렇습니다. 결론은 저희와 함께 고민하면서 더 좋은 개발문화를 만들어나갈 개발자를 구하고 있다는 것입니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 jobs@vcnc.co.kr로 이메일을 주시기 바랍니다!

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팀leejh@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #iOS

근래 소규모로 게임 프로그래밍 스터디를 시작했습니다. 서비스 UI를 개발하는 프론트엔드개발자에게 있어 게임 프로그래밍은 언제나 커튼 뒤에 비친 풍경처럼 흐릿하고 형체를 쉽게 알 수 없는 신비한 존재입니다. 이번에 미약하게나마 커튼을 걷어 창문 너머 펼쳐진 풍경을 감상해 보자는 게 이번 스터디의 개인적인 목표입니다.왜 SVG를 선택했나게임을 만드는 데 어떤 기술을 사용할지 고민했습니다. 일반적인 DOM은 쉽게 객체를 조작할 수 있지만, 문서의 엘리먼트를 추상화한 것에 불과하므로 다양한 도형을 만들거나 좌표계에 사상(寫像, Mapping)1하기 쉽지 않습니다.캔버스는 그래픽 처리에 환상적인 성능을 보여주고 원, 다각형 등 다양한 도형을 그리기 쉽지만 일일이 객체화해야 하고 이를 관리하기 쉽지 않습니다. 여기에 필자가 캔버스를 좀 처럼 써 본 경험이 없어서 무턱대고 사용하기에도 부담을 느꼈습니다.하지만 SVG는 이 두 장점을 모두 갖고 있습니다. 확장 가능한 벡터 그래픽(Scalable Vector Graphics)이라는 이름을 통해서 알 수 있듯이 그래픽 요소를 그리는데 적합한 포멧이며 DOM처럼 추상화된 객체도 지원합니다.어떤 게임을 만들었나필자가 만든 게임은 크롬에 내장된 Running T-Rex와 비슷한 것으로 JUMPING CAR라고 이름을 붙였습니다. 플레이해보고 싶은 분은 uyeong.github.io/jumping-car를 방문하시기 바랍니다.규칙은 단순합니다. 게임을 시작하면 자동차가 달려나가고 이윽고 장애물을 만나게 됩니다. 장애물을 뛰어넘으면 점수가 1씩 증가하지만 부딪히면 게임이 종료됩니다.이 글에서는 게임을 만드는 과정을 소개하기보다 SVG를 이용하면서 알게 된 몇 가지 주요한 내용을 다룹니다.Pattern을 사용한 요소는 느리다이미지를 반복해서 출력할 때 HTML에서는 CSS의 background-url 속성으로 간단히 해결할 수 있습니다. 하지만 SVG에서는 Pattern 요소를 이용해야 합니다.아래 그림처럼 pattern#pat-land 요소를 만들고 이를 rect.parallax에서 사용하여 그림을 반복 출력되도록 합니다. 그리고 rect.parallax를 조금씩 Transform 하여 앞으로 이동하도록 구현합니다.코드는 다음과 같습니다(예제: svg-parallax-test/parallax1).<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="..."> <defs> <pattern id="pat-land" x="0" y="0" width="..." height="100%" patternUnits="userSpaceOnUse"> <image x="0" y="0" xlink:href="../images/land.png" width="..." height="100%"></image> </pattern> </defs> <g> <rect class="parallax" x="0" y="0" width="..." height="100%" fill="url(#pat-land)" transform="translate(0,0)"></rect> </g> </svg> 표면상으론 전혀 문제가 없는 코드지만 크롬 브라우저에서 이 코드를 실행하면 프레임이 50 이하로 떨어지는 경우도 발생합니다. 이 정도면 육안으로도 화면의 움직임이 매끄럽지 않게 느껴지는 수치입니다.따라서 성능에 영향을 주는 pattern을 제거하고 image 요소로 대체합니다. image 요소는 자동으로 반복할 수 없으므로 두 개의 요소를 이어 붙여 사용합니다(예제: svg-parallax-test/parallax2).<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="..."> <g> <image x="0" y="0" xlink:href="../images/land.png" width="..." height="100%"></image> <image x="..." y="0" xlink:href="../images/land.png" width="..." height="100%"></image> </g> </svg> 실행 결과 프레임이 안정적이고 육안으로도 이질감을 느낄 수 없습니다. 이처럼 Pattern을 이용한 SVG 요소를 애니메이션 처리할 때에는 주의가 필요합니다.일부 안드로이드 기종에서의 성능 문제pattern을 제거하고 image로 대체하면서 Parallax 처리 시 발생한 문제를 해결할 수 있습니다. 하지만 image로 대체하더라도 일부 안드로이드 기종에서는 여전히 성능 문제가 발생합니다.아래 영상처럼 image 요소를 Transform 할 경우 프레임이 급격하게 떨어집니다. 이는 크롬 개발자 도구에서도 쉽게 발견하기 힘든데 CPU 성능을 10배 줄여 테스트해도 수치상으로는 크게 차이 나지 않기 때문입니다.<style>.video-container { position: relative; padding-bottom: 56.25%; padding-top: 30px; height: 0; overflow: hidden; } .video-container iframe, .video-container object, .video-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }</style><iframe width="560" height="315" src="https://www.youtube.com/embed/F_-zXf1jb8I?rel=0" frameborder="0" allowfullscreen="">이 처리를 DOM으로 바꿔보면 어떻게 될까. 놀랍게도 큰 차이를 보여줍니다(예제: svg-parallax-test/parallax3).<iframe width="560" height="315" src="https://www.youtube.com/embed/VXQ1aT79D2s?rel=0" frameborder="0" allowfullscreen="">SVG에 대한 최적화 상황은 브라우저마다 조금씩 다릅니다. DOM은 과거부터 최적화 노력이 많이 이뤄졌지만, SVG는 pattern 요소나 다음 절에서 이야기할 리페인팅 문제 등 성능 문제를 일으키는 부분이 아직 남아있습니다.따라서 충돌 계산처럼 특별히 좌표계 연산이 필요 없는 배경은 DOM으로 옮기고 자동차, 장애물만 SVG로 구현했습니다(예제: svg-parallax-test/parallax4).SVG는 항상 페인트를 발생시킨다SVG는 이상하게도 svg 요소의 크기를 고정하더라도 자식 요소를 변경하면 페인팅이 발생합니다. 아래는 svg 요소의 자식 요소인 rect의 좌표를 수정하는 예제 코드입니다.<svg"http://www.w3.org/2000/svg" width="500px" height="500px" viewBox="0 0 500 500"> width="500" height="500" x="0" y="0"> </svg> [removed] setTimeout(() => { rect.setAttribute('x', '100'); }, 3000); [removed] svg는 viewBox로 설정한 사이즈 만큼 내부에 그림을 그립니다. 즉, 내부의 어떠한 그래픽적 변화가 문서에 변화를 일으킬 가능성이 없습니다. 그래서 개인적으로 쉽게 이해가 되지 않는 렌더링 흐름입니다.그러면 SVG 요소의 크기나 좌표를 바꾸지 않고 색상 또는 투명도를 변경하면 어떨까요. 이번에는 rect 요소의 좌표가 아니라 색상을 바꿔봅니다.<svg"http://www.w3.org/2000/svg" width="500px" height="500px" viewBox="0 0 500 500"> width="500" height="500" x="0" y="0"> </svg> setTimeout(() => { rect.setAttribute('fill', '#ebebeb'); }, 3000); 그래도 페인트가 발생합니다. 하지만 앞서 진행한 테스트의 페인팅 시간은 수십 마이크로세컨드로 크게 의미가 없어 보입니다. 그래서 현재 서비스 중인 레진코믹스의 메인페이지에 SVG를 넣고 테스트했습니다.페인팅에 0.51ms가 소요됐습니다. 작다고 느낄 수 있지만 페이지 전반적으로 영향을 줄 수 있으며, 애니메이션 처리 중인 SVG라면 성능적 문제를 발생시킬 수 있는 부분입니다.그래서 svg 요소에 null transforms 핵을 선언해 문서 상위 레벨까지 페인팅이 전파되지 않도록 합니다.<svg"http://www.w3.org/2000/svg" width="500px" height="500px" viewBox="0 0 500 500" style="transform:translate3d(0,0,0)"> width="500" height="500" x="0" y="0"> </svg> 또는 아예 svg 내부의 요소를 개별로 분리하는 방법도 있습니다(참고: Doubling SVG FPS Rates at Khan Academy).<svg> fill="red" transform="translate(2px, 3px)"> fill="blue" transform="scale(2)"> </svg> style="transform:translate(2px, 3px)"> <svg> fill="red"> </svg> style="transform:scale(2)"> <svg> fill="blue"> </svg> 끝으로여기까지 SVG를 이용해 게임을 개발하면서 만나게 된 이슈와 해결 방법을 간단히 정리했습니다.필자는 간단한 게임은 SVG로 만들 수 있고 괜찮은 성능을 보장할 것이라고 기대했습니다. 하지만 현실은 달랐습니다. 이 글에서 다룬 문제 외에도 사파리와 크롬 브라우저의 성능 차이, 자동차를 움직일 때 버벅이는 현상 등 다양한 문제를 해결해야 했습니다. 객체의 개수도 적고 애니메이션도 복잡하지 않은 단순한 게임이었는데 말이죠.다음 게임은 캔버스로 시작하고자 합니다.공간(空間)의 한 점에 대(對)하여, 다른 공간(空間) 또는 동일(同一)한 공간(空間)의 한 점(點)을 어떤 일정(一定)한 법칙(法則)에 의(依)하여 대응(對應)시키는 일 ↩

eBrain에서 진행하는 "개발자 채용 시 기술검증 어떻게 할 것인가"라는 미니 워크숍을 다녀왔다. 항상 고민하고 있는 주제이기도 하고 개인적으로 팬심(?)을 가지고 있는 김창준님의 강의라 한시간 거리를 극복했다.  이미 창천향로님이 강의 내용을 잘 정리해 주셨다. 하지만 내 자신의 학습을 위해 강의 내용을 재해석 해서 적어 본다. 빠져든다! 1. 현재 기술력 검증의 문제점최근의 개발자 채용에 사용되는 기술력 검증 방식은 다음과 같은 것들이 있다.  온라인 코딩 테스트 (최근에 여러 가지 플랫폼도 있다)손 코딩 테스트기술 인터뷰과제 제출이 중 최근에는 주로 알고리즘에 대한 코딩 테스트가 주가 되는 것 같다. 생각보다 난이도가 있어서 재직자들이 “이런 문제면 저는 못 들어왔을 것 같아요”라고 하는 경우도 있다. 코딩 테스트에 대해 두 가지 사례를 들어 질문을 던져 본다.  삼각형 판별 문제삼각형 판별 문제는 세 좌표가 주어졌을 때 이 삼각형이 어떤 삼각형인지 (정삼각형, 이등변 삼각형, 둔각 삼각형 등)를 맞추는 것이다. 이 프로그램이 잘 동작하는지를 검증하는 것이 QA 동네의 ‘Hello World’ 문제다. 이 문제가 주어지면 초보자들은 그냥 문제를 푼다. 하지만 전문가는 문제를 풀지 않고 “이 프로그램을 누가 쓸 것인가요?”를 물어본다. 콘텍스트에 따라서 완전히 다른 테스트의 설계가 필요하기 때문이다.  코딩 테스트도 이와 비슷하다. 코딩 테스트는 단순화된 문제를 푼다. 즉 맥락이 제거된 상태에서의 문제를 푼다. 실무는 종합적인 환경에서 이뤄진다. 따라서 이 문제를 잘 푼다는 것이 실무를 잘할 수 있는 것을 의미하지 않을 수 있다.  질문) 우리의 코딩 테스트는 과연 실무에서의 실력과 높은 상관관계가 있는가?  전문성 연구개발자는 종종 전문성의 연구 대상이 되곤 한다. 이때 연구비를 이유로 주로 혼자서 빠르게 풀 수 있는 문제로 실험이 이뤄진다. 하지만 이런 식의 실험들에서 “토이 문제”가 아닌 “복잡하고 확장된 문제"를 전달했을 때 전혀 다른 결과가 도출된다는것을 알게 되었다.  복잡한 문제, 즉 실제 문제를 풀 때는 인지적 전략이 많이 바뀐다. 또한 사회적 요소도 필요하다. 이런것들을 “토이 문제”로 검증하기는 쉽지 않다. X를 테스트하면 X를 잘하는 사람을 뽑게 된다.  즉, 알고리즘 코딩 테스트를 하면 알고리즘 코딩 테스트에 능한 사람을 뽑게 된다. 질문) 실무에 최대한 가까운 상황을 제한된 면접 시간 내에 만들어 내려면 어떻게 해야 할까? 2. 개발자 채용은 어떻게 해야 할까?채용이 더 크리티컬 한 곳이 있다. 델타포스, 네이비씰과 같은 특수부대이다. 이곳에서는 사람을 어떻게 뽑을까?  작전 지역을 설정 해 두고, 보급품과 군사장비를 실제 작전 수행 환경과 같이 조성해 놓는다. 그곳에서 직접 작전을 수행하는 것을 시뮬레이션 한다.이를  교관이 직접 따라가며 기록과 채점을 한다.  개발자의 면접 시에도 최대한 실제와 비슷한 환경을 구축하는 것이 좋다. 코딩 문제처럼 맞고 틀림만 보는 것이 아니라 과정에 대한 채점이 이뤄져야 한다. 3. 효과적인 기술력 검증을 위해서는 어떻게 준비해야 하는가?1) 우리가 하는 일을 분석한다.  우리가 하는 일에 코딩만 있는 것이 아니다. 설계도 하고, 버그도 찾고, 장애 해결도 하고, 커뮤니케이션도 한다.  2) 대표 케이스들을 뽑거나 만들어 내야 한다.  예를 들어 새롭게 코드를 작성하는 것보다 기존의 기능을 파악해서 코드를 수정하는 일을 더 많이 한다면 이런 상황을 문제로 만드는 것이 좋다.  3) 대표 케이스들로 파일럿 테스트를 해본다.  우리 회사의 뛰어난 개발자 3명과 평범한 개발자 3명에게 이 문제를 풀게 해보고 이를 기준으로 채점표를 만들어야 한다. 어느 누가 평가해도 비슷하게 나오도록 해야 한다. 뛰어난 개발자의 문제 풀이 방식을 기준으로 채점 기준을 만들 수 있다. 예를 들면 다음과 채점 기준이 나올 수 있다.  질문을 5개 이상 한다.코딩하는 과정에서 반복적인 실행을 한다. 4) 면접 후에는 결과에 대한 논의가 필요하다.  특정 항목에 대해 채점 기준이 다른 경우 이에 대한 논의 과정이 필요하다. 이는 면접관의 훈련에 도움이 된다.   4. 실습실제로 면접 문제 만드는 것을 실습해 보자.1) 수강생의 제안다음과 같은 면접 문제는 어떨까요?첫날 출근을 했는데 회사 웹서비스가 죽었습니다. 어떻게 하면 좋을까요? 2) 코칭좀 더 게임스럽게 만들어 본다. 실제 토이 서버를 죽여 놓고, 쉘을 주면서 실제로 어떻게 해결 하는지 살펴본다.옆에 조언을 줄 수 있는 가상의 3년 차 팀원(NPC처럼)을 제공한다. 제한된 답변을 하도록 한다.면접자가 다음과 같은 경우면 더 높은 점수를 줄 수 있다. 실제 업무를 할 때에는 이런 상황까지 이어진다는 것을 유념하자.  문제의 원인을 밝힌 이후에 이 문제를 근본적으로 해결하기 위한 후속조치를 말한다. 개발팀 내에 이 원인과 해결에 대한 공유를 한다.  5. 질문 답변1) 필터링의 목적으로 코딩 테스트는 의미가 있나요? 간단한 문제를 던져서 못 푸는 사람을 필터링하는 것으로는 의미가 있다. 하지만 그 이상의 목적으로 사용하는 것은 조심해야 한다고 생각한다.코딩 테스트라는 과정은 특히 지원자에게 많은 비용이 드는 과정이기 때문에 조금 더 경제적인 방법들이 있다. 예를 들면 “행동 기반 인터뷰”가 있다. 과거에 있었던 행동에 대한 구체적인 질문을 던지는 것이다.또한 코딩 테스트는 지원자에게 상당히 스트레스를 주는 방법이고, 지능이 높은 사람은 오히려 스트레스에 취약하다는 연구가 있다. 따라서 코딩 테스트를 진행하더라도 스트레스를 덜 주는 방향을 고민해야 한다.  2) 블라인드 테스트(이력서를 보지 않고 면접)의 장단점? 결국 코딩 테스트에 적합한 사람을 뽑게 될 것 같다. 코딩 테스트라는 것이 훈련 과정이 필요하기 때문에 입사에 대한 갈망을 볼 수는 있겠다. 질문 시에는 실무와 관련이 깊은 질문을 하면 좋겠다. 역시나 과거의 행동에 기반한 질문이 편향이 적고 많은 정보를 얻을 수 있다. 예를 들면 “팀장이 한 달 걸릴 일을 일주일 만에 끝내라고 한 적이 있나요? 그때 어떻게 하셨나요?”와 같은 질문이다. 3) 끈기, 성실 여부를 판단할 수 있을까요? 주위에서 끈기, 성실이라는 키워드를 생각하면 떠오르는 사람이 있을 것이다. 그 사람의 구체적인 행동을 기반으로 면접 문제를 만들어내는 것이 좋다. 행동에 대한 질문을 할 때에는 과거에 대한 질문을 하는 것이 좋다. 사람은 미래에 대해서는 거짓을 이야기 하가 쉽지만 과거의 이야기를 할 때에는 과거의 상황을 조작하는 동시에 거짓말을 하기가 쉽지 않다.  4) 채용 여부는 실력에 기반하게 되는데, 결국 연봉은 연차에 따라 주게 된다. 좀 더 세밀하게 측정할 수 있는 방법이 있을까? 임시 월급을 주고, 1달 혹은 3달 뒤에 급여를 적용하는 방법이 있다. 실제 환경에서는 보다 정확하게 퍼포먼스를 측정할 수 있다.  하지만 입사할 때 연봉이 중요한 요소가 되지 않게 하는 것이 더 주요한 방법이다. 내재적 동기를 갖게 하는 것이 더 중요하다. 연봉 인상에 따른 동기는 최대 3 달이면 없어진다. 외재적 동기는 점점 내재적 동기를 감소시킨다. 그 일을 즐기지 않게 되고, 하기 싫어지고, 성과가 없어진다. 연봉 말고 다른 협상 거리를 많이 가지고 있어야 한다. 연봉이 여러 가지 조건 중 하나가 되어야 한다.  5) 현재 잘하는 사람을 기준으로 채점 기준을 만들었다면, 다른 장점이 있는 사람이 탈락되지 않을까? 만일 현재 채점기준에는 적합하지 않지만, 다른 측면에서 장점이 있는 사람이 있다면 그 측면을 반영한 채점 기준을 만들어야 한다.  채용에 대해서 틀린 선입견을 가지고 있는 경우가 많이 있다. 예를 들면 술을 잘 먹는 사람이 협력을 잘한다.라고 생각하는 것이다. 그 반례가 있는지를 생각해 보면 그런 선입견을 깨는데 도움이 된다.  6) 비개발자와 함께 면접을 할 때 합의가 힘든 경우가 있다.  회사 안에서 어떤 사람을 뽑고 싶은지 합의가 필요하다. 우리 회사에서 핵심 인재를 추린 다음에 이 사람들의 공통점을 찾아서 인재상을 만들어야 한다.  7) 전화면접 괜찮을까요? 화상면접이 더 효과적인진 않을까요? 억양이 포함되어 있는 대화는 90%의 정보를 전달할 수 있다고 본다. 그 사람의 생각을 충분히 전달받을 수 있기 때문에 화상면접이 크게 더 효과적이라고 생각하지는 않는다.  우리나라에서는 많이 하지 않지만 면접에 대한 비용이 저렴하기 때문에 전화면접이 효과적인 수단이라고 생각한다. 단, 전화면접을 하기 전에 기준이 명확해야 한다. 느낌만으로 판단을 내리는 것은 의미가 없다. 8) 사내 전문가가 없는 영역에 대한 채용을 해야 한다면? 회사 외부의 전문가 몇 분을 찾아가서 그분들의 경험을 듣는다. 그 경험들에 기반해서 면접 문제를 만든다. 도메인에 관계없는 전문성이 있는지는 검증할 수 있는 방법이 있다. 즉, 전문가의 특징이 있다. 전문가는 공부를 한다. 실력을 향상하기 위한 꾸준한 노력을 한다.전문가는 확정적이지 않고 유연하다. 9) 러닝 커브가 좋은 사람을 찾는 방법은? 소규모 회사일수록 현재는 저평가되어 있지만 성장 가능성이 있는 사람을 채용해야 한다. 사실 능력 좋은 사람이 노력도 많이 한다. 뛰어난 사람은 “의도적 수련”의 양이 많고 질이 좋다.  학습에 관련된 테스트를 할 수도 있다. 예를 들어 “새로운 언어로 작은 프로그램을 작성해 보세요. 그리고 그 과정을 타임 로그로 남겨보세요” 와 같은 문제를 보면 학습 자체에 대한 능력을 테스트할 수 있다.  10) 개발을 잘하는 친구는 리드를 안 하려고 하고, 상대적으로 부족한 친구는 리드를 하려고 합니다.  개발을 잘하는 것에 대해서 생각해 볼 필요가 있다. 보통 개발을 잘한다고 하면 코딩을 잘하는 것만 생각하지만 협력에 대한 것이 포함되어야 한다. 흔히 하는 실수가 코딩 실력만 보고 리더를 삼으려고 하는 것이다.  내가 좋아했던 상사를 생각해 보고 그 사람의 특징을 생각해 보는 것부터 시작해 보는 것이 좋겠다. 개발 트랙, 매니저 트랙으로 나눠서 이야기하는 것은 좋지 않다.   6. 후기좋은 시간이었다. 워크숍에 참여하고 나서 어떻게 실력을 검증할것인가에 대해 구체적인 방향이 잡혔다. 우리가 현재 하고 있는 것들 중에 도움이 되는것과 그렇지 않은것이 구분 되었다. 8퍼센트에 좋은 분을 모실 수 있게 하나씩 시도해 봐야겠다.#8퍼센트 #에잇퍼센트 #개발자 #워크숍 #워크샵 #채용워크숍 #채용워크샵 #후기 #참여후기

여름은 언제 끝날까? 주말부터 더위에 지친 오늘, 단비 같은 시원한 소식이 핀다에 찾아왔다.한국형 핀테크 세계 금융 판도 흔든다`제1회 매경 핀테크 어워드` 11기업 선정핀다 장려상 수상!매일경제에서 주최한 Fintech Awards에서 #Finda 가 장려상을 수상했다는 소식. (감사합니다!) 한 주의 시작을 청량감 가득한 시원한 뉴스로 시작하다니 흥이 절로 난다.금융상품 비교 추천 플랫폼으로서 Finda 이외에도 온라인 가상화폐인 '비트코인(Bitcoin)'을 활용한 신개념 해외송금 서비스 업체 '센트비' 등 총 11개의 핀테크 기업이 선정되었다. 지금까지 걸어온 우리의 걸음마에 시원한 바람을 넣어주는 것 같아 핀다 가족들이 더 힘이 나는 날이다.나는 개발자이다.핀다에서 금융상품의 검색을 시작의 용이성을 시작으로 금융 테크놀로지에 기여하고자 하는 개발자이다. #핀테크스타트업 '핀다'와 함께한 나의 이야기를 해보고자 한다.  개발 경력 10년이 넘어버린 때. 지금으로부터 2-3년 전쯤일 게다. 한창 늘어져만가는 시점에서 같이 일하던 회사 이사님이 솔깃한 제안을 해왔다. #스타트업 #Startup! WHAT?경력으로도 가늠하겠지만, 적지 않는 나이이기도 했고, 오래전 말아먹은(?) 안 좋은 기억도 어렴풋이 남아있다. (무엇인지에 대해서는 구체적으로 적진 않겠다ㅎ) 그렇지만, 뭔가의 변화가 필요했던 시점에... 나의 귓가를 울리는 새로운 단어 Start up. 뭐랄까. 단비와도 같은? 오늘 매경에서 수상한 그런 '단비'보다 문자 그대로 '꼭 필요할 때 알맞게 내리는 비 = 단비' 같은 결정적인 모먼트.하여튼 그러했다.돌파구가 필요했던 시점. 적절했다.라고나 할까.2년을 좁디좁은 사무실에서 그야말로 쉼 없이 뒹굴었다. 그 사이 늦은 결혼에 낳은 늦둥이도 세상 빛을 보았고 세상은 더욱더 팍팍해졌으며 더불어 2년의 시간이 무색해져 버릴 만큼의 성적표가 떨어져 버린 거다.다시 새로운 무언가를 찾아야 했던 시절. 딱히 어떤 목표랄까 기대 같은 건 없이 가벼이 만났던 인연이 지금 내가 이 자리에 있게 된 운명 같은 것이었다고 말할 수 있겠다.스타트업 + 핀테크 개발자로 변신개발 13년 차에 다시 시작한 스타트업.게다가 그 핫하다는 핀테크 바닥이란 말이다.어찌할 바를 모르던 모바일 개발자 덕분에 한 달을 투여했던 API 개발은 모두 쓸모없는 일이 되어버렸다. 그나마 소득이라면 그 한 달의 기간 동안 같이 얘기하고 토론했던 Co-Founder 두 분과의 인연은 깊어졌다. 그 덕에 기대도 못했던 핀테크 업체의 개발 헤더 자리에 비비고 앉게 되어 버렸다. 물론 내 의지가 전혀 없었다고 얘기할 순 없겠지만 말이다. (사실은 매우 의욕적이었다.)하지만 개발일이라는 게 서로 얼굴 맞대며 일해도 어려운 것을, 한 달이 넘게 떨어져 있었으니 서로 일정을 맞추기도 어려웠고 서로의 상황이 달라 업무 상호 확인도 어려운지라 제대로 돌아가기가 힘들었다. 결국 모바일 버전의 프로토타입은 접어두고 "그래~! 웹 버전으로 시작하자"였다. 어차피 만들어둔 API도 있겠다, 프런트엔드만 올리면 되는 일.그리 시작한 "FINDA"의 웹서비스 개발은 드. 디. 어 지난 1월에 세상에 빛을 보게 되었다. 아직 조금 모자란 "Beta"라는 이름을 걸고 말이다. 눈물이 다 날 지경이었다. 론칭 며칠 전까지만 해도 할 수 있을까? 였는데.. 할 수 있게 되다니.빠른 시일 내에 베타 서비스로 완성을 해야 했으나, 마음에 차지 않는 부분들이 여럿 있을 수밖에 없었다. 최종적인 모습인 "개개인의 성향과 상황에 따른 맞춤 추천 서비스"를 지향하기 위해선 많은 부분들이 필요했던 것. 여러 상품들을 담아두고 싶은 마음에 여러 방면으로 두 대표님들이 뛰어다니던 차, 금감위에서 오픈 API를 제공하기로 한다는 소식이 들렸다. 오호~! 뭔가 될 법한 일에는 이리도 딱 맞는 기회가 주어지는구나.금감원 API를 통해 상품군의 다변화와 다루는 금융 상품들의 개수도 많이 늘렸다. 덕분에 손봐야 하고 신경 써야 하는 일들이 많이 늘긴 해야 했지만 무언가 서비스가 성장하고 있다는 느낌이라. 방문자 수도 꾸준히 늘어 갔고 심심치 않게 외부 피드백도 손에 쥐게 되었다. 그렇게 한두 달이 정신없이 지나가고...핀다 서비스 테크놀로지- 개발자의 시선으로정식 론칭! 대망의 4월, 이젠 정말 실전이다. 정식 서비스 론칭은 베타 서비스 론칭에 비해서 그나마 수월했다. 베타 서비스 론칭 때 이미 겪은 바도 있었으니 미리미리 준비해 둔터일 게 다. 그래도 서비스 론칭인데 수월했다고는 하나 정신없는 건 어쩔 수 없는 모양.정식 서비스를 론칭한 후 핀다팀은 서비스 전반에 대해 다시금 되돌아보는 시간을 갖기로 했다. 이른바 Finda Hackathon~! 각 팀별로 서비스에 대한 생각과 앞으로 나아가야 할 방향 그리고 준비해야 할 사항 등에 대해 열띤 토론이 이어졌다. 개발자로서도 꽤나 의미 깊은 시간이 아니었나 싶다. 솔직히 시간에 쫓겨 개발에 몰두하다 보면 전체적인 그림을 못 보고 지엽적인 문제에 치중하게 될 때가 많은데, 이렇게라도 시간을 내어 서비스 전반에 걸쳐 되돌아볼 수 있는 시간을 가진다는 게 여러 가지 면에서 좋은 방법인 듯싶다.론칭 후에도 할 일이 많다. 서비스를 키워나가야 하기 때문. 마케팅팀도 보강되었고 지속적으로 인력도 늘어갔다. 외부 업체와의 MOU도 점차 늘려 나갔고  그에 따라 서비스에 상품군과 기능들도 많이 늘어왔다. 개발팀의 업무량도 자동적으로 증가. 상품에 대한 소비자들의 직접적인 의견을 들을 수 있는, 그리고 그에 따라 1) 상품 선택에 도움이 되는 리뷰 기능의 확충, 2) 소비자들이 상품의 조회에 그치지 않고 선택한 상품의 가입을 보다 더 쉽게 이룰 수 있도록 3) 상품 조회에서부터 선택, 가입에 이르는 플로워를 다방면으로 테스트하고 개선시켜 나간다든가 하는 일들이 많아졌다. 게다가 4) CMS 등의 내부 시스템의 개발까지 그야말로 눈코 뜰 새 없는 시간의 연속이었다.#육아코딩 집에서도 눈코뜰새 없이 열일 중ㅎ https://www.instagram.com/leepublic/론칭 이후 4개월이 지난 지금.건방지게 느껴질 수도 있지만 당연히 발전적이다. 여전히 성장할 여지(Room to Grow)가 상당히 많다. 그간 상품 수도 많이 늘었고, 서비스의 개선도 지속적으로 이루어져, 실질적은 성과들도 조금씩은 나타나기 시작했다. Stay hungry! 아직도 부족함을 느끼는 건 나만의 욕심은 아닐 것이다. 금융 소비자의 정보 불균형을 해소하겠다던 가치와 신념에 있어 정말 새발의 피만큼의 진전을 이루었겠지만 말이다.그래도 서로 비교할 수 있고, 간단한 몇 가지 항목만으로도 쉽게 상황에 맞는 상품을 볼 수 있다는 것만으로도 많은 시간과 기회비용을 아낄 수 있는 방법을 제기할 수 있어서 다행이라고 생각하고 있다. 솔직히, 나 스스로도 은행 대출을 끼고 집을 구입했던 사람으로서 어디 가서 물어보기도 힘들고 일일이 은행 사이트들을 찾아다니며 비교하기도 힘든데, 진작에 이런 서비스가 있었더라면 몇 번이고 써봤을 거다. 이건 진심이다.아직 해야 할 일은 많이 남아 있다. 처음부터 세세한 부분까지 모두 파악하는 건 어렵겠지만 개개인의 재정상태, 소비형태, 삶의 방식 등의 여러 가지 데이터를 기반으로 대출 및 예적금, 나아가 향유할 수 있는 금융생활에 대한 조언자, 설계자가 되고 싶고 또 그렇게 만들어갈 생각이다. 십원짜리 하나 쓰는 것도 잔소리할 테세다.사람을 기반으로 한 금융 테크놀로지를 꿈꾸며...그러기 위해선 "사람"에 대한 고민이 제일 필요한 일일 게다. 빅데이터라든가, 대용량 처리 시스템이라든가, 클라우드 서비스라든가, 금융 데이터 분석을 위한 Pandas나 데이터의 연관 관계 분석을 위한 딥러닝이라든가. 기술적인 부분들도 매우 중요하고 또 이루어져야 할 일이기도 하지만 그 무엇보다 중요한 건 역시 "사람"이 아닐까 싶다.DVD대여 회사로 출발하여 이제 글로벌 컨텐츠 공룡으로 인정받는 넷플릭스(Netflix) 성공의 기반은 기술도 아니고 콘텐츠도 아니었다. 바로 "사람"에 집중했던 것. 넷플릭스는 #하우스오브카드 (House of Card) 드라마를 출시하면서 “우리는 시청자들이 무엇을 보고 싶어 하는지 잘 알고 있으며, 분석 알고리즘을 통해 누가 케빈 스페이스 혹은 정치 드라마를 좋아하는지 파악하여 그들에게 추천할 것이다”라고 자신 한 바 있다.모든 데이터의 중심에는 "사람"이 있었다. "사람"에 대한 이해 위에 기술을 기반으로 콘텐츠를 입혀 개개인에게 보다 사람답게 다가갔던 게 성공의 열쇠가 아니었나 싶다.핀다 또한 그러한 길을 걸어가야 할 터,나 또한 사람을 기반으로 한 기술의 발전을 꿈꿔볼 일이다.핀다의 금융 테크놀로지이혁 드림Hyek from FindaHead of Engineer#핀다 #개발팀 #개발자 #팀원소개 #조직문화

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결론기존의 레거시를 바탕으로 클라우드 마이그레이션을 진행하는 기업들은 클라우드에서 발생하는 다양한 운영 이슈들을 겪을 수 밖에 없습니다. 대부분 클라우드 이전 사업을 진행하는 데 있어서 이전 서비스 성능을 맞추는 데만 집중하다보니 이전 후 운영과정에서 발생하는 많은 문제들은 운영팀이 짊어지게 됩니다. 하지만 이 문제들은 개발팀과 운영팀이 함께 지속적으로 개선해 나가야 합니다. 최종적으로 클라우드 네이티브 구조가 완성되기 위해서는 시스템과 조직 문화 모두가 변화해야 합니다. 클라우드 마이그레이션은 엄청 고난한 일입니다. 만일 클라우드를 도입했는데, 아직 불안함이 있다면 아직 클라우드 마이그레이션이 끝나지 않은것입니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

 버즈빌 개발팀의 모바일 스터디 그룹이란? 모바일 잠금화면 미디어 플랫폼 ‘버즈빌’의 개발팀이 진행하는 모바일 스터디 그룹이란, 모바일이라는 큰 주제를 핵심으로 하여 크고 작은 연관된 기술을 리뷰하고 토의하는 스터디 모임입니다. 2018년 7월에 처음 개설되어 현재까지 매주 진행하고 있으며 특정한 기한 없이 지속적으로 진행할 예정입니다. 모바일이라는 핵심 주제를 고지하기는 했지만 사실상 개발에 관련된 모든 주제가 이야기될 수 있으며, 개발 언어, 특정 라이브러리 및 프레임워크, 개발 관련 툴, Google I/O와 같은 각종 컨퍼런스 등 거의 모든 것이 저희의 관심사입니다. 심지어 한 번은 자주 쓰는 단축키에 대해서도 토의한 적이 있습니다. 어떤 목적을 갖고 만들어졌는가? 개발이라는 일은 특히나 최신 이슈에 민감한 분야인 것 같습니다. 빈번하게 일어나는 OS 업데이트와 그에 따른 이슈 처리, 주요 컨퍼런스 내용에 따른 개발 트렌드 변화, 갑작스레 혜성처럼 등장한 개발 라이브러리… 저희 개발자들은 이러한 이슈에 항상 귀를 기울여야 하며, 그에 대해 생각을 정리할 필요가 있습니다. 또한 이러한 기술 습득은 저희 직원들의 커리어에도 중요한 지표가 될 것은 자명하지요. 그러나 실제 업무에 집중하다 보면 자칫 이러한 이슈에 대해서 멀어지게 되고는 합니다. 숲을 보지 못하고 나무만 보는 꼴이랄까요. 모바일 스터디 그룹은 바로 이러한 점을 해결해보기 위해서 개설됐습니다. 적어도 1주일에 한 번씩은 업무에서 잠시 떨어져 다양한 개발 주제로 생각을 정리해보자는 게 이 스터디의 목적이며, 다재다능한 그룹원들의 참여 아래 훌륭하게 진행되고 있습니다. 어떻게 진행되고 있는가? 우선, 매주 월요일 점심마다 스터디가 진행되고 있습니다. (스터디를 할 경우 회사에서 점심을 제공하고 있어 회사의 모든 스터디 모임이 더욱 활성화되는 것 같습니다.) 스터디 주제는 1주일 전에 그룹원들과 이야기를 통해서 정하고 있고, 주제가 정해지면 자발적으로 주제에 대해 학습하며 자료를 공유합니다. 스터디 당일에는 일정 시간을 개별 학습하는 용도로 사용하고, 그 후에 각자 공부한 내용을 바탕으로 자기 생각을 이야기합니다. 기본적으로 상황에 맞게 자유롭게 진행되기 때문에 꼭 위와 같은 방식을 고수하지는 않습니다. 때로는 특정 주제에 대해서 스터디원이 세미나를 희망하기도 하는데, 이 경우 발표자가 자료를 만들어서 세미나를 진행하기도 합니다. 한 번 했던 주제에 대해서 다수가 흥미를 가질 경우 다음 주에 조금 더 깊이 있는 이야기를 나누거나 실제 실습을 해보는 시간을 갖기도 합니다. 아직 시도하지는 않았지만, 주요 컨퍼런스 영상을 보는 시간으로도 활용할 생각입니다. 어떤 주제를 진행했는가? 모든 주제를 나열할 수는 없지만, 대표적인 사례에 대해서 전달하겠습니다.  RxJava : Reactive 진영의 자바(Java) 라이브러리. 그 내부 원리와 구조 학습 Unit Test : JUnit 4, Mockito, Robolectric의 활용과 실전 예제 학습 Kotlin(코틀린) : 안드로이드(Android)에서의 Kotlin 트렌드 확인. Kotlin의 장단점 분석 MVP / MVVM : 안드로이드(Android) 아키텍쳐로 바라보는 MVP / MVVM의 내용 및 차이 학습  이 외에도 여러 주제에 대해서 지속해서 스터디를 진행했지만, 위 내용은 스터디원이 전체적으로 공감하고 도입 의지를 이끌었다는 점에서 인상적이었던 것 같습니다. 특히 코틀린과 같은 경우는 실험적으로 프로젝트에서 도입을 진행하고 있고, 코드 간결화, Null-Safety 측면에서 큰 장점을 느끼고 있습니다. 이처럼 저희 스터디는 학습하게 된 내용을 단순히 지식으로 놔두지 않고 실제 프로덕션에 도입까지 충분히 진행 할 수 있으며, 반대로 실제 프로덕션에 더 좋은 기술을 도입하기 위해서 다양한 주제를 찾아가고 있습니다.버즈빌의 스터디는 무엇이 다른가? 개인적으로 꽤 많은 스터디에 참여해 봤다고 생각합니다. 다양한 주제는 물론 강의형, 토론형 등 여러 방식으로 진행해본 경험이 있습니다. 그중에는 1년 넘게 유지되면서 다양한 지식을 습득한 모임도 있었고, 몇 번 해보지도 못하고 와해한 안타까운 케이스도 있었습니다. 덕분에 좋은 스터디란 무엇인가에 대해 꽤 고민을 해봤고 어떤 부분이 중요한지 나름대로 생각하고 있는 부분이 있습니다. 그리고 그러한 측면에서 버즈빌의 스터디는 좋은 스터디라고 분명히 말씀드릴 수 있습니다. 그렇다면 구체적으로 어떤 점이 버즈빌의 스터디를 좋게 만드는 것일까요? 그 이유는 다음과 같습니다. 첫째, 버즈빌의 수평적인 문화 버즈빌의 사내 문화는 수평적이고 자율적인 문화로 유명합니다. 소위 고루한 잔소리꾼 문화가 없기 때문에 자신의 의견을 누구나 자유롭게 이야기합니다. 사내문화가 스터디와 무슨 상관이 있냐 하실 수 있지만, 수직적인 조직의 사내 스터디와 비교했을 때 큰 차이를 볼 수 있었습니다. 버즈빌의 스터디에서는 여러 사람이 어떠한 권위에 눈치 보지 않고 자유롭게 자신의 의견을 제시하며, 듣는 이 또한 어느 의견이든 함부로 가늠하지 않고 진지하게 받아들입니다. 이는 단순히 스터디 토론에서만 적용 되는 것이 아니라, 스터디 시스템에 대해서도 불합리하거나 개선하고 싶은 점을 여과 없이 이야기합니다. 그리고 그들의 의견을 피드백하여 시스템이 지속적으로 개선되고 있습니다. 결국은 버즈빌의 수평적인 문화가 스터디 문화 자체도 현실적이고 합리적으로 바꿔나간다고 할 수 있습니다. 둘째, 뛰어난 구성원 스터디에서 구성원은 분명 굉장히 중요한 요소입니다. 구성원의 역량과 열정에 따라서 스터디의 질과 지속력이 결정됩니다. 그런 측면에서 버즈빌은 상당히 축복받은 조직임에 틀림없습니다. 당장 제 옆만 둘러봐도 어디서 이런 분들이 나왔을까 싶을 정도로 뛰어난 역량의 소유자가 많으니까요. 아마 인사팀에서 일을 잘하고 있나 봅니다. 여하튼, 버즈빌에는 다재다능한 인재가 정말 많습니다. 각종 분야에 있어서 상당한 지식을 보유하신 분도 굉장히 많으시고, 무엇보다 개발을 좋아하고 새로운 기술을 배우는 것에 긍정적입니다. 열정이 넘친 나머지 스스로 일정을 잡아서 기술 세미나를 진행하기도 하지요. 이런 분들과 함께 하는 스터디, 안 좋을 수가 없습니다. 셋째, No 강제, No 의무 제가 생각하는 좋은 스터디의 중요한 요소는 지속력입니다. 아무리 좋은 스터디라도 무리한 일정과 과제의 압박이 있다면 지속되기 힘들다고 생각합니다. 단발성으로 집중하여 어떤 지식을 습득하려는 게 아닌 이상은, 결국 얼마나 꾸준히 스터디원이 참여하고 공부를 할 수 있는지가 중요합니다. 그러한 측면에서 볼 때 참가를 강제하고, 어떠한 의무성인 과제를 부여하는 것은 지양해야 합니다. 공부는 스스로의 의지에 의해서 수행되어야 하며, 스터디 시스템에서 이를 강제 해봤자 결국은 보여주기 식의 활동밖에 되지 않습니다. 사람이 어떻게 모든 주제에 항상 열정적으로 공부를 하겠습니까. 그렇기에 스터디라는 시스템보다는 사람이 우선이어야 하며, 공부는 본인의 자유입니다. 위와 같은 요소로 인해 전 결론을 내봅니다. 버즈빌에서 굉장히 좋은 스터디를 하게 되었다고. 결론 버즈빌에서 스터디는 CEO 분들을 비롯하여 많은 구성원이 장려하고 권장하는 부분입니다. 그들은 직원의 역량 강화가 곧 회사 역량의 강화라는 인식을 바로 갖고 있으며, 이를 위해 정책적으로 지원하는 방안을 마련해주고 있습니다. 스터디 제도뿐만 아니라 각 개인이 성장할 수 있도록 동아리 지원, 자기개발비 지원 등은 물론 읽고 싶은 책은 무제한으로 제공 해주고 있습니다. 어쩌면 이러한 사소한 점 하나하나가 버즈빌의 소중한 자산이 아닐까 생각하며, 이만 글을 마무리 짓습니다. 감사합니다.작가소개 Ethan Yoo, Software Engineer (Android) 안녕하세요. 버즈빌에서 안드로이드 부분 개발을 담당하고 있는 Ethan (이든)입니다. 개발이라는 주제로 다양한 곳에 관심사를 갖고 있고, 동료와 함께 개발 이야기를 하는 것을 좋아합니다. 메인 언어는 자바(Java)를 사용하고 있지만, 코틀린(Kotlin) / 파이썬(Python) / 자바스크립트(JavaScript) / 하스켈(Haskell) 등 다양한 언어에 대해 경험이 있습니다. 최근에는 시스템 아키텍쳐에 관심을 갖고 반응형 프로그래밍, 함수형 프로그래밍 등이 안드로이드와 어떤 구조로 표현 될 수 있을지 고민하곤 합니다. 제가 만든 서비스가 세상을 바꿀 수 있기를 희망하고, 이를 위해 버즈빌에서 오늘도 열심히 개발을 하고 있습니다.

모바일 잠금화면 미디어 플랫폼 사업자 버즈빌은 어떠한 인재를 찾는지 지원자에게 잘 알리려고 노력합니다. 그럼 지원자도 버즈빌이 자신에게 맞는 기업인지 알 수 있을 테니까요. Buzzvil Career에서는 각 직무에 대해 더욱 심도 있는 정보를 제공합니다. 현재 채용에 관련한 자세한 내용은 여기에서도 확인 가능합니다. 이 게시물은 데이터 애널리스트 Elia와의 인터뷰를 담고 있습니다. 그는 좋은 데이터 애널리스트는 어떤 사람인지에 대해 이야기합니다. 데이터를 좋아하고 데이터에 기반한 기업 성장에 기여하고 싶다면 이 글에 주목해주세요.업무에 대해 설명해주세요.안녕하세요. 버즈빌의 데이터 애널리스트 Elia입니다. 팀에서 일한 지 어느덧 4년이라는 세월이 흘렀네요. 데이터 분석을 위한 툴을 세팅하고 많은 양의 가공된 데이터를 공유하고 있습니다. 데이터로 무엇을 하고 어떻게 활용할지 고민하는 것이 제 일입니다. 또 저는 올바른 결정을 내리고 효율적으로 업무를 수행할 수 있도록 A/B 테스팅과 다양한 연구를 수행하고 있습니다. 마지막으로 SQL 세션을 열어서 사람들이 데이터에 유연하게 접근하고 잘 사용할 수 있도록 합니다.왜 버즈빌을 선택 했나요?가까운 지인이 이 회사를 추천해줬습니다. 분위기가 친근했고 한국에도 이런 곳이 있다는 게 놀라웠습니다. 그리고 버즈빌은 석촌 호수 바로 앞에 있어서 전망이 훌륭한데 특히 봄이 되면 벚꽃을 볼 수 있습니다. 그리고 무엇보다 사무실은 저희 집과 가깝습니다. 그러니 제가 거절할 이유가 없었죠.버즈빌은 어떤 곳인가요?버즈빌은 데이터 애널리스트로서 성장할 수 있는 곳입니다. 팀 규모가 그렇게 크지 않아서 유연합니다. 많은 사람과 이야기를 할 수 있고 사람들을 어떻게 도울 수 있을지, 어떤 일을 이루어야 하는지 스스로 고민할 수 있기 때문에 컨설턴트 같은 존재입니다. 그만큼 특정 역할에 고정되지 않습니다. 데이터 분석은 새로운 분야입니다. 그래서 회사가 그것을 어떻게 생각하는지에 따라 담당자가 할 수 있는 일이 달라집니다. 다행히 버즈빌리언은 새로운 아이디어와 제안에 개방적인 태도를 보입니다. 버즈빌처럼 새로운 분야를 배우는 걸 좋아하는 집단도 없을 겁니다. 그래서 담당자가 얼마나 능동적인지에 따라 할 수 있는 일이 많아집니다. 정말 독특한 문화를 가졌죠.팀 분위기는 어떤가요?여기서는 다양한 프로젝트에 대해 데이터를 조사하고 돌파구를 찾아야 합니다. 초집중해야 하며 테스트를 수행하고 데이터를 분석하는 방법을 발견해야만 합니다. 올바른 의사 결정을 내리는 것은 쉬운 일이 아니기 때문에 데이터 애널리스트가 필요하죠. 이 역할이 왜 필요한지 사람들이 알 수 있도록 자신을 잘 표지셔닝을 해야 합니다. 그래야 새로운 프로젝트에 참여할 수 있는 기회가 더 많아지고 기업 성장에 더욱 직접적으로 기여할 수 있죠.좋은 데이터 애널리스트는 어떤 사람일까요?# 커뮤니케이션 데이터 애널리스트는 효과적으로 딱 필요한 말만 잘 전달하는 커뮤니케이터가 되어야 합니다. 같은 말을 반복하거나 요점에서 자꾸 벗어나면 안 되죠. 버즈빌에서 데이터 분석가로 일하려면 다양한 팀과 일하기 때문에 소통을 효과적으로 잘해야만 합니다. 그래야 데이터 연구 결과가 정확할 수 있기 때문이죠. 이는 더 나은 비즈니스 의사 결정으로 이어지죠.#적극성 데이터 애널리스트는 능동적일수록 더 성장할 것입니다. 당신의 역량이 향상될 것이고 되고 직장에서 다양한 사람들과 상호작용하는 요령을 익힐 수 있습니다. 버즈빌은 데이터 애널리스트가 다양한 연구를 수행하기 좋은 인프라를 갖추고 있는데 이것은 데이터 분석이 새로운 분야라는 점에서 매우 플러스입니다. 따라서 버즈빌은 새로운 기회를 얼마든지 제공할 수 있기 때문에 탐험을 즐기는 사람을 찾고 있습니다.*버즈빌은 현재 채용 중입니다. (전문연구 요원 포함) 자세한 내용은 아래 버튼을 눌러주세요!모바일 잠금화면 미디어 플랫폼 사업자 버즈빌은 어떠한 인재를 찾는지 지원자에게 잘 알리려고 노력합니다. 그럼 지원자도 버즈빌이 자신에게 맞는 기업인지 알 수 있을 테니까요. Buzzvil Career에서는 각 직무에 대해 더욱 심도 있는 정보를 제공합니다. 현재 채용에 관련한 자세한 내용은 여기에서도 확인 가능합니다. 이 게시물은 데이터 애널리스트 Elia와의 인터뷰를 담고 있습니다. 그는 좋은 데이터 애널리스트는 어떤 사람인지에 대해 이야기합니다. 데이터를 좋아하고 데이터에 기반한 기업 성장에 기여하고 싶다면 이 글에 주목해주세요.업무에 대해 설명해주세요.안녕하세요. 버즈빌의 데이터 애널리스트 Elia입니다. 팀에서 일한 지 어느덧 4년이라는 세월이 흘렀네요. 데이터 분석을 위한 툴을 세팅하고 많은 양의 가공된 데이터를 공유하고 있습니다. 데이터로 무엇을 하고 어떻게 활용할지 고민하는 것이 제 일입니다. 또 저는 올바른 결정을 내리고 효율적으로 업무를 수행할 수 있도록 A/B 테스팅과 다양한 연구를 수행하고 있습니다. 마지막으로 SQL 세션을 열어서 사람들이 데이터에 유연하게 접근하고 잘 사용할 수 있도록 합니다.왜 버즈빌을 선택 했나요?가까운 지인이 이 회사를 추천해줬습니다. 분위기가 친근했고 한국에도 이런 곳이 있다는 게 놀라웠습니다. 그리고 버즈빌은 석촌 호수 바로 앞에 있어서 전망이 훌륭한데 특히 봄이 되면 벚꽃을 볼 수 있습니다. 그리고 무엇보다 사무실은 저희 집과 가깝습니다. 그러니 제가 거절할 이유가 없었죠.버즈빌은 어떤 곳인가요?버즈빌은 데이터 애널리스트로서 성장할 수 있는 곳입니다. 팀 규모가 그렇게 크지 않아서 유연합니다. 많은 사람과 이야기를 할 수 있고 사람들을 어떻게 도울 수 있을지, 어떤 일을 이루어야 하는지 스스로 고민할 수 있기 때문에 컨설턴트 같은 존재입니다. 그만큼 특정 역할에 고정되지 않습니다. 데이터 분석은 새로운 분야입니다. 그래서 회사가 그것을 어떻게 생각하는지에 따라 담당자가 할 수 있는 일이 달라집니다. 다행히 버즈빌리언은 새로운 아이디어와 제안에 개방적인 태도를 보입니다. 버즈빌처럼 새로운 분야를 배우는 걸 좋아하는 집단도 없을 겁니다. 그래서 담당자가 얼마나 능동적인지에 따라 할 수 있는 일이 많아집니다. 정말 독특한 문화를 가졌죠.팀 분위기는 어떤가요?여기서는 다양한 프로젝트에 대해 데이터를 조사하고 돌파구를 찾아야 합니다. 초집중해야 하며 테스트를 수행하고 데이터를 분석하는 방법을 발견해야만 합니다. 올바른 의사 결정을 내리는 것은 쉬운 일이 아니기 때문에 데이터 애널리스트가 필요하죠. 이 역할이 왜 필요한지 사람들이 알 수 있도록 자신을 잘 표지셔닝을 해야 합니다. 그래야 새로운 프로젝트에 참여할 수 있는 기회가 더 많아지고 기업 성장에 더욱 직접적으로 기여할 수 있죠.좋은 데이터 애널리스트는 어떤 사람일까요?# 커뮤니케이션 데이터 애널리스트는 효과적으로 딱 필요한 말만 잘 전달하는 커뮤니케이터가 되어야 합니다. 같은 말을 반복하거나 요점에서 자꾸 벗어나면 안 되죠. 버즈빌에서 데이터 분석가로 일하려면 다양한 팀과 일하기 때문에 소통을 효과적으로 잘해야만 합니다. 그래야 데이터 연구 결과가 정확할 수 있기 때문이죠. 이는 더 나은 비즈니스 의사 결정으로 이어지죠.#적극성 데이터 애널리스트는 능동적일수록 더 성장할 것입니다. 당신의 역량이 향상될 것이고 되고 직장에서 다양한 사람들과 상호작용하는 요령을 익힐 수 있습니다. 버즈빌은 데이터 애널리스트가 다양한 연구를 수행하기 좋은 인프라를 갖추고 있는데 이것은 데이터 분석이 새로운 분야라는 점에서 매우 플러스입니다. 따라서 버즈빌은 새로운 기회를 얼마든지 제공할 수 있기 때문에 탐험을 즐기는 사람을 찾고 있습니다.*버즈빌은 현재 채용 중입니다. (전문연구 요원 포함) 자세한 내용은 아래 버튼을 눌러주세요!버즈빌과 함께하고 싶은 분은 지금 바로 지원 해주세요! (전문연구요원 포함)