Review on

퇴사 부검 : 네이버를 떠나며

Sat, 19 Jul 2025 10:00:00 +0900

　12년 넘게 다닌 회사를 떠난다. 군대를 전역한 이후, 스스로의 선택으로 회사를 떠나는 것은 이번이 처음이다. 그래서인지 아직 실감이 나지 않는다. 첫 출근 날의 설렘이 아직도 손끝에 남아 있는데, 어느새 마지막 퇴근을 준비하고 있다. 하루에도 몇 번씩 아쉬움과 후련함, 설렘과 두려움이 번갈아 찾아온다. 감정은 밀물처럼 들어왔다가 썰물처럼 빠져나간다. 긴 시간의 무게가 마음 한편에 조용히 가라앉는다.

　눈을 감고 천천히 지난 시간을 떠올려 본다. 신입사원이던 시절, 세상이 내 손안에 있는 듯한 자신감이 있었다. 첫 업무가 웹페이지 하단의 사명을 NHN에서 NAVER로 바꾸는 일이었으니, 지금 생각해 보면 참 귀엽고 소박했다. 동료들과 웃고 떠들던 점심시간도, 이루 말할 수 없는 뿌듯함을 안고 보냈던 수많은 야근의 밤도 생생하다. 물론 그 반짝이는 순간들 사이엔 힘들고 외로운 날도 있었다. 때로는 지치고, 때로는 막막했다. 그래도 나는 그 시간을 사랑했다. 그 모든 시간이 지금의 나를 만들었다. 그래서 더 애틋하다. 이제는 떠나지만, 이 회사는 내 안에 지울 수 없는 흔적으로 남는다.

최종 합격하고 고향에 내려가던 날

　이 글은 단지 퇴사의 기록이 아니다. 나 자신과의 깊은 대화이자, 커리어의 전환점에 대한 고백이다. 무엇을 배웠고, 무엇을 남기고 가는지. 앞으로 어떤 방향을 향해 나아갈지. 나는 지금 그 질문들 앞에 서 있다. 이 글로 모든 것을 담을 수 있을지 모르겠다. 그래도 천천히, 한 줄 한 줄 정리해보려 한다. 이 글이 누군가에게, 그리고 언젠가의 나에게 의미 있는 기록으로 남기를 바란다.

넷플릭스에서는 직원이 퇴사하기 전에 ‘퇴사부검’이라는 메일을 보낸다고 한다. 그 메일에는 아래의 내용이 담긴다.

왜 떠나는지 : 다른 직원들이 이해할 수 있는 이유
회사에서 배운 것 : 새로 배운 것과 경험한 것
회사에 아쉬운 점 : 회사가 이랬다면 떠나지 않았을 것
앞으로의 계획 : 어느 직장에서 어떤 업무를 할지
회사의 메세지 : 직원을 떠나보내는 회사의 입장

　이 형식을 따라, 건강한 퇴사를 위한 기록을 남기려 한다. 다만 5번 항목은 내가 이야기할 부분이 아니기에 생략한다. 대신 시작에 앞서 네이버라는 회사에 대한 생각을 짧게 정리하고 시작한다.

부검 0 : 네이버에 대하여

　네이버는 대한민국 최대의 검색 엔진이자 포털 사이트다. 개발자이자 직원으로서도 다니기에 좋은 회사로 유명하다. 나 역시 재직 기간 동안 수많은 복지와 혜택을 누릴 수 있었다. 사용자 중심의 ‘서비스’를 만드는 회사라 복잡한 도메인 설계부터 대규모 트래픽을 다룰 기회도 많았다. 개발자인 내게 매우 매력적인 부분이었다.

입사했던 그린팩토리와 로봇들과 함께 있던 1784 사옥
출처 : https://design.co.kr/article/33592

　네이버에는 서비스마다 다양한 조직이 존재한다. 직원 스스로 새로운 기회를 찾을 수 있는 OCC(Open Career Chance)라는 사내 제도도 있다. 물론 최근 들어 합격의 기준이 까다로워지고 있지만, 여전히 직원들이 네이버를 좋아하는 이유 중 하나라고 생각한다. 또한 네이버엔 “최복동(최고의 복지는 동료)”이라는 말이 있다. 유연하고 자율적인 분위기 속에서 서로 배우고 성장하는 문화가 잘 자리 잡혀 있다. 이런 동료들과 함께한 것은 내게 큰 행운이었다.

　개발 역량을 키우고 기술 트렌드를 따라가기에도 좋은 환경이다. ‘책임근무제’를 통해 개인이 근무시간을 자율적으로 관리할 수 있는 것도 네이버의 매력이다. 이토록 좋은 회사에서 오랜 시간 함께했지만 결국 떠나기로 했다. 회사와 내가 원하는 방향이 점점 달라지고 있었기 때문이다. 지금부터는 그 이야기를 해보려고 한다. 왜 떠나기로 했는지, 어떤 고민이 있었는지. 천천히, 솔직하게.

부검 1 : 왜 떠나는가

　12년 동안 자의 반, 타의 반으로 다양한 서비스를 경험했다. 어느 날 갑자기 다른 서비스를 맡으라는 지시를 받고 팀을 옮기기도 했다. 때로는 더 큰 도전을 위해 스스로 OCC를 통해 이동했다. 회사의 경영적 이슈나 조직 개편으로 인해 원치 않는 팀 이동을 겪기도 했다. 잦은 변화 속에 이직을 고민할 겨를조차 없었다. 매 순간 긴장과 도전의 연속이었고, 회사 자체가 싫었던 적은 없었다. 그래서 오랜 기간 내 선택지에 ‘이직’이란 단어는 없었다.

6년간의 토이프로젝트 여정을 마무리하며 - 기술블로그 구독서비스 회고록

Wed, 09 Jul 2025 10:00:00 +0900

　　계속하던 것을 그만둔다는 건, 시작하는 것보다 더 어려운 결정을 요구할 때가 많다. ‘왜 그만둬야 할까?’라는 물음 앞에 서면 수많은 이유와 핑계가 머릿속에서 충돌하고, 그 과정에서 내면의 깊숙한 갈등과 마주하게 된다. 2018년부터 6년 동안 꾸준히 운영해온 기술 블로그 구독 서비스의 종료를 결심한 지금 역시 마찬가지다.

　처음엔 단지 작은 불편을 해결하려던 단순한 프로젝트였지만, 어느 순간 수천 명의 사용자들의 아침에 만나는 루틴으로 자라 있었다. 사용자들이 보내는 감사의 메시지는 일상의 피로를 잊게 만들었고, 이 서비스가 세상 어딘가의 누군가에게 작게나마 변화를 주고 있다는 사실은 내 마음을 계속 움직이게 했다. 하지만 그 이면에서는, 늘어나는 책임과 운영의 부담 그리고 빠르게 변화하는 기술 환경 속에서 이 서비스의 존재 이유를 끊임없이 자문해야 하는 상황이 펼쳐지고 있었다.

　그 고민의 시간은 몇 년간 이어졌다. 오픈소스로 남겨둘 수도 있었고, 다른 이의 손에 넘길 수도 있었으며, 최소한의 기능만 남겨 놓고 유지하는 선택도 있었다. 그러나 결국, 더는 내 마음이 닿지 않는 곳에서 무책임하게 살아 숨 쉬는 서비스를 바라볼 자신이 없었다. 깔끔하게 정리하고 떠나는 것이, 이 서비스에 대한 마지막 애정의 표현이자 책임이라는 생각이 들었다.

　이 글은 그 6년간의 여정을 천천히 되돌아보며 써 내려간 기록이다. 시작의 설렘에서부터 성장의 기쁨과 아픔, 기술적 도전에서 얻은 배움, 그리고 ‘끝’이라는 쉽지 않은 결정까지. 이 이야기가 비슷한 고민 앞에 선 누군가에게 작은 위안과 용기가 되고, 새롭게 토이프로젝트를 시작하려는 사람에게 현실적인 안내가 되기를 진심으로 바란다. 무언가를 끝낸다는 건 실패가 아니라, 또 다른 출발을 위한 가장 정직한 준비다. 때로는 멈출 줄 아는 용기가 있어야, 새로운 길을 마주할 힘도 생긴다.

토이프로젝트 관련 글

시작

　‘글 쓰는 개발자가 되자!‘는 생각이 머릿속을 가득 채우던 시절이 있었다. 단지 좋은 개발자가 되는 것뿐만 아니라, 내가 아는 것을 공유하고 나누며 기술 생태계에 작게나마 기여하며 영향력 있는 사람이 되고 싶다는 열망이었다. 그래서 시작한 기술 블로그는 어느새 개발자로서의 정체성 일부가 되었고, 조금씩 늘어나는 방문자 수는 내게 큰 보람을 주었다. 그러나 글을 쓰고 나서 늘 아쉬움이 남았다. 정성껏 작성한 글이 많은 사람들에게 닿았으면 좋겠다는 바람도 있었지만, 한편으로는 다른 개발자들이 작성한 좋은 글들을 여기저기 분산된 채로 찾아다녀야 하는 불편함이 마음에 걸렸다. 이러한 단순하고도 순수한 마음에서 출발한 아이디어 하나를 떠올렸다. “매일 아침, 어제 하루 동안 올라온 기술 블로그 글들을 자동으로 수집해서 이메일로 보내주면 어떨까?” 하루를 시작하며 좋은 글을 읽는 습관이 개발자로서 성장하는 데 큰 힘이 되었기에, 이 서비스가 나와 같은 고민을 가진 많은 개발자들에게도 도움이 될 거라 믿었다. 처음에는 단순한 아이디어였지만, 실제로 구현하기 위해서는 생각보다 많은 기술적 도전이 필요했다.

첫 발송! 그때는 도메인도 없었어서 무료 도메인을 사용했었다.

　가볍게 무료로 운영할 방법을 고민하면서 Heroku에서 시작했으나, 제한된 자원과 운영방식의 문제로 Raspberry Pi를 거쳐야 했다. 그 과정에서 소규모 서버 운영에 대한 여러 시행착오를 겪었지만, 이것조차도 즐거운 경험이었다. 그러던 중 서버 개발자였던 나에게 한줄기 빛처럼 찾아온 것이 AWS 프리티어였다. AWS는 무료로 일정 기간 서버 인프라를 제공해줬고, 덕분에 부담 없이 조금 더 안정적인 환경을 구축할 수 있었다. Java를 중심으로 개발 경력을 쌓아왔던 나에게, 이 프로젝트는 새로운 언어를 탐색할 완벽한 기회이기도 했다. 오랜 시간 마음속에서만 궁금했던 언어인 Python을 선택했고, Python 특유의 간결한 문법과 빠른 개발 속도는 이 프로젝트에 꼭 맞는 선택이었다.

　그렇게 하나씩 기능을 추가하고 문제를 해결해 나가는 과정에서, 내 자신도 개발자로서의 시야와 역량이 넓어지는 것을 느꼈다. 처음엔 단지 개인적인 호기심과 작은 불편함을 해결하기 위한 프로젝트였는데, 어느새 수천 명이 매일 아침 나와 같은 메일을 기다리게 될 줄은 꿈에도 몰랐다. 작은 아이디어 하나가 얼마나 큰 파급력을 가질 수 있는지, 그리고 개발자로서 성장한다는 것이 얼마나 다채로운 방식으로 이루어질 수 있는지를 깨달은 순간이었다.

분위기가 확실히 달랐던 SpringCamp2024

Sun, 26 May 2024 22:55:50 +0900

　이제 막 반팔을 꺼내 입기 시작한 초여름의 지난 토요일, 스프링캠프 2024를 다녀왔다. 개발의 재미를 한창 알아가던 주니어 시절, 자바/스프링을 다루는 백엔드(서버사이드) 개발자라면 한 번쯤은 들어보거나 참여해 봤을 스프링캠프라는 기술 콘퍼런스를 매년 기다려왔다. 나에게 있어 스프링캠프는 조금 남 다르다. 여느 때와 다름없이 성장에 갈증을 느끼고 있을 무렵 지금으로부터 약 5년 전 SpringCamp2019 에 일꾼단(스텝)으로 참석하여 처음 진행부터 끝나는 과정까지를 온전히 경험한 기억이 있기 때문이다. 그래서인지 행사를 준비하는 준비 위원회부터 발표를 준비하는 연사자 분들의 땀방울이 얼마나 소중하고 힘드신 과정인지 조금은 더 잘 알기에 매년 참석해야지 했지만 코로나로 몇 년 동안 중단되었던 스프링캠프가 작년에 다시 시작했지만 확실히 개발에 대한 열정의 온도가 높아졌는지 티켓 판매는 1분 컷으로 참석을 하지 못했다. 올해는 반드시 가야겠다 다짐했기에 티켓 판매 시작과 동시에 예매에 성공했다. 물론 올해도 1분 만에 매진이 되었다고 할 정도로 그 열기는 대단했다.

　제목에도 적은 것처럼 여러 가지 측면에서 분위기가 확실히 달랐다. 앞서 1분 만에 티켓 판매가 매진된 것처럼 정말 많은 사람들이 참여한 것만으로도 개발에 대한 열정은 현장에서도 느낄 수 있을 정도였다. 특히 나는 이런 개발 콘퍼런스 또는 세미나에 참석하면 아는 내용일지라도 연사자의 답변을 들으며 기억에 오래 남기 위해 발표가 끝나면 항상 질문을 하는 게 목표라면 목표라고 할 수 있는데 워낙에 많은 분들이 질문을 하시다 보니 5개 세션이나 있었는데 한 번도 질문을 할 수가 없었다. 5년 전만 해도 이렇게 적극적인 분위기는 아니었던지라 발표가 끝나면 고요한 분위기를 항상 내 질문으로 깨곤 했었는데 적잖은 충격이었다. 더불어 질문의 수준 또한 놀라웠는데, 단순 xx가 뭐에요 라는 말 그대로 ‘질문’을 넘어서서 각자의 경험을 토대로 개인의 상황과 생각을 이야기 하면서 연사자의 생각을 듣고 싶다는 식의 질문의 흐름 속에서 비록 내가 연사자는 아니었지만 질문 자체에서 생각을 해볼 수 있는 기회가 되었던것 같아서 꽤 신선했던 것으로 기억된다. 반대로 장소가 협소했던 점과 개발 콘퍼런스를 다녀오면 항상 한 아름 선물들을 받아오곤 했었는데 생각보다 회사 부스들이 적은 게 아쉬웠다. 아마도 스프링캠프가 비영리단체이기도 하고 일꾼단 경험을 토대로 생각을 해보면 후원사가 풍족하지 않은 점이지 않을까 생각을 해봤다. 이곳을 찾아오신 많은 개발자 분들의 열정 만큼 후원사도 많아져서 특정 회사에서 주최하는 개발 콘퍼런스와 비슷한 수준으로 진행되면 좋지 않을까 싶었다.

