어떠한 작업(Job)이 있다고 가정해보자. 이를 “정해진 시간에 주기적” 이나 “필요할때” 작업을 수행하고 싶다면 어떤 툴(Tool)이 떠오르는가? 그리고 이 작업(Job)들의 실행이력 등 전체적으로 관리하고 필요에 따라 다양한 플러그인을 활용하여 입맛에 맞는 작업(Job)으로 구성하고 싶을때 가장 첫번째로 떠오르는 툴은 바로 “Jenkins” 다. (극히 필자 개인적인 생각일수도 있지만… ) 물론 리눅스 기반의 crontab 이나 다른 스케쥴러를 활용할수도 있다. 다만 필자 개인적인 느낌으로 나만의 Jarvis(?)처럼 내가 원하는데로 설정만 해두면 정해진 시간에 수행하고 그 결과를 로그로 남겨놓고 문제가 발생했을때 알림도 받을수 있으니 너무 좋은 툴이라 생각이 든다. 실제로 Jarvis가 있다면 얼마나 편할까출처 : https://gfycat.com/ko/colossalsociablebuffalo" 실제로 Jarvis가 있다면 얼마나 편할까 출처 : https://gfycat.com/ko/colossalsociablebuffalo 지난 포스팅에서는 Jenkins 를 설치하는 방법에 대해 알아보았다. (정확히 말하면 치트키 수준의… ) 이번 포스팅에서는 Jenkins에 노드를 추가하여 master-slave 분산환경으로 구성하는 방법과 Jenkins 버전을 업그레이드 하는 방법에 대해 정리해보고자 한다. 마침 필자의 팀에서 젠킨스를 분산환경으로 운영하고 있었는데 버전은 1.x … 간헐적으로 Jenkins 버전 이슈로 에러가 발생해서 업그레이드를 해야하는 상황이 생긴것이다. 시키지도 않은 일을 하면서 팀에 도움도 될겸, 포스팅도 할겸, 1석 2조 효과. 서버 환경은 CentOS 7.4 64Bit 에서 테스트 하였다. Jenkins 버전 업그레이드 하기 Jenkins를 업그레이드 하게되면 기존에 있었던 Jenkins의 환경설정은 어떻게 마이그레이션 할까? Job 실행기록들은 그냥 날려버려야 하나? 걱정을 하며 구글링을 해본다. 그러면 “안해본것에 대한 두려움” 을 갖는 필자의 마음이 무색할 정도로 너무 간단하게도 그냥 기존에 있던 war 파일을 최신버전으로 교체하고 재시작 하라고 나온다. 읭? 뭐이리 간단해? 대부분의 문제들은 지레 겁부터 먹고 실행에 옮기지 못해서 않아서 해결을 하지 못하는게 절반 이상같다. 자, 바로 실행에 옮겨보자. 우선 버전 업그레이드를 테스트 하기 위해 일부러 낮은버전으로 설치를 해둔다. (필자는 1.609.1로 설치해봤다.) 그리고 버전 업그레이드 후 설정이 그대로 옮겨지는지를 확인하기위해 Security 설정을 해서 Jenkins 접근시 로그인 여부를 물어보록 설정해둔다. 우측 하단에 빨간영역으로 낮은버전이 설치된것을 확인할수 있다." 우측 하단에 빨간영역으로 낮은버전이 설치된것을 확인할수 있다. 설정이 완료되었으면 최신버전의 war를 다운받아 교체하고 재시작을 해준다. 그러면 너무나도 간단하게 버전이 업그레이드가 된것을 확인할수 있다. 그리고 처음에 설정한 Security 설정까지 그대로 유지되는것 또한 확인이 가능하다. 물론 구 버전에서 설치되었던 플러그인들이 버전업이 되며 그에 따라 지원하지 않는 문제들이 생길 수 있는데 이 부분은 플러그인을 업그레이드를 해준다거나 각 상황에 맞는 대응을 해줘야 한다. 이렇게 해서 생각보다(?) 너무 간단하게 버전업이 완료되었다. 업그레이드 후 플러그인 업그레이드도 동일하게 맞춰주는게 중요하다." 업그레이드 후 플러그인 업그레이드도 동일하게 맞춰주는게 중요하다. Jenkins 분산환경 구성하기 (노드 추가하기) 이번엔 Jenkins를 분산환경으로 구성해보고자 한다. 이렇게 노드를 추가하며 분산환경을 구성하는 이유는 마스터-슬레이브(Master-Slave) 패턴의 장점을 얻고자 함이다. 마스터는 작업을 쪼개고 슬레이브로 구성된 노드에게 분배를 하게되면 슬레이브 서버는 마스터의 요청을 처리하고 리턴하게 된다. 마치 스타크래프트에서 일꾼을 늘려서 미네랄과 가스를 더 빨리 얻는것처럼 말이다. 여기서 필자가 가장 많이 삽질한 부분. 슬레이브 서버를 추가하는데 슬레이브 서버가 되는 서버에 동일하게 젠킨스를 설치하고 그들을 모두 연결하려 했던것… 마치 클러스터링 하는것처럼… 당연히 Jenkins 들의 묶음형태(?) 가 되야 할것같은 생각으로 시도하였지만 엄청난 삽질의 연속이 되어버렸다. 알고보니 마스터 Jenkins에서 슬레이브 서버에 작업을 전달할수 있도록 연동만 시켜주면 자동으로 Agent를 마스터 Jenkins가 슬레이브 서버에 설치/실행을 하고 작업을 분할하는것을 확인할 수 있었다. 자, 그럼 시작해보자. 마스터 서버에서 공개키와 개인키 생성 먼저 마스터 서버와 슬레이브 서버를 SSH로 통신할수 있도록 SSH 키 설정을 해준다. 통상 홈 디렉토리 하위 .ssh 폴더에서 생성한다. ssh 키 생성 $ ssh-keygen -t rsa Generating public/private rsa key pair.

