스토리 홈

인터뷰

피드

뉴스

조회수 2305

AWS 서비스를 활용한 Kubernetes 클러스터 구축 - VCNC Engineering Blog

Kubernetes 클러스터를 상용 환경에서 운영하기 위해서는 몇 가지 추가 구성요소를 설치해야 합니다. 예를 들어 Ingress를 만들더라도 실제로 트래픽을 받아줄 Ingress Controller를 설치해두지 않았으면 소용이 없습니다. 그리고 모니터링을 위해 컨테이너의 로그나 CPU/메모리 사용량 등을 수집, 조회할 수 있는 서비스도 필요합니다.다행히 이러한 추가 구성요소 또한 Kubernetes 클러스터 위에서 일반 애플리케이션과 거의 같은 방식으로 작동하므로 설치하는 것이 어렵지는 않습니다. 다만 클러스터를 원하는 대로 구성할 수 있는 만큼 선택의 폭이 넓어서 여러 가지 해법을 놓고 고민하게 될 수 있습니다. 이 글에서는 타다 서비스를 위해 Kubernetes 클러스터를 구성할 때 어떤 선택을 했는지, 특히 AWS 환경에서는 어떤 서비스들을 활용할 수 있는지 공유합니다.서비스를 외부에 노출: NGINX Ingress Controller + NLBIngress Controller 고르기Kubernetes에서 클러스터 내부 서비스를 외부에 HTTP(S)로 노출할 때는 Ingress를 사용할 수 있습니다. TLS 암호화, 로드밸런싱, 호스트명/경로 기반 라우팅 등을 제공해서 상당히 편리한데, Ingress가 실제로 작동하기 위해서는 Ingress Controller가 필요합니다.시중에는 다양한 종류의 Ingress Controller 솔루션이 나와 있습니다. 그중 Kubernetes 프로젝트에서 공식 지원하는 NGINX Ingress Controller와 AWS ALB 로드밸런서를 이용하는 AWS ALB Ingress Controller를 두고 고민을 했습니다.타다에서는 클라이언트(모바일 앱)에 실시간 이벤트를 전달하기 위해 gRPC를 사용하고 있어서 gRPC를 지원하지 않는 ALB는 선택할 수 없었습니다. 그리고 AWS ALB Ingress Controller는 현재 Ingress 하나마다 ALB를 1개 생성하는 구조여서 앞으로 노출할 서비스 수가 늘어난다면 비용 효율이 떨어진다고 판단했습니다. 따라서 NGINX Ingress Controller를 선택하게 되었습니다.NGINX Ingress Controller는 NGINX 웹서버를 기반으로 하므로 gRPC 모듈을 비롯하여 다양한 NGINX 모듈을 통해 굉장히 세세한 부분까지 설정할 수 있습니다. NGINX Ingress Controller는 Ingress나 Ingress가 가리키는 서비스의 엔드포인트에 변화가 생길 때마다 동적으로 NGINX 설정을 업데이트하는 방식으로 동작합니다.NGINX Ingress Controller 로드밸런싱NGINX Ingress Controller를 사용해도 외부에서 오는 트래픽을 적절히 분배해 줄 외부 로드밸런서는 필요합니다. AWS의 로드밸런서는 Classic ELB, ALB, NLB가 있습니다. 앞서 설명했듯이 ALB는 gRPC를 지원하지 않아서 Classic ELB를 TCP 모드로 사용하거나 NLB를 사용해야 합니다. Classic ELB는 동시에 많은 연결을 처리하려면 웜 업이 필요한 단점이 있어 NLB를 사용하기로 하였습니다.최근 NLB가 TLS termination을 지원하기 시작했지만, HTTP/2와 gRPC를 사용하기 위해 필요한 ALPN 정보를 설정할 수 없어서 NGINX 수준에서 TLS 암호화를 처리하고 있습니다. NLB 수준에서 TLS 처리를 하면 무료로 자동 갱신되는 ACM 인증서를 사용할 수 있는 등 여러 가지 이점이 있어서 아쉽습니다.Kubernetes에서 LoadBalancer 타입의 서비스를 생성하면 알아서 AWS 로드밸런서를 만들어줍니다. 하지만 이렇게 해서 NLB를 생성하는 방식은 아직 알파 기능입니다. 따라서 먼저 NodePort 타입의 서비스를 생성하여 모든 노드의 특정 포트에 NGINX를 노출한 다음, 별도로 생성한 NLB에 노드들이 속한 오토스케일링 그룹을 연결해주는 방식으로 직접 설정하게 되었습니다.정리해보면 외부에서 오는 트래픽을 처리할 때는 다음과 같은 과정을 거칩니다.모든 서브도메인(*.tadatada.com)은 NLB를 가리킵니다.NLB의 443 포트로 암호화된 HTTP 또는 gRPC 요청이 들어옵니다. NLB는 적절한 Kubernetes 노드 중 하나의 특정 포트(예: 30000번)로 요청을 전달합니다.Kubernetes 노드에서는 포트 번호를 보고 NGINX 서비스로 향하는 요청임을 알 수 있고 NGINX 컨테이너 중 하나로 요청을 전달합니다.NGINX는 복호화를 한 다음 HTTP Host 헤더를 확인하여 요청을 전달할 Ingress를 알아냅니다. 그리고 해당 Ingress의 엔드포인트 중 하나로 복호화한 요청을 프록시합니다.애플리케이션 컨테이너가 요청을 처리합니다.트래픽 흐름: NLB → NodePort → NGINX Ingress Controller → 내부 서비스Pod에 IAM 역할 부여: kube2iamS3, SQS 등 IAM으로 인증하는 AWS 서비스에 접근하려면 인증 정보가 필요합니다. EC2에서는 액세스 키를 직접 넣는 대신 EC2 인스턴스 프로파일로 인스턴스에 IAM 역할을 부여할 수 있습니다. 하지만 하나의 Kubernetes 노드 (=EC2 인스턴스)에는 여러 Pod이 실행될 수 있기 때문에 Pod마다 다른 IAM 역할을 부여하기를 원한다면 인스턴스 프로파일을 활용할 수 없게 됩니다. (인스턴스 프로파일에는 하나의 IAM 역할만 부여 가능)kube2iam을 사용하면 다음과 같이 Pod 어노테이션으로 IAM 역할을 지정할 수 있습니다.apiVersion: v1 kind: Pod metadata: name: aws-cli labels: name: aws-cli annotations: iam.amazonaws.com/role: role-arn spec: ... 설치나 사용법은 문서를 참고하면 어렵지 않은데, 원리를 간단히 설명해 보겠습니다. EC2 인스턴스 안에서는 특정 IP 주소(169.254.169.254)로 접속하면 EC2 메타데이터 API에 접근할 수 있습니다. AWS SDK는 EC2 메타데이터 API를 통해서 인스턴스 프로파일에 붙은 IAM 역할과 IAM 역할에 해당되는 액세스 키 쌍을 받아오게 됩니다.kube2iam은 모든 노드에 실행되면서 Pod 내부에서 EC2 메타데이터 서버 주소로 나가는 모든 요청을 가로챕니다. 그리고 인스턴스 프로파일 정보와 액세스 키 발급 요청을 kube2iam 서버가 대신 처리합니다. 따라서 Pod 안에서는 인스턴스 프로파일이 부여된 EC2 인스턴스 내부에 있는 것처럼 느껴지게 됩니다.추후 AWS SDK에 EKS 지원이 추가되면 별도로 데몬을 설치하지 않고도 Pod에 IAM 역할을 줄 수 있게 될 것으로 보입니다.로그 수집: fluentd + CloudWatch LogsKubernetes의 컨테이너가 stdout/stderr로 출력하는 로그는 노드에만 쌓이고 컨테이너를 재시작하거나 삭제하면 함께 삭제됩니다. 또한 노드의 디스크가 꽉 차는 것을 방지하기 위해 일정 크기를 넘으면 오래된 로그는 없어집니다. 그러므로 로그가 사라지지 않도록 계속 어딘가에 모아두어야 합니다.AWS에서 활용할 수 있는 로그 저장 서비스에는 CloudWatch Logs가 있습니다. fluentd를 DaemonSet으로 노드마다 하나씩 실행해서 컨테이너 로그를 CloudWatch Logs로 전송할 수 있습니다.CloudWatch Logs에 저장한 로그는 최근 나온 CloudWatch Logs Insights로 검색, 분석할 수 있습니다. 아직 나온 지 얼마 되지 않아서 기능이 많지는 않지만, 간단히 조회하는 용도로는 충분합니다.CloudWatch Logs Insights 사용 예모니터링: PrometheusEC2 인스턴스 하나에 서비스 하나를 띄워서 사용할 때는 CloudWatch로 CPU 사용률 등의 지표를 측정할 수 있었습니다. 하지만 Kubernetes를 사용하면 여러 서비스가 하나의 인스턴스에서 동시에 실행될 것이므로 인스턴스 수준의 지표는 무의미합니다. 특히 최소 실행 단위인 컨테이너 수준의 CPU 사용률 같은 값을 측정해야 하는데, CloudWatch를 사용하기에는 과금 체계가 적합하지 않습니다.기본 제공되는 5분 간격의 EC2 지표는 무료지만 CloudWatch에 커스텀 지표를 올리게 되면 지표 당 비용을 지불해야 합니다. 이 때 '지표'는 지표 이름 + 고유한 차원(dimension)의 조합입니다. 예를 들어 CPUUtilization이라는 이름의 지표가 PodName=server-aaaaaaaa과 PodName=server-bbbbbbbb라는 다른 차원으로 올라온다면 각각을 다른 지표로 취급합니다. 따라서 지표 수가 너무 많아지지 않게 조정해야 하는데 그러면 상세하게 모니터링하기가 어렵습니다.비용 문제도 있고, Kubernetes의 여러 가지 정보를 CloudWatch로 내보내는 기존 도구가 없었기 때문에 다른 방법을 찾아보게 되었습니다. 그래서 Kubernetes 모니터링을 위해 많이 사용하는 Prometheus를 선택했습니다. Prometheus를 온전히 사용하기 위해서는 다양한 컴포넌트들이 필요한데, Prometheus Operator Helm 차트를 사용하면 비교적 쉽게 구축할 수 있습니다.Prometheus는 Kubernetes 클러스터 모니터링 외에 애플리케이션 모니터링에도 사용할 수 있습니다. 타다의 애플리케이션들은 Spring Boot로 작성되어 있는데 Spring Boot Actuator와 Micrometer의 Prometheus 지원을 사용해서 애플리케이션 수준의 지표도 Prometheus로 모니터링하고 있습니다. 특히 Prometheus Operator를 사용하면 모니터링 대상을 추가할 때 Prometheus 설정 파일을 수정하지 않아도 Kubernetes에 ServiceMonitor 리소스를 등록하기만 하면 되어서 편리합니다.Prometheus로 수집된 지표는 Grafana 대시보드로 시각화하고, 정해진 조건에서 Alertmanager를 통해 PagerDuty와 Slack에 알림을 보냅니다.Grafana 대시보드의 모습자동 처리량 확장: Cluster AutoscalerKubernetes에서 자동 처리량 확장은 크게 두 종류로 나눌 수 있습니다. 먼저 Horizontal Pod Autoscaler로 CPU, 메모리 사용량에 따라 Pod의 수를 자동으로 조정할 수 있습니다. HPA가 실제로 동작하기 위해서는 오토스케일링을 위한 지표를 제공하는 Metrics Server를 설치해야 합니다. 그런데 부하가 증가해서 HPA가 Pod 수를 늘리려고 할 때 워커 노드에 여유가 충분하지 않으면 새로운 Pod을 실행할 수 없어서 소용이 없습니다. 이 때 워커 노드의 수를 자동으로 조정해주는 것이 Cluster Autoscaler입니다. Cluster Autoscaler는 노드 수를 증가시키기만 하는 것이 아니라 여유가 생겼을 때 노드 수를 자동으로 줄여서 불필요한 비용이 발생하지 않도록 해줍니다.AWS 환경에서 Cluster Autoscaler는 EC2 API를 통해 EC2 오토스케일링 그룹의 Desired Capacity 값을 필요한 노드 수로 조정하는 방식으로 작동합니다. 따라서 Cluster Autoscaler에는 EC2 API를 호출할 수 있는 IAM 권한을 주어야 합니다. 이를 위해 위에서 소개한 kube2iam을 사용할 수 있습니다. 그리고 Cluster Autoscaler가 오토스케일링 그룹을 자동으로 발견할 수 있도록 미리 정해진 태그를 붙여야 합니다.한 가지 주의할 점은 노드의 오토스케일링 그룹이 여러 가용 영역(AZ)에 걸쳐있으면 안 된다는 것입니다. 오토스케일링 그룹이 여러 AZ에 속한 경우 AZ 간 인스턴스 수의 균형을 맞추려고 하는데 이 과정에서 인스턴스가 예기치 않게 종료될 수 있습니다. 이 때 해당 노드에 실행되어 있던 Pod이 안전하게 종료되지 않을 수 있기 때문에 AZ마다 오토스케일링 그룹을 따로 만들고 AZ 간 균형은 Cluster Autoscaler가 맞추도록 설정해야 합니다.도움이 되는 링크들위에서 소개한 컴포넌트들은 다음과 같은 Helm 차트를 통해 설치해서 사용하고 있습니다.stable/nginx-ingressstable/kube2iamincubator/fluentd-cloudwatchstable/prometheus-operatorstable/metrics-serverstable/cluster-autoscalerEKS Workshop: AWS 환경에서 Kubernetes 운영할 때 참고할 만한 정보가 많이 있습니다.Kubernetes Slack 채널: #eks 채널에는 AWS 직원들도 접속해 있어서 높은 확률로 답변을 받을 수 있습니다.
조회수 2130