5년만에 다시 찾은 스프링 캠프!

　행사장 앞에서 외롭게(?) 안내를 하고 계셨던 운영진 분께서 감사하게도 나를 알아봐 주셔서 깜짝 놀랬다. 크게 두 가지의 트랙으로 총 10개의 발표가 진행되었다. 어쩌다 보니 줄곧 트랙 1에서 듣게 되었고 맨 앞 정중앙에 자리 잡고 우등생(?) 코스프레를 해보며 연사자분들의 발표 내용을 하나도 놓치지 않으려 집중해서 들었다. 발표라는 게 제한된 시간 내에 방대한 양을 이야기를 해야 하기 때문에 자칫 잘못하면 ‘찍 먹’의 형태로 발표하는 경우가 있다. 그런데 이번 발표하시는 분들의 내용을 보면 꽤 많은 고민을 한 흔적들도 보였고 발표 전에 준비 위원회 분들과 함께 리뷰를 잘 하셔서인지 시간이나 진행도 매끄러웠던 걸로 기억된다.

　발표 영상은 3~4개월 이후에 유튜브에 올라온다고 하니 관심 갖고 찾아보면 될 것 같고 간접적으로라도 발표 내용과 내 생각들을 공유하면 좋을 것 같아 적었던 메모를 남겨본다. 후다닥 메모를 하다 보니 잘못된 내용이 있을 수 있으니 어느 정도 감안하고 봐주길 바란다.

켄트벡의 Tidy First? / 안영회 님

I’m Back! Kent beck!

　이 책은 내가 운영하는 스터디, 그리고 회사 팀 분들과도 스터디를 진행 중이라 아직 끝까지 읽어보진 못했지만 전체적으로 어떤 ‘기술’을 알려준다기 보다 코드를 정리하는 방법들에 대해 생각해 볼 만한 아젠다를 제공해 주는 책인 것 같다. 특히 ‘Man in the mirror’라는 표현으로 ‘나 자신부터 시작하자’라는 의미가 강렬하게 다가왔고, 주변의 환경탓만 해온건 아닌지 스스로 개척해 나갈수도 있을것 같다는 자신감을 얻었다. 책에 대한 내용 그리고 꽤 오랫동안 개발씬에 계시면서 본인을 ‘설계덕후’ 라고 칭하시며 느낀 내용들에 대해 소개해 주셨는데 그분이 직접 켄트 백과 소통하며 번역하신 책이니 끝까지 읽어보고 이 책에 대한 후기도 남겨볼 수 있었으면 좋겠다고 생각했다.

초보 시니어 개발자의 2023 리뷰

Sun, 31 Dec 2023 15:26:10 +0900

　언제부터인가 새해가 되면 그 해의 키워드를 선정하고 해시태그처럼 달고 다니며 한 해를 보내온 것 같다. 작년의 키워드는 “한계”. 한정된 시간 속에서 하고 싶은 것도 많고 해야 할 것도 많은 나로서는 중요도에 따라 어쩔 수 없이 무언가를 포기하게 되는 순간들이 찾아왔다. 그럴 때마다 늘 어쩔 수 없다는 자기 가면을 쓴 채 정말 하고 싶던, 꼭 해야 할 것들임에도 불구하고 다음에 해야지 하고 넘어갔던 적이 많았다.

　그렇게 시간을 보내니 아쉬움이 남게 되었고 잠을 줄여서라도 할 것 들을 하자며 나를 극한으로 몰아붙여보자는 의미로 작년의 키워드를 “한계"라고 정했고 정말 많은 것들을 경험할 수 있었다. 그렇게 나를 몰아붙이는 삶을 살다 보니 말 그대로 그저 “여러 가지만 했던” 한 해로 기억된다. (아마 그래서 작년 리뷰가 없던 이유일지도…?)

　작년의 “한계"라는 키워드를 통해 잠은 죽어서 자야지 하는 마음으로 불타는 열정을 연습했다면 올해는 같은 시간을 쓰더라도 제대로 쓰고 싶은 마음에 많은 것들을 배우자는 의미로 “배움"이라는 키워드를 선정하게 되었다. 개발자로 살아온 지 올해로 11년 차가 되는 해 이기도 하고 이제는 “시니어 개발자"라는 수식어가 붙다 보니 더욱 시간을 허투루 보낼 수가 없다는 생각이 들었다. 그렇게 “배움"이라는 키워드를 가지고 한 해를 지나와보니 정말 많은 것들을 경험 그 이상으로 배울 수 있었고 그에 대한 한 해의 리뷰를 해보고자 한다.

회사원으로써의 노력

　부여받은 일은 기본이고 그 이상을 스스로 찾아서 해야 하며, 구성원 모두가 함께 성장할 수 있는 분위기를 이끌어 나가야 하는 일당백 ‘시니어 개발자’로써 회사 생활을 해왔던 것 같다. (쓰고 보니 이력서에서나 볼법한 문장이지만;;) 특히 후배 개발자분들이 잘 성장할 수 있는 환경을 조성하고 그러한 과정들이 결국 서비스가 나아가고자 하는 방향에 보탬이 될 수 있도록 서포트 하는 것에 집중을 해왔다.

　가끔은 팀 내에 쌈닭(?)이 되어 돌아만 가게 하던 일을 개발자로써 확장성과 유지 보수성을 위해 개선해 보자는 자세를 취해 보기도 했고 함께 일하는 주니어 분들께 하기 싫었지만 (그 시절 나를 보는 것만 같았던) 좀 더 올바른 개발자로서의 성장을 하는 바람으로 쓴소리를 몇 번 건넨 것 같다. 지나고 보면 좋은 게 좋다는 식으로 넘어가도 될법했나 싶지만 우리는 그저 코딩만 하는 기계가 아니기에. 누군가는 이런 생각과 말을 해야 하지 않을까 하는 이상한 책임감의 모자를 써보기도 했었다.

IDC장애 대비 Jenkins 이중화 구성
Active IDC 장애시 Standby IDC 에서 Jenkins 운용이 가능하다.

사내 기술공유 행사 발표

　기술적 기억으로는 젠킨스 IDC 이중화를 위해(master-slave가 아닌) 스스로 꽤 장기간에 걸친 시행착오를 통해 젠킨스 클러스터를 IDC간 이중화 구성하기도 하였고 인원 대비 업무량이 많다 보니 늘어만 가는 기술 부채를 개선하고자 자체적으로 ‘기술/프로세스 개선 TF’를 구성해서 개발팀에서 챙겨야 할 부분들을 놓치지 않기 위한 장치들을 만들었다. 여러 output 중에 하나로 팀 내 주니어 분과 함께 하반기 사내 기술 공유 행사에서 “그런 배포 프로세스로 괜찮은가(feat. Github Action)“라는 제목으로 배포 자동화 사례를 사내 오픈소스화(Github Action Marketplace) 하여 발표하기도 하였다.

나름 열정스러운 모임 이름

　사내 독서모임에서 모임장을 자처하여 인문학 독서 소모임을 만들고 10여명 정도의 사람들과 함께 진행을 해보기도 하였고, 같은 서비스를 만들고 있는 다양한 사람들끼리 한 달에 한 번씩 모여 식사 자리를 가졌던 미식회 모임을 운영해 보기도 하였다. 개발과는 관련이 없을 수도 있지만 여러 모임을 운영해 보면서 “관계” 그리고 “조직 운영"에 대한 부분을 간접적으로나마 느껴볼 수 있었던 것 좋은 경험으로 기억될 것 같다.

KAFKA 서비스 활용 스터디 사례 밋업 후기

Sun, 19 Feb 2023 23:39:22 +0900

　필자는 오프라인에서 진행하는 밋업이나 콘퍼런스 가는 것을 좋아한다. 발표하는 내용을 전부다 이해해서 듣고 온다는 건 거짓말이겠지만 간혹 들었던 내용을 팀 내에 적용해 본다거나 몰랐던 내용에 대해 알게 되는 경우가 많았다. 특히, 질문을 꼭 하는 편인데 질문을 하려고 하면 좀 더 집중해서 듣게 되거나 질문한 세션의 내용은 꽤 오랫동안 기억에 남게 되니 개발자 행사에 참석하면 꼭 질문을 하자는 게 필자 자신과의 약속 중에 하나이기도 하다.

　한동안 코로나로 모든 개발자 행사가 온라인으로 진행하는 등 오프라인 행사는 눈을 씻고 찾기란 하늘에 별 따기였다. 오프라인 행사에 참여하면 나름의 개발력(?)을 얻을 수 있었는데 오프라인 행사 자체를 하지 않아 괜히 기운이 빠지던 요 몇 년이었지 않았나 싶다. 그러다 페이스북 KAFKA 한국 사용자 모임에서 공지가 올라왔고 세션들을 보아하니 하나도 알아듣지 못할(?) 엄청나게 고차원의 내용이 아닌 그럭저럭 이해할 만한 내용으로 준비되어 있었고, 무엇보다 회사와 가까워서 설레는 마음으로 신청을 하였다. 오래전에도 한번 밋업에 참석한 적이 있었는데 나름 진행도 매끄러웠고 좋았던 기억들뿐이라 한 치의 망설임 없이 신청하게 되었다.

신입사원때 자주 오가던 다리…

　오전 근무만 하고 판교 테크노벨리에 있는 유명한 다리인 이직의 다리를 건너 SKT/SKP 판교 사옥 1층으로 걸어간다. 판교에 올 일이 잘 없는 게 올 때마다 느끼는 건 정말 IT 회사가 많다는 것. 뭔가 이직을 하려고 마음을 먹지 않아도 괜히 마음이 바운스 거리는 건 기분탓 일까 싶다.

밋업의 분위기

　이런 행사에 가면 맨 앞에 자리를 잡곤 해서 처음엔 몰랐는데 행사 진행 중간에 보니 사회자분 이야기로는 약 90여 명 정도가 왔다고 했다. 오프라인 행사라 그런 건지, 판교 직장인분들의 접근성이 좋아서인지, 아님 정말 KAFKA의 인기(?)가 좋아서 인지는 모르겠지만 예상보다 꽤 많이 와서 조금 놀랬다. 입구에 커피와 쿠키가 제공되었고 개발자 노트북에 덕지덕지 붙일 수 있는 개발자 스티커도 받을 수 있었다.

　이번에는 데보션(Devocen) 이라는 곳에서 후원을 받아 진행한다고 했다. 처음에 데보션이 뭐 하는 곳인지에 대한 간략한 소개와 나중에 추첨을 하기 위해 앱을 설치하라는 귀여운 홍보도 있었다. SK 내/외부 우수 인재가 모여 전문 기술 지식/정보를 등록/축적 하고 공유 교류를 하며 전파 및 확산에 집중을 한다고 한다. 테크 세미나가 월 1회 있다고 하니 종종 들어와 봐야 겠다는 생각을 해본다.

　카프카 모임을 이끄시는 고승범 님도 오셨다. 예전 밋업에서도 뵙긴 했지만 최근에 카프카 관련 책도 새롭게 내시고 그룹도 운영 중이신 분이다. 나는 과연 저러한 열정이 있었나? 있을 수 있나? 라는 생각을 잠시 해본다.

발표 요약

　하나부터 열까지 받아쓰기 수준으로 적진 못했지만 그래도 메모장에 남아있는 기록들을 정리 및 요약해 본다. 오랜만의 오프라인 행사라 들떠서인지 잘못된 기록이 있을 수 있음을 알린다 ^^;

Kafka MirrorMaker로 카오스 엔지니어링 맛보기 / 황한희 님

Kafka MirrorMaker? - 카프카 클러스터를 대상으로 데이터를 mirroring 하는 기능 (토픽 데이터 동기화)
활용방식 : fan-out, aggregation, active-active, acitve-passive
카오스 엔지니어링 : 운영환경에서도 갑작스러운 장애를 견딜 수 있는 시스템을 구축하기 위해 시스템을 실험하는 분야, 장애를 미리 경험
- https://en.wikipedia.org/wiki/Chaos_engineering
Chaos Monkey
- 넷플릭스 개발팀의 운영 원칙으로부터 시작해 현재는 가장 대표적인 카오스 테스팅 도구
- 마치 무기를 든 원숭이를 데이터 센터에 풀어 놓은것 같다는 의미에서 출발
Pumba
- 컨테이너 환경에서 제공되는 카오스 엔지니어링 도구
- 영화 라이온킹에 등장하는 멧돼지인 품바의 멍청하고 산만하다는 특징에서 영감을 받음
- 비교적 단순한 테스팅을 할 때 유용한 도구
카오스 엔지니어링 파이프라인
- 안정화 정의 : 기술적인 이슈나 아닌 비즈니스 관점의 지표를 안정된 상태의 지표로 설정
- 이벤트 선정 : 발생 가능성이 있는 이벤트 선정
- 실행 : 카오스 엔지니어링 수행 , 실제로 이벤트를 발생시켜보고 가설을 시험
- 분석

　이번에도 어김없이 질문을 했다. 아무래도 실 서비스의 접근을 해야 할 텐데 부담은 없을지, 성능에 영향은 없을지가 가장 궁금했다. 답변으로는 pub/sub 이 하나 더 발생하는 것이기 때문에 성능에 큰 영향은 없을 것이라고 답변을 받았다. 과연 그럴까? 라는 생각을 잠깐 해보고 팀 내에서 카오스 엔지니어링을 도입하게 되면 개발 환경부터 테스트 해봐야지 하는 생각을 해봤다.

고장나기 직전 개발자의 2021 리뷰

Sun, 02 Jan 2022 21:45:40 +0900

　미래의 시간을 계획하는 것도 중요하지만 과거의 시간을 돌아보고 더하거나 빼는 시간이 더 중요하다고 느끼는 시간인 ‘회고’. 올해도 어김없이 필자의 2021년을 돌아보며 회고 글을 쓰려 했지만 이런저런 일들로 한 해를 넘기고야 만다. 연말이 지나고 새해가 시작되었지만 무슨 일이 있어도 매년 회고는 꼭 하자는 나와의 약속을 지키려 2021년을 되돌아보고 크나큰 이벤트들의 연속이 될 것만 같은 2022년을 위해 더할 건 더하고 뺄 건 빼는 리뷰를 해보고자 한다.

