기록/회고기록

2021년 회고록 (a.k.a 퍼블리셔의 퇴사회고)

heeney 2022. 1. 1. 01:34
728x90

 

 

 

 

주마등처럼 스쳐 지나가는 2021년

그렇다. 지금 이 글을 쓰는 시간은 31일 오후 11시 23분경이다.
다소 감성적이게 될 수 있기 때문에 주의하며 글을 쓰겠다.
어차피 몇분 지났다고 어썸한 2022년이 마법처럼 펼쳐지는게 아니라 그냥 2022년 1월 1일에 불과하기 때문이다.
이제 나는 기념일이며 뭐며 감흥이 없다.

감흥 없는 사람치고 글을 쓰고 있는게 좀 웃기긴 한데 그래도 한 해를 마무리하는 시간을 가지는게 스스로에게 값지기도 할 것 같고, 벨로그 구경하다보니 다양한 회고록이 있던데 왠지 더 열심히 살아야할 것 같은 느낌과 에너지를 주기에 한번 도전해보았다.

일단 2021년을 떠올려 보면, 나에게 2021년은 되게 긴 한 해였다.

 

 

회사를 1년 다녔다.

나는 웹디자인 & 퍼블리셔로 스타트업이자 첫 회사에서 일을 하고 있었다. 그 일을 하게 된건 국비 학원이 시작이다.

자세한건 내가 개발을 하게된 이유에 대해 쓴 글을 보면 좋다.

 

위코드 회고 (2) - 오케스트라에 들어가려고 했는데 개발자를 하게 됐다.

위코드 회고 (2) - 오케스트라에 들어가려고 했는데 개발자를 하게 됐다. 이목을 집중시키려고 수 많은 단어중에 '오케스트라'라는 단어를 넣어봤다. '이 사람.. 개발자 되기 전에 오케스트

habitual-history.tistory.com

웹디자인을 하려던 내가 그 곳에서 HTML, CSS를 배우고 성장하는 스스로를 보면서 '재미있기도 하고, 디자인과 코딩을 함께 할 수 있으면 좋을 것 같아' 라고 생각했다.
그 회사에서는 마침 디자인과 퍼블리싱을 둘 다 시키고 싶어 하기도 했고... 그 때 그 회사가 진행하려는 프로젝트가 좀 커보여서 공부가 많이 되겠다 싶었다.

 

 

프론트엔드 개발자도 없고 상사도 없고 당신은 신입이지만 PL 입니다.

신입으로 들어가 당장 코드치며 view를 그려내기에도 바쁜데 일단 view단을 담당하는 사람이 초반엔 나 뿐이었으니 개발 및 디자인 직군과 무관한 상사분들과 커뮤니케이션 하는 시간이 많았다. 그 과정에서 말을 좀 더 쉽게 하는 방법을 배웠다. 간혹가다 일부러 어려운 언어를 쓰면서 상대방을 배려하지 않고 말하는 개발자분들도 있었는데 다른 부서 분들이 이해가 안되는 것 같으면 좀 더 풀어서 설명했다.
이렇게 열심히 하는 모습을 감사하게도 부장님이 좋게 봐주셨는지 갑자기 PL 역할을 맡게 되었다.

어떤 프로젝트인지는 말할 수 없지만, 아무튼 작은 프로젝트는 아니었다.

기획 회의 하러 다니고, 일정 조율 일정 조율 ++.... 그리고 클라이언트 뿐만 아니라 팀원들, 상사분들과도 원활한 소통이 되어야만 했다.
일정은 정해져있고 모두가 이 프로젝트의 목표와 플로우를 알아야했으며 나는 동시에 나무를 보기도 하고 숲을 보며 다양한 분들과 소통을 해야했기 때문이다. 이 과정에서 서비스와 비즈니스적으로 다양하게 생각해볼 수 있었다.

생존(프로젝트 완성)을 위해 주기적인 커뮤니케이션을 선택하다.

