취업 1년 회고 및 퇴사 기록, 벌써 1년.

History

2023.11월, 약 11개월의 취준 생활을 끝으로 근로계약서에 서명을 했다. 환경이 독특했다. 대표와 단 둘이 있는 아주 작은 회사. 사실 회사라고 하기에도 민망한 규모였지만 어찌됐건 내 개발자 커리어의 시작이 되어줄 회사였다. SI 기업이긴 하지만 한가지 서비스를 1년 동안 개발하는 일이었다. 실제로는 중간에 자체 프로덕트 할 거리가 있는 지도 살펴봤고, 다른 외주도 추가로 진행했지만 어찌 됐건 한가지 서비스를 중점적으로 개발했다.

프로덕트의 도메인도 독특했다. STO 플랫폼, 토큰 증권 발행을 목적으로 하는 플랫폼 서비스였다. 일종의 증권 거래 플랫폼이라고 해야할까? 평소 아트투게더와 같은 미술품 거래 서비스를 눈여겨 봤었기에 도메인을 이해하는 것에는 크게 무리가 없었다. 그렇게 1년 동안 할 수 있는 선에서 기존 코드와 사용성을 개선했고 기능을 추가했으며 크로스 플랫폼 앱으로도 개발했다. 하지만 안타깝게도 이 프로덕트는 가오픈 이후 프로젝트 진행 동력을 잃게 되었고 클라이언트사는 “쉬엄쉬엄하라”는 말과 함께 프로젝트의 진행을 딜레이 시켰다.

그렇게 흐릿해지고 있던 STO플랫폼을 옆에 두고 음악 커머스 계열의 프로덕트를 외주로 진행하게 되었다. 이건 문제 많게 개발되어 있는 프로젝트의 QA 목록을 작성하고 정상적으로 굴러가게 만드는 게 목적인 외주였다. 최초 170개 가량의 QA 목록이 작성되었고 진행하면서 발견된 문제까지 200개가 훌쩍 넘었다. 두달이라는 짧은 데드라인 속에 최대한 빠르게 작업을 진행하였으나 비즈니스에 가장 중요한 결제플로우에 중대한 문제가 발생하였다. 기획과 백엔드, 디자인 모두 각자의 주장을 강하게 내세우며 무엇 하나 서로 고려되지 않은 채로 만들어져 있었다. 해당 문제에 대해 클라이언트사에게 확인 요청, 수정 요청을 해도 (길게는) 한달여가 지나도록 답변이 돌아오지 않았다. (여전히 돌아오지 않았다.) 이 역시 진행동력을 잃게 되었다.

협의 중이었던 프로젝트들도 올해 진행이 불가능해졌다는 답변을 들었다고 했다. 그렇게 회사는 약속된 잔금을 받지 못해, 더 이상 일거리가 없어져 존속이 불가능해져버렸다. 내 개발자 커리어의 첫 시작인 회사는 이렇게 분해되었다.

남은 것

개발 공부를 제대로 시작한 건 지금으로부터 30개월 전이었다. 취업 전까지 1년 반이라는 짧은 시간을 공부했으니 1년 남짓한 회사생활은 내 개발인생의 거의 절반이었다고 할 수 있다. 그런 걸 감안한다면 남은 게 많을 수 밖에 없는 시간이었다. 아니 정확히는 남아야하는 시간이었다.

1. 작업 효율은 잘 정리된 소스코드로 부터 나온다

우선 첫번째로 느낀 점은 많은 사람들이 말하는 좋은 코드, 클린 코드의 중요성이었다.
회사에서 진행했던 어디서부터 손봐야할 지 모를 정도로 강하게 결합되어있고 정리되어있지 않던 소스코드의 두 프로젝트는 눈 앞의 빈틈없는 거대한 괴물과도 같았다. 하지만 그들도 차근차근 풀어해치며 분리해내니 내가 해결 가능한 자그마한 문제로 변해있었다. 자그마한 문제가 되니 자신감이 붙고 자신감이 붙으니 재사용성이니 뷰와 로직의 분리니 직관적인 네이밍이니 하는 것들을 생각할 여력이 생겼다. 소스코드의 파악이 용이해지니 수정도 추가도 용이해졌다. 말 그대로 능률이 올랐다.

