리팩토링

22년도 개인적으로 가장 많은 시간을 투자한 일이 있다면 내가 지금 현재 속한 개발조직에서 진행한 리팩토링이 아니었을까 싶다.

리팩토링을 결정하는 이유는 개발조직에 몸담고 있는 사람이라면 모두 대충 짐작가리라 생각하지만 특히 나에겐 리팩토링을 진행한다는 의미는 내가 속한 조직의 주요 비즈니스 로직이 이제 나한테 넘어온다는 의미이기도 하여 (자세한 설명은 생략) 더욱 신경을 쓸 수 밖에 없었다.

그때는 맞고 지금은 틀리다.

일단 기존의 DB 구조부터 손 볼 필요가 있었다. 그를 위해 넘겨받은 DB는 Flat table 구조로 이뤄져 있었고 그동안의 비즈니스 로직의 확장은 곧 컬럼의 확장으로 이어지는 구조였다.

따라서 데이터간 관계가 없는것은 물론이고 Response time도 당연히 증가할수 밖에 없었으며 인덱싱은 고려한적 없으니 검색성능은 기대할 수준이 아니었다.

리팩토링대상은 DB 뿐만 아니라 기존에 사용하고 있던 API의 대상으로도 진행되었다. 기존에 사용하고 있던 API는 node.js로 개발된 상태였는데 이미 스파게티 코드화 되어있던 상태이고 이를 관리하고 있던 인력은 이미 조직에서 이탈한 상황이었다.

결정적으로 내가 관리하고 있는 백엔드 팀은 이미 Python 생태계에 매료되어 있는 상태였다. 그리고 FastAPI로의 전환을 시도하고 싶었다.

따라서 DB 재설계와 마이그레이션 및 기존 API 전부를 FastAPI로 전환하는 결정을 하게 되었고 기존 로직을 분석하려고 기존 API의 코드나 DB를 분석할때면 한숨과 함께 원망이 터져나올수 밖에 없었다. 그것이 한순간 답답함을 풀어 줄 수 있을지언정 근본적이 해결책이 될 수 없음을 알면서도 나는 계속 남탓을 할 수 밖에 없었던것 같다.

나중에 알게된 사실이만 그 API들을 관리하던 분은 사실 Android개발자 였었고 스파게티 코드가 되더라도 비즈니스 로직의 구현이 우선적인 목표였기 때문에 그렇게 개발할 했었던 것이다.

하지만 나는 이 모든것을 이해하면서도 한편으로 서운함을 감출 수 없었다. “그래도 이왕 할거 제대로 하지” 라는 말을 항상 내뱉었던거 같다. 이게 다시 생각하면 참 무책임한게 프로덕션 레벨의 앞단 개발 경험이 없는 백엔드 개발자인 나한테 누가 갑자기 앞단 개발을 지시하면 나도 마찬가지로 구현을 위한 구조와 코드를 작성할거 같다. 그것이 나로써 할수 있는 최선의 노력임에도 불구하고 말이다. 그렇기 때문에 기존 레거시를 개발한 사람 입장에선 그 결과물이 최선을 다한것이었다. 난 그런 노력을 깡그리 무시하고 멸시하고 있었던것이다. 입장바꿔서 생각하면 얼마나 억울하겠는가.

또 생각해보면 그런 레거시 때문에 나도 도전을 할 수 있는거 아닐까 싶다. 오히려 좋아가 이럴때 쓰는 말인가 싶긴 하지만 덕분에 나도 평소에 눈여겨 보고 있던 핫한 프레임워크를 도입해볼 수 있는 구실을 만들수 있었고 조직의 주요 비즈니스 로직에 영향력을 더 행사할 수 있는 계기가 되었던 것 같다.

22년 회고를 진행하면서 다음 몇가지 다짐을 할 수 있는것 같다.

• 레거시? 오히려 좋아.
• 내가 지금 설계한 코드와 구조도 누군가에겐 레거시로 느껴질 수 있다.
• 평소에 잘하도록 노력하고 이미 세상에 나온 내 새끼들도 다시 돌아보자.

최신기술은 무조건 좋은가?

리팩토링을 진행하면서 팀 내부적으로도 큰 결정을 한것은 FastAPI로 개발하기로 결정한 것이었다.

Python 생태계에서 활동하는 개발자라면 현재 FastAPI의 관심도는 이미 github star의 개수 및 상승세만 봐도 알수 있듯 현 시점 가장 핫한 프레임워크라는 사실을 알고 있을 듯 하다. 이러니 이걸 어케참어…

바로 리팩토링 시작과 함께 FastAPI로 개발을 시작했고 사전에 공식문서를 탐독하고 각종 아티클을 수집해놔서 순조롭게 개발을 진행했던거 같다. 다만 몇가지 애로 사항들이 있었는데.

레퍼런스의 부족

구글 검색결과만 봐도 현재 FastAPI는 그 레퍼런스가 부족한 상태이다. 그중에서도 특히 한국에서의 관심도는 더욱 처참하다.

이런 상황이다 보니 거의 대부분의 문제는 공식문서를 의지 할 수 밖에 없었고 어려운 문제를 만나면 그것을 해결하기 위한 다양한 아티클들을 찾아볼 수 없어 들이박는거 밖에는 방법이 없었을때도 있었다.

그래도 현재는 팀원들도 나름 이 환경에 적응한것 같고 아직까지는 순항중인것 같다 오히려 이제는 Flask의 활용을 거의 안해서 내 보유스킬에서 내릴까 고민중이다.

채용에 대한 고민