스켈티인터뷰 / 스켈터랩스의 N잡러 엄단희 님을 만나보세요:)

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 N잡러 엄단희 님을 만나보세요:)사진1. 스켈터랩스의 N잡러 엄단희 님Q. 자기소개를 부탁한다.A. 스켈터랩스에 입사한 지 이제 8개월 정도 된 신입 소프트웨어 엔지니어, 엄단희다.Q. 스켈터랩스에서 어떤 업무를 맡고 있는가.A. 현재는 아이리스(Iris) 팀에 소속되어있다. 아이리스 팀은 맥락 인식(Context Recognition) 기술을 기반으로 SDK를 비롯한 여러가지 서비스 출시를 준비하고 있는데, 사실 지금은 레고(L.ego)팀이 준비하는 신제품인 스마트 미러 샘(Samm) 개발 업무가 주요 업무이다. 샘은 스켈터랩스가 가지고 있는 맥락 인식 기술 뿐만 아니라 음성, 얼굴, 제스처 인식을 비롯한 대화형 엔진이 모두 집약된 인텔리전트 디바이스(Intelligent Device)다. 여러 기능이 하나의 디바이스에 구현된 만큼, 샘은 다양한 모듈로 나누어져있다. 예를 들어 센서 정보를 모으는 모듈과 그 정보를 처리하는 모듈, 처리한 내용을 보여주는 UI 모듈 등이 있는데, 나는 이러한 모듈들을 gRPC 또는 bluetooth 등을 통해 서로 통신할 수 있도록 해주는 작업을 주로 진행했다. 최근에는 샘의 구매자에게 필요한 샘 어플리케이션 개발을 진행하고 있다. 아이리스 팀 관련해서는 파이어베이스(Firebase) 관련 작업을 서포트한 적이 있고, 얼마 전에는 스켈터랩스 웹사이트 개발에 참여하기도 했다.Q. 맡고 있는 업무의 가짓수가 많아 보인다. 한번에 여러 개의 프로젝트를 진행하는 것이 어렵진 않나.A. 쉽다고 말하기는 힘든 것 같다. 여러 업무에서 동일한 지식이 요구될 때도 있지만, 기본적으로 하나의 일을 처리하기 위해 집중하고 있다가 다른 업무로 전환할 때, 그 업무를 위한 나의 베이스를  바꾸는 등의 일들이 녹록치 않다. 처음에는 무엇보다 일의 우선순위를 정하는 것이 가장 버거웠다. 사실 업무마다의 기한이 정해져 있으면 당연히 급한 업무를 먼저 처리할텐데, 우리 회사는 그보다는 본인이 직접 업무량을 조정해서 기한을 정하고 처리하는 편이다. 그래서 하나의 일을 쪼개고 쪼개어, 그 중에서도 가장 빨리할 수 있는 일부터 먼저 처리하는 나만의 업무 프로세스를 만들고 있다. ‘빨리 할 수 있는 일'이라고 해서 마냥 쉬운 일을 말하지는 않는다. 그 때마다 내게 가장 맞는 일, 내가 가장 준비되어 있는 일을 자연스럽게 추려내어 업무 효율을 높이려고 한다.Q. 스켈터랩스에 어떻게 입사하게 되었는지 궁금하다.A. 재작년, 앤드비욘드라는 회사에서 인턴으로 근무했다. 당시 스켈터랩스가 앤드비욘드와 함께 개발중이던 스마트 포스(POS)기, GABE 프로젝트를 진행하며 한남동에서 같은 사무실을 쓰고 있었다. 그 프로젝트 팀에서 파견직처럼 일을 하게 되었는데, 가장 놀란 점은 ‘사람'이었다. 이렇게 누구 하나 빠짐 없이 개발을 잘하는 사람들이 모여있는 곳에서 개발하는 것은 처음이었다. 학교에서는 나름 ‘나도 잘하는 편이지 않을까’ 생각했는데 여기 와서 한없이 부족하다는 걸 깨달았다. 그런데 그렇게 부족한 신입 인턴임에도 불구하고 모두가 나를 평등하게 대해주셨고 개발 관련해서도 많이 배울 수 있었다. 덕분에 스켈터랩스는 내게 아주 좋은 이미지로 남아있었는데, 작년 스켈터랩스의 CTO인 조성진님께 오퍼를 받아서 스켈터랩스 인턴으로 일과 학업을 병행하다가 올해 정직원으로 입사하였다.Q. 인턴으로 일을 하며 학업과 병행했는지 몰랐다. A. 학교 스케줄을 우선시할 수 있도록 회사가 많이 배려해주었다. 다행히 학교가 회사와 멀지 않은 거리에 위치하기도 한다. 그래서 학교 수업은 주 2-3일 정도, 오전 타임으로 몰아서 구성했다. 시험기간이라고 하면 팀원들이 모두 나서서 ‘어서 집에 가서 공부부터 해라'라며 조언해주시고 업무적으로도 많이 도와주신 덕에 학업에 대한 지장 없이 일을 할 수 있었다.Q. 인턴을 마치고 정직원으로 입사했다면, 인턴 시절과 현재를 비교할 때 업무적으로 무엇이 가장 다른가.A. 우리 회사는 매 분기마다 분기의 목표 설정과 유사한 OKR(Objectives and Key Results)을 정하고, 이를 완료하는 방식으로 일을 진행한다. OKR에서 중요도가 높은 업무는 P0로, 가장 중요도가 낮은 업무는 P2로 표기한다. 인턴으로 처음 입사했을 때는 P1~P2 레벨의 자잘한 이슈들을 처리하는 업무가 많았다. 정직원이 되고 나니, 그만큼의 지식과 스킬이 쌓인 만큼 P0의 업무들을 조금 더 맡게되었다. 그러나 전반적인 업무의 결은 유사하다. 다만 확실히 책임감은 늘어났다고 생각한다. 인턴일 때는 ‘난 인턴이니까 몰라도 괜찮겠지?’와 같은 마인드가 있었는데, 정직원이 된 지금은 ‘정직원이 이 정도는 알고 있어야겠지?'라고 생각한다. 덕분에 공부하는 양도 이전보다는 늘어났다.사진2. 파워 코딩 중인 단희 님Q. 최근 스켈터랩스가 여러 학교의 커리어페어에 다녀오면서 많이 들었던 질문 중 하나가 ‘인공지능을 전문적으로 공부하지 않았는데, 일을 할 수 있을까요?’였다. 혹시 이 질문에 대한 답변을 해줄 수 있을까.A. 나도 입사 때 면접을 보며 같은 질문을 던졌다. 입사해서 느끼는 점은 정말 인공지능에 관련된 개발 외에 다른 영역에서도 개발해야 하는 일이 정말 많다는 점이다. 때문에 인공지능 분야를 잘 모른다고 해서 (물론 알면 좋지만) 막연한 두려움은 갖지 않아도 좋다. 물론 좀 더 코어한 부분을 개발할수록 인공지능 공부의 필요성을 점점 느끼게 된다. 이러한 기술적 갈증은 사내에서 열리는 테크톡(Tech Talk)과 같은 세미나를 통해 어느 정도 해결할 수 있으며, 업무를 위해 관련 공부가 필수적이라면 팀별로 스터디가 진행되기도 한다. 실제로 다른 팀에서는 주기적으로 관련 논문을 스터디하고 그 지식을 공유하는 세션이 진행되고 있다.Q. 스켈터랩스 입사 후 가장 뿌듯했던 순간과 힘든 순간을 꼽는다면?A. 나는 내가 무언가를 직접 만들고, 그 결과물을 선보이는 과정을 좋아한다. 그래서 가장 뿌듯한 순간으로는 회사 웹사이트를 런칭했을 때를 꼽고 싶다. ‘웹' 특성 상 내가 짠 코드들의 결과를 바로 눈으로 확인할 수 있기 때문에 개발하는 재미도 있었고, 아무래도 회사를 대표하는 사이트라 많은 사람들에게 보여질 것이라 생각하니 더욱 자부심을 갖고 일할 수 있었던 것 같다. 그런 측면에서 나중에 샘을 런칭하게 될 날도 기대된다. 반면 가장 힘들었던 순간은 작년 블루투스 개발 관련 디자인 문서 작업을 진행할 때 였다. 일단 블루투스 기술도 잘 모르는 데다가 디자인 문서 자체도 제대로 써본 적이 없어 생소했다. 사실, 개발이 안 풀리고 막혀있을 때는 그 순간만 힘들 뿐 어떻게든 해결책을 찾고 결과물을 낼 수 있었다. 그런데 디자인 문서 작업은 내가 어떤 방향성을 취해야 하는지, 지금 하고 있는 과정이 맞는 것인지가 계속 의구심이 들었다. 하루종일 컴퓨터 앞에 앉아 있어도 결과물이 없으니 마음만 조급해지는 일도 많았다. 다행히 당시 리뷰를 해주신 조성진님 등 기타 다른 개발자분들의 도움으로 문서는 마무리지을 수 있었는데, 내 한계에 대해 반성하기도, 많이 배우기도 했다.Q. 스켈터랩스 게임동호회 회장을 맡은 것으로 알고있다. 게임동호회를 소개하자면?A. 먼저 오류부터 수정해야할 것 같다. 나는 현재 게임동호회 회장은 아니다. 사내 게임동호회인 ‘Game of Troll’은 한달에 한 두번 모여서 게임을 함께 하는데, 그 게임에서 꼴찌를 한 사람이 회장이 된다. 나의 경우 저번 달 클래시로얄 게임에서 꼴찌를 하여 회장을 맡았었다. 하지만 회장이 정한 게임으로 다음 회장을 뽑기 때문에 내가 자신있는 게임인 오버워치를 9월 게임으로 선정했고, 현재는 정태형 님에게 회장 자리를 넘겨주었다. 게임은 종류에 따라 사내 블루룸 또는 PC방에서 진행한다. 블루룸에는 플스와 닌텐도 등의 각종 게임기가 완비되어 있어, 토너먼트 식으로 철권을 하거나 마리오카트를 했었다. 또 휴대폰으로는 클래시 로얄을 함께 플레이하기도 한다. PC게임인 경우에는 저녁에 함께 피씨방에 가는데, 재미있는 점은 원래 저녁을 먹고 피씨방에 가다가, 피씨방에 가서 저녁을 먹는 걸로 바뀌었다는 점이다. 저녁먹는 시간이 아까워서다. 이렇게 피씨방에서 플레이한 게임들은 스타1, 스타2, 카운터 스트라이크 온라인2, 오버워치, 히어로즈 오브 스톰 등이 있다.처음 게임 동호회에 들어올 때만 해도 ‘같은 회사 사람끼리 게임을 하는 것이 과연 재미있을까'란 생각을 했다. 그런데 막상 게임을 같이 해보니, 회사에서 일할 때는 보이지 않았던 그 사람의 의외의 면을 발견하는 재미도 있는 것 같다. 개인적으로는 초등학교 때부터 게임을 워낙 많이 했던 탓에 스스로 ‘내 인생을 게임에 너무 낭비한 것이 아닐까'란 자괴감을 느낀적도 있는데, 다른 훌륭한 개발자의 게임 덕후스러운 면모를 보면서 ‘나만 이렇게 게임에 빠진 것은 아니었구나'하는 위안도 받을 수 있었다.사진3. 스켈터랩스의 게임동호회 Game of Troll의 뒷풀이 모습Q. 와우, 플레이하는 게임이 정말 많다. 단희님이 가장 좋아하는 게임을 그 중 꼽는다면?A. 나는 단연 오버워치다. FPS게임을 선호하는 편인데 그 중에서도 오버워치를 주로 플레이한다. 개인적으로 스토리가 재미있기도 하고, 팀플레이를 진행하며 합을 맞춰가는 맛이 있다. 무엇보다 사람끼리 대결하는 PVP로 진행을 하면 정말 짜릿함이나 즐거움이 배가 되는 것 같다. 물론 협동 게임인 만큼 팀플레이가 제대로 되지 않는다거나 비매너 유저들과 붙을 때는 기분이 아주 다운되는 경우도 있지만 말이다. 그럴 때는 ‘GTA5’ 또는 최근에 시작한 ‘데스티니 가디언즈'에서 PVE를 하며 마음을 진정시킨다. 물론 이것만 하면 지루하겠지만 오버워치와 적절히 번갈아가면서 하다보면 고유의 재미가 느껴진다.Q. SNS에 웹툰도 연재하고 있는 것으로 알고있다. 어떻게 웹툰 연재를 시작하게 되었는지.A. 어렸을 때부터 만화 그리는 것을 좋아했다. 내가 상상하는 이야기들을 만화로 풀어내는 것도, 그 날 있었던 일을 재미있게 연출해서 일기 대신 그림으로 하루의 기록을 남기는 것도 좋아했다. 그렇게 학교에서 있었던 재미있는 에피소드를 글과 그림으로 남기다 보니, 이걸 모두에게 공개하면 재미있지 않을까란 생각을 했다. 때마침 한창 페이스북 페이지가 유행이었는데, 그때부터 노트에 끄적거린 짧은 만화들을 올리기 시작하면서 현재의 인스타그램 웹툰까지 오게되었다.   사진3. 단희 님이 연재 중인 <초코롤의 코딩일기>, 인스타그램과 페이스북에서 만나볼 수 있다Q. 웹툰 소개를 부탁한다.A. 인스타그램에선 @sw_chocoroll, 페이스북에서는 <초코롤의 코딩일기>라는 제목으로 게재하고 있다. 취미생활 겸 하다 보니 정기연재는 아니다. 제목에서 드러나 듯 주로 코딩(개발) 이야기를 다루고 있는 생활툰이다. 생활툰의 특성상 어쩔 수 없이 주변인들에 대한 묘사가 많고, 에피소드가 없을 때면 웹툰을 그리기도 쉽지 않다. 약간 과장하더라도 실제 있었던 일들을 중심으로 작업하기 때문에, 업로드 전 꼭 등장 인물들에게 검수를 거치기도 한다. 웹툰 그리는 것이 생각보다 집중도를 요하는 작업인지라 보통 주말에 진행하는데, 그래서 평일에는 에피소드를 꼼꼼히 기록해두는 습관이 생겼다. 무엇보다 웹툰을 그리며 가장 많이 느꼈던 점은 내 인생에 대해서 조금 더 알게됐달까, ‘나’를 다시 보게 된 느낌이 있다. 내가 기록한 에피소드가 대부분 게임과 개발에 편중되어 있는 점을 보면서, 인생에서 많은 지분을 ‘게임', ‘개발' 이 두 가지에 할애하고 있다는 것을 새삼 알게되었다.  Q. 재능 부자, N잡러로 보인다. 게임에도 웹툰에도 이렇게 관심이 많았는데 어떻게 개발자의 진로를 선택하게 되었나.A. 이유는 생각보다 단순하다. 위에 웹툰에서도 그렸듯이 영화를 보면 꼭 대형 모니터를 여러 개 띄워놓고 멋지게 주인공을 돕는 해커들이 등장하지 않나. 게임을 많이 하게 되면서 자연스럽게 컴퓨터에 친숙해지기도 했고, 영화를 보면서 ‘나도 컴퓨터 관련 전공을 택하면 저렇게 멋있는 사람이 될 수 있지 않을까’라고 생각했던 것 같다. 다만 어떤 분야의 개발자가 될 것인가에 대한 고민은 많았다. 영화처럼 정보보안 쪽도 잠깐 발을 담갔지만 지금 당장 할 수 있는 분야는 아니라는 생각을 했고, 그 다음은 게임 개발자에 관심을 가졌다. 그런데 당장 게임 회사에 들어간다고 해도 꼭 내가 만들고 싶은 게임만 만들 수는 없다는 것을 알게 되서 보류했다. 나는 일단 스토리가 탄탄하고 재미있는 게임을 정말 사랑한다. 예를 들어 <화이트데이>라는 공포 게임을 정말 재밌게 플레이했었는데, 공포 요소도 한국 정서에 맞게 잘 구현되었으면서 미연시(미소녀 연애 시뮬레이션) 요소도 가미되어 신선한 느낌을 주었었다. 제일 중요한 스토리도 배경 시나리오부터 인게임 진행까지 반전에 반전을 거듭하며 게임이 끝나고도 생각해볼 여지가 많았다. 이런 게임을 만들고 싶지만 우선 희망 사항으로 남겨둔 상태이다. 그러다 우연히 입사한 스켈터랩스에서 훌륭한 선배 개발자들을 보며 ‘개발' 자체의 즐거움을 느꼈고 당장은 어떤 특정 분야에 국한하지 않고 순수한 개발 능력을 향상시키기 위해 노력하고 있다. 스켈터랩스에서 중요하게 다루는 인공지능은 특히 기술적으로 미래의 변화를 주도하고 있기에, 여러 방면에서 매우 배울 점도 많고 발전할 수 있는 것 같다.Q. 최근 몰두하고 있는 것이 있다면?A. 여전히 웹툰과 게임이다. 웹툰을 그릴 수록 기초적인 그림 실력이 부족하다는 것을 많이 느꼈다. 전문적으로 그림을 배워볼까 싶다. 그리고 유튜브에 게임 채널을 열어보려고 한다. 내가 관심있었던 모든 일은 기본적으로 ‘창작'과 ‘기록'의 맥락을 가지고 있다. 개발 또한 어떻게 보면 내가 짜는 코드를 통해 하나의 프로그램을 만들어 내는 역할이지 않나. 웹툰도 내 일상에 대한 기록이다. 나의 일상에서 가장 큰 관심사 중 하나인 게임을 기록하는 방법에 대해 고민했는데, 역시 동영상이 최고라는 결론에 도달했다. 유튜브에는 게임 영상을 편집하여 조금씩 선보이고 있다.Q. 진부할 수 있지만, 이 인터뷰의 마지막 질문이다. 개인적인 꿈을 얘기해줄 수 있나.A. 언젠가는 접어두었던 게임 개발자의 꿈을 꾸려고 한다. 1인 개발자로서 스토리와 작화, 개발을 모두 맡은 개발자 말이다. 그러기 위해서는 그림 뿐만 아니라, 유저의 마음을 사로잡을 수 있는 스토리와 촘촘한 개발력 또한 갖추어야 한다. 개발력은 일단 스켈터랩스에서 빵빵하게 키워놓고, 스토리와 작화에 관련된 역량을 조금씩 갖추어간다면 1인 개발자로서 내 이름을 건 게임을 출시할 날이 조만간 올 수 있지 않을까.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #팀원인터뷰 #팀원소개 #팀원자랑
조회수 3603