만약 그 복잡한 소스코드 위에 리팩토링 없이 이어서 개발을 진행했다면 당장의 리소스는 줄어들 지언정 시간이 지날 수록 증가한 복잡도로 인해 일정을 지키기 어려웠을 것이다. 의미 전달이 명확한 네이밍, 잘 정리되고 분리된 컴포넌트와 로직, 재사용성의 고려 그리고 이것들을 가능케 하는 설계. 진부하지만 그만큼 생산성을 향상시키는 것들임을 몸소 느꼈다. 가능하다면 개발 기간 중간 틈틈히 코드의 개선 사항을 찾아내고 수정하는 게 남는 장사다.

2. 프로덕트를 분석적 태도로 바라봐야한다

코드를 잘 정리하기 위해서는 단순히 코드를 잘 다루는 것만 필요한 게 아니다. 기획과 디자인을 분석해 중요한 맥락을 추출해내는 능력이 제일 중요한 것 같다. 정말 단순하게는 디자인을 보고 공통으로 활용 가능한 UI를 추출해내는 것부터 서비스 전체에서 공통적으로 활용되는 로직을 추출해내는 것까지, 분석을 통해 맥락을 이해해야하는 일이다.

이런 태도 역시 당연하다고 생각하지만 생각과는 달리 눈 앞에 펼쳐진 업무도 버거워 고려하기 쉽지 않다.
그래서 한가지 습관을 가지면 좋겠다는 생각을 했다.

작업하는 도메인과 유사한 프로덕트를 찾아서 사용해보기
혹은 현재 서비스 중인 프로덕트라면 사용자로서 실제 서비스를 사용해보기

업무에서는 보이지 않던 서비스의 디테일을 보게 된다는 장점이 있다. 코드는 하루종일 바라보고 있었고 내가 구현했던 게 무엇인 지 알고 있으니 실제 서비스 플로우를 경험하며 따라가다 보면 놓친 부분을 떠올리게 된다. 개선할 수 있는 점도.

위 작업과 곁들여서 할 수 있는 도메인 이해하기

개발이해도를 높이기 위해서는 도메인 지식도 중요하다고 생각한다. 예를 들어 STO가 무엇인 지 이해하지 못한다면, 커머스가 무엇인 지 이해하지 못한다면 요구사항을 이해하기에도 로직을 도출해내기도 그리 녹록치 않을 것이다. 도메인 지식은 개발하다보면 점차 쌓여가기도 하지만 시간이 해결해주는 것보다 스스로 해결하는 게 더 나으니까. 위 처럼 실제 프로덕트, 유사 프로덕트를 사용해보면 빠르게 그 지식을 쌓을 수 있다는 장점도 있다. (물론 열심히 찾아보기도 해야겠지만.)

3. 소통. 소통. 소통.

비단 개발에서 뿐만 아니라 현대사회를 살아가면서 소통은 가장 중요한 가치다.
소통은 크게 업무적 소통과 일상적 소통으로 나눌 수 있을 것 같은데 회사는 일상이자 업무의 공간이므로 두가지 모두 크게 중요하다고 생각한다. 업무적 소통만 잘한다면 좋은 사람일 수 없고 일상적 소통만 잘한다면 일잘하는 사람일 수 없기 때문에 둘 다 잘해야한다.

(회사에서) 일상적 소통

• 업무누락으로 대표가 슬랙에서 불편한 기색을 내비친 적이 있었다. 업무 분배에 대한 규격이 없어 발생한 이슈였지만 불편한 기색을 내비친 순간에는 항변이 아니라 발생한 업무누락에 대한 사과가 선행되어야 했다. 사과했고 재발 방지를 위해 업무 분배 문서 규격을 만들었다. 대표도 불편한 기색을 내비친 것에 대한 사과를 했고 누구 하나 앞으로 불편하지 않게 잘 마무리 됐다.

