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

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

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

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

토이프로젝트 관련 글

• 개발 후기 1부
• 개발 후기 2부
• 개발 후기 3부
• 벌써 2년

시작

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

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

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

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

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

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

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

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

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

　다양한 방식으로 스터디를 해왔다. 정말 많은 것을 배웠던 스터디도 있는가 반면에 지나고 보면 시간이 아까울 정도의 스터디도 있었던 것 같다. 직접 만들어 보기도 했고 참여도 해봤던 것 같다. 이런저런 경험들 끝에 작년 중순에 직접 만들었던 스터디 멤버와는 어느덧 반년을 넘어가고 있는데 바쁜 회사 생활을 하면서도 이제까지 지속할 수 있었던 노하우를 공유해 보고자 한다.

인원

　다 그런 건 아니지만 기존 회사 분들과 스터디를 할 때면 아무래도 원래 알던 사이라 바빠서 준비를 못 해오거나 불참을 하는 경우에 “그럴 수도 있지”, “괜찮아” 하며 관대해졌던 것 같다. 또는 다양한 의견을 듣자며 10명 이상 진행을 했던 것 같다. 그렇다 보니 스터디 진행에 집중도가 떨어질 수밖에 없었고 모였을 때 이야기하던 사람들만 이야기한다든지, 중도 하차하는 경험도 많았다.

　이번 스터디는 직접 ‘블라인드’라는 익명 커뮤니티를 통해 인원을 모았다. 작년 중순쯤 자바 백엔드 관련된 주제를 스터디 하겠다며 나와 비슷한 연차분들 위주로 모으겠다고 글을 작성했더니 신기하게도 3~40명 되는 분들이나 지원하셨고 그중 오프라인 모임을 고려해서 나 포함 6명 만으로 구성을 하였다.(뭔가 서류 전형 인사담당자가 된 느낌;;) 작은 규모 그리고 새로운 분들과 하게 되니 집중도가 오르는 경험을 할 수 있었고 무엇보다 6명 모두 다른 회사라 각 회사를 대표하는 것 같은 느낌이 들어 스터디 참여에 몰입이나 책임감이 더욱 올랐던 것 같다. 또한 한 주제에 대해 각 회사에서의 경험들을 이야기하다 보니 완전히 다른 시각을 얻을 수 있다는 장점도 있었다.

　별거 아닐 수도 있지만(또는 오해가 될 수도 있지만) 남녀 성비, 그리고 나이대(연차)를 최대한 맞추고 싶었다. 그래야 분위기가 적당히 딱딱하지도, 부드럽지도 않을 것 같았기 때문이다. 지금은 여자 한 분 나머지 남자분들이라 초반에 걱정도 되었지만 생각보다 분위기가 잘 흘러가서 다행이라 생각을 한다.

주제와 목표

　처음부터 모니터 받침으로 하기 좋을만한 두꺼운 책은 피했던 것 같다. 가볍게, 스터디원들끼리의 친밀도부터 올려야 한다는 생각으로 너무 딥 다이브 한 기술적인 내용보다는 누구나 한마디 정도 할 수 있을만한 가벼운 책부터 시작했다. 그러면서 최대한 참여도를 올리는데 집중했던 것 같다.

　어디까지나 “공부"를 하기 위한 모임이긴 하지만 이 또한 사람과 사람 사이의 “관계"가 중요하다고 생각했기에 모였을 때 바로 스터디 이야기를 하는 것보다 부드러운 아이스브레이킹을 자주 해왔다. 또한 너무 루즈 해지지 않게 1달1달 반 정도로 끝날 수 있을만한 주제를 선정했다. 아무래도 한 주제가 23달 걸리다 보면 집중도가 떨어지는 경험이 많았기 때문이다. 책 한 권을 다 읽었다는 기간을 짧게 가져가면서 작은 성취의 효과를 최대한 활용하고 있다. 이번 회차가 벌써 네 번째인걸 보면 그래도 나름 잘 선택한 방법이라 생각이 든다.

　한 회차가 끝날 즈음엔 다음 스터디는 무엇을 할 것인지에 대해 이야기를 하고 다수가 동의하는 주제를 선정한다. 또한 매 회차가 끝날 때마다 어쩌면 어색할 수 있는 이야기지만 스터디 참여를 그만 둘지에 대해 의사를 분명히 물어본다. (그런데 신기하게도 지금 스터디 모임은 이런 이야기를 하기도 전에 스터디 하고 싶은 주제를 먼저 말씀해주시는 편이라, 어쩌면 스스로 사람 운이 좋다는 생각도 해본다.)

　그저 하나의 책을 읽기로 끝나는 “책 읽기 모임” 이 아닌 만큼 책을 기반으로 하는 스터디 모임일지라도 목표를 분명하게 잡는다. 여기서 목표는 개인마다 다를 수 있다. 가령 스터디 시간에 나왔던 내용을 각자의 팀에 공유 및 반영을 해본다든지, 스터디 내용에 대해 주도적으로 이야기를 하며 다른 분들의 지식을 훔쳐보겠다든지(?). 책 읽는 것으로 끝나면 안 되고 가능하다면 해당 내용을 실제로 경험하는 사이클까지 만드는 게 더 중요하지 않을까 생각을 해본다.

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

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

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

회사원으로써의 노력

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

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

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

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

