들어가며

어느덧 개발자라는 이름을 달게 된지도 1년이 되어가고 있다. 그동안 정말 많은 일이 있었고, 지금 생각해보면 이렇게 무모할 수 있었나 싶은 일들도, 다시는 겪고 싶지 않은 일들도, 목표를 달성하고 눈물날만큼 행복했던 순간도 있었다. 여전히 실력이 부족하지만 조금 머리가 컸다고 개발자로서 성장해 나가야 할 방향성, 긍정적인 조직 문화에 대한 나만의 기준이 생기기 시작했다. 그리고 자연스럽게 형성되는 이 기준들이 싫지 않다.

맨땅에서 맨땅으로, 1년 간 두 회사를 경험했고 두 회사 모두 유일한 프론트엔드 개발자로 입사했다. 누군가는 개발을 배운지 고작 3개월 밖에 안된 사람이 그게 가능하냐고, 입사는 고사하고 그 환경에서 좋은 성장이 가능하냐고 묻겠지만, 가능하게 하고싶었다. 그리고 할 수 있을 것만 같았다.

첫번째 회사에 최종 합격한 뒤, 한 멘토님께 이와 관련한 질문을 드린 적이 있었다. 멘토님의 대답은 “한번 해보시는걸 추천드려요. 돌아가는 길일 수 있지만 얻는 것은 분명 있을 거예요.”였다. “돌아가는 길”과 “얻는 것”. 그때는 몰랐지만 지금은 알게된 무엇이다. 이 글에서는 그 결론에 도달하게된 지난 1년 간의 과정을 회고해보려고 한다.

첫번째 맨땅

3개월만에 개발자 되다

운이 좋았다고 밖에 설명할 길이 없다. 3개월의 부트캠프 과정 중 마지막 한달을 가치소비 플랫폼 스타트업에서 인턴으로 보냈다. 이제 막 광고 에이전시에서 가치소비 플랫폼 스타트업으로 전환해 프로젝트 초읽기에 들어간 회사였고, 놀랍게도 내가 첫 정규직 개발자였다! 인턴 기간에 며칠을 자정이 넘어서까지 회사에 머물며 만든 프로토타입으로 회사는 Pre-A 시리즈 투자를 받게 되었고, 부족한 것도 너무나 많았지만 그때 당시에는 정말 짜릿했던 경험이었다.

빈수레가 요란했다. 마치 학부생이 몇 과목 학점 잘나왔다고 이제 전공은 좀 안다고 생각하듯, 그땐 어떤 문제 상황이든 기술적으로 해결할 수 있을 것 같았다. 하지만 필연적인 한계가 나를 기다리고 있었다. 비전공자에 3개월 개발을 배웠고, JavaScript나 CS에 대한 깊은 지식도 없이 이제 막 React를 조금 만져봤던 내가, 프로토타입이 아닌 프로덕트 레벨의 구현을 온전히 혼자 맡는다는 것은 여간 어려운 일이 아니었다.

특히 기억나는 실패의 경험은 결제 기능 개발이었다. 아임포트 결제 연동 API를 이용해 모바일 웹에서 결제 기능을 구현해야했다. 문제는 리디렉션이었는데, 회사에서 사용하는 PG사는 콜백함수가 아닌 리디렉션 url을 따로 설정해줘야 했다. 대부분의 경우 리디렉션이 가능했지만, 특정 인앱 브라우저는 url scheme이 제공되지 않았고, 리디렉션이 불가능하다는 결론에 다다랐다. 약 일주일 간 그 문제를 해결하기 위해 머리를 싸맸지만 결국 실패로 돌아갔다. 그때쯤 다행히(?) 회사에서는 결제 서비스가 필요없는 가치소비 커뮤니티 서비스로 프로젝트의 방향성을 돌려서 실패의 책임을 면할 수 있었다.😭

절망의 계곡으로 빠지다

이후 여러 해결하기 힘든 문제들에 직면했고, 어떤 문제는 겨우 해결하기도, 어떤 문제는 실패를 하기도 했다. 그 과정이 반복되면 반복될수록 자신감이 떨어져만 갔다. 더닝 크루거의 절망의 계곡으로 빠지는 기분이었다.