작년 7월 12일부터 시작한 필자의 첫 토이프로젝트인 기술블로그 구독서비스. 오픈할 때까지만 해도 “AWS 프리티어를 사용하고 있는 1년 안에 구독자가 설마 1,000명이 넘겠어?” 라고 생각을 했었는데 오픈을 하고 220일째 되는 바로 어제 어느덧 벌써 구독자가 1,000명을 달성하게 되었다. 그 기념으로 그동안 미뤄두었던 기술블로그 구독서비스 개발 후기 시리즈의 3부를 쓰고자 한다. 오예~ 1,000명이다! 땡큐! 출처 : https://gfycat.com/ko/leafytorngroundbeetle" 오예~ 1,000명이다! 땡큐! 출처 : https://gfycat.com/ko/leafytorngroundbeetle 혹시 전에 내용을 보고자 하면 아래 링크에서 확인할 수 있다. 1부 : 왜 만들게 되었는가 그리고 어떤 구조로 만들었는가 2부 : 문제발생 및 Trouble Shooting 3부 : 앞으로의 계획과 방향성 그간 어떤 식으로 서비스를 운영했는가? (한마디로 정리할 순 없는 지난 220일이었지만…) 딱 한마디로 정리하자면 엄청나게 많은 것을 배우고 경험할 수 있었으나 그만큼 힘들었던 시간들이라고 말할 수 있을 것 같다. 2부에서 이야기한 문제 발생에 따른 Trouble Shooting들도 있었지만 운영을 해오다 보니 사전에 생각하지도 못한 부분에서 문제가 생기는 정말 다양한 경험을 할 수 있었기 때문이다. 블로그 포스팅을 수집하는 과정에서의 문제 일부 블로그 RSS url에 접근을 할 때 요청에 대한 응답이 무한대로 멈춰버리는 현상이 간헐적으로 있었다. 이는 별도의 타임아웃을 설정하지 않았기 때문이다. 그래서 어느 정도의 타임아웃을 두고 시간 내에 응답이 없을 경우 다음 포스팅으로 넘어가도록 하였다. (타임아웃은 아주 기본적인 부분인데…) requests.get(rss_url, timeout=10.0) 메일 발송하는 과정에서의 문제 가끔 메일이 오지 않는다고 친절하게 필자 개인 메일로 연락이 오는 경우가 있었다. 그때마다 서버의 상태를 보면 서버에 직접 접속조차 안 될 정도로 메모리 사용량이 너무 많아서 그때마다 AWS 웹 콘솔에서 강제로 서버를 재부팅을 하곤 했었다. 예전에도 이야기한 것처럼 AWS 프리티어를 사용하고 있다 보니 서버의 메모리가 1기가밖에 되지 않아서 … 제한된 시스템에서 서비스 운영을 할 수밖에 없는 상황이었다. 그래서 수집/발송 상태를 로깅으로 쉽게 볼 수 있고 스케줄링을 하기 위해 띄워둔 Jenkins(tomcat)를 중단하고 crontab으로 스케줄링을 하도록 하였고, 로깅은 별도의 파일로 로깅하도록 변경하였다. /usr/bin/python3.6 /home/~~~/email_send.py > /home/~~~/logs/job/email_send_`date +\%Y\%m\%d\%H\%M\%S`.log 2>&1 또한 기존에는 빠르게 발송하기 위해 냅다 스레드로 돌렸는데 구독자 수가 많아지다 보니 RuntimeError: can't start new thread 라고 스레드를 만들 수 없다는 에러가 발생하기도 했다. 그래서 Pool을 사용하는 방식의 multiprocessing 을 도입하여 스레드로 발송할 때보다는 엄청나게 빠른 속도는 아닐지라도 효율적인 메모리 사용으로 2분 안에 1,000명에게 안정된 메일을 보낼 수 있게 되었다. (여담이지만 메일이 안 온다고 알려주셨던 분들께 이 자리를 빌려 감사의 인사를 전하고 싶다.) from multiprocessing import Pool ... pool = Pool(20) pool.map(sendMail, email_list) Heroku 나 Netlify 같이 서버를 직접 들어가지 않고 앱 형태로 배포하는 식으로 할 수도 있다. 하지만 초기에 이 토이프로젝트를 시작할 때 실 서비스와 최대한 동일한 시스템으로 운영해보고 싶었기 때문에 라즈베리파이에 설치하는 것까지 알아보다 결국 AWS를 사용하기로 하게 되었다. 그렇다면 AWS 프리티어를 사용하지 않고 별도의 서버를 구매하면 안 될까? 하는 생각도 해봤지만 최소한의 인프라로 최대한의 성능을 내보고 싶은 욕심(?) 때문에 1년간은 프리티어로 운영하고 그다음엔 (혹은 소프트웨어적으로 한계까지 도달한다면) 서버를 구매해서 운영하게 될 것 같다. (적어도 이후에도 이 서비스를 유지한다는 가정하에…) 농부의 마음으로… 출처 : http://www.iwithjesus.com/news/articleView.html?idxno=2511" 농부의 마음으로… 출처 : http://www.iwithjesus.com/news/articleView.html?idxno=2511 아침 10시가 되면 자동으로 메일이 잘 발송되었는지, 혹 어제 수집된 것이 아니라 예전에 수집된 내용이 중복 발송된 건 아닌지, 발송은 구독한 사람 전부에게 잘 보내졌는지… 거의 매일같이 Daily-DevBlog 서비스를 살피며 지낸 것 같다. (하루라도 문제가 생기면 밤을 새워서라도 원인을 파악하고 다음 발송에는 정상적으로 발송되도록 수정하기도 했다.) 앞으로의 계획과 방향성 여력이 되는 데까지 이 서비스를 운영할 계획이다.

