<div id="readability-page-1" class="page"><div itemprop="articleBody">
            

            

            

            <p><img src="https://user-images.githubusercontent.com/33862991/218298764-46706a1d-ac1d-41bc-b990-cc0b94d0f132.png"></p>
<h2 id="🖋-키워드"><a href="#🖋-키워드" title="🖋 키워드"></a>🖋 키워드</h2><ul>
<li><a href="#first">2022년 상반기 회고</a></li>
<li><a href="#second">2022 하반기 회고</a></li>
<li><a href="#good">지난 해 잘한 것</a></li>
<li><a href="#bad">지난 해 아쉬운 것</a></li>
<li><a href="#wish">올 해 하고 싶은 것</a></li>
</ul>
<br>

<h2 id="2022년-상반기-회고"><a href="#2022년-상반기-회고" title="2022년 상반기 회고"></a><a href="first"></a>2022년 상반기 회고</h2><ul>
<li>사내 첫 발표 및 스터디</li>
<li>팀 이동 및 회원 이관 작업</li>
<li>ISMS 대응 목적의 백오피스 동시 접속 방지 기능 개발 </li>
</ul>
<h3 id="사내-첫-발표-및-스터디"><a href="#사내-첫-발표-및-스터디" title="사내 첫 발표 및 스터디"></a>사내 첫 발표 및 스터디</h3><p> 우리 회사는 매주 월요일 개발실 멤버들끼리 온라인으로 자유 주제로 이야기 나누는 시간이 있는데, 3월에 입사 이래 처음으로 발표를 하게 되었다. 특별히 발표하겠다는 분이 안계시면 랜덤으로 추출하는데, 드디어 내가 당첨(?)된 것이다. </p>
<p> 발표 주제가 마땅치 않아 약 1년 전쯤 읽었던 <a target="_blank" rel="noopener" href="http://aladin.kr/p/aGexE">&lt;객체지향의 사실과 오해&gt;</a>를 한 번 더 읽고 발표를 하게 되었다. 온라인이긴 했지만, 수십명의 개발자들 앞에서 내가 읽은 개발서적을 발표하려고 하니 엄청 떨렸다. 이 날 오전 7시도 안되서 사무실에 출근해서 발표 준비를 했던 기억이 난다…ㅋㅋ</p>
<p><img src="https://user-images.githubusercontent.com/33862991/218297167-674ab1c7-acc5-487a-bac1-2a66ee5f28b0.png"></p><p>link : <a target="_blank" rel="noopener" href="https://www.slideshare.net/91youngjin/ss-251399777">https://www.slideshare.net/91youngjin/ss-251399777</a></p>
<p> 떨렸지만 발표를 하고 나니 다른 분들과 인사를 나눌수 있는 사이가 되었다. 그 동안 다른 분들은 내 이름이 뭔지, 내가 어느 소속인지도 모르셨고, 나 역시 다른 분들을 모르다보니 같은 개발실 소속끼리도 인사를 나누질 못했는데, 발표를 한 번 하고나니 다들 먼저 인사를 해주셔서 입사한지 거의 반년만에 회사 개발실 소속 구성원분들과 가까워지게 되었다.</p>
<p> 4월엔 회사에서 스터디를 진행했다. 슬랙에서 시니어 개발자분께서 해보고 싶은 주제를 말씀해보라고 하셔서 디자인 패턴을 얘기했다가 엉겹걸에 내가 호스트가 되어 그 스터디를 진행하게 되었다. </p>
<p><img src="https://user-images.githubusercontent.com/33862991/218297166-79cc8ea1-9c5b-4484-9484-f5e4e7d30432.png"></p><p> 당황스러웠지만, 시간이 지나고 나니 이 또한 좋은 기회였던것 같다. 덕분에 동료분들과 매주 스터디를 하면서 더 가까워질 수 있었다. </p>
<p>무튼 스터디 방식은 <a target="_blank" rel="noopener" href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=290892473">헤드퍼스트 디자인패턴</a> 책을 한 챕터씩 읽고 돌아가며 발표를 하는 방식이었다. 스터디를 통해 회사 동료분들과 더 가까워지는 계기가 되었지만, 이 스터디를 통해 스터디 방식이나 주제에 대해 조금 더 고민이 필요하다는 생각이 들었다. </p>
<p> 관심있어서 시작한 스터디였음에도 ‘<em>이걸 언제 어떻게 사용할 수 있을까?</em>‘ 라는 질문에 명확한 대답이 나오지 않다보니 스터디 중반부터 회의감이 들어서 힘들었다. 동시에 시작한 스터디가 3개정도였는데, 그 중 하나는 제대로 시작도 못하고 흐지부지 되었는데 이 스터디마저 그렇게 되면 안될것 같아 어떻게든 꾸역꾸역 마무리를 했다.</p>
<br>