이대로는 안되겠다 싶었다. 매일 아침 1시간씩 일찍 나와 공부를 하기 시작했고, 현재 쓰고있는 기술부터 제대로 파악하자는 생각에 JavaScript, React에 대해서 스스로 공부를 해나갔다. 나중에는 알고리즘도 조금씩 건드려보고 즐겨보던 개발자 유튜버가 클린 코드 책 스터디를 열었길래 참여도 했다. 그렇게 깨달음의 비탈길을 올라가기 위해 홀로 안간힘을 썼다.

개발자 3명, 경력 합계 3개월

입사 한달이 됐을 때 프론트엔드 1명, 두달이 되었을 때 백엔드 1명이 추가로 채용됐다. 다름 아닌 같은 부트캠프의 바로 밑기수 분들이었다. 나와 똑같은 루트로 한 달 간 인턴 과정을 거쳐 정규직으로 채용되었다. 그렇게 개발팀은 개발자 3명, 총 경력 3개월이라는 놀라운 수치를 경험하게 되었다. 그래도 하나보단 둘, 둘보단 셋이라고 했던가, 서로 으쌰으쌰하면서 매 주 있는 스프린트의 늪에서 버텨가기 시작했다.

하지만 핵심 유저를 찾기 위해 몇 개월 간 지속한 일주일 단위의 스프린트는 업무 강도가 너무 높았고, 반복적인 기능 개발만 계속 하기에도 시간이 매번 부족했다. 좋은 코드를 쓰고 싶다는 욕구, 팀원들과 함께 기술적인 논의를 하며 팀으로 함께 성장하고 싶은 욕구가 점점 강해졌지만 각자 맡은 feature의 기능 개발만 하기에도 바빴기에 충분히 논의할 시간도 없이 “일단 되게 개발하는” 환경에서 이러한 갈증은 점점 더 커져갔다.

그러던 중 여러가지 이유로 같이 일하던 팀원들이 이직 소식을 알렸다. 팀원분들이 이직을 결심한 분명한 이유가 있었고, 나도 그 이유를 같이 느끼고 있었다. 무엇보다 팀원들이 빠져나가고 다시 혼자 개발을 하게될 상황이 썩 긍정적이지는 않았다.

게다가 “팀”으로 일하고 싶은 이유는 단순히 내가 하는 일을 분배해서 책임감을 덜고 싶은 마음 때문은 아니었다. 그보다 “내가 잘 성장하고 있는 게 맞을까?”에 대한 두려움 때문이었다고 보는 게 맞을 것 같다. 여전히 내 주변에는 개발과는 전혀 관련없는 직종의 사람들이 대부분이었기에 회사에서 이런 논의들을 함께하고 싶었다. 하지만 당시 환경에서는 근본적으로 이 부분을 해소할 수 없다고 생각했고, 그렇게 퇴사를 결정하게 되었다.

두번째 맨땅

이직 준비 2개월의 마침표

막상 처음으로 이직 준비라는 것을 하다보니 채워야 할 것들이 한 두가지가 아니었다. JavaScript에 대한 심화 학습이 필요했고, TypeScript도 학습해야했다. 매일 알고리즘을 풀었고 테스팅 도구의 학습도 병행했다. 그 와중에 프론트엔드 면접 100제와 같은 면접 질문들도 학습을 하면서 이력서, 포트폴리오도 다듬어야 했다. 매일 10시간 이상을 투자하며 부족한 곳곳을 채워나가면서 동시에 리스트업 해둔 회사에 차례로 지원하기 시작했다.

두 달 간 20개 가까운 회사에 지원했지만 성적표는 초라했다. 17개의 서류 탈락과 2개의 최종 면접 불합격. 하지만 실패도 경험이었는지 스스로 보완할 점들을 보완하며 오히려 할 수 있겠다는 자신감이 점점 커져갔다. 딱 그런 마음이 들 때 즈음 드디어 2개의 최종합격을 하게 되었고, 그 중 한 회사에 최종 입사결정을 하게되었다.

