스토리 홈

인터뷰

피드

뉴스

조회수 1899

Mac을 처음 쓰는 개발자에게

Overview애플(Apple) 제품을 한 번도 써본 적이 없습니다. 3주 전, 입사하고 받은 맥북(MacBook Pro)이 첫 애플 제품이었죠. 사실 개발 업무를 하면서 ‘한 번쯤은 애플 제품을 써 봐야겠다’는 생각을 하고 있었습니다. 단지 쉽사리 용기가 나지 않았을 뿐이었죠. 하지만 여러 개발 환경이 존재하는데도 개발자가 한 가지 환경만 고집하는 건 스스로의 잠재 능력을 좁히는 거라 생각했습니다. 그래서 이번 기회에 새로운 환경과 친해지려고 APM 웹서버 구성에 도전해봤습니다. (아자!) OS 설치 완료 후 환경Sierra 10.13apache 2.4php 5.6mysql 5.6 APM 설치 과정MAC 환경에서 APM 설치하려면 MAMP 방법도 있지만 기본적으로 apache, php가 설치되어 있으므로 패키지관리자 Homebrew를 이용하여 설치하겠습니다. 1.apache 설치 버전 확인$ httpd -v 명령어를 실행해서 아래와 같이 버전이 나오면 설치가 되어있는 상태입니다. $ httpd -v Server version: Apache/2.4.27 (Unix) Server built: Jul 15 2017 15:41:46 2.php 설치 버전 확인php -v 명령어를 실행해 아래와 같은 버전이 나오면 설치가 된 것입니다.$ php -v PHP 5.6.32 (cli) (built: Oct 27 2017 11:55:27)  Copyright (c) 1997-2016 The PHP Group  Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies 참고: MAC Sierra 10.13 버전에는 php7 상위 버전으로 설치되어 있습니다. Homebrew로 php5.6 하위 버전을 추가적으로 설치해야 합니다.3.Homebrew 설치Homebrew 명령어1)패키지 검색하기 -> $ brew search 패키지명 2)패키지 설치하기 -> $ brew install 패키지명 3)패키지 삭제하기 -> $ brew uninstall 패키지명 4)설치된 패키지 목록확인 -> $ brew list 5)패키지 정보보기 -> $ brew info 패키지명 6)패키지 업그레이드 하기 -> $ brew upgrade 패키지명 7)패키지 저장소 추가하기 -> $ brew tap homebrew/패키지명 8)패키지 저장소 삭제하기 -> $ brew untap homebrew/패키지명 9)패키지 링크 삭제하기 -> $ brew unlink 패키지명 가.설치파일 다운$ /usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” 나. Homebrew wget 설치 (Apple에서 제공하지 않는 패키지를 설치하기 위한 것이다.) $ brew install wget다. 심볼릭 링크 연결 $ ls -l /usr/local/bin/wget ../Cellar/wget/1.19.2_1/bin/wget bin/wget -> ../Cellar/wget/1.19.2_1/bin/wget 라. 패키지 저장소 추가 $ brew tap homebrew/dupes $ brew tap homebrew/php $ brew update 4.php56 설치가. Homebrew php56 설치 $ brew install php56 –with-apache 나. Apache에 PHP 설정 수정하기 아파치에 php7 모듈이 연결되어 있어 주석 처리 후 설치한 php5 경로로 연결한다. $ vi /etc/apache2/httpd.conf LoadModule php5_module /usr/local/php5-5.6.31-20170817-164511/libphp5.so #LoadModule php7_module libexec/apache2/libphp7.so 다. apache 재시작 apachectl restart라. phpinfo 확인 phpinfo 확인5.mysql56 설치가. Homebrew mysql56 설치$ brew install mysql56나. mysql 시작$ /usr/local/Cellar/[email protected]/5.6.38/bin/mysql.server start다. mysql 버전확인$ /usr/local/Cellar/[email protected]/5.6.38/bin/mysql –version명령어를 실행해서 아래와 같이 버전이 나오면 설치가 되어있는 상태입니다.$ sudo /usr/local/Cellar/mysql\@5.6/5.6.38/bin/mysql --version  /usr/local/Cellar/[email protected]/5.6.38/bin/mysql  Ver 14.14 Distrib 5.6.38, for osx10.13 (x86_64) using  EditLine wrapper 6.가상호스트 설정로컬에 다수의 프로젝트를 세팅하기 위한 것이다. 가. httpd.conf 파일 수정Include /private/etc/apache2/extra/httpd-vhosts.conf <- 주석제거 $ vi /etc/apache2/httpd.conf  # Virtual hosts Include /private/etc/apache2/extra/httpd-vhosts.conf 나. httpd-vhosts.conf 파일 수정NameVirtualHost : 아파치 2.4 이전 버전일 경우 80 포트에서 이름 기반 가상 호스트를 사용하겠다는 의미로 반드시 적어줘야 한다.DocumentRoot : 해당 프로젝트 소스 경로ServerName : 해당 프로젝트 접속 도메인주소 $ vi /etc/apache2/extra/httpd-vhosts.conf NameVirtualHost *:80       DocumentRoot "/Users/comkjs/Sites/ex1"     ServerName ex1.brandi.co.kr     ErrorLog "/private/var/log/apache2/error_log"     CustomLog "/private/var/log/apache2/access_log" common               Options FollowSymLinks         AllowOverride All         Order allow,deny         Allow from all         Require all granted         DocumentRoot "/Users/comkjs/Sites/ex2"     ServerName ex2.brandi.co.kr     ErrorLog "/private/var/log/apache2/error_log"     CustomLog "/private/var/log/apache2/access_log" common               Options FollowSymLinks         AllowOverride All         Order allow,deny         Allow from all         Require all granted     7. hosts 설정해당 도메인으로 접속시 DNS 서버를 사용하기 이전 로컬에 지정된 IP로 맵핑된다.$ vi /etc/hosts ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost  ::1             localhost   127.0.0.1 ex1.brandi.co.kr 127.0.0.1 ex2.brandi.co.kr Conclusion물론 오랫동안 맥북을 사용했던 개발자에겐 쉬운 내용일 수 있지만 MS와 리눅스에 익숙했던 저에겐 ‘두려움’이었습니다. 리눅스 구조와 명령어가 비슷해서 리눅스를 이용했던 이용자에겐 어렵지 않을 것입니다. 한 번 세팅해두면 환경이 바뀌지 않는 이상 잘 건드리지 않기 때문에 나중에 세팅을 바꾸는 일이 있으면 또 다시 볼 수 있도록 기술 블로그에 남겨둡니다. 분명 언젠가는 도움이 되지 않을까요. 글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #기업문화 #조직문화 #업무환경 #인사이트 #경험공유 #Mac #개발자 #신입개발자 #조언
조회수 9473

AWS 비용 얼마까지 줄여봤니?

최근 들어 스타트업의 인프라는 DevOps의 유행과 함께 IDC에서 클라우드로 급속도로 이전해가고 있습니다. 많은 클라우드 업체가 있지만 그중에서도 Amazon Web Service (AWS) 가 가장 선호되고 있고 잔디도 AWS를 이용하여 서버 인프라를 구성하고 있습니다. 하지만 AWS 비용은 예상보다 만만치 않습니다. 잔디에서는 비용을 줄이기 위해 여러 가지 노력을 하고 있는데 이 글에서는 스케쥴링 기능을 이용하여 비용을 줄이는 방법에 대해 공유하도록 하겠습니다.AWS는 저렴한가?AWS는 ‘저렴한 비용’을 자사 서비스의 큰 강점이라고 홍보하지만 실제 사용해보면 막상 ‘과연 정말 저렴한가?’ 라는 의문을 가지게 됩니다. 여러 클라우드 업체의 비용을 비교한 리포트를 보더라도 AWS는 절대 저렴하지 않습니다. 오히려 클라우드 업체 중 가장 비싼 곳 중 하나입니다. 그렇다고 이제 와서 클라우드 업체를 옮기는 건 배보다 배꼽이 더 클 수도… (들어올때는 맘대로지만 나갈땐 아니란다.)예약 인스턴스? 스팟 인스턴스? 온디맨드?AWS에서는 제공하는 요금 할인 방법은 예약 인스턴스나 스팟 인스턴스를 이용하는 것입니다.예약 인스턴스는 계약 기간에 따라 최대 60%까지 저렴한 가격으로 이용할 수 있습니다. 하지만 정확한 기간과 수요예측을 하지 못한다면 잉여 인스턴스가 될 수 있습니다.스팟 인스턴스는 입찰가격을 정해놓고 저렴할 때 이용할 수 있습니다. 하지만 그때가 언제일지도 알 수 없고 인스턴스를 가져갔다고 하더라도 더 높은 입찰가격을 제시한 사용자에게 인스턴스를 뺏길 수 있습니다. 마치 KTX를 입석 티켓으로 빈 좌석에 앉아서 가다가 좌석 티켓 주인이 나타나 ‘내 자린데요?’ 하면 얄짤없면 좌석을 내줘야 하는 느낌입니다. 그때 느끼는 그 서러움은 느껴보지 못한 자는 알 수 없습니다.온디맨드는 사용한 만큼 할인 없이 비용을 지불하는 것입니다. 언제든지 필요할 때 사용하고 사용한 만큼만 과금되어 가장 적절해 보이지만 예약이나 스팟에 비해 역시나 비쌉니다. 비싸지만 현실적으로 가장 많이 사용됩니다.개발서버는 얼마 안쓰는데 좀 깍아줘!일반적으로 개발서버도 라이브와 같이 구성합니다. 고가용성은 고려하지 않더라도 아키텍쳐는 똑같이 구성하게 됩니다. 그리고 아키텍쳐가 복잡해질수록 구성하는 서버도 많아지고 언제부턴가는 개발서버도 비용을 무시할 수 없는 수준에 이르게 됩니다. 하지만 개발서버는 24시간 사용하지도 않고 업무시간에만 사용합니다. 이쯤 되면 한 번쯤 이런 생각을 하게 됩니다. ‘개발서버는 실제로 얼마 쓰지도 않는데 좀 깍아줘야 되는 거 아냐?’ 개발서버뿐만 아니라 정해진 시간만 사용하는 모든 서버들이 해당될 것입니다.EC2 SchedulerAWS는 이러한 원성(?)을 들었는지 EC2 Scheduler 라는 간단한 솔루션을 소개했습니다. 내용을 보면 설정된 시간과 요일에 자동으로 EC2 인스턴스가 자동으로 켜지고 꺼집니다. 하루 10시간 가용한다면 주말 제외 월~금요일만 작동시켜 비용을 70%나 절감할 수 있습니다.이대로만 된다면 왠만한 스팟이나 예약 인스턴스보다 더 저렴하게 개발서버를 이용할 수 있습니다. 하지만 이 솔루션을 그대로 도입하기에는 문제점들이 있었습니다.EC2 Scheduler 의 문제점EC2 Scheduler는 다음과 같은 문제점들이 있습니다.서버 아키텍쳐에 따라서 의존성이 있어 서버 실행 순서가 보장되어야 하는 경우가 고려되지 않는다.단순히 EC2 한두 대 띄워서 사용하는 게 아니고 훨씬 더 복잡한 서버 의존 관계를 가지게 됩니다. 예를 들어 DB -> Middleware -> API -> Batch 같은 관계가 있다고 한다면 의존관계에 있는 서버들이 순차적으로 실행되어야 합니다.스케쥴 시간이 UTC로만 작동한다.UTC로만 작동하기 때문에 시간 설정을 할 때는 항상 UTC 기준으로 변환해야 하는 불편함이 있습니다.스케쥴링의 예외적인 상황이 고려되지 않는다.평일이 공휴일인 경우에는 서버를 작동할 필요가 없고 평소보다 서버를 일찍 켜야 하거나 야근을 하게 되어 중지 시간을 변경해야 되는 경우에는 해당 일자에만 변경이 가능해야 했습니다.EC2에 대해서만 작동하도록 되어 있다.EC2보다 비싼 RDS도 최근에 Stop 시킬 수 있도록 추가되었습니다. Aurora는 미지원잔디의 서버 아키텍쳐는 훨씬 복잡하여 서버의 실행 순서가 맞지 않으면 정상작동을 하지 않기 때문에 1번은 반드시 해결되어야 하는 가장 치명적인 문제였습니다.AWS Instance SchedulerEC2 Scheduler의 문제점을 보안한 Instance Scheduler를 소개하겠습니다. EC2나 RDS 모두 하나의 서버를 Instance로 부르기 때문에 Instance Scheduler라 하였습니다. Instance Scheduler는 Serverless 아키텍쳐인 Cloudwatch + Lambda를 이용하여 구성되어 있습니다.작동방식Cloudwatch Event를 이용하여 Lambda를 함수를 실행시키고 Dynamo DB에 저장된 스케쥴 정보와 Instance의 Tag 값을 기반으로 RDS와 EC2를 조회하고 Instance를 시작하거나 중지합니다. 그리고 JANDI의 Incoming Webhook을 이용하여 토픽에 알림 메시지를 보내줍니다.Cloudwatch EventInstance Scheduler Lambda 함수를 작동시키는 트리거는 Cloudwatch Event를 이용합니다. 5분마다 작동시키도록 되어 있으며 각각의 사용 환경에 따라 변경할 수 있습니다.Cron 식 0/5 * * * ? *, 대상은 Instance Scheduler Lambda를 지정합니다.Dynamo DBDynamo DB에는 Schedule, Schedule 예외 설정, Schedule 서버 그룹에 대한 정보가 정의되어 있습니다.1. ScheduleSchedule 작동에 대한 기본 정보를 정의하고 있습니다.{ "ScheduleName": "Development", "TagValue": "Development", "DaysActive": "weekdays", "Enabled": true, "StartTime": "09:30", "StopTime": "22:00", "ForceStart": false } ScheduleNameSchedule 이름 입니다.TagValue적용 대상 Instance를 조회할 때 참조하는 Tag 값입니다. Instance를 Schedule에 적용 대상에 포함시키기 위해서는 해당 Instance의 Tag에 ScheduleName이라는 Key에 TagValue를 Tagging 하면 됩니다.DaysActiveSchedule 적용 요일입니다. 아래와 같은 옵션이 적용됩니다.all : 매일weekdays : 월~금mon,wed,fri : 월,수,금요일EnabledSchedule의 작동 여부입니다.StartTime, StopTime서버 시작 시간과 중지 시간입니다.ForceStartSchedule 강제 시작 여부를 나타냅니다. (Enabled 여부에 상관없이 작동합니다.)2. Schedule Server Group하나의 Schedule에는 N 개의 서버 그룹을 정의할 수 있고 각각은 먼저 실행되어야 하는 의존관계 서버 그룹을 정의하고 있습니다. 의존관계에 있는 서버 그룹의 Instance Status를 확인하여 시작 여부를 결정하도록 하였습니다. 그러면 의존관계가 없는 서버 그룹부터 시작하고 의존관계의 Depth 가장 깊은 서버 그룹은 가장 늦게 시작하게 되어 서버 실행 순서를 보장하게 됩니다.{ "Dependency": [ "GROUP1", "GROUP2", "GROUP3", "GROUP4" ], "GroupName": "GROUP5", "InstanceType": "EC2", "ScheduleName": "Development" } Dependency의존관계 서버 그룹 목록입니다.GroupName서버 그룹 이름입니다.InstanceTypeEC2와 RDS를 지원합니다.3. Schedule Exception공휴일이나 야근 등으로 인해 스케쥴을 미작동 시키거나 시간을 변경해야 하는 경우에 예외사항들을 정의하고 있습니다.{ "ExceptionUuid": "414faf09-5f6a-4182-b8fd-65522d7612b2", "ScheduleName": "Development", "ExceptionDate": "2017-07-10", "ExceptionType": "stop", "ExceptionValue": "21:00" } ScheduleName예외 적용 대상 Schedule의 이름입니다.ExceptionDate예외발생일 (YYYY-MM-DD)ExceptionTypestart : 시작stop : 중지ExceptionValueNone : 미작동H:M : 변경시간LambdaInstance Scheduler의 Lambda 코드는 Python으로 개발되었으며 Github에 오픈소스로 공개하였습니다. boto3는 배포 package에 Dependency를 추가하지 않아도 Lambda 실행환경에서 가용 라이브러리로 사용할 수 있습니다. 하지만 현재 기본적으로 사용할 수 있는 boto3 버전에서는 RDS Instance를 stop 할 수 있는 함수가 없기 때문에 최신 버전이 필요합니다. 따라서 boto3 버전을 변경하여 함께 packaging 하여 업로드하여야 합니다. 배포는 Lambda 관리 도구인 Apex를 이용합니다. Apex를 이용하면 Dependency package 및 Lambda 생성 및 업데이트, 환경 변수 설정 등을 모두 한 번에 할 수 있습니다.참조 : Lambda Execution Environment and Available LibrariesAWS SDK는 Python boto3 (botocore:1.5.75, boto3:1.4.4) 를 이용합니다.TimeZone 설정Lambda는 기본적으로 UTC TimeZone으로 설정되어 있으며 Instance Scheduler에서는 TimeZone을 변경할 수 있도록 하였습니다. 기본 설정은 Asiz/Seoul이고 아래 코드를 수정하여 변경할 수 있습니다.os.environ['TZ'] = 'Asia/Seoul' time.tzset() JANDI 메신저와 연동Instance Scheduler는 JANDI 메신저의 Incoming Wehbook 을 이용하여 Webhook URL을 Lambda의 환경 변수에 설정하면 서버의 시작과 중지에 대한 알람과 중지 10분 전부터 곧 서버가 중지된다는 알람을 발송하여 필요하다면 서버 중지 시간을 연장할 수 있도록 합니다.Incoming Webhook 설정JANDI의 토픽에서 Incoming Webhook을 연결하고 Webhook URL을 복사합니다.배포된 Lambda 함수의 Code 탭에서 Environment variables에 WEBHOOK_URL을 설정하거나 function.json에서 변경 후 재배포 하여도 됩니다.Instance Scheduler 알람서버 그룹이 시작되면 아래와 같이 알람 메시지를 표시합니다.서버가 중지되기 전에 알람 메시지를 표시합니다.정리Instance Scheduler는 EC2 Scheduler에 비해서 다음과 같은 기능이 추가되었습니다.스케쥴 시간의 타임존 적용서버 그룹 설정 및 의존관계 설정스케쥴의 예외 설정RDS 스케쥴 추가스케쥴에 상관없이 강제 시작 및 중지메신저로 상태 알람EC2 Scheduler에 비해 아쉬운 부분이나 예외사항에 대해서 좀 더 유동적으로 대응할 수 있도록 개선하였습니다.다음 장에는 스케쥴을 컨트롤을 위한 Bot 적용기를 소개하도록 하겠습니다.#토스랩 #잔디 #JANDI #AWS #서버개발 #개발 #개발자 #개발팀 #경험공유 #인사이트 #후기 #일지
조회수 1302