여러 가지 작은 도전들

　재택근무가 장기화되면서 시간을 좀 더 알차게 사용할 수 있었고, 그에 생각하지도 못한 다양한 경험들을 할 수 있게 되었다. 먼저 찾아보기도 하거나 필자의 블로그나 다른 경로를 통해 오히려 연락이 왔던 ‘멘토링’은 많은 것을 생각하게 해주는 경험이 되었다. BE, FE, 머신러닝, DevOps 등 분야를 막론하고 이제 막 개발자로써 취업전선에 뛰어드려 하는 예비 개발자부터 한참 개발을 시작하고 있는 이른바 주니어 개발자까지 다양한 분들을 zoom이나 gather-town 같은 온라인 플랫폼에서 만나게 되었고, 그들의 고민을 함께 이해하려 노력하며 선배 개발자로써 조금이나마 도움이 되는 부분들에 대해 이야기해주는 활동들을 해왔다.

10년후에 만나요 :D

　물론 필자를 완벽하게 잘 성장한 (또는 본보기의 대상이 될만한) 개발자라고 말하기는 매우 어렵지만 그들보다는 다양한 경험들을 먼저 해본 선배 입장에서 노하우나 방향성에 대해 이해하기 쉽게 최대한 풀어 설명하려 했다. 이러한 점을 누구는 대수롭지 않게 여긴 적도 있지만 누군가는 XX 기업에 취업을 했다거나 며칠간 복잡하고 힘들었던 고민이 해결이 되었다는 소리를 들었을 땐 아, 멘토링 하길 잘했다는 생각이 들게 되었고 더불어 이제는 점점 누군가와 함께 공동의 목표를 이루기 위한 위치에서 있다 보니 이런 점을 연습할 수 있는 기회가 된 것 같아 너무 좋았다. 무엇보다 멘토링을 하면서 필자도 대충 알고 있던 개발 지식에 대해 (제대로 알려주기 위해) 공부하게 되는 기회가 되었고 이런저런 상담을 하며 느낀 그들의 열정을 조금이나마 간접경험하며 얼마 전부터 잃어버린 내 열정도 찾으려는 동기부여도 되기도 하였다.

　코로나가 장기화되고 개발자로써 할 수 있는 건 없을까 하며 Elastic Stack 을 활용하여 코로나19 대시보드 만들기라는 포스팅을 올리게 되었고 그에 힘입어 나만의 데이터 분석 플랫폼 엘라스틱서치라는 책에 베타 리딩을 하기도 하였다. 작년부터 책을 써보는 건 어떻겠냐는 요청이 아주 가끔 들어오지만 베타 리딩을 하면서 책을 출간하는 게 얼마나 어려운 건지 다시 한번 깨닫게 되었고 기회가 된다면 내 이름으로 된 책을 써보고 싶은 생각도 들었다.

　공모주 청약을 가끔 하면서 누군가 알려주면 좋을 텐데 하는 생각으로 공모주 알리미 라는 토이 프로젝트를 만들었다. 기술 블로그 구독 서비스를 운영하고 있는 AWS ec2 서버에 메모리가 조금 남아 배치 형식으로 만들어서 텔레그램으로 정보를 알려주는 서비스인데 생각보다 수요가 많아서 깜짝 놀랐다. 보다 대중적인(?) 메신저인 카카오톡으로 운영하고 싶었지만 메시지를 보낼 때마다 비용이 발생해서 (아무리 토이 프로젝트라 해도…) 차마 엄두가 나질 않아 카카오톡 채널만 만들고 텔레그램 링크를 연결해두었다. 지금은 아예 손도 안대는 서비스이지만 잘 돌아가고 있는 걸 보면 자동화의 힘은 정말 대단하다는 걸 다시금 느껴본다.

카카오채널 가입자에게 메세지를 보낼 수 있음 좋을텐데…

라이프 사이클의 변화

　문득 이렇게 재미있는 개발을 언제까지 할 수 있을까 하는 생각을 하게 된 적이 있다. 개발을 오랫동안 할 수 있는 방법이 무엇이 있을까 하는 생각의 끝에는 결국 “든든한 자산"과 “생각의 패러다임 전환”, 그리고 “건강"이라는 결론에 도달하게 되었다. 개발 업무 기기를 산다거나 신기술 학습을 위해 투자하기 위해서는 결국 돈이 필요하다고 느껴졌고, 공대생의 고립된(?) 가치관에서 다양한 인문학적인 관점들이 가미된다면 개발에도 훨씬 도움이 될 거라 생각이 들었다. 마지막으로 하루의 절반 이상을 의자에 앉아 컴퓨터만 바라보는 불쌍한 개발자의 삶이기에 건강관리는 빠져서는 안 될 중요한 부분이라 하루 시간 계획을 다시 정비했어야 했다. 마치 시간표대로 움직였던 학창 시절처럼.

‘중니어 개발자’의 2020 회고

Thu, 31 Dec 2020 13:31:01 +0900

　그 어느 때보다도 정신없이 달려온 2020년. 하고 싶은 것도 많았고 큰 꿈을 꾸기도 했지만 현실의 벽 앞에 크게 좌절도 해보기도 하고. 갑작스러운 세상의 변화에 적응하랴 정신적으로 육체적으로 너무 많이 힘들었던 올해. 돌아보면 참 후회가 되지만 한편으론 시련과 좌절 속에서 여러 가지를 배웠던 그런 한 해를 보낸 것 같다.

　필자는 내년이 되면 이제 어느덧 개발자 생활을 한 지 9년 차가 된다. 보통 주니어라 함은 단순하게 이제 막 취업한 신입 또는 3~5년 차를 말하고 시니어는 연봉이 X 원을 넘거나 n 연차를 넘을 경우를 말하는 것 같다. 물론 각 회사마다 이 둘을 정의하는 기준이 다르겠지만. 그런데 필자는 주니어도 시니어도 아닌 그 사이에서 애매~한 연차. 중니어. 과연 나는 무엇을 해야 할까? 무엇을 해야 연차에 맞는 역할(?)이라고 할 수 있을까? 그리고 그건 누구에게 배워야 하고 누가 가르쳐 주기나 할까?

　매년 회고를 써왔다. 그럼에 연말이 되어서 연례행사처럼 작성하는 게 아닌 나에게 정말 필요한 방향으로 회고를 작성하려 한다. 단순하게 이런저런 일들이 있었고 ‘어쩔 수 없었네~’ 읊조리는 무의미한 회고보다 현실적으로 나 자신을 위해 변화해야 할 게 있으면 굵고 길게 계획을 세워보는 방향으로 해보고 싶다.

2019 회고
2018 회고
2017년엔 왜 없지..?
2016 회고

등장, 코로나-19

나가지 말라면 나가지 마! 밥 먹지 마! 모이지 마!
출처 : salihgonenli

　세상이 변했다. 작년까지만 해도 미세먼지가 심하면 마스크를 쓰고 나가곤 했지만 코로나-19라는 전염병이 전 세계에 퍼지며 이제는 마스크 없이 살 수 없는 세상이 되었다. 늘 사무실에 나가 팀 동료분들과 이야기를 하며 밥도 먹고 회의도 하며 업무를 진행했지만 재택근무를 한지 어느덧 반년이 훌쩍 지났다.

　처음엔 집에서 편하게 일을 할 수 있어서 좋았다. 그러나 IT 회사에 근무하고 있지만 아직도 버벅거리고 어색한 화상회의와 더딘 업무 진행으로 인해 점점 시간이 지날수록 답답함은 극을 달했다. 출/퇴근 시간 등 업무이외에 필요한 시간이 사라지며 오히려 업무에 집중하는 시간은 많아졌다. 그에 반해 피로도는 집중한 업무시간에 비례하며 늘어났기에 나무늘보처럼 늘어지는 시간들 또한 많았던 것 같다. 지나고 보면 그러한 시간들을 잘 계획하고 움직였더라면 뭐라도 배우거나 달성했을 시간들인 것 같아서 약간 아쉬움이 남는다. 내년엔 계획하는 시간의 비중을 좀 더 늘리는 것으로.

　아무쪼록 코로나-19 바이러스가 없어지고 다시 예전으로 돌아갔으면 좋겠다. 그에 마스크 잘 쓰고 손 잘 씻고 사람 많이 모이는 곳은 피해야 하는 건 우리가 ~~할 수 있는~~ 해야 할 가장 큰일이겠지.

회사생활

서비스 전면 개편

　팀에 투입한 이후 가장 큰 규모로 서비스 전면 개편을 진행하였다. 거의 올해 내내 했다고 봐도 무방할 정도. 업무의 양도 많았고 스펙 또한 복잡하였지만 가장 크게 배울 수 있었던 부분은 모놀리틱 서비스에서 마이크로 서비스로의 아키텍처 변화를 시도했다는 점. 그리고 일반적인 Request - Response 식의 1차원적인 흐름에서 이벤트라는 행위를 기준으로 모든 프로세스가 영향을 받는 구조를 적용하며 고민했다는 점에서 여러 가지 인사이트를 얻을 수 있었다. 아무래도 중니어다 보니 주어진 기능을 개발만 하는 것보단 좀 더 높은 곳의 설계 관점에서 고민하는 연습을 하려고 했던 것 같은데 아직 부족한 것 같다.

　올해도 개발 문화를 개선하려는 노력도 하였다. CI를 재설치하고 다양한 개선을 통해 빌드 속도를 몇 배로 늘리기도 하였고, 단순/반복적인 업무들은 각종 봇들을 개발하여 업무 생산성을 올리기도 하였다. Sentry를 서버 레벨에 적용하여 무분별하게 발생하는 에러들을 그룹핑하여 우선순위에 따라 에러를 해결할 수 있는 구조를 만들기도 하였고, 소나큐브와 jacoco를 적용하여 코드 커버리지를 도식화하며 현재 모듈의 상태를 보여주기도 해보았다. 개발 문화의 개선은 겉으로 드러나진 않지만 잠재적인 문제들을 해결하는 데 가장 큰 효과를 준다고 믿기 때문에.

애자일 아버지의 고함과 호통 (리뷰：Clean Agile - Back to Basics)

Sun, 27 Dec 2020 17:06:19 +0900

　‘애자일’ 이라고 하면 무엇이 떠오르는가? 잘은 모르지만 막연하게 생각을 해보면, 매일 오전 스크럼을 하고 진행 현황을 가시화하며 프로젝트를 성공적으로 이끄는 일종의 ‘프로세스’로 알고 있다. 좋다는 것도 들었고 도입을 하려 하지만 뭔지 모르게 잘 안되는 그것. 현업에 들어오면서 ‘애자일’ 도입의 성공/실패에 대한 이야기를 가끔씩 건너건너 들어만 본 수준이다. 이제는 주니어도 시니어도 아닌 중니어가 되어보니 알고리즘이나 패턴, 신기술도 중요하지만 팀과 프로젝트 전반의 건강하고 성공적인 진행을 위해서는 이러한 활동들이 중요하구나 하며 요즘 ~~(올해)~~ 뼈!저!리!게! 느끼는 중이다.

　마침 크리스마스 연휴를 앞두고 이 시국에 나가지도 못하는데 뭘 해야 하나 고민하고 있던 찰나 ~~운명처럼~~ 클린 애자일, 저자 로버트 C. 마틴이라는 책 추천을 받는다. 보통 필자는 읽고 싶은 책을 고를 때 중요하게 생각하는 두 가지가 있는데 표지와 추천인(혹은 리뷰어)의 대한 신뢰. 둘 다 너무 좋았기에 바로 인터넷 주문을 하였지만 그새를 못 참고 근처 서점에 들러 책을 사 온다.

갑.분.돈(키호테)

　풍차나 폭포를 공격해본 모든 프로그래머에게

풍차를 괴물로 보고 달려들었던 돈키호테

　호기롭게 첫 장을 넘기는데 강렬하게 다가오는 문구. 옮긴이에 따르면 세르벤테스의 소설 ‘돈키호테’에서 주인공 돈키호테가 풍차를 공격하는 모습에서 온 표현이라 한다. 대부분 헛되고 무모한 싸움을 하는 사람들을 빗대어 이야기하며 바보 혹은 현실 부적응자로 갈음하는 표현으로 사용된다. 러시아 작가 이반 투르게네프는 햄릿을 사랑하기는 힘들지만 돈키호테는 사랑하지 않기가 힘들다는 이야기를 했다고 한다. 아마 저자는 고민보다는 행동을 중요하게 생각했던 돈키호테를 빗대어 현실에 안주하지 않고 건강한 개발 문화를 개선하려는 모든 프로그래머에게 조언과 박수를 보내려 했던 건 아닐까 싶다.

책의 구성

　페이지 수(230p)가 많지 않아서 가볍게 읽을 수 있겠다 싶었지만 다소 작은 글씨들로 구성되어 있어서 책을 잘 안읽었던 필자에겐 약간 부담으로 다가왔다. 하지만 내용들이 너~무 공감이 되어 마치 필자의 2020년을 오래전에 예견하고 미리 써둔것 같은 느낌을 받았을 정도라 아침 5시에 일어나 저녁 11시가 되어서야 다 읽을 수 있었다. 처음 들어본 용어나 이해가 잘 안되는 개념들도 있어 다음날 노트북을 옆에 두고 찾아가며 다시 읽기도 하였다. (그만큼 제대로 읽어보고 싶었다.)

　책 초반부터 저자는 이 책을 ‘선언’이나 ‘정의’ 가 아닌 애자일에 대한 ‘경험’을 토대로 오해를 바로잡는다라고 이야기하고 있다. 2001년 2월, 애자일 선언이 발표가 되었고 내년이면 20년이 돼가는 시점에 여러 가지로 변형된 ‘애자일 방법론’이 나왔지만 애자일의 기준을 다시 소개하며 본질을 흐려선 안된다고 이야기한다. (책이 부 제목이 Back to Bascis인 것을 보면 …)

　흥미진진한 책 내용 중에 아직까지도 머릿속에 남아있던 애자일과 자주 비교되는 ‘폭포수 모델’로 프로젝트를 진행한 부분을 필자가 이해한 대로 적어보려 한다. (너무나도 끔찍하게 공감되기에…)

폭포수 모델로 프로젝트를 진행한 사례

프로젝트 관리자가 마감기한을 확인하고 회의를 진행한다. 지금은 1월이고 출시가 10월이니 각 일정은 거꾸로 계산하여 개발은 QA 기간 고려 9월에 종료, 설계는 7월에, 분석은 늦어도 4월까진 하는 걸로 ‘못 박는다.’ (네…?)