앞서 언급했듯 FastAPI에 대한 국내 시장의 관심도가 그리 높지 않으니 당연하게도 FastAPI를 활용하는 개발자의 인재풀 역시 얇을수밖에 없다. 당장에 채용공고만 봐도 FastAPI를 다루는 개발자는 해외공고에서나 볼 수 있는 지경

당연하게도 신규 채용에 대한 고민이 자연스럽게 따라왔다. 리팩토링을 진행하면서 간과한 부분인것 같다. 개인적인 성장을 위해 FastAPI라는 Young하고 MZ한 최신기술을 도입했으나 내가 관리자라는걸 까먹었던거 같다. 내무덤 내가 판거지…

23년에는 그래서 FastAPI에 대한 온보딩 프로세스를 개발해야 할거 같다. Python Backend 채용 시장은 아직까지 Django와 Flask가 양분하고 있는 상황이니 이들을 찾아 FastAPI로의 자연스러운 전환이 가능한 방법에 대해 찾아볼 필요가 있을것 같다.

충분한 기술 조사가 필요하다.

이번 리팩토링에서 FastAPI와 함께 또 하나의 최신기술인 DynamoDB를 도입하려 했었다. 이 DB는 AWS에서 제공하는 완전 관리형 NoSQL DB인데 특히나 내가 혹한 부분은 쉬운 고가용성 확보와 Serverless로 동작하여 내구성에 신뢰도 확보된 상태였다가 게다가 AWS에서는 10ms 미만의 Read/Write 속도를 보장한다고 하니… 이걸 어케 참어… 당장에 도입할 수 밖에 없었다.

하지만, 역시 행복 코딩만 가능하다면 세상이 얼마나 아름다울까 그러나 일단 시작 부터 문제였다. 이 DB 로컬 환경을 구축할 수 없었다. 어쩌면 당연한게 서버리스로 동작하는 DB를 무슨수로 로컬에서 띄울수 있을까 그나마 AWS 에서 제공하는 Docker Image가 존재하여 로컬 및 개발환경에서 DynamoDB의 컨테이너에 접근할 수 있게는 해놨다.

그 다음 문제는 ORM의 레퍼런스가 거의 없었다. 기본적으로 제공은 당연히 안하는건 이해하는데 (이건 MongoDB도 마찬가지) 그나마 있는 PynamoDB의 레퍼런스는 너무 부족했다. ORM알자너 한번 잡숴보면 어지간하면 다른집 못가는거

근데 그 ORM이 너무 마이너 영역에 있다는게 문제였다. 세상 모든 질문이 다 있다는 Stack Overflow에도 질문글을 찾아보기 힘들정도니까… 이쯤되니 환상이 슬슬 깨지고 있었는데 한가지 더 문제가 있었다.

우리가 쿼리를 할때 보통 정렬을 하는것은 일반적인 일이다. 근데 이 DB… 정렬을 위한 인덱스 생성을 해야한다… GSI와 LSI의 개념을 이해하는것은 둘째 치더라도 그 당시 나에겐 정렬을 위해 인덱스를 생성한다는것 자체가 이해하기 어려웠다. 그래서 이별통보만을 앞두고 있었다.

그리고 헤어진 결정타는 바로 이 DB에 존재하는 각종 제한들을 관리할 자신이 없었다. 하루는 로컬 환경에서 더미 데이터를 집어넣고 Scan때렸는데 평소에 발생하지 않던 에러들이 마구 튀어나오는 것이다. 문제는 바로 스캔의 결과가 1mb를 넘었기 때문이며 이 경우 LastEvalutedKey 옵션을 통해 다음 결과를 가져오는 방식으로(약간 Pagination과 비슷함)모든 결과를 가져와야 하는 상황이었는데 물론 이것이 페이지네이션을 구현할때 응답속도를 고려하지 않고 자연스럽게 처리해준다는 장점은 분명히 존재했지만 이 방식을 앞단에서도 용인해 줄지는 의문이었으며 이때 그동안의 안좋았던 개발경험과 향후 이뤄질 개발경험이 그닥 좋지는 않겠다고 판단되어 모두 MongoDB로 이사하는 결정을 내렸다.

그렇게 밤새워 모두 이사를 가고나니 첫번째로 일단 이게 프로덕션환경에서 발생한 해프닝이 아니라는 것에 일단 감사했고 두번째는 프로덕션환경에서 발생했다면 진짜 끔찍했을거라는 상상에 등골이 살짝 오싹해지는 경험을 했으며 세번째이자 가장 중요한 생각은 최신기술은 최대한 기술조사를 하고 난 다음에 도입하는게 맞다는 생각이 들었다.

내가 앞서 언급했던 문제들 솔직히 내가 DynamoDB에 대해 파악이 미숙해서 발생한 문제지 이미 잘 사용하고 있는 사람을 대수롭지 않게 넘어갈 문제일 수도 있다. 다만 납기는 다가오고 있었으며 마음은 조급해졌다. 한치 앞도 안보이는 길을 더듬어 가며 걸어가기엔 너무 위험하다고 판단했던거 같다. 만약 내가 기술조사를 충분히 했고 이것저것 사용해보며 익숙했으면 다른 결과가 도출되었겠지? 그러니 다음부터는 기술조사를 철저히 하고 새로운 기술을 도입해야겠다.

원래, 기존에, 옛날에, 이미

이번 리팩토링을 진행하면서 나 역시 처음 경험한 리팩토링이기 때문에 머리에 물음표가 띄워질때가 종종 있었다.