jekyll을 이용한 Github 블로그 만들기

Overview“githubPage로 기술 블로그를 만들자!” “jekyll로 만들면 한두 시간이면 가능할 거야!” 지난 1월, 브랜디 기술 블로그 제작 작업을 시작했습니다. 다양한 삽질과 험난한 여정의 결과물인 기술 블로그의 제작 및 커스터마이징 과정을 소개하겠습니다.GithubPage는 Github에서 공식적으로 운영하는 블로그 서비스입니다. 이곳엔 개발자들의 경험이나, 코드가 업로드되어 있습니다. 저장 공간도 무료로 제공되고, 도메인 연결도 편리하게 할 수 있지만, 무엇보다 GithubPage 혹은 GithubIO라고 하면 개발자 스멜이 풀풀 나기 때문에 선택의 이유가 되는거 같습니다.GitgubPage 제작 프로그램은 jekyll, HEXO가 가장 많이 쓰입니다. 브랜디의 기술 블로그는 템플릿의 종류도 많고, 더 어울리는 jekyll을 선택했습니다. jekyll 공식 사이트는 여기를 클릭하세요. 한국어도 지원하니 아주 멋집니다. 변역된 문서가 2015년 11월 23일 문서인 게 함정이지만 기능의 거의 유사하기 때문에 문제될 것은 없습니다. 1. 준비물을 챙기자!$ gem install jekyll $ jekyll new my-awesome-site $ cd my-awesome-site /my-awesome-site $ jekyll serve ▲ jekyll 설치 스크립트이제 브라우저로 http://localhost:4000 에 접속합니다.메인에 내거는 것처럼 설치와 실행이 쉽지만 몇 초 만에 되진 않습니다. 설치가 몇 분 정도 걸리고 ruby나 bundler같은 선행 조건이 갖춰져야 하기 때문입니다.ruby는 있는데 bundler가 없다면 아래와 같이 설치하면 됩니다.gem install bundler 설치가 잘 되고, 사이트 생성 후 실행을 했다면 브라우저와 함께 기본 페이지가 뜹니다. 설치가 성공했다!2. 1차 멘붕, 이제 무엇을?설치는 제법 쉽게 했지만 ‘이제 무엇을 해야 하나’ 막막하기만 합니다. 블로그 작성에 대한 아무런 가이드도 없고, 페이지나 이미지 추가 확인 등의 작업을 커멘드로만 하려니 힘들고 아찔하기만 합니다.커멘드 지옥..jekyll admin을 검색했더니 이런저런 아이들이 나옵니다. 그중에 jekyll 공식 플로그인을 선택했습니다. jekyll-admin 공식 사이트 이미지그런데 사이트 메뉴얼만 보고 설치하기 쉽지 않습니다. 이제 막 jekyll 띄웠을 뿐인데 플로그인은 어떻게 추가하는지 알 길이 없습니다. 이런저런 삽질을 거듭하고 안 되는 영어를 해석하다 보니 얼떨결에 성공했습니다.추가한 프로젝트 root에 보시면 Gemfile이 존재합니다.아마도 사이트 제너레이트 시 실행되는 스크립트인 것 같습니다. 파일을 열고 아래와 같이 추가합니다.# 아래와 같이 한줄 추가해주세요 gem 'jekyll-admin', group: :jekyll_plugins 프로젝트 root로 이동해 설치를 요청합시다.bundle install 달라진 게 없어 보여도 http://localhost:4000/admin 으로 접속하니 아뉫! 관리자가 설치되었습니다. 이제 한시름 놓입니다.3. 마크다운, 넌 누구?마크다운을 잘 안다면 넘어가도 됩니다.관리자를 설치하고 나면 그나마 좀 할만하지만 막상 글을 쓰려고 보니 무언가 다릅니다. HTML이나 위지윅 에디터도 아니고 Textarea만 덩그러니 있기 때문입니다....마크다운은 위키나 Github페이지 설명 작성 등에 쓰이는 언어입니다.1) HTML을 어느정도 한다면 문법만 읽어도 금방 이해할 수 있습니다. 생각보다 어렵지 않아서 간단한 문서 작성은 수월하게 가능합니다. 무엇보다 코드를 붙여넣을 때 아주 좋습니다. ``` PHP 코드 내용 ```위의 그림처럼 작성하면 자동적으로 신텍스 하이트라이트가 적용되니 개발 코드를 전달하기 편리합니다.4. Posts? Pages? Static Files? Data Files?확실히 jekyll은 그동안 봤던 블로그나 워드프레스 등 유명한 블로그와는 많이 다릅니다. 일단 개념부터 짚어보겠습니다. PostsPost는 한 개의 글을 지칭합니다. 블로그의 글 하나입니다. 어느 정도 구축이 되면 Post에서 글만 작성해도 쉽게 운영할 수 있습니다.PagesPost처럼 계속 추가되는 형태가 아닌 고정 페이지를 작성할 때 씁니다. About이나, 채용, 회사소개 등 Post와 분리가 필요한 글을 작성할 때 유용합니다.Static Files정적 리소스를 올리는 기능입니다. 생각보다 버그가 많아서 사용하기 쉽지 않습니다. 저는 이 기능을 커스터마이징해서 약간 쓰기 쉽게 바꾸었지만 쉽지는 않았습니다. 자세한 관리자 커스터마이징은 나중에 다루겠습니다.Data Files정적 데이터를 다루는 기능입니다. 저자 관리나 공통 변수를 담아두면 편리하게 쓸 수 있는 기능입니다. 역시나 버그가 넘쳐납니다. 당분간은 그냥 파일을 직접 수정하는 게 나을 겁니다.5. 블로그 제목 등 설정을 바꾸고 싶다면관리자의 configuration 메뉴를 이용하거나, 프로젝트 루트에서 _config.yml 을 열고 수정해도 됩니다. 사이트에서 사용할 전역 변수나, 플로그인, 기본값 등을 관리해주기 때문에 자주 수정하는 파일입니다. 제목을 변경하려면 title을 찾아서 변경하면 됩니다. 그외의 하단 문구는 buttomtitle을 변경하면 됩니다. 아래 보이는 각종 정보들은 맞게 수정하면 되고, social: 밑에 있는 정보들은 나중에 페이스북 공유나, 트위터 공유 등으로 사용할 수 있습니다. 해당 정보가 없거나 공유를 원치 않는다면 share를 false로 변경합니다. _config.yml은 수정 후 재시작을 해야만 반영되므로 jekyll를 다시 실행하면 됩니다.6. 테마를 적용하자테마 기능은 jekyll를 선택한 가장 중요한 이유였습니다. 멋진 디자인과 추가로 구현된 특수한 기능들은 jekyll이 가지고 있는 큰 메리트입니다. 테마를 사용하려면 소스를 다운로드 받고 압축을 해제해 사용하거나 git checkout 하면 됩니다. 해당 폴더로 이동해 실행하면 테마를 쉽게 사용할 수 있습니다.jekyll serve jekyll은 테마가 완성된 프로젝트 개념이기 때문에 바로 사용이 가능하지만 마이그레이션 이슈가 있습니다. 마이그레이션은 _post의 있는 파일과 _page에 있는 파일을 그저 테마 프로젝트 폴더에 덮어쓰기하면 됩니다.아쉽게도 _config.yml파일은 다시 세팅하는 게 빠릅니다. 어드민 설정 부분도 다시 하면 됩니다. 테마마다 약간씩 기능이 달라 마이그레이션이 안 되는 경우도 있으니 테마는 초기에 선택하는 게 좋습니다. 브랜디 랩스는 Centrarium 테마를 적용했습니다.테마가 적용된 화면7. 글에 이미지를 어떻게 넣을까?글을 쓰면 참고자료로 쓸 이미지도 필요합니다. static file에 업로드 기능이 있지만 업로드를 하면 프로젝트 루트 폴더에 업로드되어 관리상 좋지 않습니다. 앞서 공유한 것처럼 해당 기능 개선에 대해서는 다루지 않을 것이기 때문에 수기로 이미지를 관리하는 방법을 소개하겠습니다.로컬 프로젝트 기준에서 _site는 제너레이트된 최종결과라고 할 수 있습니다. 그래서 _site 폴더에 assets와 같은 폴더가 있으나 그 폴더에 올리면 덮어쓰기와 동시에 초기화 되므로 반드시 프로젝트 루트의 assets에 파일을 올려주시면 됩니다. 폴더를 생성하는 것도 문제 없으므로 포스팅마다 이미지를 나누길 권장합니다. 이미지가 폴더에 복사가 되었다면 이제 글에 넣어봅시다.마크다운 위지윅을 이용해도 좋고 이미지 부분을 HTML코드롤 사용해도 좋습니다. 마크다운으로 이미지를 추가할려면 아래처럼 사용하면 됩니다. ![이내용은 alt속성으로 치환됨](/assest/20180118/test.jpg "이 내용은 타이틀로 치환 됨") assets/test.jpg적용된 이미지이미지의 사이즈나 정렬을 변경하는 건 다음에 다루겠습니다.8. Gnav 변경은 어떻게 할까?커스터마이징한 Gnav영역테마도 적용했고, 글도 쓸 수 있지만 안 쓰는 기능 삭제를 비롯해 손볼 곳은 아직 많습니다. (분명 한두 시간이면 된다고 했던 일이 2주째 수정 중입니다…) 화면 구성을 고치려면 프로젝트에 포함되어 있는 템플릿 파일을 고쳐야 합니다.템플릿은 Liquid 라는 언어로 구성되어 있으며, 문법이 좀 난해하지만 충분히 헤쳐 나갈 수 있습니다. 다만 어디서부터 어떻게 고쳐야 하는지를 파악하는 게 어렵죠. 문법은 공식 사이트를 참고하고, 사용 가능한 변수는 여기를 참고하면 됩니다.사용 가능한 변수는 site와 page로 나눌 수 있습니다. site는 _config.yml 설정한 내용과 jekyll이 지원하는 전역 변수들입니다. page는 해당 페이지에 지정된 세부 변수들입니다. 글의 제목이나 경로 내용들은 기본적으로 세팅되어 있습니다. 추가적인 값을 다루려면 post를 작성하면서 meta정보를 추가하면 됩니다.템플릿의 시작파일은 index.html이고, 페이지에 layout이 지정되었다면 _layouts 안에 있는 [layout].html이 됩니다. 기본적 틀은 _layout/default.html에서 파생됩니다. 그외 파츠로 사용되는 HTML파일은 _includes에 넣고 `{% include header.html %} 같은 방식으로 추가하면 됩니다. 우리 변경하려는 파츠는 header.html에 있습니다. site.pages에는 모든 페이지가 들어있기 때문에 그중에 gnav가 지정된 글만 상단에 노출되게 했습니다. 그리고 상단 글에 대한 정렬이 없기 때문에 좋은 방식은 아니지만 1~10까지 숫자를 기입하면 순서대로 나오게 코드를 구성했습니다. (site.pages에는 posts와 pages가 같이 나옵니다.){% for i in (1..10) %}   {% for page in site.pages %}     {% if page.title and page.gnav == i %}     {{ page.title }}     {% endif %}   {% endfor %}  {% endfor %} 글에 옵션을 지정한 화면이제 pages에서 상단에 노출하고 싶은 글만 gnav를 숫자로 부여해 노출할 수 있게 변경했습니다.9. 스타일 변경은 어떻게 할까?sass로 구성된 스타일의 변경은 심도있게 다루지 않으려고 합니다. sass를 처음 사용한 것도 있지만 내용이 너무 깊어지기 때문입니다. 스타일변경은 _sass 밑에있는 scss 파일을 변경하면 되고, 템플릿마다 구조가 다르기 때문에 열심히 찾는 수밖에 없습니다.10. 저자 기능을 추가해보자 (1)최고의 난이도를 자랑하는 신규 기능 추가입니다. 브랜디의 기술 블로그에서는 작성자를 클릭하면 작성자의 글만 따로 모아서 볼 수있습니다. 하지만 이 기능은 공식적으로 지원되는 것이 아니기 때문에 처음부터 만들어야 했습니다. 완성된 작성자 기능위의 이미지와 같은 기능을 구축하려고 collection을 사용했습니다. collection은 posts나 pages와 같이 그룹핑된 글 목록을 이야기 합니다. posts나 pages는 기본 세팅되어 있고, 약간(?)의 설정 변경으로 collection을 추가할 수 있습니다. 작성자의 메인 페이지가 필요하니 authors라는 collection을 추가해보겠습니다.# _config.yml collections:   authors:     title: Authors     output: true jekyll을 재시작하면 아래와 같이 Authors가 관리자에 추가된 것을 볼 수 있습니다.authors는 작성자 메인 페이지만 생성하면 되므로, 내용에는 작성자에 대한 소개글만 간략히 쓰면 됩니다. jekyll admin에 한글 버그가 있기 때문에 우선 영어로 작성하고, 제목을 다시 한글로 수정하면 됩니다.포스팅마다 저자의 정보가 공통적으로 나와야 하기 때문애 위의 전역변수에 authors를 추가해 따로 관리하게 했습니다.# data/authors.yml # authors 공용 변수   - name: chunbs     koname: 천보성 팀장     email: [email protected]     position: R&D 개발2팀     img: /assets/profile/chunbs.jpg   - name: kangww     koname: 강원우 과장     email: [email protected]     position: R&D 개발2팀     img: /assets/profile/kangww.jpg 그리고 작성자의 포스팅을 엮어주려고 작성자의 아이디가 같을 때, 포스팅으로 나오게 구성합니다.{% if post.author %} {% for author in site.data.authors %}   {% if post.author == author.name %}   {{author.koname}}   {% endif %}  {% endfor %}  {% endif %} 11. 저자 기능을 추가해보자 (2)데이터가 준비되었다면 저자 레이아웃을 추가해야 합니다.(이거 도대체 언제 끝날까요) 저자가 작성한 글만 노출되어야 하는 게 어려울 수도 있지만 jekyll의 구동 원리를 이해하면 손쉽게 할 수 있습니다.jekyll은 내용 수정이 발생되면 전체를 다시 컴파일하는 구조입니다. 다시 말해 일부 파일이 변경되면 노출되는 모든 html파일을 다시 랜더링해서 write하는 것입니다. author의 각 작성자 페이지는 컬렉션에 포함되어 있기 때문에 랜더링이 발생하고 site.posts엔 작성된 모든 페이지 정보가 있습니다. site.posts를 foreach를 돌리고, 저자가 일치하는 페이지만 리스트로 보여줍시다.{% for post in site.posts %} <!-- author 정보가 저자와 같은 경우만 리스트로 출력한다. --> {% if post.author == page.author %}       {{ post.title }}         {{ post.content | strip_html | truncatewords: 25 }}         {{ post.date | date: "%Y-%m-%d" }}           {% if post.author %}         {% for author in site.data.authors %}           {% if post.author == author.name %}           {{author.koname}}           {% endif %}         {% endfor %}       {% endif %}       {% if forloop.last == false %} {% endif %}   {% endif %} {% endfor %} Conclusionjekyll admin은 은근히 버그가 많습니다. 그래도 ‘md파일을 메모장으로 작성하세요’라고 하는 것보단 편하죠. 다양한 기술을 사용하기 때문에 어려울 수도 있겠습니다. 글에서 소개할 수 없거나, 너무 깊어지는 내용은 소개에서 제외했습니다. 양해를 부탁드립니다. 대신에 브랜디 랩스는 저의 피땀 눈물로 만들어졌다는 걸 기억해주세요… 기타jekyll의 기본값 설정을 이용하면 layout과 같은 공통적인 부분을 쉽게 설정할 수 있다.# _config.yml defaults:  - scope:     path: ''     type: posts   values:     #permalink: "/blog/:title/"     layout: post     cover: /assets/default.jpg     author:  - scope:     path: ''     type: authors   values:     layout: author     cover: /assets/author.jpg     subtitle: ~담당하고 있습니다.     author: 영문이름 jekyll admin이 버그가 많아서 업로드 기능은 커스터마이징 했다. 루비와 UI코드를 고쳐서 다시 빌드하는 어지러운 작업을 했다.만약 버그를 고치기 어렵다면 IDE로 파일을 직접 수정하는 게 안전하다. 참고 1)마크다운 작성법은 여기를 참고하세요.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 3550

