웹서버 하나만 사용하거나 WAS 하나만을 사용하며 웹서비스를 운영하는 경우는 극히 드물다. 웹서버의 장점과 WAS의 장점 그 두마리의 토끼를 다 잡기 위해 보통 앞단에 웹서버를 두고 그 뒤에 WAS를 두며 서비스를 운영하곤 한다. 헌데 운영하는 서비스가 인기가 많아져(?) 사용량이 많아지다면 그만큼 응답이 느려 (TPS 등) 서버를 늘려야 하는 상황이 생긴다고 가정해보자.(물론 서버를 늘리는 것보다 캐시를 적용하거나 로직을 바꿔보는 노력이 선행되야 하겠지만…) 당연히 서버부터 구매하며 “Scale Out"을 하려고 할것이다. 만약 원래 운영하던 서버가 너무 좋아서 CPU나 메모리 사용률이 거의 바닥이여도 서버를 구매해야 할까? 서버를 구매하게되면 결국 두개 이상의 서버가 운영될텐데 그 서버들을 앞에서 묶어주며 트래픽을 분산시켜주는 무언가가 필요하다. 그러한 기술을 바로 로드밸런싱 이라고 한다. 통상 L4 스위치를 활용하여 요청을 여러 서버들로 분산시키며 산술적으로는 서버 대수만큼 성능이 좋아지는 효과를 볼 수 있다. 하지만 앞서 말했듯 서버의 자원 사용률이 바닥일 정도로 거의 사용을 안할경우 서버를 구매하는건 너무나 비효율적이다. 이번 포스팅에서는 서버를 늘리지 않으면서 웹서버 중 아파치를 활용하여 여러 WAS를 운영하는 방법에 대해 알아보고자 한다. 서버 늘려야 하는 상황에서 사용해 볼 수 있는 나만의 좋은 무기(?)가 생긴게 아닐까 생각이 든다. 아파치는 EOL이 되었기 때문에 2.4버전으로 설치하고, WAS는 편의상 톰켓 최신버전으로 설치해서 동일한 서버에 아파치 한대와 톰켓 3대를 연동하는것을 목적으로 한다. 로드밸런싱이 어떤식으로 이루어 지고 하위에 연결된 톰켓을 컨트롤 하는 방법 또한 알아볼 예정이다. 서버 환경 및 설치하게 될 각 버전은 다음과 같다. 서버 : CentOS 7.4 64Bit apache : httpd-2.4.39 tomcat : apache-tomcat-8.5.43 tomcat-connectors(mod_jk) : 1.2.46 Apache 와 Tomcat 설치 필자의 포스팅에서 종종 나오는 부분이기도 하고, 구글링 해보면 바로 설치 방법을 쉽게 찾을 수 있겠지만 그렇다고 언급을 안하고 넘어가기엔 너무 불친절하니… 치트키처럼(?) 빠르게 정리해보자. Apache $ wget http://apache.tt.co.kr//httpd/httpd-2.4.39.tar.gz $ tar -zxvf httpd-2.4.39.tar.gz $ ./configure --prefix=/home/~~~/apache $ make && make install $ cd /home/~~~/apache/bin $ sudo chown root:계정명 httpd $ sudo chmod +s httpd $ vi /home/~~~/apache/conf/httpd.conf User 계정명 Grop 계정명 $ /home/~~~/apache/bin/apachectl start ← 실행 이렇게 설치를 한뒤 실행을 시키고 서버의 ip를 접속해보면 아래와 같은 화면을 볼 수 있다. Tomcat $ wget http://mirror.apache-kr.org/tomcat/tomcat-8/v8.5.43/bin/apache-tomcat-8.5.43.tar.gz $ tar -zxvf apache-tomcat-8.5.43.tar.gz $ /home/apache-tomcat-8.5.43/bin/start.sh ← 실행 톰켓의 기본 http 포트인 8080으로 접속을 해보면 귀여운 고양이가 있는 톰켓 기본화면을 볼 수 있다. 아파치와 톰켓 연동하기 아파치와 톰켓의 연동은 mod_jk 와 mod_proxy 등 다양한 모듈로 연동을 할 수 있는데 이번 포스팅에서는 mod_jk 를 활용하는 방법에 대해 알아보고자 한다. 우선 mod_jk 를 설치하자. 간단히 mod_jk 는 컴파일, 설정 등 복잡하지만 톰켓 전용 바이너리 프로토콜인 AJP를 사용하기 때문에 높은 성능을 기대할수가 있다. mod_proxy 는 반면 기본으로 아파치에 탑재되어있는 모듈이기 때문에 별도의 모듈 설치가 필요 없고 설정도 간단하다는 장점이 있다. 각 연동방식의 장단점이 있기 때문에 본인이 운영하는 서버 상황에 맞추어 적용 할 필요가 있다. mod_jk 설치 $ wget http://apache.tt.co.kr/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.46-src.tar.gz $ tar -zxvf tomcat-connectors-1.2.46-src.tar.gz $ cd tomcat-connectors-1.2.46-src/native $ ./configure --with-apxs=/home/~~~/apache/bin/apxs $ make && make install $ /home/~~~/apache/modules 하위에 mod_jk.so가 생김 mod_jk 를 활용하면 AJP라는 통신으로 아파치와 톰켓이 연동되는데 톰켓의 기본 AJP 포트는 8009번임을 알고 다음처럼 설정을 해주자. apache/conf/workers.properties worker.list=tomcat1 worker.tomcat1.port=8009 worker.tomcat1.host=localhost worker.tomcat1.type=ajp13 worker.tomcat1.lbfactor=1 apache/conf/httpd.conf LoadModule jk_module modules/mod_jk.so <IfModule jk_module> JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel info JkMount /* tomcat1 </IfModule> 이렇게 하고서 아파치와 톰켓을 재시작 후에 서버의 ip로 접속해보면 (별도의 port 없이) 톰켓 설정페이지로 랜딩이 되는것을 확인할 수 있다.