내가 생각하는 리팩토링은 레거시한 코드들을 걷어내는것도 그 의미가 있지만 기존 구현 로직을 변경하는것에도 그 의미가 있다고 생각했다. 그런데 개발조직 자체가 리팩토링이 처음이라 그런지 내 생각과 다르게 원래, 기존에, 옛날에, 이미 이런 주제를 자주 얘기하게 되었던거 같다.

속으로 물음표를 띄우면서 그거 바꾸자고 리팩토링 하는거 아닌가? 하는 생각을 종종했던거 같다. 하지만 이미 다수결에서 압도된 상태에서 회사생활에 가면써야 하는 한국인 특성상 차마 바꾸자고 강력하게 밀고 갈수도 없었고 이미 그렇게 개발이 끝났다는 말을 듣게 된다면 (부차적으로 이건 또 소통의 문제) 이미 개발된거 바꾸자도 할수도 없는 노릇이니 그저 내 손에 뒷단 로직이 들어온다는 생각으로 쉽게 용인했던 문제들이 현 시점에 와서 가끔 문제가 되는 경우가 있다.

그래도 다행인점은 지금은 고칠수라도 있을거 같아서 나름 다행이라고 생각하는 중이다.

재택근무

리팩토링 결정과 함께 또 하나의 큰 결정은 개발조직의 재택근무로의 전환이다. 수많은 조직이 이미 코로나로 인해 반강제로 재택근무로 전환하기도 했는데 이 과정에서 느낀 몇가지를 회고하고자 한다.

좋았던 점 👍

일과 삶의 일치

요즘 워라밸이라 불리는 일과 삶의 밸런스를 찾는것에 집중하는것 같다. 근데 사실 재택근무를 하면 그런 고민을 건너 뛰고 일과 삶을 일치시킬 수 있는 방법이 생긴다. 예를들어 퇴근시간 직전에 떨어지는 업무들이 기존에는 부담이 되었다면 퇴근이라는 개념이 사라졌으니 자연스럽게 아무 부담 없이 처리하게 되는 경험을 하게 되었다. 퇴근시간 즈음에 업무를 던진 누군가를 욕할 필요가 없었다. 시간적 여유가 생겼기 때문이다.

그리고 나는 취미도 개발인데, 개발하는 행위 자체가 즐거워서 이것이 회사의 업무더라도 출퇴근을 하지않으니 오후에 개발하고 있는 것을 밤 12시가 넘어서까지 붙잡고 있는 경우가 많았다. 만약 출퇴근을 하는 상황이었다면 퇴근후에는 당연히 내 사이드 프로젝트를 진행했을 것을 회사의 업무를 붙잡고 있게 되었다. 그래도 즐거웠다. 다만, 사이드 프로젝트의 양이 줄었던건 그닥 반가운 일은 아니라서 올해는 그 둘의 밸런스를 찾아야 할거 같다. 일과 삶의 밸런스가 아니라…

효율적인 시간 활용

일단 먼저 나는 인천에서 나고 자란 34년차 Inchonian이다. 역삼에 위치한 본사까지 대략 2시간에서 차막히면 답도없다. 내가 어디 강원도 산골사는건 아니지만 그래도 매일 출퇴근하기엔 부담스러운 거리기도 하다. 이런 나에게 출퇴근 시간이 사라졌다는 하루에 최소 4시간씩의 시간을 확보한셈이다. 이렇게 확보한 시간은 곧바로 생산성으로 이어져 나의 생산성을 폭발적으로 증가시켰다.

게다가 나는 결혼을 하여 가정을 두고 있는 사람이다. 이런 사람한테 재택근무는 집안에서의 소소한 업무를 처리할 여유로운 시간을 준다. 주민센터에서 서류 뗀다고 반차쓰지 않고 점심시간을 이용해서 소소한 집안일을 처리할 수 있게 되어 와이프한테 눈치보지 않아도 된다.

특히나 나의 경우 와이프도 재택근무를 하는데 출근하면서 줄어들 수 밖에 없던 대화의 시간이 매우 늘어나 서로 더 잘 이해할 수 있는 장점도 생겼고 평소엔 나의 부재로 인해 결정하지 못했던 집안의 크고 작은 일들을 바로바로 대화해 나가며 결정할 수 있었다. 덕분에 집에는 관심도 없는 사람이란 타이틀은 달지 않으면서 회사의 주요 굵직한 업무들은 처리하는 만능이 된것만 같았다.

비동기 커뮤니케이션

모든 개발자가 가장 싫어하는 짓중 하나가 아마 몰입중에 그 몰입을 깨고 들어오는 커뮤니케이션일 것이다. 물론 안그러신 분도 있겠지만 존경드린다.

아무튼 이런 실시간 커뮤니케이션을 요하는 상황에선 바로바로 답변을 하지 못하는 것이 스트레스로 작용했고 특히 몰입을 깨는 커뮤니케이션이 발생하면 상대방은 내 몰입도의 수준을 모르니 다소 억울하겠지만 나는 어쩔수 없이 몰입도를 깨고 들어온 상대방에게 “정말 배려가 없는 사람이군”이라 생각할 수 밖에 없다.

재택근무를 하게 되면서 이런 스트레스로 부터 해방이 되었다. 비동기 커뮤니케이션이 가능해지면서 어차피 Slack에 기록이 남기 때문에 생각해보고 답변을 할수도 있고 레퍼런스를 찾아보고 더 정확한 답변도 가능해지고 나또한 상대방이 즉시 답변을 하지 않더라도 “확인하고 답변주겠지” 라고 생각하고 몰입하던 업무를 이어서 진행할수 있었다. 그리고 이런 비동기 커뮤니케이션을 지원하기 위해 Slack에서도 권장하는 방법들이 있으니 재택근무가 확대 된다면 고려해볼만 할것 같다.