그렇게 여유롭게 시간을 보내다 4월이 되어 분석 단계가 끝난다. 왜? 4월이 됐으니까. 또 시간이 흘러 7월이 되자 기적이 발생한다. 설계 종료. 왜? 7월이 됐으니까. 그 후 남은 2개월 동안 개발자들은 엄청난 압박과 급증하는 야근과 함께 하나둘씩 팀을 떠나고 그만두기 시작한다. QA에서 확인한 버그가 셀 수 없이 쏟아져 나온다. (소름 1)

하지만 10월에 출시하기로 했으니 버그나 에러가 터져 나오지만 출시를 하고. 프로젝트는 실패로 돌아간다. 그리고 회고를 하고. 다음번엔 제대로 해야지! 하며 다짐한다. (소름 2)

저자는 이것을 따라잡을 수 없는 프로세스 인플레이션(Runaway Process Inflation)이라고 부른다. 우리는 될 리가 없는 일을 계속하려고 한다. 그것도 아주 많이.

벌써 2년 (feat. 토이프로젝트 회고,가치,수입)

Sun, 12 Jul 2020 19:55:02 +0000

　정확히 2018년 07월 12일 필자의 첫 토이 프로젝트인 ‘기술 블로그 구독 서비스’를 오픈하게 된다. 얼마나 많이 구독(가입) 하겠어 하는 생각이 부끄러울 만큼 6개월이 지나 구독자 수는 1,000명을 넘기고 1년이 지나 2,000명. 어느덧 달력을 보니 오늘이 정확하게 토이 프로젝트를 서비스한지 벌써 2년이 되는 날. 구독자 수는 어느덧 3,000명을 넘어선다. 뭔가 뿌듯하면서도 서비스를 좀 더 디벨롭 하지 못한 필자 자신을 돌아보니 괜히 마음이 무거워지고.

뭔가 해야하는데… 괜히 눈치만 보이네…
출처 : http://egloos.zum.com/nievess/v/657827

　지난 2년 동안을 돌이켜보며 서비스를 어떻게 운영해 왔는지, 그리고 토이 프로젝트가 필자에게 어떤 영향을 주었는지 되돌아보며 셀프 리뷰를 해 보고자 한다.

서비스 자체 평가

심플한 기능

　말 그대로 토이 프로젝트이기 때문에 기능 또한 아주 간단하다. awesome-devblog에서 제공하는 개인/단체 블로그들의 포스팅을 조회하여 어제 작성된 글들만 모아 발송한다. 거기에 주간 많이 클릭된 포스팅을 모아서 한 번 더 발송하는 기능까지. 추가적인 기능을 더 디벨롭 해야 하는데 아이디어가 없어서 인지 디벨롭 할 힘이 안 나서 인지 유지만 하고 있는 상태다.

서비스에 없어서는 안될 ‘로깅(Logging)’

　형식을 막론하고 컴퓨터로 돌아가는 모든 ‘프로그램’은 상황에 따라 미리 만들어 놓은 로직에 따라 움직이는 로봇에 불과하다. 물론 요즘에는 머신러닝이나 AI 같은 기술들로 컴퓨터가 스스로 학습하는 경우도 있지만 그 또한 미리 코딩을 통해 만들어진 부분들. 그렇기 때문에 2년이 지난 지금 이제까지 서비스가 어떻게 돌아갔는지를 확인하기 위해서는 사전에 준비해야 할 것이 있다. 그것은 바로 ‘로깅’. 서비스 투입 전부터 프론트부터 백엔드까지 다양한 로깅을 해서인지 2년이 지난 지금, 기록된 로그로 다양한 서비스 지표를 확인해 볼 수 있음에 다행이라 생각한다.

각종 지표

　먼저 봐야 할 지표는 당연히 가입/해지 추이. 드라마틱 한 선형 그래프는 아니지만 당연히(?) 해지 보다 가입이 더 많고 시간이 지날수록 어느 정도 꾸준하게 가입자가 들어오는 것을 보면 어떻게 알고 가입을 하러 오는지 신기할 따름이다. 하지만 마냥 신기해하지만 말고 해지하는 원인을 분석해야 할 필요가 있어 보인다. 아마도 수집하는 블로그들 중 간혹 개발과 관련되지 않는 글들이 종종 수집되어서 그런 것 같기도 하다.

가입/해지 트랜드

　다음으로는 클릭수. 눈치가 빠른 분들은 이미 알고 있겠지만 이메일에서 클릭 시 서버에서 각종 로깅을 하고 넘어가게 된다. 그러다 보니 클릭 성향(?)에 대해 집계도 가능한데 아래 지표를 보면 오전 일과를 시작하면서 메일로 종합된 기술 블로그 들을 읽기 시작하고 그중에서 특히 월요일 - 10시가 가장 많은 클릭수가 집계되었다.

클릭수 트랜드 | 시간+요일 별 클릭수 트랜드 | 시간+요일 별 클릭수 히트맵

　이 포스팅을 작성하고 있는 지금까지 약 19,000여 개의 포스팅을 수집하고 발행하였는데 그중에서 가장 인기 있었던 포스팅 TOP 30 은 다음과 같다. 아무래도 단체 블로그의 포스팅을 메일 상단에 위치하고 노란색으로 테두리를 표시해서인지 대부분의 글들이 단체 블로그의 포스팅인 것을 알 수 있다.

그렇다면 수익은 얼마나 있었을까? 음?! 이 서비스의 수익이 있다고?? 우선 아래 차트를 보자.

매니저는 정말 개발자의 무덤일까? (리뷰 - 개발자 7년차, 매니저 1일차)

Thu, 26 Mar 2020 23:37:17 +0000

개발자로서의 커리어는 정말 다양하지만 필자가 보고 들은 경험을 아주 일반화 시켜 정리해 보자면 다음과 같다.

처음엔 전공/비전공을 불문하고 신입으로 개발을 시작하여 다양한 개발 경험을 하게 된다. 사수에게 혼나기도 해보고 또는 혼내줄 사수가 없어 혼자 끙끙 밤도 새보고, 다크서클과 거북목을 겸비한 이른바 “삽질"을 하며 고통의 시절을 보내고 나면 어느덧 승진(진급)을 하며 일정 규모의 “팀장(혹은 관리자)“이 된다. 그게 자의든 타의든. 개발자는 다소 “기술"이라는 특수성을 가지고 있지만 어느 직군이든 간에 이러한 커리어 패스의 흐름은 매우 비슷하게 흘러가는 것 같다. 적어도 필자가 보고 들은 것만 보면 말이다. (예외 케이스는 항상 있지만…)

하루는 팀장님과의 면담 중에 “이제는 마냥 눈앞에 있는 개발만 할 것이 아니다. 기술을 좀 더 깊게 들여다보는 자리와 사람을 관리하며 주어진 과제를 진행하는 자리, 둘 중 선택해야 하는 시기가 온 것 같다. 더 높고 더 멀리, 그리고 더 넓게 볼 줄 알아야 한다.“라는 말씀을 듣게 된다. 어느덧 “그 시점"이 다가온 것이다. 개인적으로 필자는 팀장님이 말씀하신 두 가지 중 전자에 좀 더 가깝게 다가가고 싶다. 그만큼 오래오래 “실무 개발"을 하고 싶고, 또 그만큼 개발이 재밌기 때문이다. 아직도 눈앞의 문제를 해결하기 위해 개발하며 시간 가는 줄 모를 만큼 밤을 새우는 게 재미있는 걸 보면…

요리하는 걸 좋아하지만 이상하게 치킨집은 하고 싶지 않다.
출처 : https://catapult.tistory.com/entry/%EC%B9%98%ED%82%A8%EC%A7%91%EC%9D%B4%EB%82%98-%EC%B0%A8%EB%A0%A4%EC%95%BC%EC%A7%80

어느 날 SNS 피드에 개발 관련된 소식들을 받아보다가 개발 7년차. 매니저 1일차라는 제목의 책을 보게 된다. 뭐야, 이거 내 이야기 아니야? 하며 귀신에 홀린 듯 사서 읽어보려는 찰나, 마침 한빛미디어 에서 주최하는 나는 리뷰어다 라는 이벤트를 발견하게 된다. 결국 리뷰어에 당첨이 되고 운 좋게 해당 책을 받아볼 수 있었다. (이 책을 읽게 해준 한빛미디어 측에게 이 글로나마 감사의 인사를 전하고 싶다.)

필자의 SNS를 장식했던 ‘개발 7년차, 매니저 1일차’

이번 포스팅에서는 우선 책에 대한 리뷰를 간단히 적어보고 거기에 필자의 생각을 조금 더 얹어보고 싶다. 필자를 두고 만들어진 책 같아서 아직도 책 표지만 봐도 신기하고 설렌다. 일단 책 표지나 제목이 맘에 든 건 감출 수 없는 사실이다.

신입 혹은 주니어 개발자가 읽어봐도 좋을 책.

제목만 보면 이제 갓 팀장 혹은 매니저를 하게 되는 사람에게만 해당되는 책으로 보인다. 표지 상단에 “개발만 해왔던 내가, 어느 날 갑자기 ‘팀’을 맡았다!” 적혀있기도 했으니까. 하지만 책을 읽다 보면 꼭 그렇지마는 않다. 멘토링을 할 때엔 멘토와 멘티 각자의 위치에서 어떤 자세로 서로를 맞이해야 하는 방법에 대해서도 알려주기도 하고 무작정 눈앞에 있는 기능 개발만을 하며 안갯속을 걷는 주니어 개발자가 미리 미래를 경험해보는 좋은 사례를 들어 알려주고 있기 때문이다.

꼭 누군가 혹은 무언가를 “관리"하는 입장이 아닌 “팀"이라는 공동체 사회, 특히 개발 팀에서 팀원들과 협력하는 방법론을 살펴보고 있고, 경력이 낮으면 안 보이는 부분들까지 마치 멀리 있는 것을 대신 망원경으로 보여주는 느낌이 들었다. 앞부분에는 “이 책을 읽는 방법"이라며 상황별로 읽는 챕터를 가이드 해주고 있지만 사실 어느 하나 중요하지 않을 내용이 없어서 처음부터 무언가에 홀린 듯 읽을 수밖에 없었고 선배님이 앞서 지나간 길을 올바르게 지나갈 수 있도록 가이드 해주는 느낌으로 중간중간 사례가 있어서 현업에 있어서 그런지 좀 더 쉽게 읽힐 수 있었다.

다 읽고서야 알아차린 번역서(?)라는 사실.

어떠한 XX 기술 서적에서는 Method를 ‘방법’, Overriding 을 ‘과적’이라고 번역한 책들이 있는가 반면, 이 책은 읽는 내내 국내 어떤 분이 쓰신 거라 생각하고 읽어내려 갔지만 다 읽고 보니 외국에 어느 CTO가 쓴 책을 옮겨서 다시 써진 책이었다. 그만큼 전혀 특유의 번역 느낌(?)은 없었고 오히려 한국 문화에 맞춰 다시 써진 건 아닐까 싶을 정도로 너무 술술 잘 읽혔다.

조금은 무거운 2019 회고

Sun, 29 Dec 2019 22:22:03 +0000

“회고"는 비단 개발 블로그 뿐만 아니라 어떠한 과정의 마지막에는 꼭 해야할 중요한 시간인 것 같다. 앞만보고 달려가자! 닥공! 라는 말이 있지만 사실 이 말이 성립되기 위해선 지난 과거에 대한 정리와 반성 그리고 무엇을 하려고 했는데 어떤 이유로 못했는지와 그 동안의 나 자신을 바라볼 수 있는 이 “회고” 시간이 필요하다. 벌써 2019년도 마무리가 되어간다. 작년보다 더 정신없이 달려온 올해. 내년엔 올해보다 더 멋지고 힘차게 출발하기 위해 필자의 한 해를 돌아보고자 한다.

그렇다면 회고는 어떻게 하는게 가장 좋을까? 무작정 타임라인 기반으로 1월엔 뭐했고 2월엔 뭐했고… 이 방법이 틀린건 아니지만 타임라인 기반으로 정리를 한 뒤 키워드별로 다시 정리하는 방식이 가장 맞을것 같다는 생각이다. 무엇을 했고, 뭐가 좋았고 어떤건 아쉬웠고. 그래서 내년엔 어떻게 할 것이고. 각자의 회고 방식에는 차이가 있겠지만 회고를 하는 이유, 그리고 회고라는 목표 중에 공통점은 “뒤를 돌아보고, 앞을 보기위한 힘을 찾는것” 이 아닐까 싶다.

내년 회고를 할때는 흑백이 아닌 컬러 사진을 넣을 수 있는 분위기가 될까?…
출처 : http://www.nanum.com/site/poet_walk/820914

회사는 성장의 공간이 아닌것을 깨닳는 순간.

(이야기에 앞서 필자는 현재 서비스 개발자임을 밝힌다.)

내년이 되면 컴퓨터쟁이가 된지 벌써 8년차. 매년 성장의 그래프를 그려보면 작년까지만 해도 우상향이었다. (그래프의 기울기는 매년 달랐지만) 허나 올해는 기울기가 0 이거나 오히려 마이너스가 된 것 같은 느낌이다. 왜일까.

키는 왜 더이상 성장을 안할까? (쓰읍…)
출처 : http://www.guro1318.or.kr/bbs/board.php?bo_table=data&wr_id=1723

회사를 다니다 보면 아주 일반적으로 “시키는 일"을 하곤 한다. 주어진 업무를 정해진 기간 안에 스펙에 맞춰 개발하는. 아주 극단적으로 나쁘게 말하면 “도구"로 전락되어버릴 수도 있는 시간들. (개발자가 도구가 된다는 말은 너무나도 듣기 싫은 말중에 하나.) 흔히 말하는 CRUD(Create, Read, Update, Delete) 성의 개발 업무를 하곤 한다. 하지만 꼭 성과에 align(더 좋은 한국말을 찾고 싶은데…) 하는 일 말고도 허드렛일(일종의 서스테이닝?)을 할 경우도 있는데 그게 만약 재미없는 일이라면 어떨까?