“매일매일 새로운 도전으로 채워지는 자리”

“매일매일 새로운 도전으로 채워지는 자리” – 패스트캠퍼스에서 일하는 콘텐츠 마케터 이야기“마케팅 중 유효한 것은 콘텐츠 마케팅 뿐이다.” – 세스 고딘<보랏빛 소가 온다>를 쓴 세계적인 마케팅 구루 세스 고딘의 말처럼 콘텐츠 마케팅은 마케팅의 주류로 자리잡으며 전통적인 광고의 입지를 위협하고 있습니다. 그런데 콘텐츠 마케팅은 범주가 넓어 기업 특성에 따라 실무에서 담당하는 업무가 다양한데요. 이번 글에서는 패스트캠퍼스의 콘텐츠 마케터들은 무슨 일을 어떻게 하는지 자세히 알려드리고자 프로그래밍팀 시니어 콘텐츠 마케터 김하림님과 파이낸스팀 콘텐츠 마케터 이유나님을 모시고 인터뷰를 진행했습니다.안녕하세요 하림님 유나님, 오늘 인터뷰에 응해 주셔서 감사합니다. 간단하게 자기소개 부탁드려도 될까요? 안녕하세요, 프로그래밍팀 시니어 콘텐츠 마케터 김하림입니다. 지난주에 막 입사한 지 1년이 되었어요.안녕하세요, 저는 파이낸스팀 콘텐츠 마케터 이유나라고 합니다. 패스트캠퍼스에서 일한 지 이제 9개월 째고요. 두 분께서는 패스트캠퍼스에 합류하기 전 무슨 일을 하셨는지, 어떤 계기로 패스트캠퍼스 콘텐츠 마케터로 입사하게 되셨는지 궁금합니다. 패스트캠퍼스에 오기 전에는 웹디자인 일을 하고 있었는데, 회사 규모가 작아 세금계산서 발행부터 제안서 작성까지 회사 운영의 전과정에 참여해야 하다 보니 웹디자인에만 몰두할 수 있는 환경은 아니었어요. 전문성을 가지고 한 가지 일에 좀 더 집중하고 싶어 회사를 그만두었습니다. 그러다 채용공고를 살펴보던 중 패스트캠퍼스의 콘텐츠 매니저(지금은 콘텐츠 마케터로 직함이 바뀌었죠) 자리를 발견하게 되었고요. 제가 할 수 있는 다양한 일들을 업무 역량으로 발휘할 수 있을 것 같아 지원했어요. 저는 지금 마지막 학기를 보내고 있는 대학생이에요. 경영을 전공했고, 교육 분야에도 관심이 있어 국어교육학과를 복수전공하고 있었어요. 제가 흥미를 느낀 이 두 분야를 접목해 할 수 있는 일을 찾다 교육업에 있는 마케터 일이 저에게 딱 맞을 것 같아 지원서를 넣었던 기억이 납니다. 인턴으로 입사했다 정직원으로도 계속해서 함께하는 중이예요. 유나님께서는 인턴 기간이 종료된 후에도 이곳에서 일하고 계신데, 패스트캠퍼스를 선택하신 이유가 무엇일까요? 패스트캠퍼스에서는 인턴이라도 정직원과 같은 일을 하면서 눈치 보지 않고 자기 의견을 낼 수 있던 것이 좋았어요. 저에게는 자기발전을 계속할 수 있는지가 직업을 선택할 때 중요한 기준인데 여기에 맞고, 사회 초년생으로서 일을 배우기에도 좋은 환경인 것 같아 정직원으로 계속 일하고 있습니다. 제가 막 입사했을 때, 당시 팀장님께서 제 직무에 대해 설명해주셨던 것이 기억에 남아요. “프로덕트 매니저가 오프라인에서 기획을 하는 사람이면 콘텐츠 마케터는 온라인에서 기획을 하는 사람이다”라는 말이었는데 저희는 고객분들이 온라인에서 접하는 모든 콘텐츠를 기획·제작하고 글을 쓰는 만큼 일리가 있는 것 같아요. 기획자, 제작자, 에디터의 역량을 모두 발휘해야 하는 사람이 콘텐츠 마케터라고 생각합니다. 하림님의 말씀에 더해, 우리 회사 콘텐츠 마케터가 맡는 특별한 일 중 하나는 상세페이지를 기획 및 디자인해 고객을 설득하는 글쓰기를 한다는 것이에요. 마케터라 하면 광고 크리에이티브를 제작하는 데 업무의 초점이 맞춰져 있다는 느낌이지만, 여기서는 기획 역량까지 발휘해야 하는 점이 특징이죠. 콘텐츠 마케터로서 다양한 일을 하고 계시는데, 어느 정도 정해진 일과가 있을까요? 하루 일과를 딱 잘라서 말하긴 어렵습니다. 그때그때 담당하는 일의 중요도가 달라져서요. 우선 프로덕트 매니저 분이 새로운 강의 기획을 완성하시면 신규 상세페이지를 제작하고, 기존 강의를 업그레이드해 오시면 그에 맞게 기존 상세페이지의 내용을 수정합니다. 홍보 진행이 원활하지 않으면 팀원들과 트러블 슈팅을 통해 상세페이지나 광고 크리에이티브를 손보기도 하고 강사 인터뷰, 수강생 인터뷰 혹은 블로그 게시물이나 카드뉴스 형태의 오가닉 콘텐츠를 발행하기도 합니다. 업무 진행에 있어 큰 틀은 있겠지만 그때그때 업무의 우선순위가 달라져요. 일이 많아 야근할 때도 종종 있고요. 패스트캠퍼스 콘텐츠 마케터 직무, 입사 전 생각했던 것과 실무를 진행하는 것에 차이가 있나요? 저는 비슷한 것 같아요. 간단한 퍼블리싱, 마크업(HTML/CSS로 코딩을 하는 것)을 할 수 있는 사람으로서 이런 스킬들이 상세페이지 제작 업무에 도움이 될 거라고 생각했거든요. 입사 전 필수적으로 갖춰야 할 스킬은 아니었지만 업무를 진행하다 보니 마크업을 알아서 더 도움이 되는 게 많았어요. 그런데… 트러블 슈팅이 이렇게 많을 줄은 몰랐네요. 하하. 저는 하림님과 반대예요. 콘텐츠 마케팅이 이렇게까지 다양한 능력을 요구하는 일인 줄 전혀 몰랐어요. 업무 스킬은 물론 담당하는 강의에 대한 지식적인 부분까지도요. 깊게 파고들 필요는 없지만 얕고 넓은 지식이 필요한 일이더라고요.물론 하림님처럼 업무와 관련된 스킬을 가지고 입사하시면 실무에 확실히 도움 되는 부분이 있어요. 포토샵이나 HTML/CSS 같은 것들요. 하지만 저의 경우에는 포토샵도 못 다룰 만큼 아무것도 모르는 상태로 일을 시작했는데도 필요한 것들을 배워 가며 일할 수 있는 환경이라 괜찮았어요. 그 과정에서 성장하고 있는걸 스스로도 느낄 정도에요.지금 패스트캠퍼스에서는 프로그래밍, 데이터 사이언스, 마케팅, 외국어 등 다양한 팀에서 콘텐츠 마케터를 채용 중인데요. 팀별로 콘텐츠 마케터가 갖춰야 할 배경지식, 선호하는 스킬셋이 다를까요? 크게 차이는 없는 것 같아요. 합류하는 팀에 따라 만들게 되는 콘텐츠의 성격은 달라질 수 있지만 배경지식이 필수는 아니거든요. 프로덕트 매니저 분들이 작성하신 기획 문서를 읽고 핵심이 되는 부분을 짚어 콘텐츠로 만들어낼 수 있으면 됩니다. 이해하기 어려운 부분은 프로덕트 매니저 분들께 물어보면 어느 팀에서건 친절하게 알려주실 거예요. 맞아요. 저도 파이낸스 분야를 공부하며 콘텐츠를 만들고 있는데, 아는 게 점점 많아지고 있는 것 같아 뿌듯합니다. 콘텐츠 마케터는 끊임없이 새로운 것들을 배워야 하는 직무 같은데요. 패스트캠퍼스에서 콘텐츠 마케터로 일하며 가장 힘든 점은 무엇인지 솔직하게 말씀해 주신다면? 하나의 콘텐츠에 오랜 시간을 투입할 수 없는 점? 일주일에 새로운 상세페이지를 세 개씩 만들 때도 있다 보니 한 가지 업무만 집중해서 파고들 시간적 여유가 없어요. 특히 트러블 슈팅이 많이 발생하다 보면 업무 시간이 절대적으로 부족하죠. 유나님 말씀에 더해, 강의마다 특징을 가장 잘 보여줄 수 있는 상세페이지를 만들기 위해 고민하는 게 재밌으면서도 어려운 일 같아요. 이런 부분에 대해 어떤 도움을 드릴 수 있을까 다른 시니어 분들과 함께 고민 중이고요. 그리고 솔직히 말하자면, 일이 정말 많아요. 그게 제일 힘들죠. 업무 과다로 고생이 많으신데, 힘든 점들이 있음에도 이 일을 계속하게 만드는 원동력은 무엇인가요? 일은 많지만 업무 방식에 제한은 없어서 이것저것 새로운 시도를 해 볼 여지가 있다는 게 좋아요. 상세페이지를 수정했거나 새로운 광고 크리에이티브를 만들었는데 효율이 좋다거나, 오가닉 콘텐츠를 발행했는데 커뮤니티 등에 업로드되는 등 좋은 반응을 얻었다거나 하면 보람도 있고요. 틀에 박힌 일을 하지 않는다는 점이 재밌어요. 맞아요. 새로운 시도에 대한 제재가 없으니 할 수 있는 게 많아서 좋죠. 성과에 따른 연봉협상도 유연하게 이뤄지고요. 어떤 콘텐츠 마케터를 동료로 맞이하고 싶으신지 궁금합니다. 새로운 시도에 대한 거리낌이 없으신 분. 새로운 일이 주어졌을 때 ‘저는 이거 못하겠어요’가 아니라 ‘이것도 저것도 해 볼게요’라고 말할 수 있는 분! 팀원들과 협업을 잘할 수 있는 분. 프로덕트 매니저, 퍼포먼스 마케터의 의견을 반영해 콘텐츠를 제작하고 배포하기 때문에 커뮤니케이션 능력이 좋다면 일을 잘할 수 있을 것 같아요. 거기에 하나 더, 자신의 의견만 고집하기보다 다른 사람의 의견을 잘 받아들일 수 있는 분. 서로의 잘잘못을 따지기보다 더 나은 방향을 위해 협업하고 있다는 걸 잊지 않는 분이면 좋겠어요. 쓰는 걸 두려워하지 않는 분이면 정말 좋고요. 맞아요. 포토샵이나 워드프레스 스킬들은 모르셔도 괜찮아요. 저희가 알려드릴게요! 마지막 질문입니다. 두 분께 패스트캠퍼스란 어떤 곳일까요? 매일매일 변화무쌍한 곳. 틀에 박힌 일을 하지 않아요. 오늘, 지금입니다. 오늘이 쌓여서 내일이 되고 매일이 되는데, 그 오늘이 매일매일 새로워요.* 패스트캠퍼스 콘텐츠 마케터는? *  패스트캠퍼스 고객들이 접하게 되는 모든 접점을 컨트롤하는 역할을 담당합니다. 기획 과정에 참여하는 것은 물론 교육 콘텐츠 상세페이지를 제작하고, 매력적인 광고 크리에이티브를 만들고, 강사와 수강생들의 목소리를 전달하기도 합니다. 즉, 패스트캠퍼스에서 만들어지는 모든 콘텐츠의 외모를 결정하고 그 톤앤매너를 관리합니다.
조회수 1876

[H2W@NL] 실패해도 끝까지 간다, COMET팀