<h3 id="회원-이관-작업"><a href="#회원-이관-작업" title="회원 이관 작업"></a>회원 이관 작업</h3><p> 2022 년은 회사에게 쉽지 않은 시간이었다. 2021년 여러 서비스를 론칭했던것과 달리 지난해는 새 서비스 론칭보다 성과가 미진한 서비스들을 중단하는 결정들이 계속 이어지는 시간이었다. </p>
<p> 성과가 아쉬워서 서비스를 더 이상 운영할 수는 없지만, 이미 구입한 고객에게 강의시청 기간을 약속하고 판매했기 때문에 이분들이 이용할 수 있는 다른 사이트로 회원이관이 필요했다.</p>
<p><img src="https://user-images.githubusercontent.com/33862991/218297172-476f2bea-7b73-43a3-a268-4774bea341e5.png"></p><p> 강의 영상들이야 데이터 팀에서 쿼리로 이관해주셨는데 회원 이관의 경우, <code>당신의 정보를 B에서 A로 이관합니다</code> 에 대해 각 회원에게 직접 동의를 얻어서 이관해야 했다. </p>
<p> 서비스 종료를 발표하고 특정 시기까지 회원 이관 동의 기간을 발표하고, 이 기간동안 접속해서 이관에 동의하는 회원은 회사가 운영하는 다른 서비스에서 구입한 강의를 계속 시청할 수 있는 프로세스였다. 따라서 쿼리로 해결하지 못하고, 회원이 동의하는 시점에 회원정보가 이관되어야 하므로 API가 필요했다. 우리팀에서 회원 이관 API를 개발해야 해서 내가 이를 담당하게 되었다. </p>
<p> 우리 회사는 온라인 강의를 서비스하는 회사인데, 기존에 운영중인 A라는 서비스가 있어서 서비스 중단이 결정된 B 서비스의 결제 회원에 대해서 본인이 동의하면 A 사이트에서 계속 강의를 들을 수 있도록 회원의 결제 정보를 이관 하는 작업이었다. 이 과정에서 회사의 강의 결제 프로세스를 익힐 수 있었다.</p>
<blockquote>
<p> 강의를 주문하면, 강의 주문정보가 등록되고, 이후 결제가 완료되면 강의를 시청할 수 있는 권한이 주어진다.</p>
</blockquote>
<br>

<h3 id="ISMS-대응-목적의-백오피스-동시-접속-방지-기능-개발"><a href="#ISMS-대응-목적의-백오피스-동시-접속-방지-기능-개발" title="ISMS 대응 목적의 백오피스 동시 접속 방지 기능 개발"></a>ISMS 대응 목적의 백오피스 동시 접속 방지 기능 개발</h3><p> 우리 회사 규모가 커지면서 매출 천억 이상의 소위 중견기업들에게 요구되는 ISMS 심사를 받게 되었다. 인증/권한 관련 하여 우리 팀도 ISMS 대응으로 할 일이 있었는데, 1년 미만의 연차를 가진 내겐 <code>하나의 계정으로 여러 클라이언트에서 백오피스에 접근하지 못하는 기능</code> 개발을 태스크로 부여받았다.</p>
<p> 사실 블로그임에도 불구하고 이와 관련해서 아직 솔직하게 설명하기 어려운 부분이 있다. 기능은 개발하였지만, 현재 내가 개발한 방식이 최선인지 아직 스스로 확신을 못갖고 있다. 팀장님과 CTO님께도 리뷰를 받았기 때문에 문제가 될 일은 없지만, 엘레강스한 방식이 아니라고 생각하고 있다. 언젠가 이 기능을 개선하게 되면 그 땐 어떻게 개선하게 되었는지를 블로글를 통해 솔직하게 회고 하고 싶다. 그러나 자신없어서 그러지 못하겠다 😭</p>
<br>