필자는 그렇게 “시키는 일만 하며 재미없는 회사생활” 보다 “재미있게 개발하며 성장을 할 수 있는 회사생활” 이라는 기준을 가지고 한 해를 지내온 것 같다. 즉, “시키는 일"이 아닌 “시키지도 않은 일"을 찾아서 해가며. 예컨대, 처음에 잡았던 서비스 구조가 사용자가 많아지고 요구사항이 많아짐에 따라 복잡하고 성능을 저해하는 상황을 발견하고 미리 구조개선을 통해 성능과 효율이라는 두마리의 토끼를 잡는다거나. 지난 외부 세미나에서 듣고 인사이트를 얻어 팀내에도 적용해본 배치 무중단 배포 기능. 팀 내 코드리뷰의 활성화와 수동으로 해야할 업무들을 메신저 봇을 활용하여 자동화 한다거나. 서비스 지표 대시보드를 만들어 한눈에 서비스 상황을 볼 수 있게 별도의 개발 페이지를 만들어 보는 등. 다양한 업무 내/외 적으로 일을 찾아가며 + 필자의 개인 시간을 할애해 가면서 정말 재미있게 보내온 것 같다.

하지만 뒤를 돌아보면 “성장 했는가?” 라는 질문이 있다면 “그렇게 하고있는것 같아서 신나게 해왔는데 돌아보니 막상 뭘했나 하는 느낌이 든다” 라고 말할 수 있을 정도로 여러가지를 많이 하며 다양한 “경험"을 얻긴 했지만 실질적인 “성장"은 아쉽지만 부족한 한 해 였던것 같다.

회사가 원하는, 연차에 맞는 업무 역량과 개발 팀에서의 위치를 충족시키기엔 회사 안에서 성장하기엔 한계가 있다고 판단이 들었다. (이 생각이 왜 이제서야 들었을까.) 오픈소스나 새로운 언어를 회사 밖에서 혼자서 공부 하던지 여러명이서 스터디를 통해 습득을 해야하고 토이프로젝트 또한 회사와 별도로 진행하며 개발 스킬을 늘려야 할것 같다. 그 이유는 회사에서의 성장이 결국 나의 성과로 잡힐 수는 없는데 괜시리 기대를 하게 되기도 하고 특히 서비스를 운영하는 팀에서는 요즘 핫 하다는 개발 방법론이나 솔루션을 도입하기에는 다소 무리가 있기 때문이다. (물론 회사일도 하면서 성장을 할 수 있는 상황이라면 금상첨화. 이를 찾는건 정말 어려운 일 같다.)

우아한 스프링 배치 테크세미나 정리 및 후기 (by 우아한 형제들)

Sun, 29 Sep 2019 17:55:50 +0000

지난주 우아한 형제들에서 진행하였던 “9월 우아한 테크 세미나 - 우아한 스프링 배치” 에 다녀왔다. 필자에게 이번 9월은 정신이 어디에 있는지 모를만큼 바쁘고 힘들었지만 예전부터 궁금하기도 했고 요즘들어 관심을 갖던 “배치 어플리케이션"을 어떻게 하면 “우아한 방법"으로 사용할 수 있을지에 대해 여러 생각들이 있었기에 큰 기대를 가지고 지옥철을 견디며 잠실 근처에 있는 우아한 형제들 작은집으로 가게 되었다. 어떤 내용을 발표하였는지에 대해 기억잘하는 똑똑한 앵무새가 되어 정리하기 보다 주요 포인트에 대한 생각과 함께 참여를 못한 분들 위해서라기 보다 내 스스로 정리를 하기 위해 포스팅을 작성해 보고자 한다. (이번에도 불러주셔서 감사합니다 ^=^)

인트로

연사자 분은 워낙에 유명하신 분이라 별도의 설명이 필요 없이 운영하시는 블로그 주소로 대체를 해본다. 이번 행사에 초대되신 분들은 한번이라도 스프링 배치를 써분 분들을 대상으로 진행하게 되었다고 했는데 마침 필자도 팀 내에서 운영하고 있는 배치 어플리케이션을 보다 효율적이고 우아하게 바꿔보고자 하는 니즈가 있었기에 아마 초대된게 아닐까 싶다.

아기자기한 우아한 형제들 건물 내부

더불어 발표전에 간략히 회사가 원하는 인재에 대하여 언급해주셨는데 그게 어찌나 공감이 가던지. 역시 생각이 남다른 회사구나 하고 다시한번 생각을.

자기보다 경험이 “적은” 사람에게 “설득을 당할 수” 있어야 하고, 자기보다 경험이 “많은 사람을 설득” 시킬 수 있어야 한다.

기본편

배치 어플리케이션이란 컴퓨터에서 사람와 상호작용없이 이어지는 프로그램(작업)들의 실행이라고 위키피디아에 간결&명료하게 정리되어 있다. 그만큼 일반적인 웹 어플리케이션과의 차이가 있는데 웹 어플리케이션은 실시간 처리가 기본이고 요청에 대한 응답을 제공해야 하니 아무래도 속도가 상대적이며 QA시 편한 부분이 있다. 그에 반해 배치 어플리케이션은 웹 어플리케이션에서 말하는 요청이라는 개념보다 후속처리에 가깝고, 속도 또한 절대적이며 QA가 복잡하다는게 특징이다. 따라서 테스트코드는 웹 어플리케이션 보다 배치 어플리케이션이 더 필요하다고 볼 수 있다. 배치 어플리케이션이 필요한 상황은 크게 두가지로 나눠 볼 수가 있다고 한다.

일정 주기로 실행 되어야 할 때
실시간 처리가 어려운 대량의 데이터를 처리 할때

평소 첫번째 상황만 생각하고 배치 어플리케이션을 작성하곤 했었는데 두번재 상황에 대해 생각에 생각을 더 해보니 스프링 배치를 간단하게만 (Tasklet) 사용하고 있는건 아닌가 하는 반성을 해보곤 했다. (Reader, Processor, Writer 등 다양한 레이어가 있는데도…)

특히 스프링 배치에서는 기본적으로 모든 데이터를 메모리에 쌓지 않는 조회방식라고 한다. (DB기준) Paging 혹은 Cursor로 pageSize만큼만 읽어오고 chunkSize만큼만 commit 하는 형태. 이러한 각 레이어별 size를 잘 조정하기만 해도 적은 노력으로 큰 성능을 얻을 수 있는 부분이 프레임워크를 사용하는 이유 아닐까 라고 생각해본다.

또한 @JobScope 나 @StepScope는 Late Binding 즉 배치 어플리케이션이 실행되는 시점이 아니라 Job 이 실행될때 생성이 되기 때문에 이를 활용하여 동적으로 reader / processor / wirter 레이어를 만들 수 있다고 한다.

활용편

스프링 배치를 이용한 배치 어플리케이션이 있고 이를 스케쥴링 등 관리를 해주는 도구들에 이야기를 해주셨다.

Cron
- 리눅스를 어느정도 사용해봤다면 알만한 리눅스 기본 스케쥴링 프로그램인 Cron.
- 필자도 Cron 으로 주기적으로 실행하도록 설정해보기도 하였지만 배치 어플리케이션의 특성상 로그 및 실행/종료 등 제한사항이 많은 건 사실인것 같다.
Spring MVC + API Call
- 주변에서 사용하고 있다고 하던 방식. 이 방식의 장점은 항상 떠있기 때문에 어플리케이션 구동시간이 별도로 필요 없다는 장점이 있지만 전반적인 관리가 어려운 단점이 있는것 같다.
- 물론 울며 겨자먹기 식으로 단점을 극복할 방법은 여러가지가 있겠지만 모든건 항상 Trade off
Spring Batch Admin (Deprecated)
- 예전 팀분이 알려주셔서 잠깐 봤던 부분이긴 한데 어느사이에 Deprecated 되었다고 한다.
Quertz + Admin
- http://www.quartz-scheduler.org/
- 아주 오래전에 써본 기억이 있지만 배보다 배꼽이 더 큰 상황같았던 힘들었던 기억들만 남아있는 구현방법인것 같다. 여러 레이어를 혼용해서 쓰다보면 각 레이어간의 상호 연결성의 위배되는 경우가 많기에…
CI Tools (Jenkins / Teamcity 등)
- 아무래도 가장 추천할만한게 CI Tool 인것 같다. 그중에 필자도 Jenkins라는 툴을 너무 좋아하고.
- 유료 툴 중에 Teamcity 를 잠깐 언급해주셨는데 찾아보니 한번즈음 써보고 싶을만한 기능들이 있어보였다.

Jenkins 의 장점은 ~~말해뭐해~~ 정도로 배치 어플리케이션과 궁합이 너무 잘 맞는 툴인것 같다. (물론 다른 툴들도 있겠지만 필자개취라 넘어가도록 하자.) 특히 실행시 필요한 플러그인들이 다양하게 많이 있고, 실행방법 또한 수동/스케쥴링 으로 다양하게 할 수가 있으며 RestAPI 지원과 보안, 실행이력관리, 로그 등 최적화 되어있다고 해도 과언이 아닐정도로 다양한 장점들이 있는것 같다.

2019 상반기 리뷰 (feat. 글또)

Sun, 07 Jul 2019 17:52:20 +0000

누구나 어렸을 땐 빨리 어른이 되고 싶어 하는 것 같다. 시간이 빨리 지나가길 바라고, 빨리 어른이 되고 싶다는 간절함이 있지만 이상하게도 그땐 시간이 천천히 가는 것처럼 느껴졌다. 반면, 시간이 천천히 갔으면 하는 때가 있다. 딱 지금. 남들은 워어어어얼화아아수우우모옥금퇼 이라고 부르며 시간이 느리게 간다고 빨리 주말이 왔으면 좋겠다고 하지만 요즘의 필자는 정 반대다. 방금 출근한 것 같은데 어느샌가 퇴근인사를 주고받고 있다. 무언가에 홀린 것 같다. 벌써 올해도 절반이 지나가고 뜨거운 여름과 함께 후반전이 시작되었다.

그래서 빨리 지나갔나…
출처 : https://m.blog.naver.com/kong6482/220584667861

이제까지는 12월 말 즈음에 한 해를 바라보고 리뷰를 했었는데 글또라는 글쓰기 모임에 가입을 하게 되어 상반기 리뷰를 해보려 한다. 글또 모임의 첫 숙제가 상반기 리뷰 포스팅이다. 사실 리뷰를 상반기에 하던 연 말에 한 해 기준으로 하던 정해진 건 없지만 나를 다시 바라보고 다잡는 시간이 많을수록 보다 더 앞으로 가는데 힘이 될 거라는 데에는 이견이 없다.

회사 속에서의 나

회사에서는 회사일이 최우선!
출처 : https://m.blog.naver.com/hwee__/221191852972

최근에 팀장님과 면담 중에 나온 이야기다. 신기하게도 군 시절 장기를 꿈꾸던 필자를 어서 전역하라고 권유하시던 대대장님께 매일같이 들었던 이야기와 비슷하다.

“이제는 단순 개발만 하고 기능구현만 하는 것이 아니라 그 이상을 해야 할 시기가 다가온다.” “사람들 관리가 될 수도 있고 어느 한 분야에 전문가가 되어야 할 수도 있고, 선택은 본인의 몫”

사실 기능 구현이야 누구나 다 할 수 있다. 단지 경험에 따른 구현의 속도나 안정성의 차이가 아닐까 생각해본다. 그렇다면 그 이상은 어떻게 해야 할까? 정답은 없겠지만 필자는 그 이상을 해보려 우선 팀에 도움이 되기 위해 여러 가지 자동화 툴 들을 만든 것 같다. 보다 기능 개발에 집중하고 단순 반복적인 업무는 시스템이 할 수 있도록. 그렇게 툴들을 만들어 가며 생각하지 못한 부분들을 배우게 되고 나중에 그걸 또 사용하게 되는, 미래의 나를 위해 강제로 배우고 있는듯한 느낌이랄까. 아, 물론 회사 본연의 업무가 최우선이지만 말이다. 어쨌든 시킨 일은 우선 차질 없이 잘 하고 시키지도 않은 일을 찾아서 하려고 노력했던 것 같다. 팀을 위해서, 곧 나를 위해서. 적어도 회사에서 있는 시간 속에서는 다른 곳에 한눈 안 팔고 회사 업무에 전념하려고 노력했던 것 같다.

외부 활동

부족한 시간을 쪼개면서 밋업이나 세미나에 참여하곤 했었다. 그리고 마냥 듣고만 오진 않았고 “행사에 참여하면 무조건 질문 하나는 하자"라는 나와의 약속을 지키며 정리한 내용을 블로그에 포스팅하기도 하였다.

올해 첫 발표!

디자이너와 개발자가 함께하는 투게더톤을 진행하기도 했었다. 투게더톤은 약 한 달 동안 진행되는 해커톤으로 하루 또는 무박 2일 동안 하는 기존 해커톤과 다르다. 이 기간 동안 팀 내에서 자유롭게 일정을 조정할 수 있다. 우리 팀은 약 7주에 걸쳐 “동네 마트 할인 정보를 알려주는 앱” 을 만들게 되었다. 필자는 API 전반에 대해 담당을 하였고 작은 부분이었지만 웹사이트도 간단하게 만들어 보았다. 아무것도 없는 백지상태에서 시작하려니 막막했지만 후기에서도 적었듯이 다시 해보라고 하면 머릿속에 전체 아키텍처가 그림으로 그려질 만큼 자신감이 생겼다. 특히 정말 좋은 팀원들과 함께 협업할 수 있어서 너무 좋았다.

내공 연마

한 달에 2개 이상 블로그 글을 작성하는 목표가 있었다. 그런데 지난달에 이사를 하다 보니 (핑계…) 목표를 달성 할 수가 없었다. 하지만 나름 퀄리티가 있는 글을 쓰려고 노력했고 PV도 작년보다 조금씩 오르고 있는 것 같아 내심 기분이 좋다. 그리고 작년 말부터 시작한 필자의 첫 토이프로젝트 인 기술블로그 구독서비스 에 이런저런 기능을 추가하였다. 설마 1000명이 넘게 구독 하겠어?라고 생각했지만 이 글을 작성하고 있는 시점에서 1,569명이나 구독했다. 설마 1년 넘게 내가 이 프로젝트를 운영하겠어?라고 생각했지만 다음 주가 되면 딱 1년째. 신기할 따름이다. 마침 기회가 되어 GDG 주관으로 행사하는 모두의 TOY STORY: SIDE PROJECT 어디까지 가봤니?라는 주제에 첫! 공식 발표자로써 발표를 할 수 있게 되어 너무나도 영광이다. 해당 발표 후기는 나중에 작성하는 것으로~

D.light 투게더톤 참가후기

Sun, 19 May 2019 22:46:03 +0000