개발자, 디자이너, 기획자의 온도차

 아마 가장 많은 분들이 생각하시기에 가장 걱정되는 부분이라고 생각이 듭니다.그래서 저 역시도 이 이야기를 하는 것에 좀 조심스럽습니다. 이야기는 바로 "업무를 대하는 개발자, 기획자, 디자이너 간의   온도차."입니다. (다시 한번 말씀드려요! 제가 사용한 방법이 백프로 모두에게 맞는 말은 아닙니다!!) 스타트업은 큰 기업처럼 디자인팀, 개발팀, 기획팀이 갈려서 서로의 팀장에게 허가를 받고, 기획을 시작하고, 개발을 시작하고, 디자인하는 그런 상하관계의 구조가 아닙니다. 서로서로들 비슷한 경력들과 환경에서 서비스를 제작하는 사람들이 많죠. 특히, 젊은 스타트업 기업들은 대학생들이나 대학원생 등 아직 본격적인 사회생활을 해보지 않은 인원들이 더 많을 것으로 알고 있습니다. 아시다시피, 다들 맞춰진 직무를 기반으로 개발자는 개발자의 생각과 계산에 따라서 일을 진행하고 있고, 기획자는 기한에 맞춰 예상했던 진행대로 일을 진행하고 싶어 하고, 디자이너들은 보다 다은 디자인으로 서비스를 보이려 다양한 자료들을 모으고 분석하여 제작자의 아이디어를 입혀 새로운 콘텐츠를 제작하려 노력합니다.문제는 서로가 서로의 일에 대하여 모른다는 것입니다. 스타트업의 팀원들 간의 커뮤니케이션은 마치 연애와 같아서 서로 이야기해주지 않으면 모를 수밖에 없고, 서로 어떻게 일을 하는지, 얼마나 시간이 걸릴 것이다 등 일정에 대한 공유나, 업무를 하는 절차를 이야기 해주짖 않으면, 원치 않는 감정의 골이 생기기 마련입니다. 이런 문제를 해결하기 위해, 기업은 매일매일 아침시간에 진행하는 Scrum이라든지, Jira, Taskworld, Trello 등 다양한 프로젝트 매니지먼트 툴을 사용하고, 스크럼 마스터나, 다양한 서비스를 제작해 보신 PM(Project Manager), 또는 PO(Product Owner)님들이 각부서의 현황들을 파악하고, 다양한 부서를 총괄하고 관리합니다.그러나, 기본적으로 국내 스타트업 상황은업무자들의 수가 절대적으로 부족하고,젊은 개발자나 디자이너 같은 경우는 생업(또는 학업)과 스타트업을 동시에 하는 인원이 많고,젊은 창업자들과 직원들의 경우, 프로젝트 경험이 없어 이러한 분업구조를  낯설어하고,개발자와 디자이너 역시 자신이 작업하는 프로젝트가 언제쯤 끝날지 가늠할 수 없는 상황이 생기고,적은 인원들이 많은 프로젝트를  진행하느라 예민한 구조가 되어 남을 이해하기 힘든 상황등의 다양한 이유들 때문에 각 직군 간의 갈등 상황이 큰 기업에 대비하여 많이 생기고 있습니다(물론 큰 기업도 문제가 없진 않다고 합니다.).이 전설의 짤을 보신적이 있으신 분들도 많으실듯... (출처: http://9gag.com/) 이러한 갈등 해결 방안은 다음에 더  디테일하게 설명드리도록 하고, 이번 글에서는 간단히 저가 생각하는 발전방향에 대하여  이야기해보도록 하겠습니다. 앞서 말씀드린 것과 같이, 스타트업 팀원들의 관계는 마치 연예와 비슷하다고 생각합니다. 말하지 않으면 모를 수밖에 없는 노릇이고, 말을 해줘도 이해할 수 없는 일들이 수두룩 합니다(그런 이유로 저는, 스타트업에서 근무하시는 분들은 서로의 업무에 대하여 어느 정도의 배경지식을 배우는 게 필요하다고 생각합니다.). 그럼에도 불구하고 우리는 항상 이야기를 해야 해요. 연애를 할 때도 말이 안 통해도 될 때까지 이야기하듯이. 스타트업에서의 업무는 끊임없이 피보팅을 진행하고, 하루하루 떠오르는 처리해야 할 일들이 생깁니다. 그리고, 그러한 변경사항들에 관하여  이야기할 때, 서로가 서로의 말을 이해해 주지 못한다면, 더 큰 갈등 상황들을 야기하기 마련이지요. 그러나, 만약 각 직군의 전문가들이 서로의 업무에 대한 배경이나, 아주 기본적이더라도 기초사항을 알고 있다면, 서로의 업무량에 대한 불만이 아무래도 적을  수밖에 없다고 생각합니다. 제가 스타트업을 진행할 당시를 말씀드리자면, 저는 창업 당시 기획자로서 서비스를 기획하고, 프로젝트를 관리하고, 투자 또는 공모전 등에 쓰일 기획서 등을 제작하는 업무를 주로 하였습니다. 디자인에 관하여는 무엇을 논할 수 있는 실력도 아니고, 개발에 관하여는 더더욱 그렇습니다. 그러므로 기획서를 작성할 때나, 어떤 계획을 할 때 “원하는 시간”을 개발자나 디자이너에게 요청하고, 그러한 요청 사안과 당사자들과의 이야기를 통해 조정하고 계획을 진행하는 것이 주  업무였습니다. 그리고 나름 생각하기에는 "개발이나 디자인을 하나도 모르는 사람이 일의 진행 정도를 스스로 보고 판단하고, 기한을 준다는 것은 올바르지 않다."라고 생각하여 아주 기초적일 수 있지만 웹 공부와 포토샵 일러스트 디자인 등의 디자인과 개발 툴 공부를 꾸준히 하면서 개발과 기획에서 어느 정도  서포트할 수 있는 실력을 기르기 위해 많은 시간을 투자했었습니다. 그리고 이러한 노력 덕분에 서로의 직군과 업무에 대한 고충을 이해할 수 있어서 많은 이점을 가질 수 있었지만, 그럼에도 불구하고, 자주자주 일이 딜레이 되는 상황이 발생하였고, 그러함에 따라서 개발자와 디자이너와 기획자들이 조금씩 소원해지고  섭섭해지는 상황이 발생하였던 것 같습니다. 그래서 하나 더 생각했던 것이, "일을 처음 시작하는 초보들에게도 바로 적용해서 업무에 도입할 수 없는 어려운 프로젝트 매니지먼트 툴이 아닌 서로의 작업현황이나, 상태 정도를 가늠할 수 있는 PM 툴을 만들어 보자." 하는 것이었습니다. 그래서 창업 당시 사용한 아주 간단한 툴이 있는데, 이 프로젝트 메니지 방법은 내일 이미지로 보여드리면서 설명드릴게요. :) 그리고 지금은 Taskworld나 Jira 같은 더 전문적인 툴을 사용하고 있지만, 해당 툴에 대한 전문전 지식이 아직 없는 분들은 엑셀 등으로 서로의 일을 정리해서 공유하는 것도 좋을 것 같네요! 기회가 되면, 요즘은 제가 어떤 식으로 툴을 사용하는지 설명하는 글도 적도록 하겠습니다! 마지막으로 긴 글을 세줄 정리하자면, 1. 개발자, 기획자, 디자이너는 달라요. x나 달라요.... 2. 다르면 잘 들어보고 뭘 하는지 아는 것이 중요하다고 생각합니다. 3. 그리고 서로가 어떤 일을 하고 있는지 현황을 파악할 수 있다면 더 좋겠죠?오늘도 읽어주셔서 감사합니다! 좋은 하루들 되세요:)#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트
조회수 1621

공용 계정용 OTP 관리방법

제대로 된 기업용 서비스라면 의례 다중 계정과 권한 제어 기능을 함께 제공하기 마련이다. 그래서 공용 계정을 굳이 만들 이유가 하나도 없다. 하지만 일부 서비스(그리고 대부분의 한국의 기업 서비스)는 단일 계정만 지원하는데다 AWS 같은 서비스도 root 계정이 따로 있어서 계정 관리 이슈가 불거지기 마련이다. 계정 아이디와 암호의 경우는 LastPass 같은 기업용 계정 관리 서비스를 사용하거나 팀 공용 계정 비밀번호 관리하기에서 소개된 방식과 같이 약간은 불편하지만 비용이 들지 않는 수단을 도입하여 관리하면 된다. 그런데 MFA 또는 2FA(2-Step Verification)라고도 부르는 OTP로 계정을 보호할 때는 OTP 정보를 공유하기가 쉽지 않다. 일반적으로 MFA 계정은 Google Authenticator 같은 앱을 설치해 관리한다. OTP 정보와 계정 암호를 한 계정에서 관리하지 않아야 한쪽이 노출되어도 보안을 유지할 수 있기 때문이다. 문제는 Google Authenticator와 Authy 같은 도구를 특정 휴대폰에 설치하면 여러 사람이 OTP 정보를 공유하기 힘들다는 것이다. 그래서 몇가지 솔루션을 찾아보았는데 “이거다!” 싶은 건 없어도 gauth라는 명령줄 기반 도구에 안착하게 되었다.gauth.csv라는 파일에 OTP 정보를 아래와 같이 입력하고AWS: ABCDEFGHIJKLMNOPQRSTUVWXYZ234567ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 Airbnb:abcd efgh ijkl mnop Google:a2b3c4d5e6f7g8h9 Github:234567qrstuvwxyzgauth를 실행하면 아래와 같이 OTP 토큰을 확인할 수 있다.$ gauth prev curr next AWS 315306 135387 483601 Airbnb 563728 339206 904549 Google 453564 477615 356846 Github 911264 548790 784099 [======= ]이제 gauth.csv 파일만 라스트패스 등으로 제한된 사용자에게 안전하게 공유하면 된다.개선 사항DailyHotel/gauth는 pcarrier/gauth를 개선한 tuxmartin/gauth를 Docker 이미지로 감쌌다. 그래서 Golang 개발환경을 갖추고 소스코드를 빌드하지 않아도 바로 사용할 수 있다. 자세한 사용법은 README 문서에 적어두었다.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #꿀팁
조회수 22493

Next.js 튜토리얼 9편: 배포하기

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기 2편: 페이지 이동 3편: 공유 컴포넌트4편: 동적 페이지5편: 라우트 마스킹6편: 서버 사이드7편: 데이터 가져오기8편: 컴포넌트 스타일링9편: 배포하기 - 현재 글개요아래와 같은 궁금증이 생긴 적이 있나요?어떻게 내가 만든 Next.js 애플리케이션을 배포할 수 있나요?아직 배포에 대해 이야기하지 않았지만 배포하는 것은 꽤 간단하고 직관적입니다.Node.js를 동작할 수 있는 곳이라면 어디든 Next.js 애플리케이션을 배포할 수 있습니다. 매우 간단한 ▲ZEIT now로 배포하는 데에도 불구하고 어떤 잠금 장치도 없습니다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.Build와 Start처음으로 프로덕션에 우리의 Next.js 애플리케이션을 빌드해야 합니다. 빌드는 최적화된 프로덕션의 코드 세트를 생산합니다.이를 위해 간단히 다음의 npm 스크립트를 추가하세요:그런 다음 하나의 포트에서 Next.js를 시작해야 합니다. 사이드 렌더링을 수행하고 페이지를 제공합니다. (위의 명령으로 빌드됩니다)이를 위해 다음의 npm 스크립트를 추가하세요:이러면 3000 포트에서 우리의 애플리케이션이 시작됩니다.이제 프로덕션에서 애플리케이션을 동작시키 위해 다음의 명령어를 실행할 수 있습니다:두 개의 인스턴스 실행하기애플리케이션의 인스턴스 두 개를 실행시켜 봅시다. 대부분 앱을 수평으로 확장하기 위해 이 작업을 수행합니다. 처음으로 start npm 스크립트를 다음과 같이 변경해봅시다:만약 Winodws라면 next start -p %PORT%로 스크립트를 변경해야 합니다.이제 애플리케이션을 처음으로 빌드해봅시다.npm run build그러면 터미널에서 다음의 명령어로 실행시켜 봅시다:PORT=8000 npm startPORT=9000 npm startWinodws에서는 다른 명령어를 실행시켜야 합니다. 하나의 옵션은 애플리케이션에 cross-env npm 모듈을 설치하는 것입니다.그런 다음 커맨드 라인에서 cross-env PORT=9000 npm start를 동작시켜 주세요.두 개의 포트 모두에서 애플리케이션에 접근할 수 있나요?- 네. http://localhost:8000와 http://localhost:9000 둘 다 접근할 수 있습니다.- http://localhost:8000에서만 접근 가능합니다.- http://localhost:9000에서만 접근 가능합니다.- 둘 다 접근할 수 없습니다.한 번의 빌드로 많은 인스턴스 실행시키기보다시피 애플리케이션을 한 번 빌드해야 합니다. 그런 다음 원하는만큼의 많은 포트들을 시작할 수 있습니다.▲ZEIT now에 배포하기Next.js 애플리케이션을 빌드하고 시작하는 방법을 배웠습니다. npm 스크립트를 사용하여 모든 것을 수행했습니다. 그래서 원하는 배포 서비스를 사용해서 동작하도록 애플리케이션을 설정할 수 있습니다.하지만 ▲ZEIT now를 사용하면 딱 한 번의 과정만 수행하면 됩니다.다음과 같은 npm 스크립트만 추가해주세요:그런 다음 now를 설치해주세요. 설치 후 다음 명령어를 적용해주세요:now기본적으로 애플리케이션의 루트 디렉터리 안에서 "now" 명령어를 실행합니다.여기에서 애플리케이션을 시작하는 포트로 8000 포트를 지정했지만 ZEIT now에 배포할 때 변경하지 않았습니다.그러면 ZEIT now에 배포할 때 애플리케이션에 접근할 수 있는 포트는 어떤 것일까요?- 8000- 443 (혹은 언급되는 포트가 없음)- URL에 언급한 모든 포트- 에러를 표시한다. "443 포트에서만 시작할 수 있습니다"ZEIT는 항상 443 포트를 사용합니다실제로 8000 포트에서 애플리케이션을 시작해도 now에 배포될 때는 443 포트를 사용해서 접근할 수 있습니다. ("https" 웹사이트의 기본 포트)이것은 ▲ZEIT now의 특징입니다. 원하는 포트에서 애플리케이션을 시작해야 합니다. ▲ZEIT now는 항상 443 포트로 매핑합니다.로컬에서 애플리케이션 빌드하기▲ZEIT now는 npm build 스크립트를 발견하고 빌드 인프라 내부에 빌드합니다.하지만 모든 호스팅 제공자가 이와 같은 것을 가지고 있지는 않습니다.이 경우 로컬에서 다음의 명령어를 사용해서 빌드할 수 있습니다:npm run build그런 다음 .next 디렉터리를 사용하여 애플리케이션을 배포하세요.커스텀 서버를 사용하여 애플리케이션 배포하기우리가 막 배포한 애플리케이션은 커스텀 서버 코드를 사용하지 않았습니다. 하지만 만약 사용한 경우에는 어떻게 배포할 수 있을까요?다음의 브랜치로 체크아웃하세요:커스텀 서버를 사용하여 애플리케이션을 실행하기 위해 애플리케이션에 Express를 추가해주세요:npm install --save express애플리케이션 빌드하기이를 위해 next build를 사용하여 애플리케이션을 배포할 수 있습니다. 다음의 npm 스크립트를 추가해주세요:애플리케이션 시작하기프로덕션 애플리케이션임을 알리기 위해 커스텀 서버 코드를 생성해야 합니다.이를 위해 server.js로부터 이 코드를 살펴봅시다.이 부분을 살펴봅시다:그러면 프로덕션으로 이와 같이 애플리케이션을 시작할 수 있습니다.그래서 "npm start" 스크립트는 다음처럼 변경됩니다:마무리Next.js 애플리케이션을 배포하는 것에 대해 거의 다 배웠습니다.문서에서 Next.js 배포하기에 대해 더 배울 수 있습니다.배포에 대한 질문이 있다면 자유롭게 Slack에서 물어보거나 issue를 제출하세요.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유
조회수 1336

레진 기술 블로그 - 자바 기반의 백엔드와의 세션 공유를 위한 레일즈 세션 처리 분석

레일즈 기반의 프론트엔드(브라우저에서 서버 사이드 렌더링 계층까지)와 자바 기반의 백엔드(내부 API와 그 이후 계층)이 세션을 공유하기 위해 먼저 레일즈의 세션 처리 과정을 분석하고, 레일즈 세션 쿠키를 다루기 위한 자바 소스 코드를 공유합니다.여기저기 자랑하고 다녔으니 아시는 분은 아시다시피 레진은 구글앱엔진을 사용하고 있습니다. 지금이야 Java, Python, Node.js, Go 언어와 Flexible Environment 같은 다양한 선택지가 있지만, 레진이 입주할 당시만 해도 Java 7(subset), Python(subset)을 지원하는 Standard Environment라는 선택지 밖에 없었죠.최근 Saemaeul Undong 기술 부채 탕감의 일환으로 자바7, 스프링3.x, JSP(!) 기반의 백엔드에 포함되어 있던 프론트엔드를 레일즈 기반의 프론트엔드 서버(서버 사이드 렌더링을 담당하는 서버는 프론트일까요? 백엔드일까요?)로 분리하고 있습니다.서로 다른 세계의 존재들 - 자바와 레일즈의 세션을 공유해야하는 상황이 문제의 발단입니다.자바와 레일즈의 세션을 공유하는 여러가지 방법이 있겠지만, 가장 단순하고 효과적인 방법은 쿠키(cookie)라고 판단하고, 세션 encrypt/decrypt와 marshal/unmarshal을 동일한 방식으로 맞추기로 했습니다. (백엔드 API를 완전히 stateless하게 새로 만들면 좋겠지만, 코인은 벌어야 소는 키워야죠)이를 위해 레일즈의 세션 처리 과정을 분석하고 정리했습니다.레일즈의 actionpack의 action_dispatch/middleware/cookie.rb를 보면 EncryptedCookieJar 클래스의 초기화 과정은 다음과 같습니다(digest의 경우 따로 지정안하면 SHA1이 사용되는 듯):class EncryptedCookieJar < AbstractCookieJar # :nodoc: include SerializedCookieJars def initialize(parent_jar) super if ActiveSupport::LegacyKeyGenerator === key_generator raise "You didn't set secrets.secret_key_base, which is required for this cookie jar. " + "Read the upgrade documentation to learn more about this new config option." end secret = key_generator.generate_key(request.encrypted_cookie_salt || '') sign_secret = key_generator.generate_key(request.encrypted_signed_cookie_salt || '') @encryptor = ActiveSupport::MessageEncryptor.new(secret, sign_secret, digest: digest, serializer: ActiveSupport::MessageEncryptor::NullSerializer) end private def parse(name, encrypted_message) debugger deserialize name, @encryptor.decrypt_and_verify(encrypted_message) rescue ActiveSupport::MessageVerifier::InvalidSignature, ActiveSupport::MessageEncryptor::InvalidMessage nil end def commit(options) debugger options[:value] = @encryptor.encrypt_and_sign(serialize(options[:value])) raise CookieOverflow if options[:value].bytesize > MAX_COOKIE_SIZE end end key_generator는 EncryptedCookieJar에 포함된 SerializedCookieJars 모듈에 정의되어 있습니다:module SerializedCookieJars # ... def key_generator request.key_generator end end 흠… 좀 더 파보죠. request.key_genrator는 다음과 같습니다:class Request # ... def key_generator get_header Cookies::GENERATOR_KEY end #... end 흠… 좀 더 파야할 듯 ㅠㅠ.Cookies::GENERATOR_KEY는 다음과 같습니다:class Cookies #... GENERATOR_KEY = "action_dispatch.key_generator".freeze end action_dispatch.key_generator는 레일즈의 엔진 모듈에 해당하는 railties의 application.rb에 정의되어 있습니다:def key_generator # number of iterations selected based on consultation with the google security # team. Details at https://github.com/rails/rails/pull/6952#issuecomment-7661220 @caching_key_generator ||= if secrets.secret_key_base unless secrets.secret_key_base.kind_of?(String) raise ArgumentError, "`secret_key_base` for #{Rails.env} environment must be a type of String, change this value in `config/secrets.yml`" end key_generator = ActiveSupport::KeyGenerator.new(secrets.secret_key_base, iterations: 1000) ActiveSupport::CachingKeyGenerator.new(key_generator) else ActiveSupport::LegacyKeyGenerator.new(secrets.secret_token) end end # ... def env_config @app_env_config ||= begin validate_secret_key_config! super.merge( # ... "action_dispatch.key_generator" => key_generator, "action_dispatch.signed_cookie_salt" => config.action_dispatch.signed_cookie_salt, "action_dispatch.encrypted_cookie_salt" => config.action_dispatch.encrypted_cookie_salt, "action_dispatch.encrypted_signed_cookie_salt" => config.action_dispatch.encrypted_signed_cookie_salt, "action_dispatch.cookies_serializer" => config.action_dispatch.cookies_serializer, "action_dispatch.cookies_digest" => config.action_dispatch.cookies_digest ) end end 너무 깊이 판 느낌적느낌(?)이 있지만, 여기까지 왔으니 좀 더 파보겠습니다.핵심 알고리즘은 activesupport의 key_generator.rb, message_encryptor.rb, message_verifier.rb에 정의되어 있습니다.먼저, key_generator.rb의 핵심은 다음과 같습니다:class KeyGenerator def initialize(secret, options = {}) @secret = secret # The default iterations are higher than required for our key derivation uses # on the off chance someone uses this for password storage @iterations = options[:iterations] || 2**16 end # Returns a derived key suitable for use. The default key_size is chosen # to be compatible with the default settings of ActiveSupport::MessageVerifier. # i.e. OpenSSL::Digest::SHA1#block_length def generate_key(salt, key_size=64) OpenSSL::PKCS5.pbkdf2_hmac_sha1(@secret, salt, @iterations, key_size) end end 계속해서, message_encryptor.rb의 핵심은 다음과 같습니다:def initialize(secret, *signature_key_or_options) options = signature_key_or_options.extract_options! sign_secret = signature_key_or_options.first @secret = secret @sign_secret = sign_secret @cipher = options[:cipher] || 'aes-256-cbc' @verifier = MessageVerifier.new(@sign_secret || @secret, digest: options[:digest] || 'SHA1', serializer: NullSerializer) @serializer = options[:serializer] || Marshal end def _encrypt(value) cipher = new_cipher cipher.encrypt cipher.key = @secret # Rely on OpenSSL for the initialization vector iv = cipher.random_iv encrypted_data = cipher.update(@serializer.dump(value)) encrypted_data << cipher.final "#{::Base64.strict_encode64 encrypted_data}--#{::Base64.strict_encode64 iv}" end def _decrypt(encrypted_message) cipher = new_cipher encrypted_data, iv = encrypted_message.split("--".freeze).map {|v| ::Base64.strict_decode64(v)} cipher.decrypt cipher.key = @secret cipher.iv = iv decrypted_data = cipher.update(encrypted_data) decrypted_data << cipher.final @serializer.load(decrypted_data) rescue OpenSSLCipherError, TypeError, ArgumentError raise InvalidMessage end def encrypt_and_sign(value) verifier.generate(_encrypt(value)) end def decrypt_and_verify(value) _decrypt(verifier.verify(value)) end (Hopefully)마지막으로, message_verifier.rb의 핵심은 다음과 같습니다:def initialize(secret, options = {}) raise ArgumentError, 'Secret should not be nil.' unless secret @secret = secret @digest = options[:digest] || 'SHA1' @serializer = options[:serializer] || Marshal end def valid_message?(signed_message) return if signed_message.nil? || !signed_message.valid_encoding? || signed_message.blank? data, digest = signed_message.split("--".freeze) data.present? && digest.present? && ActiveSupport::SecurityUtils.secure_compare(digest, generate_digest(data)) end def verified(signed_message) if valid_message?(signed_message) begin data = signed_message.split("--".freeze)[0] @serializer.load(decode(data)) rescue ArgumentError => argument_error return if argument_error.message =~ %r{invalid base64} raise end end end def generate(value) data = encode(@serializer.dump(value)) "#{data}--#{generate_digest(data)}" end private def encode(data) ::Base64.strict_encode64(data) end def decode(data) ::Base64.strict_decode64(data) end def generate_digest(data) require 'openssl' unless defined?(OpenSSL) OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get(@digest).new, @secret, data) end # ... # encode, decode는 base64사용 이제 레일즈가 쿠키 기반의 세션을 어떻게 처리하는지 조금 눈에 들어옵니다. 그러나 우리의 최종 목표는 레일즈의 내부를 공부하는 것이 아니라, 자바에서 동일한 처리를 하는 것입니다. 모듈 의존성 따위는 가볍게 무시하고 무한복붙(?)을 시전해서, 레일즈의 세션 처리 과정을 눈으로 확인할 수 있도록 재구성했습니다:require 'openssl' require 'base64' require 'concurrent/map' class Object def blank? respond_to?(:empty?) ? !!empty? : !self end def present? !blank? end end class Hash # By default, only instances of Hash itself are extractable. # Subclasses of Hash may implement this method and return # true to declare themselves as extractable. If a Hash # is extractable, Array#extract_options! pops it from # the Array when it is the last element of the Array. def extractable_options? instance_of?(Hash) end end class Array def extract_options! if last.is_a?(Hash) && last.extractable_options? pop else {} end end end module SecurityUtils def secure_compare(a, b) return false unless a.bytesize == b.bytesize l = a.unpack "C#{a.bytesize}" res = 0 b.each_byte { |byte| res |= byte ^ l.shift } res == 0 end module_function :secure_compare end class KeyGenerator def initialize(secret, options = {}) @secret = secret # The default iterations are higher than required for our key derivation uses # on the off chance someone uses this for password storage @iterations = options[:iterations] || 2**16 end def generate_key(salt, key_size=64) OpenSSL::PKCS5.pbkdf2_hmac_sha1(@secret, salt, @iterations, key_size) end end class CachingKeyGenerator def initialize(key_generator) @key_generator = key_generator @cache_keys = Concurrent::Map.new end # Returns a derived key suitable for use. def generate_key(*args) @cache_keys[args.join] ||= @key_generator.generate_key(*args) end end class MessageVerifier class InvalidSignature < StandardError; end def initialize(secret, options = {}) raise ArgumentError, 'Secret should not be nil.' unless secret @secret = secret @digest = options[:digest] || 'SHA1' @serializer = options[:serializer] || Marshal end def valid_message?(signed_message) return if signed_message.nil? || !signed_message.valid_encoding? || signed_message.blank? data, digest = signed_message.split("--".freeze) data.present? && digest.present? && SecurityUtils.secure_compare(digest, generate_digest(data)) end def verified(signed_message) if valid_message?(signed_message) begin data = signed_message.split("--".freeze)[0] @serializer.load(decode(data)) rescue ArgumentError => argument_error return if argument_error.message =~ %r{invalid base64} raise end end end def verify(signed_message) verified(signed_message) || raise(InvalidSignature) end def generate(value) data = encode(@serializer.dump(value)) "#{data}--#{generate_digest(data)}" end private def encode(data) ::Base64.strict_encode64(data) end def decode(data) ::Base64.strict_decode64(data) end def generate_digest(data) require 'openssl' unless defined?(OpenSSL) OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get(@digest).new, @secret, data) end end class MessageEncryptor module NullSerializer #:nodoc: def self.load(value) value end def self.dump(value) value end end class InvalidMessage < StandardError; end OpenSSLCipherError = OpenSSL::Cipher::CipherError def initialize(secret, *signature_key_or_options) options = signature_key_or_options.extract_options! sign_secret = signature_key_or_options.first @secret = secret @sign_secret = sign_secret @cipher = options[:cipher] || 'aes-256-cbc' @verifier = MessageVerifier.new(@sign_secret || @secret, digest: options[:digest] || 'SHA1', serializer: NullSerializer) @serializer = options[:serializer] || Marshal end def encrypt_and_sign(value) verifier.generate(_encrypt(value)) end def decrypt_and_verify(value) _decrypt(verifier.verify(value)) end def _encrypt(value) cipher = new_cipher cipher.encrypt cipher.key = @secret # Rely on OpenSSL for the initialization vector iv = cipher.random_iv encrypted_data = cipher.update(@serializer.dump(value)) encrypted_data << cipher.final "#{::Base64.strict_encode64 encrypted_data}--#{::Base64.strict_encode64 iv}" end def _decrypt(encrypted_message) cipher = new_cipher encrypted_data, iv = encrypted_message.split("--".freeze).map {|v| ::Base64.strict_decode64(v)} cipher.decrypt cipher.key = @secret cipher.iv = iv decrypted_data = cipher.update(encrypted_data) decrypted_data << cipher.final @serializer.load(decrypted_data) rescue OpenSSLCipherError, TypeError, ArgumentError raise InvalidMessage end def new_cipher OpenSSL::Cipher.new(@cipher) end def verifier @verifier end end #key generate encrypted_cookie_salt = 'encrypted cookie' encrypted_signed_cookie_salt = 'signed encrypted cookie' def key_generator secret_key_base = 'db1c366b854c235f98fc3dd356ad6be8dd388f82ad1ddf14dcad9397ddfdb759b4a9fb33385f695f2cc335041eed0fae74eb669c9fb0c40cafdb118d881215a9' key_generator = KeyGenerator.new(secret_key_base, iterations: 1000) CachingKeyGenerator.new(key_generator) end # encrypt secret = key_generator.generate_key(encrypted_cookie_salt || '') sign_secret = key_generator.generate_key(encrypted_signed_cookie_salt || '') encryptor = MessageEncryptor.new(secret, sign_secret, digest: 'SHA1', serializer: MessageEncryptor::NullSerializer) value = "{\"session_id\":\"6022d05887d2ab9c1bad8a87cf8fb949\",\"_csrf_token\":\"OPv/LxbiA5dUjVsbG4EllSS9cca630WOHQcMtPxSQUE=\"}" encrypted_message = encryptor.encrypt_and_sign(value) #encrypted_message = encryptor._encrypt(value) p '-----------encrypted value-------------' p encrypted_message # decrypt encrypted_message = 'bDhIQncxc2k0Rm9QS0VBT0hWc3M4b2xoSnJDdkZNc1B0bGQ2YUhhRXl6SU1oa2c5cTNENWhmR0ZUWC9zN05mamhEYkFJREJLaDQ3SnM3NVNEbFF3ZVdiaFd5YXdlblM5SmZja0R4TE9JbDNmOVlENHhOVFlnamNVS2g1a05LY0FYV3BmUmRPRWtVNUdxYTJVbG5VVUlRPT0tLXd1akRqOU1lTTVneU9LTWszY0I5bFE9PQ==--b0a57266c00e76e0c7d9d855b25d24b242154070' p '-----------decypted value-------------' puts encryptor.decrypt_and_verify encrypted_message p '---------------------------------------' 이 과정을 자바로 구현한 소스는 생략 깃헙에 올려두었습니다. 이 코드를 이용해서 서블릿 세션과 연동하는 방법은 추후 사측(?)과 협의되는 대로 공유할 예정입니다. 물론, 그 전에 쿠키를 공유할 필요가 없어지면(or 공유할 쿠키가 없어지면) 더 좋겠죠 :D
조회수 6547

`git push —force` 이야기

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

[어반베이스 피플] 알고리즘으로 전 세계 도면을 변환하다_CV 개발자 인터뷰

최근의 가장 핫한 연구분야인 '자율주행'의 바탕에는 '컴퓨터 비전'이 필요하다는 사실을 아셨나요? 홍채인식, 스노우 어플도 '컴퓨터 비전'을 사용한 사례입니다. 우리의 가까이 다가와 있지만, 기술 자체에 대해서는 어딘가 생소합니다. 어반베이스의 CV개발자 대희님이 멀고도 가까운 컴퓨터 비전의 모든 것을 알려드립니다!멀고도 가까운 컴퓨터비전(CV)의 모든 것Q. 간단한 자기소개를 해주세요.네, 안녕하세요. 어반베이스에서 컴퓨터 비전(CV) 개발자 윤대희라고 합니다.Q. CV가 생소한 분들이 많을 것 같아요. CV에 대해 쉽게 설명 부탁드려요.CV는 컴퓨터비전(Computer Vision)의 약자에요. 쉽게 말해 컴퓨터가 인체라면 '눈'역할을 담당해요. 카메라를 사용해 입력받은 이미지나 영상을 프로세싱하면 '컴퓨터 비전 처리했다'고 말해요. 예를 들면, 카메라 어플 내에서 얼굴을 인식한 후에 안경을 달아준다거나, 눈을 크게 해준다거나 그런 것들을 컴퓨터 비전에서 처리할 수 있는 거죠. Q. 그렇다면 컴퓨터 비전의 시작은 언제부터인가요? 최근에 생긴 기술 같은데요. 그렇지 않아요. CV의 시작은 60년대부터 있었어요. (60년대요?) 네. 달 표면을 찍은 위성 사진의 화질을 개선하기 위해 디지털 이미지 프로세싱 분야가 탄생했어요. 그동안 기술력이 뒷받침되지 않아서 무언가를 할 수 없었을 뿐이에요. 하드웨어, 즉 카메라 장비나 처리 기술이 발전하면서 이제서야 붐이 일어난 거죠. Q. CV 개발이 활발히 이루어지는 분야가 있을까요?핸드폰 카메라 어플, 자율주행, 홍채인식 등에도 모두 CV가 필요해요.특히 요즘 떠오르고 있는 분야가 자율 주행이에요. 자율주행을 하려면 주행 시 주위 환경을 모두 살펴해야 해요. 차선이나 신호, 보행자와 차량도 봐야 하죠. 실시간으로 영상을 인식하고 처리하는 분야이니 CV 개발이 활발해요.의학 쪽에서도 많이 써요. MRI 사진을 찍은 후 세포의 영역을 볼 때, 의사가 그 모든 세포를 볼 수가 없으니까 CV 처리를 한 후 이상이 있는 세포의 특징만 뽑아내는 거죠. 아까 말씀드렸듯이 항공 쪽에서는 옛날부터 많이 썼어요. 최근에는 무인 우주선의 이미지 분석에 사용돼요. 무인 우주선에서 여러 가지 이미지 데이터를 보내오는데, 기상상황에 의해 이미지를 제대로 판단하지 못하는 경우가 있어요. 그래서 이런 이미지들을 보정하거나 특징을 뽑아내는, 전처리 과정을 CV 통해 해야 해요. 자율주행의 차량인식스노우 어플 (출처 : 스노우 앱 페이지)홍채인식 (출처 : 삼성전자 블로그)Q. 컴퓨터 비전에 대해 조금 더 자세히 알 수 있을까요?최근에 나온 명함인식 어플도 컴퓨터 비전을 사용해요. 명함에 사람의 사진이 붙어 있는 경우도 CV를 통해서 인식하게 될 거예요. 컴퓨터의 입장에서 사람의 얼굴은 공통적인 특징이 있어요. 눈 밑, 코 밑은 어두울 것이고 광대 이마 등은 밝을 거예요. 이런 패턴을 분석해서 명함 내의 얼굴을 인식하게 만드는 것이 CV에요.Q. 제가 알기론 머신러닝도 이미지를 인식하고 분류해주는 역할이라고 알고 있어요. 컴퓨터 비전과 머신러닝은 어떻게 다른 건가요?간단히 말해 컴퓨터 비전은 '눈', 머신러닝은 '뇌' 역할이죠.CV는 머신러닝에 앞선 전처리를 해주는 역할이에요. 앞서 말했듯 CV를 통해 사람 얼굴을 인식할 수 있어요. 우리 모두 눈 밑, 코 밑은 어둡고 광대 이마는 밝게 인식되겠죠. 하지만 사람마다 패턴이 미묘하게 다를 거예요. 또한 같은 사람이라도 각도나 조명에 의해 패턴이 달라질 거고요. 그래서 이런 패턴을 분석해주는 게 머신러닝이에요.'사람'을 분류해주는 건 CV로, 그 사람들 중 '홍길동'을 인식하는 것은 머신러닝인거죠.사람을 분류해주는 건 CV, '홍길동'을 인식하는 건 머신러닝CV 개발자, 어떻게 시작했나요?Q. 개발자가 되기까지의 과정이 궁금해요. 원래 컴퓨터공학을 전공하셨나요?아뇨, 기계설계를 전공했어요. 요즘은 기계 쪽에서도 공장 자동화를 기본 베이스로 하고 있어서 물건의 바코드 인식이나 라벨 색상 처리도 모두 CV의 영역이에요. Q.기계설계 중에서도 다양한 분야가 있는데, CV를 선택하신 이유가 있나요?저는 처음부터 CV를 생각했어요. 과 특성상 하드웨어 설계와 소프트웨어 설계를 동시에 하는데 저는 소프트웨어 쪽에서도 CV를 많이 했어요. CV는 다른 것에 비해서 확실히 재밌어요. 카메라로부터 받은 데이터들을 처리하는 과정이 눈으로 확실히 보이니까 훨씬 재미있게 느껴져요.Q. 운영하고 계신 블로그를 구경한 적이 있는데, 굉장히 정리가 잘 되어 있더라고요. 블로그 사이트는 어떻게 시작하게 된 거예요? 저는 누군가에게 무언가를 알려주고, 지식을 공유하는 걸 좋아해요. 제가 알고 있는 것을 함께 공유하고 공부하기 위해 블로그를 시작했어요. 어떤 것을 설명하는 방법이 그것에 대한 가장 좋은 공부법이라는 말도 있잖아요? 정보를 함께 공유하고 피드백도 받으면서 굉장히 도움이 많이 됐어요. 그래서 지금도 계속 쓰고 있어요.대희님의 블로그블로그의 강좌 목록Open CV 강좌많은 러브콜을 뒤로하고, 어반베이스에 합류하게 된 이유Q. 어반베이스의 합류 과정이 남달랐던 것으로 알고 있어요. 일종의 '스카웃 당했다'고 말할 수 있을 것 같은데요. 합류 과정을 알려주실 수 있을까요?제가 CV 온라인 강의를 진행하고 있었는데, 그때 저를 보시고 연락을 주셨어요. 강의하는 홈페이지에는 개인적인 연락처를 적어 놓지 않고 제 블로그 링크만 달아놨었어요. 그런데 제 블로그에 있는 메일 주소를 찾으셔서 연락을 주셨어요. Q. 어반베이스의 제안을 받고 어땠어요?좋았어요. 말씀해주신 업무를 제가 할 수 있을 것 같았고, 또 면접을 함께한 현우님에게 굉장히 좋은 인상을 받았어요. 부담을 안 가지고 편하게 얘기했는데 좋게 봐주셨던 것 같아요.Q. 여러 산업분야에서 CV로 할 수 있는 것들이 굉장히 많은데 어반베이스를 선택한 이유가 있을까요?확실하게 ‘사람’의 이유가 가장 컸던 것 같아요. 어반베이스에서 저를 믿고 먼저 연락을 주셨고, 함께 이야기를 나누다 보니 좋으신 분이라는 게 확실히 느껴졌어요. 사실 다른 곳에서도 연락이 많이 왔지만 일단 제 능력을 믿어주는 사람과 같이 일하고 싶었어요. 제 능력을 펼치고 싶어도 그렇게 할 수 없는 경우가 있잖아요. 하지만 어반베이스는 확실하게 제 의견을 반영해주시고 제가 하고 싶은 일을 할 수 있는 환경이라는 생각이 들었어요. 결국은 ‘사람’이 좋아서 선택한 거죠. 그게 가장 큰 이유에요. Q. 어반베이스는 VR, AR을 활용해서 공간데이터 사업을 하는 곳이잖아요. 어반베이스 비즈니스에 대한 첫인상은 어땠어요?저는 되게 좋았어요. 자동화한다는 것 자체에 메리트가 느껴졌어요.기계공학을 전공했지만 기계공학에서 건축과 닮은 부분이 있어요. 기계 도면 역시 2D로 그린 후 3D 파일을 또 만들고, 그 이후 텍스처를 설정하는 과정을 거쳐요. 분야만 다를 뿐 일련의 과정들이 건축과 굉장히 비슷해요. 그래서 막연히 '2D 도면을 3D로 바꿔주는 과정을 CV로 자동화 처리하면 괜찮지 않을까?'라는 생각을 했었어요. 분야가 기계에서 건축으로 바뀌었을 뿐, 제가 가지고 있었던 생각이랑 어느 정도 맞아떨어지더라고요. 그래서 어반베이스 비즈니스에 대한 생각이 굉장히 좋았어요. Q. 그렇다면 입사하신 이후 느꼈던 어반베이스의 개발 환경은 어때요? 굉장히 좋아요. 사람에 대한 믿음이 확실히 느껴져요. 맡은 일에 대해 믿어준다는 느낌이 있어요. 그리고 다른 분들에게 질문을 해도 항상 본인 일을 멈추고 먼저 알려주려고 하세요. 그런 모습을 보며 억압하는 분위기가 없고, 협업을 중시하고 사람을 중시한다는 걸 많이 느꼈어요. 물리적인 환경도 좋아요. 사양 좋은 맥북을 새로 사주셨거든요. 하하사양 좋은 맥북과 함께 일하는 대희님어반베이스 기술의 핵심, 도면 변환 알고리즘을 개발하다Q. 대희님이 하고 있는 일을 소개해주세요. 건축도면 이미지(2D)를 읽어서 3D 모델로 만들어주는 알고리즘을 개발하고 있어요.도면 변환에 가장 중요한 것은 좌표에요. 꼭짓점만 알면 벽을 그릴 수 있잖아요? 2D 도면상 좌표의 위치를 알아내서 벽, 문, 창문의 위치를 만들어내는 역할이에요. 좌표의 위치를 안다면 그 도면에 대해서 3D로 만들 수 있는 거죠. 3D로 만드는 과정까지 제가 담당하고 그 후의 렌더링은 3D 파트에서 담당하고 계세요. 대희님의 작업 과정Q. 업무 일과나 업무 스타일은 어때요?하루 종일 개발밖에 안 해요. 알고리즘 만든 후에 도면을 대입해서 처리가 되는지 확인하고, 오류가 있으면 수정하는 이런 패턴의 반복이죠. 어느 정도 완성이 됐다면 다음 단계로 넘어가는 거죠.제 업무 스타일은 목표한 게 있으면 끝까지 하는 스타일이에요. 해야 할 일을 정해놓고 그 일을 모두 마쳐야 퇴근해요. (막히는 경우가 생길 수도 있지 않나요?) 그러면 쉬지 않고 계속 개발하면 돼요. (웃음)Q.대희님은 어떤 분들과 협업을 많이 하나요? 2D에서 3D로 바꿔주는 도면 변환 부분, 즉 가장 베이스가 되는 부분을 만들고 있다 보니 개발 부문 대부분과 협업을 하고 있어요. 제가 만든 것을 사람들에게 보여줘야 하니까 UI/UX팀과 협업을 많이 해요. 제가 만든 API에 대해서도 이야기해야 하기 때문에 API, 백엔드팀과도 협업을 많이 하고요.Q. CV 개발자로 입사 후 가장 기뻤을 때는 언젠가요?제가 입사한 후 CV 코드 리뷰를 하고 코드를 개선해서 확실하게 좋아진 것이 보일 때 정말 좋았어요. 제 의견이 반영이 되어 바뀔 수 있었고, 결과적으로 결과도 좋았으니까요. 그 부분이 가장 좋았어요.제가 만든 알고리즘이 도면 인식을 잘 할 때도 기분이 좋죠. 도면을 넣었을 때 내가 생각한 대로 처리가 잘 되고 생각한 대로 오류가 잘 날 때 뿌듯해요.Q. 앞으로 어반베이스 내에서 개발 계획은 어떻게 되나요?이번 해에는 도면 변환 알고리즘이 구동될 수 있게끔 만들고, 내년 초부터 코드를 수정하면서 알고리즘의 정확도를 높이는 작업을 계속하려고 해요. 그다음엔 해외 도면을 처리하는 과정을 생각하고 있어요. 데드라인이 정해져있는 프로젝트는 아니지만 최대한 빨리 진행하려고 해요. 2D에서 3D로 도면을 변환하는 개발을 저 혼자 하고 있어서 제가 일을 쉬면 프로젝트 자체가 아예 멈춰 버리니까, 되도록 빨리해야죠. 그렇게 해야 수정하고, 피드백을 받고, 출시하는 모든 과정들이 빠르게 진행될 수 있으니까요.CV 개발자에게 가장 필요한 역량은 코딩 능력이 아니다.Q. 여러 분야의 개발자가 있지만 '컴퓨터 비전(CV) 개발자'는 많이 들어보지 못했는데 최근 들어 '컴퓨터 비전 개발자'의 채용이 굉장히 늘고 있는 것 같아요. 앞으로의 CV 시장을 어떻게 예측하세요?사실 이전까지는 기술력 부족으로 할 수 있는 것이 많이 없었어요. 카메라로 찍었을 때 화질이 안 좋으면 CV 처리하기가 굉장히 힘든데 최근에 카메라 성능이 최근에 굉장히 좋아져서 처리 과정이 수월해진 거죠. 그래서 'CV 개발자'에 대한 수요도 늘고 있어요. 이미지로 무언가를 한다면 무조건 CV 개발자가 필요해요. 요즘은 손쉽게 카메라를 설치하고 이미지/영상 데이터들을 얻을 수 있으니까, 더욱 많이 필요할 거예요. 모든 산업분야에서 CV와 관련된 더 많은 개발자, 더 많은 기술이 필요할 것이라고 생각해요.Q. CV 개발자에게 가장 필요한 역량은 뭘까요? 코드를 잘 짜는 것보다 수학을 잘 하는 게 중요해요. 대부분의 이미지 인식 과정에서 수학공식이 사용되기 때문에 후처리를 하려면 수학을 잘 해야 해요. CV는 공업수학, ML은 통계학이 많이 관련되어 있어요.Q. 그러면 코드를 짤 때 코드에서 막히기보다 수학 공식에서 막힐 때가 있잖아요. 그럴 땐 어떻게 해요?늘 거기서 막혀요. 학교를 최근에 졸업했으니 아직 공식이 머릿속에 많이 남아있어서, 막힐 때가 있으면 이런저런 다른 공식 적용을 시도하죠. 어반베이스의 알고리즘으로 전 세계 도면을 변환하다Q. 좋아하거나 롤모델로 삼고 있는 사람이 있나요?루카스 카나데 교수님이요. CV 분야의 세계적인 권위자이신 분이에요. 교수님의 이름을 딴 함수가 있을 정도로요. 그 정도의 명예와 재력이 있는데도 불구하고 꾸준히 공부하고 논문을 발표하시는 모습도 정말 멋있다고 생각해요.Q. 혹시 CV 외에 어반베이스 내에서 욕심나는 분야가 있어요?머신러닝이요. CV에서 전처리를 하고 머신러닝 후에 후처리에 또 CV가 필요해요. 그래서 중간 영역인 머신러닝을 배우면 모든 프로세스를 혼자서 처리할 수 있으니까 머신러닝을 공부해보고 싶어요.   Q. 어반베이스가 혁신적인 기술을 통해서 많이 이슈가 되고 있고, 많은 컨택이 오고 있잖아요. 스스로 어반베이스의 개발자로서 어반베이스의 가능성은 어떻다고 생각해요?확실히 굉장히 높다고 생각해요. CV로 처리해서 자동화한다는 것 자체가 굉장히 뜨고 있는 기술이고 앞으로 계속 발전할 기술이기 때문에 가능성도 굉장히 크다고 생각해요. Q. 대희님의 포부는 뭐예요?전 세계의 2D 도면을 어반베이스의 알고리즘을 통해 3D로 변환할 수 있게끔 만드는 거죠. 단기간은 국내, 중장기적으로는 해외 도면까지요.컴퓨터 비전. 그저 어렵게만 느껴졌던 단어인데, 이번 인터뷰를 통해 컴퓨터 비전과 많이 가까워진 느낌이 듭니다. 어반베이스의 핵심기술을 담당하고 있는 CV 개발자 대희님! 대희님이 만든 알고리즘으로 전 세계 도면이 3D로 변환될 날이 왔으면 좋겠습니다 :)출처: https://blog.naver.com/urbanbaseinc 
조회수 1675