<h2 id="2022년-하반기-회고"><a href="#2022년-하반기-회고" title="2022년 하반기 회고"></a><a href="first"></a>2022년 하반기 회고</h2><ul>
<li>Thanos 프로젝트 시작 w/TypeScript</li>
</ul>
<h3 id="Thanos-프로젝트-시작-w-TypeScript"><a href="#Thanos-프로젝트-시작-w-TypeScript" title="Thanos 프로젝트 시작 w/TypeScript"></a>Thanos 프로젝트 시작 w/TypeScript</h3><p> 2022년은 백엔드 개발자들이 대대적으로 레거시 프로젝트를 개선하는 작업을 진행했던 한 해였다. 특히 자바 스크립트로 작성된 코드를 타입 스크립트로 전환하는 것이 주요 업무였다.</p>
<p> 나의 경우 지난해 모바일앱에서 사용할 목적의 리프레시 토큰을 개발하는 작업을 하면서 인증 관련 코드를 살펴보게 되었는데, 이 일을 계기로 회사에서 사용하는 인증 패키지를 새 패키지로 대체하는 작업을 하반기부터 진행하게 되었다. 처음으로 내가 오너십을 갖는 레포지토리가 생기게된 계기였다. </p>


<p> 공개 레포지토리는 아니지만, 인증(Authentication)을 다루는 영역이다보니 팀장님께서 이 레포의 네이밍을 <a href="thanos"></a>Thanos로 해주셨다. 오너십은 갖고 있지만, 레포지토리 생성 초반엔 팀장님과 다른 팀원 분께서 작업을 해주셔서 다른 분들의 코드가 더 많았는데, 지금 서서히 내 기여도도 높아지고 있다.</p>
<p><img src="https://user-images.githubusercontent.com/33862991/218297168-652251f7-3b22-4ab7-91b6-9efceaff371e.png"></p><p> NPM 패키지였던 지난 인증 코드와 달리 현재는 아예 서버를 따로 띄우는 작업을 하고 있다. 이게 <a target="_blank" rel="noopener" href="https://aws.amazon.com/ko/microservices/">MSA</a>라고 할 수 있을지 모르겠지만, 앞으로 회사의 인증 관련 로직을 분리해서 따로 서버로 배포한 후, API 통신을 통해 필요한 기능을 제공하고자 한다. 그러나 코드 로직상으로 보면, 솔직하게 현재까진 타입스크립트와 DI를 적용한거 외엔 아직 레거시 코드와 크게 차이가 없다. 더 개선할 필요가 있다. 뿐만 아니라 어떤 서비스가 요구사항이 들어왔을때 대응할 수 있도록 미리 인증 관련한 기능 구현이 더 필요하다. 예를 들어 쉽게 Oauth2 를 구현할 수 있도록 기능이 필요하다. 또한 서비스마다 정책이 다를 경우 복잡한 시나리오로 권한을 분리하고 관리해야할 수 있는데, 이 또한 빠르게 대응가능하도록 관련 기능 준비와 유연한 설계가 요구된다. </p>
<p> 궁극적인 목표는 팀장님이나 내가 아닌 누가 이 레포지토리를 맡아도 빠르게 코드를 파악하고 리팩토링을 할 수 있는 것이 목표이다. 그래서 내가 작성한 코드가 언젠가 사라지고 서비스에서 요구하는, 더 좋은 코드로 대체되더라도 Thanos라는 레포지토리의 명맥이 계속 유지되는 것이다. 그러기 위해 우선 구조를 단순화하고, 문서화하는 것이 필요하다고 판단하고 있다.</p>
<br>

