에세이

이직을 준비하며 느낀점 몇가지 회고

·

평온(을 위한) 기도(Serenity Prayer)
God, grant me the serenity to accept the things I cannot change,courage to change the things I can, and the wisdom to know the difference.
신이시여, 제가 바꿀 수 없는 것을 받아들일 수 있는 평온함과, 바꿀 수 있는 것을 바꿀 수 있는 용기, 그리고 그 차이를 분별할 수 있는 지혜를 주소서.

출처 : 나무위키 - 평온을 위한 기도

비즈니스에 기여하는 ‘나’를 제대로 보여주기

기초 보다는 경력자로서의 ‘경험’

일단 가장 처음 느낀 점은, 이직의 모든 과정, 더 넓은 범위에서 업을 구하는 모든 과정에서 ‘나’를 정확하게 인식하고 보여주는게 중요하다는 점이었다. 나는 지연을 통해 일을 시작하게 된 부류여서, 적극적으로 자신을 어필하거나 업을 구해본 적이 없었다. 어떤 관점으로 보면, 나는 그 쓰임의 맥락을 외부가 선택하도록 위탁하고 있었다. 그러니 스스로 쓰일 곳을 찾는 것이 더딜 수 밖에 없다고 생각했고, 실제로도 그랬다.
그래서 최초로 세운 전략은 레퍼런스를 찾고 참고하자는 것이었다. 일종의 ‘답지’를 보고 방향성을 정렬해나가는 것. 그때 조금 문제가 있었다. 일단 가장 큰 잘못은 '수준'에 맞지 않는 레퍼런스를 참고했다는 것이었다. 대부분 레퍼런스들은 신입의 경우를 나타내는 경우가 많았다. 하지만 경력직은 신입채용과는 전혀 결이 다른 필드였다. 이 경우에는 내가 운이 조금 없었다. 최초로 면접을 본 회사가 CS적인 측면, 기초적인 측면에 대해 많이 질문했었다. 내심 ‘이런 건, 필요할 때 찾아보면 되는 거 아닌가?‘라는 생각이 드는 질문이었다. 대답을 잘 하지는 못했다. 필요할 때 찾을 수 있다면 그건 내것이다.라는 신조가 있어서, 그것들을 일일히 외우고 있지도 않았고, 실무에서도 그런 것보다 더욱 추상화된 레벨로 일하기 때문이었다. 이유가 어떻게 되었든, 방향성의 수정이 필요했고, 한동안은 기초적인 부분에 있어서 미비하다고 여겨지는 것들을 채워나갔다.
그런데 웬걸, 그 이후 면접에서는 관련 질문이 뚝 끊어졌다. 그도 당연한 것이 경력직에 기대하는 건, 특히 시니어 개발자에게 기대하는 건, 코드를 잘 작성하는 레벨이 아니기 때문이다. 그것보다는 전체 프로젝트를 조망하고 유연하게 문제 상황에 대응할 수 있는지가 중요하다. 너무 예민하게 피드백하고, 방향성을 조정한 것이 독이되었다.

’수치’보다 내게 맞는 전략에 집중하기

두 번째 함정은 ‘수치’였다. 일단 전제로 '수치'적으로 나타낼 수 있는 지표를 쌓아놓은게 아니라면 '수치'에 집착하지 말라는 것을 덧붙이고 싶다. 즉, ‘수치를 드러내며 설득력을 더하는 것’이 나쁘다는 이야기가 아니라는 뜻이다. 이건 여러 레퍼런스를 찾아봐도 알 수 있는 부분이고, JD를 조금만 본 사람도 알 수 있다. 이력서를 검토하는 사람 입장에서는 이 사람이 문제를 해결 했고, 그 방법이 효과적이었다라는 사실을 가장 쉽게 이해할 수 있는 수치 지표가 필요하기 때문이다.
하지만 나의 경우에는 수치를 토대로 말해오던 사람이 아니었기 때문에, 이 기준으로 나를 평가하게 하는 것은 큰 독이 되는 전략이었다. 쌓아온 수치가 없었기 때문에 이 관점을 고수하면 내 경력은 물거품이 된다. 따라서 무작정 ‘수치’를 밝히는 것이 좋다고 접근하기보다 내가 시장에서 평가받을 수 있는 가장 유리한 기준을 설정하는 것이 중요하다.

시니어라면 기술보다 그 너머를