개발을 하다보면 실제로 직접 구현을 해본적은 없지만 여기저기서 들어본 지식과 그 동안의 짬밥(?)으로 추측해볼수 있는 부분들이 있다. 물론 모든일에 정답은 없겠지만 요즘 느끼는건 책에서 공부만 해본것과 다른 블로그들에서 눈으로만 보고 넘어가는것들 그리고 직접 손가락을 움직여가며 왜 여기서는 이 방법을 사용하지 고민하면서 구현을 해본다는건 정말 엄청나게 큰 차이가 있는것 같다. 웹 어플리케이션을 개발하다보면 한번 쯤 만나게 되는 파일 업로드 기능. 필자도 몇번 구현은 해봤지만 그냥 단순히 구현만 해본 상태였다가 최근에 그냥 파일 업로드가 아닌 대용량 파일 업로드에서의 문제가 발생하여 여기저기 삽질을 하게 되었고 정리도 해볼겸 스프링에서의 대용량 파일 업로드시 한번쯤 고려해봐야 할 부분에 대해 정리를 해보려고 한다. 물론 구글에서 검색을 해보면 아마 필자가 쓴것 보다 더 자세하고 좋은 글들이 있겠지만 필자는 보다 대용량에 집중에서 작성해 보고자 한다. 명심하자. “아무리 흐린 잉크라도 좋은 기억력보다 낫다” 라는 말이 있듯이 스프링을 활용한 파일 업로드 구현 우선 완전 초기상태에서 시작하기 위해 스프링 부트 프로젝트를 만들고 간단하게 파일 업로드를 할 수 있는 form 페이지와 업로드 버튼을 눌렀을때 작동하게 되는 컨트롤러를 만들어 보자. import java.io.File; import java.io.IOException; import java.io.InputStream; import org.apache.commons.io.FileUtils; import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.multipart.MultipartFile; import lombok.extern.slf4j.Slf4j; @Slf4j @Controller public class FileUploadController { // 너무 간단 ... @RequestMapping("/form") public String form() { return "form"; } @RequestMapping(value = "/upload", method = RequestMethod.POST) public String upload(@RequestParam("file") MultipartFile multipartFile) { log.info("### upload"); File targetFile = new File("/home1/irteam/" + multipartFile.getOriginalFilename()); try { InputStream fileStream = multipartFile.getInputStream(); FileUtils.copyInputStreamToFile(fileStream, targetFile); } catch (IOException e) { FileUtils.deleteQuietly(targetFile); e.printStackTrace(); } return "redirect:/form"; } } upload 요청이 들어오면 file이라는 이름의 파라미터로 MultipartFile을 받고 파일의 이름을 확인 후 스트림을 읽어 특정 경로에 파일로 저장하는 로직이다. 그다음 /form을 접속하게 되면 나오는 폼 화면을 만들자. 이것도 아주 심플하게! <h1>파일 업로드</h1> <form action="/upload" method="post" enctype="multipart/form-data"> <input type="file" value="파일 선택" name="file"/> <input type="submit" value="업로드"/> </form> multipart/form-data 라는 Content-Type 을 명시해주고 파일을 선택하면 /upload로 POST요청을 하도록 설정한다. 이렇게 되면 너무 간단하게 + 이상없이 파일이 업로드가 잘 되니 이게 이야기 할 꺼리인가(?) 싶을정도로 심플하다. 그런데 파일 크기가 크다면? 설마 파일 업로드 하는 용량이 크겠어?… 왠지 파일의 용량이 크면 문제있을것 같은데… 출처 : https://m.blog.naver.com/naibbo0407/30170815180" 설마 파일 업로드 하는 용량이 크겠어?… 왠지 파일의 용량이 크면 문제있을것 같은데… 출처 : https://m.blog.naver.com/naibbo0407/30170815180 개발을 하다보면 항상 생각해야 할 부분중에 하나가 바로 확장성인것 같다. 이 부분에서 역시 문제가 되었던 것. 평소보다 용량이 큰 파일이 업로드가 되면서 (평소 3~400MB 였다가 3~4GB정도의 파일이 업로드가 되는 매직) 업로드가 안되는 상황이 발생하였다. 당연히 문제가 발생하면 누군가 말했듯 로그부터 살펴보았는데 Apache - (AJP) - Tomcat 으로 구성된 환경에서 tomcat 로그에 ### upload라는 로그가 없고 아파치 로그엔 502 에러가 발생한 것이었다. 왜 톰켓 로그도 안남고 그전에 에러가 발생하였을까? 이때부터 (근거없는 추측을 하며…) 고난과 역경의 삽질을 하기 시작하게 된다. 톰켓 버전이 문제일까? 로그가 안찍혔다면 다른 필터나 인터셉터에서 무언가를 먹고(?)있는건 아닐까? 잠깐, 근데 원래 대용량 업로드가 되긴 해? 파일 업로드/다운로드 하는 사이트 보면 별도 프로그램으로 하던데… 꼬불꼬불 미로속을 헤메는것만 같았던 삽질의 문제는 결국 메모리에 있었다. 파일을 업로드 하게 되면 해당 내용을 우선 메모리에 담게 되고 다 담은 후 메모리에 있는 내용을 was에 전달한 뒤 HttpServletRequest 로 넘어오게 된다.(Apache > Tomcat) 그런데 파일을 업로드 하면서 메모리에 파일이 써지다가 메모리 부족으로 OOM이 발생하게 되버린 것이었다. 또한 스프링 파일 최대크기를 별도로 지정하지 않고 있었기 때문에 메모리가 충분했다 하더라도 에러가 발생했을 상황이었다.

누구나 어렸을 땐 빨리 어른이 되고 싶어 하는 것 같다. 시간이 빨리 지나가길 바라고, 빨리 어른이 되고 싶다는 간절함이 있지만 이상하게도 그땐 시간이 천천히 가는 것처럼 느껴졌다. 반면, 시간이 천천히 갔으면 하는 때가 있다. 딱 지금. 남들은 워어어어얼화아아수우우모옥금퇼 이라고 부르며 시간이 느리게 간다고 빨리 주말이 왔으면 좋겠다고 하지만 요즘의 필자는 정 반대다. 방금 출근한 것 같은데 어느샌가 퇴근인사를 주고받고 있다. 무언가에 홀린 것 같다. 벌써 올해도 절반이 지나가고 뜨거운 여름과 함께 후반전이 시작되었다. 그래서 빨리 지나갔나…출처 : https://m.blog.naver.com/kong6482/220584667861" 그래서 빨리 지나갔나… 출처 : https://m.blog.naver.com/kong6482/220584667861 이제까지는 12월 말 즈음에 한 해를 바라보고 리뷰를 했었는데 글또라는 글쓰기 모임에 가입을 하게 되어 상반기 리뷰를 해보려 한다. 글또 모임의 첫 숙제가 상반기 리뷰 포스팅이다. 사실 리뷰를 상반기에 하던 연 말에 한 해 기준으로 하던 정해진 건 없지만 나를 다시 바라보고 다잡는 시간이 많을수록 보다 더 앞으로 가는데 힘이 될 거라는 데에는 이견이 없다. 회사 속에서의 나 회사에서는 회사일이 최우선!출처 : https://m.blog.naver.com/hwee__/221191852972" 회사에서는 회사일이 최우선! 출처 : https://m.blog.naver.com/hwee__/221191852972 최근에 팀장님과 면담 중에 나온 이야기다. 신기하게도 군 시절 장기를 꿈꾸던 필자를 어서 전역하라고 권유하시던 대대장님께 매일같이 들었던 이야기와 비슷하다. “이제는 단순 개발만 하고 기능구현만 하는 것이 아니라 그 이상을 해야 할 시기가 다가온다.” “사람들 관리가 될 수도 있고 어느 한 분야에 전문가가 되어야 할 수도 있고, 선택은 본인의 몫” 사실 기능 구현이야 누구나 다 할 수 있다. 단지 경험에 따른 구현의 속도나 안정성의 차이가 아닐까 생각해본다. 그렇다면 그 이상은 어떻게 해야 할까? 정답은 없겠지만 필자는 그 이상을 해보려 우선 팀에 도움이 되기 위해 여러 가지 자동화 툴 들을 만든 것 같다. 보다 기능 개발에 집중하고 단순 반복적인 업무는 시스템이 할 수 있도록. 그렇게 툴들을 만들어 가며 생각하지 못한 부분들을 배우게 되고 나중에 그걸 또 사용하게 되는, 미래의 나를 위해 강제로 배우고 있는듯한 느낌이랄까. 아, 물론 회사 본연의 업무가 최우선이지만 말이다. 어쨌든 시킨 일은 우선 차질 없이 잘 하고 시키지도 않은 일을 찾아서 하려고 노력했던 것 같다. 팀을 위해서, 곧 나를 위해서. 적어도 회사에서 있는 시간 속에서는 다른 곳에 한눈 안 팔고 회사 업무에 전념하려고 노력했던 것 같다. 외부 활동 부족한 시간을 쪼개면서 밋업이나 세미나에 참여하곤 했었다. 그리고 마냥 듣고만 오진 않았고 “행사에 참여하면 무조건 질문 하나는 하자"라는 나와의 약속을 지키며 정리한 내용을 블로그에 포스팅하기도 하였다. 올해 첫 발표!" 올해 첫 발표! 디자이너와 개발자가 함께하는 투게더톤을 진행하기도 했었다. 투게더톤은 약 한 달 동안 진행되는 해커톤으로 하루 또는 무박 2일 동안 하는 기존 해커톤과 다르다. 이 기간 동안 팀 내에서 자유롭게 일정을 조정할 수 있다. 우리 팀은 약 7주에 걸쳐 “동네 마트 할인 정보를 알려주는 앱” 을 만들게 되었다. 필자는 API 전반에 대해 담당을 하였고 작은 부분이었지만 웹사이트도 간단하게 만들어 보았다. 아무것도 없는 백지상태에서 시작하려니 막막했지만 후기에서도 적었듯이 다시 해보라고 하면 머릿속에 전체 아키텍처가 그림으로 그려질 만큼 자신감이 생겼다. 특히 정말 좋은 팀원들과 함께 협업할 수 있어서 너무 좋았다. 내공 연마 한 달에 2개 이상 블로그 글을 작성하는 목표가 있었다. 그런데 지난달에 이사를 하다 보니 (핑계…) 목표를 달성 할 수가 없었다. 하지만 나름 퀄리티가 있는 글을 쓰려고 노력했고 PV도 작년보다 조금씩 오르고 있는 것 같아 내심 기분이 좋다. 그리고 작년 말부터 시작한 필자의 첫 토이프로젝트 인 기술블로그 구독서비스 에 이런저런 기능을 추가하였다. 설마 1000명이 넘게 구독 하겠어?

스프링 기반의 웹 어플리케이션을 만들다 보면 요청을 처리하는데 맨 처음에 위치하고 있는 Controller(이하 컨트롤러)라는 레이어를 만들게 된다. 그럴때면 사용자가 어떤 요청(Request)을 하였는지에 대해 확인이 필요할 수 있다. 물론 확인을 안해도 무방하지만 가급적 로깅은 시스템 로직에 영향을 주지 않는 범위에서 최대한 다양하게 미리 해두는게 나중에 유지보수시 편할 수 있다. (예전 조직장님께서 말씀하신게 아직도 머릿속에 꽉 자리잡고 있다…) 아~주 일반적으로, 컨트롤러에서는 다음과 같이 메소드 단위로 파라미터를 직접 로깅하게 된다. @Slf4j @RestController public class SampleController { @GetMapping("/test1") public String test1(@RequestParam String id) { log.info("id : {}", id); return "length : " + id.length(); } } 이렇게 되면 사용자가 GET /test1 이라는 요청을 보낼때 어떤 파라미터로 호출하였는지에 대해 로깅이 남게 되는데 항상 log.info("id : {}", id); 과 같이 수동으로 로깅을 남겨야 하는 불편함이 생긴다. 물론 꼼꼼하게 메소드마다 로깅을 적어주면 전혀 문제될게 없지만 이러한 컨트롤러 ~ 메소드가 한두개가 아닌 수십 또는 수백개일 경우엔 그때마다 로깅을 적어줘야 하는 불편함이 있을 수 있다. 또한 자칫 깜박하고 로깅을 빼먹고 배포를 하게 된 경우 모니터링시 로깅을 하지 않아서 다시 로깅하고 배포를 하는, 별것도 아닌데(?) “정말 불편한” 상황이 있을 수 있다. 이번 포스팅에서는 사용자의 요청을 모니터링 하기 위해 컨트롤러마다 코드를 작성해가며 로깅을 하는것이 아니라 HttpServletRequestWrapper 라는 것과 Filter, AOP를 이용하여 Request의 정보를 한곳에서 우아하게 로깅하는 방법에 대해 알아보고자 한다. 요구사항 와 개발하자아!출처 : https://gfycat.com/ko/brightevilaoudad" 와 개발하자아! 출처 : https://gfycat.com/ko/brightevilaoudad 투우사가 흔드는 빨간 천을 보며 돌진하는 황소처럼 (쓰고보니 너무 TMI 같다….) 당장 코딩을 시작하며 개발을 할 수도 있지만 정작 원하는 기능이 무엇인지 천천히 정리하고 넘어갈 필요가 있는 것 같다. (어쩔땐 오히려 후자가 더 빠른 개발을 하게 되는것 같다.) GET, POST 등 다양한 http method 로 구현된 모든 컨트롤러의 파라미터와 기타 Request 정보가 로깅이 되야 한다. 컨트롤러, 메소드가 늘어날때마다 별도의 코드 추가 없이 한곳에서 공통적으로 로깅이 되야 한다. URL 중 특정 패턴으로 들어오는 요청은 다른 방식으로 로깅을 하거나, 로깅에서 제외할 수 있어야 한다. 앞서 말했듯 다른 비지니스 로직에 영향을 주지 않아야 한다. 구현하기 - Request 의 파라미터 정리 Request 의 모든 로깅을 한곳에서 처리하기 위해서 filter(필터)를 활용하였다. 필터는 Dispatcher servlet의 앞단에 위치하고 있기 때문에 모든 정보를 확인할 수 있는데 용이하다. 물론 인터셉터를 활용해서도 방법이 있겠지만 본 포스팅 에서는 필터를 활용해서 구현하는것을 목적으로 한다. (사실 인터셉터로 몇번 시도해보다가 실패해서…유유 ) Spring MVC Request Life Cycle출처 : https://justforchangesake.wordpress.com/2014/05/07/spring-mvc-request-life-cycle/" Spring MVC Request Life Cycle 출처 : https://justforchangesake.wordpress.com/2014/05/07/spring-mvc-request-life-cycle/ Filter를 만들기 전에 Filter에서 사용할 주요 핵심(?) 클래스가 필요한데 HttpServletRequest 를 Wrapping 해서 사용하기 위해 HttpServletRequestWrapper를 상속받는 클래스를 만들자. Request 에 담겨있는 param 과 body로 요청이 들어올 경우 body에 있는 내용을 param 에 담는 로직이다. 주요 설명은 코드 안에서 주석으로 설명하겠다. public class ReadableRequestWrapper extends HttpServletRequestWrapper { // 상속 private final Charset encoding; private byte[] rawData; private Map<String, String[]> params = new HashMap<>(); public ReadableRequestWrapper(HttpServletRequest request) { super(request); this.params.putAll(request.getParameterMap()); // 원래의 파라미터를 저장 String charEncoding = request.getCharacterEncoding(); // 인코딩 설정 this.encoding = StringUtils.isBlank(charEncoding) ? StandardCharsets.UTF_8 : Charset.forName(charEncoding); try { InputStream is = request.getInputStream(); this.rawData = IOUtils.toByteArray(is); // InputStream 을 별도로 저장한 다음 getReader() 에서 새 스트림으로 생성 // body 파싱 String collect = this.getReader().lines().collect(Collectors.joining(System.lineSeparator())); if (StringUtils.isEmpty(collect)) { // body 가 없을경우 로깅 제외 return; } if (request.getContentType() != null && request.

회사일을 하다 보면 시키는 대로 혹은 팀의 목표에 부합하기 위해 어쩔 수 없이 해야 하는 일을 하게 된다. 그러한 일이 재미있고 결과물에 대한 만족도가 100% 라면 다행이지만 간혹 재미도 없고 시켜서 하는 일은 밤을 꼬박 새 가면서 완성을 해도 썩 그렇게 만족스럽지 못한 경우가 대부분인 것 같다.(물론 회사일에서 자신만의 인사이트를 찾는다면 금상첨화겠지만… + 매번 회사일이 재미없고 하기 싫은건 아님) 언제부터인지 필자도 이러한 부분에 갈증을 느끼며 회사와는 별도로 무언가를 만들어 보고 싶은 마음이 무럭무럭 생겨날 즈음 facebook 타임라인에서 개발자와 디자이너가 약 7주간 프로젝트를 진행하는 D.light 투게더톤 이라는 행사가 있다는 것을 발견하고 나름 정성스레 지원서를 작성 후 합격 메일을 받게 된다. (GDG Facebook 해당 게시글) 이번 포스팅에서는 해커톤과는 살짝 성격이 다른 D.light 투게더톤을 진행하면서 느꼈던 부분들과 진행한 결과물에 대해 간략히 리뷰를 해보며 정말 급행처럼 지나간 약 7주간을 돌이켜 보는 시간을 갖고자 한다. 팀 빌딩 눈도 못마주칠 정도로 어색한 첫날Team. 그팽" 눈도 못마주칠 정도로 어색한 첫날 Team. 그팽 총 6개 팀 중에 필자는 여자 디자이너 두 분, 남자 안드로이드 개발자 두 분을 포함한 팀에 속하게 되었다. 5명 중 해커톤 참여 경험이 있다는 이유만으로 여자 디자이너 분께서 팀장이 되시고, 7주라는 시간이 정말 급하게 지나갈 것 같다는 억지(?) 이유를 들먹여 그팽이라는 팀 이름이 정해졌다. 그렇게 “우리가 정말 무엇을 만들 수 있을까?” 하는 의구심 속에 프로젝트가 시작이 되었다. 프로젝트 진행 전반 신기하게도 우리 5명은 각각 사는 지역이 전부 달랐다. (심지어 한 분은 매주 저 멀리 충청남도 천안에서 올라오셔야 하는 수고를 ㅠㅠ) 매 주말마다 오프라인으로 만나서 회의를 진행했다. 그래야 길다면 길고 짧다면 짧은 7주 안에 완성도 높은 결과물을 만들 수 있을 것 같아서였다. 프로젝트의 주제를 정하는 아이디어 회의에서 정해진 우리의 목표는 “동네 마트 할인 정보를 알려주는 앱"을 만들기로 하였다. 시간가는줄 몰랐던 아이데이션 회의" 시간가는줄 몰랐던 아이데이션 회의 팀워크가 중요한 투게더톤 임에도 불구하고 여느 천재 디자이너, 천재 개발자처럼 일당백 스타일로 뚝딱 만드는 그런 프로젝트의 진행 방식은 피하려고 우리 모두가 노력하였다. 되도록이면 이렇게 모인 다섯 명이 한마음 한뜻으로 각자가 생각하는 크기와 양은 다르겠지만 이 프로젝트를 통해 무엇이라도 배울 수 있었으면 했다. 디자이너 분들은 서로 디자인하신 시안에 대해 공유를 하면서 개선해 나가는 모습과, 안드로이드 개발자 두분은 (거의 매일) 밤마다 서로 슬랙에서 개발 방법론에 대해 스터디를 하는 모습이 보기 너무 보기 좋았다. 물론 필자도 아무것도 없는 환경에서 백엔드 서버를 구축하고 API를 만드는 과정 속에서 정말 많은것을 배울 수 있었다. 그렇게 시간이 흘러 마지막 발표하는 전날엔 팀원 몇 분과 함께 꼬박 밤을 새우며 프로젝트 결과물의 완성도를 높이는데 노력하였고 필자 개인적으로 아주 성공적으로 프로젝트를 마무리할 수 있었다. 개발 진행 안드로이드 개발자분들은 코틀린 기반으로 개발을 하였다. 여러 디자인 패턴과 다양한 기술들을 사용하였다고 들었는데 필자는 아쉽게도 백엔드 개발을 하다 보니 전부를 이해하지는 못하였다. 예전에 토이 프로젝트를 파이썬 기반으로 해본 경험이 있어서 Flask 또는 Django 기반으로 API 서버를 구축해볼까 하고 고민하였다. 하지만 (Spring Boot 기반으로도 해보고 싶었고) 파이썬보다는 자바 기반으로 다양한 어플리케이션의 요구 사항을 개발하는데 조금 더 능숙할 것 같아서 Spring Boot 기반으로 개발 환경을 구성하였다. 서버는 AWS 프리티어의 EC2를 발급받고 DB 또한 AWS에서 제공해주는 RDS(mysql)을 발급받아 구성하였다. 그리고 DNS는 예전에 무료 도메인을 찾다가 알게 된 http://mooo.com/ 라는 서비스에서 발급받아 연결하였고, 프로젝트 기능 중에 서버에서 앱으로 푸시를 하는 기능이 있었는데 Firebase를 활용해서 구성할 수 있었다. 사용한 기술들" 사용한 기술들 Entity Relationship Diagram (ERD) 는 무료로 인터넷에서 사용할 수 있는 툴이 있는지 찾다보니 http://aquerytool.

실무에서 자바 기반으로 개발을 하고 서비스를 운영을 하다보면 처음엔 아무런 문제가 없다가 사용자가 몰리는 등 이벤트성으로 트래픽이 많아질 경우 꼭 문제가 생기기 마련이다. 그럴때면 뒤늦게 부랴부랴 원인을 찾고 개선하기 바빠지게 된다. (아마 윗분들에게 혼나면서?ㅠㅠ) 평소에 이런 성능문제를 개선하고 미리 모니터링 할수있는 부분에 대해 관심을 갖고 있었던 찰나, 우아한 형제들에서 5월 우아한 테크 세미나를 한다기에 부랴부랴 장문의 글로 신청을 하였고 운이 좋아 당첨이 되었다. 한창 회사에서 새로운 서비스 출시, 그리고 잠을 줄여가며 별도로 진행하고 있던 토이프로젝트 등 여러가지로 바쁜 시기였지만 특히 예전부터 뵙고싶던 이상민님께서 직접 강의를 해주신다기에 피곤한 심신을 이끌고 세미나에 참석하였고 그 후기를 적어보고자 한다. 두레이로 만드신 발표자료를 공유해 주셨지만 저작권 문제도 있고 해서 필자기준에서 이해한 부분에 대해서만 공유하고자 한다. 더불어 그냥 듣고 앵무새처럼 발표내용 그대로를 공유하는건 의미가 없다고 생각되어… 포스터만 봐도 벌써부터 가슴이 뛴다(?)." 포스터만 봐도 벌써부터 가슴이 뛴다(?). 성능 구글에서 작성한 성능이 중요한 이유 라는 아티클을 공유해 주셨다. (시간이 된다면 한번 읽어보길 강추, 무려 한글!) 어플리케이션에서 성능은 사용자의 증가, 이탈율, 응답속도에 영향이 있고 이는 결국 추구하는 가치(이를 테면 수익)에 직면한다고 한다. 사용자는 어느 관점에서 바라보는가에 따라 달라지고 각 관점에 따라 성능을 챙겨야 하는 부분이 달라진다. 수강신청을 하는 시점에서의 사용자와 뉴스 페이지를 읽는 시점에서의 사용자는 각 성격이 엄연히 다른것처럼. 시스템 관리자 등록된 / 등록되지 않은 사용자 서버 관점 로그인된 / 로그인 하지 않은 사용자 성능 테스터 관점 Active User 서버에 부하를 주는 사용자 메뉴나 링크를 누르고 결과가 나오기를 기다리는 사용자 성능테스트시 Vuser와 거의 동일 ( Vuser : 가상사용자(virtual user) ) Concurrent user 서버에 부하를 주고 있거나, 줄 가능성이 매우높은 서비스에 접속중인 사용자 웹 페이지를 띄워놓은 사용자 TPS(Transaction Per Seconds)는 초당 얼마나 많은 요청을 처리할수 있는지에 대한 시스템의 절대적인 수치로 볼수있다. (개발자는 어느상황에서든지 대충 감으로 이야기 하지말고 정확한 수치로 이야기 해야한다는 뼈를 때리는 조언과 함께…) TPS는 Scale out/up을 통해 증가시킬수 있지만 Response Time 은 불가능하다. 물론 어플리케이션을 튜닝하면 두 수치 모두 개선이 가능하다. 이러한 TPS와 Response Time의 최대치는 출시전에 반드시 테스트를 통해 알고 있어야 이슈발생시 대응하는데 유용하다. Bottleneck 즉 병목은 장비, 어플리케이션, 저장소, 설정 등 다양한 상황에서 발생할수 있다. 그중에 “아주 일반적"으로 가장 병목이 많이 발생하는 구간은 DB이고 그 다음으로 클라이언트(Web page, App), Network이 있을 수 있다. 결론은 Performance engineering is “Composite Art” of IT 라는 하나의 문장으로 정리를 해주셨다. 아무리 이쁜 디자인과 어렵고 복잡한 기능이 있을지라도 성능이 뒷받침 안된다면 대용량 트래픽 상황에서는 무의미해지기 때문이라고 생각한다. 자바 자바의 역사에 대해 설명해 주셨다. ( 역사에 대한 보다 자세한 설명은 https://www.whatap.io/blog/12/ 참고 ) 언제부터인가 JDK 라이센스 이슈가 많았었는데 실무에서 개발하는 입장에서는 java 8 에서는 문제가 안되고 java 11부터 라이센스 문제가 복잡하게 생길수 있다고 한다. 이부분은 공식문서(?)를 찾아보는게 좋을듯 하다. (개인 또는 회사에서 사용할 경우 상황에 따라 법적 이슈가 생길수도, 안생길수도 있는 복잡한 문제가 있어보여서… 필자도 제대로 이해하지는 못했다ㅠ) 그리고 각 자바 버전에서 발표한 새로운 기능에 대해 설명해주셨다. Java 8 lambda, stream, default method, LocalDate / LocalTime 추가 stream 과 foreach 의 성능은 거의 차이 없음 (오히려 가독성이 나빠질수도 있다.) ParallelStream 은 해당 장비의 cpu 개수만큼 스레드 풀을 만들어 사용 (오히려 독이 될수 있으니 잘 알아보고 사용할것) Java 9 Compact Strings : char[] > byte[] G1 default GC : https://www.

실무에서 개발을 하다보면 과거 누군가 잘 구성해 놓은 밥상(legacy)에 숟가락만 얹는 느낌으로 로직 구현만 할때가 있다. 그러다보면 각종 레이어가 어떻게 구성(설정)되어있는지도 모르고 간혹 설정에서 문제가 발생하면 “아 내가 이것도 모르고 이제까지 개발을 해왔나” 하는 자괴감이 들며 몇시간을 삽질하는 경우가 있다. 그게 지금의 필자인것 같다. (눙물…) 출처 : http://blog.naver.com/PostView.nhn?blogId=ondo_h&logNo=221437452142" 출처 : http://blog.naver.com/PostView.nhn?blogId=ondo_h&logNo=221437452142 사이드 프로젝트 초기셋팅을 하며 호기롭게 spring boot 최신버전에서 db를 연동하려 했는데 막상 완전 바닥부터 해본 경험이 적다보니 (spring boot 2 버전에서는 더욱더…) 어디서부터 뭘 설정을 해야할지… 그리고 이럴때 보는 도큐먼트를 봐도 잘 이해가 안되어 삽질을 해가며 당황하기 일쑤였다. 이번 포스팅에서는 아래와 같은 구성을 하는데 목표를 두고자 한다. Spring Boot 2 프로젝트를 처음 만들고 mybatis 를 사용해서 mysql 을 연동하는것 (AWS 의 RDS를 사용, 추후 RDS사용법에 대해 블로깅 예정) 위와 같은 상황을 처음 접하는 분들께 도움이 되었으면 하는 바램으로 짧게나마 필자의 삽질기를 여행해보자. Spring boot 2 프로젝트 만들기 필자는 IntelliJ를 사용하고 있어서 새로 프로젝트를 만들려고 할때 클릭 몇번만으로 dependency 설정까지 다 해주기 때문에 편하고 좋았다. 혹 이클립스나 다른 IDE를 사용하고 있다면 https://start.spring.io/ 을 참고하면 도움이 될것같다. 여기서도 클릭 몇번으로 IntelliJ 에서 해주는 것처럼 내가 사용할 모듈을 선택하고 generate 를 누르면 프로젝트가 생성되어 다운로드 받아진다. (참 좋은 세상…) 우선 File → New → Project 를 눌러서 아래 창을 열어보자. 그리고 뭔가 다 해줄것 같은 (개발도 해주면 안되나…) Spring Initializr을 선택후 아래와 같은 설정을 적어준 뒤 다음을 눌러준다. 사용할 모듈을 선택해주자. 필자는 이것저것(?)을 도와주는 lombok과 Mybatis, MySQL을 선택하고 프로젝트를 생성하였다. 그러면 이쁜(?) pom.xml 과 함께 당장 개발을 시작할 수 있는 환경이 제공된다. <dependencies> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.0.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies> 우선 여기까지 잘 되었는제 확인해보기 위해 Controller 에 현재시간을 출력하는걸 만들어 보고 @RestController public class ApiController { @GetMapping(path = "/helloWorld") public String helloWorld() { return LocalDateTime.now().format(DateTimeFormatter.ISO_LOCAL_DATE_TIME); } } 톰켓을 실행해보면 정상적으로 접속과 출력이 되는것을 확인할 수 있다. MySQL 연동하기 필자가 허둥지둥 했던점 중 하나는 MyBatis와 MySQL을 동시에 연동하려고 하다보니 문제가 발생해도 어디서의 문제인지를 제대로 파악하지 못하고 삽질했다는 점이다. 여기서 정확히 짚고 넘어가면 우선 데이터를 연결해주는 ORM인 MyBatis를 셋팅해준 다음 MySQL을 연동해주는 식으로 분리해서 설정을 하면 햇갈리지 않고 (돌아가지 않고) 보다 빠르게 설정이 가능할것 같다. (여기서 순서는 중요하지 않고 별도로 설정해야 한다는 관점이 중요한것 같다.) 우선 src/main/resources폴더에 있는 application.properties 에 다음처럼 작성해주자. spring.datasource.hikari.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.hikari.jdbc-url=jdbc:mysql://{url}:{port}/{db} spring.datasource.hikari.username={id} spring.datasource.hikari.password={password} 위의 jdbc-url 항목에서 AWS에서 제공하는 RDS를 사용하는 경우 RDS에서 제공해주는 엔드포인트와 포트를 적어주면 된다. (추후 AWS - RDS에 대해 블로깅 예정이다.) Spring Boot 2.0 이후부터 기본적으로 사용되는 커넥션 풀이 HikariCP로 변경되었다고 한다. (링크) 커넥션 풀 종류중 성능이 좋다고 하는데 링크를 가보면 다른 커넥션 풀 라이브러리와 성능을 비교한 벤치마크 결과를 확인할 수 있다. 위처럼 spring.datasource.hikari 가 prefix로 붙고 각종 정보들을 적어주어 config 에서 인식될수 있도록 해주자. 그 다음 DataSource 설정을 해준다. @Slf4j @Configuration @PropertySource("classpath:/application.properties") public class DatabaseConfiguration { @Bean @ConfigurationProperties(prefix = "spring.datasource.hikari") public HikariConfig hikariConfig() { return new HikariConfig(); } @Bean public DataSource dataSource() { DataSource dataSource = new HikariDataSource(hikariConfig()); log.info("datasource : {}", dataSource); return dataSource; } } 위 내용은 DataSource 를 hikariConfig에서 설정한 정보로 만들어 준다는 의미이다. 이렇게만 하고 프로젝트를 다시 실행시켜보면 logger 에 의해 datasource 의 정보를 볼수가 있다. 2019-04-22 00:27:35.048 INFO 23040 --- [ main] com.

IT 쪽에 일을 하고 있거나 관심을 가지고 있는 사람이라면 한번쯤을 들어봤을 AWS(Amazon Web Services). 이름에서도 알수있는 것처럼 아마존에서 제공하는 각종 원격 컴퓨팅 웹서비스이다. 아마존은 이러한 서비스를 누구나 쉽게 접근해볼수 있도록 AWS 프리티어를 제공해 주는데 이 프리티어 만으로도 과금없이 (또는 최소화 하여) 웹서비스를 구성할수 있다. 필자가 운영하고 있는 기술블로그 구독서비스또한 AWS 프리티어로 운영되고 있다. 최근 GDG Seoul, P-typer, Sketch Seoul 에서 주최한 D.light 345 투게더톤에 참가하며 사이드 프로젝트를 하고 있는데 마침 AWS를 사용하게 되었다. 예전에 사용했을때는 장님 코끼리 만지듯이 설정을 했었는데 이번기회를 통해 다시한번 정리를 해본다. 본 포스팅에서는 AWS 계정을 발급받고 신용카드 확인까지 된 계정에서 EC2 서버를 발급받고 putty를 활용하여 서버에 접근을 해보는것을 목표로 둔다. (사이드 프로젝트를 하면서) 아마도 웹서비스를 개발하면서 AWS를 활용하는 부분에 대해 시리즈물로 포스팅을 하게 될것 같다. 사실 너무 간단해서 이런걸 글로 쓰나? 라고 할수도 있지만 눈으로만 보는것과 직접 해보는 것이 다르고, 이걸 다시 글로써 정리를 하는것 또한 완전 다른 부분이기 때문에 포스팅을 해본다. EC2 생성하기 EC2? Amazon Elastic Compute Cloud의 약자로 물리서버가 아닌 클라우드 서버를 제공하고 있다. EC2의 장점은 서버의 스펙을 쉽고 자유롭게 조정할 수 있는점이 가장 매력있게 생각한다. 우선 콘솔에 들어가 EC2를 검색후 접속을 하고 인스턴스 시작을 눌러서 인스턴스 생성 화면으로 들어간다. AMI 즉 생성할 이미지를 선택하는 부분인데 여기서 주의할점은 잘못선택 했다간 계정 만들었을때의 카드로 생각지도 못할 금액이 결제가 되버릴수도 있다. (실제로 필자도 AWS를 처음 만져볼때 아무생각없이 좋아보이는걸로 했다가 한 30달러 정도를 지불했어야만 했다…) 좌측에 보면 프리 티어만이라는 체크박스를 체크하고 자신이 원하는 이미지를 선택하자. 일반적인 리눅스 서버를 발급받고 싶기 때문에 빨간 영역의 이미지를 선택하고 선택한 이미지의 스팩을 다시한번 확인하자. (cpu 1개에 메모리도 1기가… 너무 짜지만 무료니까…) 마지막으로 시작하기 를 누르면 키 페어를 선택 또는 생성하도록 안내가 나오는데 당연히 아무것도 안한 상태라 새 키 페어 생성을 선택해 주고 이름을 지정한뒤 키 파일을 받아준다. 이 부분에서도 조심해야할 점이 키 페어를 한번 다운 받으면 다시 동일한 키 페어를 다운받을수가 없게 된다. (나중에 다시 발급을 받아야 하는 번거로운 문제가…) 다운을 받고 잊어버리지 않도록 잘 보관해두자. 키 페어를 다운 받으면 생성중이라는 메세지와 함께 결과화면이 나온다. 여기서도 중요한 부분! 프리티어라는 달콤한 키워드 때문에 들뜬 마음으로 성급하게 빨리 서버를 받아보고 싶다고 다음다음 신공을 하다보면 자칫 간과할수가 있는데 화면을 보면 결제 알림 생성이라는 다행스러운 기능이 있다. 별 어려운 설정이 아니니 꼭 설정을 해서 필자같이 기부(?)를 하는 일이 발생하지 않았으면 한다… EC2 인스턴스가 생성이 되었다. 인스턴스의 각종 정보를 확인할수가 있는데 public IP, public DNS 까지 제공되는것을 확인할 수 있다. (추후 DNS를 구입하게 되다면 이 IP에 연결을 시켜 도메인으로 해당 서버에 접속을 할수가 있게 된다.) putty 로 발급받은 EC2 인스턴스에 접속을 해보자. 이제 발급받은 EC2 인스턴스에 접속을 해볼 차례이다. 다양한 서버 접속툴이 있지만 필자는 putty를 가장 선호한다. 디자인은 구닥다리처럼 보일지 모르겠지만 개인적으로 직관적인 UI에 가벼운 프로그램이라 생각이 든다. 우선 putty를 다운 받고 putty.exe를 실행시킨뒤에 바로 ssh 접속을 하면 너무 간단하게 서버 접속에 성공을 할수 있지만 위에서 받은 키 페어 파일을 다시 private key 로 전환해야 하는데 putty를 다운받으면 동일한 폴더에 puttygen.exe라는 파일을 실행시켜주자. 그다음 pem파일을 불러와서 마우스를 움직여서 게이지(?)를 다 채우고 save private key를 줄러 저장을 하는데 여기서 주의할점은 ppk파일명을 pem파일명과 동일하게 저장해야 한다는 것이다. (안그러면 서버 접속시 실패가 남… 삽질…) putty.exe를 실행시킨뒤 Connection > SSH > Auth 탭에서 방금 만들어 놓은 ppk파일을 불러오고, 다시 Session탭에서 host name 을 입력해주고 적당한 이름으로 저장을 눌러준다.

필자는 ElasticStack을 사용하면서 처음 카프카를 접하게 되었다. 메세징 큐 라는 개념도 전혀 모르는 상태에서 설치부터 ElasticStack 연동까지 사용하며 정말 강제로 카프카에 대해 공부를 하게 되었다. 카프카를 자주 다루고 메커니즘에 대해 자세히 살펴보다 잠깐 해이해질 무렵 카프카 한국 사용자 모임에서 밋업을 한다고 하길래 빛의 속도로 신청, 아마도 1등으로 신청했지 않았을까 싶다.사실 작년 카프카 밋업을 못간게 너무 한(?)이 되어 이번엔 회사 업무 등 여러가지로 한창 바쁘지만 “지금이 아니면 안돼” 라는 생각으로 밋업을 다녀왔고, 짧지만 후기를 작성해 보고자 한다. (요즘 왜 이렇게 바쁜지 모르겠지만… 신기하게도 그 바쁜 일정들이 하나도 겹치지 않는게 더 신기하다… ) 삼성 SDS 건물에서 진행된 카프카 밋업" 삼성 SDS 건물에서 진행된 카프카 밋업 참고로 필자는 카프카에 대해 아주 조금 건드려본 수준이라 발표하시는 분들의 전부를 습득하기엔 다소 그릇이 작아서 일부 세션은 거의 “그런가보다~” 하고 들을 수 밖에 없었다. 후기도 아마 그런 맥락으로 작성할듯 싶다. Kafka 한국 사용자 모임 링크 : https://www.facebook.com/groups/kafka.kru 카프카를 활용한 캐시 로그 처리 - 김현준(카카오) 이미지 등 캐시서버의 로그를 분석하기 위한 시스템을 구축하는데 ElasticStack 을 활용 Elasticsearch 로 늦게 들어와서 사례를 찾아보니 대용량 로깅 처리시 앞단에 메세징 큐를 둬야 한다고 했고 그게 카프카 카프카 모니터링은 그라파나로 활용 lag이 자꾸 생김 파티션을 쪼개거나, 컨슈머를 늘리는 방법이 있음 auto.commit.interval.ms 와 enable.auto.commit=true 로 조정 interval을 줄이니 lag이 줄어듬 현재는 수백대 캐시서버의 로그를 초당 15만건 이상 처리중 질문을 했다. 필자도 lag이 높아지면 어쩌지 하는 불안감과 높아지면 컨슈머를 늘리면 되겠지 하는 막연함이 있었는데 commit interval을 줄이면 lag이 줄어든다고 해서 무조건 줄이면 좋은가에 답변은 카프카를 관리하는 주키퍼쪽에 무리가 간다고 설명해 주셨다. 역시 만병통치약은 없고 상황에 따라 적절하게 시스템 관리자가 조정해가며 운영해야 하는점을 느꼈다. 참고 URL : https://kafka.apache.org/documentation/#adminclientconfigs 카프카를 활용한 엘라스틱서치 실무프로젝트 소개 - 이은학(메가존) 카드사의 프로젝트를 약 3개월간 개발하였고 전체 아키텍쳐 중에 일부분을 kakfa를 활용 Elasticsearch 데이터를 hadoop에 백업 형태로 옮기며 관리 filebeat > kafka > spark streaming 을 활용하여 데이터의 검증처리가 가능 (특정 상황에서의 관리자에게 알림 등) logstash 의 ruby 필터를 활용하여 일정의 작업을 해주는 데이터 파이프라인 구성 가능 (개인정보 식별 등) logstash 는 cron형태의 배치로도 가능 또 질문을 하였다. (카프카 밋업과는 무관했지만…) logastsh 를 사용하면서 필터쪽에 로직이 들어가면 성능상 괜찮냐는 질문에 하루에 15억건을 처리하고있고 문제가 없었다고 한다. 필자는 아파치 엑세스 로그를 logstash로 처리하면서 간혹 뻗거나 에러가 발생했는데 아마 파일을 logstash가 직접 바라보고 처리도 하게해서 그런것 같다. (지금은 filebeat가 shipper 역활을 수행하고 있고 큰 무리 없이 운영중) 카프카를 활용한 rabbitMQ 로그처리 - 정원빈 (카카오) 레빗엠큐는 erlang으로 구현된 AMQP 메시지 브로커이고 TCP기반으로 구성 Kafka 는 게으르지만 메우 효율성이 뛰어남, 반면 RabbitMQ 는 똑똑하지만 보다 느림 Kafka 에서 Elasticsearch 로의 ingset 는 NIFI를 활용 레빗엠큐와 카프카의 차이 Kafka RabbitMQ 컨슈머 추가 여러 컨슈머가 하나의 메세지를 동시에 할수 있어 확장에 용이함 확장할때마다 큐를 추가 생성해야함 메세지 저장 로그기반으로 디스크에 저장, 리텐션 이후 삭제 큐 기반으로 메모리에 저장 컨슈머가 메세지 수신시 즉시 삭제 메세지 처리 발송확인 가능 / 수신확인 불가능 발송확인/수신확인 가능 카프카를 마이크로서비스 아키텍쳐에 활용하기 - 이동진 (아파치 소프트웨어 파운데이션) 카프카 스트림즈 소개 (Interactive Query) 카프카를 활용하여 마이크로서비스에서 사용하려면 데이터를 임시 공간에 넣어두고 (redis 같은?

필자는 평소 개발자에게 가장 중요한 덕목 중 하나가 글쓰기라고 생각하고 있다. 마침 글쓰기와 기술의 접점을 고민하고 이야기하는 “Write The Docs 서울 밋업”(링크) 이 있다고 하여 쉬고 싶던 주말이지만 만사를 집어치우고 참석하게 되었다. 사실 연예인 개발자분들을 직접 만날 수 있다는 기대감도 있었기 때문이다. (발표하시는 바로 앞자리에 앉았는데 정작 한마디도 못 건넸지만…) 밋업 가능길 문득 나를 사로잡았던 문구와 밋업 장소 마루 180" 밋업 가능길 문득 나를 사로잡았던 문구와 밋업 장소 마루 180 발표에 앞서 “이 발표 자료는 공개할 예정이니 필기하실 필요가 없다"라고 하셨다. 하지만 뒤통수를 (좋은 의미) 몇 대 아니 몇십대 맞은 느낌이라 정리를 하지 않을 수가 없었고 오늘 느끼고 배운 마음을 쭉 유지하고 싶어(내 것으로 만들고 싶어) 후기를 작성해 본다. 더불어 제목에 감히 개발자 강추!라고 적을만큼 최근 밋업 행사 중에 손꼽을 정도로 좋았기 때문이다. 이정도로 쌔게 맞은건 아니다…출처 : https://namu.moe/w/뒤통수" 이정도로 쌔게 맞은건 아니다… 출처 : https://namu.moe/w/뒤통수 변성윤(소카) - 글쓰는 개발자 모임, 글또 변성윤 님" 변성윤 님 필자도 가입만 하고 활동은 안 하는 중인 “글 쓰는 개발자 모임 - 글또” 모임에 대해 소개해주셨다. 글을 꾸준히 작성하기 위해 만들었고, 일정에 예치금을 내고 정해진 규칙에 의해 블로그에 글을 올리면 다시 돈을 환급받는 반강제적인 모임이라고 한다. 그뿐만 아니라 다른 분들이 글을 써서 공유를 하면 성윤님이 직접 피드백을 주며 개발 시 리팩토링을 하듯 더 나은 품질의 글을 쓸 수 있도록 도움을 주고 있다고 하신다. 이러한 피드백 문화가 1:N이 아닌 N:N이 되면 또 다른 동기부여가 될 것 같은데 … 하는 아쉬움을 느꼈다. 사실 “글을 꾸준히 작성"하는 부분이 필자도 매우 공감이 된다. 바쁘고, 귀찮고, 글을 쓰려면 욕심이 생기고 그러다 미루고… 그 동기부여가 “돈” 일수밖에 없는 현실이 아쉽긴 한데 오히려 그 “돈"만큼 동기부여가 잘 되는 것도 없을것 같다. (헬스장 1년 권 계약하고 돈이 아까워서라도 나가는 느낌으로…) 올해 새로운 기수를 모집한다고 하니 그때는 꼭 지원해서 글을 꾸준히 쓰는 습관을 길러보고 싶다. 김대권(당근마켓) - 기술 블로그 생존 전략 : 구글 시대의 글쓰기 김대권 님" 김대권 님 얼마 전에 한번 쓱 보고 정독할 수밖에 없던 포스팅인 [좋은 기술 블로그를 만들어 나가기 위한 8가지 제언](https://www.44bits.io/ko/post/8-suggestions-for-tech-programming-blog 을 작성하시고, 해당 기술블로그 를 운영하시고 계시는 김대권 님께서 글을 왜 쓰는지, 그리고 어떻게 하면 사람들에게 잘 읽힐 수 있을지에 대해 구글 검색엔진 관점에서 정리해주셨다. 우리는 보통 읽히기 위해 공개된 글을 쓰기 때문에 좋은 글을 쓰는 게 선행되어야 하지만 반대로 어떻게 하면 잘 읽힐 수 있을지에 대해 고민이 필요한 부분 같다. 요즘은 소셜미디어나 검색을 통해 글이 공유되고 검색되는데 장기적으로 봤을 때는 검색엔진에 노출이 돼야 한다고 하신다. 또한 검색엔진은 백과사전처럼 정답을 알려주는것이 아닌 “거대한 추천 시스템"의 관점으로 접근해야 하며, 글의 양이 너무 크거나 적으면 안 되고 적당한(?) 수준을 지켜야 이를 검색엔진이 알아서 판단한다고 한다. 또한 [What nobody tells you about documentation (번역본)](http://blog.weirdx.io/post/60414 이라는 것도 소개해주시며 결국엔 글 내용의 자체가 좋아야 한다고 재차 강조하셨다. (매우 공감, SEO 아무리 잘 설정해봤자 내용이 안 좋으면 말짱 꽝) 홍연의(LINE) - To. 지식 공유를 시작하려는 개발자, From. 당신의 든든한 서포터 Developer Relations팀 홍연의 님" 홍연의 님 다소 생소한 Developer Relations 팀에 대해 소개를 해주시며 꼭 기술 관점이 아닌 다양한 분야에서 해당 팀이 어떤 지원을 해주고 있는지에 대해 알려주셨다. 기술 블로그 운영, 소셜 페이지 관리, 개발 컨퍼런스, 세미나, 커뮤니티 후원 등등 개발자와 개발 문화를 알리는 모든 일을 하고 있다고 한다.