나만의 업무 환경

개발은 장비빨임

특히 개인화된 장비들과 환경 구성을 통해 일하기 가장 좋은 환경을 스스로 만들수 있는것은 재택근무의 장점이라고 생각한다. 덕분에 지출이 조금 발생하는건… 단점이지만 그래도 마음이 풍요로워 지니까 등가교환 했다고 생각하면 될것이다.

게다가 다들 한번쯤 해봤을 오늘 뭐입지? 라던가 기본적인 씻는것 조차 눈치 볼 필요가 없어졌고 혼자 개발 하면서 키보드 샷건을 치던 (나는 안친다 비싼 키보드한테 그라믄 안대) 허공에 쌍욕을 박아버리던 신명나는 노동요를 틀어놓고 열창을 하며 업무를 하던 눈치봐야할 사람들이 없으니 업무 외적으로 신경쓰던 것들에게서 벗어날 수 있었다. 그 정신력과 집중력을 온전히 내가 개발하고 있는 작업물에 쏟을 수 있었던것 같다.

안좋았던 점 👎

업무를 진행했는지 증명하기에는 더 힘들어졌다.

사실 상주하여 근무를 하고 있으면 대충 코딩화면 띄워놓고 키보드에 손 올리고 있으면서 머리속으로는 퇴근하고 술마시면서 먹을 안주메뉴를 고르고 있어도, 동료들과 시종일관 쓰잘때기 없는 대화를 나누고 있어도 (혹자는 잡담에서 아이데이션을 얻을 수 있으니 적극 권장한다지만 이것도 그 잡담의 유형과 시간이 중요하겠지?) 누군가 보기엔 업무를 진행하는 것으로 보일 수 있다.

그러나 재택근무로 전환되면서 실제로 내가 업무를 하고 있다는 것을 증명하는 방법은 Slack이 온라인 상태인지, PR이 올라오는지, 티켓이 갱신되는지로만 증명이 된다. 즉, 업무 진행여부 보다는 실제 결과가 더 중요해진 것이다. 걔중 누군가는 비즈니스 로직에는 변화가 없고 기존 로직의 리팩토링이나 유지보수를 하는 친구들은 그 성과를 증명받기 더 어려워진것 같다.

관리자로써의 고민은 더 해진것 같다.

내 팀원들이 내가 보는 눈 앞에서 일하는 모습을 봐야 마음이 진정되는 좋소기업 사장님 마인드를 얘기하고자 하는것은 아니고 팀원들도 분명 기술적으로든 회사생활이든 고민인 부분이 있을텐데 그런것들이 눈에 보이는 행동들로 발현이 될텐데 재택근무 환경에서는 그 부분을 캐치하지 못하니 관리자로서 선조치를 해줄 수 있는 기회가 사라지는것 같았다. 특히나 최근 아끼던 팀원 하나를 잃어서 그런지 이런 부분이 제일 아쉬웠던거 같다.

물론 나도 아직 주니어레벨인데 누가 누굴 관리하는거 자체가 조금 어불성설이지만 그래도 입사선배로써 조언해줄수 있는 부분이 있을것이며 그래도 밥한공기 더 먹은 늙다리니까 먼저 건너간 징검다리 두번째돌은 절대 밟지마라 그거 내가 밟아봤는데 진짜 주옥같이 힘들더라와 같은 경험기반의 조언들은 가능하다고 생각한다.

그러나 재택근무 환경에서는 이런부분들이 조금 힘들어진것 같다. 이를 방지하기 위해 “고민이 있으면 나에게 편하게 DM해라 언제든 연락해라”라고 말은 하고 있으나 내가 팀원들 입장에서 생각해보면 팀원이 관리자에게 먼저 다가간다는게… 생각보다 쉽지는 않을것이다. 결국 나도 하지 않을걸 팀원들에게 요구하고 있던거 같다. 재택근무 체제에서 이런 부분을 해소 할 방법이 있는지 고민이 필요할 것 같다.

재택근무 문화를 더 다지기 위한 고민

재택근무를 확대한다면 이미 잘 시행하고 있는 조직으로 부터 배워보고 싶은것들이 있다. 특히 그 중에서는 내가 개인적으로 생각했을때 로켓펀치의 알리콘이 재택근무 문화를 정말 잘 정착했다고 생각하는데 우리 조직도 확대하게 된다면 이런 좋은 예시를 참고하여 확대해보는것이 어떨까 생각이 든다.

Notion → Trello → Redmine 도입썰

내가 아무래도 개발자로 전향하기 전에 QA/PM 조직에 몸담고 있었다보니 새로운 팀원들의 합류와 재택근무의 도입으로 자연스럽게 먼저 생각이 든것이 바로 할일, 일감, 업무라고 불리우는 태스크를 어떻게 하면 재택근무를 하면서도 효과적으로 관리할 수 있을까? 에 대한 고민이었다.

사실 기존에 Notion이라는 협업 도구를 통해 각자 할일에 대해 관리하고 있었다. 하지만 업계에서 Trello나 Redmine을 오랬동안 사용한 나로써는 태생부터 프로젝트 관리 도구가 아닌 Notion으로 태스크를 관리하는것에 한계를 느끼고 있었고 리팩토링이라는 매우 큰 프로젝트를 진행하면서 각 팀간의 업무 현황 공유를 위한 도구가 필요해진 상황이었다.

고민끝에 Trello를 도입했다가 현재에 이르러서는 Redmine으로 전환했는데 그 과정에서 느낀점들을 서술해보고자 한다.