그 동안 나는 나 자신을 주니어라고 생각했다. 하지만 내 관점이 어떠하든, 최장 7년차의 이력서는 시장에서 ‘주니어’로 평가될 수 없었다. 시니어로서의 자질을 갖추어야하는 경력이 된 것이고, 그동안 그런 일들을 해왔는지를 시험받는다. 그리고 시니어의 기준은 기술 너머 비즈니스의 성장에 기여할 수 있는가라고 생각한다. 하지만 앞서 말한 것처럼 나는 잘못된 인풋을 통해 기술적인 측면에서 나를 증명해야한다고 오해했다. 특히 인공지능의 시대에서 코딩과 기술이라는 기초적인 부분으로 시니어로서 평가받는 것은 크게 불리할 수 밖에 없다. 이제 개발자에게 필요한 능력은 코딩 그 자체보다 전체 시스템을 설계하는 능력이고, 시니어에게는 그것과 더불어 팀을 리드할 수 있는 능력, 원활한 커뮤니케이션, 생산성의 향상 등이 필요해진다. 이렇게 생각해보면, 나는 줄곧 그런 관점으로 팀에 기여해왔고, 사실상 내가 가장 잘 할 수 있는 것들, 그리고 생각해왔던 것들임에도 불구하고 스스로 불리한 판으로 뛰어들었다. 결국, 어떤 비즈니스에 합류한다는 것은 어떻게 내가 그것들 도울 수 있느냐로 귀결되는 것이다.

과제 모두 탈락 : 개선 방향 가설 세우기

두 번의 과제 전형을 모두 탈락했다. 조금 낙담하게 된 이유는 더 이상 잘 할 수 있는 부분을 모르겠다이다. 현실적인 기준에서 정해진 시간과 조건에서 최선을 다했다고 생각했고, 시간이 더 많은 경우에는 개인적인 개선사항까지 코드에 반영하였다. 그런데 돌이켜 생각해보면 개인적인 개선사항까지 코드에 반영한 부분이 발목을 잡지 않았을까 생각해본다.
그렇게 생각하는 이유는 과제 리뷰가 자동화 되어있을 가능성과 제한사항을 정확하게 충족했는지를 기준으로 평가할 가능성 때문이다. 일단 첫 번째 가능성의 경우, 내가 더 좋은 솔루션을 알고 있다고 해서 그런 솔루션을 적용할 경우, 프로그램이 비관적으로 판단할 가능성이 높다. 어찌됐든 자동화된 평가프로그램은 로직이 정한대로 평가하기 때문이다.
제한사항의 정확한 충족 부분에서는 합의되지 않은 결정사항의 독단적 반영을 경계할 수 있다. 개발은 커뮤니케이션이 주가되는 업이다. 내 생각에 개발자보다 협업을 많이 하는 직군은 사실상 없다고 생각한다. 그런 측면에서 합의되지 않은 기준을 마음대로 적용하는 사람을 의도적으로 경계할 수 있다. 물론, 나의 경우 개선사항을 보여주고 증명하는 것이 더 빠른 일처리를 가능하다고 생각하기 때문에, 그런 것이 습관화 되어있지만, 나의 워크플로우와 맥락을 공유하지 못한 상태로는 자칫 리스크가 될 수 있다.
따라서 개선해보자고 하면, 1. 테스트코드를 작성하여 Spec을 정의한다, 2. 정직하고, 가독성있게 구현한다., 3. 문서를 통해 구현 방식과 이유, 그리고 개선점을 제안한다 이 세가지 흐름으로 과제를 작성해야할 것 같다. ‘커뮤니케이션’이 전제되지 않은 커밋에 대한 반성을 다시금하게 된다.

천천히, 꾸준히

최근 TCI 기질 / 성격 유형 검사를 했다. 나는 자극추구와 위험회피 기질이 모두 높은 사람이다. 이런 사람의 경우 하고 싶은 게 많지만, 위험을 회피하는 성향 때문에 내적으로 갈등이 많다고 한다. 돌이켜보니 나는 도전하는 사람들에 경의를 보내면서도, 내가 도전할 때 리스크를 끊임업이 생각하고 완결 전에 리스크를 이유로 포기한 경험이 많았던 것 같다. 그렇게 나는 불안을 타고난 사람이다.
그렇다보니 이직의 과정에서도 위험회피 기질이 나를 불안하게 만든다. 이제 곧 부모가 되는 입장에서 기반이 바뀌는 선택을 하기 때문이기도 하다. 이 때 나를 가장 위로한 말은 대부분의 사람이 1년을 과대평가하고 20년을 과소평가한다는 말이었다. 모두 1년내에 자신이 더 성장할 것이라고 믿지만, 꾸준히 쌓아가는 작은 것들에 대해 과소평가한다는 이야기. 그 말을 듣고나니, 내 고민들과 이직의 경험들도 과정으로 생각할 수 있게 되었다. 내 안에 중심을 두고, 내가 되고 싶은 사람의 방향성을 명확하게 해나가고, 그렇게 살아나가다보면, 반드시 나를 필요로하는 곳을 만나 내가 꽃필 때가 있을 것이다. 그런 위로를 얻을 수 있었다.
비록, 오늘의 부족함에 마음이 아프지만, 한편으로 부족하다는 것은 내가 할 수 있는게 있다라는 뜻도 된다. 받아 들이고 나아가고자 한다. 천천히 꾸준히. 좋은 회사와 복지를 향해 이직하는 것 너머, 내가 원하는 모습과 삶으로 살아갈 수 있도록 하기 위해서. 혹시나 나와 같은 고민을 하는 사람들이 있다면, 조금이나마 이 글로 위로받기를.