Android Studio JCenter 이용하기

 안녕하세요. 크몽개발팀 입니다.오늘 포스트 주제는 Android Studio JCenter 이용하기입니다.JCenter????  JCenter에 대해 처음 들으시는분들도 있을거같은데요.JCenter는 라이브러리들이 모여있는 저장소라고 보시면 되겠습니다.그렇다면 JCenter를 이용하여 무엇을 할까요?바로 외부 라이브러리들을 가져와서 프로젝트안에 Import 할려고 합니다. JCenter 사이트 링크 : https://bintray.com/bintray/jcenterJCenter 페이지에 접속하시면 위와 같은 페이지를 볼 수 있는데요.여기서 사용하고 싶은 라이브러리를 검색해보겠습니다.제가 검색한 라이브러리는 ImageLoder 라이브러인 'Glide'를 검색했습니다.빨간색으로 표시되있는게 제가 찾던 라이브러리 입니다.검색한 라이브러리를 클릭하면 위와 같이 상세페이지를 볼 수 있는데요.라이브러리 Github 주소 와 버젼에 대한 정보를 확인할 수 있습니다.그럼 이제 검색한 라이브러리를  Android Studio Gradle에 Import 하겠습니다. Android Studio에서 프로젝트를 생성하게 되면 위와 같이 3개의 그래들 파일을 볼 수 있는데요.자주 사용할 그래들 파일은 app폴더에 있는 그래들 파일입니다.그래들 파일을 열어보면 낯익은 코드들이 보이는데요.ADT에서는 매니페스트에서 버젼관리를 햇었는데 Studio에서는 그래들로 빠진거같습니다.그리고 빨간표시를 해둔곳이 바로 JCenter에서 검색한 라이브러리를 Import 하시면 되겠습니다.  위에 JCenter에서 찾은 라이브러리명을 입력하고 뒤에 버젼번호도 같이 입력합니다.그리고 Sync 버튼을 눌러주면 라이브러리가 Import 됩니다. External Libraries를 확인해보시면 라이브러리가 추가된걸 확인할 수 있습니다.---------------------------------------------------------------------------------------이렇게 JCenter를 이용하여 간단하게 라이브러리들을 Import를 할 수 있습니다.그리고 그래들 과 JCenter를 이용하여 라이브러리를 적용할때 가장 좋은점은'com.github.bumptech.glide:glide:3.+' 이런식으로 버젼에대한 값을 주면라이브러리 상위버젼이 나올경우 자동으로 최상위 버젼으로 라이브러리를 Import 해준다는 점입니다.이로써 라이브러리 버젼관리도 많이 편해질거 같습니다.이것으로 Android Studio JCenter 이용하기 포스트를 마치겠습니다.#크몽 #개발팀 #인턴 #인턴생활 #인사이트
