내가 10년차라고 인정을 받았을 시기에, 그 때 시기는 바로 개발자들이 뜨기 시작했을 시점이었다.
하지만 다른 친구들과 다른 아는 개발자들이 평균 급여를 받을 때 나는 여전히 그들의 반을 받고 일했다. 왜냐고? 하필 개발자가 뜨기 1달 전에 재계약을 했다는 그지같은 타이밍 덕분이었지.
하지만 그래도 10년차다 보니, 나란 놈에게도 멘토링 제안이 몇몇 들어오긴 했었다.
그러나 나는 거절할 수밖에 없었다. 멘토링 시간을 내기엔 하필 그 때, 고도화 지원을 나가야 했기 때문이다.
유지보수 담당인 내가 왜 고도화 지원까지 해야 하나, AS-IS 지원 때문이다.
그래서 나는 안양과 강남을 오가면서 출퇴근을 했었지.
아무튼 정신없는 업무 처리에다가 이런 저런 사정과 겹쳐서 타이밍이 좋지 않을 시기에 제안이라, 나는 어쩔 수 없이 거절할 수밖에 없었다.
그러고 난 뒤 큰 폭풍이 지나간 뒤, 나는 또다시 멘토링 제안을 받았고, 나는 이제 괜찮을 것 같아 승낙했지만, 며칠 뒤 멘토링 제안을 들어온 곳에서 거절 통보를 받았다.
갑작스런 거절 통보에 이유를 물었지만, 그들은 결국 꺼내주지 않았다.
그리고 나는 그 이후로 멘토링 제안이 다시는 내게 들어오지 않았다.
만약 그때 내가 멘토링을 했다면, 이런 걸 가르쳐 주고 싶었는데, 내가 결국 주니어 멘토링에 준비한 멘트를 썩히고 나서 어느새 몇 년이 지났는데,
dev.to 에서 내 멘토링 주제와 비슷한 글을 발견했다.
3개월간의 실무 경험이 2년간의 튜토리얼보다 더 많은 것을 가르쳐 준다
영어지만 생각보다 짧고 간결하며 주니어들이 이해하기 쉬운 글이라 주니어인 너희들에게 한번 영어든 번역이든 정독시켜 주고 싶었다.
"준비됨"이라는 신화
저는 첫 개발자 직무에 지원할 때 전혀 준비되지 않았다고 느꼈습니다. 첫 주는 HR 담당자가 끔찍한 실수를 저질렀다고 생각하며 보냈습니다.
하지만 한 달도 채 되지 않아, 저는 6개월간의 온라인 강의에서 배운 것보다 버전 관리, 디버깅, 다른 사람의 코드 읽기에 대해 더 많은 것을 배웠습니다.
왜냐하면 튜토리얼은 밤 9시에 실제 운영 중인 서비스의 버그를 수정하거나 코드 리뷰 중에 자신의 논리를 설명하는 상황을 시뮬레이션할 수 없기 때문입니다.
다들 한 번 뛰어들었다면 알다시피, 배운 것과 실무는 너무나 다른 차원의 세계라는 것을 느낄 것이다.
내가 인턴에 뛰어들었을때도, 좋소인지는 중요하지 않고, 그저 어디든 마찬가지로 아무도 내게 업무를 가르쳐주지 않았다.
이렇게 해매다 싶이 하려던 찰나, 나는 운이 좋게 같은 학교 선배 개발자를 볼 수 있었다. 그는 프리랜서였고, 나에게 많은 동질감이 온다며 나에게 이것저것 멘토링해 주었다.
하지만 그게 100% 내 실무를 바꿔주지는 않았지만, 나는 일단 주어진 업무를 처리했다.
나는 Ajax in Action 이라는 당시 명서를 바탕으로 고객지원 업무 프로세스를 구현했고, 새로고침 없이 현 화면을 유지하면서 고객센터 직원이 통화를 받아가며 적으며, 저장하고, 그리고 고객에 대한 회사의 처리 방향을 동시에 기록하는 프로세스를 성공적으로 구현한 것이다.
하지만, 나는 자잘하긴 했지만 예상치 못한 교통사고로 병원에 입원했고, 회사는 그런 나를 바로 잘라버렸다.
이게 회사라는 각인을 시켜 준 첫번째 좋은 경험이었다.
대신, 나는 겨우 하나의 경력이 쌓였지만, 이곳저곳 지원해서 좋소든 좆소든 어디든 갈 수 있었다. 그리고 계속 경력을 쌓고, 갑작스레 찢어질 수밖에 없었던 선배의 연락에 나는 두번째 기회를 얻을 수 있었다.
단지, 그 분야가 하필 악명높은 SI/SM 이게 된 줄을 모른 채였지만, 아무렴 어떤가...
4년의 실무 경험 끝에 프리랜서라는 신고식을 받고 프리랜서를 오랫동안 했었으니...
지랄같은 SI/SM 이었지만, 뭐 페이는 괜찮았으니 투덜투덜대도 계속 해왔었지.
물론 그 덕분에 그 유명한 네카라쿠배와는 영원히 바이바이하게 됐지만 말이지
(참고로 나는 네카쿠 지원한 적 있었고, 면접과정에서 보기좋게 떨어졌지만 딱히 나쁜 경험은 없었다)
실무가 모든 것을 바꾸는 이유
실제 환경에 일단 들어가면 모든 것이 바뀝니다.
당신은 다음을 배우게 됩니다:
- 지저분한 레거시 코드를 읽고 이해하는 법.
- 더 낫고, 더 날카로운 질문을 하는 법.
- 피드백을 개인적으로 받아들이지 않고 처리하는 법.
- 명세(specs)가 명확하지 않을 때 모호함을 다루는 법.
이것이 진정한 개발자 교육이며, 첫날부터 시작됩니다.
내 경험 상 글쓴이는 정말 토씨 하나 틀리지 않고 정확하게 배우는 항목들을 정리해 주었다.
진짜 실무에서 이렇게 한다. 열심히 리액트 배웠더니 제이쿼리 레거시를 분석해야 한다? 실무에서는 매우 흔한 일이다. 파이썬 3.12 로 파이토치로 알고리즘 분석했는데 갑자기 파이썬 2.7로 짜여진 Pandas로 짠 알고리즘 보고 맨탈이 붕괴되려 한다면 그건 지극히 정상이다.
바로 그지같은 실제 환경에서 그 맨탈을 어떻게 유지하느냐가 바로 네가 주니어에서 성장하는 개발자로 가느냐 방향이 결정되는 것이다.
나? 라떼는 말이야 굳이 알고싶다면 알려주지. 나는 Ajax 기반 웹표준 사이트 만들어야 했는데 레거시 코드가 ActiveX 떡칠한 사이트였다. 시발 제이쿼리는 선녀야, 선녀.
당신은 충분히 준비되었습니다
준비되지 않았다는 그 느낌? 그건 완전히 사라지지 않습니다. 시니어 개발자조차도 그렇게 느낍니다.
그러니 일단 지원하세요. 성장하는 가장 빠른 길은 영원히 준비하는 것이 아니라 시작하는 것이기 때문입니다.
당신은 실행하고, 실패하고, 개선하면서 배우게 될 것입니다.
모든 훌륭한 개발자가 그렇게 시작했습니다.
뭐? 본문에 뭔가 빠진 것 같다고? 너는 내 글을 정말 잘 봐줬구나. 고맙다.
하지만 대충 읽는 이들을 위해 고의적으로 누락시키도록 하겠다.
본문의 결론은 간단하다. 내가 하고싶은 말은 비슷하다.
회사가 널 가르칠 거라 생각한다면 당장 버려라.
마치 전쟁에서 대충 4주 훈련 시키고 바로 전장에 투입시키는 것과 마찬가지다.
만약 거기서 살아남는다면, 아마 너는 이미 영웅이 되어 있을 것이다.
물론 목숨이 파리 목숨이란 건 변하지 않고, 전쟁이 끝난 뒤 인생은 알 수 없을 뿐이지...
회사도 마찬가지다. 물론 한국이 미국에 비해서 해고가 어렵긴 하지만, 개발자는 미국이나 한국이나 가장 해고가 쉽고, 그냥 쿨하게 해고하는 회사들이 즐비하다. 왜냐? 대기업이나 중소기업이나 어디가나 개발은 비용으로 취급한다. 이는 어느나라 가도 마찬가지. 그렇다보니 비용을 아끼려면 인건비를 줄이는 명분이 금융쟁이들과 경영진들에게 바로 납득을 시킬 수 있으며, 그 명분으로 막 자른다 해도 기업들과 노조들은 쳐다봐주지도 않는다. 각자 지들 일 아니니까.
노조가 끼면 얘기가 복잡해지니 여기까지 하고, 아무튼,
넌 개발자고, 이미 넌 전문가다. 네가 뭘 해야 하는지 스스로 파악하고, 문제를 해결하며, 만약 잘릴 때를 대비하고, 자산 관리를 직접 해야 한다. 이건 네카라쿠배 소속 개발자라도 마찬가지다.
이건 내가 전 글에게 언급한 바 있다.
생존을 위해서라면 수단과 방법 가리지 말고 살아남으려 노력하다 보면,
너는 이미 시니어가 되어 있다.
나처럼.
단지 너와 내가 방향이 다르게 갈 뿐.
하지만 아무렴 어떤가.
너도 시니어로 인정받을 거고,
욕쳐먹는 나도 인정받고 있다.
어떻게 인정받는지만 다를 뿐이지.
사실 개발자 뿐만 아니라 다른 직업이라도 마찬가지일 테지만, 난 개발자만 설명하겠다.
넌 준비되어 있다. 자각하기 힘든 거 알아. 하지만,
회사에서 원하는 "경력있는 신입" 이란 조건은 이런 것도 인정해준다.
네가 준비된 인재라는 점을 어필하다.
뛰어들다 보면, 결국엔 넘어간다.
그리고 살아남아라. 개복치
개발자가 되고 싶다면 기본적으로 이정도 근성이 있어야지!
끗.
즐겨찾기 해놓고 생각날때마다 늘 잘 보고 있습니다.