연차가 쌓일 수록 익숙해져야하는 5가지
주니어이지만 주니어이고 싶지 않은 프론트엔드 5년차 개발자
시작
저는 어느덧 5년차 개발자가 되었습니다. 아직도 모르는 게 많아서 스스로를 주니어라고 생각하지만, 주니어이고 싶진 않은 모순적인 마음으로 살아가고 있습니다.
뭔가 다 통달한 척하는 글일까 조심스럽긴 하지만, 저도 아직 배워가는 중입니다.
주니어이지만, 주니어이고 싶지 않은 나에게 ‘연차가 쌓일 수록 이런 일들은 익숙해져야해’라고 정신승리를 하기 위해 오늘의 글을 씁니다.
혼자인 것에 익숙해져야 한다
다르게 표현하면 외로움에 익숙해져야하는 것 같습니다. FE 개발자가 몇 명이든 결국에 개발은 혼자해내야하는 경우가 많은 것 같습니다. 제가 개발자로 일해봤던 회사는 대부분 스쿼드 조직이었고, 스쿼드에는 보통 1~2명의 FE 개발자가 있었습니다. 혼자 하다 어려워지면 다른 FE 개발자분들과 페어프로그래밍을 하기도 했지만, 결국엔 혼자 해내야하는 영역이 대부분이었던 것 같습니다.
예전에는 혼자 일하는 회사 말고 FE 여러명이 있는 조직을 가고 싶다는 생각을 했는데, 막상 그런 조직들을 경험해보니 여전히 개발은 혼자 해야하는 경우가 많습니다. FE 개발자가 여러 명인 조직이면 가끔 어려운 문제를 함께 해결해볼 수 있다는 장점이 있지만, 연차가 쌓일 수록 혼자인 것, 외로울 수 있다는 것을 받아들여야하는 것 같습니다.
쓴 소리를 해야할 때도 있다
미움 받을 용기랄까.
어떤 말이든 말을 예쁘게 하는 사람이 참 부럽습니다. 저는 그런 완급 조절을 잘 못하는 편이긴 합니다. 완급 조절을 하려고 노력하면 하려던 의미를 분명하게 전달 못하고 빙빙 돌려말하게 되서 정말 어려운 영역인 것 같아요.
회사에서 지내다보면 나 혼자 no라고 말해야하는 상황이 있고, 그 말들은 보통 다른 사람이 받아들일 때는 쓴소리인 경우가 많은 것 같습니다.
사실 조용히 있으면 중간이라도 갈 것이고, 그냥 해달라는대로 해주는 게 속이 편할 때가 더 많을텐데요. 지금보다 더 많이 주니어일 때는 해달라는 대로 해주는 것이 사람들에게 점수를 따는 것 같아서 해달라는 대로 해주려고 노력하기도 했습니다.
그런데 생각 없이(?) 지내게 되면 제품의 완성도가 떨어지는 것 같습니다. 빠른 속도도 중요하지만 엉성한 제품을 유저들은 좋아하지 않을 거고, 신뢰의 영역이기도 한 것 같아요. 이유가 있는 no는 나름의 의미가 있고, 당장 사람들과의 관계가 서먹해질 수 있어도 결국엔 더 멀리 나아갈 수 있게 해주는 것 같습니다.
제가 말한 no라는 것이 거절만을 이야기하고 싶은 것은 아닙니다. 모두가 좋은 이야기만 하거나, 이걸 굳이 내가 말하지 말아야겠다는 생각으로 지나쳐버리지 말고, 이야기 해보는 것이 어쩌면 좋은 결과를 낳을 수도 있다는 이야기를 말씀드리고 싶었습니다.
아마도 회사에서 누군가는 저를 무서워할 것이고, 싫어해서 뒷담화를 할 수도 있고, 이런 부분마저 좋게 봐주시는 분도 계실거에요. 가끔은 제가 너무 나대는 걸까라는 생각이 들어서, 많이 조용히 그냥 있으려고도 노력하는 날도 있어요. 누군가에겐 저의 나댐(?)이 무척 불편할 수 있을 것 같아서요. 우아한 쓴소리를 하고 싶지만, 아직까지 현실에선 그저 쓰디 쓴 잔소리 같긴해요. 요즘에는 정신건강의학 전문의 선생님들이 책을 쓰신 것이 많아서 그런 책을 보면서 조금씩 쓴소리를 우아하게 하는 방법에 대해 알아가고 있어요. (너무 어렵..)
아직은 우아하게 쓴소리를 하지는 못하고 있지만, 하나 깨달은 것이 있다면, 쓴소리를 하기 위해서는 적당한 거리감(?)이 필요한 것 같습니다. 너무 친해도, 너무 친하지 않아도, 쓴소리를 하기 어려운 것 같아요. 뒤에서 제 생각을 좀 더 풀어보려고 합니다.
도움을 요청할 때까지 지켜보기
심리학에서 구원환상이라는 말이 있습니다. 누군가를 돕는 것을 넘어서 내가 그를 절망에서 구원하는 구원자가 되고 싶은 마음을 뜻하는 단어입니다.
저도 아직 배울 게 많은 주니어이지만, 연차가 쌓이다보니 저보다도 주니어인 분들을 마주하게 되는 일이 점점 늘어나고 있습니다.
구원환상이 저에게도 있었던건지, 예전에 일했던 회사에서 인턴으로 입사한 분에게 redux와 redux-saga로 상태가 갱신되는 플로우를 종이에 그려가며 설명드렸던 적도 있습니다. 사실 문서보고 스스로 공부하게 그냥 두고보는 게 더 나은 판단이었을 것 같아요. 알려드린다고 머리에 100% 다 들어가는 것도 아니었을텐데 말이죠.
보통 완전 신입일 때는 자신감이 없는 상태였다가, 2–3년차쯤 되었을 때 자신감이 넘쳐흐르는 경우를 많이 봅니다. 저도 그랬고, 만나는 주니어분들도 대부분 그렇더라고요 ㅎㅎ 회사에서 요구하는 사항들을 어느 정도 할 수 있는 능력이 있고, 나보다 조금 더 연차가 있다고 하는 사람이 나와 비슷한 것 같고 별거 없는(?) 것 같다고 생각했던 것 같아요. 그 시기 즈음부터 다른 회사에서 이직제안하는 콜드메일도 많이 받게 되니까, 나 정도면 괜찮다라는 자신감이 넘쳐흐를 때인 것 같습니다. 자만의 상태에 가까워지는 것 같아요.
저도 그러한 시기를 보냈고, 그 때가 가장 고집이 센 시기였던 것 같아요. 내 생각이 분명 맞는데 자꾸 누가 뭐라고하는 것 같아서 싫었고, 내가 많이 안다는 것을 표현하고 싶었던 것 같아요.
지금 회사에서 배운 것 중 하나가 피드백은 상대가 원할 때 해야한다는 것입니다. 시기가 맞지 않으면 그저 잔소리일 뿐이라고 하더라고요. 그냥 지켜보고, 도움을 요청받았을 때 돕는 걸 연습하고 있어요. 잘 안될 때도 많긴해요.
아주 엄청난 장애가 예상되는 게 아니라면, 에러를 만나서 고생도 해봐야하고, console.log 외에도 디버깅할 수 있는 다른 방법이 많다는 것도 경험해보시도록 두고, 배포는 롤백이 가능하고 후속 대응을 할 수 있을 때 하는 것이 좋다는 소소한 경험을 쌓아가실 수 있도록 약간 방치(?)하는 것이 필요한 것 같습니다. 지켜보다가 이건 좀 빠르게 해결되어야할 것 같을 때는 중간에 껴들긴 하는데, 이것도 앞으로는 지켜보고 맡기는 연습을 해야할 것 같아요.
어떤 분이 지금 진행하시는 것을 다 암묵적으로 동의해서 그대로 두는 것이 아니고, 이런 저런 경험을 하며 성장하실 수 있게 제 스스로를 — watch 상태에 두는 것 같아요. 그 어떤 분이 자유롭게 진행하시는 걸 지켜보면서 저도 많이 배우고 있어요.
이제는 저보다 더 시니어 레벨에 있는 분들을 보면 확실히 위기에 대응하는 능력은 더 뛰어나다는 걸 느끼고 있어요. 고민의 깊이도 다른 부분이 있어서 그 사람들의 경험을 듣는 게 즐겁습니다. 회사일이 바쁘면 그런 이야기를 들을 시간이 부족해서 그 점이 항상 아쉬워요. 아마 그 분들이 저를 보면 제가 하는 일들이 위태로워보이고, ‘그렇게 하면 안되는데…’라고 생각하실 수도 있을 것 같아요. 저도 하나씩 배워가는 중입니다.
꼭 사적으로 친해질 필요는 없다
제가 예전에 개발자가 아니었던 시절에 어떤 스타트업에서 일했을 때는, 마음이 맞는 몇 사람들끼리 잘 모여서 어울려놀았습니다. 새벽 3~4시까지도 술도 마시고, 회사, 이직, 연애, 결혼, 노후 등등 진짜 여러 이야기들을 하기도 했고, 주말에 따로 모여서 놀기도 했습니다.
제 스스로가 냉소적으로 바뀌게 된 걸 수도 있지만, 지금은 회사 분들하고 그 정도까지 어울리지는 않습니다. 사람들을 나름 챙겨주려고 노력하지만, 사적으로 친한 분은 없습니다. 친해지면 얼마든지 함께 어울릴 수는 있지만, 굳이 굳이 사적으로 친해지기 위해서, 학교 다닐 때처럼 친구를 만들려고 노력하지 않습니다.
사적으로 굳이 친해질 필요가 없다고 생각한 이유는 ❶그 관계가 영원하지 않을 것이고, ❷여러 사람이 모였을 때 긍정적인 이야기보다 부정적인 이야기가 더 많이 오고 갔던 경험때문입니다. 그리고 ❸적당한 거리감이 어느 정도 우아한 쓴소리를 할 수 있게 만들어주는 것 같습니다.
진정한 친구는 한 명이어도 족한다라는 말이 있는 것 처럼, 회사는 회사로 두고 나의 생활은 나의 생활대로 가져가는 것이 마음을 제일 건강하게 유지할 수 있는 것 같습니다. 그렇게 새벽 3~4시까지 많은 이야기를 나누었던 사람들은 지금은 다들 또 각자의 인생(?)을 살고 있습니다. 그 때 그렇게 친했기 때문에 지금 다시 만나도 어색하진 않을 것 같지만, 예전처럼 다시 만나지는 않아요.
삼삼오오 회사 사람들과 어울렸을 때 남녀 관계의 이슈가 있기도 했고, 내 회사의 좋은 점을 이야기 하기도 하지만, 나쁜 점은 더 많이 이야기하게 됐던 것 같아요. 그 때는 그런 이야기가 참 재밌기도 했는데, 한편으로는 부정적인 말들에 제가 점점 물들었던 것 같습니다. 지금 생각해보면, 그 때 그런 쓸데 없는(?) 소문에 물들지 말고, 여행 가거나 해보고 싶었던 일을 했다면 지금 더 행복하지 않았을까 생각합니다. 온전히 저에게 집중하는 게 좀 더 행복을 가져다주었을 것 같아요.
그렇다고 외톨이(?)처럼 아무하고도 말을 하지 않는 것은 아닙니다. 다른 사람이 봤을 때는 나대는 것처럼 보일 수 있어서 걱정이긴 하지만, 사적인 관계에 쏟던 에너지를 이제는 회사와 저를 위해서 쏟고 있습니다. 회의 시간에 좀 더 이야기를 나누는 데 쓴다거나, 이렇게 틈틈이 제 생각을 블로그에 적기도 하고, 어딘가에 연사로 초청을 받아서 제 이야기를 하기도 합니다.
업무적으로 긴밀한 관계이고 사적으로 친하진 않기 때문에, 제가 좀 쓴소리를 했을 때 그 사람이 많이 감정이 상했다면 어딘가에서 뒷담화라도 하면서 스트레스를 풀 수 있겠거니 생각합니다. 만약 저와 사적으로 많이 친한 사이라면, 쓴소리를 듣는 입장에서는 스트레스를 풀기는 어려울 것 같습니다. 이미 형성된 라포를 깨고 싶지 않을 것이기 때문입니다. 친하기 때문에 할 수 있는 말이 있고, 친하지 않기 때문에 할 수 있는 말이 있다고 생각합니다.
기존 코드를 마이그레이션 시키는 고통을 즐겨야 한다
경력이 쌓일 수록 이미 라이브에서 돌고 있는 코드를 마이그레이션 시키는 고통(?)을 즐길 줄 알아야겠구나라고 생각합니다.
내부적인 코드가 어떻게 생겨먹었든(?) 개발자가 아닌 직군은 크게 관심이 없습니다. 이미 라이브에서 특별한 이슈 없이 잘 돌고 있는 코드인데, 개발자가 코드를 더 좋게 바꿨다고 말했는데 에러가 펑펑 터지면, ‘이게 뭐가 더 좋아진거지?’라고 보통 생각할 것입니다. 리팩토링/마이그레이션 같은 것들이 내 이력서에 적힐 한 줄이 될 수도 있지만, 제일 중요한 것은 어떤 과정으로 리팩토링/마이그레이션을 진행했느냐인 것 같습니다.
극단적인 상상을 해보자면..
아주 작은 스타트업일 때는 인건비 부담으로 인해 신입을 뽑기도 하고, 대표분이 직접 코딩을 하기도 합니다. 어느 정도 수준까지는 분명 잘 동작할 것이고요. 그러다 회사의 규모가 커지고 자금의 여유가 생기면, 회사에서는 경력직을 적극적으로 채용하기 시작합니다. 그리고 그렇게 뽑힌 시니어들이 기존의 코드를 보고 깜짝 놀라며 리팩토링과 마이그레이션을 시작합니다. 고도화를 하기 위한 작업을 진행하는 거겠지요. 그 이후에는 주니어를 채용하면서 양성하고, 시니어 중 누군가 퇴사하더라도 그 사이에 시니어로 성장한 주니어(또는 중니어)가 회사의 코드를 점점 발전시켜 나갈 것입니다. 제가 생각했을 때 회사의 성장 라이프 사이클은 이런 흐름입니다.
이런 생각을 가지고 있는 저이기 때문에, 신입과 시니어를 나눌 수 있는 기준은 기존 코드를 얼마나 고도화시킬 수 있느냐입니다. 저도 지금 회사에서 받은 코드를 원하는 수준까지는 발전시키지 못한 것 같긴 하지만, 고도화 시키기 위해서 나름의 시간을 투자하고 있습니다. 이런 일을 뚝딱뚝딱 할 수 있을 때, 스스로 이제 나는 시니어라고 생각할 수 있을 것 같습니다. 제 다음을 이어 할 사람에게 조금이라도 짐을 덜어주고, 무언가 만들고 싶을 때 지금의 코드가 발목잡지 않았으면 좋겠거든요.
그래서 라이브 되고 있는 A 서비스를 마이그레이션할 때, 왠만하면 통으로 갈아치우는 것보다 점진적인 수정하며 라이브에 계속 배포를 하면서 모니터링하는 방향으로 진행합니다. 통으로 마이그레이션하는 것은 기존 라이브 코드의 최신 커밋을 따라잡는 것도 벅차고, 테스트 코드가 완벽하지 않다면 설상가상 새로운 버그 양성기가 될 수도 있습니다.
하지만 이런 생각을 갖는다는 것이 벌써 어엿한 꼰대가 되었다고 생각되어서 슬프기도 하지만, 가끔씩 저보다 더 주니어이신 분들이 ‘저 이제 그러면 무엇을 해볼까요?’했을 때 ‘백로그로 어떤 기능을 리팩토링해야하는 A가 있고, 아니면 새롭게 B를 적용해보는 일도 있어요’라고 후보를 말씀드리곤 합니다.
보통 그러면 왠만하면 새로운 걸 해보고 싶으신지 B를 선택합니다. 기존 코드를 수정하는 게 두려워서일 수도 있지만, 새로운 것이 더 흥미있고 스스로 대단한 것 같고 구미가 당기기도 하니까요. 이해합니다. 가급적 저도 새로 입사하신 분은 처음에는 온전히 A-Z까지 만드는 일을 하시도록 하고, 그 뒤에는 조금씩 기존 코드를 수정하시게 은근하게 유혹합니다 🤓
맺으며
세상을 다 통달한 것처럼 이런 저런 이야기를 쓰긴 했는데, 저도 배울 것이 정말 많고 ‘왜 그런 말을 했지’하면서 후회하는 것도 많은 사람입니다.
내가 틀렸다는 걸 거의 매일 느끼고 있어서, 언젠가 이 글이 흑역사가 될 수도 있지만, 당분간 제 마음을 다잡는 데 도움이 될 것 같아서 생각을 적어보았습니다.
읽어주셔서 감사합니다 🙇🏻♀️
