Funes

올해 1월, 나는 어음 할인 웹 서비스를 제공하는 한국어음중개에 프론트엔드 개발자로 입사했다. 취업한 직후에는 내가 개발자로 월급을 받으면서 일을 한다는 사실이 어색하기만 하고 시간도 하루하루 더디게 갔는데, 정신을 차려 보니 순식간에 6개월이 흘러 있었다.

이제야 조금은 눈이 뜨인다는 느낌이다. 조직 내에서 좋은 평판을 유지하고 괜찮은 커뮤니케이션을 이어간다는 게 왜 중요한지, 왜 근무를 하면서 자기 학습을 지속한다는 게 어려운지 등등. 내가 직장 생활을 다른 직종으로도 해봤거나 이전에 다녀본 회사가 있더라면 더 깊은 비교를 할 수 있었을 테지만 우선은 첫 단추를 끼운다는 느낌으로 리뷰를 해 보겠다.

1. 코딩만 하라고 나를 채용한 게 아니다

요약: 시키는 업무만 하려 들지 말고, 의사결정 과정의 빈 자리를 능동적으로 채워나가려 애쓰자. 오더 내려서 아웃풋만 받을 거였으면 회사는 외주업체를 고용했을 것이다.

회사가 나를 채용한 이유는 단순했다. "JSP 기반 사이트를 Node 기반으로 리빌딩해주세요." 뭐 그렇군. 구현 자체는 품이 많이 들어갈지언정 작업을 진행하는 방식은 간단할 거라고 생각했다. 정말 단단히 착각한 셈이다. 이전까지 페이지 제작은 처음부터 끝까지 손수 하거나, 이미 만들어져 있는 사이트를 유지보수하는 프리랜서 작업만 해왔기 때문에 여기서도 엇비슷할 거라고 짐작해 버린 것이었다. 업무에 투입되기 전까지만 해도 나는 속으로 모든 작업이 순조롭게 끝난 뒤 팀원들에게 박수를 받는 그런 장면을 상상하고 있었다. 😂

진부하지만 역시 이것만한 비유가 없다

나는 몇 주만에 금세 깨우쳤다. 조직 업무에서 가장 어려운 건 UX/UI 설계도 아니요, 마이크로서비스를 서버리스 환경으로 구축하는 것도 아니요, 직원들 간의 의견을 맞추는 일이라는 걸... 복잡한 어른의 사정 이 끼어 있는 탓에 간단히 말하자면 디자인과 IT, 기획 사이에 극복하기 어려운 의견 차가 있었고, 그 차이가 조율되는 걸 기다리기만 해선 리빌딩 프로젝트는 시작도 못한 채 몇 달까지도 딜레이될지 모르는 상황이었다. 어떤 부분에서 의견 차가 있었나 하면... 먼저 디자인 팀은 이번 프로젝트가 단순히 룩 앤 필을 바꾸는 수준을 넘어서 전체 사이트 설계 구조나 페이지 별 시나리오를 정확히 설계하고, 개선된 내용을 문서화하면서 제작하기를 원했다. 예를 들면 GNB 메뉴에 연체 상품 소개 섹션을 올리고 단순 홍보성 섹션은 2depth 아래로 내린다든지, 회원가입 제한 연령대를 정확히 몇 세 미만으로 잡을 것인지 등의 이슈들이었다. 기술적으로는 어떤 식으로 구현해도 상관 없으나 회사의 입장에서는 민감할 수도 있는 내용들이었다. 특히 연체 상품의 추심 현황을 메인 메뉴로 끌어올리자는 아이디어는 논란이 많았다. 투자자들에게 운영 과정을 투명하게 공개하는 효과가 있다는 찬성 의견과 어음 할인 당사자의 프라이버시 침해라는 반대 의견이 부딪쳤다. 아무튼 디자인 팀이 주장한 바는 논란이 될 만한 기능을 추가하자는 게 아니라 이런 식으로 부딪쳐 보기라도 하면서 회사 차원에서 합의된 최소한의 무엇을 만들고, 그걸 기반으로 리빌딩을 시작하자는 것이었다. 이런 정책적 기반이 없으면 아무리 리빌딩을 거듭해도 사이트의 근본적인 개선은 이루어지지 않을 거라는 게 주장이었다.