일단 PL을 하면서 유연한 소통을 위해 상하좌우 대화를 시도한게 일을 제대로 완성하는데 중요한 역할을 하지 않았나 싶다.
프로젝트가 크다보니 다양한 인력이 프로젝트 진행 중간에 투입되어서 진행상황을 전혀 모르는 사람들이 존재했다. 주체적으로 시간을 정해 주기적인 회의를 진행하고 주어진 기간 안에 모두 얼마나 가능할지 커뮤니케이션 했다.
클라이언트와 회의할 때 항상 참여했는데 이때 view단의 기술적인 부분은 웹에 대한 이해가 아예 없으신 클라이언트 분들에게도 설명이 쉽도록 이미지와 함께 적극적으로 설명드리고 조율해나갔다.
아무래도 부장님도 웹을 하시는 분이 아니다보니 반응형이나 웹 접근성 (당시 IE 고려는 필수적이었다)에 대해 어떻게 일이 진행될 것인지, 이렇게 하면 어떤 문제가 있고 시간이 얼마나 걸리는지에 대해서는 내가 직접 이야기했다.
말씀을 드렸을 때 이해가 되었다는 긍정적인 반응에 희열을 느꼈던 경험이 있어서 지금도 코드에 대해 개발자들과 이야기하거나 개발을 잘 모르는 사람들에게 설명하기가 도전적이면서도 즐거운 이유가 이 때문일 것이다.
퍼블리셔 팀원들은 더더욱 자주 소통했다. 그 안에서 할 수 있는 것과 없는 것을 나눠서 명확히 상사분께 보고드렸고 퍼블리셔 팀의 업무 진행상황과 담당 업무를 한눈에 볼 수 있도록 구글 스프레드 시트를 공유드리니 파악이 훨씬 쉬워졌다고 칭찬받기도 했다.

유연한건 장점이기도 하고 단점이기도 하다. 그 안에서 해결할 수 있는 방법은 언제나 존재한다.

스타트업이다보니 애자일하게 굴러가야하는데 이 과정을 처음 접해보다보니 답답하고 불안해서 많이 울기도 했다.
할 수 있다고 했던 팀원이 1~2일 전에 못하겠다고 손을 놓아버리는 상황이거나, 완성 했다고 해서 QA를 진행하면 전혀 되어있지 않는 문제들이 그러했다. 시간은 얼마 안남았는데 클라이언트는 이것도 해주면 안되냐고 막무가내로 몰아붙이는 경우도 있었다.
그럴때마다 아득하고 답답하고 처음이라 어떻게 해야할지 힘들어했는데 그때마다 부장님께 의견을 많이 전달했었고 부장님도 "책임도 내가 지고, 욕도 내가 먹을거니까 걱정하지 말고 하고싶은거 해라." 라고 말씀해주셨는데 정말 든든했다.

그래서 더더욱 대화를 통해 필수적인 부분을 가장 먼저 처리하려고 했다. 팀원이 할 수 없다고 손을 놓아버린건 화는 나지만(...) 그럼에도 불구하고 팀원들 다같이 해결 방법을 찾아야 했다. 그건 기술적으로 퍼블리셔 팀원끼리만 소통할 문제가 아니었기에 연관된 다른 부서 직원분들과도 이야기했다. 상황 설명과 함께 꼭 필요한 부분인지, 빼도 되는건지.. 필수적으로 필요하다면 다같이 모여서 집단 지성을 활용해 해결했고 이 문제로 인해 다른 문제를 해결하지 못할 수 있으므로(시간 부족) 더 쉽게 처리하는 방법도 함께 찾곤 했다.

QA를 진행했는데 하나도 되어있지 않는 부분은 어떻게든 다시는 그런 일이 없도록 진지하게 대화를 했다. 다같이 부족하고 힘든건 알지만 못하겠다면 미리 말씀해주시고 그럼에도 불구하고 해결하고 싶다면 다같이 해결하는게 가장 좋은 방법이니 언제든 이야기해달라고 했다.
그리고 해결 방법도 함께 말씀드렸다. 완성한 다음에 그냥 넘어가지 마시고, 꼭 직접 한번 테스트해보는 시간을 가져주었으면 좋겠다고 권유하니 그런 일이 좀 줄어들었던 기억이 난다. 대화를 어떻게 하느냐는 정말 중요하다고 생각한다.

백날 천날 말해도 안바뀌는 사람도 있지만 내가 어떻게 말하느냐에 따라 그 사람이 행동과 태도를 바꾸기도 한다. 무작정 사람을 너무 포기하고 멸시하는 태도는 좋지 않다.