<h2 id="지난-해-잘한-것"><a href="#지난-해-잘한-것" title="지난 해 잘한 것"></a><a href="first"></a>지난 해 잘한 것</h2><p> 하반기에 회사 동료분들과 적극적으로 어울리는 시간을 보냈다. 회사 동료들을 더 가까이 알고 싶었던 이유도 있었고, 코드 리뷰나 슬랙에서 더 편하게 이야기 나누고 싶었다. 3월에 발표를 한 번 한 이후에 인사를 나누게 된 동료분들이 생긴 계기로 하반기에도 자유주제로 한 번 더 발표를 하게 되었다.</p>
<p><img src="https://user-images.githubusercontent.com/33862991/218297170-d13a3e56-e46e-4049-bf7f-d1686ed6c21c.png"></p><p> 주제를 생각하기 전에 일단 발표부터 해야겠다는 생각을 했는데, 이유는 하나였다. 더 많은 분들과 가까워지려면 이들에게 내가 누구인지를 먼저 전달해야하는데, 비용대비 가장 효과적인 이벤트는 개발실 식구들이 모두 모이는 매주 월요일 아침 미팅이었다. 회사내 다른 분들의 경우 발표를 하더라도 카메라를 켜지 않지만, 난 매번 발표 때마다 카메라를 켜는데 같은 맥락의 이유이다.</p>
<p> 이 덕분에 지금은 회사 동료들과 즐거운 저녁 식사 자리를 갖는 빈도도 늘었지만 무엇보다 좋은건 코드리뷰이다. 친해지기 전엔 항상 같은 팀원들에게만 리뷰를 요청했다. 다른 팀이 오너십을 갖는 레포지토리엔 PR을 올리는게 살짝 걱정되었지만, 지금은 모든게 편해졌다. 나를 리뷰어로 걸지 않아도 슬랙에 올라는 PR 노티 채널에서 관심있는 PR에 들어가서 의견을 남기거나 또는 내 PR 역시 리뷰어가 아님에도 찾아와주셔서 리뷰를 남겨주시는 감사한 분들이 생겼다. 😍 </p>
<br>

<h2 id="지난-해-아쉬운-것"><a href="#지난-해-아쉬운-것" title="지난 해 아쉬운 것"></a><a href="first"></a>지난 해 아쉬운 것</h2><p> 현재 작업중인 Thanos 프로젝트 사용처가 아직 없다. 사실 다른 팀원께서 작업해주신 기능의 경우 ISMS 대응을 하며 Thanos에서 만든 패키지가 사용되고 있긴 한데, 내가 만든 패키지는 여전히 사용되고 있지 않다. 그래서 코딩만 했을뿐, 성과 또는 결과라고 할만한게 없다. </p>
<p> 이제 신입딱지 뗀 2년차 개발자이므로 더 이상 코딩만 하는 사람이 되어선 안된다고 생각한다. 내가 작업한 코드가 어떤 식으로든 회사에 기여할 수 있어야 한다. 상반기엔 회원 이관 API 개발, ISMS 대응 백오피스 동시접속방지 기능 개발 등 요구사항에 따라 일을 했는데, 하반기엔 그러지 못해서 약간의 아쉬움으로 남는다. 요구사항 없이 일을 하다보니 사실 온전히 개발에만 집중할 수 있어서 재밌기도 했지만, 이렇게까지 작업한게 아직 회사에 기여하지 못한다는 사실을 생각하면 또 아쉬움이 느껴진다. </p>
<br>

<h2 id="올-해-하고-싶은-것"><a href="#올-해-하고-싶은-것" title="올 해 하고 싶은 것"></a><a href="first"></a>올 해 하고 싶은 것</h2><p> 지난 해 아쉬운 점과 연결되는 내용이다. 2022년까지는 미국의 Layoff 소식이 많았는데, 올 해부터는 우리나라 회사들도 구조조정 소식들이 들려오고 있다. 심심치 않은정도가 아니라 ‘이 회사도 힘들다고..?’ 할만큼 이곳 저곳에서 비용을 줄이기 위한 마지막 자구책을 내놓는 실정이다. </p>
<p> 지금 회사에 입사하던 때와 시장 분위기가 180도 바뀌었다. 코드를 잘 짜는것만큼 중요한건 회사가 돈을 잘 벌어야 보상을 받을 수 있다는 사실이다. 좋은 코드만큼 회사에 기여할 수 있는 시간을 보내고 싶다. 그래서 상반기엔 <a href="#thanos">Thanos</a>의 구조를 다른 분이 살펴보더라도 쉽게 이해할 수 있도록 단순화하고, API 스펙 문서도 작성을 하려고 한다. 그리고 하반기엔 이를 바탕으로 여러 서비스에 적용해서 서비스 개발 속도를 조금이라도 앞당기는데에 기여하고자 한다. 서비스에서 요구하는 인증/권한 기능 뿐 아니라 관련한 책임까지 Thanos가 떠맡을 수 있다면, Thanos가 회사에 기여하고 있음을 입증할 수 있을것 같다.</p>
<p> 현재 새로운 백오피스가 개발중인데 여기에 내가 작업인한 Thanos를 공급하는중이다. 잘 반영이 된다면 새 백오피스부터는 인증관련 모든 책임을 Thanos가 가져갈수있게된다.</p>


        </div></div>

2022년 회고

댓글