회사일을 하다 보면 시키는 대로 혹은 팀의 목표에 부합하기 위해 어쩔 수 없이 해야 하는 일을 하게 된다. 그러한 일이 재미있고 결과물에 대한 만족도가 100% 라면 다행이지만 간혹 재미도 없고 시켜서 하는 일은 밤을 꼬박 새 가면서 완성을 해도 썩 그렇게 만족스럽지 못한 경우가 대부분인 것 같다. (물론 회사일에서 자신만의 인사이트를 찾는다면 금상첨화겠지만… + 매번 회사일이 재미없고 하기 싫은건 아님) 언제부터인지 필자도 이러한 부분에 갈증을 느끼며 회사와는 별도로 무언가를 만들어 보고 싶은 마음이 무럭무럭 생겨날 즈음 facebook 타임라인에서 개발자와 디자이너가 약 7주간 프로젝트를 진행하는 D.light 투게더톤 이라는 행사가 있다는 것을 발견하고 나름 정성스레 지원서를 작성 후 합격 메일을 받게 된다. (GDG Facebook 해당 게시글) 이번 포스팅에서는 해커톤과는 살짝 성격이 다른 D.light 투게더톤을 진행하면서 느꼈던 부분들과 진행한 결과물에 대해 간략히 리뷰를 해보며 정말 급행처럼 지나간 약 7주간을 돌이켜 보는 시간을 갖고자 한다.

팀 빌딩

눈도 못마주칠 정도로 어색한 첫날
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를 활용해서 구성할 수 있었다.

자바, 성능, 모니터링 테크세미나 정리 및 후기 (by 우아한 형제들)

Sun, 12 May 2019 20:04:01 +0000

실무에서 자바 기반으로 개발을 하고 서비스를 운영을 하다보면 처음엔 아무런 문제가 없다가 사용자가 몰리는 등 이벤트성으로 트래픽이 많아질 경우 꼭 문제가 생기기 마련이다. 그럴때면 뒤늦게 부랴부랴 원인을 찾고 개선하기 바빠지게 된다. (아마 윗분들에게 혼나면서?ㅠㅠ) 평소에 이런 성능문제를 개선하고 미리 모니터링 할수있는 부분에 대해 관심을 갖고 있었던 찰나, 우아한 형제들에서 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.oracle.com/technetwork/tutorials/tutorials-1876574.html
- Collections of (불변) : List.of, Set.of, Map.of
Java 10
- var 의 등장
- Application Class-Data Sharing(AppCDS)
Java 11
- Oracle JDK의 유료화
- Http Client. 기본 설정값들을 제대로 알고 써야한다. ( https://golb.hplar.ch/2019/01/java-11-http-client.html )
Java 12
- Switch expressions
- Shenandoah : https://www.youtube.com/watch?v=E1M3hNlhQCg

모니터링

유명한 상용 APM들을 설명해 주셨다. 각각의 장점에 대해 설명해 주셨는데 정말 회사에 요청해 구매할수만 있다면 사서 해보고 싶을정도로 신기한 기능이 많았다. 그중 dynatrace 는 에이전트만 설치해두면 별도의 설정 필요없이 알아서 해준다고…

KafkaKRU(Kafka 한국사용자 모임) 밋업 후기

Sun, 31 Mar 2019 01:49:30 +0000

필자는 ElasticStack을 사용하면서 처음 카프카를 접하게 되었다. 메세징 큐 라는 개념도 전혀 모르는 상태에서 설치부터 ElasticStack 연동까지 사용하며 정말 강제로 카프카에 대해 공부를 하게 되었다. 카프카를 자주 다루고 메커니즘에 대해 자세히 살펴보다 잠깐 해이해질 무렵 카프카 한국 사용자 모임에서 밋업을 한다고 하길래 빛의 속도로 신청, 아마도 1등으로 신청했지 않았을까 싶다. 사실 작년 카프카 밋업을 못간게 너무 한(?)이 되어 이번엔 회사 업무 등 여러가지로 한창 바쁘지만 “지금이 아니면 안돼” 라는 생각으로 밋업을 다녀왔고, 짧지만 후기를 작성해 보고자 한다.

(요즘 왜 이렇게 바쁜지 모르겠지만… 신기하게도 그 바쁜 일정들이 하나도 겹치지 않는게 더 신기하다… )

삼성 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 같은?) 빼서 사용하는 형태가 아니라 Interactive Query 또는 Queryable Store 로 활용 가능

사실 이부분은 필자가 제대로 못따라간 세션중에 하나이다. 용어나 메커니즘도 다소 생소했고 대략 어떤 부분을 발표해주시는지 느낌은 있었으나 제대로 이해를 못해서 … 부끄럽지만 카프카 스트림즈의 공식링크로 대체한다.

Write The Docs 서울 밋업 후기 (개발자 강추!)

Sun, 24 Mar 2019 21:43:14 +0000

필자는 평소 개발자에게 가장 중요한 덕목 중 하나가 글쓰기라고 생각하고 있다. 마침 글쓰기와 기술의 접점을 고민하고 이야기하는 “Write The Docs 서울 밋업”(링크) 이 있다고 하여 쉬고 싶던 주말이지만 만사를 집어치우고 참석하게 되었다. 사실 연예인 개발자분들을 직접 만날 수 있다는 기대감도 있었기 때문이다. (발표하시는 바로 앞자리에 앉았는데 정작 한마디도 못 건넸지만…)

밋업 가능길 문득 나를 사로잡았던 문구와 밋업 장소 마루 180

발표에 앞서 “이 발표 자료는 공개할 예정이니 필기하실 필요가 없다"라고 하셨다. 하지만 뒤통수를 (좋은 의미) 몇 대 아니 몇십대 맞은 느낌이라 정리를 하지 않을 수가 없었고 오늘 느끼고 배운 마음을 쭉 유지하고 싶어(내 것으로 만들고 싶어) 후기를 작성해 본다. 더불어 제목에 감히 개발자 강추!라고 적을만큼 최근 밋업 행사 중에 손꼽을 정도로 좋았기 때문이다.

이정도로 쌔게 맞은건 아니다…
출처 : 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 팀에 대해 소개를 해주시며 꼭 기술 관점이 아닌 다양한 분야에서 해당 팀이 어떤 지원을 해주고 있는지에 대해 알려주셨다. 기술 블로그 운영, 소셜 페이지 관리, 개발 컨퍼런스, 세미나, 커뮤니티 후원 등등 개발자와 개발 문화를 알리는 모든 일을 하고 있다고 한다. 옆 회사(?)이지만 저런 개발자의 문화를 만드는 팀이 있다는 게 부럽기도 하였고, 가끔 세미나가 있는 걸로 아는데 공개적으로 하면 어떨까 하는 아쉬움이 있지만… 점차 private에서 public으로 확대될 꺼라 기대를 해본다. 발표를 내가 직접 들으며 이러한 문화를 만들 수도 있겠구나 하는 생각도 해봤다. 작게는 팀 단위부터 시작해서 서버/앱 등 개발자들을 모아두고 관심 있는 사람들끼리 공유하는 자리를 정기적으로 만드는… 중요한 건 “정기적"으로… 일단 나부터라도 시작을 해보자.

2018 회고 - Coder가 아닌 Programmer로

Mon, 31 Dec 2018 21:33:29 +0000

매사에 행동하는 모든것들의 끝자락에서는 그동안 잘한것과 못한것을 다시 생각하며 잘한것은 보다 더 잘할수 있도록 하고 못한것은 왜 못했는지 그리고 어떻게 하면 못한 부분을 고칠수 있을지에 대한 시간을 갖으려고 노력해왔다. 그게 개발이 되었든 게임이 되었든 연인과의 데이트가 되었든 뭐든지. 이러한 시간들은 필자에게 큰 인사이트를 얻을 수 있게 되었고 지난 한해를 돌이켜 보자면 개인적으로 계획한 전부를 다 이뤄내지는 못했지만 나름의 많은 경험과 성과를 달성했다고 생각해본다. 이제 몇시간 뒤면 올해가 끝나고 새로운 한 해가 시작되는 이 시점에 개발자로써의 회고를 해보며 2018년 정리 및 2019년 목표를 다짐해보자.

글쓰는 개발자가 되자. 개인 블로그 운영

아주 오래전, 동기 형을 통해 개발자가 글을 써야하는 중요성에 대해 절실하게 배우게 되었고 그때부터 블로그를 운영하기 시작하였다. 그 동기형의 말에 조금 더 내 생각을 첨가하자면 글을 쓰다보면 누군가 내 글을 본다는 마음에 내가 알고있는 지식을 보다 더 깊게 공부하게 되고 그것들이 모여 내 개발 히스토리가 만들어 지며 포트폴리오 등 다양하게 활용할 수 있기에 블로그를 운영하는건 정말 좋은 선택지 였던것 같다. 실제로 그냥 구글링 해서 알게된 것과는 또 다른 배움이 있었기 때문이다. 회사 일 그리고 개인 공부를 하면서 적어도 한달에 한가지 이상은 배우게 되기 때문에 올해 초 한달에 한개 이상의 글을 쓰기로 결심하였다.(그 달의 글이 없다면 뭔가 놀았거나(?) 미친듯이 바빴거나 아니면 게을렀거나…) 블로그에 글을 쓴 내역을 그래프로 시각화 해보면 아래처럼 총 23개의 글을 작성하였고 월 평균 1.9개의 글을 작성하게 된것을 볼수 있다.

9월달엔 팀 옮기자마자 엄청 바빴고, 11월엔 그 바쁜게 결실을 맺는 시간… 이라 핑계를… (나중에 블로깅 예정, 병렬 프로그래밍 관련)

월별 글 작성수

위 결과만을 두고 봤을땐 많으면 많고 적으면 적다고 할 수 있는 결과지만 개인적으로는 자투리 시간을 활용해서 그간 배웠던것, 그리고 경험했지만 내것으로 만들지 못하고 보기만 하며 넘어간것들에 대해 귀찮지만 시간을 투자하고 정리했더라면 더 많은 글을 썼을것 같다는 조금 아쉬운 결과라고 생각이 든다.

주 단위 PV, 누군가 내 글을 보고 있다는것에 뿌듯함

나름 열심히 글을 쓴 결과일까, GA를 통해 본 필자의 블로그에 유입량이 점점 늘어나는것을 보며 하나를 쓰더라도 좀더 자세히 독자의 입장에서 써야겠다고 다시한번 다짐하게 된다. 다만 글을 “많이” 쓰는것보다 하나를 작성하더라도 원인과 근거를 들어가며 문제를 정확히 파악하는데 집중을 해야하고, 단순 사용법 나열이 아닌 실제로 경험을 해가면서 “내것"으로 만드는 과정이 필요하겠다.

회사 팀 변경 그리고 토이 프로젝트

기존에 아무것도 없던 환경에서 서버 발급부터 이런 저런 서비스에 도움이 되는 다양한 모니터링 툴을 개발하며 무사히 서비스를 오픈을 하였고, 약간의 매너리즘이 생겨날 즈음 좋은 기회가 생겨 성격이 전혀 다른 서비스를 하는 팀을 옮기게 되었다. 약간 이직과도 비슷한 느낌으로 팀을 옮기게 되었는데 처음엔 새로운 지식을 습득해야 하는 두려움도 있었고 기존 서비스에 애정이 많아서 고민이 많았지만 벌써 옮긴지 5개월이 지나고 돌이켜보면 올해 가장 잘한 일 중 하나가 아닐까하는 생각이 든다. 전 팀에선 서비스를 운영하는데 그쳤지만 지금 내가 있는 곳은 대용량 서비스를 성능측면에서, 그리고 아키텍쳐 측면에서 보다 효율적으로 개발하는데 집중을 하려는 모습들이 보이기 때문이다. 더불어 팀에 투입되자마자 필자 홀로 기존에 있던 병렬 프로세스를 개선하여 서비스적으로 약 90%의 개선효과를 볼수있었는데 이 부분은 추후 포스팅 할 예정이다. 그리고 팀을 옮기기 한두달 전 개인적인 여유시간이 많이 있었고, 다른사람들의 블로그를 보며 챙겨보고 싶은 마음에 토이 프로젝트를 만들게 되었다. 7월 중순부터 시작했으니 이것도 어느덧 반년이 지나고 있는데 운영을 해가면서 기능을 추가하기 위해 종종 밤을 새는 등 올 한해있어 꽤 많은것을 얻을수 있었던 시간이였다. 간혹 버그가 생겨 메일이 발송 안되면 지인 또는 모르는 분들이 메일로 제보도 해주시고 … 색다른 경험이였다. 자세한 내용 및 후기는 개발후기-1 과 개발후기-2에서 확인 가능하다. (어서 3편을 쓰고 마무리를 지어야 할텐데…) 그리고 최근에는 아카이빙 기능을 만들어 과거 글을 조회할수 있도록 만들었는데 2% 부족한 느낌이다… (맘같아서는 형태소 분석을 해서 자동 필터링도 해보고 싶은데…)

엘라스틱서치 12월 서울 밋업 후기

Thu, 13 Dec 2018 22:27:02 +0000

엘라스틱을 처음 접하게 된 건 2017년 여름 facebook 피드에 “Elastic Stack을 이용한 서울시 지하철 대시보드” 라는 링크를 보게 된 것부터인 것 같다. 그 당시 데이터 분석 및 자동화에 관심이 커지고 있던 찰나였는데 키바나로 간단하면서도 아주 멋진 대시보드를 그릴 수 있다는 게 너무 흥미롭게 다가왔고 거기다 실시간으로 볼수 있다는 점에 공부를 시작하지 않을 수 없었다. 그렇게 이것저것 만들어 보기도 하고 한국 엘라스틱서치 커뮤니티 활동을 해오던 찰나 (최근들어 눈팅만 하고 있지만…) 올해 마지막 밋업을 한다고 하여 참여하게 되었다.

여기어때 본사 방문

강남에 위치한 여기어때 본사에서 밋업을 하게 되어 덕분에 다른 회사 구경을 할 수 있게 되었다. 예전 다른 IT 스타트업 밋업 행사에서도 느꼈던 부분인데 엄청나게 큰 시설은 아니지만 아기자기하게 회사의 색깔과 특징을 잘 살려놓은 인테리어가 인상적이었다. 그런데 생각보다 사람이 너무~ 많이 와서 약간 집중이 안 될것 같았지만 다행히도 자리를 잘 잡아서 세션을 듣는 데는 무리가 없었다. (정확하진 않지만 참석하신 분들 중의 절반 정도만 강의장에 들어오고 나머지는 밖에서 듣는 걸 보고 이런 IT 행사의 인기를 다시 한번 실감할 수 있었다.)