이렇게 유연한 환경에서 나같이 계획을 중요시 여기는 사람이 감당하기에는 고통스러웠지만 이 과정속에서 유연하게 대처하는 방법을 배웠다고 생각한다. 좀 더 사람을 이해할 수 있게 되었고 전혀 무관한 직군인 분들과 대화하는 것 자체가 두렵거나 어려운 일이 아닌 좋은 서비스를 만들기 위한 시도라고 생각하는 기회가 되었다. 팀원들이 서로 하는 일에 대해 명확히 아는 것은 중요한 일중 하나이다. 그들은 HTML, CSS, JS의 동작 원리에 대해 알 필요가 없다. 그러나 우리가 하는 일에 대해 알아야하는 내용은 있다. 그런 내용을 그들도 이해하려면 그들의 입장에서 생각해야하고 단어 선택도 더 쉽게 변경해야 한다. 그래야 그 내용은 그들에게 진정 가치가 있을 것이다.

유연한건 단점이 될 때도 있었지만, 과정을 더 빛나게 하는데에는 유연함이 장점이 되었다. 사람은 완벽하지 않기 때문이다.
완벽하지 않다는 것은 기계처럼 100% 모든 일을 시간 안에 무조건 처리할 수 없다는 뜻이다. 하물며 기계도 가끔은 망가진다. 그럴 때마다 도화지에 작은 점이 이상한 곳에 찍혔다고 울며 불며 다 망했다고 할 수는 없지 않은가? 그 때마다 할 수 있는 것을 찾아 해결해야 한다.
갑자기 계획이 변경되고 구현하려던 내용이 바뀌는 것은 사람이 하는 일에서 불가피하다고 느꼈다. 그 안에서 징징댈 것인지, 수용하고 다음 스텝을 위해 방법을 찾을 것인지는 오로지 그 일을 담당한 사람의 책임이다. 무조건 해결하라는게 아니라 할 수 있는 선에서 하는게 중요하다.

 

 

퇴사 후 느낀 1년동안 내가 배운 점 5가지 👀

1. 살기 위한 자기주도학습의 근육이 다져진다.

일단 이거 구현은 해야하고 너무 어렵고 물어볼 상사는 없다. 구글링만이 살 길인데 처음에 검색 능력이 높진 않으니까 버거워 한다.
그렇게 끙끙댈 때마다 옆자리 퍼블리셔 팀원분은 구글링을 참 잘하는 것 같았다. 그래서 많이 관찰하고 따라했었는데, 그중 에러메세지가 뜨면 아예 에러메세지 자체를 구글링하는 과정을 보면서 어떻게 답을 찾는지 많이 배웠다.

2. 안좋은 예시를 보면서 어떻게 해야 하는지 갈피가 잡힌다.

당장 어제의 내 코드만 봐도 답답한 경우가 많다. 팀원의 코드는 더더욱 눈에 안들어올 때도 있고 말이다.
그래도 그로 인해 발전하는 스스로를 발견할 수도 있고, 안좋은 코드를 봤으니 어떻게 좀 더 좋게 방향을 틀 수 있을지가 눈에 보인다.
쎄할 때쯤 해결방법을 찾게되는데 혼자 생각해도 답이 안나온다면 구글링을 통해 다른 더 쉬운 방법이 있는지 찾게 되었다.

3. 소통의 중요성을 깨닫게 되어서 전보다 더더더 적극적인 사람이 된다.

생각보다 말이 안통하거나 토론 자체가 힘든 사람들도 많다.
그들이 나쁘다는건 아닌데, 같이 협업할때 정말 힘들다.
나는 원래 서로 소통하는 것을 중요하게 여기기도 했고 서로 다른 사람이기에 커뮤니케이션이 필수적이라서 능동적으로 행동했지만 나 혼자 그런다고 해답이 나오지는 않았다. 점점 대화하고 싶지 않아지고 어떤 부분에 대해 기술적인 요청하는 것도 큰 부담과 망설임을 안고 간다.
어쨌든 일은 처리가 되어야 하니 울며 겨자먹기로 계속해서 나는 소통을 요청하고, 적극적으로 능동적으로 진행하지만 정신적 소모가 상당하다. 그렇다고 포기하고 있을 수는 없다. 내가 할 수 있는 일을 찾아야 하므로 최대한 상대방을 배려하면서 메신저가 더 편하다는 팀원은 메신저를 통해 소통하고, 대화가 필요하다면 언제든지 요구할 수 있도록 나라는 사람에 대한 허들을 낮추려고 노력했다. (당시 나는 사원이었으므로 권력에 대한 허들이 존재한다는 의미가 아니라, 누구나 불편한 사람이 있기 마련이므로 "언제든 대화를 요청하기에 편한 사람"이 되기 위해 허들을 낮추었다는 의미이다)