반면 기획과 IT 쪽 의견은 그와 달랐다. 와이어프레임이나 정책 결정 사항을 모두 문서화하면 구현하는 입장에선 좋겠지만, 애초에 조직 내에서 정책을 최종적으로 "결정" 해주는 주체가 명확하지 않을 뿐더러 정책이란 계속해서 변하기 마련인데 그 문서를 한번 만들어낸다 해서 지속적으로 신뢰할 수 있는 내용으로 관리될지도 불투명하다는 것이었다. 거기에 CTO는 완전히 새로운 디자인으로 교체하는 것조차 불필요하지 않는가 하는 의견을 내기도 했다. 요컨대 새 기술 기반으로 이전하는 것에 추가로 디자인까지 변경하다는 건 개발 주기 한 사이클 안에서 구현할 볼륨이 아니라는 것이었다.

한창 이렇게 부딪치고 있을 때, 나는 뭘 했는가? "허스키 님은 어떻게 생각하세요?" 라고 디자이너 분이 물으셨을 때, 나는 잠만보 인형이라도 된 기분이었다. "아... 저는 뭘 해도 크게 리스크가 없을 거라서..." 우물쭈물한 게 전부.

속마음은 이랬음...

이 논쟁에서 누구 의견이 옳은가보다도 한 가지 교훈을 배울 수 있었다. (아직도 나는 양쪽 의견이 전부 옳다고 생각한다. 상황에 따라 덜 나쁜 방법이 있을 뿐이겠지) 조직에서는 모두가 보수적으로 움직인다. 나를 고용한 사람들조차. 아무것도 모르는 신입의 입장에서, 회사는 나를 어디에서 어떻게 일하게 할 것인지 모든 계획을 갖추고 있으리라 짐작했었다. 그러나 현실의 조직은 거대한 조별과제를 끌어안은 데면데면한 팀원들의 집합에 가까웠다. 직원을 배려하느라 그랬든 정말 계획이 없어서였든, 아니면 내 퍼포먼스를 지켜보려고 일부러 내버려 둔 것이든 회사는 각자의 업무를 소화하느라 바쁘고, 한정된 리소스를 쓸데없이 소모하지 않기 위해 최대한 자기에게 변화가 적을 방향으로 입장을 정한다. 그리고 각자의 입장에 맞추어 만들어지는 최소한의 합의가 가장 효과적이라고 보는 것이다. 차라리 자기가 계속 게으를 수 있는 '입장'을 고수하는 편도 회사 입장에선 손해가 아닌 것이, 그렇게 해서 최대치의 솔루션을 만들어낸다면 다른 직원의 리소스도 절감하는 효과를 낳을 수 있기 때문이다. 최악은 상급자의 지시를 기다리느라 자기 입장을 생각해두지 않는 경우다. 회사에 협조적이고 싶어서 그랬는지는 모르지만, 그건 자기 자신만 생각하는 발상이기도 하다. 조직은 현재 '내 자리'로 구체화된, 예를 들면 프론트엔드 개발자 포지션이 지금 위치에서 겪을 수 있는 문제점에 대한 정보를 필요로 한다. API 혹은 디자인이 공급되는 속도가 늦다든지, 기존 리소스에 대한 문서가 충분하지 않다든지 하는 점들 말이다. 그런 정보를 전달해야 조직은 자신의 프로세스를 개선할 수 있다(최소한 악화시키지 않을 수 있다). 따라서 나를 위해 이기적으로 생각하는 건 조직에 도움이 된다. 이 주장이 듣기 거북하다면 '나' 라는 주어를 '내 역할을 맡게 될 사람', 혹은 '내 포지션'으로 바꿔 불러도 좋다. 예컨대 "내 포지션에 놓인 사람이 일하기 좋은 환경이 갖춰지려면 무엇을 받아야 하는가" 하는 의견을 세워야 하고, 장기적인 과제가 다가왔을 땐 "어떤 식으로 일해야 내 포지션에게 가장 효과적일까" 하고 고민해야 하는 것이다.