‘여기어때’ 본사건물에서 엘라스틱 밋업을!

엘라스틱서치 6.5 최신버전 소개 및 커뮤니티 회고

행사 처음 세션으로 김종민 커뮤니티 엔지니어 분께서 엘라스틱의 최근 업데이트 정보와 커뮤니티 활동에 대해서 회고해주셨다. 내가 처음 엘라스틱서치를 접한 버전이 2.4였는데 벌써 6.5라니… 빨라도 너무 빠르다. 이번 버전에서는 한 클러스터에서 다른 클러스터로의 인덱스를 복제하는 방법인 Cross-cluster replication (클러스터 복제) 기능이 추가되었고 ODBC Client 추가, 자바 11지원 등 여러 가지 기능이 추가되었다고 한다. 특히 키바나에서는 파일을 업로드하면 자동으로 분석해서 인덱싱을 해주는 기능도 생겼고 (파일 크기가 100메가 제한이라는게 살짝 아쉽긴 했다.) 캔버스, 스페이스 등 역시 키바나 라는 생각이 들 정도로 비주얼라이징을 한번더 업그레이드 한듯 하다. (다 사용할 수 있을까 하는 정도로… 엘라스틱 스택을 들어보기만 하던 함께 참석한 동기 녀석도 당장 해보겠다고 할 정도로…) 다른 자세한 내용은 여기서 확인이 가능하다.

너무나 빠른 버전업과 너무나 발빠르게 움직이는 사람들

엘라스틱서치 활용사례

스마일게이트 및 여기어때 에서 엘라스틱 서치를 활용한 사례를 발표해 주셨다. 하지만 아쉽게도 필자는 5.6 버전까지밖에 사용한 게 전부여서인지(그것도 일부 기능만) 전체 발표 내용을 다 이해를 하진 못했지만 구축하면서 생긴 문제나 삽질 경험담을 공유해주셔서 간접적으로라도 그때의 현장감(?)을 느낄 수 있어 좋았고, 한편으로 여태까지 나름 엘라스틱서치를 만져봤다고 약간의 자신감 반 자만심 반으로 생각했었는데 역시 세상엔 고수가 많구나 하며 다시 분발해야겠다고 다짐했다.

스마일게이트 + 여기어때

마치며

커뮤니티 활동 회고 시간에 누가 페이스북 커뮤니티에서 “공유"라는 단어를 사용해서 게시글을 작성했는지 키바나로 보여주고 밋업에 온 사람이 있다면 5만원 여기어때 쿠폰을 준다고 했었다. 마침 키바나 대시보드 한쪽 구석에 필자의 이름이 보였지만 (예전에 나름 활발하게 질문도 하고 공유도 했던 적이 있어서…) 쿠폰을 받는구나 하며 기대를 하고 있었지만 아쉽게도 최근에 작성한 몇 분에게만 선물이 돌아갔다… 하지만 그 아쉬움도 잠시, 무작위로 추첨하여 또 쿠폰을 준다고 했는데 당첨이 되어서ㅎㅎ 감사하게도 쿠폰을 받는 기쁨을 누릴 수 있었다!!

역시 밋업의 마무리는 굿즈모음이지(?)

매번 이런 IT밋업에 참가 신청을 하고 참석하기 전에는 “아 귀찮다. 취소할까. 날도 추운데. 피곤한데” 하며 가기 싫었지만 막상 와보면 생각보다 많은 것을 배워가고 얻어 간다. (쿠폰을 받아서가 아니라…) 세션에 발표하시는 분들, 그리고 그 발표를 듣는 참석하신 분들의 눈동자에서 배움에는 끝이 없고 배워야 살아남는다는 걸 (특히 IT직군은 더…) 다시 한번 느끼고 생각할 수 있었던 좋은 시간이었다.

Deview 2018 리뷰 (Day 1, Day2)

Sun, 14 Oct 2018 18:26:26 +0000

회사 내에서도 대학시절 수강신청마냥 1분도 안되서 마감될 정도로 관심이 많았던 DEVIEW 2018. 다행히 클릭신공으로 운좋게 신청에 성공하였고 팀에서도 바쁜 시기였지만 감사하게도 보내주셔서 올해는 이틀 모두 다녀올수 있게 되었다. 예전에는 연차가 올라가면 DEVIEW행사는 참여 안하겠지~라는 생각이 있었는데 그때는 단순 호기심에 참석을 하고 싶었다면 이번에는 뭐라도 배워오자라는 마음으로 신입 시절보다 조금더 성숙한 마음가짐과 자세를 가지고 참석을 하게 되었다.

다시 생각해보면 호기심만으로 세션들을 듣고 부스에서 나눠주는 굿즈를 조금이라도 더 받아와야지 하고 생각했던 신입시절의 생각이 틀린건 아니였지만, 말 그대로 기술행사이니만큼 가급적이면 세션에서 발표하는 내용을 내것으로 만들고 실무에서 또는 다른곳에서 활용할수는 없을까 하는 생각을 갖는게 보다 성장하려는 개발자로서의 자세가 아닐까 생각이 든다. (라고 멋드러지게 말하지만 세션내용의 절반이라도 이해하면 다행이겠지…)

행사 시작 그리고 키노트

10초만에 마감되었다는 소리가 있을정도로 올해도 여전히 관심이 많았던 DEVIEW 2018. 코엑스에 도착하고 등록을 한뒤 이곳저곳 부스들을 구경하기 바빴다. 이번에는 지난번과 달리 거의 네이버 서비스가 60~~70%를 자리잡고 있었고(파파고, 지도, 클로바, 글로벌 광고 등등) 일반 기업에서는 얼마 오지 않았다.(내 기억으로 5~~6개?) 개인적으로 여러 다양한 회사들이 함께하는 기술행사가 되었으면 하는 바램이 있었지만 회사를 선정하는데, 그리고 기타 사정들이 있을꺼라는 아쉬움을 뒤로하고 CTO님이 발표하시는 키노트를 들으러 메인강의장에 들어갔다. (자칫… 이것도 네이버 독과점(?) 이러면 할말이 없는데…ㅠㅠ)

송창현 네이버 CTO님의 keynote

작년에는 거의 로봇잔치로 느껴졌는데 올해는 그 기술들의 융합(?)잔치 로 받아들여졌다. Ambient Intelligence 를 강조하시며 기술의 진정한 가치는 기술이 생활속으로 사라졌을 때 나온다라는 명언같은 말씀도 해주셨다.

연결 : 사물, 상황, 위치인식, 이해
발견 : 적시에 답, 추천, 액션제공

그리고 그와 관련된 네이버 서비스를 공개 하셨는데, 네이버 지도 Map API를 무제한/무료로 사용할수 있게 된다고 한다. (박수 유도하심 ㅎㅎ) 또한 이번에 가장 크게 바뀌는 네이버 모바일 홈 페이지인 그린닷, 지도 기술들의 종합 플랫폼인 xDM Platform(측위, 지도, 내비), 그리고 자율주행과 로봇에 대해 연구결과 그리고 앞으로의 방향성에 대해 정리해주셨다. 집에 돌아와서 검색좀 하다보니 테크수다에서 벌써(?) 영상을 하나 올린게 있어 공유해본다.

키노트를 다 듣고 작년에는 그런가보다 하고 별생각이 안들었는데 올해는 저런 기술들이 서비스 레벨까지 가는데 이렇다할 허들없이 사용자들에게 보여질수만 있다면 개발자로서 보다 더 큰 자부심을 가지고 기술개발에 정진할텐데… 하는 씁슬한 생각을 해보게 되었다. (물론 이런 부분들도 다 사정이 있을꺼라 생각이 들지만 안타까운건 감출수가 없을것 같다.)

이틀에 걸쳐 이런저런 다양한 세션들을 들을수 있어 좋았는데 몇몇 세션들은 기본지식이 없어 (AI, 머신러닝 등…ㅠ) 이해하기 힘들었다. 내년엔 이해할수 있도록 준비를 해서 오자며 또다짐을 하고… 그나마 조금이라도 이해할수 있었던 세션들 몇개만 정리해본다.

React Native: 웹 개발자가 한 달 만에 앱 출시하기

지난팀에서 아주 잠깐 React를 경험해보긴 했지만 거의 hello world 수준이였기 때문에 이 세션 역시 이해가 잘 되지 못했다. 하지만 필자처럼 이해를 잘 못하는 사람도 발표자가 전달하려는 목적이 무엇인지 알수 있을 정도로 전체적인 흐름은 조금이나마 이해를 할수 있었고 특히 개발하면서 좋았던 것이나 경험담을 알려주며 삽질공유를 해주는게 듣기 좋았다. React Native 는 빠른개발을 할수있고 코드공유가 쉬우며 개선이 쉽다는 장점이 있다고 한다. 또한 단기간에 크로스 플랫폼을 만들어야 할때 사용한다고 하니 나중에 참고해봐도 좋을듯 싶다.

2018 오픈소스개발자이야기 후기

Sun, 01 Jul 2018 10:00:00 +0000

Facebook그룹들을 눈팅하다(?) OSS개발자 포럼에서 오픈소스 개발자이야기라는 주제로 세미나를 주최한다는 공지를 보게되었다. 언제부턴가 트랜드에 뒤쳐지지 않으려는 몸부림중 세미나같은 외부 개발 행사에 참여해보자는 마음으로 공지를 보자마자 홀린듯이 신청을 하게 되었고 세미나를 듣고 감흥이 가시기 전에 후기를 적고자 한다.(시간이 지나면 잊어버릴것만같은, 보고 들은 생생한 그 무언가를 얻었기에…)

비가오는 주말이였지만 많이 배우고 오자는 설레임을 갖고 서울 광화문 근처에 있는 한국마이크로소프트로 가게되었다. 말로만 듣던 MS사 로고를 보고 사람들이 하나둘씩 모이는걸 보니 뭔가 배울수 있겠구나 하는 기대감이 생겼다. 사실 오픈소스를 사용만 해본 입장이라 실제 오픈소스에 기여하시는 분들은 어떤 생각들을 갖고 계시는지가 가장 궁금했고 개발자인 나도 언젠간 오픈소스에 기여할수있지 않을까 하는 생각을 하며 발표를 들었다.

오픈소스는 아무리 말그대로 Open이지만 오픈소스마다 다양한 저작권을 갖고있고 서로 쟁취하려는 싸움이 많이 발생한다고 한다. 그러다보니 어떠한 프로그램을 만들고 오픈소스화 시킬때도 라이센스의 종류를 잘 결정해야 추후 불이익을 당하는 상황을 모면할수 있다고 한다. 특허와 라이센스는 같은 말이면서도 다른데 아래 표처럼 각 상황에 따라 다른 부분을 확인할수 있었다.

	특허	라이센스
권리발생	출원, 심사, 등록	창작과 동시 발생
권리내용	독점배타적 실시권	인격권/재산권
효력범위	아이디어의 동일성	표현의 실질적 유사성

첫 시간이기도 하였고 아무래도 주제가 끝장토론을 해도 안끝날 주제였던지라 정해진 시간을 넘길정도로 이야기를 많이 해주셨다. 특히 오픈소스 관련된 이야기는 사례를 이야기 해야 재밌다고 하셨는데 시간관계상 몇가지만 말씀해주셨다.

링크가 맞는지는 모르겠으나 첨부해본다.

오픈소스 개발에 대해 단순하게 누구나 수정할수 있는 환경 이라고만 생각을 하고있다가 이런 복잡한 라이센스 문제가 나오니 약간 어려웠지만, 오픈소스의 생태계를 알고 발을 들이기 위해서는 어느정도의 히스토리는 알아야 겠다고 느끼게 되었다.

Elastic 에서 Remote 로 일하기 / 김종민 님

그전부터 Elastic 제품들을 실무에서도 사용해 왔었기에 개인적으로 오늘 발표중에 가장 궁금했었고, 관심이 있던 시간이였다. 발표에 앞서 어떻게 Elastic에 들어가게 되셨고 회사 소개를 간단히 해주셨는데 생각보다 어마어마한 회사다고 느낄수 있었다.(800여명중 한국엔 9명 / 네덜란드 출신 스타트업 인데 본사는 캘리포니아 마운틴뷰에 있고 등등) 원격근무는 편하고 비용이 절약되는 장점이 있으나 동료들간의 유대감형성이 힘들거나 회의시 집중이 힘든 단점도 있다는 점을 말씀해 주셨다. 시간관계상 몇가지 링크들을 소개해주셨는데 나중에 봐볼 생각이다.

원격 툴로는 다음과 같이 사용한다고 한다.

github : 슬랙연동, 개발뿐 아니라 운영/기획/이벤트 공유시 활용
Google Apps
Slack : 봇 활용 (다양한 종류의 봇, 상황마다 특정 알림을 준다.)
salesforce : CRM 툴
zoom : 화상회의 200명 동시콜 가능, 회의가 끝나면 녹음/녹화/스크립팅까지 가능하다고 한다 (wow)
pinboard : 근태/인사 관리용 앱
jira는 사용 잘 안함

나중에 팀 내 Slack 봇으로 여러가지 다양한 자동화를 구성할수 있을것 같다는 생각이 들었다.

오픈소스 생태계 일원으로서의 개발자 / 변정훈 님

사회자분이 “아웃사이더님"이라고 하시길래 설마 했다. 뭐가 잘 안되면 구글링을 하게되는데 내가 자주 보던 블로그를 운영하셨던 분이 내눈앞에 ㄷㄷ… 언제부터 해야지~가 아니고 개발하다보니 어느새 오픈소스에 참여하고 있었다고 한다. 또한 참여하는게 아니고 이미 오픈소스 생태계속에서 살고있는 우리들이라 말씀하시고, 오픈소스 Contribution 방법으로는 사용/홍보/번역/리포팅/문서화/코드제출 등 다양하게 있으니 어렵게 생각하지 말자 라고 하셨다. 오픈소스에서 배울수 있는점은 커뮤니케이션의 방법, 협업의 방법과 중요성, 테스트코드의 중요성, 지속적 통합/지속적 배포, 코드의 품질관리 라고 한다. 점점 발표를 들으면서 오픈소스에 대한 생각이 바뀌고 있는 내 자신을 느낄수 있었다. 너무 어렵게만 생각해 온것 같다는.

Elastic{ON}Tour

Thu, 14 Dec 2017 12:02:45 +0000

