왜 매일 쓰는 일기도 아니고 자주 쓰는 일기도 아니고 가끔 쓰는 일기일까? 🤔

티스토리로 블로깅할 때는 매일을 기록하는 개발일지도 써봤는데 그 자체가 일이 되어가더라.

사실 처음에는 차가운 도시속의 쿨하고 펀한 개발자 모습을 생각하며 시작했었는데 매일 글을 쓰기 위해 수 시간을 소모하는 블로그의 노예가 되어갔다...
내가 원하는 이상과 달랐던 현실에 결국 패배의 깃발을 들었다.

하지만 그렇다고 안하자기에는 사람이 살다보면 기록하고 싶고, 그 간 내가 보내온 시간들을 되돌아보며 간단하게 회고를 하게 되지 않겠는가? 그럴 때 마다 일기를 쓰듯 작성하고 싶었다.

사실 꽤 이전부터 생각했던 콘텐츠인데 그 간 이직도 있었고, 이직한 회사에 적응하고, 귀찮았고(?) 해서 이제서야 작성한다.

이직 👋

그렇다. 나는! 나는!! 나는!!! 이직을 했다!!!!

2019년에는 핫하다 못해 철사장같은 코인판에 끼려던 작은 스타트업에서 일을 했다. 자체 코인을 개발해서 게임이나 활동을 통한 자연스러운 채굴 시스템을 주 서비스하는 업체였는데 당시에는 코인이 활성화되서 판매하고 현물화하고 뭐 그러지 못했던거 같은데 요즘엔 어떨지 모르겠다.

왜 퇴사를 결심했는데?

뭐 어쨌든 여느 스타트업이 그렇듯 항상 성공할지 어떨지도 모르는 불확실한 미래의 사업을 바라보는 회사였는데 내가 느끼기에 근무 조건은 썩 나쁘진 않았다. 별 일이 없으면 퇴근 시간 되서 퇴근을 할 수 있었고, 점심 식대도 제공해주는 회사였으니까. (물론 제공받는 식대 대비 선릉은 주변 물가가 너무 비쌌다!)
가끔은 간식을 사서 임원진들, 직원들 모두 모여 먹으며 사소한 이야기나 나누는 등 소소한 재미도 있는 회사였다.

(선릉역에 있는 우마쿠라. 저녁에는 선술집을 운영하고 점심에는 식사메뉴를 판매한다.)

그런 회사를 나는 왜 그만두고 이직하기를 마음 먹었더라?

아마 첫 단추부터 잘못 꿰였던 것 같다. 잡 코리아에서 지원을 하고 서류 통과와 면접에 합격하며 입사하게 되었는데 당시 팀은 백엔드를 전문으로 하는 중고 신입인 나를 비롯해서 프론트 팀 신입 1명, 팀장 1명으로 총 3명으로 구성되었다. (백엔드 신입 분이 한명 더 들어왔었지만 한 달 만에 그만두게 되었다.)

중고 신입으로 반년 가량의 공백을 끝으로 나름 기합이 잔뜩 들어간 상태로 입사했었는데 의욕도 가득찼었고, 매일 아침마다 출근 후 팀에서 인프런으로 Spring Boot, JPA, Vue, Webpack 스터디를 하면서 배우는게 많았다.

그러다가 돌연 팀장이 회사를 떠나게 되었고 그렇게 그 해를 팀장없이 운영되었기에 일찍이 혼자 인프라 구축 경험을 할 수 있었다. AWS, 리눅스, 가용성 구성 등 서비스의 퀄리티는 썩 만족스럽지 않았지만 다양한 경험을 할 수 있었다.

그러다 퇴사를 결심하게 된 원인은 아무래도 좀 더 전문적인 도메인을 다루고, 더 나은 개발 환경에서 일해보고 싶어서였다. 자체 코인을 다루는 회사였지만 정작 거래나 채굴등의 서비스를 다뤄볼 수 있는 기회가 없었고 그것이 이직을 결심하게 된 큰 원인이었다.

지금은 🧑‍💻

현재는 만화, 소설을 웹으로 서비스하는 곳에서 일하고 있다. 평소에 웹툰 콘텐츠를 자주 소비하는 사람으로써 꽤 흥미로운 서비스였고 한번쯤 경험해보고 싶었다. 2020년 3월에 입사하였고 2021년 7월인 현재까지 재직 중이다.