이렇듯 조직원 하나하나의 역할이 클 수 밖에 없는 스타트업에서 인하우스 멤버란 단순 실무자 이상의 의미를 갖는다. 맡은 업무의 아웃풋만 내고 끝이 아니라 의사결정 과정과 조직 문화에 지속적으로 피드백을 내놓을 줄 알아야 한다.

리빌딩 프로젝트는 어떻게 되었는가? 의견이 좁혀지지 않은 투자자 영역은 개발을 시작하지 않고, 어음 할인 고객 영역을 페이지 단위 교체 방식으로 제작 중이다. 만일 누군가의 독단적인 지시로 억지로 개발이 시작되었다면? 월 대출액이 폭발적으로 늘어나기 시작한 현 시점에 프론트엔드가 어음 할인 환경 개선에 대응하지 못했을지도 모른다.

2. 입사해도 회사는 너를 모른다. 자기를 입증하는 건 본인의 몫

요약: 1번 주제의 연장. 메인 잡은 물론이고 업무 외적으로도 회사에 무엇이 필요한지 스스로 발견하려는 태도를 갖자.

"업무 디파인(define)을 스스로 하셔야 돼요." 면접 때부터 CTO님이 거듭 강조하셨던 말이었다. 처음엔 저 말의 진짜 뜻을 이해 못했다. 머릿속으로는 드라마 <미생>의 한석율이 공장에 내려가는 장면이 흘러가고 있었는데... 내가 영업이라도 하게 된다는 건가?

그게 무슨 뜻인지는 입사 첫 주에 분명하게 드러났다. "리뉴얼 프로젝트는 서버리스한 환경에서 가볍게 돌아가면 좋을 것 같아요." CTO님의 주문 사항은 이게 전부였다. 자바스크립트 프레임워크를 뭘로 잡을지, 클라이언트 사이드 / 서버 사이드 중 어떤 렌더링 방식을 택할지, 인스턴스는 어디에 어떤 식으로 띄울지, CI/CD 전략은 어떻게 할 것인지 등등 구체적인 지시는 아무것도 없었다. 불안해진 내가 이것저것 여쭤보자 CTO님은 눈치를 채셨는지 이렇게 말해주셨다. "저는 관리자이기 때문에, 실무 하시는 분들께 어떤 스택을 쓰라고 강요할 수는 없어요. 본인이 가장 잘할 수 있는 방식으로 하시는 게 좋죠. 다만 나중에... 설명을 할 수 있어야 돼요."

원하는 대로 구현하되, 설명할 수 있어야 한다. 아주 오싹한 한 마디였다. 여러 블로그에서 "스타트업에선 권한과 책임이 동시에 따라옵니다." 라는 식의 글을 읽었을 땐 아무렇지도 않았는데 직접 듣고 나니 가슴이 덜컹 내려앉는 듯했다. 그때부터 나름의 솔루션을 구축하기 위해 한 달 정도 고심을 거듭했다. 사내 VPC 구조를 익히고, 백엔드 서비스에 접근하는 법을 익힌 뒤엔 React 기반 서버 사이드 렌더링 앱을 제작했다. 서버 사이드 렌더링을 택한 이유는 SEO에 대응하기 위해서뿐만 아니라 웹앱 렌더링 용 Express 서버를 사내 API에 접근하기 위한 프록시 서버처럼 구성하기 위해서였다. React 클라이언트가 직접 API를 호출하면 보안에 취약하기 때문.