네이버랩스의 인재상은 passionate self-motivated team player입니다. 어쩌면 '자기주도적 팀플레이어'라는 말은 형용모순(形容矛盾)일 지도 모릅니다. 하지만 우린 계속 시도했고, 문화는 계속 쌓여갑니다. 다양한 분야의 전문가들이 경계없이 협력하고 스스로 결정하며 함께 도전하는 곳의 이야기를 전합니다. How to work at NAVER LABSH2W@NL 시리즈 전체보기공간 데이터를 디지털라이즈하는 것, 즉 '고정밀 매핑'은 네이버랩스 기술의 시작이 되는 중요한 과제입니다. COMET 프로젝트는 매핑 로봇이나 MMS (mobile mapping system) 차량이 다니기 어려운 복합 지형에서의 매핑 기술을 연구하고, 네이버랩스 매핑 디바이스들의 표준을 개발하는 것을 목표로 합니다. 그런데 이 프로젝트 이전, 많은 시도와 실패가 있었습니다. 물론 실패를 극복해 더 단단한 결과물을 만들어낸다는 아름다운 결말이 현실에서 비일비재하지는 않습니다. 여건도 상황도 이를 쉽게 허락하지 않지만, 무엇보다 사람도 지치기 마련입니다. 그래서 COMET 팀이 더 궁금했습니다. 어떤 일들이 있었는지 들어보았습니다. Q. 어떤 프로젝트인가요?(정은교|TL) 그간의 매핑 디바이스 개발은 주로 고정형이거나 특정 지형에 한정되었죠. 그런데 COMET은 지형 지물에 상관없이 데이터 수집이 가능해야 한다는 것이 전제였습니다. 실내나 도로처럼 규격화된 곳이 아닌 울퉁불퉁한 인도, 계단, 구불구불한 등산로 등등. 지형의 특성과 무관하게 고정밀 데이터를 수집할 수 있어야 합니다. 먼저 백팩 타입 설계를 시작한 이유입니다.프로젝트 이름에 모든 의미가 담겨있다(이성준|PM) 그래서 COMET이라는 프로젝트 명을 정했죠. 우주에는 정해진 궤도를 따라 움직이는 행성들만 있는 것이 아니라 궤도를 가로지르는 혜성도 있죠. COMET 프로젝트는 네이버랩스의 실내 매핑로봇 M1, 도로의 모바일매핑시스템 R1 사이에서 그간 커버하기 힘들었던 공간들을 빈틈없이 연결해주는 역할을 합니다.한 획을 그어보자, 혜성처럼(정성용|하드웨어/펌웨어 설계) 사실 다른 컨셉의 프로젝트들이 계속 있었어요. 그런데 예상치 못했던 내외부 변수들로 여러차례 중단되었죠. 거의 완성 직전인 프로젝트도 있었거든요. 그때 의욕이나 열정이 많이 사라질 뻔 했는데, 성준님이 ‘마지막으로 혜성처럼 회사에 한 획을 그어보자’고 하며 COMET 프로젝트를 제안했던 게 기억나요. 그런 의미의 이름 아니었나요?"COMET 의 핵심 컨셉은 기존의 고정밀 매핑 디바이스들로 접근하기 어려웠던 영역들의 빈틈을 빠짐없이 연결한다는 것입니다. 이동 환경이 비교적 균일한 도로나 실내의 보도에서는 이미 솔루션이 충분한 편입니다. 하지만 아직 고정밀 지도를 만들기 어려운 영역이나 복합 지형들은 여전히 많아요. 그런 곳에서도 COMET을 통해 공간 데이터를 끊김없이 연결할 수 있게 된 것이 가장 큰 성과입니다." 실패라는 것을 팀에서는 어떻게 활용 했나요?실패도 자산화하려면 프로세스가 필요하다(이성준|PM) COMET 이전의 여러 시도와 실패를 통해 깨달은 게 있습니다. 프로젝트의 자산에 대한 것입니다. 중단된다고 그간 쌓아왔던 것이 없어지면 안되죠. 그래서 각 프로젝트를 통해 얻은 경험과 노하우를 자산화하기 위한 프로세스를 만들고자 했습니다. 일단 큰 틀을 잡고, 각 단계는 sprint 방식으로 진행했습니다. 지금 우리가 어디까지 왔는지를 가시적으로 확인할 수 있다는 점도 큰 도움이 되었어요.모든 끝은 새로운 시작으로 연결(천정훈|프로그래밍/하드웨어 설계) 진행되었던 모든 프로젝트 정보들이 정리되고 공개되어 있습니다. 저 역시 이전의 솔루션들을 참고해 개발속도를 높일 수 있었습니다. 이런 정리를 중요하게 생각하는 이유는, COMET이 끝이 아니라 다음 프로젝트로 이어지는 단계라고 생각했기 때문입니다. 애초에 추후 프로젝트에서 활용될 수 있는 기술들에 대한 고려를 많이 하고 있습니다. 예를 들어, 다음 프로젝트에서도 활용할 것을 전제로 각종 센서데이터의 효율적 수집 프로토콜을 설계하거나, circuit board의 펌웨어 업데이트 기능도 적용하여 확장성을 미리 대비해 두는 것이죠.프로세스가 작동하면 일어나는 일(정성용|하드웨어/펌웨어 설계) 저는 사실 COMET도 완료되지 않을 거라 생각했어요. 기술적인 어려움은 아니었어요. 올해 회사의 리더십이나 로드맵이 변화되는 상황에서 이 프로젝트가 안정적으로 끝나는 것이 쉽지 않을 거라 생각했죠. 그런데 그간 쌓인 경험들, 그로 인해 만들어진 단단한 프로세스가 작동하기 시작했습니다. 그래서 모두의 예상보다 빠르게 완료가 되어버렸어요. 정말 말도 안되게 기간 단축이었습니다. 물론, 개발 중엔 하루 하루가 도전이고 위기였죠.담당자라는 개념과 경계를 넘는 것(천정훈|프로그래밍/하드웨어 설계) 분명 개개인이 달성해야 할 목표라는 건 있습니다. 보통 이런 건 명확한 편이죠. 그런데 그것만 각자 잘 한다고 프로젝트가 잘 되는 건 아닙니다. 다른 담당자의 역할이나 완료를 그저 기다리는 것이 아니라, 필요하다고 생각되면 스스로 리드하거나 함께 고민하고 대화했습니다. 팀과 상관없이 해당 분야의 전문가를 찾아 풀어야 할 문제에 대해 편하게 논의할 수 있다는 건 네이버랩스 조직문화의 확실한 강점입니다. 누구든 언제든 쉽게 서로 피드백을 나눌 수 있는 분위기이기 때문에, 고민이 생겼을 때마다 더 잘 해결할 수 있었던 것 같네요.전문가들의 진짜 전문가다운 협업(최문용|GPS 하드웨어 설계) COMET의 GPS 수신이 예상보다 나쁘게 나온 적이 있었어요. 그러면 하드웨어 전문가, 소프트웨어 전문가, GPS 알고리즘 전문가가 총출동합니다. 각각의 전문 분야를 기반으로 다각적으로 관찰하고, 논의하며, 효과적인 대응 방안을 찾으면 기구 파트에서 바로 적용을 해줍니다. 그 결과 우리가 기대하는 성능까지 올릴 수 있었습니다. 그걸 바라보는 저는, 소름이죠! 각자의 업무 경계를 크게 가르지 않고도, 협업을 통해 팀 전체의 전문성을 높일 수 있었어요.너도 코딩 나도 플래닝(정성용|하드웨어/펌웨어 설계) 실제로 우리는 서로의 영역을 구분하지 않고 자연스럽게 영역을 넘나듭니다. 담당자는 정해져 있지만, 그렇다고 개발 및 의사결정을 담당자만 하지 않습니다. 필요하다고 생각되면 누구든 직접 회로를 그려보고, 직접 코드를 작성해보고, 기구를 설계하거나 스스로 프로젝트 계획을 수립합니다.(이재량|기구개발) 물론 현실은 티격태격이죠. 의견 차이가 있을 때는 정말 뜨겁습니다. 서로 화를 내며 논쟁하기도 합니다. (저는 아닙니다) 그런데 결과적으로는 더 좋은 결론에 다다르더라고요. 누구나 자유롭게 의견을 말하고 논쟁할 수 있다는 건 프로젝트 완성도를 위해 정말 중요한 환경입니다. 결국 각자의 분야에서 아주 뛰어난 전문가들이기 때문이죠."전문성을 가진 팀원들간의 자유로운 소통이 주는 장점은 무엇일까요? 각자의 담당 업무 영역이 오버랩되면서 ‘너의 문제’와 ‘나의 문제’라는 경계가 어느 순간 사라진다는 점입니다. 서로의 전문성을 진심으로 인정하고, 서로 다른 분야에 대한 관심과 이해하려는 노력이 있었기 때문에 가능했던 것 같아요. 지금은 농담으로 다음 프로젝트에서 각자 무엇을 담당할지 사다리 타서 정하더라도 프로젝트는 잘 돌아가겠다고 말해요." Q. 앞으로의 목표는?어떤 형태로도 적용 가능한 매핑 디바이스의 표준을 만들 것(정은교|TL) 앞서 말했듯 COMET 프로젝트는 다양한 지형에서 고정밀 공간 데이터를 수집하는 것이 목표였고, 그것이 가능해졌다는 것이 가장 큰 성과입니다. 이 프로젝트를 통해 센서간 조합에서 오는 아주 다양한 문제와 side effect들을 경험하고 해결했습니다. 이러한 정보와 노하우를 바탕으로 네이버랩스 매핑 디바이스들의 표준화를 준비하고 있습니다. 그래야 이후의 많은 매핑 프로젝트에 빠르고 효율적으로 대응할 수 있습니다.(이성준|PM) 실제로 COMET은 그 자체로 끝이 아닙니다. 실제 운용 시간과 환경을 늘려가며 테스트하면서 새로운 개선점을 발견하게 될 것이고, 이러한 과정을 통해 더 다양한 환경과 머신에 적용할 수 있는 확장성 있는 시스템으로 발전시킬 수 있을 것입니다.(이재량|기구개발) 처음에는 기존에 해보지 않았던 타입을 개발해야 한다는 점에서 초기 컨셉 단계부 터 막막했습니다. 지금은 어느새 새로운 소재나 구조를 검토하며 업그레이드를 위한 테스트를 지속하고 있는 상태입니다. 계속 버전업되는 COMET을 기대해주세요.과거의 자산을 잃지 않기 위해 단단한 근간을 마련한다(정성용|하드웨어/펌웨어 설계) 결국 우리가 COMET을 통해 얻어낸 가장 큰 것은, 우리만의 매핑 디바이스 표준을 만들어가고 있다는 점이 아닐까 생각합니다. 앞으로 네이버랩스에서 개발될 매핑디바이스는 그 형태나 목적이 어떻게 되더라도 COMET이 근간이 됩니다. 이제는 프로젝트 방향이 달라질 때마다 컨셉을 새로 설계하는 방식을 벗어나, 그간의 자산을 하나도 잃지 않은 상태에서 지금 가장 효과적인 방식의 매핑 디바이스를 만들 수 있습니다. 이러한 결과를 위해 필요했던 과거의 실패들이었던 것 같습니다.
조회수 1839

GDG DevFest Seoul 2018, 크래커나인 부스 참가 후기