최종 입사결정을 한 이유는 이전 회사의 퇴사 이유와 맞물려있었다. 훌륭한 실력을 가진 프론트엔드 개발자 한 분과 백엔드 개발자 한 분이 계셨다. 면접 당시 코드 리뷰 문화와 개발자의 성장에 대한 이야기가 오갔고, 여러 가치관이 맞는다는 경험을 했다. 또한 이곳에서 제공하는 영어 화상 교육 서비스라는 도메인도 도전해 볼만한 매력을 가졌다고 생각했다. 결론적으로 이곳에서 기술적으로 좋은 성장을 할 수 있다는 생각을 했다.

예상하지 못한 것들

입사 후 맡은 업무는 3개월 간 아임웹 기반으로 작성된 서비스를 완전한 자체 서비스로 이전하는 것이었다. 프론트엔드 개발자 분이 퇴사를 하셔서 또 다시 홀로 프론트엔드 개발을 맡게된 상황이 왔다. 하지만 빠르게 인원 충원을 해주겠다는 약속을 받았기도 했고, 자체 서비스 확장에 처음부터 기여하면서 원하는 기술들을 접목할 수 있겠다는 생각 + 인원 충원이 되면 생각하던 개발 문화들을 하나 둘 접목시킬 생각에 나쁘지 않았던 것 같다.

내가 미처 생각하지 못했던 문제는 인원 충원이 생각보다 늦어질 수 있었다는 점, 이전될 자체 서비스는 내가 생각했던 MVP(Minimum Viable Product)가 아니라 모든 것이 갖춰진 완벽한 수준의 프로덕트였다는 점, 그리고 비즈니스 문제라는 이유로 일정 조율의 여지가 거의 없을 수 있다는 점이었다. 그렇게 두번째 맨땅에 발을 딛게 되었다.

프론트엔드 파트에 대해 아는 사람이 없었기에 모든 것은 “내가 알아서” 해야했다. 그래서 입사 2주 차, 주어진 요구 사항의 파악부터 하기 시작했다. 요구 사항과 리소스를 정리해보니 다음과 같았다.

• 프로젝트 기간 3개월
• 유저 타입에 따른 4가지 feature
• 데스크탑 웹 / 모바일 웹 / ios, android 웹뷰 총 3가지 환경
• 프론트엔드 1명, 파트타임 백엔드 1명, 디자이너 1명

주어진 환경에 최선 다하기

예상은 어느정도 했지만 막상 정리하고보니 도저히 가능한 지점이 안보였다. 하지만 나 또한 누구보다 프로덕트를 완료하고 싶은 욕심이 있었고, 잘 해내고 싶었다. 그래서 일이 되게 하려면 개선이 필요하다고 생각했다. 크게 3가지였고, 다음과 같았다.

1. 현재 요구되는 풀패키지 기획안이 아닌 “정말 필요한 기능들만 있는” MVP의 기획안으로 수정
2. 프론트엔드 파트에서 최대한 업무량을 줄여줄 수 있는 라이브러리들 적극 도입
3. 구성원 모두가 같은 목표를 달성할 수 있도록 1~2주 단위의 스프린트를 도입해 목표를 세분화하고 장기 목표를 달성하기 위한 단기 목표를 구성원들과 함께 논의 및 합의

가장 먼저 할 수 있는 것은 프론트엔드 파트의 프로젝트 세팅이었다. 가장 주요하게 생각한 것은 “퍼블리싱 업무의 최소화”였다. 개발할 페이지 수 자체가 너무 많았기 때문이다. 그래서 여러 CSS 라이브러리 중 tailwindcss 를 선택했다. 며칠 간만 문법을 익히면 일관된 디자인을 제공할 수 있고, 특히 반응형을 간단하게 적용할 수 있었기 때문이다. 이 선택은 유효했다. 문법을 익히기 시작하자 체감되는 퍼블리싱 업무 소요 시간이 현저하게 줄어들었으며 실제 선생님 feature 개발 시 반응형 업무를 예상 시간보다 절반을 줄여주었다.

이 밖에도 클라이언트 전역 state와 서버 state를 분리해서 관리하기 위한 Recoil + React Query, TypeScript, Next.js 등의 필요한 프레임워크, 라이브러리와 react-hook-form, dayjs 등 안정성은 유지하면서 업무 시간은 획기적으로 단축할 수 있는 라이브러리들을 적용하였다.

