Archives-2023 on

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

그런 개발자로 괜찮은가 - '환경' 편

Sun, 23 Jul 2023 10:39:22 +0900

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

코딩하는 로봇은 되지 말자.
출처 : https://sdtimes.com/ai/ai-enabled-tools-might-completely-change-development-one-day/

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

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

시간관리

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

가만히 놔도 흘러가는 시간
출처 : https://www.bobaedream.co.kr/view?code=strange&No=1515814/

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

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

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 이 하나 더 발생하는 것이기 때문에 성능에 큰 영향은 없을 것이라고 답변을 받았다. 과연 그럴까? 라는 생각을 잠깐 해보고 팀 내에서 카오스 엔지니어링을 도입하게 되면 개발 환경부터 테스트 해봐야지 하는 생각을 해봤다.