도구 만능주의

먼저 나는 도구 만능주의에 빠진것 같다. “일단 한번 잡숴봐”라며 일단 Trello를 도입하게 되면 자연스럽게 각 팀이 프로젝트 관리 도구 위에서 업무를 진행할것 이라는 안일한 생각이 그 이유인것 같다. 도구를 쓰는 것도, 업무를 진행하는것도 결국 사람이 하는 일인데 그동안 구두로 진행하던 업무가, 의사결정들이 도구의 도입으로 한순간에 전환되지는 않았다.

그것을 간과한채 사내 커뮤니케이션 도구인 Slack으로 Integration만 덕지덕지 붙여놨다. Automation 도구인 Butler도 기깔나게 붙여놨다. 덕분에 우리팀 슬랙채널은 Notification의 홍수가 되었고 커뮤니케이션의 목적으로 채널을 사용할 수 없는 지경에 이르렀다.

게다가 Trello를 적극적으로 활용하지 않는 팀원들에겐 잔소리 폭격을 쏟아냈다. 기존의 구두로 진행되는 프로세스로 부터 가능한 빨리 분리시키고 싶었기 때문에, 모든 히스토리를 내가 알아야 하기 때문에 기존의 방식을 버리도록 더욱 강하게 요구 할 수 밖에 없었다.

그 당시 팀원들 기분은 위 짤과 같았을거라 생각이 든다. 노티 폭격에 잔소리 폭격… 버틴게 대단하고 고맙고 감사하다.

결국엔 사람이 문제

앞서 언급했듯 결국 태스크관리는 사람이 하는 일이다. 아무리 좋은 도구를 도입한들 사람이 활용하지 않으면 무용지물인것을 깨달았다. 그렇다면 사람과 환경을 바꿔야 하는데 내가 속한 조직이 그게 쉽지가 않다. 몇가지 이유를 나열하면

개발 조직의 관리자가 없다는 문제

개발 조직내 각 팀에 대한 관리자는 존재하나 개발조직 전체를 관리할 수 있는 관리자가 존재하지 않는다. 열심히 채용중이긴 하나 쉽지 않은것 같다.

결국 개발조직의 프로세스를 강력하게 밀고나갈 사람이 없다보니 프로젝트 관리 도구 도입에 대한 의견은 모아져도 이를 활용하는 것은 자율적으로 맡길수 밖에 없다.

자율적이라는 말은 바꿔말하면 해도 그만 안해도 그만이라는 말과 같아서 결국 후자로 귀결되는 문제가 있다. 안해도 피해 보는거 없잖아?

태스크 관리는 조직 전체가 나서야

결국 개발이란 다양한 팀들의 아이디어를 실현시키는 하는 작업이다. 그렇다면 태스크는 사실 그 아이디어, 다른말로는 기획단계에서 부터 관리되어야 한다는 것을 깨달았다.

개발 조직내에서 그동안의 기획과 디자인으로 일정과 계획을을 잡아놔도 추가기능 요구사항 이라던가 변경사항들에 대한 일감이 갑자기 하늘에서 뚝 떨어져버리니…물론 그들 입장에서는 갑자기는 아닐터이다. 다만, 협업 도구내에서 해당 태스크를 구경해본적이 없었기 때문에 갑자기라고 느낄수 밖에 없다. 아무튼 이렇게 갑자기 떨어진 일감에 기존 계획들은 전부 수정해야 하는 경험을 몇번 하였다 그러고 나니 개발조직 독자적으로 태스크 관리를 하는것이 의미가 있는건가 싶은 생각이 몇번 들었던거 같다.

결과적으로 뒤에 후술할 예정이지만 그래서 Trello에서 Redmine으로 갈아타게 된거 같다.

익숙함의 문제

앞서 언급했듯 그동안 히스토리 관리에 대한 니즈도 없었고 구두로 업무를 빠르게 진행하는것에 이미 익숙한지라 변화를 받아들이기 어려웠을것 같다.

갑자기 사람이 변하면 무슨일 있다는 말도 있듯 사람이란 동물 자체가 변화를 두려워 하고 익숙함에서 답을 찾는 동물같다.

게다가 비효율적이라고 생각하기도 할법하다. 구두로 이미 잘 진행되었다고 문제가 발생한적은 딱히 없었다. 그러니 업무 티켓을 발행하고 이 상태를 관리하며 남들에게 나 일 다했어요, 나 지금 문제있어요 라고 전파하는것이 상당한 비효율이라고 생각했을거 같다.

다만, 문제가 생기면 히스토리 관리가 안되었으니 어디서 부터 문제인지 파악은 힘들고 일단 당장 해결에 급급했던거 같다. 그것이 임시방편으로 땜빵을 쳐놓은건지 근본적인 해결인지는 중요하지 않았던거 같다. 어차피 히스토리가 없으니 나는 대충 무너진 댐에 구멍난거 감자하나 박아놓고 일단 물만 세지 않게 해놨다가 런하면 그건 뭐 남은 사람들 문제니까 라고 생각할수도 있을거다.

나는 이 히스토리 추적이 안되는 문제에 더 주목했었다. 그리고 특히, 재택근무 환경이면 더더욱 필요하다고 생각했다. 근데 결과적으로 그런거 없어도 엄청난 양의 원격회의를 통해 일이 돌아가긴 했고 익숙함을 벗어날 순 없었다.

미숙함의 문제

아무래도 조직에서는 프로젝트 관리도구를 사용한 경험이 없기 때문에 사용함에 있어 미숙함이 존재했다. 제일 큰 실패는 아무래도 태스크 관리라는 목적과 상반되게 개발 조직내 각 팀이 독자적인 워크스페이스를 갖고 움직였다.

