다양한 방식으로 스터디를 해왔다. 정말 많은 것을 배웠던 스터디도 있는가 반면에 지나고 보면 시간이 아까울 정도의 스터디도 있었던 것 같다. 직접 만들어 보기도 했고 참여도 해봤던 것 같다. 이런저런 경험들 끝에 작년 중순에 직접 만들었던 스터디 멤버와는 어느덧 반년을 넘어가고 있는데 바쁜 회사 생활을 하면서도 이제까지 지속할 수 있었던 노하우를 공유해 보고자 한다. 인원 　다 그런 건 아니지만 기존 회사 분들과 스터디를 할 때면 아무래도 원래 알던 사이라 바빠서 준비를 못 해오거나 불참을 하는 경우에 “그럴 수도 있지”, “괜찮아” 하며 관대해졌던 것 같다. 또는 다양한 의견을 듣자며 10명 이상 진행을 했던 것 같다. 그렇다 보니 스터디 진행에 집중도가 떨어질 수밖에 없었고 모였을 때 이야기하던 사람들만 이야기한다든지, 중도 하차하는 경험도 많았다. 블라인드 글에 첨부한 스터디 참여 설문" 블라인드 글에 첨부한 스터디 참여 설문 　이번 스터디는 직접 ‘블라인드’라는 익명 커뮤니티를 통해 인원을 모았다. 작년 중순쯤 자바 백엔드 관련된 주제를 스터디 하겠다며 나와 비슷한 연차분들 위주로 모으겠다고 글을 작성했더니 신기하게도 3~40명 되는 분들이나 지원하셨고 그중 오프라인 모임을 고려해서 나 포함 6명 만으로 구성을 하였다.(뭔가 서류 전형 인사담당자가 된 느낌;;) 작은 규모 그리고 새로운 분들과 하게 되니 집중도가 오르는 경험을 할 수 있었고 무엇보다 6명 모두 다른 회사라 각 회사를 대표하는 것 같은 느낌이 들어 스터디 참여에 몰입이나 책임감이 더욱 올랐던 것 같다. 또한 한 주제에 대해 각 회사에서의 경험들을 이야기하다 보니 완전히 다른 시각을 얻을 수 있다는 장점도 있었다. 　별거 아닐 수도 있지만(또는 오해가 될 수도 있지만) 남녀 성비, 그리고 나이대(연차)를 최대한 맞추고 싶었다. 그래야 분위기가 적당히 딱딱하지도, 부드럽지도 않을 것 같았기 때문이다. 지금은 여자 한 분 나머지 남자분들이라 초반에 걱정도 되었지만 생각보다 분위기가 잘 흘러가서 다행이라 생각을 한다. 주제와 목표 배워야 할게 한도 끝도 없는 개발자 세상스터디 목표에 따라 집중해야 할 범위를 좁히자!" 배워야 할게 한도 끝도 없는 개발자 세상 스터디 목표에 따라 집중해야 할 범위를 좁히자! 　처음부터 모니터 받침으로 하기 좋을만한 두꺼운 책은 피했던 것 같다. 가볍게, 스터디원들끼리의 친밀도부터 올려야 한다는 생각으로 너무 딥 다이브 한 기술적인 내용보다는 누구나 한마디 정도 할 수 있을만한 가벼운 책부터 시작했다. 그러면서 최대한 참여도를 올리는데 집중했던 것 같다. 　어디까지나 “공부"를 하기 위한 모임이긴 하지만 이 또한 사람과 사람 사이의 “관계"가 중요하다고 생각했기에 모였을 때 바로 스터디 이야기를 하는 것보다 부드러운 아이스브레이킹을 자주 해왔다. 또한 너무 루즈 해지지 않게 1달~1달 반 정도로 끝날 수 있을만한 주제를 선정했다. 아무래도 한 주제가 2~3달 걸리다 보면 집중도가 떨어지는 경험이 많았기 때문이다. 책 한 권을 다 읽었다는 기간을 짧게 가져가면서 작은 성취의 효과를 최대한 활용하고 있다. 이번 회차가 벌써 네 번째인걸 보면 그래도 나름 잘 선택한 방법이라 생각이 든다. 　한 회차가 끝날 즈음엔 다음 스터디는 무엇을 할 것인지에 대해 이야기를 하고 다수가 동의하는 주제를 선정한다. 또한 매 회차가 끝날 때마다 어쩌면 어색할 수 있는 이야기지만 스터디 참여를 그만 둘지에 대해 의사를 분명히 물어본다. (그런데 신기하게도 지금 스터디 모임은 이런 이야기를 하기도 전에 스터디 하고 싶은 주제를 먼저 말씀해주시는 편이라, 어쩌면 스스로 사람 운이 좋다는 생각도 해본다.) 　그저 하나의 책을 읽기로 끝나는 “책 읽기 모임” 이 아닌 만큼 책을 기반으로 하는 스터디 모임일지라도 목표를 분명하게 잡는다. 여기서 목표는 개인마다 다를 수 있다. 가령 스터디 시간에 나왔던 내용을 각자의 팀에 공유 및 반영을 해본다든지, 스터디 내용에 대해 주도적으로 이야기를 하며 다른 분들의 지식을 훔쳐보겠다든지(?

언제부터인가 새해가 되면 그 해의 키워드를 선정하고 해시태그처럼 달고 다니며 한 해를 보내온 것 같다. 작년의 키워드는 “한계”. 한정된 시간 속에서 하고 싶은 것도 많고 해야 할 것도 많은 나로서는 중요도에 따라 어쩔 수 없이 무언가를 포기하게 되는 순간들이 찾아왔다. 그럴 때마다 늘 어쩔 수 없다는 자기 가면을 쓴 채 정말 하고 싶던, 꼭 해야 할 것들임에도 불구하고 다음에 해야지 하고 넘어갔던 적이 많았다. 　그렇게 시간을 보내니 아쉬움이 남게 되었고 잠을 줄여서라도 할 것 들을 하자며 나를 극한으로 몰아붙여보자는 의미로 작년의 키워드를 “한계"라고 정했고 정말 많은 것들을 경험할 수 있었다. 그렇게 나를 몰아붙이는 삶을 살다 보니 말 그대로 그저 “여러 가지만 했던” 한 해로 기억된다. (아마 그래서 작년 리뷰가 없던 이유일지도…?) 　작년의 “한계"라는 키워드를 통해 잠은 죽어서 자야지 하는 마음으로 불타는 열정을 연습했다면 올해는 같은 시간을 쓰더라도 제대로 쓰고 싶은 마음에 많은 것들을 배우자는 의미로 “배움"이라는 키워드를 선정하게 되었다. 개발자로 살아온 지 올해로 11년 차가 되는 해 이기도 하고 이제는 “시니어 개발자"라는 수식어가 붙다 보니 더욱 시간을 허투루 보낼 수가 없다는 생각이 들었다. 그렇게 “배움"이라는 키워드를 가지고 한 해를 지나와보니 정말 많은 것들을 경험 그 이상으로 배울 수 있었고 그에 대한 한 해의 리뷰를 해보고자 한다. 회사원으로써의 노력 　부여받은 일은 기본이고 그 이상을 스스로 찾아서 해야 하며, 구성원 모두가 함께 성장할 수 있는 분위기를 이끌어 나가야 하는 일당백 ‘시니어 개발자’로써 회사 생활을 해왔던 것 같다. (쓰고 보니 이력서에서나 볼법한 문장이지만;;) 특히 후배 개발자분들이 잘 성장할 수 있는 환경을 조성하고 그러한 과정들이 결국 서비스가 나아가고자 하는 방향에 보탬이 될 수 있도록 서포트 하는 것에 집중을 해왔다. 　가끔은 팀 내에 쌈닭(?)이 되어 돌아만 가게 하던 일을 개발자로써 확장성과 유지 보수성을 위해 개선해 보자는 자세를 취해 보기도 했고 함께 일하는 주니어 분들께 하기 싫었지만 (그 시절 나를 보는 것만 같았던) 좀 더 올바른 개발자로서의 성장을 하는 바람으로 쓴소리를 몇 번 건넨 것 같다. 지나고 보면 좋은 게 좋다는 식으로 넘어가도 될법했나 싶지만 우리는 그저 코딩만 하는 기계가 아니기에. 누군가는 이런 생각과 말을 해야 하지 않을까 하는 이상한 책임감의 모자를 써보기도 했었다. IDC장애 대비 Jenkins 이중화 구성Active IDC 장애시 Standby IDC 에서 Jenkins 운용이 가능하다." IDC장애 대비 Jenkins 이중화 구성 Active IDC 장애시 Standby IDC 에서 Jenkins 운용이 가능하다. 사내 기술공유 행사 발표" 사내 기술공유 행사 발표 　기술적 기억으로는 젠킨스 IDC 이중화를 위해(master-slave가 아닌) 스스로 꽤 장기간에 걸친 시행착오를 통해 젠킨스 클러스터를 IDC간 이중화 구성하기도 하였고 인원 대비 업무량이 많다 보니 늘어만 가는 기술 부채를 개선하고자 자체적으로 ‘기술/프로세스 개선 TF’를 구성해서 개발팀에서 챙겨야 할 부분들을 놓치지 않기 위한 장치들을 만들었다. 여러 output 중에 하나로 팀 내 주니어 분과 함께 하반기 사내 기술 공유 행사에서 “그런 배포 프로세스로 괜찮은가(feat. Github Action)“라는 제목으로 배포 자동화 사례를 사내 오픈소스화(Github Action Marketplace) 하여 발표하기도 하였다. 나름 열정스러운 모임 이름" 나름 열정스러운 모임 이름 　사내 독서모임에서 모임장을 자처하여 인문학 독서 소모임을 만들고 10여명 정도의 사람들과 함께 진행을 해보기도 하였고, 같은 서비스를 만들고 있는 다양한 사람들끼리 한 달에 한 번씩 모여 식사 자리를 가졌던 미식회 모임을 운영해 보기도 하였다. 개발과는 관련이 없을 수도 있지만 여러 모임을 운영해 보면서 “관계” 그리고 “조직 운영"에 대한 부분을 간접적으로나마 느껴볼 수 있었던 것 좋은 경험으로 기억될 것 같다.

(필자의 과거 경험을 미루어) 개발자로서 회사에서 일을 하다 보면 가끔 CRUD(Create, Read, Update, Delete) API를 찍어내는 기계(?)가 되는 느낌을 받을 때가 있다. 일정은 촉박한데 사람은 부족하고, 기술 부채가 복리로 늘어나는 게 눈에 훤히 보이지만 개선할 시간이나 여유조차 없어 자신도 모르게 점점 “돌아가게만” 개발하는 상황들. 기술적인 고민을 할 시간은 점점 없어지고, 코드를 설계하는 측면이나 테스트 코드, 책임과 관심 같은 생각들은 하지 못한 채 편의만 추구하며 코드를 작성한다. 그러다 이직을 해야겠다 마음먹고 이력서를 작성할 때나 연말 평가를 위해 한 해 무엇을 했는지 돌아보면 회사일은 불철주야 정말 열심히 했지만 회사를 벗어나 개발자로써 본인 스스로를 위한 건 회사일 대비 아주 극소수에 불과하는 삶이 계속된다. 코딩하는 로봇은 되지 말자.출처 : https://sdtimes.com/ai/ai-enabled-tools-might-completely-change-development-one-day/" 코딩하는 로봇은 되지 말자. 출처 : 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/" 가만히 놔도 흘러가는 시간 출처 : https://www.bobaedream.co.kr/view?code=strange&No=1515814/ 　필자는 하고 싶은 게 너무나 많다. 그와 비슷한 양으로 꼭 해야 하는 것도 많다. 그렇기에 매월 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 컨테이너 환경에서 제공되는 카오스 엔지니어링 도구 영화 라이온킹에 등장하는 멧돼지인 품바의 멍청하고 산만하다는 특징에서 영감을 받음 비교적 단순한 테스팅을 할 때 유용한 도구 카오스 엔지니어링 파이프라인 안정화 정의 : 기술적인 이슈나 아닌 비즈니스 관점의 지표를 안정된 상태의 지표로 설정 이벤트 선정 : 발생 가능성이 있는 이벤트 선정 실행 : 카오스 엔지니어링 수행 , 실제로 이벤트를 발생시켜보고 가설을 시험 분석 　이번에도 어김없이 질문을 했다.

미래의 시간을 계획하는 것도 중요하지만 과거의 시간을 돌아보고 더하거나 빼는 시간이 더 중요하다고 느끼는 시간인 ‘회고’. 올해도 어김없이 필자의 2021년을 돌아보며 회고 글을 쓰려 했지만 이런저런 일들로 한 해를 넘기고야 만다. 연말이 지나고 새해가 시작되었지만 무슨 일이 있어도 매년 회고는 꼭 하자는 나와의 약속을 지키려 2021년을 되돌아보고 크나큰 이벤트들의 연속이 될 것만 같은 2022년을 위해 더할 건 더하고 뺄 건 빼는 리뷰를 해보고자 한다. 여러 가지 작은 도전들 　재택근무가 장기화되면서 시간을 좀 더 알차게 사용할 수 있었고, 그에 생각하지도 못한 다양한 경험들을 할 수 있게 되었다. 먼저 찾아보기도 하거나 필자의 블로그나 다른 경로를 통해 오히려 연락이 왔던 ‘멘토링’은 많은 것을 생각하게 해주는 경험이 되었다. BE, FE, 머신러닝, DevOps 등 분야를 막론하고 이제 막 개발자로써 취업전선에 뛰어드려 하는 예비 개발자부터 한참 개발을 시작하고 있는 이른바 주니어 개발자까지 다양한 분들을 zoom이나 gather-town 같은 온라인 플랫폼에서 만나게 되었고, 그들의 고민을 함께 이해하려 노력하며 선배 개발자로써 조금이나마 도움이 되는 부분들에 대해 이야기해주는 활동들을 해왔다. 10년후에 만나요 :D" 10년후에 만나요 :D 　물론 필자를 완벽하게 잘 성장한 (또는 본보기의 대상이 될만한) 개발자라고 말하기는 매우 어렵지만 그들보다는 다양한 경험들을 먼저 해본 선배 입장에서 노하우나 방향성에 대해 이해하기 쉽게 최대한 풀어 설명하려 했다. 이러한 점을 누구는 대수롭지 않게 여긴 적도 있지만 누군가는 XX 기업에 취업을 했다거나 며칠간 복잡하고 힘들었던 고민이 해결이 되었다는 소리를 들었을 땐 아, 멘토링 하길 잘했다는 생각이 들게 되었고 더불어 이제는 점점 누군가와 함께 공동의 목표를 이루기 위한 위치에서 있다 보니 이런 점을 연습할 수 있는 기회가 된 것 같아 너무 좋았다. 무엇보다 멘토링을 하면서 필자도 대충 알고 있던 개발 지식에 대해 (제대로 알려주기 위해) 공부하게 되는 기회가 되었고 이런저런 상담을 하며 느낀 그들의 열정을 조금이나마 간접경험하며 얼마 전부터 잃어버린 내 열정도 찾으려는 동기부여도 되기도 하였다. 　코로나가 장기화되고 개발자로써 할 수 있는 건 없을까 하며 Elastic Stack 을 활용하여 코로나19 대시보드 만들기라는 포스팅을 올리게 되었고 그에 힘입어 나만의 데이터 분석 플랫폼 엘라스틱서치라는 책에 베타 리딩을 하기도 하였다. 작년부터 책을 써보는 건 어떻겠냐는 요청이 아주 가끔 들어오지만 베타 리딩을 하면서 책을 출간하는 게 얼마나 어려운 건지 다시 한번 깨닫게 되었고 기회가 된다면 내 이름으로 된 책을 써보고 싶은 생각도 들었다. 　공모주 청약을 가끔 하면서 누군가 알려주면 좋을 텐데 하는 생각으로 공모주 알리미 라는 토이 프로젝트를 만들었다. 기술 블로그 구독 서비스를 운영하고 있는 AWS ec2 서버에 메모리가 조금 남아 배치 형식으로 만들어서 텔레그램으로 정보를 알려주는 서비스인데 생각보다 수요가 많아서 깜짝 놀랐다. 보다 대중적인(?) 메신저인 카카오톡으로 운영하고 싶었지만 메시지를 보낼 때마다 비용이 발생해서 (아무리 토이 프로젝트라 해도…) 차마 엄두가 나질 않아 카카오톡 채널만 만들고 텔레그램 링크를 연결해두었다. 지금은 아예 손도 안대는 서비스이지만 잘 돌아가고 있는 걸 보면 자동화의 힘은 정말 대단하다는 걸 다시금 느껴본다. 카카오채널 가입자에게 메세지를 보낼 수 있음 좋을텐데…" 카카오채널 가입자에게 메세지를 보낼 수 있음 좋을텐데… 라이프 사이클의 변화 　문득 이렇게 재미있는 개발을 언제까지 할 수 있을까 하는 생각을 하게 된 적이 있다. 개발을 오랫동안 할 수 있는 방법이 무엇이 있을까 하는 생각의 끝에는 결국 “든든한 자산"과 “생각의 패러다임 전환”, 그리고 “건강"이라는 결론에 도달하게 되었다. 개발 업무 기기를 산다거나 신기술 학습을 위해 투자하기 위해서는 결국 돈이 필요하다고 느껴졌고, 공대생의 고립된(?) 가치관에서 다양한 인문학적인 관점들이 가미된다면 개발에도 훨씬 도움이 될 거라 생각이 들었다.

몇 달 전부터 좋은 기회가 생겨 이제 막 개발자의 길로 들어서는 분들과 다양한 색깔들로 이야기를 나누고 있다. 과거 필자가 막 취업을 했을 때의 온도와는 확연하게 다르지만 확실하게 이야기할 수 있는 건, 이미 개발자라는 직업으로 10년 가까이 지내보니 무엇이 중요하고 어떤 것들은 자신을 갉아먹는 존재라는 게 뻔히 보인다는 점이다. 하지만 그 어느 누구도 처음 시작점에서는 당연히 힘들어할 수밖에 없는데 그 과정을 무작정 싫어만 한다거나 그 힘듦을 못 견디고 포기 또는 잘못된 선택(일단 어디라도 붙으면 무조건 가자는 식의)을 하게 되는 점이 너무 안타깝다. 만약 어떠한 ‘공식’처럼 중요한 것만 바라보고 필요 없는 것들은 하지 않는 식으로 하면 개발자라는 직업을 갖는 직장인의 삶은 과연 행복할까? 아니 그게 가능하긴 할까? 　이런저런 과정을 거쳐서 취업에 성공했다고 가정해 보자. 과연 우리가 꿈꾸던 아름답고 멋진 개발자 라이프가 보장이 될까? (물론 사람마다 회사마다 다르지만) 야근은 밥 먹기 일쑤고 모르는 거 투성에 매번 실수하거나 혼나고 좌절의 연속. 드디어 취업했다!라는 외침이 온 데 간 데 사라지고 스트레스가 반복되어 결국 퇴사를 생각하거나 정신 차려보니 나도 모르게 CRUD (create, read, update, delete) 찍어내는 기계가 되어버리곤 한다. 무엇이 문제일까? 이런 생활을 기대하고 취업한 건 아닐 텐데 말이다. 개발자 전성시대, 이대로 좋은가출처 : https://news.nate.com/view/20210226n37680" 개발자 전성시대, 이대로 좋은가 출처 : https://news.nate.com/view/20210226n37680 　이번 포스팅에서는 이제 막 ‘개발자’라는 직업을 가지려는 분들이나 직장인으로서 시작은 했는데 어떠한 이유로 지친다거나 매너리즘에 빠진 분들께 조금이나마 도움이 될까 하여 필자의 생각을 정리해 보고자 한다. 왜 본인이 수많은 직업 중에 하필 ‘개발자’를 선택했는지, 그리고 취업을 하고자 할 때 생각해 봐야 할 몇 가지들에 대해 이야기해보자. 왜 하필 ‘개발자’인가 　한국 고용정보원이 2020년 발간한 「한국 직업사전 통합본 제5판」에 따르면 2019년 12월 기준으로 우리나라 직업의 종류는 16,891개라고 한다. 산업이 발달됨에 따라 다양한 직업들이 생겨나기에 지금은 훨씬 더 많을 것으로 예상된다. 그런데, 이 수많은 직업들 중에 왜 하필 우리는 ‘개발자’라는 직업을 선택하려는 걸까? 관련 전공을 나와서? 요즘 인기 있는 직업이라서? 한 번쯤은 아니, 꼭 이런 생각을 며칠에서 몇 달 동안 깊게 고민해 봤으면 좋겠다. 왜 나는 개발자로써 살아가려 하는 것인지에 대해서 말이다. 　이력서 혹은 자기소개서에 ‘입사 포부’라는 문항이 자주 나타난다. 그곳에는 본인이 개발자가 되어야만 하는 이유에 대해 다양한 미사여구를 붙여가며 작성하기 마련인데 그렇게 ‘보여주기식’내용 말고 정말 내가 개발이 ‘재밌는지에’ 대해 반문을 해보는 과정이 필요하다. 개발을 하는 과정 속에서 나는 어느 상황에서 재미를 느끼는지. 새로운 기술을 배울 때, 몇 날 며칠 동안 삽질을 하다 해결을 했을 때, 내가 개발한 애플리케이션을 누군가 사용할 때 등등. 찾아보면 다양한 시점에서 우리는 개발을 하며 재미를 느낄 때가 있다. 　눈치를 챘을 수도 있지만 필자가 말하고 싶은 건, 개발자라는 직업을 선택하려면 개발이 재미있어야 된다는 말이다. 반문을 해보자. 그럼 만약에 개발이 재미없다면 어떨까? 개발자로써 살아갈 수 없는 것일까? 일반화하긴 싫지만 개발이 재미가 없으면 개발자로써 살아가기에 너무 힘들 것 같다. 검정 화면에 영어로 된 글자들을 만져가며 홀로 고독하게 자신과의 싸움을 하는 시간들의 연속일 텐데 재미라도 있지 않다면, 더군다나 그게 하루의 절반 이상을 할애하는 ‘직업’이라면 오래 유지하는데 힘들지 않을까? 그래도 오늘이 몇일인지는 알고 하자.출처 : https://bbs.ruliweb.com/community/board/300143/read/49006211" 그래도 오늘이 몇일인지는 알고 하자. 출처 : https://bbs.ruliweb.com/community/board/300143/read/49006211 　당장 개발이 재미없어도 좋다. 태어날 때부터 개발이 재밌어서 돌잡이 때 기계식 키보드를 잡는 사람은 없듯 누구나 약간의 호기심에서 개발을 시작하기 마련인데 여기서 중요한 점은 개발의 재미를 본인만의 호흡으로 찾는 습관을 들여야 한다는 것이다. 예컨대, 필자는 회사에서 이런저런 이유로 개발이 재미 없어지거나 쳐다도 보기 싫을 상황이 생기면 무언가를 만들어 보거나(=토이 프로젝트) 모르는 부분이 생겼다면 깊게 파고 들어 어떻게든 해결하려고 노력하는 과정을 어딘가에 정리하며(=기술 블로그) 무너지지 않으려 개발의 재미를 유지하려 애써온 것 같다.

공모주 알리미라는 토이 프로젝트 개발기의 마지막 포스팅이다. 토이 프로젝트를 왜 시작하게 되었고 어떻게 설계하게 되었으며 데이터는 어떤 식으로 수집하고 그 데이터를 어떤 방법으로 사용자들에게 알림을 보내기까지 알아보았다. 이제는 이러한 일련의 ‘파이프라인’을 자동화해야 할 시간이다. 사람이 직접 수동으로 로컬 컴퓨터에서 위 파이프라인을 실행하는 것이 아니라 별도의 서버에 해당 애플리케이션이 등록되어 있고 이를 어떤 무언가에 의해 트리거링을 해주는 방식으로 말이다. 1부 : 프로젝트 설계, 데이터 수집 2부 : 수집한 데이터 알림 발송 3부 : 서버 선정 및 릴리즈 서버 선정 　1부에서 이야기했던 것처럼 heroku라는 PaaS(Platform as a service)를 사용하면 될 것 같았다. 무료 플랜으로도 설계했던 서비스 내용을 모두 소화 가능했기 때문이다. 앞서 만든 Spring Boot Application 을 heroku에 배포를 해보자. 　heroku에서 새로운 ‘App’을 생성한다. 아래에서 보여주고 있는 화면대로 App name을 지정하고 만들기만 하면 끝. 그러면 배포 방법이 여러 가지가 나오는데 heroku에서 제공하는 CLI를 사용하는 방법, 그리고 Github 과 연동하거나, 컨테이너 레지스트리를 활용하는 방법 총 3가지가 있다. 여기서 필자는 Github을 활용해서 연동하는 방법을 소개해 보고자 한다. heroku 에서 app을 생성하자." heroku 에서 app을 생성하자. 　로컬에서 만든 애플리케이션을 Github에 push 하면 Github Repository 가 생기고 작업 파일들이 정상적으로 업로드된 것을 확인할 수 있다. 그다음 heroku에서 만들었던 App 페이지에서 Deploy 탭을 클릭하면 아래와 같이 3가지 방법으로 Deploy를 할 수 있다고 나오고, 이 중에 “Connect to Github"을 선택하면 Github 과 연동할 수 있는 버튼이 생기고 이를 누르면 자동으로 본인의 Github 내 Repository를 등록할 수 있도록 화면이 바뀐다. heroku 와 github 연동" heroku 와 github 연동 　그다음 위에서 Github에 push 했던 Repository 이름을 적고 검색하면 조회가 되고 ‘Connect’를 누르면 자동으로 연결이 된 것을 확인할 수 있다. 연동된 Repository 브랜치에 코드가 푸시 되면 자동으로 heroku에 배포가 되도록 자동화 설정도 가능하고 그 아래에 보면 브랜치를 선택해서 배포를 수동으로 할 수 있기도 하다. 수동으로 푸시를 눌러보면 이런저런 빌드 로그가 나오고 최종적으로 배포가 되어 {Appname}.herokuapp.com 을 접속해보면 서버에 배포가 되어있는 것을 확인할 수 있다. sample Github Code : taetaetae@heroku#HelloWorldController.java#L11 sample heroku app : https://taetaetae-test.herokuapp.com/ 수동으로 배포를 해보자." 수동으로 배포를 해보자. 　heroku에서는 이렇게 몇 번의 클릭만으로 간단하게 애플리케이션을 배포할 수 있는 기능을 제공하고 있고 서버 내 로그도 아래 화면처럼 보여주고 있기 때문에 쉽고 간단하게 서버를 구성하고 싶은 사용자들에게 매력적으로 보이는 것 같다. 단, 무료 플랜의 제한사항들을 자세히 살펴보고 사용할 것을 추천한다. 서버 로그도 볼 수 있다!" 서버 로그도 볼 수 있다! 호출 테스트, 문제의 시작 　앞서 만들었던 텔레그램 채널에는 아무도 가입을 하지 않았기에 배포한 heroku web endpoint를 호출하면 텔레그램 봇을 통해 알림이 오는 걸 테스트하고 싶었다. 그런데 아무리 호출을 해도 서버는 타임아웃이라는 에러 응답을 뱉기 일쑤였고, 로직이 문제인지 한참을 리팩토링하며 원인을 파악하는데 꽤 오랜 시간을 삽질하였다. 왜 타임아웃이 발생할까? heroku는 web에서 바로 실행할 수 있는 console 페이지를 제공하고 있었다. 그래서 ‘크롤링을 하기 위한 페이지’와 ‘구글’을 비교하기 위해 단순하게 curl 해서 가져오는 테스트를 해보니 아래처럼 확연히 결과가 달랐다. 결국은 heroku 와 크롤링 하는 서버 간의 네트워크 타임아웃이 문제였던 것. 오류가 나고 원인을 찾는 과정이 가장 어려운 것 같다. 어플리케이션의 문제가 아닌 네트워크 자체의 문제" 오류가 나고 원인을 찾는 과정이 가장 어려운 것 같다. 어플리케이션의 문제가 아닌 네트워크 자체의 문제 그래서 어떻게 해결 했나? 　heroku에서 타임아웃이 발생하는 문제를 해결하려 여러 구글링을 통해 찾아봤지만 방법을 찾을 수 없어서 결국 heroku를 사용하는 것을 포기하고 다른 방법을 찾아봐야만 했다.

혹시 이 포스트를 처음 읽는 독자라면 지난 포스팅을 읽고 오는 것을 추천한다. 정리하자면, 지난 포스트에서는 토이 프로젝트를 시작하게 된 계기와, 어떤 식으로 만들지에 대한 설계. 그리고 데이터를 수집하는 과정에 대해 이야기했었다. 지난 포스팅에서 수집한 데이터를 이제 사용자들에게 알려주는 부분에 대해 정리하고자 한다. 1부 : 프로젝트 설계, 데이터 수집 2부 : 수집한 데이터 알림 발송 3부 : 서버 선정 및 릴리즈 데이터 정의 　java 라이브러리 중에 jsoup라는 것을 사용하여 웹사이트를 크롤링 하였고, 필요한 데이터를 파싱을 하였다. 아래는 ‘공모주’라는 자바 모델을 정의해 보았다. 이렇게 자바 ‘모델’로 정의를 하는 이유는 필요한 데이터가 무엇인지 다시 한번 정리를 하기 위함이기도 하고 map 같은 형태의 임시 변수(?)보다 더 직관적이기에 이후 코드를 작성하는데 가이드 역할의 효과도 얻을 수 있을 것 같았기 때문이다. public class PublicOffering { private String name; // 종목명 private LocalDate startDate; // 일정 시작일 private LocalDate endDate; // 일정 마감일 private LocalDate listingDate; // 상장일 private String publicOfferingPrice; // 확정 공모가 private String expectedOfferingPrice; // 희망 공모가 private List<String> Underwriter; // 주간사 private String detailUrl; // 상세URL private String competitionRate; // 청약경쟁률 } 　초기에는 위에서 정의한 모델처럼 공모주의 기본 정보만을 서비스해야겠다 생각했고, 관련 뉴스라든지 기타 추가적인 정보나 다른 분들의 요구 사항(?)들이 추가될 경우 점진적으로 설계를 하고서 확장시켜 나가는 방향으로 계획했다. 우선은 기능들이 부족하더라고 돌아가는 서비스를 만들고 싶었기에. 애자일 방법론! 출처 : https://m.blog.naver.com/keycosmos3/221267522930" 애자일 방법론! 출처 : https://m.blog.naver.com/keycosmos3/221267522930 텔레그램 봇/채널 생성 　텔레그램 봇을 만드는 과정은 가볍게 검색을 해보면 너무나 쉽게 찾을 수 있지만, 보다 하나의 글 안에 모든 내용을 담고 싶어 텔레그램 봇을 만들고 → 텔레그램 채널을 만든 다음 → 텔레그램 봇을 이용해서 텔레그램 채널에 메시지를 보내는 걸 이야기해 보고자 한다. 아, 여기서 왜 꼭 ‘텔레그램’을 선택했는가에 대한 이유는 개인적으로 다른 메신저 (카카오톡, 라인 등)보다도 api를 활용하여 메시지를 보내는 과정이 단순하면서도 빠르고 쉽게 느껴졌기 때문이다. 혹시 텔레그램 이 아닌 다른 메신저로 보내달라는 요청이 있을 경우 그때 가서 고민해 보려 한다. 텔레그램 봇 생성 　먼저 텔레그램 메신저에서 ‘BotFather’라는 사용자를 찾고 ‘/start’를 누르면 아래와 같이 사용할 수 있는 명령어가 나온다. 　그다음 우리는 봇을 만들 것이기 때문에 ‘/newbot’을 누르고 봇의 이름을 작성하고 그 봇의 사용자 이름을 지정한다. ‘_bot’으로 끝나야 한다고 하기에 이름 뒤에 붙여서 만들면 그걸로 끝. 다음으로 친절하게 HTTP API를 사용할 수 있는 토큰이 발급되는데 이 토큰으로 봇을 컨트롤 가능하기 때문에 잘 간직하고(?) 있어야 한다. 친절한 봇 아버지" 친절한 봇 아버지 　이후 해당 토큰을 이용해서 봇의 상태를 확인해보자. 아래의 url에 토큰 경로만 변경하여 입력하면 json 응답을 받을 수 있다. https://api.telegram.org/bot{token}/getUpdates e.g. https://api.telegram.org/bot17...42:AAH...cQU/getUpdates 텔레그램 채널 생성 　1:N으로 채널에 가입한 사람들에게 메시지를 일방적으로 보내야 하기 때문에 사용할 채널을 만들어 보자. 텔레그램 UI만 봐도 간단하게 생성하기 쉽게 되어있다. 더불어 이 채널에 메시지를 보내야 하기 때문에 위에서 만들었던 봇을 추가하고 관리자로 승격 시키자. 채널 생성 > 봇을 관리자로" 채널 생성 > 봇을 관리자로 텔레그램 봇으로 텔레그램 채널에 메시지 보내기 　이 부분에서 약간 헤맸는데 결국 위에서 얻은 토큰과 채널의 특정 id를 알아야 메시지를 보낼 수 있다. 앞서 만들었던 채널에 아무 메시지나 작성을 하고 위에서 호출했던 ‘getUpdates’ api를 다시 호출해보면 아래처럼 채널의 id를 구할 수 있게 된다.

작년부터 시작된 ‘동학 개미 운동’에 언제부터인가 필자도 주린이로써 동참을 하게 되었다. 최근에는 ‘공모주 청약’이라는 걸 알게 되었는데 따라 해보고 정신 차려보니 치킨 한 마리 정도의 수익을 얻는 기적이 일어났다. 공모주란 정해진 일자에 청약을 하고 배정을 받으면 해당 주식이 상장을 하기 전에 미리 살 수 있다는 ‘기회’로 이해했다. (주린이라 이해의 범위가 여기까지다…) 공모주 배정이 로또처럼 엄청난 큰 수익률을 가져다주는 건 아니지만 앞서 이야기 한 것처럼 언제 있을지 모르는 공모주 청약을 꼬박꼬박 챙겨서 하게 된다면 맛있는 치킨을 먹을 수 있겠다는 기대감이 부풀었다. (치킨은 역시 교촌 허니콤보…) 주린이는 계속 자야 할까 싶다. 출처 : https://b-s-d.tistory.com/8" 주린이는 계속 자야 할까 싶다. 출처 : https://b-s-d.tistory.com/8 　치킨이 머릿속에 맴도는 시간도 잠시. 필자의 머리를 스치는 하나의 생각. 그러면 공모주 청약은 언제 하는 거지? 청약하니까 준비하라고 누가 알려주면 좋을 텐데… 그러면서 이런저런 검색을 해보니 안드로이드 앱은 이미 있었고, IOS 앱은 없었다. 음? 그럼 이걸 내가 만들어보면 어떨까? 　결론부터 말하자면, 텔레그램을 활용하여 자동화 공모주 알림봇을 만들게 되었다. 혹시 공모주에 관심이 있다면 필자가 만든 텔레그램 채널을 가입하는 것도 좋을 것 같다. 　이번 글에서는 필자의 새로운 토이 프로젝트인 ‘공모주 알리미’를 만들게 된 배경과 설계, 그리고 개발부터 릴리즈까지에 대해 이야기를 해보고자 한다. 크게 아래의 목차로 이야기하게 될 것 같다. 1부 : 프로젝트 설계, 데이터 수집 2부 : 수집한 데이터 알림 발송 3부 : 서버 선정 및 릴리즈 　자칫 너무 간단한데~, 이런 걸 굳이 왜 만들어?라는 시각이 있을 수 있겠지만 토이 프로젝트를 해야지 하고 마음을 먹었지만 막상 시작을 못하고 있는 어느 누군가에게는 도움이 될 내용인 것 같아서 꽤 자세히 정리를 하려 한다. 물론 이러한 정리는 필자 자신을 위해서가 더 크긴 하다. 프로젝트 설계 　과거에 토이 프로젝트로 진행했던 기술블로그 구독 서비스의 경험을 되새기면서 처음부터 황소처럼 달려드는 것보단 충분에 충족을 더해 충만해질 때까지 고민을 오랫동안 해보기로 했다. (그래봤자 하루 정도…?^^)  우선 데이터를 어딘가에서 가져오고 가져온 데이터를 DB에 저장할 것인지 아니면 저장하지 않고 휘발성으로 조회후 버리는(?) 형태로 할 것인지를 고민해야 했다. 공모주라는 데이터의 특성상 한번 정해진 메타 데이터가 상황에 따라 변경이 될 수도 있다고 했기에(일정이 변경되거나 공모가가 변경되거나 등) DB에 저장을 하게 되면 이를 동기화(Sync) 하는 비용이 추가로 생길 것 같아서 알림을 보내기 직전에만 조회하고 버리는 형태를 생각했다. 　그렇게 데이터를 조회했다면 이를 입맛에 맞게 가공하고서 사용자에게 알림을 줘야 한다. 알림을 발생시키는 방법은 매우 다양한데 뭔가 적은 비용으로 구성하고 싶었다. 즉, 알림을 받는 사용자가 10명, 100명, 1000명 이 되어도 (그렇게 될지는 모르겠지만;;) 내가 만든 서비스에서 알림 수신인이 늘어나는 경우를 고려하지 않아도 되었으면 했다. 그에 생각한 게 메신저 API. 그중에서도 텔레그램 API가 뭔가 이런 형식으로 딱일 것 같았기 때문이다. 결국 데이터를 메시지 형태에 맞춰 한 번만 발송하게 되면 1:N 형식(Broadcast)으로 텔레그램 채널을 구독하고 있는 사용자들에게 전송이 될 테니 안성맞춤이었다. 　그럼 언제 어떤 정보를 알려주는 게 좋을까? 청약이 보통 오전에 시작하기 때문에 대략 매일 오전 9시에 관련 정보들을 보내주면 될 것 같았다. 3일 전에 청약을 시작하게 되니 미리 준비하라는 알림. 그리고 청약 날짜가 도래해서 잊지 말고 청약을 신청하라는 알림. 마지막으로 공모주가 상장을 하게 되는 알림. 이 세 가지 알림만 잘 챙긴다면 필자 같은 주린이들도 충분히 공모주 청약으로 치킨을 먹을 수 있을 거라 생각했다. 　마지막으로 이 모든 내용을 개발한 어플리케이션을 어느 곳에 배포해야 하는지를 결정해야 했다. 항상 머릿속에는 있었지만 한 번도 안 해본 클라우드 Paas 인 heroku가 딱일 거라 생각했다.

이런저런 고생 끝에 원하는 회사에 취업을 해서 ‘주니어’라는 꼬리표를 달고 이제 막 회사 생활을 하다 보면 경험이 부족해서 실수를 하거나 기대했던 업무 퍼포먼스가 나오지 않는 경우가 종종 생긴다. 그럴 때면 “주니어잖아~ 주니어니까 괜찮아~” 라는 말로 어느 정도 ‘이해’를 하게 되지만. 쳇바퀴처럼 정신없이 시간이 지나 어느새 경력이 생기게 되고 이제는 약간의 실수조차 ‘이해’하기 어려운 시점이 되어버린다. 그러다 이런저런 이유로 ‘개발자’를 그만두게까지 되는 슬픈 현실은 주변을 둘러보면 어렵지 않게 찾아볼 수 있다. 그런데, 처음부터 잘 할 수는 없을까? 혹은 어렵거나 힘든 시점이 올 때면 학창 시절에 나를 이끌어 주셨던 ‘선생님’같은 존재에게 기대며 다시 일어날 수는 없는 것일까? 　나름 괜찮은 조직의 경우 연차가 낮은 직원이 힘들어할 때면 그 직원이 적응을 하는 데 도움을 줄 수 있도록 보다 연차가 높은 ‘지도선배’ 혹은 ‘멘토’를 할당해 주곤 한다. 그렇게 맺어진 관계가 잘 지속이 되면 위에서 말했던 ‘힘든 시점’에서 큰 도움이 되어 이겨낼 수 있는 힘이 생길 순 있지만 자칫 잘못되는 경우 ‘멘토’, ‘멘티’ 모두에게 부담이 되거나 오히려 안 하느니만 못한 시간들이 되어버리는 멘토링. 함께 성장하는 멘토링.출처 : https://medium.com/@ashokbalasubramanian/career-development-mentorship-844797327703" 함께 성장하는 멘토링. 출처 : https://medium.com/@ashokbalasubramanian/career-development-mentorship-844797327703 　이번 포스팅에서는 개발자로써 ‘멘토링’에 대해 어떤 마음가짐을 가져야 할지에 대해 작성해보고자 한다. 물론 틀린 부분도 있을 수 있지만 적어도 필자가 실무 개발자로써 다양한 경험들을 해보며 ‘멘토링’에 대해 꽤 중요하다 여겨왔던 순간들이 많았고, 직접 멘티 / 멘토의 경험도 해봤기에 누군가에게는 도움이 될 것이라 조심스레 생각해 본다. 멘토링? 어떻게 시작 하는거야?  멘토링에 대해 이야기하기 전에 멘토링의 정의부터 이야기할 필요가 있을 것 같다. 위키백과에 따르면 풍부한 경험과 지혜를 겸비한 신뢰할 수 있는 사람이 1:1로 지도와 조언을 하는 행위라 나와있다. 더불어, 조력자의 역할을 하는 사람을 멘토(mentor)라고 하며 조력을 받는 사람을 멘티(mentee)라고 나와있다. 학창 시절로 돌아가 보면 선생님은 멘토, 학생들은 멘티의 역할이 될 수도 있을 것 같다. 하지만 회사에서 멘토, 멘티의 관계는 어떻게 맺을 수 있을까? 앞서 이야기했듯이 누군가(아마도 조직의 리더가) 멘토와 멘티 관계를 정해주는 경우가 있지만 그렇지 않은 경우엔 어떻게 해야 할까? 　아래에서 이야기하겠지만 멘토링은 비단 도움을 ‘얻게 되는’ 멘티만 좋은 것이 아니라 도움을 ‘주는’ 멘토에게도 상당히 좋은 활동이라 생각한다. 하지만 단편적으로 보면 멘토보단 멘티가 힘들고 어려운 상황을 이겨내는데 더욱 ‘필요’로 하기 때문에 궁극적으로는 멘티가 멘토를 찾아 나서서 멘토링 관계를 맺어야 한다고 생각한다. 물론 천사 같은 선배가 멘토를 자처하고 멘토링을 해주겠다고 하는 상황이라면 땡큐지만 대부분의 선배들은 자기 코가 석자다 하며 바쁘기에… 　그렇다면 멘티는 멘토를 어떻게 찾아야 할까? 함께 일하는 선배 동료가 있다면 정중하게 도움을 요청하는 것도 나쁘지 않다 본다. 단, 무작정 “저의 멘토가 되어주세요.“라는 것보다 자신이 가지고 있는 고민거리를 털어놓으며 조금씩 친분을 쌓아간다면 아무래도 경험이 많은 선배이기에 고민의 범위를 조금이라도 줄여줄 수 있지 않을까. 혹여 주변에 선배 동료가 없다면 온/오프라인 커뮤니티 활동을 하면서 찾는 것도 방법이다. 메신저를 통해 다가가거나 메일로 정중하게 고민을 요약해서 보내놓으면 당장은 아니더라도 가까운 시일 내에 응답이 오기 마련이다. (적어도 괜찮은 선배라면.) 　여기서 말하는 ‘선배’의 정의는 단순 나이가 많아서가 아닌 자신보다 경험이 많은 사람을 의미한다. 그렇기에 자신보다 나이가 적은 사람이 멘토가 될 수도 있다고 생각한다.  왜 멘토링을 해야할까?  ‘경험’이 정말 중요하고 홍수같이 쏟아지는 신기술을 온몸으로 받아내야 하는 우리 개발자들은 특히나 멘토링이 필요하다고 생각한다. 어떠한 기능을 만들어 내야 하는 상황이라 생각해 보자. 아주 일반적으로는 기능 개발에만 집중하다 보니 서비스 릴리즈시 검토해야 할 부분들을 생각하지 못하는 경우가 있다.