2018년 11월 10일 토요일, 세종대학교 광개토관 컨벤션홀에서 GDG DevFest Seoul 2018이 열렸습니다. 세종대학교 광개토관 컨벤션홀 세션장과 세션 소개지GDG 행사 중 가장 큰 개발자의 축제에 크래커나인이 빠질 수 없겠지요?GDG DevFest는 GDG 커뮤니티에 의해 매년 개최되는 개발자 행사 중 하나로, 올해는 'Digital Wellbeing' 이라는 키워드 아래 진행되었습니다.이번 행사는 구글 기술과 관련된 세션, 해커톤, 코드랩 등의 형태로 구성이 되어 짜임새 있고 더 유익했습니다.⬆️ 위의 시간표 출처: 티켓구입처(https://festa.io/events/88)여기서 코드 랩은 무엇인지 궁금 하시지요?* Codelab은 미리 작성된 가이드를 따라 빠르게 해당 기술의 튜토리얼을 해볼 수 있는 프로그램이였어요. Codelab 튜터가 상주하고자유롭게 출입해 시작할 수 있다는 큰 매력으로 많은 개발자님들이 참여해주셨습니다.이미지 출처: https://devfest-seoul18.gdg.kr/timetableTrack E에 후반에 진행하는 마인드폴니스는 이번 'Digital Wellbeing' 키워드에 가장 걸맞았어요.* Mindfulness는 경직된 자세로 오랜 시간 작업을 하기 쉬운 개발자들을 위해 명상을 하는 시간을 가지는 프로그램입니다.저희 크래커나인 팀원들도 마인드폴니스에 참여하여 힐링하였다고 하네요 :)이미지 출처: https://devfest-seoul18.gdg.kr/timetable그 밖의 세션들은 Android, Firebase, Google Cloud Platform, Machine Learning, Web Technologies, Chrome 등의 Google 개발자  기술  콘텐츠 뿐만  아니라  더  나아가  트렌드에  부합하는  많은  주제를  폭  넓게  다루는  다양한  시간이었습니다.이미지 출처: https://devfest-seoul18.gdg.kr/timetable단 5분만에 디자인을 코드로 만들어주는 크래커나인은 행사의 꽃, 부스 참가하였습니다.구글 코리아, 레이니스트, 카카오페이, 알지피코리아 등과 나란히 부스 참가하여 많은 개발자님들을 만날 수 있었습니다.이미지 출처: https://devfest-seoul18.gdg.kr크래커나인은 10월 1일 부터 GDG DevFest Seoul 2018을 준비하기 시작했습니다.더 많은 개발자님들에게 편리하고 효율적인 크래커나인을 소개하여 작업 속도와 능률을 올리고자 했습니다.대략 40일간 준비하면서 진짜 디자이너와 개발자가 원하는 바가 무엇인지도 생각해보는 뜻깊은 시간들 이었습니다.먼저, 개발자님들의 애정한다는 스티커를 팀 명함과 함께 제작하였습니다.또한 많은 분들에게 크래커나인 무료 베타 서비스와 더불어 선물을 선사해드리고 싶어 경품 이벤트도 진행했답니다 :)  국내에서 다수가 사용하는 GUI 가이드 프로그램 제플린의 아성에 도전하는 크래커나인!실제 크래커나인을 사용하면 GUI 정보는 물론, 안드로이드 코드까지 생성해주어 매우 효율적입니다. 실제 블로터에 메인 게재될 만큼 혁신적이고 획기적인 크래커나인을 많은 분들께 소개하려니 너무 설레였습니다 :)“디자인만 하면 코드 자동 생성”…‘크래커나인’ 베타 출시코드를 '클릭'으로 해결해준다.www.bloter.net이 날, 제플린 vs 크래커나인 속도 테스트 영상을 공개하여 큰 이슈를 받았는데요~ 많은 개발자님들의 환호와 관심에 더욱 더 좋은 기능과 서비스로 보답해야 겠다는 마음이 커졌습니다.   제플린과 크래커나인 속도 테스트 영상 궁금하시지요?Cracker9 VS Zeplin (19sec)똑같은 앱 화면 디자인을 크래커나인과 제플린을 사용하여 GUI정보를 받아 안드로이드 스튜디오를 이용하여 화면을 구성하기 까지의 작업 속도를 비교한 영상입니다. 안드로이드 코드까지 생성해주는 크래커나인은 5분대에 화면 완성! GUI가이드문서를 만들지 않아도 빠르고 간편하게 GUI가이...youtu.be코드 생성 프로그램은 기존에도 존재한 적 있지만, GUI 정보와 안드로이드 레이아웃 코드까지 클릭만으로 뽑아주는 크래커나인은 그야말로 +_+ 최고!실제 사용해보고 시연할 수 있는 곳을 만들어 많은 개발자님들의 검증도 받았답니다.  믿음이 가는 코드에 만족하셨나요?스피드하게 짜는 손코딩 장인 "시니어 개발자"도~알아가는 단계지만 꼼꼼하게 체크하며 한땀한땀 작성해가는 "주니어 개발자"에게도~시연, 체험했던 크래커나인!개발자님들에게 편의성 뿐만 아니라 신뢰성 마저 안겨주었던 좋은 기회였습니다. :)그 밖에도 카카오인형 경품으로 많은 인원을 모은 카카오페이는 "요즘개발자, 카카오페이" 라는 카피와 QR 코드로 부스를 장식했습니다. 명함 이벤트를 진행한 요기요 배달통 부스는 경품 당첨때만 인산인해를 이루었답니다. 갑자기 많은 개발자님들이 당첨 여부 확인하러 오셨다가 저희 부스에 와주셔서 또 다른 기회로 크래커나인을 소개할 수 있었답니다 :) 세션에 참가하여 각자의 생각과 견해를 적어주신 개발자님들께도 감사의 인사를 드립니다.세션의 상세내용은 아래의 포스트에서 좀 더 자세히 보실 수 있습니다.※ 디테일한 강연내용과 후기를 남겨주신: http://eclipse-owl.tistory.com/18?category=1022165※ 자신의 견해와 행사의 세션 정리를 잘 해주신: https://brunch.co.kr/@oemilk/196#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업 #이벤트참여 #이벤트후기
조회수 1712

금융 테크놀로지와 #개발

여름은 언제 끝날까? 주말부터 더위에 지친 오늘, 단비 같은 시원한 소식이 핀다에 찾아왔다.한국형 핀테크 세계 금융 판도 흔든다`제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#핀다 #개발팀 #개발자 #팀원소개 #조직문화
조회수 2442

A/B Testing 도구인 Optimizely 사용법

웹 서비스를 운영하다 보면 준비하는 과정에서 정말 많은 고민이 오갑니다. 컨텐츠의 배치, 헤드 카피, 인터랙티브.. 하지만 어떤 요소가 조금 더 사용자의 반응을 이끌어내는지 정확히 알 수 없습니다. 이런 부분들을 ‘직감’이나 ‘경험’으로 막연하게 자기 자신과 타인에게 주장하고 있지는 않나요?그렇다면 두 가지 혹은 그 이상의 시안들을 직접 시험대에 올려 각각 더 좋은 것을 선택하는 것은 어떨까요?A/B 테스팅에 관련한 유명한 일화가 하나 있습니다. 1497년, Vasco da gama는 최초로 유럽에서 아프리카 남부를 거쳐 인도까지 항해한 인물입니다. 그가 인도를 발견하고 귀항했을 때 160명의 원정대원 중 100명이 괴혈병으로 사망하는 사건이 있었습니다. 그만큼 괴혈병은 항해하는 선원들의 공포 대상이었죠. 그로부터 약 300년 뒤, 영국의 의사인 James Lind는 괴혈병의 치료법을 알기 위해 실험군을 나누어 각각 다른 음식으로 실험을 진행했습니다.실험은 다음과 같습니다. 괴혈병에 걸린 12명의 선원을 선정하여 그 중 10명에게는 보통 음식을 주고, 두 사람에게는 매일 라임 과즙을 마시게 하였습니다. 6일 후 라임 과즙을 마신 선원 두 명만이 괴혈병에 완벽히 치료된 모습을 보였습니다. James Lind가 실험하기 전에는 단순히 ‘감귤류 과일이 괴혈병에 좋다.’, ‘괴혈병으로 죽어가는 찰나에 잡초를 먹고 다시 살아났다.’ 라는 이야기만이 난무했었고 직접적인 치료법을 제시한 사람은 James Lind가 최초였습니다. 비타민C가 발견된 것이 1928년임을 고려하면, 이 당시에는 비타민C 이라는 개념이 없었기 때문에 James Lind의 실험은 후에 많은 선원의 목숨을 괴혈병으로부터 지켜주는 사례가 됩니다.괴혈병이 해적보다 더 무서웠던 대항해시대에 보통 음식(A)과 라임(B)을 이용해 선원들을 모두 구했던 영국 해군의 현명한 대처법에서 우리의 웹 서비스를 더욱 더 활성화 시키는 지혜를 얻어야 합니다.Optimizely?Optimizely는 웹서비스를 운영하면서 A/B Testing 수행을 원하시는 분들에게 적합한 서비스입니다. Optimizely를 사용하기 전에 A/B 테스팅에 대한 정보가 필요하다면 A/B 테스팅에 관련한 JC Kim님의 글( A/B Testing에 대한 기초적인 정보들 )을 먼저 읽어보시는 것을 추천합니다.Optimizely는 단순히 A/B 테스트의 진행과 그 통계 결과만 제공하는 것이 아니라, 테스트를 진행하는 동안의 모든 준비 과정에서 사용자들에게 도움을 주고 있습니다. 오늘은 그 Optimizely의 핵심 기능 및 활용법에 대하여 알아보겠습니다. Optimizely는 유료 서비스이지만 30일 동안의 Free Trial을 제공해주므로 그 기간 동안 충분히 이 서비스의 모든 것을 체험할 수 있습니다.Optimizely는 세계적인 대형 기업들이 이용하는 서비스로, 이들은 이미 Optimizely를 통해 각각 컨텐츠들에 대한 사이트 접속자들의 반응을 체크하고 있습니다. 대표적인 회사로 Starbucks, Salesforce, MTV, The Walt Disney Company, ABC 등이 있습니다.그렇다면 왜 많은 기업들이 A/B Testing에 집중하고 있고, Optimizely를 이용하는 걸까요?더 정확한 데이터를 추출하려는 노력.메일링 리스트를 수집하는 등의 폼 입력/전송을 하는 비율을 구하는 경우, 혹은 메인 페이지에서 다른 세부페이지로 이동하는 이용자 비율을 나타내기 위해 목표(Goal)을 나타냅니다. 목표한 골에 A 버전(기존안/Original) 이용자가 더 많이 들어갔는지, B 버전(새로 작성한 안/Variation)이 효과적이었는지를 테스트 할 수 있습니다.이처럼 Goal에 도달하는 행위를 ‘Conversion’이라 표현합니다. 방문자 수 대비 Conversions 수치를 비교한 Conversion rate를 비교하면 A/B 시안 중에 더 효과적인 결과를 수치와 그래프, 특히 “기준을 이길 수 있는 확률”(Chance to beat baseline)을 철저하게 계산해 결과를 명확하게 진단할 수 있습니다. 말 그대로 Goal과 Conversion Rate 수치로 사용자가 승자를 판단하는 것이 아니라, 수치공식을 통해 B 버전이 기존안(A버전)을 확실하게 이겼는지 아닌지를 파악해줍니다.더 자세히 알고싶은 부분은 해당 값을 구하는 통계공식이 있는 링크를 참고해주세요.정말 쉬운 실험요소 변경.Optimizely를 이용하면 여러분이 복잡한 CSS나 Javascript 기술이 없어도 쉽게 A/B 테스팅을 진행할 수 있습니다. Optimizely에서는 실험군의 요소를 마우스 클릭 몇 번으로 손쉽게 바꿀 수 있습니다. 가령 B 버전에 A 버전과 다른 문서 배치를 하거나 배경화면, 이미지, 폰트, 버튼 속의 문구 등도 별도의 코딩 절차 없이 Optimizely 실험페이지 내에서 변경할 수 있다는 말이죠. 또한 실시간으로 CSS를 변경하여 적용하거나 Javascript도 적용할 수 있습니다. 마치 ‘나모 웹 에디터’ 나 ‘드림위버’ 같은 인터페이스로 파워포인트 내의 요소를 다루듯 쉽게 바꿀 수 있습니다.위치와 크기를 Drag & Drop 으로 쉽게 움직이게 할 수 있습니다.웹사이트에 적용된 이미지 또한 로컬에 있는 파일 혹은 웹에 있는 이미지로 대체할 수 있습니다.텍스트도 곧바로 변경할 수 있고 HTML을 직접 대체해서 끼워 넣을 수 있습니다.참 쉽죠?간단한 설치위처럼 변경했던 시험요소들을 저장하려면 복잡하고 긴 코드를 다시 원래 파일에 붙여 넣어야 할까요? 그렇지 않습니다. Optimizely는 변경한 컨텐츠 정보를 간단한 자바스크립트 코드로 ‘Optimize’ 해 주기 때문에 단 몇줄만 추가해주면 원하는 결과가 나옵니다.확장성유명한 아티스트 두 명이 콜라보레이션 하는 상상을 해보죠. 각자의 개성을 살려 새로운 결과물들을 창조해내지요. 물론 그들의 궁합이 잘 맞아야 한다는 전제가 있습니다. 하지만 다행히도 Optimizely와 연동되는 서비스들은 궁합이 잘 맞는 편입니다. Optimizely는 A/B 테스팅에 관한 자료에 집중하고 있기 때문에, 조금 더 디테일한 자료(Analytics, Heatmap)는 욕심내지 않고 기타 많은 서비스와 연동합니다.Optimizely와 연동되는 서비스는 다음과 같습니다.AnalyticsGoogle AnalyticsKISSmetricsMixpanelOmniture SiteCatalystHeatmapClickTaleCrazyegg위 서비스 중 하나라도 이용 중이시라면, Optimizely와 어떤 부분이 연동이 되는 지 살펴보세요.마치며페이지 두 개를 접속자들에게 무작위로 나누어 배포해서 반응을 트래킹하는 기술은 흔할지도 모릅니다. 하지만 Optimizely를, 그리고 연동되는 다양한 서비스들을 이용하면 조금 더 세밀하고 확실한 데이터를 얻을 수 있습니다. 정말로 나의 웹 서비스에 필요한 것이 ‘잡초’인지 ‘레몬’인지 알고 싶다면 지금 당장 시작해보세요.#스포카 #기획 #A/B테스트 #A/BTest #꿀팁 #인사이트 #조언
조회수 3660

포스트맨 200% 활용하기

편집자 주 MAC OS 기준으로 작성했으며, 본문 내용 중 Proxy(또는 프록시)는 영문으로 통일하여 표기함. OverviewPOSTMAN은 API 테스트에 큰 도움을 주는 도구입니다. 강력한데다가 무료입니다. 안 쓸 이유가 없군요. POSTMAN은 사용하는 방법도 쉽습니다. 그래서 이번 글에서는 최근에 나온 POSTMAN native 버전 패킷캡쳐 방법을 공유하겠습니다.native App은 기존 크롬 플러그인 버전보다 깔끔하고 버그도 많이 줄었습니다. 하지만 원래부터 강력했던 postman interceptor가 아직 지원하지 않습니다.1)공식 블로그 답변입니다.이미 interceptor를 사용하고 있어서 native App에 대한 니즈는 없었는데요. 한글 패킷 캡쳐를 시도하고 생각이 완전히 바뀌었습니다. intetceptor로 캡쳐된 패킷테스트 중이던 공지사항 제목이 이상하게 변경됐습니다.Postman Proxy를 써보자!어쩔 수 없이 native App 을 써야겠다고 생각했습니다. 가장 먼저 postman interceptor에 연결할 방법이 필요했는데 위의 공식 블로그 답변처럼 지금은 안 된다고 합니다. 구글링을 했더니 아래와 같은 글이 보였습니다.스마트폰이나, 기타 기기들의 패킷을 캡쳐할 수 있기 때문에 매력적인 방법입니다. 웹을 사용할 땐 브라우저를 Proxy 태우면 결과는 비슷하게 나올 겁니다.native Appnative App은 여기에서 다운로드 받을 수 있습니다. nativeApp을 켜면 오른쪽 위의 메뉴에 interceptor 아이콘은 없고 위성안테나 모양의 아이콘이 있습니다. 이것은 Proxy Server 기능입니다. Proxy Server를 postman native가 구동해주고 사용하는 방식이죠.Proxy 설정 화면이 뜨는 기본 포트는 5555번입니다. 따로 할 건 없고, 캡쳐 위치는 기본 값인 History로 지정합니다. 만약 다른 컬렉션에 내용을 모으고 싶다면 그곳으로 지정하세요. Connect 버튼을 클릭하면Proxy가 구동됩니다.요청 내용을 긁어 모을 때다!Proxy 세팅을 마쳤으니 브라우저를 연결해야겠죠? 일반적인 방법으로는 연결되지 않습니다. 여기선 크롬 확장 프로그램인 Proxy SwitchyOmega의 도움을 받았습니다. 다운로드는 여기를 클릭하세요.이것은 Proxy 스위칭 프로그램입니다. 도메인 단위로 설정이 가능하기 때문에 on 또는 off 따로 하지 않고도 사용이 가능할 겁니다. 플러그인 설치를 마쳤다면 설정을 유도합시다.Server에는 localhost, Port에는 5555를 적어주세요.캡쳐하고 싶은 사이트에 들어가 Direct 옵션을 켭니다.Proxy를 활성시킵니다.브랜디 주요 도메인인 brandi.co.kr을 클릭해 Proxy를 활성시키면 ***.brandi.co.kr 도메인은 Local Proxy를 타고 넘어가는데요. 이제 받기만 하면 됩니다. (빵끗)진짜 긁어 모아보자!캡쳐하려고 했던 사이트에 접속해 요청을 발생시킵니다.내부 테스트 서버postman native App 캡쳐 내용와우! 발생한 요청 내용이 캡쳐되어서 들어오기 시작합니다.속이 뻥!!!속을 썩이던 한글도 깔끔하게 캡쳐되었군요. 이제 행복한 테스트만 남았습니다. 즐거운 시간 되시길 바랍니다.소소하지만 알찬 팁1: 필터 기능proxy 설정도구에서 필터 기능을 사용하면 원하는 것만 캡쳐할 수 있습니다.소소하지만 알찬 팁2: 테스트 기능스마트폰의 native App은 위와 같이 설정하면 테스트할 수 있습니다. 이제 휴대폰 테스트 결과를 PC로 수집할 수 있을 겁니다. 앱 테스트에 대한 상세 설명은 여기를 클릭하세요.소소하지만 알찬 팁3: 안 쓸 때는..proxy를 안 쓸 때는 System Proxy를 클릭해 끄도록 합시다.1) interceptor는 브라우저 요청을 postman에서 패킷을 캡쳐해주는 도구다.참고Capturing HTTP requests글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #Postman
조회수 1918

Docker, NodeJS, Nginx! 너로 정했다!

편집자 주아래와 같이 용어를 표기하기로 저자와 협의함Docker, NodeJS, NginxOverview안녕하세요. 칼 같은 들여쓰기에 희열을 느끼는 브랜디 개발자 강원우입니다! 서버를 운영해본 개발자라면 Fatal 에러, 아웃오브메모리 에러, 또는 전날 흡수한 알코올로 인해 손을 떨다가 한 번쯤 서버를 요단강 너머로 보내봤을 겁니다. 만약 테스트 서버였다면 잠시 마음을 가다듬으면 되지만, 현재 상용 서비스 중인 서버라면 얘기는 달라집니다.님아, 그 강을 건너지 마오!이런 간담이 서늘해지는 경험은 저 하나로 족합니다. 그래서 고군분투했던 지난 날을 되돌아보면서 빠르고 안정적이며, 죽어도 죽지 않는 좀비 같은 서버 구축 방법을 쓰려고 합니다.준비물서비스를 운영할 때 가장 중요하게 여겨야 하는 건 역시 안정성입니다. 이번 글에서는 오래 전부터 개발 세계의 뜨거운 감자였던 Docker와, 단일 스레드와 이벤트 루프로 태생적으로 심플하고 민첩한 NodeJS, 마지막으로 고성능을 목표로 개발된 Nginx를 활용하겠습니다.1. DockerDocker는 컨테이너 기반의 오픈소스 가상화 플랫폼입니다. 대표적으로 LXC(Linux Container)가 있습니다. 화물 컨테이너처럼 어떠한 일련의 기능을 완전히 격리된 소프트웨어 환경에서 작동하게 만드는 기술을 말합니다.OS 가상화와 별반 다를 게 없는 것 같지만 소프트웨어적으로 작동한다는 차이가 있습니다. 다시 말해, 현재 OS의 자원을 그대로 사용하기 때문에 하이퍼 바이저가 가상환경을 위해 가상의 커널을 만드는 오버헤드가 거의 없다는 것이죠.이미지와 속도도 차이를 보입니다. 완벽하게 구성한 세팅을 그대로 이미지화할 수 있고, 해당 이미지는 Docker 위에서 완벽히 동일하게 동작하는 걸 보장합니다. 해당 이미지로 컨테이너를 제작할 땐 1~2초면 새로운 컨테이너가 생겨날 정도로 엄청나게 빠른 속도도 자랑합니다. 1)또한 Docker는 자주 사용되는 다양한 이미지를 퍼블릭 레포지토리에 공유해 사용할 수 있기도 합니다. 양파도 아닌데 특징이 계속 나오죠? 다음 글에서 Docker의 특징을 더 자세히 다루겠습니다.Docker는 리눅스만 지원했었지만, 요즘은 Docker for Windows와 Docker for Mac으로 거의 모든 OS에서 사용할 수 있습니다. 2) Docker 설치 링크는 윈도우와 맥으로 나뉘어져 있습니다. 리눅스는 아래를 참고하세요.curl -fsSL https://get.docker.com/ | sudo sh 2. NodeJSNodeJS는 구글이 구글 크롬에 사용하려고 제작한 V8 오픈소스 자바스크립트 엔진을 기반으로 제작된 자바스크립트 런타임입니다. NodeJS에는 몇 가지 특징이 있습니다.단일 스레드입니다.비동기 방식입니다.이벤트 루프를 사용합니다NPM이라는 끝내주는 동반자가 있습니다.비유하자면 예전엔 낡은 곡괭이로 큰 돌을 캐내려고 수십 명의 인부가 달라 붙었는데, 지금은 육중한 포크래인으로 거대한 돌을 쑥! 뽑아버리는 것과 비슷합니다. 굉장히 효율적이죠. NodeJS는 단일 스레드의 장점을 극대화하려고 이벤트 루프를 통해 모든 처리를 비동기로 수행합니다. 서버 사이드의 묵직한 CPU들이 빠르게 일을 처리하고 이벤트 루프에 등록된 일을 감지해 다음 작업을 빠르게 수행하는 방식입니다.마지막으로 NPM(Node Package Manager)은 NodeJS에서 사용할 수 있는 다양한 모듈을 관리해주는 프로그램입니다. 도커와 상당히 유사합니다. NodeJS에서는 무언가 기능을 만들기 전에 NPM을 먼저 뒤져보라는 말이 있을 정도로 풍부한 모듈 생태계가 구성되어 있습니다. 이는 로깅이나 날짜 계산 등 생각보다 까다로운 것들을 가져다 사용할 수 있게 도와주기 때문에 개발이 빨라집니다. NodeJS 설치링크는 여기를 클릭하세요. 이 글의 예제에서는 NodeJS의 현재시점 LTS인 codename Carbon버젼을 사용합니다!8.x 버젼이 Active LTS 상태입니다.LTS은 Long Term Support의 약자로 가장 오랜기간 지원하는 버전입니다.우선 서비스 구성을 위해 간단한 NodeJS 어플리케이션을 작성해보겠습니다.첫째, packge.json를 작성합시다.{   "name": "nodejs_tutorial_server",   "version": "0.0.0",  "private": true,   "scripts": {     "start": "node nodejs_tutorial_server.js"   },   "description": "NodeJS Tutorial Server",   "author": {     "name": "WonwooKang"   },   "dependencies": {     "express": "^4.16.3",     "uuid": "^3.2.1"   } } nodejs_tutorial_server.js 파일을 메인으로 실행합니다. HTTP Request를 처리하려면 express를 사용해야 하며, 서버를 구분하려면 uuid모듈이 필요합니다.둘째, package.json의 의존 파일들을 설치합시다.npm install npm install 전npm install 후셋째, 간단한 웹 어플리케이션을 작성합시다.var express = require('express'); var app = express(); const port = 3000;  var server = app.listen(port, function () {     console.log("Express server has started on port : "+port);  });  app.get('/', function (req, res) {     res.send('Hello?');  }); 넷째, package.json의 script start 구문을 실행하여 서버를 로드합시다.npm start 3000번 포트로 서버가 시작되었습니다!접속해볼까요?잘 접속됩니다.그런데 수정할 때마다 서버를 매번 다시 띄우면 귀찮을 겁니다. 이럴 땐 nodemon 모듈을 사용합시다. nodemon은 Nodejs의 파일이 수정되는 걸 감지해 자동으로 리로드해주는 편리한 도구입니다.nodemon설치npm install nodemon -g package.json script 변경"scripts": {     "start": "nodemon nodejs_tutorial_server.js"   }, nodemon 실행확인을 위해 약갼의 수정//nodejs_tutorial_server.js 수정 app.get('/', function(req, res) {     res.send('Hello Nodemon');  }); nodemon을 통해 어플리케이션이 실행된 모습파일수정 후 저장했을 때 자동 감지한 모습서버 잘 떴습니다!성공적으로 단 하나의 GET 요청을 처리할 수 있는 심플한 NodeJS 기반 웹 어플리케이션을 완성했습니다. 이제 웹 어플리케이션을 Docker Container위에서 구동해봅시다!3. Docker로 NodeJS Express 서버 구동하기이제 Docker Container위에서 NodeJS서버를 구동할 건데요. 그러려면 우선 Dockerfile을 작성해야 합니다. 물론 Docker의 이미지를 당겨 받고, 컨테이너를 생성하고, 또 컨테이너를 실행해서 Attach하고, 필요한 파일들을 밀어넣는 등 귀찮은 방법도 있습니다. 하지만 개발자에게 이것은 힘든 작업이므로 Dockerfile을 적극 활용합시다. (Dockerfile의 D는 대문자여야 합니다! 꼭이요)Node 도커 이미지에 어플리케이션 파일을 추가해 실행하는 Dockerfile 작성하기FROM node:carbon MAINTAINER Wonwoo Kang [email protected] #app 폴더 만들기 - NodeJS 어플리케이션 폴더 RUN mkdir -p /app #winston 등을 사용할떄엔 log 폴더도 생성 #어플리케이션 폴더를 Workdir로 지정 - 서버가동용 WORKDIR /app #서버 파일 복사 ADD [어플리케이션파일 위치] [컨테이너내부의 어플리케이션 파일위치] #저는 Dockerfile과 서버파일이 같은위치에 있어서 ./입니다 ADD ./ /app #패키지파일들 받기 RUN npm install #배포버젼으로 설정 - 이 설정으로 환경을 나눌 수 있습니다. ENV NODE_ENV=production #서버실행 CMD node nodejs_tutorial_server.js Dockerfile 내용은 node:carbon에서 :carbon이 NodeJS의 이미지 버전 Tag 입니다.Dockerfile을 통해 docker image 빌드하기docker build –tag 레포지토리명: 태그 Dockerfile 경로docker build --tag node_server:0.0.1 [Dockerfile이 위치하는 경로] 호오... 게이지가 마구마구 차오르는군요?build가 완료된 화면입니다. Dockerfile의 내용 순서가 각 Step별로 진행된 것을 알 수 있습니다.빌드 결과 생성된 이미지 확인하기docker images 빌드 명령어에서 입력했던 버전 태그까지 잘 입력된 것을 알 수 있습니다.NodeJS Carbon 이미지를 기반으로 한 node_server 이미지를 제작했습니다. 사이즈는 둘이 합쳐 1Gb가 넘을 것 같지만 실제로는 변경된 부분만 저장됩니다. 그러므로 node_server 이미지의 크기는 6~10Mb 정도입니다.생성된 이미지로 컨테이너 만들기컨테이너 생성 명령어는 아래와 같습니다.docker create --name [서버명] -p [외부 포트:컨테이너 내부포트] [이미지명:버전태그] 주의할 점이 있습니다. 포트번호 바인딩 중 왼쪽은 우리가 접속할 실제 포트이고, 오른쪽은 컨테이너 내부의 NodeJS서버 할당 포트가 된다는 것입니다. 공유기의 포트포워딩 설정과 같습니다.docker create --name NODE_SERVER_0 -p 3000:3000 node_server:0.0.1 알 수 없는 코드가 생성되었습니다. 응?컨테이너 확인하기생성한 컨테이너를 확인해볼까요?docker ps 어.. 없잖아?옵션을 추가합니다.docker ps -a 나타났다!docker ps 명령어는 현재 실행 중(STATUS:Up)인 컨테이너의 목록을 보여줍니다. -a 옵션은 실행하지 않는 모든 컨테이너를 보여줍니다. 위의 이미지에서 node_server:0.0.1이미지로부터 NODE_SERVER_0 이라는 이름으로 2분 전에 생성되었다는 걸 알 수 있습니다. 3)컨테이너 실행하기docker start NODE_SERVER_0 다시 확인하기docker ps 19초 전에 Up상태가 되었다는 걸 알 수 있다.외부 3000번 포트 -> 내부 3000번 포트로 연결되었습니다. 서버도 실행되었고요! 이제 접속해볼까요?내용도 안 바꾸고 새로고침도 빨라서 뜬 건지 잘 모르겠군요. 내용을 수정해서 다시 확인하겠습니다.//nodejs_tutorial_server.js 수정 app.get('/', function (req, res) {     res.send('Hello I\'m In Docker Container Now!');  }); 파일 변경해서 다시 확인하기//버전 태그도 0.0.2로 업해주고 docker build --tag node_server:0.0.2 [Dockerfile위치] 잘 생성되었습니다.//이미지가 잘 생성되었는지 확인하고 docker images 0.0.2가 나타났습니다.//기존 컨테이너를 삭제합니다. -f 옵션은 실행중인 컨테이너도 강제로 삭제하겠다는 뜻입니다.  docker rm -f NODE_SERVER_0 // 잘지워졌나 확인하고  docker ps -a 잘 지워집니다.//0.0.2 버젼 이미지로 컨테이너를 다시 생성합니다.  docker create --name NODE_SERVER_0 -p 3000:3000 node_server:0.0.2   //서버를 실행합니다. docker start NODE_SERVER_0 잘 실행됩니다.이제 다시 접속해봅시다.안녕! 나 지금 Docker 안에 있어!이제 Docker로 여러 개의 서버를 띄우겠습니다. NodeJS는 싱글 스레드이기 때문에 하나의 CPU를 여럿이 나눠 갖는 건 비효율적입니다. 따라서 CPU 숫자에 맞춰서 서버를 띄워보겠습니다.제 맥북엔 CPU가 4개뿐입니다.CPU수에 맞춰 추가로 생성하기추가로 컨테이너를 생성하고, 서버를 실행합니다. 서버 목록도 확인해야겠죠.서버 생성서버 실행서버 목록 확인포트번호는 같은 포트를 쓸 수 없기 때문에 3001, 3002, 3003으로 매핑합니다. 브라우저로 접속해서 확인해보겠습니다.각 포트별 접속 화면미리 만들어둔 이미지 덕분에 서버 3대를 띄우는 데에 5분도 안 걸렸습니다. 하지만 Docker 서버를 여러 개 띄워도 결국 사람의 손이 닿아야 합니다. 따라서 이번에는 NodeJS의 Cluster를 활용해 적은 수의 Docker Container를 이용하면서도 다수의 CPU를 사용하겠습니다. 또 죽은 워커를 다시 살려 서버가 다운되는 것을 막아 안정적인 서비스도 구축해보겠습니다.4. 멀티코어대응 NodeJS Cluster 구성2컨테이너용 NodeJS Cluster서버 어플리케이션 작성하기var cluster = require('cluster'); var os = require('os'); var uuid = require('uuid'); const port = 3000; //키생성 - 서버 확인용 var instance_id = uuid.v4();  /**  * 워커 생성  */ var cpuCount = os.cpus().length; //CPU 수 var workerCount = cpuCount/2; //2개의 컨테이너에 돌릴 예정 CPU수 / 2  //마스터일 경우 if (cluster.isMaster) {     console.log('서버 ID : '+instance_id);     console.log('서버 CPU 수 : ' + cpuCount);     console.log('생성할 워커 수 : ' + workerCount);     console.log(workerCount + '개의 워커가 생성됩니다\n');        //CPU 수 만큼 워커 생성     for (var i = 0; i < workerCount>         console.log("워커 생성 [" + (i + 1) + "/" + workerCount + "]");         var worker = cluster.fork();     }        //워커가 online상태가 되었을때     cluster.on('online', function(worker) {         console.log('워커 온라인 - 워커 ID : [' + worker.process.pid + ']');     });        //워커가 죽었을 경우 다시 살림     cluster.on('exit', function(worker) {         console.log('워커 사망 - 사망한 워커 ID : [' + worker.process.pid + ']');         console.log('다른 워커를 생성합니다.');                 var worker = cluster.fork();     });  //워커일 경우 } else if(cluster.isWorker) {     var express = require('express');     var app = express();     var worker_id = cluster.worker.id;         var server = app.listen(port, function () {         console.log("Express 서버가 " + server.address().port + "번 포트에서 Listen중입니다.");     });        app.get('/', function (req, res) {         res.send('안녕하세요 저는 워커 ['+ cluster.worker.id+'] 입니다.');     });  } CPU 숫자를 받아 CPU 수(4)를 컨테이너 수(2) 로 나눠 워커를 생성하는 NodeJS 클러스터 구성입니다. 이렇게만 해도 운영에는 무리가 없지만 컨테이너 2개의 구분이 안 되서 확인할 수가 없습니다.그러므로 마스터와 워커의 통신을 이용해 마스터의 uuid를 얻겠습니다. (워커와 마스터 간의 데이터 이동은 통신 말고는 메모리DB 등의 데이터 저장소밖에 없습니다)마스터의 아이디를 알아오는 로직이 추가된 어플리케이션 작성var cluster = require('cluster'); var os = require('os'); var uuid = require('uuid'); const port = 3000; //키생성 - 서버 확인용 var instance_id = uuid.v4();  /**  * 워커 생성  */ var cpuCount = os.cpus().length; //CPU 수 var workerCount = cpuCount/2; //2개의 컨테이너에 돌릴 예정 CPU수 / 2  //마스터일 경우 if (cluster.isMaster) {     console.log('서버 ID : '+instance_id);     console.log('서버 CPU 수 : ' + cpuCount);     console.log('생성할 워커 수 : ' + workerCount);     console.log(workerCount + '개의 워커가 생성됩니다\n');         //워커 메시지 리스너     var workerMsgListener = function(msg){                    var worker_id = msg.worker_id;             //마스터 아이디 요청             if (msg.cmd === 'MASTER_ID') {                 cluster.workers[worker_id].send({cmd:'MASTER_ID',master_id: instance_id});            }      }        //CPU 수 만큼 워커 생성     for (var i = 0; i < workerCount>         console.log("워커 생성 [" + (i + 1) + "/" + workerCount + "]");         var worker = cluster.fork();                //워커의 요청메시지 리스너         worker.on('message', workerMsgListener);     }        //워커가 online상태가 되었을때     cluster.on('online', function(worker) {         console.log('워커 온라인 - 워커 ID : [' + worker.process.pid + ']');     });        //워커가 죽었을 경우 다시 살림     cluster.on('exit', function(worker) {         console.log('워커 사망 - 사망한 워커 ID : [' + worker.process.pid + ']');         console.log('다른 워커를 생성합니다.');                 var worker = cluster.fork();         //워커의 요청메시지 리스너         worker.on('message', workerMsgListener);     });  //워커일 경우 } else if(cluster.isWorker) {     var express = require('express');     var app = express();     var worker_id = cluster.worker.id;     var master_id;        var server = app.listen(port, function () {        console.log("Express 서버가 " + server.address().port + "번 포트에서 Listen중입니다.");     });        //마스터에게 master_id 요청     process.send({worker_id: worker_id, cmd:'MASTER_ID'});     process.on('message', function (msg){         if (msg.cmd === 'MASTER_ID') {             master_id = msg.master_id;         }     });        app.get('/', function (req, res) {         res.send('안녕하세요 저는 ['+master_id+']서버의 워커 ['+ cluster.worker.id+'] 입니다.');    });  } Docker Container에 올리기 전 로컬 테스트를 먼저 진행합니다. 서버 구동!두 개의 워커가 실행되었습니다.똑같은 localhost:3000번 접속이지만 워커의 번호가 다릅니다.이제 워커로 CPU 수만큼 워커를 생성할 수 있게 되었습니다. 이제 워커가 어떻게 안정적으로 서비스되는지 테스트하겠습니다. 워커 킬링 테스트하기워커 킬러 로직 작성//워커 킬링 테스트     app.get("/workerKiller", function (req, res) {         cluster.worker.kill();         res.send('워커킬러 호출됨');     }); 실험에 앞서 똑같은 상황 재연 마스터 아이디를 유심히 봐주세요. 워커 킬러를 실행하겠습니다.워커 킬러 호출아래는 호출된 결과입니다. 하나의 워커가 죽자마자 곧장 다른 워커가 태어나(?) 3000번을 Listen하기 시작했습니다. 워커 킬러가 호출된 화면이제 워커 킬러를 여러 번 호출해보겠습니다. CMD+R을 꾸욱 눌러 연속으로 킬링해봤는데 아래 화면처럼 바로 살아납니다.접속해서 현재 워커를 확인합니다.위의 화면처럼 마스터의 UUID가 그대로인데 워커만 교체되었습니다. 준비는 끝났습니다. 이제 Docker를 이용해 2명의 워커를 가진 2개의 NodeJS서버를 실행하고, 4개의 귀여운 CPU를 불살라봅시다! 5. Docker로 NodeJS Cluster 서버 실행하기docker build --tag node_server:0.0.3 /Users/kww/eclipse-workspace/nodejs-for-article docker create --name NODE_SERVER_0 -p 3000:3000 node_server:0.0.3 docker create --name NODE_SERVER_1 -p 3001:3000 node_server:0.0.3 docker start NODE_SERVER_0 docker start NODE_SERVER_1 cluster가 적용된 2개의 컨테이너 start0.0.3번 이미지로 생성된 2개의 컨테이너 서버가 무사히 로드되었습니다. 이제 접속해서 확인해볼까요?cluster가 적용된 2컨테이너 4서버 구동화면WOW! 2개의 URL, 2개의 UUID, 각 2명의 워커까지. 완벽한 2.2.2입니다. 마치 홍진호를 보는 듯한 서버 현황입니다. 이제 워커 킬러로 습격해보겠습니다.워커 킬러 습격 후위의 이미지를 보면 3000번 포트서버에서 13명, 3001번 포트서버에서 22명의 워커가 사망했습니다. UUID를 통해 2개의 서버에서 일정량의 워커가 매우 안정적으로 서버를 지키고 있는 걸 알 수 있었습니다.지금까지 2개의 컨테이너로 4개의 서버를 구성해보았습니다. CPU 숫자와 나눠지는 수에 따라 컨테이너의 수, NodeJS 클러스터 서버의 수를 유동적으로 조정할 수 있습니다. 전에 운영하던 API서버는 16코어 서버였고, 로드벨런서 및 기타 작업용 1코어의 여분을 남기고 15코어 / 3 으로 5개의 워커를 가진 3개의 NodeJS서버를 도커 컨테이너로 운영했었습니다.여기서 문제점이 생깁니다. 우리는 어떤 서비스를 할 때 하나의 도메인을 쓰는데 포트번호가 2개죠? 어떻게 해야 할까요. 여기서 바로 한참을 기다렸던 불곰국의 Nginx가 등장합니다.6. Nginx로 로드밸런싱 하기Nginx은 “더 적은 자원으로 더 빠르게”를 지향합니다. 러시아의 이고르 시쇼브(Игорь Сысоев)는 Apache에서 10,000개의 접속을 동시에 다루기 힘든 걸 해결하려고 Nginx를 개발합니다.Nginx는 NodeJS와 유사하게 싱글 스레드 방식에 이벤트 드리븐 구조 사용하는 오픈소스 HTTP서버로 최근 아파치의 점유율을 상당히 뺏고 있는 서버입니다. 다운로드 링크를 아래에 써두었습니다.Nginx 설치WindowNginx 다운로드Macbrew install nginx Linuxapt-get install nginx or yum install nginx Nginx 설치 성공Nginx 기본 접속 화면서버 조작방법서버 시작 : nginx 서버 중지 : nginx -s stop 서버 재시작 : nginx -r reload (맥에선 이건 안되는듯?) 기본 설정은 8080포트로 되어있습니다. 원하는 포트르 로드벨런싱 설정을 해보겠습니다. Nginx 로드밸런싱 설정아래는 Nginx의 로드밸런싱입니다.#http블럭 내부에 추가     #NodeJS 서버 로드밸런싱     upstream nodejs_server {         #least_conn;         #ip_hash;         server localhost:3000 weight=10 max_fails=3 fail_timeout=10s;         server localhost:3001 weight=10 max_fails=3 fail_timeout=10s;     }        #3333번 포트 NodeJS 서버로 연결     server{         listen               3333;         server_name  localhost;                location / {             proxy_pass http://nodejs_server;         }     } 로드밸런싱이 잘 적용되었는지 확인해보겠습니다. 로드밸런싱 적용 이후모든 브라우저에서 3333번으로 접속했는데 서로 다른 2개의 서버가 번갈아 접속되고, 워커가 가끔 바뀌는 걸 확인할 수 있습니다. 이번엔 로드밸런서로 워커 킬러를 호출하겠습니다.로드밸런싱 포트인 3333번 포트로 여러 번 호출결과 확인Nginx 로드밸런서가 확실하게 작동하는 걸 확인할 수 있었습니다. 위의 이미지에서 서버가 자꾸 바뀌는 모습을 볼 수 있는데, 이는 세션이 유지되지 않기 때문입니다. 실제 서비스에서는 세션의 유지를 위해 ip_hash 옵션이 꼭 필요합니다.ip_hash : 동일한 IP의 접속은 같은 서버로 접속하도록 하는 옵션입니다.  least_conn : 가장 접속이 적은 서버로 접속을 유도하는 옵션으로 ip_hash와 같이쓰입니다. Conclusion자, 고생하셨습니다. 여기까지 Docker와 NodeJS, Nginx를 이용해 관리하기 쉽고, 일부러 죽여도 죽지 않는 안정적인 서비스 환경을 구축해봤습니다. 한 가지 주의할 점이 있습니다. NodeJS의 Cluster는 죽은 워커를 바로 살리는데 싱글스레드여서 그런지 그 속도가 정말 어마어마합니다. 따라서 NodeJS Cluster를 사용할 땐 여러 핸들링에 신중하세요. 모든 promise에 반드시 catch를 달아 핸들링하고, 오류가 날 것 같은 로직엔 반드시 try - catch를 달아 핸들링을 해야 합니다. 그렇지 않으면 다시 살아나는 워커에 의해 서버의 자원이 고갈될 수 있습니다.예전에 16코어 서버를 운영할 땐 서버 자원에 비해 사용자가 적어서..(눈물) 5워커 2개의 서버만 구동하고 여유를 두었습니다. 그리고 서버 패치가 있을 때 3번째 서버를 대기시켰습니다. 앱에서 업데이트가 완료되는 시점에 Docker Container를 바꿔치기 하는 방식으로 Non-Stop서비스를 운영했죠. 혹시 코어가 빵빵한 여유 서버가 있는데 재빠르고 좀비 같은 서비스를 구성해야 한다면 위와 같은 환경 구축을 강력히 추천합니다. 지금까지 긴 글을 읽어주셔서 감사합니다.ps. 글 쓰다 보니 해가 떴네요. 하하.참고1) 가상 머신은 작은 이미지라도 기가바이트 단위의 사이즈와 Load되기까지 상당한 시간이 소요된다.2) 그러나 Windows의 경우, Hiper-v위에 리눅스를 띄워 도커를 구동한다. Mac에서도 가상 머신 위에서 구동된다. 따라서 성능적인 강점은 리눅스에만 적용된다.3) 도커에서는 NAME 속성을 지어주지 않으면 알아서 이름을 지어주는데 romantic한 단어가 많다.글강원우 과장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유
조회수 861

P2P금융에서 고도의 엔지니어링이 필수적인 이유

지난 8월30일, 매일경제신문이 주최하고 과학기술정보통신부와 금융위원회, 금융감독원이 후원한 매경핀테크어워드2018에서 렌딧이 최우수상을 수상했다. 렌딧이 굳이 이런 경연대회에 참여를 한 이유는 ‘P2P금융산업에서 기술력과 고도의 엔지니어링 파워가 얼마나 중요한 지’를 널리 알리고 싶기 때문이었다.매경핀테크어워드 수상 소식을 들은 후, 엔지니어링팀 렌딧맨들과최근 렌딧은 개발자 채용에 그 어느때보다도 열심이다. 많은 개발자들과 만나 P2P금융산업의 미래와 우리 회사가 하는 일에 대해 설명하고 좋은 개발자를 영입하기 위해 노력하고 있다. 그런데 생각보다 훨씬 더 개발자들에게 P2P금융기업이 어떤 일을 하고 있고, 왜 개발자가 도전할 만한 분야인지 알려져 있지 않다는 사실을 알게 되었다. 이번 글에서는 렌딧이 하는 일을 바탕으로 P2P금융회사에서 왜 고도의 소프트웨어 엔지니어링이 필수적으로 필요하고, 개발자 여러분이 어떤 일에 도전해 볼 수 있는지에 대해 설명해 보려고 한다. 우선 대출과 투자 등 모든 서비스가 기존 금융회사와 달리 온라인 상에서 이루어진다. 특히 렌딧이 집중하고 있는 개인신용 P2P금융의 경우, 대출 심사와 집행, 투자 모집과 운용 등 서비스 전 과정을 100% 온라인, 비대면 서비스로 구축하고 있는 디지털 금융 플랫폼이다.대출 서비스에서는 머신러닝 기반의 대출자 심사평가모델 개발이 핵심적이다. 렌딧이 자체 개발한 렌딧 개인신용평가시스템(Lendit Credit Scoring System)을 예로 들어 보겠다. 신용평가사에서 제공하는 250여가지의 금융 데이터를 순식간에 분석해 모든 대출 신청자마다 개인화 된 적정금리를 산출해 내는 시스템이다. P2P금융기업인 렌딧이 개발한 심사평가모델을 기존 금융권의 심사평가모델과 비교할 때 가장 큰 차이점은, 머신러닝 기법을 사용해 각종 금융 데이터의 최근 12개월 간 트렌드를 분석한다는 점. 이를 통해 보다 정교하게 개인의 신용을 평가해 낸다. 여기에 추가적으로 신용평가사에서 제공하는 사기정보공유(Fraud Bureau)데이터, 직장 신용정보, 상환 정보 등을 종합적으로 반영하고 있다. 최근에는 대출자가 제출하는 신분증 확인 과정에 머신러닝을 적용해 자동화해 나가기 시작했다. 투자 서비스에서는 실시간으로 분산투자 포트폴리오를 추천해 주는 알고리듬이 돌고 있다. 투자자가 투자할 금액을 입력하면 눈깜짝할 사이에 현재 투자 가능한 채권을 조합해 분산투자 포트폴리오를 추천해 주는 시스템이다. 포트폴리오에 조합된 모든 채권에 투자금을 일정한 비율로 고르게 나누어 분산투자할 수 있도록 추천해 주는 것이 특징이다. 렌딧이 개발한 분산투자 시스템은 투자자 1인이 수백~수천개의 채권에 분산하는 것과 동시에, 채권 1개도 평균 1,303명, 최대 3,814명(기준 2018년 6월30일 현재)이 나누어 리스크를 분산하도록 개발되어 있다. 이렇게 분산투자를 시스템적으로 활성화 시키고 있는 덕분에, 현재까지 렌딧의 모든 투자자가 하고 있는 분산투자의 총 누적 건수는 거의 800만 건에 육박하는 수준이다. 점점 더 많은 데이터가 축적되고 있기 때문에, 이러한 데이터를 바탕으로 고객에게 제공할 수 있는 서비스 아이디어도 하루 하루 쌓여 가고 있는 중이다.P2P금융산업이 가장 발전한 시장인 미국의 경우, 최대 규모인 렌딩클럽 한 회사가 미국 개인신용대출 시장 전체의 약 1.5%이상을 차지할만큼 금융 시장을 혁신해 나가고 있다. 렌딧 역시 지난 3년간 빅데이터 분석에 기반한 정교한 신용평가를 통해, 대출 고객의 이자를 총 100억원이 넘게 절약해 드리는 성과를 만들어 냈다. 그간 기존 금융회사들이 만들어 내지 못한 중금리 대출 시장을 스타트업인 렌딧이 활짝 열어낸 것이다.렌딧에서 우리 렌딧맨들과 함께 한국의 금융을 혁신하는 금융 플랫폼을 만들어 가실 엔지니어 여러분을 기다립니다. 관심있는 분은 주저없이 [email protected] 로 연락 주세요. 많은 엔지니어 여러분과 만나뵙고 싶습니다. 
조회수 2010

스켈티인터뷰 / 스켈터랩스의 조깨비 조경희 님을 만나보세요:)

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 조깨비 조경희 님을 만나보세요:)사진1. 스켈터랩스의 조깨비 조경희 님Q. 자기소개를 부탁한다.A. 이름은 조경희, 아이리스 팀에서 소프트웨어 엔지니어로 일하고 있다. 2016년 8월에 입사했으니 이제 스켈터랩스에 합류한 지도 2년이 훌쩍 넘었다.Q. 맡고있는 업무를 설명한다면?A. 우리 팀은 일종의 실시간 맥락 인식(Context Recognition) 기술을 개발하고 있다. 다양한 종류의 맥락 인식이 있겠지만, 현재 우리는 모바일 기기를 주요 디바이스로 삼고있다. 핸드폰을 통해 사용자의 다양한 정보를 수집하고, 우리의 기술이 알아서 사용자의 취향이라던지 성향, 좋아하는 음식부터 음악까지 다양한 정보를 여러 시그널을 바탕으로 추론하고자 한다. 이후에는 사용자에 딱 맞는 ‘추천'까지 제공하는 기술을 개발하는 것이 목표다.Q. 핸드폰 하나로 사용자의 다양한 정보를 수집하고 추론할 수 있다는 부분이 신기하다. 조금 더 자세히 얘기해줄 수 있나.A. 가령 내가 안드로이드 사용자라고 가정해보자. 우리가 택시를 부를 때 흔히 사용하는 것 처럼 내가 현재 위치한 곳을, 즉 장소 정보를 핸드폰은 알아서 수집하고 있다. 우리는 장소를 비롯하여 와이파이나 사운드, 배터리, 자이로센서 등으로부터 시그널을 수집하고, 스트리밍 프로세싱 엔진에 송출한다. 그럼 그 엔진에서 실시간으로 이러한 스트림(정보)를 받고, 받은 데이터를 조합하여 새로운 데이터로 변환한 후 다음 단계를 추론하다. 내가 만일 아침 9시쯤에는 항상 일정한 A라는 장소로 이동하고 있고, A 장소로 이동하는 길목에서 카페에 들러 커피를 한 잔 사는 일과를 가지고 있다면, ‘A는 사용자의 회사이고, 사용자는 출근하기 전 커피를 마시기를 즐기는 사람이다'라고 추론할 수 있다. 우리는 이러한 상황에 대한 추론을 바탕으로, 조금 더 고차원적인 추론을 하거나, 사용자의 취향 및 패턴을 찾는 기술을 개발하고 있다. 궁극적으로는 <아이언맨>에 등장하는 자비스(JARVIS)와 같은 퍼스널 어시스턴트(Personal Assistant)를 세상에 내보이고 싶다. 사실 자비스는 어디까지나 영화 속의 상상이 많이 묻어있고, 현재로서는 갈 길이 멀기도 하다. 하지만 현재 스켈터랩스는 음성 인식이나 이미지(Vision), 챗봇과 같은 다양한 프로젝트를 동시에 진행하고 있으며 각각의 기술력도 뛰어나다. 이 여러가지 기술이 총체적으로 구현된 서비스가 탄생한다면, 일상을 혁신적으로 바꿀 것이라고 생각한다. Q. 지금까지의 개발 상황을 살짝 공개하자면?A. 시장에 공개한 것을 기준으로 하자면, 일단 베타 버전으로 런칭한 앱 서비스 ‘큐(CUE)’ 이야기를 하고 싶다. 간단한 상황 인식을 통해 사용자에게 추천을 제공한다. 가령 강수량이 높게 예고된 날에는 ‘우산 챙겨가'라고 카드를 띄워준다거나, 라면을 즐겨 먹는 사용자에게 ‘오늘은 라면 대신 건강한 샐러드 어때?’라고 말해주기도 한다. 사실 큐에 대한 사용자의 의견은 정말 가지각색이었다. 날씨 예보를 기반으로 한 추천의 경우 ‘너무 뻔해서 의미가 없는 것 같다’ 라고 생각하는 사용자가 있는 반면, 출근 직전과 같은 적시에 카드가 알아서 추천해주니 매우 편하게 느꼈다는 사용자도 있었다. 결국 나는 상황 인식이 사용자에게 유용한 서비스로 와닿기 위해서는 ‘정확성'이 큰 척도라고 생각한다. 적시에, 적절한 장소에서, 나에게 꼭 맞는 추천을 해주는 것, 이를 위해서는 사용자를 정확하게 파악하는 것이 우선되어야 하기 때문이다. 지금까지의 개발이 상황 정보를 적절하게 받을 수 있는 플랫폼 구축 중심이었다면, 현재는 더 자세한 상황을 찾는 쪽으로 초점이 맞추어져 있다. 가령 사용자가 ‘지하철을 타고 이동한다'가 아니라, ‘어느 역에서 지하철에 탑승하여 어느 역에서 내렸다'까지 인식할 수 있는 것이다. 음악도 마찬가지다. 음악과 같이 엔터테인먼트 컨텐츠의 경우 단순히 ‘음악을 듣고 있다'라는 정보가 아니라, 취향 정보가 중요하다. 때문에 ‘어떤 가수의 어떤 음악을 들었다'까지 인식하여 이를 조합한 추론을 만들려고 한다.사진2. 사내 Tech Talk 세미나를 진행하고 있는 경희님Q. 큐의 베타 서비스를 런칭하며 팀원들끼리 자축하던 장면이 떠오른다. 굉장히 뿌듯한 경험이었을 것 같다.A. 나는 사실 뿌듯함 보다는 ‘갈 길이 멀다'라는 생각을 먼저 했다. 베타 버전이기도 했고, 개발한 우리 스스로도 정확성이 기대에 미치지 못하고 있다고 생각했다. 그럼에도 불구하고 런칭을 결정한 이유는 명확하다. 다양한 사용자가 큐를 통해 어떤 경험을 얻고, 어떻게 느끼는지 들어야만 더욱 사용자의 핏에 맞는 정식 버전을 제대로 개발할 수 있을 것이라고 판단했기 때문이다. 모든 서비스가 마찬가지겠지만 나는 큐야 말로 많은 사용자와 함께 만들어가는 서비스라고 생각한다.Q. 경희님 개인의 이야기를 들어보고 싶다. 스켈터랩스에 어떻게 합류하게 되었는가.A. 스켈터랩스의 CTO인 조성진 님과 같은 연구실에서 일했다. 연구를 마친 후 나는 전문연구요원으로 다른 회사에서 일을 했고, 성진님은 구글에 입사한 것으로만 알고 있었는데, 구글을 나와서 회사를 차렸다는 얘기를 듣게되었다. 그때만 해도 대기업이 주는 안정감을 놓칠 수 없어 대기업에 머물러있었다. 하지만 성진님을 자주 만나 스켈터랩스의 프로젝트가 어떠한 방향으로 구체화되고 있는지 들을수록 매력적으로 와닿았다. 대기업의 경우 조직의 구조 때문에 어쩔 수 없이 쪼개진 일에 집중하게 된다. 하지만 스켈터랩스는 구성원들 모두가 자발적으로 참여하여 방향성을 결정 짓고, 개발 환경을 선진적으로 꾸리고 있다는 점도 좋았다. 이러한 요소가 결국 스켈터랩스로의 이직을 결정지었던 것 같다.Q. 스켈터랩스로 이직하여 얻은 가장 큰 성취를 꼽자면?개인적으로 코드리뷰 문화를 통한 개발 실력의 발전을 꼽고 싶다. 다른 조직에서는 다른 사람이 내 코드를 봐주고, 평가하는 것이 마치 자존심 싸움처럼 여겨지곤 했다. 타인의 코드는 일종의 침범할 수 없는 ‘불가침 영역'으로 인식되었다. 하지만 스켈터랩스에서는 코드리뷰가 너무나도 당연하다. 다른 사람에게 코드를 보여주고, 내 코드가 더욱 효율적으로 작동할 수 있도록 바꾸어주는 것이 자연스럽게 이루어지고 있다. 이 과정을 통해 코드를 리뷰하는 사람도, 리뷰받는 사람도 모두가 윈윈(win-win)할 수 있다. 코드리뷰 문화가 익숙하지 않은 사람에게는 이 문화가 마치 일의 효율을 저해하는 것 처럼 여겨질 수 있다. 그러나 결론적으로는 목표에 닿기 위한 가장 빠른 방법이라고 생각한다. 확실히 여러 개발자의 리뷰를 거칠수록, 버그는 적어지고 개인의 실력이 향상될 뿐더러 시야도 넓어질 수 있기 때문이다. 나 또한 같은 경험을 했다. 스켈터랩스에서 몇 개월 근무한 후, 내가 이전에 짜놓은 코드를 보면 ‘어떻게 이렇게 짜놓았지' 싶을 때가 있다. 개발 실력에 관한 이러한 성취를 정량적으로 판단할 수 는 없지만, 회사와 개인이 모두 발전할 수 있는 가장 의미있는 성취라고 생각한다.Q. 반대로 스켈터랩스에서 개발을 하며 가장 어려운 점은 무엇이 있을까.개발 자체에 대한 어려움보다는 방향성에 대한 어려움이 있다. 인공지능이라는 분야는 워낙 넓기도 하고, 상황인식 기술의 경우 근래에 크게 발전하고 있는 것은 맞지만, 세부 기술에 대해서는 시장 자체가 뚜렷하지 않다. 참고할만한 제품도, 경쟁사도 없기 때문에 새로운 시장을 만들어내는 것에 대한 부담이 있다. 언뜻 보기에는 경쟁사가 크게 없는 니치마켓(Niche market)처럼 여겨질 수 있지만, 기술을 쪼개고 쪼개어 들여다보면 하나의 기술을 바탕으로 각각 다른 사용자와 상황을 타깃으로 변주한 다양한 서비스가 등장하는 상황이다. 이러한 기술을 마냥 뭉뚱그린다면 기술에 대한 깊이가 얕아질 수 있고, 특정 상황과 사용자에게만 집중한다면 타깃이 좁아질 위험이 있다. 때문에 시장과 사용자에 대해 매 순간 유추하며 적절한 균형을 가지고 개발을 진행할 수 있도록 노력하고 있다. 사진3. 프로젝트 별 Sync-up 미팅, 짧은 미팅을 통해 업무 효율을 높이고 있다Q. 스켈터랩스의 개발 문화가 타 기업과 확고하게 다르다고 느낀 사례가 있다면, 그 이야기를 구체적으로 듣고싶다.A. 두 가지를 꼽고 싶다. 첫 번째는, 다른 분들도 많이 얘기했을 것 같지만 역시 와 다. 각각 상반기와 하반기에 한 번 씩, 하는 일을 모두 멈추고 일주일 간 원하는 개발에 집중하는 일종의 해커톤이다. 내가 입사한 날이 Demo Days 시작 이틀 전이었다. 입사하자마자 부랴부랴 팀을 만들고, 아이디어를 구체화하여 개발에 매달렸다. Demo Days 기간 내내 팀원들이 밤을 새워가며 개발에 매달리는데, ‘매일 이렇게 일하는 곳인가' 라는 두려움과 ‘이렇게 뛰어난 개발자들이 집중하니까 뚝딱 서비스가 나올 수 있구나'라는 재미를 동시에 느꼈다. 그 기간이 끝나고 보니 역시 매일 그렇게 일하는 것은 아니었다. 일주일 간 그토록 밤을 세워 개발을 할 수 있는 원동력은 ‘내가 원하는 서비스를 직접 만들어볼 수 있다'라는 흥미와 ‘최종 발표일에 어설픈 개발로 쪽팔리고 싶지 않다'라는 감정인 것 같다. 매일 하는 업무에서 벗어나 리프레쉬 할 수 있는 재미요소도 크다. 그 기간의 우리 성과를 돌아보면, 이토록 개발을 사랑하고 기대 수준이 높은 사람들이 모여있으니, 뭘 하던 성공할 것이라는 일종의 확신을 얻을 수 있다. 두 번째는 ‘빠르다'라는 점이다. 새로운 아이디어나 기술에 대해 흥미가 생겼을 때 쉽고 빠르게 팀을 꾸릴 수 있다. 그렇기 때문에 자연스럽게 자신의 흥미와 역량에 맞는 팀을 찾아 이동하는 것도 매우 자발적으로, 빠르게 이루어진다. 오픈 소스 사용도 빠르다. 새로운 기술이나 제품을 들여다보고 싶다면, 그냥 진행해 볼 수 있다. 기존의 큰 회사들은 수직적으로 팀장 급에서 업무를 할당하고 시일에 맞추어 개발을 진행하다 보니, 속도 자체는 빠를 수 있지만 허술한 부분이 생기기 마련이고 새로운 기술을 도입에 있어서도 조심스럽다. 하지만 스켈터랩스에서는 ‘빨리 도입하고 빨리 경험해보자’ 라는 의식을 공통적으로 가지고있다.Q. 개발자는 개발이 막히는 순간도 종종 맞닥뜨릴 것 같다. 그럴 때 어떻게 해결하는지 자신만의 팁을 공유한다면.A. 고민의 양이 아니라, 그저 고민의 끈을 놓지 않고 있는 것이 중요한 것 같다. 나는 개발이 막혔을 때 스트레스를 꽤 많이 받는 편이다. 한 번 막히면 맥주를 마시면서도, 밥을 먹으면서도 항상 머리 한 구석에는 개발 고민을 이어간다. 꿈에서도 하도 코딩을 한 탓에, 와이프가 어느 날 “어젯 밤에도 ‘테스트 코드는 이렇게 해야지’ 라는 잠꼬대 하던데?”라고 말할 정도다. 그러다 신기하게도 개발을 아무 것도 모르는 제 3자와 얘기하다가 번뜩 방법이 떠오르곤 한다. 지극히 일상의 순간, 가령 샤워를 한다거나 멍하니 지하철을 타다가 해결책을 찾기도 한다. 이 방법이 훌륭한 팁은 아닐 수 있지만, 포기하는 것이 아니라 개발에 대한 고민을 놓지않는 것이 중요하다는 얘기를 전하고 싶다.사진4. 경희 님과 아내 분의 투샷Q. 경희님이 회사에서 종종 드라마 얘기를 하는 것을 들었다. 드라마를 많이 보는 편인가, 하루 일과를 듣고 싶다.A. 예전에는 <와우>라는 게임을 정말 많이했다. 덕분에 게임 동호회에도 가입해있는데, 요즘에는 <오버워치>나 <클래시로얄> 정도만 즐기고 있다. 결혼하고 와이프와 시간을 함께 보내면서, TV 시청이 늘었다. 와이프가 워낙 TV를 좋아하기도 하고 함께 집에서 시간을 보낼 수 있는 가장 편리한 방법인 것 같기도 하다. 하루 일과는 그래도 일찍 시작하는 편이다. 와이프는 일곱시 쯤 일어나 출근하는데, 나도 보통은 맞춰서 함께 일어난다. 재택근무를 할 수 있는 환경이다보니, 오전에는 주로 집에서 코딩을 하며 개발에 집중한다. 보통 점심 때 출근을 하거나, 미팅에 맞추어 출근하는 편인데, 오후 시간은 미팅과 개발 모두를 병행해서 꽤 정신 없이 하루가 흘러가는 것 같다.사진5. 게임동호회에 가입하면, 회사의 지원을 받아 게임을 즐길 수 있다.Q. 스켈터랩스에서 이루고 싶은 것을 듣고싶다.A. 나의 꿈이 원래 ‘내가 개발한 기술이나 제품이 최대한 많은 사람에게 편리함을 주는 것'이었다. 우연히도 스켈터랩스의 미션인 “언제 어디서나 우리의 일상을 이해하고, 도와주고, 더 나아지게 하는 머신 인텔리전스의 혁신을 이룬다”와 일치하더라. 덕분에 내 꿈을 이루어나가는 것과 스켈터랩스가 혁신적인 기술을 바탕으로 성장하는 것은 궤를 같이한다. 그것이 내가 스티브잡스 처럼 특정 분야의 스타가 되는 것을 뜻하지는 않는다. 연속성이 있고 확장성이 있는 기술로 우리의 일상을 조금씩 더욱 편리하게 가꾸어나가고 싶다.Q. 마지막 질문이다. 스켈터랩스에 바라는 점이 있다면 무엇인가.A. 내가 입사했을 때만 해도 20명 정도에 불과했던 인원이 현재는 70여 명으로 늘었다. 체감상 인원이 조금씩 느는 것이 아니라 순간적으로 확 늘어나는 시기가 있는 것 같다. 그 때마다 약간의 침체기랄까, 분위기가 변하는 모습이 감지된다. 예전에는 사람이 적기 때문에 자연스레 커뮤니케이션이 자율적이이었지만, 사람이 늘어난 만큼 제한적인 커뮤니케이션 모습을 종종 발견할 수 있었다. 이러한 문제 의식의 발로로 컬쳐커미티(Culture Committee)가 생겨났다. 커미티의 활동 덕분에 매주 1:1로 커피를 마실 수 있는 커피믹스와 같은 제도도 신설되었다. 이렇듯 지속적으로 우리만의 모습을 유지하기 위한 노력이 지속되었으면 좋겠다. “우리는 답을 찾을 것이다. 늘 그랬듯이”, 흔한 명대사지만 스켈터랩스 또한 내부적으로도, 외부적으로 늘 답을 찾아가길 바란다. 물론 나 또한 그 답을 찾는 여정에 함께할 테지만 말이다.
조회수 3256

Attention is all you need paper 뽀개기

이번 포스팅에서는 포자랩스에서 핵심적으로 쓰고 있는 모델인 transformer의 논문을 요약하면서 추가적인 기법들도 설명드리겠습니다.Why?Long-term dependency problemsequence data를 처리하기 위해 이전까지 많이 쓰이던 model은 recurrent model이었습니다. recurrent model은 t번째에 대한 output을 만들기 위해, t번째 input과 t-1번째 hidden state를 이용했습니다. 이렇게 한다면 자연스럽게 문장의 순차적인 특성이 유지됩니다. 문장을 쓸 때 뒤의 단어부터 쓰지 않고 처음부터 차례차례 쓰는 것과 마찬가지인것입니다.하지만 recurrent model의 경우 많은 개선점이 있었음에도 long-term dependency에 취약하다는 단점이 있었습니다. 예를 들어, “저는 언어학을 좋아하고, 인공지능중에서도 딥러닝을 배우고 있고 자연어 처리에 관심이 많습니다.”라는 문장을 만드는 게 model의 task라고 해봅시다. 이때 ‘자연어’라는 단어를 만드는데 ‘언어학’이라는 단어는 중요한 단서입니다.그러나, 두 단어 사이의 거리가 가깝지 않으므로 model은 앞의 ‘언어학’이라는 단어를 이용해 자연어’라는 단어를 만들지 못하고, 언어학 보다 가까운 단어인 ‘딥러닝’을 보고 ‘이미지’를 만들 수도 있는 거죠. 이처럼, 어떤 정보와 다른 정보 사이의 거리가 멀 때 해당 정보를 이용하지 못하는 것이 long-term dependency problem입니다.recurrent model은 순차적인 특성이 유지되는 뛰어난 장점이 있었음에도, long-term dependency problem이라는 단점을 가지고 있었습니다.이와 달리 transformer는 recurrence를 사용하지 않고 대신 attention mechanism만을 사용해 input과 output의 dependency를 포착해냈습니다.Parallelizationrecurrent model은 학습 시, t번째 hidden state를 얻기 위해서 t-1번째 hidden state가 필요했습니다. 즉, 순서대로 계산될 필요가 있었습니다. 그래서 병렬 처리를 할 수 없었고 계산 속도가 느렸습니다.하지만 transformer에서는 학습 시 encoder에서는 각각의 position에 대해, 즉 각각의 단어에 대해 attention을 해주기만 하고, decoder에서는 masking 기법을 이용해 병렬 처리가 가능하게 됩니다. (masking이 어떤 것인지는 이후에 설명해 드리겠습니다)Model ArchitectureEncoder and Decoder structureencoder는 input sequence (x1,...,xn)<math>(x1,...,xn)</math>에 대해 다른 representation인 z=(z1,...,zn)<math>z=(z1,...,zn)</math>으로 바꿔줍니다.decoder는 z를 받아, output sequence (y1,...,yn)<math>(y1,...,yn)</math>를 하나씩 만들어냅니다.각각의 step에서 다음 symbol을 만들 때 이전에 만들어진 output(symbol)을 이용합니다. 예를 들어, “저는 사람입니다.”라는 문장에서 ‘사람입니다’를 만들 때, ‘저는’이라는 symbol을 이용하는 거죠. 이런 특성을 auto-regressive 하다고 합니다.Encoder and Decoder stacksEncoderN개의 동일한 layer로 구성돼 있습니다. input $x$가 첫 번째 layer에 들어가게 되고, layer(x)<math>layer(x)</math>가 다시 layer에 들어가는 식입니다.그리고 각각의 layer는 두 개의 sub-layer, multi-head self-attention mechanism과 position-wise fully connected feed-forward network를 가지고 있습니다.이때 두 개의 sub-layer에 residual connection을 이용합니다. residual connection은 input을 output으로 그대로 전달하는 것을 말합니다. 이때 sub-layer의 output dimension을 embedding dimension과 맞춰줍니다. x+Sublayer(x)<math>x+Sublayer(x)</math>를 하기 위해서, 즉 residual connection을 하기 위해서는 두 값의 차원을 맞춰줄 필요가 있습니다. 그 후에 layer normalization을 적용합니다.Decoder역시 N개의 동일한 layer로 이루어져 있습니다.encoder와 달리 encoder의 결과에 multi-head attention을 수행할 sub-layer를 추가합니다.마찬가지로 sub-layer에 residual connection을 사용한 뒤, layer normalization을 해줍니다.decoder에서는 encoder와 달리 순차적으로 결과를 만들어내야 하기 때문에, self-attention을 변형합니다. 바로 masking을 해주는 것이죠. masking을 통해, position i<math>i</math> 보다 이후에 있는 position에 attention을 주지 못하게 합니다. 즉, position i<math>i</math>에 대한 예측은 미리 알고 있는 output들에만 의존을 하는 것입니다.위의 예시를 보면, a를 예측할 때는 a이후에 있는 b,c에는 attention이 주어지지 않는 것입니다. 그리고 b를 예측할 때는 b이전에 있는 a만 attention이 주어질 수 있고 이후에 있는 c는 attention이 주어지지 않는 것이죠.Embeddings and Softmaxembedding 값을 고정시키지 않고, 학습을 하면서 embedding값이 변경되는 learned embedding을 사용했습니다. 이때 input과 output은 같은 embedding layer를 사용합니다.또한 decoder output을 다음 token의 확률로 바꾸기 위해 learned linear transformation과 softmax function을 사용했습니다. learned linear transformation을 사용했다는 것은 decoder output에 weight matrix W<math>W</math>를 곱해주는데, 이때 W<math>W</math>가 학습된다는 것입니다.Attentionattention은 단어의 의미처럼 특정 정보에 좀 더 주의를 기울이는 것입니다.예를 들어 model이 수행해야 하는 task가 번역이라고 해봅시다. source는 영어이고 target은 한국어입니다. “Hi, my name is poza.”라는 문장과 대응되는 “안녕, 내 이름은 포자야.”라는 문장이 있습니다. model이 이름은이라는 token을 decode할 때, source에서 가장 중요한 것은 name입니다.그렇다면, source의 모든 token이 비슷한 중요도를 갖기 보다는 name이 더 큰 중요도를 가지면 되겠죠. 이때, 더 큰 중요도를 갖게 만드는 방법이 바로 attention입니다.Scaled Dot-Product Attention해당 논문의 attention을 Scaled Dot-Product Attention이라고 부릅니다. 수식을 살펴보면 이렇게 부르는 이유를 알 수 있습니다.Attention(Q,K,V)=softmax(QKT√dk)V<math>Attention(Q,K,V)=softmax(QKTdk)V</math>먼저 input은 dk<math>dk</math> dimension의 query와 key들, dv<math>dv</math> dimension의 value들로 이루어져 있습니다.이때 모든 query와 key에 대한 dot-product를 계산하고 각각을 √dk<math>dk</math>로 나누어줍니다. dot-product를 하고 √dk<math>dk</math>로 scaling을 해주기 때문에 Scaled Dot-Product Attention인 것입니다. 그리고 여기에 softmax를 적용해 value들에 대한 weights를 얻어냅니다.key와 value는 attention이 이루어지는 위치에 상관없이 같은 값을 갖게 됩니다. 이때 query와 key에 대한 dot-product를 계산하면 각각의 query와 key 사이의 유사도를 구할 수 있게 됩니다. 흔히 들어본 cosine similarity는 dot-product에서 vector의 magnitude로 나눈 것입니다. √dk<math>dk</math>로 scaling을 해주는 이유는 dot-products의 값이 커질수록 softmax 함수에서 기울기의 변화가 거의 없는 부분으로 가기 때문입니다.softmax를 거친 값을 value에 곱해준다면, query와 유사한 value일수록, 즉 중요한 value일수록 더 높은 값을 가지게 됩니다. 중요한 정보에 더 관심을 둔다는 attention의 원리에 알맞은 것입니다.Multi-Head Attention위의 그림을 수식으로 나타내면 다음과 같습니다.MultiHead(Q,K,V)=Concat(head1,...,headh)WO<math>MultiHead(Q,K,V)=Concat(head1,...,headh)WO</math>where headi=Attention(QWQi,KWKi,VWVi)dmodel<math>dmodel</math> dimension의 key, value, query들로 하나의 attention을 수행하는 대신 key, value, query들에 각각 다른 학습된 linear projection을 h번 수행하는 게 더 좋다고 합니다. 즉, 동일한 Q,K,V<math>Q,K,V</math>에 각각 다른 weight matrix W<math>W</math>를 곱해주는 것이죠. 이때 parameter matrix는 WQi∈Rdmodelxdk,WKi∈Rdmodelxdk,WVi∈Rdmodelxdv,WOi∈Rhdvxdmodel<math>WiQ∈Rdmodelxdk,WiK∈Rdmodelxdk,WiV∈Rdmodelxdv,WiO∈Rhdvxdmodel</math>입니다.순서대로 query, key, value, output에 대한 parameter matrix입니다. projection이라고 하는 이유는 각각의 값들이 parameter matrix와 곱해졌을 때 dk,dv,dmodel<math>dk,dv,dmodel</math>차원으로 project되기 때문입니다. 논문에서는 dk=dv=dmodel/h<math>dk=dv=dmodel/h</math>를 사용했는데 꼭 dk<math>dk</math>와 dv<math>dv</math>가 같을 필요는 없습니다.이렇게 project된 key, value, query들은 병렬적으로 attention function을 거쳐 dv<math>dv</math>dimension output 값으로 나오게 됩니다.그 다음 여러 개의 head<math>head</math>를 concatenate하고 다시 projection을 수행합니다. 그래서 최종적인 dmodel<math>dmodel</math> dimension output 값이 나오게 되는거죠.각각의 과정에서 dimension을 표현하면 아래와 같습니다.*dQ,dK,dV<math>dQ,dK,dV</math>는 각각 query, key, value 개수Self-Attentionencoder self-attention layerkey, value, query들은 모두 encoder의 이전 layer의 output에서 옵니다. 따라서 이전 layer의 모든 position에 attention을 줄 수 있습니다. 만약 첫번째 layer라면 positional encoding이 더해진 input embedding이 됩니다.decoder self-attention layerencoder와 비슷하게 decoder에서도 self-attention을 줄 수 있습니다. 하지만 i<math>i</math>번째 output을 다시 i+1<math>i+1</math>번째 input으로 사용하는 auto-regressive한 특성을 유지하기 위해 , masking out된 scaled dot-product attention을 적용했습니다.masking out이 됐다는 것은 i<math>i</math>번째 position에 대한 attention을 얻을 때, i<math>i</math>번째 이후에 있는 모든 position은 Attention(Q,K,V)=softmax(QKT√dk)V<math>Attention(Q,K,V)=softmax(QKTdk)V</math>에서 softmax의 input 값을 −∞<math>−∞</math>로 설정한 것입니다. 이렇게 한다면, i<math>i</math>번째 이후에 있는 position에 attention을 주는 경우가 없겠죠.Encoder-Decoder Attention Layerquery들은 이전 decoder layer에서 오고 key와 value들은 encoder의 output에서 오게 됩니다. 그래서 decoder의 모든 position에서 input sequence 즉, encoder output의 모든 position에 attention을 줄 수 있게 됩니다.query가 decoder layer의 output인 이유는 query라는 것이 조건에 해당하기 때문입니다. 좀 더 풀어서 설명하면, ‘지금 decoder에서 이런 값이 나왔는데 무엇이 output이 돼야 할까?’가 query인 것이죠.이때 query는 이미 이전 layer에서 masking out됐으므로, i번째 position까지만 attention을 얻게 됩니다.이 같은 과정은 sequence-to-sequence의 전형적인 encoder-decoder mechanisms를 따라한 것입니다.*모든 position에서 attention을 줄 수 있다는 게 이해가 안되면 링크를 참고하시기 바랍니다.Position-wise Feed-Forward Networksencoder와 decoder의 각각의 layer는 아래와 같은 fully connected feed-forward network를 포함하고 있습니다.position 마다, 즉 개별 단어마다 적용되기 때문에 position-wise입니다. network는 두 번의 linear transformation과 activation function ReLU로 이루어져 있습니다.FFN(x)=max(0,xW1+b1)W2+b2x<math>x</math>에 linear transformation을 적용한 뒤, ReLU(max(0,z))<math>ReLU(max(0,z))</math>를 거쳐 다시 한번 linear transformation을 적용합니다.이때 각각의 position마다 같은 parameter W,b<math>W,b</math>를 사용하지만, layer가 달라지면 다른 parameter를 사용합니다.kernel size가 1이고 channel이 layer인 convolution을 두 번 수행한 것으로도 위 과정을 이해할 수 있습니다.Positional Encodingtransfomer는 recurrence도 아니고 convolution도 아니기 때문에, 단어의sequence를 이용하기 위해서는 단어의 position에 대한 정보를 추가해줄 필요가 있었습니다.그래서 encoder와 decoder의 input embedding에 positional encoding을 더해줬습니다.positional encoding은 dmodel<math>dmodel</math>(embedding 차원)과 같은 차원을 갖기 때문에 positional encoding vector와 embedding vector는 더해질 수 있습니다.논문에서는 다른 *frequency를 가지는 sine과 cosine 함수를 이용했습니다.*주어진 구간내에서 완료되는 cycle의 개수PE(pos,2i)=sin(pos/100002i/dmodel)<math>PE(pos,2i)=sin(pos/100002i/dmodel)</math>PE(pos,2i+1)=cos(pos/100002i/dmodel)<math>PE(pos,2i+1)=cos(pos/100002i/dmodel)</math>pos<math>pos</math>는 position ,i<math>i</math>는 dimension 이고 주기가 100002i/dmodel⋅2π<math>100002i/dmodel⋅2π</math>인 삼각 함수입니다. 즉, pos<math>pos</math>는 sequence에서 단어의 위치이고 해당 단어는 i<math>i</math>에 0부터 dmodel2<math>dmodel2</math>까지를 대입해 dmodel<math>dmodel</math>차원의 positional encoding vector를 얻게 됩니다. k=2i+1<math>k=2i+1</math>일 때는 cosine 함수를, k=2i<math>k=2i</math>일 때는 sine 함수를 이용합니다. 이렇게 positional encoding vector를 pos<math>pos</math>마다 구한다면 비록 같은 column이라고 할지라도 pos<math>pos</math>가 다르다면 다른 값을 가지게 됩니다. 즉, pos<math>pos</math>마다 다른 pos<math>pos</math>와 구분되는 positional encoding 값을 얻게 되는 것입니다.PEpos=[cos(pos/1),sin(pos/100002/dmodel),cos(pos/10000)2/dmodel,...,sin(pos/10000)]<math>PEpos=[cos(pos/1),sin(pos/100002/dmodel),cos(pos/10000)2/dmodel,...,sin(pos/10000)]</math>이때 PEpos+k<math>PEpos+k</math>는 PEpos<math>PEpos</math>의 linear function으로 나타낼 수 있습니다. 표기를 간단히 하기 위해 c=100002idmodel<math>c=100002idmodel</math>라고 해봅시다. sin(a+b)=sin(a)cos(b)+cos(a)sin(b)<math>sin(a+b)=sin(a)cos(b)+cos(a)sin(b)</math>이고 cos(a+b)=cos(a)cos(b)−sin(a)sin(b)<math>cos(a+b)=cos(a)cos(b)−sin(a)sin(b)</math> 이므로 다음이 성립합니다.PE(pos,2i)=sin(posc)<math>PE(pos,2i)=sin(posc)</math>PE(pos,2i+1)=cos(posc)<math>PE(pos,2i+1)=cos(posc)</math>PE(pos+k,2i)=sin(pos+kc)=sin(posc)cos(kc)+cos(posc)sin(kc)=PE(pos,2i)cos(kc)+cos(posc)sin(kc)<math>PE(pos+k,2i)=sin(pos+kc)=sin(posc)cos(kc)+cos(posc)sin(kc)=PE(pos,2i)cos(kc)+cos(posc)sin(kc)</math>PE(pos+k,2i+1)=cos(pos+kc)=cos(posc)cos(kc)−sin(posc)sin(kc)=PE(pos,2i+1)cos(kc)−sin(posc)sin(kc)<math>PE(pos+k,2i+1)=cos(pos+kc)=cos(posc)cos(kc)−sin(posc)sin(kc)=PE(pos,2i+1)cos(kc)−sin(posc)sin(kc)</math>이런 성질 때문에 model이 relative position에 의해 attention하는 것을 더 쉽게 배울 수 있습니다.논문에서는 학습된 positional embedding 대신 sinusoidal version을 선택했습니다. 만약 학습된 positional embedding을 사용할 경우 training보다 더 긴 sequence가 inference시에 입력으로 들어온다면 문제가 되지만 sinusoidal의 경우 constant하기 때문에 문제가 되지 않습니다. 그냥 좀 더 많은 값을 계산하기만 하면 되는거죠.Trainingtraining에 사용된 기법들을 알아보겠습니다.Optimizer많이 쓰이는 Adam optimizer를 사용했습니다.특이한 점은 learning rate를 training동안 고정시키지 않고 다음 식에 따라 변화시켰다는 것입니다.lrate=d−0.5model⋅min(step_num−0.5,step_num⋅warmup_steps−1.5)warmup_step<math>warmup_step</math>까지는 linear하게 learning rate를 증가시키다가, warmup_step<math>warmup_step</math> 이후에는 step_num<math>step_num</math>의 inverse square root에 비례하도록 감소시킵니다.이렇게 하는 이유는 처음에는 학습이 잘 되지 않은 상태이므로 learning rate를 빠르게 증가시켜 변화를 크게 주다가, 학습이 꽤 됐을 시점에 learning rate를 천천히 감소시켜 변화를 작게 주기 위해서입니다.RegularizationResidual ConnectionIdentity Mappings in Deep Residual Networks라는 논문에서 제시된 방법이고, 아래의 수식이 residual connection을 나타낸 것입니다.yl=h(xl)+F(xl,Wl)<math>yl=h(xl)+F(xl,Wl)</math>xl+1=f(yl)<math>xl+1=f(yl)</math>이때 h(xl)=xl<math>h(xl)=xl</math>입니다. 논문 제목에서 나온 것처럼 identity mapping을 해주는 것이죠.특정한 위치에서의 xL<math>xL</math>을 다음과 같이 xl<math>xl</math>과 residual 함수의 합으로 표시할 수 있습니다.x2=x1+F(x1,W1)<math>x2=x1+F(x1,W1)</math>x3=x2+F(x2,W2)=x1+F(x1,W1)+F(x2,W2)<math>x3=x2+F(x2,W2)=x1+F(x1,W1)+F(x2,W2)</math>xL=xl+L−1∑i=1F(xi,Wi)<math>xL=xl+∑i=1L−1F(xi,Wi)</math>그리고 미분을 한다면 다음과 같이 됩니다.σϵσxl=σϵσxLσxLσxl=σϵσxL(1+σσxlL−1∑i=1F(xi,Wi))<math>σϵσxl=σϵσxLσxLσxl=σϵσxL(1+σσxl∑i=1L−1F(xi,Wi))</math>이때, σϵσxL<math>σϵσxL</math>은 상위 layer의 gradient 값이 변하지 않고 그대로 하위 layer에 전달되는 것을 보여줍니다. 즉, layer를 거칠수록 gradient가 사라지는 vanishing gradient 문제를 완화해주는 것입니다.또한 forward path나 backward path를 간단하게 표현할 수 있게 됩니다.Layer NormalizationLayer Normalization이라는 논문에서 제시된 방법입니다.μl=1HH∑i=1ali<math>μl=1H∑i=1Hail</math>σl= ⎷1HH∑i=1(ali−μl)2<math>σl=1H∑i=1H(ail−μl)2</math>같은 layer에 있는 모든 hidden unit은 동일한 μ<math>μ</math>와 σ<math>σ</math>를 공유합니다.그리고 현재 input xt<math>xt</math>, 이전의 hidden state ht−1<math>ht−1</math>, at=Whhht−1+Wxhxt<math>at=Whhht−1+Wxhxt</math>, parameter g,b<math>g,b</math>가 있을 때 다음과 같이 normalization을 해줍니다.ht=f[gσt⊙(at−μt)+b]<math>ht=f[gσt⊙(at−μt)+b]</math>이렇게 한다면, gradient가 exploding하거나 vanishing하는 문제를 완화시키고 gradient 값이 안정적인 값을 가짐로 더 빨리 학습을 시킬 수 있습니다.(논문에서 recurrent를 기준으로 설명했으므로 이에 따랐습니다.)DropoutDropout: a simple way to prevent neural networks from overfitting라는 논문에서 제시된 방법입니다.dropout이라는 용어는 neural network에서 unit들을 dropout하는 것을 가리킵니다. 즉, 해당 unit을 network에서 일시적으로 제거하는 것입니다. 그래서 다른 unit과의 모든 connection이 사라지게 됩니다. 어떤 unit을 dropout할지는 random하게 정합니다.dropout은 training data에 overfitting되는 문제를 어느정도 막아줍니다. dropout된 unit들은 training되지 않는 것이니 training data에 값이 조정되지 않기 때문입니다.Label SmoothingRethinking the inception architecture for computer vision라는 논문에서 제시된 방법입니다.training동안 실제 정답인 label의 logit은 다른 logit보다 훨씬 큰 값을 갖게 됩니다. 이렇게 해서 model이 주어진 input x<math>x</math>에 대한 label y<math>y</math>를 맞추는 것이죠.하지만 이렇게 된다면 문제가 발생합니다. overfitting될 수도 있고 가장 큰 logit을 가지는 것과 나머지 사이의 차이를 점점 크게 만들어버립니다. 결국 model이 다른 data에 적응하는 능력을 감소시킵니다.model이 덜 confident하게 만들기 위해, label distribution q(k∣x)=δk,y<math>q(k∣x)=δk,y</math>를 (k가 y일 경우 1, 나머지는 0) 다음과 같이 대체할 수 있습니다.q′(k|x)=(1−ϵ)δk,y+ϵu(k)<math>q′(k|x)=(1−ϵ)δk,y+ϵu(k)</math>각각 label에 대한 분포 u(k)<math>u(k)</math>, smooting parameter ϵ<math>ϵ</math>입니다. 위와 같다면, k=y인 경우에도 model은 p(y∣x)=1<math>p(y∣x)=1</math>이 아니라 p(y∣x)=(1−ϵ)<math>p(y∣x)=(1−ϵ)</math>이 되겠죠. 100%의 확신이 아닌 그보다 덜한 확신을 하게 되는 것입니다.Conclusiontransformer는 recurrence를 이용하지 않고도 빠르고 정확하게 sequential data를 처리할 수 있는 model로 제시되었습니다.여러가지 기법이 사용됐지만, 가장 핵심적인 것은 encoder와 decoder에서 attention을 통해 query와 가장 밀접한 연관성을 가지는 value를 강조할 수 있고 병렬화가 가능해진 것입니다.Referencehttp://www.whydsp.org/280http://mlexplained.com/2017/12/29/attention-is-all-you-need-explained/http://openresearch.ai/t/identity-mappings-in-deep-residual-networks/47https://m.blog.naver.com/PostView.nhn?blogId=laonple&logNo=220793640991&proxyReferer=https://www.google.co.kr/https://www.researchgate.net/figure/Sample-of-a-feed-forward-neural-network_fig1_234055177https://arxiv.org/abs/1603.05027https://arxiv.org/abs/1607.06450http://jmlr.org/papers/volume15/srivastava14a.old/srivastava14a.pdfhttps://arxiv.org/pdf/1512.00567.pdf

기업문화 엿볼 때, 더팀스

로그인

/