https://blog.keizie.net/2024/06/another-postmortem.html
다니던 회사가 폐업으로 끝나고 나라가 주는 월급으로 2개월 정도를 지내다가 한 곳에 딱 한 달, 다른 곳에 두 달 좀 넘게 다니며 새해를 지나 연말정산까지 진행했다.
1. 해온 일
- 개발조직이 주가 아닌 업체 두 곳에서 개발조직을 자리잡게 하는 목표였다. 세부적으로는 도메인이 달라서 업무도 약간 달랐지만. 결과적으론 두 번 모두 실패했다. 세상엔 비기술 인력이 훨씬훨씬 많음을 새삼 느꼈다.
- 한 곳은 이미 있는 개발팀의 팀장이 개발문화에 발담은 적 없이 스스로 바닥부터 공부를 해서 코드를 짠 사람이라, 출근해보니 깃허브에 올라와 있지 않은 소스코드가 꽤 많은 상황이었고 팀원이 소스코드를 확인 못하고 업무지시만 받아서 작업을 했다고 한다. 회사에서는 공통된 팀 단위의 기록 공간이 없이 저마다 개인 노션을 만들고 몇몇 사람들만 공유를 해서 돌려보는 식이었다. 지난 작업들이 있다고는 하는데 코드도 문서도 볼 수 없는 상황을 해소하느라 시간을 꽤 썼다. 무엇보다 놀란 건 메일이 구글 워크스페이스가 아니라 생전 처음 들어보는 메일 포함 사무 서비스 몇 가지를 제공하는 업체였다는 것이다. 특히 메일은 '구글 로그인' 기능이 있는 곳을 회사 구글 계정으로 바로 쓸 수 없다는 점이 너무나도 불편했고 어색했다.
- 다음 곳은 상주 개발팀장이 없이 한동안 신입 개발자만 뽑아서 사장이 직접 이것저것 요구사항을 전달하고 쪼아가며 일을 하다가 사장 지인을 리모트 팀장역으로 뒀다가 이번에 처음 상주 팀장이 들어앉은 거였다. 공동대표 체제이기도 했는데 예전에 다른 회사에서 잠깐 맛봤던 것처럼 이번에도 좋은 결과는 아니었다. 업무 지시가 구두로 들어오고 시시각각 새로 쌓이거나 바뀌는 게 너무나도 큰 문제였는데 이걸 어떻게든 개선하려고 시도했지만 최상위에서 업무를 발생시키는 사장이 끊임없이 외부 영업을 도느라 내부에 시간을 할애하기 힘든 상황이 바뀌지 않는 한 업무지시가 짧고 단편적이고 부정확할 수 밖에 없음을 절감했다. 몇 번의 퇴사 면접 때 여러 차례 이 점을 얘기했는데 얼마나 전달이 됐을지는 모르겠다.
- 주니어 교육을 좀 더 진지하게 생각하게 되었다. 두 번째 회사가 팀장 없이 '방치된' 기간이 길다 보니 에러가 났는데 무슨 에러인지 확인하지도 않고 아무 코드나 의심되는 부분을 냅다 고치려고 한다든지, 기본적인 기술 용어는 들어본 적도 없이 그저 결과물이 나오도록 프레임워크 영역 안에서 부품 코드만 짜넣는다든지 하는 모습을 보았다. 물론 초년차가 뭐 대단한 바탕이 없는 게 당연한 거지만 당장 눈에 보이는 것 이상의 뭔가가 있다는 걸 생각조차 하지 못하는 게 너무나도 안타까웠다. 기회가 될 때마다 어떤 기술이 현재에 이르기까지 어떤 연원이 있었는지, 연관되는 키워드들은 뭔지를 설명해주고자 애썼다. 나로서는 드물게도 주말 오전에 시간을 내어 강사 노릇을 하려고도 했지만 이건 몇 번 못하고 끝나버려 아쉽다.
- 하나의 주제를 잡아 직접 해결하기보다는 전반적으로 뭐가 문제인지 확인까지만 하고 저연차가 이해할 수 있는 수준으로 설명하고 어디를 어떻게 손대라고 지시하는 전처리 단계 주로 진행했던 것 같다. 그럴 수 밖에 없는 여건이었던 게 가장 큰 이유고, 주니어의 성장에도 이 편이 유리하다고 생각했다. 예전 회사의 돌파력 있던 팀원들이 아쉽기는 했지만.
2. 다뤄본 것
- 두 회사 모두 비용은 덜 들이면서 적절한 시스템을 구성한다는 목표는 비슷했다. 한 쪽은 이미 다들 노션을 편하게 쓰고 있던 터라 노션을 팀 단위로 바꾸면서 돈을 썼다. 지라에 해당하는 건 슬랙의 리스트 기능부터 깃허브 이슈까지 다양하게 검토했지만 뚜렷하게 결론을 못 냈던 걸로 기억한다. 다른 쪽은 개인들은 노션을 쓰고 있었지만 회사로는 활발하지 않아도 지라와 컨플루언스를 이미 도입해둔 상황이어서 무료 10명 선에서 유지하며 유료로 넘기지 않기 위해 노력했다. (한번은 어쩌다 11명째 가입자가 생긴 상태로 시험판 기간이 지나서 갑자기 사용이 제한되는 바람에 얼른 10명으로 다시 맞추고 기술지원을 요청해서 되살린 적도 있었다)
- EC2 안에 docker로 떠 있는 구조를 ECS Fargate로 바꾸고 AWS X-Ray도 붙이는 작업을 했다. 비용 절감을 위해서였는데 다음달 비용이 나오는 걸 확인 못해서 결과를 못 본 게 아쉽다. ECS 전환 자체보다는 ECR+ECS 기반으로 Github Actions 자동 배포 스크립트를 짜고 슬랙에 결과를 보여주는 구성을 하는 게 더 오래 걸렸다. Self-hosted Runner를 도입했으면 좀 더 간단해졌을 것 같기도 한데 다음에 기회가 닿으면 시도해봐야겠다.
- https://tailscale.com/kb/1019/subnets Tailscale로 서브넷 라우터를 실제로 구성해봤다. 그동안은 매번 ssh 터널을 구성했는데 이번엔 그렇게 각자 터널을 다 세팅하게 만들도록 ssh 터널링의 개념을 설명하고 교육하는 것조차 부담으로 느껴져서 Tailscale 앱만 깔게 하면 이게 차라리 쉽다고 생각하고 시작했다. 하지만 의외로 윈도우 환경에서는 Tailscale이 뭔가 보안 앱의 검출에 걸려서 동작하지 못하는 상황이 생겼다.
- 그동안은 백엔드 위주로 일을 하다보니 React와 Next.js라는 요즘의 프론트엔드 기술을 접할 일이 잘 없었는데 이번에는 백엔드도 프론트엔드도 기존 팀원들이 현황을 만족스럽게 설명해주거나 버그가 있는 부분이 정확히 뭔지 파악하기 힘들다 보니 자연스럽게 프론트엔드의 고질적인 문제라고 하는 부분을 내가 직접 확인하고 해결해야 했다. 이 과정에서 그럭저럭 React의 컴포넌트 구조와 Next.js의 라우팅 방식 등에 익숙해질 수 있었다.
- 비슷한 시기에 개인적으로 접했던 linkwarden, hoarder가 모두 Next.js 기반으로 어느 정도 백엔드스러운 기능까지 구현하고 있어서 꼭 Nest.js를 써야 백엔드고 Next.js는 백엔드가 아니라는 식의 선입견을 깰 수 있었다.
- v0.dev와 bolt.new, Github Copilot Workspace 등 내가 잘 모르면서도 어렵지 않게 프론트엔드 코드를 얻을 수 있는 수단이 생긴 것도 큰 도움이 되었다. 개인 프로젝트를 진행할 때 눈에 보이는 뭔가를 만들어내는 게 늘 걸렸는데 이제는 혼자 풀스택을 다루는 게 정말 멀지 않다는 걸 체감했다.
- 우연찮게도 구글에서 라이센스 제안을 받아서, 구글 Looker 플랫폼 라이센스를 받을 수 있었다. 찾아보니 예전의 Data Studio가 Looker Studio가 됐다는 식이어서 예전 기억으로 가볍게 생각했었는데 실은 Looker라는 별개의 서비스를 사들이면서 브랜딩만 맞춘 거지 예전 Data Studio와는 전혀 다른 거라고 했다. BI를 위해 인력으로 매주 자료를 쌓는 걸 어떻게 자동화할 수 있는지 개발팀에 설명하고 회사에 도입할 수 있게 되어 기뻤다. 어쩌다 보니 도입 완료까지는 못 봤지만 인수인계한 내용 정도는 지금의 팀원들도 충분히 소화할 수 있으리라 기대한다. 나중에 어떻게 됐는지 물어봐야지.
3. 다뤘어야 하는 것
- 단연코 2025년 현재는 AI의 하이프가 한 번 더 도약하는 시기다. ChatGPT라는 걸출한 서비스가 자리잡으면서 AI가 학자스러운 세계의 모델 경쟁만이 아니라 이미 존재하는 주요 클라우드 서비스 제공자들의 응용 기능들을 어떻게 가져다 쓰느냐가 업무의 판세를 엎을 수 있는 환경이 되었다.
- 이미지의 분석, OCR, 객체 인식, TTS, STT, 영상 분석 등을 해야 하는 회사들이었다. 팀 환경부터 만들어야 하는 상황이 아니었다면 이런 기술적인 경험들을 하고 내가 원했던 결과물을 이끌어낼 수도 있었을 텐데 기술적인 부분에 충분한 시간을 쏟지 못해 아쉽다.
4. 다루고 싶은 것
- 기술 위주가 아닌 회사여서 더더욱이나 개발팀이 뭘 하는지 조직 외부에 회사 전체에 잘 알릴 수단이 필요했다. 내 나름대로는 개발팀이야말로 커밋 로그도 남고 논의 문서나 설계나 각종 흔적들이 남는다고 생각해 너무나도 투명하게 일의 자취가 드러난다고 생각하지만 그것도 한발짝 떨어져서 기술에 익숙하지 않은 사람들에게는 먼나라 이야기가 된다. 지라에 이슈를 등록하라는 것도 누군가에게는 장벽이 되고, 어떤 작업이 지라에는 완료로 되어있는데 왜 내 눈에는 달라진 게 없는지 의아해한다. 글자 몇 개 바꾸고 숫자 두어개 바꾸면 될 것 같은 일이 왜 내일모레에 결과로 나오지 않는지 믿을 수 없어 한다. 이런 간극을 해소할 방법이 필요하다고 절실히 느꼈다. 개발 경력이란 걸로 이만큼 연차가 쌓였음에도 똑부러지는 답을 내지 못했다. 누군가는 두 번의 회사에서 실패했다고 말할 수도 있겠다. 릴리즈 노트를 내는 것과는 차원이 다른 문제임은 나도 절감했다. 어떻게 하면 좋을지 아직도 만족스러운 결론을 내지 못했다.