하지만 이것은 근본적인 해결책은 아니었다. 공동의 목표를 달성하기 위한 팀으로써의 논의가 가장 필요했다. 1, 3번 문제가 이에 해당됐다. 이와 관련해 팀원들을 설득하기 시작했다. 해당 문제를 논의하기 위한 4~5차례의 미팅을 요청했다. 현재 프로젝트가 불가능한 이유를 사례와 대안을 들어 설명하고, 되게 하기 위해 어떤 것들이 필요한지 문서를 작성해서 팀원들에게 공유하기도 했다. 수시로 다양한 근거를 바탕으로 의견을 피력하기도 했다. 나와 같은 의견을 가진 팀원도 있었고, 그렇지 않은 팀원도 있었지만 결과는 실패였다. 주요 골자는 “비즈니스 문제”였다

모바일 웹과 웹앱을 포기하자니 아임웹으로 제공되고 있는 모바일 웹, 앱 서비스를 포기하는 리스크를 감내해야했고, 기간을 늘리자니 시즌으로 수익이 결정되는 서비스 특성상 여름 방학 시즌을 놓칠 수 없었다. 인원을 늘리자니 예산 문제 때문에 불가능했고, 기획안을 줄이자니 현재 제공되는 서비스는 그대로 유지해야했다. 무엇 하나 놓치기 싫은 상황에서 내가 설득할 수 있는 여지는 더 이상 없다는 판단이 들었다.

그리고 이 과정은 여전히 진행 중이다. 소폭의 진전은 있지만 여전히 큰 변화는 없다. 아니 어쩌면 있을 수 없다는 표현이 맞을지도 모르겠다. 생각해보면 나는 이 조직에 들어온 지 2달 밖에 안된 신입이고, 내 뚜렷한 주장이 기존 조직원들에겐 당황스러울 수 있으니까. 나에게는 넌센스한 상황이 반복되면서 동기 부여를 잃은 것도, 처음 생각했던 “기술적으로 성장하는 조직, 팀으로 함께 성장하는 조직”을 만드는 것도 당장은 포기하게 된 것도 맞지만 지금은 내 선택에 책임을 지고 최선을 다하고 싶다는 생각을 하고 있다.

돌아가는 길에서 얻은 작고 소중한 것들

1년 간 수 많은 곁길을 돌아왔다. 아직 목적지에 다다르기 전이기만 어느 길이 나에게 맞는 길인지는 이제 조금 보인다. 그리고 그 길을 향해 피치를 올리며 달려가고 있다고 느낀다. 곁길에서 얻은 무엇들은 당장의 실효성이 없을 수 있다. 하지만 분명한 족적이 있는 이상 지금은 체감하지 못하지만 명료하게 존재하는 성장도 있을 거라고 생각한다. 이것들은 미래의 내가 잘 포장된 도로를 걷다가 곁길을 통하지 않으면 방법이 없을 때, “아, 그때 이런 방법이 있었지.” 하며 떠오를 수 있을 무언가일 것이다. 그렇게 몸소 생채기를 겪으며 얻어낸 나만의 그 어떤 기준들을 몇가지 정리해보았다.

같이의 가치

한때 “혼자서도 할 수 있지”라는 다소 오만한 생각을 한 적이 있었다. 어떤 문제가 발생했을 때 부딪히고 깨지며 해낼 수는 있다. 어떻게든 방법은 있을 것이다. 하지만 혼자가면 빠르게 갈 수 있지만 같이 가면 멀리갈 수 있다는 말이 있듯이 빠르게 가기 때문에 놓치는 것들은 혼자서는 얻어낼 수 없는 무엇들이다.

개발자로 시각을 좁혀보면, 내가 생각한 방식이 아닌 다른 방식으로 문제를 풀어나가는 동료들을 보며 서로에게 자극과 배움을 주고 받는 역할을 할 수가 있다. 가볍거나 깊은 기술적인 논의를 하면서 공동의 문제를 풀고자 함께 노력할 땐, 그 자체만으로 혼자 머릿 속으로 끙끙대며 고민하는 것과는 결이 다른 기술적 성장을 가져다 줄 것이라 본다. 서로의 코드를 리뷰해주는 조직이라면 내가 미처 생각 못한 부분을 피드백받고 동료가 놓친 부분을 피드백 해주며 팀으로 함께 성장할수도 있다. 나열해보니 너무 이상적인 조직인가? 라는 반문이 들긴 하지만 “그런 조직만 가겠다”가 아니라 “내가 속한 조직을 능동적으로 그렇게 만들어보자”라는 측면으로 접근하면 모든 기준들이 충족될 필요는 없다.