4. 새로운 기술을 도입하기 위해 윗분들 및 동료들을 설득하는 기술이 생긴다.

나도 깃헙을 몰랐지만 그들도 깃헙을 알지만 안하거나 아예 몰랐다.
일단 급하게 배워서 commit, push, merge할 수 있을 정도는 만든 채 동료들을 repository에 초대했다. 어떻게 하면 되는지 메모해서 보여주기도 하고 오히려 나보다도 설명을 친절하게 써둔 분들의 질 좋은 글 링크를 공유하기도 했다.
노션도 도입하여 소통이 쉽게 한 부분도 있었다. 다들 처음이라 서툴지만 어떻게든 함께 해보려는 시도가 좋았다. 그리고 서로 영향을 받아 다른 디자이너 동료분은 피그마를 쓰자고 추천해주셔서 어느 순간부터 피그마로 함께 작업하게 되었는데 정말 편해졌다.
회사에 새로운 기술을 도입하는데는 많은 시간과 노력이 들지만 그럼에도 불구하고 꼭 필요한 기술은 설득해서라도 도입하는게 좋다고 생각했다.

5. 개발 환경에서 누군가를 탓하지 않는 분위기는 무조건 필요하다는 것을 깨닫는다.

모든 회사는 완벽할 수 없다. 불완전한 상태로 완전함에 근접하게 일할 뿐....
그래서 "완벽한 시스템이 갖추어지지 않았다!!!!" 라고 탓하고 싶지는 않다. 그러나 어느정도의 체계적인 시스템이 없다면, 누군가를 탓하기 쉽다.
나도 어느새 누군가의 잘잘못을 따지고 범인을 색출(?)하는 나 자신의 모습을 보고 깜짝 놀랐던 적이 있다.
정신적으로 지치고 일정은 다가오니 힘들어서 내가 쟤까지 책임지고 싶지 않다 이런 느낌이라서 그때의 나를 충분히 이해하지만, 탓하기 전에 해결 방법부터 찾아야 맞다. 같은 팀이니까 그렇다.
그 팀에서 누군가 실수했다면 제대로된 환경을 구축해두지 않은 매니저와 최종 담당자의 잘못이라는 글을 봤었다. 누구나 실수는 하기 때문이다. 그 실수가 표면에 드러나 영향을 미치지 않도록 하는데에는 시스템 구축이 필요하다는 생각이 든다. 그렇지만 갖춰져있지 않더라도 가급적 팀원을 탓하는 일은 줄어야 한다. 같은 배를 탄 동료를 나무라봤자 분위기만 안좋아지고 단합력이 줄어든다. 그럼 일도 재밌지 않을 것이다. 탓하지 말고 함께 방법을 찾아나가야 한다는 것을 회사에서 하나의 프로젝트를 마무리 하면서 느꼈다.

 

 

자발적 퇴사와 반 강제적 퇴사를 곁들인 5월

자발적으로 5월에 퇴사하기로 했지만, 회사의 여러 문제도 있었고 회사가 이사를 하게된 시점과 퇴사를 하게된 시점이 맞물려서 퇴사일이 앞당겨졌다.
어수선한 분위기 속에서 팀원에게 '앞당겨 퇴사해야 도움될 것 같다'는 내용을 전달받아서 급하게 퇴사를 진행해야 했다는 점이 아쉽지만 그런 과정 속에서 어쩔 수 없었다는 생각은 든다.
원하지 않았던 날짜라서 상사분에게 다시 이야기했으나 그분들끼리 소통이 잘 안되셨는지 반강제적으로 퇴사가 진행되었다.
일단 퇴사를 했으니 하고싶은 것을 하려고 계획을 짰다. 컴퓨터 활용 자격증을 취득해보았고, 그동안 마음에 품고만 있던 웹 개발을 시작하기로 했다.