이게 문제가 되는 부분은 결국 태스크 관리의 본질은 업무의 흐름을 파악해야 하는것인데 각자 워크스페이스에서 관리되다 보니 흐름을 파악하기가 힘들었다.

솔직히 느그팀일 알빠노? 마인드라면 타 팀 워크스페이스 구경조차 안할것이다 나를 포함해서 말이다. 그러다보니 현재 앞단에서 무슨 문제가 있는지 뒷단에서 무슨 문제가 있는지 서로 공유가 안되는 부분이 존재했고 쉽게 해결 가능한 문제도 빙빙 돌아가는 경우도 있었을것이다.

이 문제는 조직 전체로 확장되어 기획단계와 디자인 단계(이하 줄여서 기, 디)에도 해당하는데 앞서 언급한 조직 전체가 태스크 관리를 하지 않는 문제와 합쳐져 기, 디에서도 서로의 태스크가 공유된다면 그들이 고민하고 있는 문제들도 개발팀에서 가볍게 해결가능한 경우도 존재했을 것이다.

근데 솔직히 다 내가 돌리는 행복회로고 막상 도입하게 된다면 해결될지는 솔직히 의문이다.

결국 돌고 돌아 Redmine

일단 프로젝트 관리도구의 목적은 두가지로 나눌수 있었다.

1. 각 유관부서간 협업의 도구로써의 활용
2. 관리자로써 현재 팀의 업무를 파악하는 용도

일단 1번은 Trello로 사용의 결과로 일단 현 시점에서 도입하는것은 무리라고 판단됐다. 아직까지 내가 속한 조직은 이미 기존 방식을 못버리고 있었고 개발팀 단독으로 시작하는것도 큰 의미 없어보였다. 그리고 나 역시 조금 지쳐버린거 같다. 내가 뭐라고 다른 유관부서들이 기존에 일하고 있는 방식을 뒤흔들어놔… 그래서 일단 깔끔하게 포기했다.

그럼 이제 두번째 목적이 남아있는데 다행히도 내가 관리하고 있는 Backend 팀은 잔소리의 결과였는지 Trello에서의 티켓관리를 곧 잘 하고 있었다. 이미 한번 궤도에 올랐으니 그럼 두번째 목표라도 이뤄내야 겠다는 생각을 했던것 같다. 관리의 목적이라면 사실 내가 가장 잘쓰고 잘 아는 도구를 선정하는게 맞아보였다.

그래서 요즘 완전 Young하고 MZ한 Jira가 아닌 Old하고 Y한 Redmine을 선택했다. 물론 출시된지 오지게 오래된 화석과도 같은 도구지만 아직도 제법 규모가 있는 기업들이 사용하고 있다. 특히 일본 시장에서 점유율이 특히 높다. 그들의 갈라파고스 논란은 둘째치더라도 그래도 칸반보드를 창시한 토요타의 고향이다. 이쯤 되면 프로젝트 관리에 진심이라 볼수도 있지않을까?

아무튼 그 말인즉 대규모 프로젝트도 충분히 커버 가능하다는 것이다. 게다가 RDB로 데이터를 관리하기 때문에 원한다면 DB에 접근하여 데이터를 추출하여 이것저것 내가 원하는 기능을 직접 개발이 가능할것으로 보였다. 가장 결정적인건 직접 구축이 가능한 형태라 무료라는 점이 가장 큰 매리트였다. 이미 Trello로 실패를 맛봤는데 회사의 자금을 사용하면서까지 내 목표를 실행시키고 싶지 않았다.

그래서 지금은 어떤데?

일단은 Redmine에 팀이 무사히 안착한것으로 보인다. 쓰레기 같은 UI도 나름 Theme을 적용시켜 놔서 그런지 그닥 거부감은 없어 보인다.

아직까지 모든 유관부서가 사용하는 도구로써는 활용하지 못하고 있다. 이부분은 나도 포기했으니 패스하고

여전히 각자 자율에 맡긴다. 그래도 아직까지는 곧잘 관리하는 중이다. 가끔 주간업무나 월단위 업무를 정리할때면 관리를 포기한 티켓이 간혹 몇개 보이는데 내가 담당한 일감티켓도 있다. 나 역시 자율성을 부여해주니 신경쓰지 않게된 결과인것 같다. 이 부분은 결국 강제로 관리하는 방법을 도입할수 밖에 없겠지?

여기서 말하는 강제로 관리하는 방법은 나도 좀 거부감이 들어서 하기 싫었던 티켓 처리에 대한 부분을 평가에 반영하는 방법이 있을것이다. 근데 결국 강제성을 부여해야 실행에 옮기는게 또 인간의 습성인가 보다.

일단은 최대한 자율성 안에서 해결할 방법을 찾아보려 한다. 노티 지옥이 되기는 싫어서 앵간한 노티는 거의다 제거 했는데 일단은 모니터링 도구 부터 개발해볼 생각이다. 월단위 집계해서 각자 얼마나 티켓처리를 했는지, 완료기한에 임박한 티켓에 대해 리스트업 해서 Slack으로 쏴준다던가 이런식으로 일단 자율성 안에서 최대한 처리가 가능한지 확인해 볼 생각이다.

너 정말 커뮤니케이션 못한다.