조회수 1574

데이터, 기록되고 있습니까?

올해 2월에 썼던 글을 이제야 올려봅니다. 태블로는 아직 잘 사용하고 있습니다. : )“아무개 님, 지난번에 요청한 자료 언제까지 받을 수 있죠?”다행이다. 꿈 이었다.가벼운 발걸음으로 출근하던 중 일감 하나가 떠오른다. 간밤의 꿈이 꿈 만은 아니었던게다.아뿔싸, 아직 시작도 못했는데.오늘 할 일을 내일로 미룬 자의 아침은 발걸음이 무겁다.Business Intelligence 라는 것이 있다. 뭔가 멋드러진 단어의 조합처럼 보이지만, 현실은 그리 아름답지 않다. 대부분의 시간을 비슷한 일을 반복하며 숫자를 맞춰야하고 엑셀과 SQL 에 빠져 살기 일쑤다. 잘못된 데이터라도 발견되면 이걸 어디서부터 수습해야 하나 고민해야 한다. (끝이 없는 재귀호출)반복, 반복, 반복. 비용을 줄이자.반복은 비용이다. 한두번 반복되는 일을 최적화 하는 것은 최적화 자체가 비용 이겠지만, 매일같이 반복되는 일, 주기적으로 찾아야 하는 데이터들은 그 자체만으로도 최적화의 대상이다.특히나, 아직 성장하고 있는 ‘스타트업’ 이라면 회사의 데이터가 잘 정리되어 있을리 만무하다. 몇몇 데이터는 잘 관리되고 있겠지만, 상당수는 흩어져 있을 것이다. 어느 순간을 지나면 이들을 모으는 게 일이 되어버린다. 임계점을 넘어서버린 일을 한다는 것은 손을 더럽히는 일이 된다는 뜻이기도 하다. 아무쪼록 그대에게 이 임계점을 분간할 지혜가 있기를.시간 비용을 절약하자스타트업의 구성원들에게 가장 중요한 것은 무엇일까? 나의 짧은 생각으로는 사람과 시간이라고 생각된다. 이 중에서 BI 툴이 해결해 줄 수 있는 것은 무엇일까?나 스스로에게 질문해보니 이런 답이 나온다. ‘사람은 쉽게 바뀌지 않는다’ 그럼 시간은? 다행히, 시간은 모두에게 공평하게 주어진다.‘그럼 이 시간을 아껴보자!’여기에 하나 더, 내가 모르는 것이 있었다.앞으로 회사가 데이터를 다루는 스펙트럼을 얘상할 수 없다는 것이다.Zeppelin무엇을 사용할까 고민하던 중 가장 먼저 떠오른 것은 다름 아닌 제플린 이었다.< 이 형님들 말고 >(출처 : http://fortune.com/2016/07/26/led-zeppelin-stairway-heaven-appeal/)아파치 제플린은 한국에서 시작해 아파치 인큐베이터에 들어간 오픈소스 데이터 분석 및 시각화 툴 이다.장점은 개발자에게 익숙한 노트북 기반이라는 것과 강력한 인터프리터를 통해 다양한 데이터 소스에 접근할 수 있다는 것이다.나프다 팟캐스트에서 들은 내용인데, 트위터의 경우 태블로에서 제플린으로 갈아탔다는 이야기도 있었다.기본적으로 프로그래밍이 가능하기 때문에 어떤 형태의 데이터를 요구해도 제공할 수 있다는 장점도 있다.물론, 단점도 있다. 먼저 시각화 부분이 약하다는 것이다. D3.js 를 같이 사용하면 보완할 수 있지만 개발자의 꾸준한 지원이 있어야 할 것이었다.더불어, 비개발자들에겐 노트북 형태로 데이터를 가공하는 것에 진입장벽이 있다고 생각 했다.한번쯤 사용해보고 싶었지만 개발 리소스가 부족한 우리 상황에는 맞지 않다고 생각했기에 다음을 기약해본다.Spotfire, Amazon Quicksight, Google Data Studio다음으로 찾아본 툴 들은 바다 건너에서 잘 사용 되는 몇가지 것들 이었다.Spotfire 는 레퍼런스도 충분했지만 다음에 등장한 강력한 후보로 인해 제외됬다.아마존 퀵사이트는 잠깐 사용해봤지만 회사의 요구사항을 맞추는데 부적절해 보였다.구글의 데이터 스튜디오 역시 기능에 제약이 많았다.아마존과 구글의 솔루션은 무료로 사용할 수 있거나 가격이 합리적이라는 장점도 있었다.Spotfire 역시 비싸지 않은 가격이었다.태블로, 그리고 plotly태블로는 동료 직원의 지인 중 사용해본 분이 있어서 직접 만나서 여러가지를 물어볼 수 있었다. 나중에 알았지만 한국에 공식 총판이 있어서 메일로 문의하면 다양한 안내를 받을 수 있었다.태블로는 장점이 많은 툴이다. 다양한 데이터 소스를 지원하며, 강력한 시각화를 통해 데이터를 분석할 수 있다.데이터를 유연하게 다룰 수 있어서 여러가지 인사이트를 얻는데 도움을 줄 것이라 생각됐다.온라인 튜토리얼도 잘 되어있고, 한국에서 오프라인으로 기초교육도 받을 수 있다.종합적으로 비교해 본 결과 비슷한 성격의 툴 중에선 가장 강력한 툴 이었다.유일한 단점이라면 가격이다.plotly 는 리서치 중 가장 마지막으로 접했는데 대시보드로도 사용할 수 있고 노트북에도 붙일 수 있는 라이브러리 형태로 제공되는 툴 이었다.데이터 분석에 주로 사용되는 파이썬, R, 매트랩에 모두 사용 가능했고 훌륭한 시각화도 가능했다. 학생이라면 아주 저렴한 가격으로도 이용이 가능하다.단점이라면, 개발자에게 더 친화적 이라는 것과 데이터 커넥터가 태블로에 비해 부족하다는 것 이었다.BI 툴, 개발자와 분석가 중 누구에게 더 쉬워야 할까?회사마다 개발자의 비중이 다르다. 스타트업 이라고 해서 개발자들로만 이루어진 것도 아니고, 이미 안정적으로 비즈니스를 운영하는 회사라고 해서 개발자가 적은 것도 아니다.각 회사가 처한 상황에 따라 어떤 툴을 사용할 지는 다를 것이다.나는 우리 회사가 어떤 BI 툴을 써야 최적일지 생각해 봤다.같은 작업을 하는데 있어서 시간을 줄여줄 수 있어야 하고, 앞으로의 변화에 유연하게 대응할 수 있는 툴이었으면 했다.개발자의 지원을 최소화 하면서 비즈니스를 이해하는 분들이 적극적으로 사용하는데 어려움이 없었으면 했다.가격적인 면도 중요했지만, 국내에서 사용하는데 참조할 수 있는 레퍼런스, 교육이 풍부한 것도 선택에 한 축이 되었다.모든 것을 종합해 본 결과 태블로 만한 것이 없다고 생각됐다.< 이제 데이터와 사랑에 빠져 볼까? >(출처 : https://www.youtube.com/watch?v=2onPdVj5zgQ)여러분들의 상황은 어떤가.지금 사용중인 툴이 충분한 효과를 가져다주고 있는가? 혹시 기존에 익숙하던 것을 습관적으로 사용하고 있지는 않나?대부분의 스타트업은 부족한 인원으로 복잡한 이슈를 해결하기 위해 고군분투 중일 것이다.특별히, 데이터를 들여다보고 최적화를 해야하는 업무를 담당하는 사람이라면 지금 이 순간도 머리를 싸메고 고민에 빠져 있을 것이라 생각된다.데이터 때문에 잠이 부족한 그대에게, 비슷한 고민을 하는 분들에게, 아무쪼록 이 글이 조금이나마 도움이 되었기를 바란다.#8퍼센트 #에잇퍼센트 #협업 #업무프로세스 #팀워크 #수평적조직

기업문화 엿볼 때, 더팀스

로그인

/