국비 학원 다니면서 내가 뭘 배우든 어떻게든 다 할 수 있겠구나 싶었기 때문일까 언어 공부가 어려울지라도 할 수 있을 것 같았다.
그런데 자바스크립트를 처음 접하는 그 때의 나의 기분은.... '아.. 진짜 모르겠는데.. 무슨말이지..' 아 정말 무슨 말인지도 모르겠고 너무 어려운 것이다. 그래도 일단 퍼블리셔 하다가 개발자로 전향해야겠다는 생각은 늘 품고 있었다.

나는 팀원들과의 소통을 잘하고, 사용자와 상호작용하는 웹을 만드는 것을 좋아하니까 행복한 프론트엔드 개발자가 될 수 있겠다고 생각했다.

 

 

함께해서 위코드

그래서 공부를 시작했고 혼자 공부하기에는 버거움이 느껴져 부트캠프를 알아봤다. 검색하다가 위코드를 발견했고, 별로인 부트캠프도 많다고 들어서 일단 상담부터 진행했다.
아름님과 상담을 진행했고 내가 원하는 코드리뷰, 팀 프로젝트, 소통 및 협업, 기업 협업을 갖춘 곳이라서 하겠다고 마음 먹었다.

혼자 공부할 때 막막하고 어려웠던 부분을 멘토님들, 동기분들과 의논해볼 수 있어서 정말 좋다. 열심히 해보겠다고 하는 분들이 왔기에 열정도 대단하셨다.
아직 1차 프로젝트 진행중이지만 소통하려고 노력하시는 분들과 함께 하는 모든 순간이 즐거웠다....✨ ㅋㅋㅋㅋ

가장 좋았던건 알고리즘 풀이할 때 동료들과 코드에 대해 이야기하고 작성하는 시간.
내가 왜 이렇게 작성했는지, '왜'에 대해 많이 탐구하도록 도와주었다.
개발자가 친 코드들은 왜 그렇게 작성했는지, 다른 방법은 없었는지 등 코드 한줄 한줄에 이유가 필요하다. 그래서 동기분들과 이야기할 때 왜 내가 이렇게 생각했고 왜 이런 메소드를 사용 했는지에 대해 딥하게 이야기 나누다보면 정말 몰입하고 있다는 느낌이 들어 즐겁다.

요즘 느끼는 거지만 코드에 대해 사람들과 이야기할 때 신세계를 접한 사람 마냥 즐거워서 지칠 때가 있어도 행복하다.
물론 어렵고 간혹 무슨 말인지 모르겠을 때도 있지만 그로 인해 배우기 때문에 모든 순간들이 값지다.
2022년 새해를 맞이하여 함께 해주는 멘토님들과 동기분들께 감사하다는 인사를 전하고 싶다 ❤️‍🔥

 

 

2021년의 나에게 말해주고 싶다. 너 진짜 멋졌어 ✨

 

 

모든게 다 처음이고 낯선 경험들이 난무했지만 정말 고생 많았어!
그로인해 많이 배우고 성장했으니 모든 경험은 나에게 좋은 경험이다.
어느새 글을 쓰다보니 2022년이 살짝쿵 다가왔지만 2022년에도 잘부탁한다 나야!!!!!

목표한 회사에 들어가 존재하는(present) 개발자가 되어서 1인분은 꼭 해볼 수 있기를...!
다이어트도 해보고 🙄 맛있는거 많이 먹고 늘 그랬듯이 즐겁고 행복하게! 가벼운 마음으로! 2022년을 또 따뜻하게 안아주며 보낼 수 있기를 바란다.
이번엔 꼭 여행도 가보고 싶다!!!! 코로롱 그만!!!!

 

블로그 이름이 <개발은 정말 재밌어>인데, 이 이름을 보고 흠칫 하고 놀라는 분들이 계셨다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
사실이기도 하고... 약간의 세뇌도 할겸(?) 지었다.
블로그 이름대로 즐겁게 개발하는 사람이 되어야겠다.
웹 개발 기술을 익혀서 사람들에게 가치를 전달할 수 있는, 1인분은 할 수 있는 개발자로 성장하라고 스스로에게 응원을 해본다!

반가워 2022년, 잘부탁한다 ~~!! 🎊

 

 

 

 

728x90