Express + Create-React-App 으로 구성된 웹앱을 컨테이너로 감싼 뒤에는 AWS ECS로 배포했다. ECS는 AWS가 제공하는 컨테이너 오케스트레이션 서비스인데, 여기서 Fargate라고 하는 서버리스 컨테이너 서비스를 이용할 수 있다. 사용자가 관리해야 하는 EC2가 아닌 AWS가 관리하는 마이크로 VM에 컨테이너를 실행시키는 것이다. Fargate로 배포된 인스턴스는 유저가 관리할 필요가 전혀 없다! 처음 설정할 때 vCPU와 메모리 설정만 해주면 끝이다. 그렇게 서버리스 환경을 세운 다음, CodeBuild와 CodePipeline을 이용해 CI/CD 환경을 만들었다. 미리 설정해 둔 브랜치에 push 명령이 실행되면, 파이프라인은 webhook을 통해 저장소를 클론 받아 컨테이너를 빌드하고 ECS 배포까지 자동으로 실행한다. 그리고 이 모든 AWS 리소스는 CloudFormation 템플릿을 제작해 만들었다.

이렇게 리뉴얼 프로젝트 환경을 다 세우고 나니 그제야 나도 회사 안에 어느 정도 스며들게 되었다는 기분을 느낄 수 있었다. 본격적인 사이트 개발은 시작도 안한 상태였지만 하하... CTO님은 내가 구현을 마친 이후에도 뭘 어떻게 만들었는지 꼬치꼬치 캐묻거나 하진 않으셨다. ("설명"은 퇴사할 때 하라는 말씀이었을까) 하지만 내가 주어진 과제를 나름의 방식으로 해결했다는 걸 알릴 때마다 새로운 갈 길을 보여주시는 걸로 봐서 구현 퀄리티는 실무진에 대한 신뢰로 가져가고, 본인은 IT 전체 태스크를 관리하는데 집중하겠다는 입장이신 것 같았다. 아무튼 별 말씀 없으셔도 내가 박자를 잘 맞춰가야 한다는 거겠지.

이런 식의 "신뢰"가 가능한 건 우리 회사 IT가 소규모이기 때문이다. (스타트업이 인력을 소규모로 유지하고 싶어 하는 이유이기도 하다) 인력이 적기 때문에 최대한 개발 이슈 이외의 장애 상황을 만들지 않으려 했고, 하나의 저장소는 한 명만 관리하는 관행이 굳어졌다. 자연스럽게 사내 리소스는 마이크로 서비스 형태로 갖춰지고 있다. 이런 환경에서는 개인의 자율성이 더더욱 부각될 수밖에 없다. 모든 인력이 하나의 스프린트 사이클로 개발하는 것도 아니니, 각자가 독자적으로 자기 일에 대응할 수 있어야 한다.

요약: 직장이 있지만 직장이 없는 것처럼 살자

아직 경력도 적고 여러 조직을 경험해 본 것도 아니어서 경험 많으신 분들이 이 글을 읽으면 갸우뚱하실지도 모르겠다. 아무튼 지금까지의 내 생각은 이렇다. 우리 조직이 무조건 좋다는 뜻은 아니다. 소수의 팀원이 자기 저장소만 붙잡고 일한다는 건 장기적으로 봤을 때 개인에게나 조직에게나 위험할 수도 있는 전략이다. 서로 코드를 공유하지 않게 되면 개개인이 조직에서 대체불가능한 존재가 되는 것도 문제고, 피드백이 없으니 개인적인 발전도 더딜 거라는 게 더 큰 문제다.

결론을 내리자면 조직 안에 들어갔다 하더라도 무작정 조직에 의존하지 말고, 마치 직장이 없는 것처럼 문제 해결 능력과 환경 적응 능력을 계속 갈고 닦아야 한다는 것이다. 그게 조직에 있을 때에도 모두에게 좋고, 조직을 떠나거나 옮기더라도 능력 있는 개발자로 바로서는 길이 될 것 같다. 이상!