내 의사소통 방식의 대해서도 개선의 필요성이 있다. 간혹 나는 당연하다고 생각하는 것을 질문한다거나 내 기준에서 말도 안되는 의견을 들으면 순간의 화 혹은 짜증을 참지못하고 맹견이 될때가 있는데 지금와서 생각해보니 지식의 저주가 걸린게 아닐까 생각한다. 이건 내가 올해 팀원들에게서 지적받은 부분이기도 해서 반드시 개발자로 롱런하기 위해서 고쳐야 하는 부분이기도 하다.

작년에 스마일게이트 홀딩스의 기술이사님에게 멘토링을 받은적이 있는데 이분께서도 개발팀에게 요구하신 부분이기도 하다. 제로베이스 부터 설명한다는 느낌으로 접근하라 대충 이런 말을 하셨던걸로 기억한다.

근데 그런 멘토링을 받고도 고쳐지지 않았던건 앞서 언급한 지식의 저주에 걸려버려 “당연히 이정도는 이해하겠지”라는 뿌리부터 박힌 고정관념 때문인것 같다 결국 중요한건 얼마나 쉽게 비유하고 누구나 알기 쉽도록 설명하는것이 아닌 내가 알고 있는 수준과 상대가 알고 있는 수준은 다르다는 것을 인지해야 한다. 나는 지금까지 이 부분이 부족했던거 같다.

추가적으로 해결해야 할 부분은 유관부서와의 의사소통의 문제이다. 이런 경험 이미 수많은 짤로 봐서 유머로써 넘겼는데 그게 내가 당사자가 되어버리니까 참으로 골치아픈 문제더라.

팀원중 하나가 회사만의 용어 사전을 만들자고 제안한 적이 있는데 좋은 아이디어 같아서 대표님에게 제안했고 슬슬 작업을 시작하는걸로 보인다. 다만 이게 앞서 프로젝트 관리도구 마냥 조직 전체가 사용하는거 같지는 않아서 이부분에 대해 조금 더 발전할 수 있는 방향이 있는지 고민할 필요는 있을것같다. 근데 이쯤 되면 내가 개발자인가 싶기도 하고 뭐 그렇다.

처음 겪어본 번아웃

리팩토링의 성공적인 출시 이후 12월 즈음엔 번아웃이 한번 온거 같다 이게 처음 겪어 보는 경험이라 이게 번아웃이 맞는건지 모르겠는데 아직 확신을 하지 못하는 이유는 보통 개발자의 번아웃이라 함은 코딩하다 쓰러지는걸 생각했는데 나는 특이하게도 관리자로써의 나와 개발자로써의 나를 분리하지 못하는 불안감에서 오는 부담감과 조직에 대한 회의감 때문에 온거 같다.

그리고 아직까지는 회복기인거 같다. 아직까지는 생각을 정리중이라 이부분에 대해서는 추후 생각이 정리되면 한번더 블로깅해야 할거 같다.

기타 소소한 이벤트들

MongoDB Day Seoul 2022

MongoDB Day에 참여했었다. 사실 코로나때문에 오프라인 컨퍼런스는 처음 참여하는것 같다. MongoDB를 막 도입해서 배울것도 많았고 흡연하며, 커피마시며, 밥먹으면서 주워 들었던 주변 개발자들의 아이디어들 에게서도 많은 영감을 받았다 온라인 컨퍼런스와는 다른 재미였다.

특히 Atlas Search는 안그래도 Elastic Search를 고민하고 있던 찰나에 매우 좋은 주제가 되었고 지금 사이드 프로젝트에 적용해보고 있는 중이다. 어차피 쓰고 있는 MongoDB에 검색용 인덱스 하나 붙여서 검색엔진을 만들수 있다니 이걸 어케 참누…

그리고 개발바닥의 향로님 실제로 뵈었는데 정말 멋진분이라 생각이 들었다. 저런 개발자가 되고 싶다. 근데 이분께서 이미 100만 조회수의 주인공이시라 너무 많은 사람들이 아마 이분 롤모델 삼을거같아서 개성은 조금 없어보이긴 하다.

박살난 건강

리팩토링을 진행하며 불규칙 적인 생활과 밤마다 음주코딩 조지며 잦은 음주와 야식을 먹던 습관이 결국 건강을 박살내고야 말았다. 체중도 엄청 불어났다.

불행인지 다행인지 원래도 한 체격하고 워낙 고무줄 체중이라 주변에서 “너 왤케 살쪘어?” 라는 걱정섞인 반응을 볼순 없었던거 같다. 근데 진짜 심각한건 간이 박살났다.

최근 건강검진 기록이다. 말이 나와서 말인데 혹시 건강검진을 계획하고 있다면 내가 속한 조직의 서비스 착한의사도 꼭 사용해보길 추천한다 최근에 검진비교 기능을 배포하여 쉽게 검진 상품을 비교하고 각종 검사들의 대한 친절한 설명으로 선택에 도움을 준다.

아무튼 각설하고 인간의 간수치를 아득히 벗어나 적잖히 충격을 받아버렸다. 이러다 40대에 요절할거 같아서 건강관리가 시급하다 느꼈다.

게다가 내 고질병인 수면장애로 인해 새벽 4시전엔 잠에 들지 못하는 습관도 이젠 고쳐야 겠다.

그외에는

사실 진짜 다사다난 했던 2022년이었다. 별의 별일이 다 있었는데 이거 다 정리했다가는 밤새도 모자를거 같아서 못푼 썰은 향후 블로깅에서 하나씩 꺼내볼 예정이다.

2023년에는?