적응

이직 하자마자 코로나로 감염자가 1,500명 넘게 찍었던 것으로 기억하는데 출근한 지 일주일만에 재택근무로 전환되었다. 다른 팀에 입사하신 분들의 경우에 재택근무로 인해 부적응으로 퇴사하는 분들이 있었다고 들었는데 충분히 이해는 가더라.

아직 낯설고 친하지 않은 팀원들에게 도움을 받기 위해 선뜻 슬랙으로 질문하는 것이 쉽지 않았다. (그럼에도 따뜻하게 다 하나하나 알려주는 당신들은 천사인가)
더군다나 다른 곳들과 똑같이 회사가 평소에 재택근무 환경에 경험이 없었기 때문에 업무 환경을 위한 인프라 설정이 필요했을 것이고, 규칙과 체계를 잡느라 이제 막 입사한 나를 챙기기에는 정신이 없었을 것이다.

그래서 적응을 하기위해 무엇을 해야하는지 스스로 생각하려 했고, 서로 말이 통하려면 이 회사가 무엇을 서비스하는지 도메인에 대한 이해가 우선이지 않겠는가? 우선 도메인을 이해하려고 했다. 소스코드를 보면서 궁금한 것들은 슬랙을 통해 질문했고 WIKI문서, JIRA 이슈들, 정의서들과 API 툴을 이용해 직접 요청을 날려보면서 어떠한 응답을 내리고 어디에 사용되는지를 이해해 나가며 한 달 가량을 재택근무하며 보냈던 것 같다.

(내가 이런 걸 할 줄 몰랐지...)

R&D와 리뷰

이 곳에서 나는 연구원 직책으로 입사하게 되었는데, 평소에 R&D라는 말만 들어봤지 정확하게 어떠한 일을 하고 어떤 업무 환경인지 알지 못했었다.
그래서 "Johnny OO에 대해서 R&D를 해보세요." 라거나 "이 업무에 대해서 스스로 일정을 산출해보세요." 하면 무엇부터 시작해야하는지 감이 오지 않았다. 지금까지 일정은 업무를 요구하는 측에서 일방적으로 통보 받아오는 환경에서 일을 해왔고, 무언가에 대해 찾아보고 리서치하기 위해 시간을 소모해본 적이 많지 않았기에 지금은 해당 업무에 대해서 크게 부담을 가지지는 않게 되었지만 당시에는 꽤 신선한 오더였고 나를 긴장시키게 만드는 요소였던 것 같다.

현재 팀은 리뷰 환경에 꽤 적극적인 자세를 가지고 있는데, 난 아직도 내 첫 커밋에 대한 Merge Request를 잊지 못한다.
당시 리뷰를 위한 코멘트가 한 15개 가량 달렸던 것 같은데 코드 스타일에 대한 의견이 많았었다. 도메인에 대한 관심사 분리(Separation Of Concern) 개념을 배울 수 있었고, Spring의 validation 어노테이션등 전반적으로 코드를 깔끔하게 정리하여 작성할 수 있는 방법들을 배웠다.

리뷰 시스템은 당시 나에게 큰 도움을 주었기에 나 또한 팀원들에게 도움을 주고자 산출물에 대한 리뷰를 적극적으로 하고 있으며, 아는 것은 아는대로 모르는 것은 질문하는 자세로 열심히 커뮤니케이션을 하고 있다.

나는

이전까지 Java와 Node.js를 기반으로 웹 백엔드 서비스 개발을 해왔었고 지금은 Java, Golang을 이용해서 웹 백엔드 서비스를 비롯해서 업무에 도움이 되는 CLI를 개발하고 있다.

어릴 때 부터 게임을 하다보면 잡캐를 만들곤 했었는데 지금 나는 이거저거 하는 잡캐가 되어가고 있다.
(캐릭터는 삭제하고 다시 만들 수라도 있지 이건...)
뭐 꼭 부정적인 생각만 가지고 있지는 않다. 관점에 따라서 개발자에게 언어란 필요한 상황에 적재적소로 사용할 도구로 인식할 수도 있고, 장인이 되기 위해 하나만을 깊게 파는 전문 기술로 인식할 수도 있다.