　(필자의 과거 경험을 미루어) 개발자로서 회사에서 일을 하다 보면 가끔 CRUD(Create, Read, Update, Delete) API를 찍어내는 기계(?)가 되는 느낌을 받을 때가 있다. 일정은 촉박한데 사람은 부족하고, 기술 부채가 복리로 늘어나는 게 눈에 훤히 보이지만 개선할 시간이나 여유조차 없어 자신도 모르게 점점 “돌아가게만” 개발하는 상황들. 기술적인 고민을 할 시간은 점점 없어지고, 코드를 설계하는 측면이나 테스트 코드, 책임과 관심 같은 생각들은 하지 못한 채 편의만 추구하며 코드를 작성한다. 그러다 이직을 해야겠다 마음먹고 이력서를 작성할 때나 연말 평가를 위해 한 해 무엇을 했는지 돌아보면 회사일은 불철주야 정말 열심히 했지만 회사를 벗어나 개발자로써 본인 스스로를 위한 건 회사일 대비 아주 극소수에 불과하는 삶이 계속된다.

　개인이 스스로 진행하는 프리랜서나 사업가를 제외하고 선 대부분 회사라는 집단에 소속되어 살아간다. 그러한 회사의 가장 중요한 목표는 돈을 벌기 위한 사업을 하는 것이다. 회사에서는 직원들에게 어느 정도의 처우는 보장해 줄 순 있지만 개개인의 인생을 책임져주진 않는 게 현실이다. 그걸 알면서도 지금 다니고 있는 회사에서 성장을 하지 못한다며 이직을 준비하거나 어쩌면 나를 위한 게 아닌 회사를 위한 일만 해오고 있는 건 아닌가 스스로를 되돌아보게 된다.

　개발자로써 지금의 삶이 너무 행복하고 만족스럽다면 이 글을 읽지 않아도 좋다. (어쩌면 우물 안 개구리로 살아가고 있는 건 아닌지 묻고 싶다. 물론 그 우물마저 따뜻하다면 패스하는 것으로.) 오랜만에 쓰는 이 글에서는 회사라는 의존을 벗어나 스스로 우뚝 설수 있는 ‘환경을 바꾸는 이야기’를 하려 한다. 몸짱이 되기 위해 헬스장을 가고 그것도 모자라 비싼 PT를 끊는다거나, 허리가 좋지 않아 스탠딩 책상으로 바꾸는 것처럼 개발자로 살아가면서 내가 제어할 수 있는 ‘환경’을 바꾸면서 앞서 이야기 한 ‘본인 스스로를 위해 성장하는 시간’을 만들었으면 하는 바람이다.

시간관리

　하루를 시작하면 세상 모든 사람들에게 공평하게 주어지는 게 바로 시간이다. 누구나 24시간을 쓰는데 어떻게 쓰는지는 본인이 선택하기에 달린 문제다. 밤늦게까지 컴퓨터 앞에 앉아 공부를 하고 출근이 늦는답시고 아침 늦게 일어나는 선택, 퇴근하고 집에 오면 피곤해서 아무것도 하기 싫어 TV나 SNS를 하다 잠에 드는 선택, 회사에서 하는 개발은 어느 정도 할 줄 아는 수준까지 되었으니 굳이 다른 개발 공부는 하지 않아도 된다는 선택. 여기서 중요한 건 선택이 다를 뿐이지 잘못된 선택은 없다. 선택에 대해 책임을 질수 있다면 그것으로 OK. 하지만 시간이 부족하다는 핑계를 대고 있다면 시간관리부터 잘 할 필요가 분명히 있다.

　필자는 하고 싶은 게 너무나 많다. 그와 비슷한 양으로 꼭 해야 하는 것도 많다. 그렇기에 매월 1일이 되면 메모장에 한 달의 청사진을 그려본다. 정확하게 그릴 수 있는 것도 있지만 추상적으로 적는 경우도 많다. 그러고는 매주 일요일 저녁이 되면 다음 일주일에 대해 좀 더 자세한 계획을 작성하고, 매일 저녁이 되면 내일의 하루를 미리 정리해 본다. 시간 단위로 작성하는 경우도 있고 계획 중에 우선순위를 점검하며 빠짐없이 시간을 알차게 보내려고 애를 쓰는 연습 중이다.

　MBTI의 맨 마지막 문자가 대문자 J라서 그런지 계획하는 걸 선호하지만 막상 계획대로 시간을 보내다 보면 그래도 시간이 부족한 경우가 많다. 제한된 시간 내에서 최대한 시간을 확보해 보려 여러 가지 노력을 해봤다. 저녁 늦게까지 책상 앞에 앉아서 시간을 확보하기도 해봤지만 늦게 자게 되니 다음날의 체력에 지장을 줄 수밖에 없던 구조였다. 반대로 아침에 일찍 일어나는 건 워낙에 아침잠이 많은 체질이라 너무나도 힘들었지만 시간을 확보할 수 있다는 희망 아래 ‘미라클 모닝’을 시작하게 되었다.

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

　한동안 코로나로 모든 개발자 행사가 온라인으로 진행하는 등 오프라인 행사는 눈을 씻고 찾기란 하늘에 별 따기였다. 오프라인 행사에 참여하면 나름의 개발력(?)을 얻을 수 있었는데 오프라인 행사 자체를 하지 않아 괜히 기운이 빠지던 요 몇 년이었지 않았나 싶다. 그러다 페이스북 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 이 하나 더 발생하는 것이기 때문에 성능에 큰 영향은 없을 것이라고 답변을 받았다. 과연 그럴까? 라는 생각을 잠깐 해보고 팀 내에서 카오스 엔지니어링을 도입하게 되면 개발 환경부터 테스트 해봐야지 하는 생각을 해봤다.