초창기 신입시절에 배우거나 사용했던 기술적인 방법들이 있다. 시간이 지날수록 왠만해선 다른방법은 사용하지 않으려 하고 습관처럼 기존에 사용했던 방법을 고수하는 버릇이 있다. 그 이유는 과거에 사용했을때 아무 탈 없이 잘 되었기 때문에, 그리고 빠른 구현 때문이라는 핑계일 것 같다. 이러한 버릇은 비단 이 글을 적고있는 필자 뿐만이 아니라 대부분의 개발자들이 가지고 있을꺼라 조심스레 추측해본다. (아니라면…더욱 분발 해야겠다…ㅠ) 최근 운영하고 있는 서비스에서 장애 상황까지 갈수있는 위험한 상황이 있었는데 팀내 코드리뷰를 통해 문제점을 파악할 수 있었다. 그 원인은 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 개발 보안 취약점 이야기 버그바운티라는 신기한(?)프로그램에 대한 소개와 운영에 대한 내용을 발표해 주셨다. 가끔 사내에서도 버그를 잡으면 포상을 드려요 라는 글이 올라왔었는데 그때마다 손안데고 코풀려나 하는 비뚤어진(?

IT관련 행사에 참여하면 여러가지 정보를 얻을수 있다. 개인적으로는 사실 정보를 얻기 위함보다 그곳의 분위기를 현장에서 몸소 느끼고 참여한 사람들의 눈빛을 보며 해이해진 마음가짐을 다시 다잡을수 있음이 가장 큰 목적이다. 그에 올해 Pycon도 하나의 전환점이 되길 바라는 마음으로 신청을 하게 되었다. 등록 https://www.pycon.kr 얼리버드 등록을 한다고 Facebook에서 홍보를 하길래 그런가보다 했는데 잠깐 회사일에 집중하고 다시 보니 이미 매진이 되어있었다. 사실 Pycon 은 올해가 처음 가보는거라 인기를 실감할수 없었는데 이정도일줄은 상상도 못했다. (나중에 알게 된 사실이지만 올해가 가장 인원이 많았다고…) 그래서 나중에 진행되었던 일반표 등록은 휴대폰 알람까지 걸어두며 늦지않게 등록할수 있었다. 세부 일정들이 업데이트가 되고 어떤 세션을 들을까 고민하면서 간략 소개를 하나둘씩 보게 되었는데 Python을 만지며 평소에 궁금했던거나 재밌어 보이는 세션들이 너무많아 고민을 많이 했다. 한가지 아쉬운건 로그인 기반이 아니다 보니 (임시 로그인기반?) 내 시간표 설정하는게 없었다. 나는 별도로 적어서 갔지만 나중엔 그런 기능이 생겼으면 좋겠다. 2019년 Pycon엔 크롬 익스텐션으로 기능을 만들어 로그인 여부와 상관없이 몇시에 내가 어떤 세션을 들을건지에 대한 설정을 하고 이를 이미지로 캡쳐해서 출력/다운 받을수 있는 걸 만들어 보고 싶다. (그전에 미뤄뒀던 크롬 익스텐션 개발하는 방법부터 공부하자…) 첫째날 개인적으로 아침잠이 너무 많은데 알림이 울리기도 전에 눈이 떠졌고 행사장에 도착해보니 후원사 부스는 아직 텅텅 비어있었고, 밤새가면서 준비를 하셨는지 자원봉사자 분들은 여기저기 빈백에 누워(쓰러져) 자고 있었다. 그만큼 Pycon에 대한 기대가 컸나보다. 시간이 지나니 하나둘씩 사람들이 등록을 하며 오기 시작하였고 역시나 행사에 꽃중에 꽃인 후원사 부스에서 나눠주는 이벤트 상품들을 받기 바빴다. DIVE INTO DIVERSITY !!" DIVE INTO DIVERSITY !! 키노트를 시작으로 사람들은 각자 듣고싶은 세션에 참가하며 행사는 시작이 되었다. 전체적으로 기술의 난이도는 초급 수준의 발표였던걸로 느껴졌다. (물론 나는 초초초급도 안되는 꼬꼬마 수준이지만…) 대부분 Python으로 어떤걸 해봤고, 어떤 어려움이 있었고, 이러저러한 상황들을 만났으며, 요런 경우에서는 어떻게 하며 해결을 하였다는 등 기술을 활용한 “경험기"에 대한 내용들을 들을수 있었다. Pycon의 슬로건인 DIVE INTO DIVERSITY에 걸맞게 아주 다양한 주제로 흥미있는 발표내용들이였다. 기억나는 것들중에 인상깊었던 부분들을 정리해본다. 파이썬 문화(?)중의 하나는 몰라서 물어보는 사람에게 구글링을 하라기보다 직접 알려주라는 것이다. 배우고 싶다면 다른사람들을 가르치는것부터(알려주는것부터) 시작하라. 여성 개발자, 여성 발표자들도 점점 늘어나고 있다. 파이썬을 개발 현장(?)이 아닌 다른곳에서 사용한다면 작업 속도도 빠르고 얻어내는 가치또한 훨씬 더 방대하다. 엑셀로 할수 있는 작업을 파이썬으로 할수 있다. 파이썬의 다양한 라이브러리는 일상의 도움을 준다. 행사를 들으며 꼭 질문을 해야지 하는 마음을 갖고 있었는데 (그래야 오래 기억에 남으니) 마침 어떤 세션에서 궁금한게 있어 질문을 할수 있었다. (질문을 하니 파이썬 관련 책 선물도 받았다.^^) 그리고 마지막 라이트닝 톡이라는 세션이 있었는데 여러 발표자들이 짤막하게 5분동안 하고싶은 이야기를 하는 세션이였다. 5분이라는 제한이 있기에 다들 쉽고 편하게 발표하는듯 보였으나 발표 자료나 발표내용을 보면 꼭 그렇게 간단하게 발표하는건 아니였다. 본 세션에서 말하기엔 다소 분량이 작은 알차고 깨알같은 발표도 있었고, 매년 Pycon 라이트닝톡에 발표하는게 목표이신 분도 있었다. 발표를 들으면서 난 언제 저런자리에 가서 발표를 할수 있을까 하는 마음이 스쳐 지나갈때 쯤. “왜못하지? 나 파이썬으로 만든거 있잖아?” 라고 혼잣말로 궁시렁거리며 둘째날에 있는 라이트닝톡에서 발표하기로 마음을 먹고 서둘러서 참가 신청을 보냈다. 그러고서는 저녁을 먹고 집에 늦게 돌아와 새벽 3시넘어서야 발표자료를 완성하였지만 “발표” 라는 부담감때문에 어렵게 잠에 들었다. 둘째날 어제와는 달리 오늘은 잠을 많이 못자서 인지 늦게 일어나 첫 세션이 시작하고서 거의 끝날 즈음에 행사장에 도착하게 되었다. “괜히 발표 한다고 한걸까” 라는 생각이 들며 진행위 본부에 가서 발표 순서를 확인해보니 첫번째… 슬슬 머리가 아파오기 시작했다.

자바(Java)로 개발을 하다보면 한번쯤 객체를 복사하는 로직을 작성할때가 있다. 그때마다 나오는 이야기인 Shalldow Copy 와 Deep Copy. 한국어로 표현하면 얕은 복사와 깊은 복사라고 이야기를 하는데 이 두 개념의 차이는 아주 간단하다. 객체의 주소값을 복사하는지, 아니면 객체의 실제 값(value)를 복사하는지. 이 둘의 차이점을 소개하는 글들은 워낙 많으니 패스하도록 하고 이번 포스팅에서는 Deep Copy를 할때 org.apache.http.client.utils 하위에 있는 CloneUtils 사용법에 대해 정리 하고자 한다. 그냥 쓰면 되는거 아닌가? 라고 생각했지만 (별거 아니라고 생각했지만) 해보고 안해보고의 차이는 엄청컸고 사용할때 주의점이 몇가지 있어 정리 하려고 한다. 예제에 앞서 본 포스팅에서 사용할 객체를 간단히 정리하면 다음과 같다. (학교에서 학생 신상정보를 관리한다고 가정해보자.) public class Student { String name; // 이름 int age; // 나이 Family family; // 가족 } public class Family { String name; // 이름 int age; // 나이 boolean isOfficeWorkers; // 직장인 여부 } public class PhysicalInformation { int height; // 키 int weight; // 몸무게 } 객체는 Cloneable interface 를 implement 해야하고 clone 메소드를 public 으로 override 해야한다. 당연한 이야기가 될수도 있으나 CloneUtils를 사용하기 위해서는 해당 객체는 Cloneable interface 를 implement 해야한다. 그리고 나서 clone 메소드를 override 해야되는데 여기서 가장 중요한점은 외부에서도 호출이 가능해야하기 때문에 public 으로 override를 해야한다. (기본은 protected 로 되어있다.) 우선 간단히 객체를 생성하고 출력부터 해보자. (출력을 이쁘게 하기 위해 ToStringBuilder.reflectionToString을 사용하였다.) PhysicalInformation physicalInformation = new PhysicalInformation(); physicalInformation.height = 180; physicalInformation.weight = 70; System.out.println(ToStringBuilder.reflectionToString(physicalInformation, ToStringStyle.DEFAULT_STYLE)); 결과는 당연히 PhysicalInformation@5d6f64b1[height=180,weight=70] 이제 Cloneable interface 를 implement 하고 clone 메소드를 public 으로 override 한뒤, CloneUtils를 사용해서 객체를 복사해보자. 테스트를 하면서 Shalldow Copy도 해보자. // class setting public class PhysicalInformation implements Cloneable{ int height; int weight; @Override public Object clone() throws CloneNotSupportedException { // public 으로 바꿔주자. return super.clone(); } } // test code PhysicalInformation physicalInformation = new PhysicalInformation(); physicalInformation.height = 180; physicalInformation.weight = 70; PhysicalInformation physicalInformationShalldowCopy = physicalInformation; PhysicalInformation physicalInformationDeepCopy = null; try { physicalInformationDeepCopy = (PhysicalInformation)CloneUtils.clone(physicalInformation); } catch (CloneNotSupportedException e) { e.printStackTrace(); } // 원본 System.out.println(ToStringBuilder.reflectionToString(physicalInformation, ToStringStyle.DEFAULT_STYLE)); // 얕은 복사 System.out.println(ToStringBuilder.reflectionToString(physicalInformationShalldowCopy, ToStringStyle.DEFAULT_STYLE)); // 깊은 복사 System.out.println(ToStringBuilder.reflectionToString(physicalInformationDeepCopy, ToStringStyle.DEFAULT_STYLE)); // 값 변경 physicalInformation.weight = 80; physicalInformation.height = 170; // 원본 System.out.println(ToStringBuilder.reflectionToString(physicalInformation, ToStringStyle.DEFAULT_STYLE)); // 얕은 복사 System.out.println(ToStringBuilder.reflectionToString(physicalInformationShalldowCopy, ToStringStyle.DEFAULT_STYLE)); // 깊은 복사 System.out.println(ToStringBuilder.reflectionToString(physicalInformationDeepCopy, ToStringStyle.DEFAULT_STYLE)); 결과는 원본과 얕은 복사를 한것은 메모리 주소(?)가 같으나 깊은 복사를 한것은 데이터는 같지만 주소가 다르고 값을 변경해도 영향을 주지 않는다. (완전히 서로다른 객체인것을 증명) PhysicalInformation@1376c05c[height=180,weight=70] PhysicalInformation@1376c05c[height=180,weight=70] PhysicalInformation@1b4fb997[height=180,weight=70] PhysicalInformation@1376c05c[height=170,weight=80] PhysicalInformation@1376c05c[height=170,weight=80] PhysicalInformation@1b4fb997[height=180,weight=70] 만약 위에서 clone을 기본값인 protected로 override를 하게 되면 어떤 결과를 가져올까? Exception in thread "main" java.lang.NoSuchMethodError: com.PhysicalInformation.clone() at org.apache.http.client.utils.CloneUtils.cloneObject(CloneUtils.java:55) at org.apache.http.client.utils.CloneUtils.clone(CloneUtils.java:77) at com.Test.main(Test.java:16) 접근제한자에서 눈치를 챌수도 있었겠지만 접근을 할수없어 CloneUtils 이 리플렉션을 하는 과정에서 Exception을 발생한다. 꼭! public 으로 override를 해주자. 객체 내에 clone이 안되는 변수는 별도 처리가 필요하다. 객체 내에 있는 멤버 변수는 원시 변수(int, char, float 등) , Immutable Class (String, Boolean, Integer 등) 또는 Enum 형식일 때는 원본의 값을 바로 대입해도 되지만, 그렇지 않을 때는 멤버변수의 clone을 호출하여 복사해야 한다. 말로만 보면 무슨이야기 인지 모르니 예제를 보자. public class Student implements Cloneable { String name; int age; Family family; @Override public Object clone() throws CloneNotSupportedException { return super.clone(); } } Student 클래스에서 Cloneable 를 implements 하고 clone 메소드를 override 하였다. (여기서 구멍이 있다!

1부에서는 기술블로그 구독서비스(이하 서비스)를 왜 만들게 되었고 어떤구조로 만들가에 대해 이야기를 해보았다면, 이번 포스팅에서는 만들면서 만나게 된 각종 트러블슈팅 종합세트(?)를 하나씩 풀어보고자 한다. 물론 개발을 하면서 아무 문제 없이 잘 되면 당연히 좋겠으나 잘되도 이상한게 개발이라는 세계가 아니던가. 잘 안되면 문제, 잘 되도 문제 ㅠㅠ 출처 : https://www.clien.net/service/board/park/9111495" 잘 안되면 문제, 잘 되도 문제 ㅠㅠ 출처 : https://www.clien.net/service/board/park/9111495 1부 : 왜 만들게 되었는가 그리고 어떤 구조로 만들었는가 2부 : 문제발생 및 Trouble Shooting 3부 : 앞으로의 계획과 방향성 지난 1부에서 이야기 했던것처럼 문제 - 해결, 문제 - 해결 식으로 나열해보고자 한다. 다소 글의 전개가 뒤죽박죽일수도 있겠지만 말 그대로 트러블슈팅 종합세트이니 독자들의 양해를 미리 구한다. 트러블 슈팅 리스트 10시에 로직이 실행되었지만 메일을 11시 넘어서 받게 된다. 제목없는 글? 블로그 RSS파싱 오류? 간헐적으로 오류가 생긴다. 메일 내에 class를 적용하여 CSS 처리가 불가능하다. 메일을 보냈으나 스팸으로 처리된다. Elastic Stack을 사용할수 없다. 메일 보내는 발송속도가 너무 느리다. 구독해제가 아닌 자체 수신거부는 어찌 처리할까? 10시에 로직이 실행되었지만 메일을 11시 넘어서 받게 된다. 👉 해결방안 : Divide and Conquer 본 서비스의 요구사항중 하나는 매일 오전 10시, 구독자들에게 어제 등록된 글을 수집하여 메일로 보내주는게 있다. 우선 로직은 다음과 같은 순서로 진행되게 개발하였고, jenkins 등 별도의 스케쥴러 관리 어플리케이션에 의해 할수도 있었으나 이 또한 심플하게 crontab 에 등록하여 매일 오전 10시에 실행되도록 하였다. 1. awesome-devblog 에서 블로거들의 RSS 피드를 조회한다. 2. 어제 등록된 글이 있다면 리스트에 담는다. 3. 조회가 끝나면 메일형식에 맞추어 html 문자열을 만든다. 4. 만들어진 문자열을 가지고 등록된 구독자들에게 메일을 보낸다. 로직은 아주 간단했다. 데이터를 파싱하는 방법이나 메일형식에 맞추어 html문자열을 만드는 등 별도의 라이브러리를 사용하는 다소 복잡한 부분만 빼면 단순히 for문과 if문을 조합해서 로직을 구성할수 있었다. 헌데, 10시에 해당로직이 실행되었지만 최대 1시간이 지나고서야 메일을 받는 경우도 있었다. 이게 무슨일일까!? 눈치를 챘을수도 있지만 RSS 피드를 조회하는 곳에서 오래걸린 것이다. 티스토리나 네이버등 다른 블로그들은 RSS를 읽고 파싱하는 속도가 그렇게 오래 걸리지 않았는데 (1초 이내) 유독 이글루스 블로그의 RSS파싱이 오래걸리는건 1분까지도 걸리던 것이였다. ( 참고로 RSS 파싱모듈, yaml 파싱모듈 을 사용했다. ) 아마 RSS의 형식이 약간 달라서 그런것 같긴 한데 그렇다고 이글루스 일 경우에 파싱을 다르게 하는건 좀 그렇고… 추후 이글루스가 아닌 또다른 파싱속도가 느린 블로그의 RSS를 만날수도 있기에 RSS 타입별로 예외처리를 하는건 좀 아닌것 같았다. 이런저런 고민끝에 아주 간단하게도 임무(?)를 나누는식으로 해결 하였다. 즉, RSS를 읽고 메일에 보낼 데이터를 만드는 job 하나와 만들어진 데이터를 가지고 이메일을 보내는 job 으로 나눈뒤 RSS를 분석하는 job은 9시에, 메일보내는 job은 10시에 보내도록 해서 생각보다 아주 심플하게 문제를 해결할수 있었다. 복잡하고 어려운 문제를 꼭 복잡하고 어렵게만 해결해야하는 법은 없는것 같다. 모로 가도 서울만 가면 된다라는 속담이 있지 않는가. 제목없는 글? 블로그 RSS파싱 오류? 간헐적으로 오류가 생긴다. 👉 해결방안 : 언제나 신경써야 하는 예외처리(try-catch) 내가 만든 코드는 언제나 내 생각대로만 돌아갔으면 하는건 모든 개발자의 마음과 같다. 흔한 IT 종사자들.deploy 출처 : https://9gag.com/gag/a0Yxw4B/operations-team-before-leaving-for-holidays" 흔한 IT 종사자들.deploy 출처 : https://9gag.com/gag/a0Yxw4B/operations-team-before-leaving-for-holidays 하지만 그생각도 잠시 언제나 예외는 발생하기 마련. ( 물론 전혀 예외가 발생 안할수도 있으나 만약 발생하지 않았다 할지라도 발생할수 있는 가능성은 염두해둬야 한다. ) 파싱하는 과정에서 제목이 없는글로 온다거나, 가끔 RSS url 응답이 404 또는 503 인 경우가 있었다. 참고로 필자는 출근이 늦은편이라 아침마다 늦잠을 자곤 했는데 이 서비스를 만들면서 덕분에(?