작년에 팀을 옮기면서 로깅에 대해서 관심을 갖기 시작 하였고 찾아보다 ElasticStack 이 적합하다고 판단, 팀 내에서 나홀로 삽질해가며 지금의 로그 모니터링 시스템을 구축하였다. 그에 ElasticStack 에 관심을 갖던 찰나 지난 화요일(12월 12일)에 있었던 Elastic On Tour에 참석을 하였고 다양한 기술적 인사이트를 얻을수 있었는데 그 감동(?)을 잃기 싫어 정리해보고자 한다.

Registration + Partner Showcase

코엑스 인터컨티넨탈 호텔에서 진행되었다. 역시 외국계 기업이여서 그런지 행사 규모가 어마어마 했다. 이정표를 따라 지하로 가서 등록을 하고, ElasticStack 을 이용해서 서비스를 하고 있는 파트너사들의 부스를 기웃거리며 ElasticStack의 저력(?)을 다시한번 실감을 할수 있었다. 특히 Elatic 본사에서 나온듯한 외국인들이 Q&A 같은걸 해줬는데 답변을 해주는 외국인도 대단해 보였는데 질문을 하는 한국사람(?)들이 더 대단하게 보였다. 과연 난 저렇게 아무렇지 않고 프로페셔널(?)하게 질문을 할수 있을까?

Registration + Partner Showcase

Track 1 : Partner Sessions

Track 1 과 2로 나뉘였는데 2는 Elastic Stack 을 경험하지 못해봤거나 소개하는 자리같아서 Track 1를 듣기로 하였다. 내가 도입을 할때만 해도 관련 자료가 잘 없었고, 정말 특이 케이스가 아닌 이상엔 잘 사용하지 않겠구나 하는 느낌이였는데 발표하시는 분들을 보고서는 생각이 180도 바뀌었다. 너무 활용들을 잘 하며 서비스를 하고 있었고 단순하게 검색엔진이 아닌 상황에 맞는 커스터 마이징이나 다른 기술 스택을 함께 사용함으로써 시너지 효과를 내고 있었다.

Microsoft
- OpenSource 에 안좋은 이미지가 있으나 오래전부터 투자를 많이 해왔다고 설명을 하며 Azure라는 서비스에서 Elastic Stack 을 어떤식으로 활용하는지 발표를 하였다.
- 상당히 심플하고 처음 접하는 사람도 클릭 몇번으로 ES Cluster를 구성할수 있다는게 장점이였으나, 유료 + 커스터마이징 제한 이 아쉬웠다.
S-Core : 에스코어 경험에 기반한 Elastic 활용법
EZFarm
- (외모 비하는 아니지만)농부 처럼 생기신 분이 나와서 기술에 대해 말씀하시는게 신기한 발표였다.
- 간단히 말하면 돼지가 물 먹는 량 등 농업/축산업의 데이터를 ES에 담고 머신러닝을 통하여 효율화 하는 방안 이였던것 같다.
MEGAZONE
- 파트너 부스에서 티셔츠를 준(?) 곳이였는데 Elastic Cloud Seoul 을 발표하였다. (드디어 한국에도 이런 서비스가!)
OpenBase
- 키바나 플러그인을 직접 개발하고 커스텀 UI의 사례를 보여주었다.
- 키바나 소스중에 엑셀 다운로드가 한글로 안되어 고쳐본것 말곤 플러그인을 개발할 생각은 없었는데 정말 개발자 스러운 발표였다.
DIREA
- 결제 관련 장애추적 및 예측 시스템을 발표하였다.
- 마침 내가 하고있는 서비스와 비슷하고, 내가 구현해보려고 했던 부분과 거의 일맥상통한 부분이 있어서 소름이였다.

Track 1 : Partner Sessions

Opening Keynote

앞서 어떤 발표에서 ElasticSearch가 탄생하게된 계기가 어떤 분이 요리사가 되려는 아내를 위해 조리법을 더 빨리 검색할수 있는 엔진을 만들었다고 하는데 그 어떤분이 내눈앞에 나타나 발표를 하셨다. 현 Elastic CEO 이신 Shay Banon 이였다. (어색한 동시 통역으로 이해하였지만) 그분이 강조하신 Elastic 회사 정신인 “간단한건 간단하게 만들어야 하며 쉬워야 한다.” 가 연설중에 가장 인상적이였고, 통역하신 아주머님(?)때문이였는지 전달하시는 의도를 정확히 파악하긴 어려웠으나 일단 CEO를 포함한 전체 회사 분위기가 젊어보인다는걸 느낄수 있었다.

Shay Banon key note

Break (식사시간)

이런 세미나? 컨퍼런스? 를 많이 다녀본건 아니지만 역대급으로 좋았던 점심식사였다. ;) 사실 혼자와서 밥을 어떻게 해결하나 했는데 우르르르 호텔 직원분들이 각 자리에 도시락을 대령(?)해주셔서 맛있게 먹을수 있었다. 참 사람이 간사한게, 아침에 졸린눈 비벼가며 지옥철 고생을 뚫고 와서 힘들었지만 밥을 먹으면서 아침의 그 고생은 눈녹듯 사라졌다.

호텔 도시락!!

Deep Dive (Elasticsearch, Ingest, Kibana, Machine Learning)

각 스택(?)에 대해서 변화된 부분, 그리고 활용가능성과 최근 출시한 6.X 버전에 대해서 소개하는 시간이였다. 사실 아직 2.4 버전을 운영중이라서인지 6.X의 변화된 부분, 그리고 5.x 버전에서의 차이를 설명해주는데 확 와닿지는 못하였다. 아직 5.x 버전의 필요성을 못느껴서 버전업을 안하고 있었는데 발표를 듣고 꼭 유료 라이센스를 구매하지 않아도 용량 단축이나 안정성, 추가 기능등 5.X로의 버전업은 해서 나쁠것도 없을듯 하다는 생각이 들었다. (단, 무조건 신버전이 좋은것은 아닌듯 잘 알아보고 해야겠지…) 특히 키바나를 활용해 머신러닝을 눈앞에서 보여준건 너무 좋았다. 성능이 좋아서인지 데모시연 하는데 전혀 막힘이 없었으니…

2016 회고

Sat, 31 Dec 2016 16:59:43 +0000

2016년, 내겐 정말 수많은 일들이 있었고 그 어느때보다 (전역 후로) 미친듯이 회사에 집중했던 시간들로 기억난다. 무작정 다가오는 새해를 맞이하는것도 좋지만 올 한해를 되돌아보는 시간을 갖고, 나를 다시 점검해보는 차원에서 일명 ‘회고’를 해볼까 한다.

회사

정말 열심히 했다. 잘했는지는… 잘 모르겠다. 난 잘한것 같다. 물론 내 하루중에 가장많은 시간을 쏟은것도 있지만 작년에 많이 하지 못하던것을 ‘날씨’라는 서비스를 홀로 맡으면서 정말 많은것을 배우고 결과물도 후회하지 않을만큼 나온것 같다. 지나고보면 구지 하지 않아도 월급은 똑같이 나올테고, 시키지도 않았는데 그시간에 잠을 더 잤으면 하는 생각도 들지만 후회하지 않는다. 아무도 없는 사무실 나혼자 12시넘어서 퇴근을 해도 즐거웠으니까, 그거면 됬다. 모바일 개편이라는 큰 업무를 무사히(?) 해쳐내고는 사내에서 조직(서비스)을 변경할수 있는 기회가 되어 나홀로 지원, 다행스럽게도 합격을 해서 지금은 네이버페이 와 관련된 일을 하고있는 중이다. 기존 서비스운영을 하면서 느끼지 못했던, 초기 설계부터 시작하여 어떤 기술스택을 쓸것인가에 대한 선택부터 다양한 시행착오를 통해 이제 한 두달 되었는데 정말 많이 배우고 있다. 너무 힘들지만 너무 행복하다. 돌이켜보면 작심삼일로 개발 관련된 공부를 등한시 한게 너무 후회가 된다. 바쁘다는 이유하나만으로 (솔직히 바쁘다는건 핑계다) 기능구현에만 신경을 써왔는데, 내년부터는 할수만 있다면 업무 외적으로 나만의 개발트리를 세워보고 싶다.

건강

일주일에 한번 이상 오전엔 배드민턴, 저녁엔 헬스장엘 가려고 노력했다. 그 결과였을까, 사랑니 뺀거 말고는 병원을 단한번도 안갔다. 감기조차 걸리지 않는게 다행이라고 생각하지만, 요즘들어(야근이 많아져서인지) 책상에 앉아있는 자세가 불량해서 거북목이 되가고 있다. 폼롤러도 구비했고 어깨 펴지라고 밴드도 구입해서 사용은 하는데 잘 실천이 안되는 중이다. 작년에 자전거를 잃어버리다 되찾고는 자전거를 등한시 하게 되는것 같다. 이또한 핑계겠지. 내년엔 꼭 4대강중 하나 잡고 종주한번 해야겟다. 기필코.. 아맞다 수영도. ㅠㅠ 물에 뜨질 않으니 큰일이다…

사람관계

학교선후배동기 및 동아리 사람들, 군대 동기들 및 소대원들 과 선임 장교분들, 기타 등등… 올해 들어서인지. 연락에 너무 무색할만큼 잊고 살았던것 같다. 지나고보면 다른곳에 신경쓴다고 연락을 못했다고 핑계를 대고 있는 나이지만, 또 한편으로는 그 연락 10분 시간이 없다는건 … 역시나 핑계다. 나를 도와주고 나를 믿어주고 나를 생각해주는 사람들을 조금이라도 더 신경써서 연락하고 찾아 뵙는 시간을 내년부터서라도 가져야겠다.

마치며

일단 첫번째로 내년부터 할일은, 기술 블로그를 운영하는것이다. 솔직히 두달전 이 gitHub 를 이용해서 블로그를 만들긴 했지만 그닥 포스팅도 못했고 방치 수준이였으니… 적어도 한달에 한두개 정도는 포스팅 해보려고 노력해야겟다. 글쓰는게 힘들고 시간이 많이 들어가는 작업이지만, 돌이켜 생각하면 다 내 자산이고 나를 다시 바라볼수 있는 기회니까. 꼭 기술블로그만이 아닌, 하루를 기록하는 무언가를 해야겠다. 막상 한해를 돌이켜보니 그때는 뭐했는지 기억도 안나네.. 두번째로는 지킬수 있는 계획을 잡는것이다. 올 한해 목표중에 이룬건 10개중에 단 두개… (그중에 노래대회나가기, 스쿠버다이빙 하기, 자유형 마스터하기도 있다;;) 부끄럽다..

2016년, 나라도 뒤숭숭 하고 정신없던 한해였지만 나름 의미있던 시간들을 보낸것 같아 다행이라 생각한다. 음,. 10점만점에 8점?? 2017년! 다시한번 일어서자! 화이팅!!

Review on

퇴사 부검 : 네이버를 떠나며

부검 0 : 네이버에 대하여

부검 1 : 왜 떠나는가

6년간의 토이프로젝트 여정을 마무리하며 - 기술블로그 구독서비스 회고록

시작

분위기가 확실히 달랐던 SpringCamp2024

켄트벡의 Tidy First? / 안영회 님

초보 시니어 개발자의 2023 리뷰

회사원으로써의 노력

KAFKA 서비스 활용 스터디 사례 밋업 후기

밋업의 분위기

발표 요약

Kafka MirrorMaker로 카오스 엔지니어링 맛보기 / 황한희 님

고장나기 직전 개발자의 2021 리뷰

여러 가지 작은 도전들

라이프 사이클의 변화

‘중니어 개발자’의 2020 회고

등장, 코로나-19

회사생활

서비스 전면 개편

애자일 아버지의 고함과 호통 (리뷰：Clean Agile - Back to Basics)

갑.분.돈(키호테)

책의 구성

벌써 2년 (feat. 토이프로젝트 회고,가치,수입)

서비스 자체 평가

심플한 기능

서비스에 없어서는 안될 ‘로깅(Logging)’

각종 지표

매니저는 정말 개발자의 무덤일까? (리뷰 - 개발자 7년차, 매니저 1일차)

신입 혹은 주니어 개발자가 읽어봐도 좋을 책.

다 읽고서야 알아차린 번역서(?)라는 사실.

조금은 무거운 2019 회고

회사는 성장의 공간이 아닌것을 깨닳는 순간.

우아한 스프링 배치 테크세미나 정리 및 후기 (by 우아한 형제들)

인트로

기본편

활용편

2019 상반기 리뷰 (feat. 글또)

회사 속에서의 나

외부 활동

내공 연마

D.light 투게더톤 참가후기

팀 빌딩

프로젝트 진행 전반

개발 진행

자바, 성능, 모니터링 테크세미나 정리 및 후기 (by 우아한 형제들)

성능

자바

모니터링

KafkaKRU(Kafka 한국사용자 모임) 밋업 후기

카프카를 활용한 캐시 로그 처리 - 김현준(카카오)

카프카를 활용한 엘라스틱서치 실무프로젝트 소개 - 이은학(메가존)

카프카를 활용한 rabbitMQ 로그처리 - 정원빈 (카카오)

카프카를 마이크로서비스 아키텍쳐에 활용하기 - 이동진 (아파치 소프트웨어 파운데이션)

Write The Docs 서울 밋업 후기 (개발자 강추!)

변성윤(소카) - 글쓰는 개발자 모임, 글또

김대권(당근마켓) - 기술 블로그 생존 전략 : 구글 시대의 글쓰기

홍연의(LINE) - To. 지식 공유를 시작하려는 개발자, From. 당신의 든든한 서포터 Developer Relations팀

2018 회고 - Coder가 아닌 Programmer로

글쓰는 개발자가 되자. 개인 블로그 운영

회사 팀 변경 그리고 토이 프로젝트

엘라스틱서치 12월 서울 밋업 후기

여기어때 본사 방문

엘라스틱서치 6.5 최신버전 소개 및 커뮤니티 회고

엘라스틱서치 활용사례

마치며

Deview 2018 리뷰 (Day 1, Day2)

행사 시작 그리고 키노트

React Native: 웹 개발자가 한 달 만에 앱 출시하기

2018 오픈소스개발자이야기 후기

# 회색지대 : 이상과 현실 - 오픈소스 저작권 / 신정규 님

Elastic 에서 Remote 로 일하기 / 김종민 님

오픈소스 생태계 일원으로서의 개발자 / 변정훈 님

Elastic{ON}Tour

Registration + Partner Showcase

Track 1 : Partner Sessions

Opening Keynote

Break (식사시간)

Deep Dive (Elasticsearch, Ingest, Kibana, Machine Learning)