• “아직 결혼식은 안올렸는데 저 결혼했어요” 라고 말하기 싫고 앞에 설명은 생략하고 “저 결혼했어요” 라고 말하고 싶어 올해는 결혼식을 올릴 예정이다. 이제 앞으로는 우리 부부가 왜 혼인신고만 하고 사는지 구구절절 설명하지 않아도 될거 같아서 기대중이다. 이때 모바일 청첩장 정도는 내손으로 만들고 싶다. 그러니 Frontend 스킬 하나는 장착 해야겠다.
• 건강관리가 진짜 시급하다. 웨딩스냅도 찍어야 할거고 그냥 내가 살아야겠다. 음주는 진짜 줄여야겠다. 그리고 식단관리를 해야한다. 운동도 하고는 싶은데 가능할지는 올해 스케쥴을 보고 결정해야겠다. 다행히 회고하는 동안 실내 마스크도 해제되어 신선한 공기 마시며 운동이 가능할거 같다. 일단은 식단관리, 절대금주, 그리고 새벽 4시전엔 짐대에 눕기 부터 실천해보자.
• 22년에 읽은 책이 진짜 0권이다. 이게 사실 22년도에는 책 5권은 읽자고 재작년에 다짐했는데 얼마전 대표님과 잡담을 나누다 계산해보니 진짜 0권이더라. 틈틈히 읽고 싶어서 구매한 책들은 책장 어디 처박혀서 한순간도 나오지 않았나 보다. 이럴땐 실현 가능한 목표를 잡아야 한다. 올해는 1권이라도 읽어보자
• 온보딩 프로세스가 시급하다. 그러기 위해 서버 아키텍쳐도 조금 손볼 필요가 있다. 나 포함 우리팀이 항상 있던 자리 그대로 있을수는 없다. 빠른 시일내로 온보딩 프로세스를 개발하여 FastAPI로의 소프트 랜딩을 이뤄내야 한다. 막말로 퇴사했는데 이전에 내가 개발해놓은 로직때문에 회사에서 연락오는거 받기는 누구나 싫자너?
• 코드 리뷰, 일감 관리, 데일리 스탠드업 미팅등 벌려놓고 제대로 관리 안되는 부분들이 조금 있다. 내 행복회로들의 결과물인데 인정할건 인정하고 팀에 맞는 개발문화로 다시 정착시켜야겠다.
• 근데 이와중에 하나 더 벌려놨다. 최근 Frontend 개발자 하나와 사이드 프로젝트 그룹을 하나 만들어 운영해볼 생각에 있다. 일단 행복회로만 돌려놓은 상태라 구체화 된게 하나도 없다. 단지 우리끼리 프로젝트 진행하면서 소통 및 개발물 관리가 안되어서 만든건데 일단은 현재 프로젝트가 어느정도 마무리 되고 같이 운영할 개발자와 뜻이 맞으면 확대해볼 생각이다.
• 사이드 프로젝트 말이 나와서 그런데 올해는 작년에 깔짝조차 못했던 사이드 프로젝트를 하나 둘 가동시킬 생각이다. 이미 가동중이기도 하고…
• 또한 개발이 인간의 삶에 도움이 되는 행위라는 것을 느껴보고 싶다. 최근에 Hitman이라는 게임을 즐겨봤는데 이 게임의 한글패치가 아직 미완성 상태이다. 개발자로 전향하기 전에는 그냥 한글패치 기다렸을텐데 이젠 바로 구글링 해서 이 게임 파일들을 언락하는 프로젝트를 발견했다. 파일 하나씩 까보다가 대사들을 포함한 파일을 발견했고 Json형태로 추출이 가능해서 미번역된 대사들을 Google 번역 API든 파파고 번역 API든 태워서 기계번역이라도 한다면 한글패치 오매불망 기다리던 겜돌이들에게 희망이 될수 있지 않을까 생각이 들었다. 근데 이것도 일단 23년도 계획을 보니 실현이 가능할지 모르겠다.
• 아직까지 번아웃에서 완전히 벗어난것이 아닌듯하다. 번아웃이라 불러야 하는지도 애매모호한데 뭐가 되었던 나를 위해, 롱런하기 위해 빠르게 벗어날 필요가 있는거 같다 다양한 방향으로 생각을 확장해볼 생각이다. 일단은 내가 하고 싶은 개발을 하며 슬슬 시동을 다시 거는중이다. 한동안은 개발이 질려버렸는데 역시 내가 원하는 개발을 하니 여전히 개발은 재미있다는건 알았다.
• 대략 6개월 정도 블로깅을 하지 않은듯 하다. 사실 블로그 자체를 그냥 메모장 용도로 쓰기도 했지만 블로깅의 기술적 필요성을 느끼지 못하기도 했다. 나는 사실 기술을 배우는것을 블로깅 하는것 보단 직접 들이박아보면서 이것저것 만져보면서 만들어 보면서 습득하는 타입이다. 그래서 블로깅도 자연스럽게 뜸해졌고 리팩토링 진행해야 해서 쓸 시간도 없었다. 그런데 이번 회고 같이 내 생각을 정리해보니 이제서야 블로깅 용도를 알 것 같다. 이제 2주에 최소 1개의 포스팅을 해 볼 생각이다. 그 첫 시작이 이번 회고라 오바해서 또 1년간 있었던 일 구구절절 적어 나가고 있다. 앞으로는 간단하게라도 꼭 블로깅 할 예정이다.
• 현재 사용하고 있는 블로그는 gatsby를 사용하여 배포해놓은 상태인다. 꼬꼬마때는 이게 간지인거 같았는데 그냥 티스토리나 벨로그같은 서비스 사용해야 내가 관리할 포인트가 하나 줄거 같다. 근데 딱히 또 관리할게 많지는 않아서… 이건 좀 더 고민해봐야 겠다.