조금 더 철학적인 측면에서는, 이러한 일련의 커뮤니케이션 과정을 체득하면서 사회적으로 성장한 개인을 얻을 수 있다는 것이다. 같은 프론트엔드 개발자, 다른 직군의 개발자, 디자이너, 기획자 등 공동의 목표를 가짐과 동시에 조금씩 다른 이해관계를 가지고 있는, 각자 다른 접근 방법을 가진 사람들과 의견을 조율하고 양보하고 때론 강하게 주장하면서 원하는 것을 얻어낼 때에는 되려 자신을 돌아보게 되는 경험을 많이 하게 된다. 내가 특정 부분에 기분이 나빴다면 나의 언어는 다른 이에게 기분이 나쁘진 않았을지 생각하며 조금 신경을 쓴다거나 내 주장을 강하게 해야할 필요가 있다면 너무 날카롭지 않으면서 상대방이 이해할 수 있는 합리적인 이유와 근거를 생각하고 준비한다거나 같은 것들이다.

특히 프론트엔드 개발자는 같이의 가치가 더욱 필요하지 않을까 싶다. 유저와 가장 직접적으로 맞닿는 제품의 인터페이스 개발을 주로 담당하기 때문이다. 이 과정에서 백엔드 개발자와는 물론이고 디자이너, 기획자와 같은 타 직군 팀원들과도 다수의 커뮤니케이션이 필연적으로 존재한다. 그래서 더욱 “커뮤니케이션 능력”의 중요성을 체감하며, 또 나는 어떻게 더 이 능력을 확대할 수 있을까도 함께 고민되어야 할 영역이다.

Best Practice

무작정 기능 개발을 할 때에는 몰랐지만 이제는 내가 지금 이 기술을 Best Practice로 사용하고 있는 게 맞을까? 라는 생각을 하게 된다. 물론 항상 100% 완벽한 코드가 되어야 하는 것도 아니며 상황에 따라 적절한 Best Practice는 모두 다르다. 때론 우선 되는 코드를 만들어내는 것이 가장 중요한 역량이 될 때도 있다. 하지만 Best Pracrice를 알면서 그렇게 하는 것과 모르고 그렇게 하는 것은 상쇄 불가능한 현격한 차이가 있다.

그런 의미에서 지금의 나는 찍먹 정도한 기술을 마치 잘 아는 듯이 뿜어내고 분출하는 것이 아니라 외부의 좋은 사례를 스펀지처럼 학습하고 어떻게 하면 더 좋은 코드가 되는걸까를 스스로도 고민하는 방식의 접근을 하는 게 중요하지 않나라는 생각을 한다. (다시 한번 언급하지만 모든 코드를 그렇게 짠다는 것이 아니다!). 그러한 환경 속에 내가 존재하고 스스로 설정한 방향성을 가지고 노력할 때 적어도 나에게는 가장 효율적이고 커다란 성장을 경험할 수 있다고 생각한다.

유저 중심의 사고

하나의 프로덕트를 개발하는 모든 과정은 일을 위한 일이 아닌 유저를 위한 일이 되어야 한다. 수동적인 자세로 내게 주어진 일만 한다는 사고를 하게 되면 일을 위한 일이 되게 십상이다. 아니다. 능동적이고 적극적으로 정말 유저를 위한 것이 무엇인지 고민하면서 접근한다고 해도, 틈만 나면 일 그 자체에 매몰되어 버리기 너무 쉽다. 구조 자체가 그렇다. 많은 업무량에 치이거나 팀 내에서 이견이 있을 때 그 의견들까지 조율해가면서 주어진 일을 병행하기란 쉽지 않다. 마치 다이어트를 할 때면 죽어도 빠지지 않는 살이 조금만 먹어도 날 놀리기라도 하듯 쉽게 쪄버리는 것처럼.