필자가 Elastic Stack을 알게된건 2017년 어느 여름 동기형이 공부하고 있는것을 보고 호기심에 따라하며 시작하게 되었다. 그때까지만 해도 버전이 2.x 였는데 지금 글을 쓰고있는 2019년 2월초 최신버전이 6.6이니 정말 빠르게 변화하는것 같다. 빠르게 변화하는 버전만큼 사람들의 관심도 (드라마틱하게는 아니지만) 꾸준히 늘어나 개인적으로, 그리고 실무에서도 활용하는 범위가 많아지고 있는것 같다. trends.embed.renderExploreWidget("TIMESERIES", {"comparisonItem":[{"keyword":"elasticsearch","geo":"KR","time":"today 5-y"}],"category":0,"property":""}, {"exploreQuery":"date=today%205-y&geo=KR&q=elasticsearch","guestPath":"https://trends.google.co.kr:443/trends/embed/"}); 그래서 그런지 최근들어 (아주 코딱지만큼 조금이라도 더 해본) 필자에게 Elastic Stack 사용방법에 대해 물어보는 주변 지인들이 늘어나고 있다. 그리고 예전에 한창 공부했을때의 버전보다 많이 바꼈기에 이 기회에 “그대로 따라만 하면 Elastic Stack을 구성할 수 있을만한 글"을 써보고자 한다. 사실 필자가 예전에 “도큐먼트를 보기엔 너무 어려워 보이는 느낌적인 느낌” 때문에 삽질하며 구성한 힘들었던 기억을 되살려 최대한 심플하고 처음 해보는 사람도 따라하기만 하면 “아~ 이게 Elastic Stack 이구나!”, “이런식으로 돌아가는 거구나!” 하는 도움을 주고 싶다. + 그러면서 최신버전도 살펴보고… 1석2조, 이런게 바로 블로그를 하는 이유이지 않을까? 다시한번 말하지만 도큐먼트가 최고 지침서이긴 하다… Elastic 공식 홈페이지에 가면 각 제품군들에 대해 그림으로 된 자세한 설명과 도큐먼트가 있지만 이들을 어떤식으로 조합하여 사용하는지에 대한 전체적인 흐름을 볼 수 있는 곳은 없어 보인다. (지금 보면 도큐먼트가 그 어디보다 설명이 잘되어 있다고 생각되지만 사전 지식이 전혀없는 상태에서는 봐도봐도 어려워 보였다.) 이번 포스팅에서는 Apache access log를 Elasticsearch에 인덱싱 하는 방법에 대해 설명해보고자 한다. 전체적인 흐름 필자는 글보다는 그림을 좋아하는 편이라 전체적인 흐름을 그림으로 먼저 보자. 외부에서의 접근이 발생하면 apache 웹서버에서 설정한 경로에 access log가 파일로 생성이 되거나 있는 파일에 추가가 된다. 해당 파일에는 한줄당 하나의 엑세스 정보가 남게 된다. fileBeat에서 해당 파일을 트래킹 하고 있다가 라인이 추가되면 이 정보를 logstash 에게 전달해준다. logastsh 는 filebeat에서 전달한 정보를 특정 port로 input 받는다. 받은 정보를 filter 과정을 통해 각 정보를 분할 및 정제한다. (ip, uri, time 등) 정리된 정보를 elasticsearch 에 ouput 으로 보낸다. (정확히 말하면 인덱싱을 한다.) elasticsearch 에 인덱싱 된 정보를 키바나를 통해 손쉽게 분석을 한다. 한번의 설치고 일련의 과정이 뚝딱 된다면 너무 편하겠지만, 각각의 레이어가 나뉘어져있는 이유는 하는 역활이 전문적으로(?) 나뉘어져 있고 각 레이어에서는 세부 설정을 통해 보다 효율적으로 데이터를 관리할 수 있기 때문이다. beats라는 레이어가 나오기 전에는 logstash에서 직접 file을 바라보곤 했었는데 beats가 logstash 보다 가벼운 shipper 목적으로 나온 agent 이다보니 통상 logstash 앞단에 filebeat를 위치시키곤 한다고 한다. 전체적인 그림은 위와 같고, 이제 이 글을 보고있는 여러분들이 따라할 차례이다. 각 레이어별로 하나씩 설치를 해보며 구성을 해보자. 설치순서는 데이터 흐름의 순서에 맞춰 다음과 같은 순서로 설치를 해야 효율적으로 볼수가 있다. (아래순서대로 하지 않을경우 설치/시작/종료 를 각각의 타이밍에 맞추어 해줘야 할것 같아 복잡할것같다.) elasticsearch → logstash → kibana → filebeat 이 포스팅은 CentOS 7.4에서 Java 1.8, apache 2.2가 설치되어있다는 가정하에 보면 될듯하다. 또한 각 레이어별 설명은 구글링을 하거나 Elastic 공식 홈페이지에 가보면 자세히 나와있으니 기본 설명은 안하는것으로 하고, 각 레이어의 세부 설정은 하지 않는것으로 한다. Elasticsearch 공식 홈페이지 다운받고 압축풀고 심볼릭 경로 만들고 (심볼릭 경로는 선택사항) $ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.6.0.tar.gz $ tar zxvf elasticsearch-6.6.0.tar.gz $ ln -s elasticsearch-6.6.0 elasticsearch 설정 파일을 열고 추가해준다. $ cd elasticsearch/conf $ vi elasticsearch.yml path.data: /~~~/data/elasticsearch (기본경로에서 변경할때추가) path.logs: /~~~/logs/elasticsearch network.host: 0.0.0.0 # 외부에서 접근이 가능하도록 (실제 ip를 적어줘도 됨) elasticsearch 의 시작과 종료를 조금이나마 편하게 하기위해 스크립트를 작성해줌 (이것또한 선택사항) $ cd ../bin $ echo '.