• 스몰토크도 중요하다고 생각한다. 업무 내용이 포함되지 않은 사적 대화로 서로(팀이든 더 큰 조직이든)를 파악해야 좀 더 매끄러운 관계가 유지된다. 가령 상대방이 싫어하는 게 무엇인 지 파악 가능하고 좋아하는 게 무엇인 지 파악하면 말실수 하는 일이 줄어들거고, 업무로 인해 쌓인 응어리를 녹일 수도 있다. 팀 분위기에 지대한 영향을 미치고 이건 생산성과도 직결된다.

업무적 소통

• 빠른 피드백 혹은 기한을 정해놓고 지키기가 필요하다. 누군가는 그 피드백을 기다리느라 일을 못한다. 다른 할 일이 있다면 하고 있으면 되지만 현재 업무가 다른 업무를 위해 필수적으로 선행되어야하는 업무라면? 하릴없이 기다릴 수 밖에 없다.

  나는 기본적으로 2인 회사라 노크 한번이면 빠른 피드백을 하고, 듣는 게 가능하지만 클라이언트사와의 소통이 무한한 기다림의 연속이었다. 기획/디자인/API 내용의 불일치로 빠른 확인이 필요한 상황이었으나 여러번 호출해도 답이 없었고 그 이슈는 3주 가량 체류해 있다. 처리 가능한 다른 업무를 우선 처리하고도 답은 없었다.

  빠른 피드백 혹은 기한을 정하고 기한 지키기는 필수다. (이건 일상적 소통도 마찬가지지만.)

• 체계적인 문서화가 필요하다. 문서화 작업은 지루하지만 업무 누락을 줄이고 문제가 발생했을 때 책임 소지에 대해서 잘잘못을 가릴 수 있으며 현재 작업 진행상황을 파악할 수 있는 등 많은 역할을 한다. 멋진 문서 만들기! 이런 것보단 팀 내 합의에 의한 규격화된 양식과 지속적 작성이 중요한 것이기 때문에 문서화 문화가 없다면 도입하고 있다면 개선점을 찾아내며 지속적으로 작성하자.

부록

이건 남은 것이라기 보단 난리가 난 소스코드를 리팩토링하면서 특히나 스타일 코드들 때문에 스트레스 받아서 느꼈던 것인데 SCSS로 작성된 스타일의 경우 트리쉐이킹이 따로 되지 않으므로 잔존하는 레거시 스타일을 모두 제거하지 않는 이상 성능에 영향을 미칠 수 있었다. 그래서 악착같이 의미없이 존재하는 스타일 코드들을 제거하고 리팩토링 했었는데 만약 이 프로젝트가 빌드 타임에 사용되지 않은 스타일들이 트리쉐이킹 되는 VE같은 스택으로 스타일링 되어있으면 당장은 이런 노가다를 하지 않아도 되지 않을까? 하는 생각이 들었다. 기술스택 고려할 때 단순히 유명해서라던가 많이 쓰인다던가 하는 이유를 넘어서서 다양한 상황을 곱씹어보며 선택하면 좋겠구나~ 하는 생각도 들었다는 그런 얘기.

마치며…

인생을 살아가면서 많은 시간을 음악을 공부했고 돈이 안되는 일을 하고 영리적이고 상업적인 집단에 속한 적이 많지 않았다. 그런 내 인생에서, 죽도록 하기 싫었던 고객센터를 제외하고는 거의 첫직장 같은 곳이었다. 어쩌면 상당히 특수한 환경이었지만 그래도 정말 많은 것들을 배우지 않았나 싶다.

앞으로 어떤 개발자가 되겠냐! 라고 한다면 지금 이 일년간 느꼈던 점들을 잘 녹여낸 개발자가 되겠다고 답할 거다. 녹여낸 다음에는 다른 것들을 녹여내는 개발자가 된다고 해야지.

항상 어떤 환경에서든 배울 점은 있고 그 배움으로 성장하자. 고마웠어. 내 첫직장.