그래서 계속 개인이 계속 의식하고 신경쓰는 것보다 환경 자체를 “유저 중심의 사고일 수 밖에 없는 환경”을 만드는 게 핵심이라고 생각한다. 그리고 그 중심에는 “데이터”가 있다. 모든 팀이 데이터를 바탕으로 논리를 펴고, 의사결정을 하며, 커뮤니케이션을 하는 것 만큼 강력한 유저 중심의 팀이 없다고 생각한다. 물론.. “어떻게”가 중요한 것 같다. 어떻게 활용하느냐에 따라 같은 데이터도 유저의 니즈를 송곳처럼 날카롭게 파악하는 결론이 날 수 있는 반면 전혀 엉뚱한 곳을 긁는 결과를 발생시킬 수도 있다. 그런데, 사실 이 부분은 내가 무언가를 말하기엔 아무것도 모르기에 나도 이 신념을 가지고 관련 지식을 습득하고 발현해나가야 하는 입장이다.

이 밖에도 테크 기반의 스타트업에서 의사 결정 권한의 주체는 어떻게 배분되어야 할까, 한정된 시간에서 업무와 개인 학습 사이의 조율을 어떻게 하면 잘 해낼 수 있을까 등등에 대한, 나에게는 커다랗지만 누군가에게는 작고 소중할 무언가를 나는 얻었다. 이것들이 나중에 내가 기술적으로 더 깊은 수준의 개발자가 되었을 때 눈덩이처럼 불어나 선물처럼 내게 와주었으면 하는 조그마한 바람이 있다.🤔 그 시간이 오기까지 꾸준히 나만의 길을 걸어가보도록 하자.

마치며

문득 글을 적으면서 이런 생각을 했다. “어쩌면 내가 철새인 거 아닐까?”. 그도 그럴 것이 개발자가 된 1년 동안 1번의 이직을 했으며 현재있는 곳도 내 선택에 대한 책임이 다하면 더이상 기다리지 않고 나와 더 컬쳐핏이 맞는 곳을 찾게 될 것 같다. 사실 조금 더 깊이 생각을 파헤쳐보면, 스스로 그렇게 생각한다기보다 누군가 나를 그렇게 생각하면 어쩌지에 가깝다. 당연할 수 있겠지만 나는 나 자신을 그렇게 평가하지 않는다. :-)

다만 성장에 대한 욕심이 좀 많은 건 있는 것 같다. 인정할 수 밖에 없는 부분.. 그런데 그 욕심이 나를 움직이게 한다고 믿는다. 몇번의 시행착오를 통해 나는 나만의 기준을 획득했고, 그 욕심 때문에 부족한 부분을 찾고 메꾸기 위해 고민하고 성장하기 위해 시도한다. 글을 적다보니 또 이런 욕심이 든다. 기술적으로 깊은 내용을 다루는 블로그 글을 조만간 올려야겠다 뭐 이런. 어디에선가 그런 깊은 글들을 보고있자면 배울 점들이 보인다. 나는 항상 기술을 찍먹하는 수준으로 다루고 넘기는데 그 글들은 깊게 기술적인 사고를 해야만 나오는 결과물이라고 느낀다. 그런 진득한 부분이 나에게도 필요한 것 같다.

개발자로 살아간 1년의 경험을 전체적으로 한 마디로 총평하자면 “불안 속 행복”이다. 참 불안함을 많이 느낀다. 이건 내 성격적 기질일수도 있다는 생각이 드는데, 어렸을 때부터 컴퓨터 자체를 사랑하신 분들, 혹은 나와 비슷하게 시작한 것 같은데 더 깊은 지식을 가지고 있는 것 같은 분들을 볼 때면 언젠간 나도 꼭! 이라는 생각이 들면서 동시에 약간의 질투심도 유발되는 것 같다. 나에게 주어진 과제는 이 불안함을 조급함이 아니라 긍정적인 성장의 동력으로 전환하는 것이지 않을까, 고민해보면서 이 글을 마친다.

어느 지점에서든 나처럼 불안함을 느끼는 이들이여, 피쓰-⭐️