초창기 신입시절에 배우거나 사용했던 기술적인 방법들이 있다. 시간이 지날수록 왠만해선 다른방법은 사용하지 않으려 하고 습관처럼 기존에 사용했던 방법을 고수하는 버릇이 있다. 그 이유는 과거에 사용했을때 아무 탈 없이 잘 되었기 때문에, 그리고 빠른 구현 때문이라는 핑계일 것 같다. 이러한 버릇은 비단 이 글을 적고있는 필자 뿐만이 아니라 대부분의 개발자들이 가지고 있을꺼라 조심스레 추측해본다. (아니라면…더욱 분발 해야겠다…ㅠ) 최근 운영하고 있는 서비스에서 장애 상황까지 갈수있는 위험한 상황이 있었는데 팀내 코드리뷰를 통해 문제점을 파악할 수 있었다. 그 원인은 Spring MVC Controller 레벨에서 redirect 처리를 할때 return값의 Cardinality가 높을경우 다음과 같이 사용하면 안된다고… @RequestMapping(value = "/test", method = RequestMethod.GET) public String test() { String url = "어떠한 로직에 의해 생성되는 url"; return "redirect:" + url; // <- 위험 포인트! } 이 코드가 왜? 어디가 어때서? 이제까지 Controller 레벨에서 redirect 처리를 할때 아무생각없이 위에 있는 코드 형태로 구현을 했는데 저러한 코드 때문에 OOM이 발생하여 fullGC 가 여러번 발생하고, 일시적으로 서비스가 지연되는 현상이 발생했다고 한다. 자주 사용하던 방법이였는데 장애를 유발할수 있는 위험한 방법이였다니… 이번 포스팅에서는 이러한 방법이 왜 잘못되었는지 실제로 테스트를 통해 몸소(?) 체감을 해보고, 그럼 어떤 방법으로 redirect 처리를 해야 하는가와 개선을 함으로써 기존방식에 비해 어떤점이 좋아졌는지에 대해서 정리해보고자 한다. 뭔가 내것으로 만들기 시리즈물이 나올것만 같은 느낌이다… 기존방식의 문제점 재현 및 다양한 원인분석 기존방식으로 했을때 왜 OOM이 발생했을까? 우리는 개발자이기 때문에 이런저런 글들만 보고 추측 할것이 아니라 직접 재현을 해보고 다양한 시각에서 원인분석을 해보자. 먼저 기본적인 Spring MVC 뼈대를 만들고 redirect 하는 return 값의 Cardinality가 높도록 random string 을 만들어 주도록 한다. 즉, /random을 호출하면 /result/ETmHfowFkU처럼 random string 이 만들어 지며 redirect 처리가 되는 매우 심플한 구조이다. // Spring 버전은 4.0.6.RELEASE @Controller @RequestMapping("/") public class TestController { @RequestMapping(value = "random", method = RequestMethod.GET) public String random() { return "redirect:result/" + UUID.randomUUID(); } @RequestMapping(value = "result/{message}", method = RequestMethod.GET) public String result(ModelMap model, @PathVariable String message) { model.addAttribute("message", message); return "result"; } } 또한 해당 프로젝트에서는 AOP를 사용하고 있었기 때문에 그때와 동일한 상황으로 재현을 하기 위해 AOP관련 설정도 추가해준다. @Configuration @EnableWebMvc @EnableAspectJAutoProxy @ComponentScan public class HelloWorldConfiguration { @Bean(name="HelloWorld") public ViewResolver viewResolver() { InternalResourceViewResolver viewResolver = new InternalResourceViewResolver(); viewResolver.setViewClass(JstlView.class); viewResolver.setPrefix("/WEB-INF/views/"); viewResolver.setSuffix(".jsp"); return viewResolver; } } 이렇게 한뒤 tomcat으로 최대/최소 메모리를 256m으로 설정후 해당 모듈을 띄워준다. 그다음 메모리 상태를 보기 위해 tomcat에 pinpoint를 연동하고 마지막으로 호출테스트를 위해 nGrinder을 설정해준다. 특별한 설정은 없고 위 컨트롤러의 url (/random) 을 여러번 호출하도록 하였다. nGrinder을 설정하는대에는 이 블로그 포스팅을 참고해서 설정하였다. 자, 이제 테스트를 시작해보자. (마치 수술 집도하는것 같은 기분으로…간호사~ 칼!) nGrinder nGrinder의 기본 스크립트에서 url만 해당 서버로 호출되도록 바꿔주고 총 가상 사용자는 2,000으로 시간은 5분으로 설정후에 테스트 시작을 하였더니 다음과 같은 그래프를 볼수 있었다. TPS가 불안정해지다가 어느시점부터 낮아지는것을 확인할 수 있다. 이게 서비스 였다면 사용자가 접속하는데 불편을 느꼈을꺼라 추측을 해본다. 또한 아주 간단한 random string 을 리턴하는 페이지 임에도 불구하고 에러 응답이 적지 않은것을 확인할 수 있었다. pinpoint 메모리 상태는 어떤지 확인하기 위해 pinpoint를 확인해보면 다음과 같은 그래프를 볼수 있었다. 보기만해도 심장이 벌렁벌렁(?) 뛸 정도로 무서운 그림이다. 실제로 서비스에 (이정도까진 아니였지만) 비슷한 상황이 발생했었다. 메모리가 테스트를 점점 하면 할수록 올라가다가 fullGC가 발생하더니 대나무 숲에 있는 대나무마냥 fullGC가 빼곡히 발생하였다. (이러니… 페이지 접근에 지연이 생긴것 같다.

만약 1번부터 10번까지 번호표가 있는 사람들 총 열명에게 혼자서 동일한 내용의 메일을 보낸다고 가정해보자. 그리고 메일 발송시 한번에 한명에게만 보내야 하는 제한사항이 있을때 과연 당신은 어떤식으로 보내겠는가? 이어서 읽지말고 한번 생각해보자.아무것도 고려하지 않고 단순하게 생각한다면 1번 보내고 > 2번 보내고 … 9번 보내고 > 10번 보내는 방법이 먼저 떠오르게 된다. (for loop 1 to 10 … ) 하지만 보내야 할 사람들이 많아져서 백명, 천명 많게는 천만명에게 보내야 할 경우 방금과 같은 순차적인 방법을 사용하면 너무 늦게 발송된다는건 코드를 작성하지 않아도 알 수있는 문제… 그렇다면 어떤 방법으로 보내야 보다 빨리 보낼수 있을까? 이번 포스팅에서는 필자가 운영하고 있는 서비스에서 기존에 있던 병렬프로세스를 어떤식으로 최적화 했는지, 그래서 결국 얼마나 빨라졌는지에 대한 과정을 정리해 보고자 한다. 비단 메일 발송이나 앱 푸시 등 특정 도메인에 국한되지는 않고 전반적인 프로세스에 대해 이해를 한다면 다른 곳에서도 비슷한 방법으로 활용할 수 있을꺼라 기대 해본다. 상황파악 및 목표 (원할한 이해를 돕기 위하여) 먼저 필자가 운영하고있는 서비스를 간략히 소개부터 해야겠다. (그렇다고 필자 혼자 다 하는건 아님^^;…) 셀럽의 방송이 시작되면 구독한 사용자에게 각 모바일 기기에 설치되어있는 앱으로 알림을 보내어 예정에 없던 깜짝 라이브 방송이나 VOD 영상 오픈을 보다 빠르게 확인할 수 있도록 제공하고 있다. 여기서, 알림이 늦게 발송되면 셀럽은 방송을 시작하고 팬들이 들어오기까지 기다려야 한다거나 반대로 팬들은 방송 시작하고 뒤늦게 방송을 보게되는 불편함이 생기게 된다. 그리고 중복으로 알림이 발송되거나 특정 사용자들에게 발송이 누락되면 안 되는 등 “알림” 이란 기능은 서비스에 있어서 중요한 기능 중에 하나라고 할수 있다. 여기서 “발송 시간"은 처음 발송작업 시작부터 마지막 사용자에 대해 사내 발송 플랫폼으로 발송 요청을 하기까지의 시간을 의미 그리고 “채널” 이라는 샐럽단위의 그룹이 있는데 영상과 채널의 관계는 1:N이다. 즉, 하나의 영상을 여러 채널에 연결시킬수 있어서 하나의 영상에 대해 여러 채널들에게 연결을 시켜놓으면 채널을 구독하고있는 각각의 사용자에게 모두 알림을 발송 할수가 있게 된다. 우선, 알람이 사용자에게 전달되기까지의 큰 흐름은 다음과 같다. 알림 프로세스" 알림 프로세스 서비스에서 보낼 대상과 보낼 정보를 조합하여 사내 푸시 발송 플랫폼인 사내 발송 플랫폼에게 전달을 하면 플랫폼에 따라 발송이 되고 최종적으로는 사용자의 모바일 기기에 노출이 됨 간단하게 “병렬로 발송하면 되지 않을까?“라는 필자의 생각이 부끄러워질 정도로 이미 redis, rabbitMQ 를 활용해서 아래 그림처럼 병렬 프로세스로 구성되어 있었다. 기존 구조" 기존 구조 라이브가 시작되거나 VOD가 오픈될 경우 api가 호출이 되고 다시 배치 서버에게 영상의 고유번호를 전달 전달받은 영상의 고유번호를 rabbitMQ의 수신자 조회 Queue에 produce 수신자 조회 Queue의 consumer인 수신자 조회 모듈에서 영상의 고유번호를 consume 후 아래 작업을 진행 3-1. 영상:채널 은 1:N 구조이기 때문에 여러 채널의 사용자들에게 알림을 발송할 수 있고, 영상에 연결된 채널들의 user를 db에서 가져온다. 3-2. 가져온 user를 (중복으로 알림이 발송되지 않기 위해) java set에 담고 모든 채널을 조회했다면 redis에 sorted set으로 담는다. 3-3. 적당한 크기로 분할하고 이 분할정보를 발송 Queue에 produce 발송 모듈에서 분할 정보를 consume 하고 아래 작업을 진행 (병렬처리) 4-1. redis 에서 user 모음을 가져오고 4-2. 조회한 user에 해당하는 deviceId를 db에서 가져옴 deviceId와 컨텐츠 정보를 활용하여 적절한 payload를 구성 후 사내 발송 플랫폼 에게 전달 기존 구조에서 발송 시간은 서비스에서 구독자 수가 가장 많은 채널 기준으로 약 1.1천만 명에게 최종 11분 정도 소요되고 있었다. (맨 처음에 이야기 한 순차적인 방법이였다면… 훨씬더 오래 걸렸을꺼라 예상해본다…) 기존에 구성하셨던 분들도 수많은 시행착오와 고민을 하시며 구성하셨을 텐데 더 이상 어떻게 더 빠르게 보낼 수 있을까 하는 부담감과 자칫 알림이 잘못 발송되기라도 한다면(장애가 발생한다면) 그 수많은 사용자들의 불만 화살 과녁이 필자가 되어야 한다는 압박감이 개선 시작 전부터 머릿속을 휘감고 있었던 찰나에

매사에 행동하는 모든것들의 끝자락에서는 그동안 잘한것과 못한것을 다시 생각하며 잘한것은 보다 더 잘할수 있도록 하고 못한것은 왜 못했는지 그리고 어떻게 하면 못한 부분을 고칠수 있을지에 대한 시간을 갖으려고 노력해왔다. 그게 개발이 되었든 게임이 되었든 연인과의 데이트가 되었든 뭐든지. 이러한 시간들은 필자에게 큰 인사이트를 얻을 수 있게 되었고 지난 한해를 돌이켜 보자면 개인적으로 계획한 전부를 다 이뤄내지는 못했지만 나름의 많은 경험과 성과를 달성했다고 생각해본다. 이제 몇시간 뒤면 올해가 끝나고 새로운 한 해가 시작되는 이 시점에 개발자로써의 회고를 해보며 2018년 정리 및 2019년 목표를 다짐해보자. 글쓰는 개발자가 되자. 개인 블로그 운영 아주 오래전, 동기 형을 통해 개발자가 글을 써야하는 중요성에 대해 절실하게 배우게 되었고 그때부터 블로그를 운영하기 시작하였다. 그 동기형의 말에 조금 더 내 생각을 첨가하자면 글을 쓰다보면 누군가 내 글을 본다는 마음에 내가 알고있는 지식을 보다 더 깊게 공부하게 되고 그것들이 모여 내 개발 히스토리가 만들어 지며 포트폴리오 등 다양하게 활용할 수 있기에 블로그를 운영하는건 정말 좋은 선택지 였던것 같다. 실제로 그냥 구글링 해서 알게된 것과는 또 다른 배움이 있었기 때문이다. 회사 일 그리고 개인 공부를 하면서 적어도 한달에 한가지 이상은 배우게 되기 때문에 올해 초 한달에 한개 이상의 글을 쓰기로 결심하였다.(그 달의 글이 없다면 뭔가 놀았거나(?) 미친듯이 바빴거나 아니면 게을렀거나…) 블로그에 글을 쓴 내역을 그래프로 시각화 해보면 아래처럼 총 23개의 글을 작성하였고 월 평균 1.9개의 글을 작성하게 된것을 볼수 있다. 9월달엔 팀 옮기자마자 엄청 바빴고, 11월엔 그 바쁜게 결실을 맺는 시간… 이라 핑계를… (나중에 블로깅 예정, 병렬 프로그래밍 관련) 월별 글 작성수" 월별 글 작성수 위 결과만을 두고 봤을땐 많으면 많고 적으면 적다고 할 수 있는 결과지만 개인적으로는 자투리 시간을 활용해서 그간 배웠던것, 그리고 경험했지만 내것으로 만들지 못하고 보기만 하며 넘어간것들에 대해 귀찮지만 시간을 투자하고 정리했더라면 더 많은 글을 썼을것 같다는 조금 아쉬운 결과라고 생각이 든다. 주 단위 PV, 누군가 내 글을 보고 있다는것에 뿌듯함" 주 단위 PV, 누군가 내 글을 보고 있다는것에 뿌듯함 나름 열심히 글을 쓴 결과일까, GA를 통해 본 필자의 블로그에 유입량이 점점 늘어나는것을 보며 하나를 쓰더라도 좀더 자세히 독자의 입장에서 써야겠다고 다시한번 다짐하게 된다. 다만 글을 “많이” 쓰는것보다 하나를 작성하더라도 원인과 근거를 들어가며 문제를 정확히 파악하는데 집중을 해야하고, 단순 사용법 나열이 아닌 실제로 경험을 해가면서 “내것"으로 만드는 과정이 필요하겠다. 회사 팀 변경 그리고 토이 프로젝트 기존에 아무것도 없던 환경에서 서버 발급부터 이런 저런 서비스에 도움이 되는 다양한 모니터링 툴을 개발하며 무사히 서비스를 오픈을 하였고, 약간의 매너리즘이 생겨날 즈음 좋은 기회가 생겨 성격이 전혀 다른 서비스를 하는 팀을 옮기게 되었다. 약간 이직과도 비슷한 느낌으로 팀을 옮기게 되었는데 처음엔 새로운 지식을 습득해야 하는 두려움도 있었고 기존 서비스에 애정이 많아서 고민이 많았지만 벌써 옮긴지 5개월이 지나고 돌이켜보면 올해 가장 잘한 일 중 하나가 아닐까하는 생각이 든다. 전 팀에선 서비스를 운영하는데 그쳤지만 지금 내가 있는 곳은 대용량 서비스를 성능측면에서, 그리고 아키텍쳐 측면에서 보다 효율적으로 개발하는데 집중을 하려는 모습들이 보이기 때문이다. 더불어 팀에 투입되자마자 필자 홀로 기존에 있던 병렬 프로세스를 개선하여 서비스적으로 약 90%의 개선효과를 볼수있었는데 이 부분은 추후 포스팅 할 예정이다. 그리고 팀을 옮기기 한두달 전 개인적인 여유시간이 많이 있었고, 다른사람들의 블로그를 보며 챙겨보고 싶은 마음에 토이 프로젝트를 만들게 되었다. 7월 중순부터 시작했으니 이것도 어느덧 반년이 지나고 있는데 운영을 해가면서 기능을 추가하기 위해 종종 밤을 새는 등 올 한해있어 꽤 많은것을 얻을수 있었던 시간이였다.

엘라스틱을 처음 접하게 된 건 2017년 여름 facebook 피드에 “Elastic Stack을 이용한 서울시 지하철 대시보드” 라는 링크를 보게 된 것부터인 것 같다. 그 당시 데이터 분석 및 자동화에 관심이 커지고 있던 찰나였는데 키바나로 간단하면서도 아주 멋진 대시보드를 그릴 수 있다는 게 너무 흥미롭게 다가왔고 거기다 실시간으로 볼수 있다는 점에 공부를 시작하지 않을 수 없었다. 그렇게 이것저것 만들어 보기도 하고 한국 엘라스틱서치 커뮤니티 활동을 해오던 찰나 (최근들어 눈팅만 하고 있지만…) 올해 마지막 밋업을 한다고 하여 참여하게 되었다. 여기어때 본사 방문 강남에 위치한 여기어때 본사에서 밋업을 하게 되어 덕분에 다른 회사 구경을 할 수 있게 되었다. 예전 다른 IT 스타트업 밋업 행사에서도 느꼈던 부분인데 엄청나게 큰 시설은 아니지만 아기자기하게 회사의 색깔과 특징을 잘 살려놓은 인테리어가 인상적이었다. 그런데 생각보다 사람이 너무~ 많이 와서 약간 집중이 안 될것 같았지만 다행히도 자리를 잘 잡아서 세션을 듣는 데는 무리가 없었다. (정확하진 않지만 참석하신 분들 중의 절반 정도만 강의장에 들어오고 나머지는 밖에서 듣는 걸 보고 이런 IT 행사의 인기를 다시 한번 실감할 수 있었다.) ‘여기어때’ 본사건물에서 엘라스틱 밋업을!" ‘여기어때’ 본사건물에서 엘라스틱 밋업을! 엘라스틱서치 6.5 최신버전 소개 및 커뮤니티 회고 행사 처음 세션으로 김종민 커뮤니티 엔지니어 분께서 엘라스틱의 최근 업데이트 정보와 커뮤니티 활동에 대해서 회고해주셨다. 내가 처음 엘라스틱서치를 접한 버전이 2.4였는데 벌써 6.5라니… 빨라도 너무 빠르다. 이번 버전에서는 한 클러스터에서 다른 클러스터로의 인덱스를 복제하는 방법인 Cross-cluster replication (클러스터 복제) 기능이 추가되었고 ODBC Client 추가, 자바 11지원 등 여러 가지 기능이 추가되었다고 한다. 특히 키바나에서는 파일을 업로드하면 자동으로 분석해서 인덱싱을 해주는 기능도 생겼고 (파일 크기가 100메가 제한이라는게 살짝 아쉽긴 했다.) 캔버스, 스페이스 등 역시 키바나 라는 생각이 들 정도로 비주얼라이징을 한번더 업그레이드 한듯 하다. (다 사용할 수 있을까 하는 정도로… 엘라스틱 스택을 들어보기만 하던 함께 참석한 동기 녀석도 당장 해보겠다고 할 정도로…) 다른 자세한 내용은 여기서 확인이 가능하다. 너무나 빠른 버전업과 너무나 발빠르게 움직이는 사람들" 너무나 빠른 버전업과 너무나 발빠르게 움직이는 사람들 엘라스틱서치 활용사례 스마일게이트 및 여기어때 에서 엘라스틱 서치를 활용한 사례를 발표해 주셨다. 하지만 아쉽게도 필자는 5.6 버전까지밖에 사용한 게 전부여서인지(그것도 일부 기능만) 전체 발표 내용을 다 이해를 하진 못했지만 구축하면서 생긴 문제나 삽질 경험담을 공유해주셔서 간접적으로라도 그때의 현장감(?)을 느낄 수 있어 좋았고, 한편으로 여태까지 나름 엘라스틱서치를 만져봤다고 약간의 자신감 반 자만심 반으로 생각했었는데 역시 세상엔 고수가 많구나 하며 다시 분발해야겠다고 다짐했다. 스마일게이트 + 여기어때" 스마일게이트 + 여기어때 마치며 커뮤니티 활동 회고 시간에 누가 페이스북 커뮤니티에서 “공유"라는 단어를 사용해서 게시글을 작성했는지 키바나로 보여주고 밋업에 온 사람이 있다면 5만원 여기어때 쿠폰을 준다고 했었다. 마침 키바나 대시보드 한쪽 구석에 필자의 이름이 보였지만 (예전에 나름 활발하게 질문도 하고 공유도 했던 적이 있어서…) 쿠폰을 받는구나 하며 기대를 하고 있었지만 아쉽게도 최근에 작성한 몇 분에게만 선물이 돌아갔다… 하지만 그 아쉬움도 잠시, 무작위로 추첨하여 또 쿠폰을 준다고 했는데 당첨이 되어서ㅎㅎ 감사하게도 쿠폰을 받는 기쁨을 누릴 수 있었다!! 역시 밋업의 마무리는 굿즈모음이지(?)" 역시 밋업의 마무리는 굿즈모음이지(?) 매번 이런 IT밋업에 참가 신청을 하고 참석하기 전에는 “아 귀찮다. 취소할까. 날도 추운데. 피곤한데” 하며 가기 싫었지만 막상 와보면 생각보다 많은 것을 배워가고 얻어 간다. (쿠폰을 받아서가 아니라…) 세션에 발표하시는 분들, 그리고 그 발표를 듣는 참석하신 분들의 눈동자에서 배움에는 끝이 없고 배워야 살아남는다는 걸 (특히 IT직군은 더…) 다시 한번 느끼고 생각할 수 있었던 좋은 시간이었다.

“show me the money”, “black sheep wall”. 어렸을적 스타크래프트라는 게임이 나오고서 입에 달고 살았던 치트키. 게임이 시작되고 해당 치트키를 입력하면 돈이 들어오거나 맵이 훤하게 보여 컴퓨터를 이기는데 도움을 주곤 했었다. 개발을 하면서 Jenkins는 나 대신 어떤 업무를 수행하는데 강력한 툴 중에 하나이다. (물론 만능이라는 소리는 아니지만…) 새로운 프로젝트가 시작되거나 개발도중 무언가 자동화를 하고 싶을 경우엔 Jenkins를 찾게 되는데 그럴때마다 설치를 하고 이런저런 설정이 필요하다. 눈치를 챘을수도 있지만 이 포스트는 오로지 젠킨스 설치하는 방법을 아주 간단하고 핵심만 정리하고자 한다. 마치 치트키처럼. 나중에 다시 보기위해 + 누군가 해당 포스트를 보고 도움이 되었으면 하는 바람으로. (물론 이 방법밖에 있는건 아니지만 필자는 아래와 방법을 사용하고 있다.) 우선 CentOS 환경에 Java가 설치되어 있는 상황이라 가정한다. 적당한 위치에 tomcat 다운 ( https://tomcat.apache.org/download-80.cgi ) wget {압축파일 다운경로, 필자는 apache-tomcat-8.5.35 } 압축 해제후 하위 폴더중 webapps로 이동 tar -zxvf apache-tomcat-8.5.35.tar.gz cd apache-tomcat-8.5.35/webapps Jenkins 다운 ( https://jenkins.io/download/ ) wget http://mirrors.jenkins.io/war-stable/latest/jenkins.war tomcat 하위폴더중 conf 폴더로 이동 cd ../conf server.xml 수정 및 http port 확인 vi server.xml <Host> 하위에 추가 <Context path="/jenkins" debug="0" privileged="true" docBase="jenkins.war" /> port 확인 <Connector port="8080" protocol="HTTP/1.1"/> 해당 서버의 ip와 위 port에 맞춰 url 입력후 jenkins 설치 http://ip:8080/jenkins

필자가 운영하고 있는 Daily Dev Blog 라는 서비스는 매일 동일한 시간에 주기적으로 데이터를 크롤링 하고 사용자에게 메일을 발송하는 일련의 작업을 수행하고 있다. 헌데 예상하지 못한 부분에서 예외가 발생하게 되면 어떤경우는 메일 발송을 못한다거나 기존에 발송했던 데이터를 다시 보내는 등 정상적이지 못한 상황을 맞이하게 된다.메일이 하루라도 잘못오면 여기저기서 연락이 온다. 감사한 분들…" 메일이 하루라도 잘못오면 여기저기서 연락이 온다. 감사한 분들… 이런저런 바쁜일들로 차일피일 미루다 마침 여유가 생겨 기존에는 Crontab 스케쥴로 파이썬 스크립트를 실행하던 것에서 Jenkins로 옮기는 작업을 했다. 젠킨스가 스케쥴링을 해주고 실행이력을 보여주며, 실시간으로 스크립트가 돌아가는걸 볼수 있을것 같다는 기대감에서이다. 위에서 이야기 했던 예외상황을 보다 빠르고 편하게 실시간으로 디버깅을 하기 위해서가 가장 컸다. 당연히 될거라고 생각했으나… 작업은 간단할꺼라 생각했다. 우선 Jenkins를 설치하고 기존에 스크립트 파일을 Jenkins Job으로 옮긴후에 적당한 코드 중간중간에 디버깅이 용이하도록 로그를 출력하게 해둔다음 스케쥴링만 걸어두면 끝이라고 생각했다. 하지만, 이렇게 간단하게 끝날것만 같았던 작업이 은근 귀찮은 작업이 될줄이야. 디버깅을 위해 로그를 출력하도록 해놨는데 모든 스크립트가 끝이 나서야 해당 로그가 출력되는 것이였다. 로그를 실시간으로 볼수 없다면 Crontab에서 Jenkins로 옮기는 이유가 크게 없게 된다. 실제로 아래처럼 코드를 작성하고 Jenkins Job을 실행시켜보면 다 끝나고서야 출력이 되는걸 볼수 있었다. (1초에 한번씩 5초동안 로그를 찍는 간단한 코드다.) import time print('start') for second in range(0,5) : print(second) time.sleep(second) print('end') 스크립트가 다 끝나서야 출력을 볼수 있다ㅠ 실시간으로 디버깅이 어렵다." 스크립트가 다 끝나서야 출력을 볼수 있다ㅠ 실시간으로 디버깅이 어렵다. 그럼 어떻게 해야할까? 개발을 하면서 만나는 대부분의 문제들은 누군가 과거에 경험했던 문제였고, 이미 해결된 문제일 확률이 상당히 높은것들이 많다. 이번에도 역시, 갓 스택 오버플로우 : https://stackoverflow.com/questions/107705/disable-output-buffering 위 링크에서 알려준것처럼 해보면 다음과 같이 로그가 출력되는대로 젠킨스에서 볼수 있게 된다. 콘솔환경에서의 디버깅은 로깅이 최고!" 콘솔환경에서의 디버깅은 로깅이 최고! 정리해보면 다음과 같은 방법이 있겠다. Execute Python script 을 활용하여 Jenkins 에 직접 코드를 작성하는 경우 print의 flush옵션을 활용 ( https://docs.python.org/3/library/functions.html?highlight=print#print ) print('hello', flush=True) 매번 print 가 될때마다 flush가 되도록 재정의 import sys class Unbuffered(object): def __init__(self, stream): self.stream = stream def write(self, data): self.stream.write(data) self.stream.flush() def writelines(self, datas): self.stream.writelines(datas) self.stream.flush() def __getattr__(self, attr): return getattr(self.stream, attr) sys.stdout=Unbuffered(sys.stdout) Execute shell을 활용하여 특정경로의 Python 파일을 실행할 경우 -u 옵션을 줘서 실행시킨다. ( python -u python_module.py ) 이렇게 두고보면 너무 간단한 작업인데 이런 방법을 모르는 상황에서는 작성된 Python Script를 Shell Script로 다시 감싸보거나 Python 코드를 쓰지 말까 까지 생각했었다… 삽질의 연속들… (Shell Script로 작성하면 바로바로 보였기 때문…) 다시한번 모르면 몸이 고생한다(?)라는걸 몸소 체험한 좋은…시간이였다.

회사 내에서도 대학시절 수강신청마냥 1분도 안되서 마감될 정도로 관심이 많았던 DEVIEW 2018. 다행히 클릭신공으로 운좋게 신청에 성공하였고 팀에서도 바쁜 시기였지만 감사하게도 보내주셔서 올해는 이틀 모두 다녀올수 있게 되었다.예전에는 연차가 올라가면 DEVIEW행사는 참여 안하겠지~라는 생각이 있었는데 그때는 단순 호기심에 참석을 하고 싶었다면 이번에는 뭐라도 배워오자라는 마음으로 신입 시절보다 조금더 성숙한 마음가짐과 자세를 가지고 참석을 하게 되었다. 다시 생각해보면 호기심만으로 세션들을 듣고 부스에서 나눠주는 굿즈를 조금이라도 더 받아와야지 하고 생각했던 신입시절의 생각이 틀린건 아니였지만, 말 그대로 기술행사이니만큼 가급적이면 세션에서 발표하는 내용을 내것으로 만들고 실무에서 또는 다른곳에서 활용할수는 없을까 하는 생각을 갖는게 보다 성장하려는 개발자로서의 자세가 아닐까 생각이 든다. (라고 멋드러지게 말하지만 세션내용의 절반이라도 이해하면 다행이겠지…) 행사 시작 그리고 키노트 10초만에 마감되었다는 소리가 있을정도로 올해도 여전히 관심이 많았던 DEVIEW 2018. 코엑스에 도착하고 등록을 한뒤 이곳저곳 부스들을 구경하기 바빴다. 이번에는 지난번과 달리 거의 네이버 서비스가 60~70%를 자리잡고 있었고(파파고, 지도, 클로바, 글로벌 광고 등등) 일반 기업에서는 얼마 오지 않았다.(내 기억으로 5~6개?) 개인적으로 여러 다양한 회사들이 함께하는 기술행사가 되었으면 하는 바램이 있었지만 회사를 선정하는데, 그리고 기타 사정들이 있을꺼라는 아쉬움을 뒤로하고 CTO님이 발표하시는 키노트를 들으러 메인강의장에 들어갔다. (자칫… 이것도 네이버 독과점(?) 이러면 할말이 없는데…ㅠㅠ) 송창현 네이버 CTO님의 keynote" 송창현 네이버 CTO님의 keynote 작년에는 거의 로봇잔치로 느껴졌는데 올해는 그 기술들의 융합(?)잔치 로 받아들여졌다. Ambient Intelligence 를 강조하시며 기술의 진정한 가치는 기술이 생활속으로 사라졌을 때 나온다라는 명언같은 말씀도 해주셨다. 연결 : 사물, 상황, 위치인식, 이해 발견 : 적시에 답, 추천, 액션제공 그리고 그와 관련된 네이버 서비스를 공개 하셨는데, 네이버 지도 Map API를 무제한/무료로 사용할수 있게 된다고 한다. (박수 유도하심 ㅎㅎ) 또한 이번에 가장 크게 바뀌는 네이버 모바일 홈 페이지인 그린닷, 지도 기술들의 종합 플랫폼인 xDM Platform(측위, 지도, 내비), 그리고 자율주행과 로봇에 대해 연구결과 그리고 앞으로의 방향성에 대해 정리해주셨다. 집에 돌아와서 검색좀 하다보니 테크수다에서 벌써(?) 영상을 하나 올린게 있어 공유해본다. 키노트를 다 듣고 작년에는 그런가보다 하고 별생각이 안들었는데 올해는 저런 기술들이 서비스 레벨까지 가는데 이렇다할 허들없이 사용자들에게 보여질수만 있다면 개발자로서 보다 더 큰 자부심을 가지고 기술개발에 정진할텐데… 하는 씁슬한 생각을 해보게 되었다. (물론 이런 부분들도 다 사정이 있을꺼라 생각이 들지만 안타까운건 감출수가 없을것 같다.) 이틀에 걸쳐 이런저런 다양한 세션들을 들을수 있어 좋았는데 몇몇 세션들은 기본지식이 없어 (AI, 머신러닝 등…ㅠ) 이해하기 힘들었다. 내년엔 이해할수 있도록 준비를 해서 오자며 또다짐을 하고… 그나마 조금이라도 이해할수 있었던 세션들 몇개만 정리해본다. React Native: 웹 개발자가 한 달 만에 앱 출시하기 React Native: 웹 개발자가 한 달 만에 앱 출시하기" React Native: 웹 개발자가 한 달 만에 앱 출시하기 지난팀에서 아주 잠깐 React를 경험해보긴 했지만 거의 hello world 수준이였기 때문에 이 세션 역시 이해가 잘 되지 못했다. 하지만 필자처럼 이해를 잘 못하는 사람도 발표자가 전달하려는 목적이 무엇인지 알수 있을 정도로 전체적인 흐름은 조금이나마 이해를 할수 있었고 특히 개발하면서 좋았던 것이나 경험담을 알려주며 삽질공유를 해주는게 듣기 좋았다. React Native 는 빠른개발을 할수있고 코드공유가 쉬우며 개선이 쉽다는 장점이 있다고 한다. 또한 단기간에 크로스 플랫폼을 만들어야 할때 사용한다고 하니 나중에 참고해봐도 좋을듯 싶다. 발표자료 : https://www.slideshare.net/deview/121react-native LINE x NAVER 개발 보안 취약점 이야기 LINE x NAVER 개발 보안 취약점 이야기" LINE x NAVER 개발 보안 취약점 이야기 버그바운티라는 신기한(?)프로그램에 대한 소개와 운영에 대한 내용을 발표해 주셨다. 가끔 사내에서도 버그를 잡으면 포상을 드려요 라는 글이 올라왔었는데 그때마다 손안데고 코풀려나 하는 비뚤어진(?