“자바 개발 5년”
1. 언어의 장벽
처음 이야기 하고 싶은 이야기는 언어의 이야기 입니다.
우리가 내려가서 거기서 그들의 언어를 혼잡케 하여 그들로 서로 알아듣지 못하게 하자 하시고
ㅡ창세기 11:7
성경에 나오는 구절입니다. 별 뜻은 없지만, 하필이면 개발언어가 이렇게 다양할 줄은 꿈에도 몰랐습니다.
6년전, 2011년 입사초만 하더라도, 안드로이드는 꽤나 초기에 나온 제품이었습니다.
당시 전, MFC를 열심히 하고 있었고, (동시대 친구들은 파이썬이나 임베디드 쪽에 관심이 더 많았던것 같네요)
전 앞으로의 시장이 모바일 기기로 퍼져나갈꺼라는 생각에 미리 선점해야겠다는 일념하나로 졸업작품을 모바일로 했습니다.
그 당시로썬 교수님들이 별로 좋아하진 않았죠. 차라리 연구실에 쓸법한, 영상처리 기법 (OpenCV나 Image Lib를 활용한)이나 당시 삼각측량을 활용한 근거리 통신 (지그비,직비라고도 함) 정도 이용해서 뭔가를 만들어야 교수들이 흥미를 가지던 시절 이었습니다.
당시 전 mobile 6.0 윈도우 모바일이 부흥할꺼라는 어긋난 믿음을 가지고, mfc와 모바일 6.0기반 Gps를 활용하여 (따로 기기가 있었습니다) 버스 알람 프로젝트라는 명칭의 졸작을 만들었는데요. 뭐 자다가 내릴때 알람을 해주는겁니다. ㅎ
당시 데이터를 얻고, 실제 테스트하느라 부산 떨었던 것들이 떠오르네요.
서론이 길었는데, 이때까지만해도 윈모가 뜰꺼라고 생각했고, 안드로이드와 아이폰쪽은 전혀 상상을 못했습니다.
하지만, 입사후에 제가 처음한 일은 자바.
스트럿츠.
스프링.
CRUD.
전혀 새롭고 생소한, 프레임 워크였죠.
지금에야 학생들이 토비의 스프링을 사다 놓고 미리 학습할수 있는데, 시중에 책들은 사실 꽤 옛날 내용의 자바 2.0 이라던지, 실효성이 별로 없는 내용에,
제가 탔던 개발 서적 테크는
기초플러스 C — 기초플러스 Cpp — MFC6.0, more effective cpp, more more?!, gof 디자인패턴과 같은 류의 책들이었는데.
추억의 배게
자바라니!
웹에 대해 엄청나게 무지했고, css도 책한번 보지 않고 자바 웹 시장에 팔려 나온 셈이죠.
포인트는 언어에 장벽을 스스로 정하고 가두어도, 꼭 그것을 하게되리란 보장이 없다는 것과, 초기에 가지는 시선, 프레임중에 하나는 언어의 우월성입니다.
어떤 언어가 좋다. 나쁘다. 효율적이다. 어느 순간 가다보면, 어느덧 안드도 하게 되어있고 어느순간은 XCode도 깔게되고, 어느 순간엔 node나 express도 경험하고, 파이선도 설치하고 델파이도 해보고, 그러다보면, 언어란 해외 나가면 영어 쓰듯이, 필요에 따라 바꾸는거지 내가 좋아한다고 회사에서 자바를 쓰고 있는데 mfc나 c#으로 바꿀수 없는 것이고, 누군가 원하는 프로젝트가 네이티브인데 굳이 하이브리드로 만들 이유가 없었다.
라는 겁니다.
물론, 한국어 하다가 영어 하다가 불어하다가 언어 바꾸는게 내맘같지 않은게 사실이지만, 언어가 다르다고, 미리 겁먹거나 배척할 필요가 없는 것 같습니다.
결국 그걸 하게 되어 있으니까요.
초기, xml에 대한 지식이 없던 때는 뭐 xml이 대단한것인줄 알고, xml 문법도 찾아보고 규칙을 만드는것도 궁금하고 있던 시절이 있지만, 결국 그건 사람 편하자고 만든거라는걸, 너무 늦게 알게된 경우도 있고 말이죠.
2. 회사를 결정하는 일과 직무를 결정하는 일은 다르다.
첫회사는 몇일 다니지 않았지만, 음성인식 솔루션을 만드는 회사에 들어갔었습니다. Bnf라고 음성 데이터를 파싱하고 규칙을 만드는 회사였습니다.
전 core 업무를 할수 있을줄 알았는데, 업무라는게 제 마음대로 할수는 없더군요.
이사님께서는 제게 소리 raw를 뽑아서 가공해보라고 과제를 던져 주셨는데, 그 때 처음 느낀건, 회사는 내가 골라도, 일은 내가 고를 수 없다.
두번째 회사도, 어플리케이션 직무를 선택했지만, 자바 웹을 개발하게 되었으니 말이죠.
다만, 인사 시스템 직무에서 경영지원 시스템을 만드는 일로 보직이 변경되었었는데, 개발를 계속하다보면, 운영적 업무에서 개발적 업무로 넘어가게 되는 일도 있는 것 같아요.
처음 받은 직무가 개발일이 아니라고 해서 개발을 하지 않으면 개발과는 엄청 동떨어진 삶을 살 수도 있으니, 최소한 개발은 좋아해야하지 않나 싶네요.
3. 연봉과 일의 강도는 비례하는가?!
저의 첫회사와 두번째 회사의 연봉은 천만원 이상 차이가 났었습니다.
첫회사에 살짝 발을 걸쳤던 저로썬, 두번째 회사에서 벌어질 노동 강도에 대해 막연한 두려움을 가질 수 밖에 없었죠.
아마도 돈을 주는 만큼 더 많이 일을 시키겠지?!
이런 불안감 말입니다.
이 불안감에서 비롯된 질문이
천만원을 적게 받고 야근이 없는 회사를 택할래? 천만원을 더 받고 생활이 없는 회사를 택할래?
이 질문이 아닌가 생각해 봅니다.
끝없이 화자되고 되풀이 되는 이야기 인데, 이 이야기는 더 많이 받는 삶에 대한 막연한 두려움을 줍니다.
그리고 많이 받으면 더 일해야할 꺼 같은 압박감을 주죠.
근데, 결론은 회사마다 다르고 부서마다 다르고…
연봉이 많은 회사들 사이에서도 좋은 부서, 혹은 야근이 없는 부서가 있고
연봉이 상대적으로 적은 회사에사도 나쁜 부서, 상대적으로 야근이 많은 부서가 존재합니다.
나는 아니겠지.
하지만 주변에 부러워하는 대상들은 언제나 있습니다.
그럼, 방법이 있는가 싶은데, 이 사실을 이해하는 대목이 중요한 것 같아요.
개발자로써의 삶도 사실상 더 많이 개발하기 위해서가 아니라, 더 효율적이고 간단하게 만들어서 많은 이익을 창출하기 위함도 포함되니, 적게 일하더라도, 많이 버는 개발자는 충분히 더 많을 수 있다고 봅니다.
결론은 이런 연봉과 일의 양이 비례하지 않다면, 더 효율적인 곳을 찾아 떠나는 개발자들의 삶도 이해가 가능한 대목인 셈이죠.
아마 학생때 가졌던 생각은 회사는 돈을 버는 곳이고 일을해야 돈을 벌어주는 거니 일한 만큼 받는게 아닌가 그런생각이었다면, 회사에서 느낀건, 회사는 어떤 사회적 시스템을 통해 돈을 벌 수도 있고 어느정도 성장된 부분에 따라 효율을 먹을 수도 있다. 따라서 어느 위치나 어떤 기업에서 해당 업무가 아주 원할하게 돌아갈 수 있을 정도의 역량이라면, 연봉은 회사 주기 나름이다.
이렇게 이해가 변경되었습니다.
즉, 연봉의 개념은, 회사가 주고 싶은 마음에 따라 다른거지, 일이 많고 적음과는 다르단 점입니다.
회사의 입지와도 연관성이 있겠죠. 왜 구글에 입사하려고 하는가.
뭐 이런 이유를 떠올리면 어느정도 이해가 되는 대목이 아닐까 생각해 봅니다.
- 출처 : pixabay
4. 회사에서 알고리즘이 필요한가?!
최근에 알고리즘 이슈가 대두되어서, 학생들의 알고리즘에 대한 관심히 날로 날로 더해지고 있다고 생각합니다.
학부때 알고리즘 수업을 처음 듣고, 대단하다는 생각이었습니다. 이런 걸 생각해낸 사람도 대단하고, 실무에 어떻게 적용할 지에 대한 막연한 기대감들,
실무의 껍데기를 들추어보니.
화면 —프로세스 — 데이터
이게 전부입니다. 간간히 도는 스케쥴러들과 데이터의 향연.
너무 간촐화 시켜서 그렇지만, 어떤 프레임워크를 쓰던, 어떻게 화면단을 꾸미든, 설계를 잘하든 못하는 핵심은 데이터를 가공해서 어떻게 빠르게 혹는 효율적으로 화면에 뿌리고 사용자들은 어떤 것들을 할 것인가.
거의 이 부분에 집중되어 있었습니다.
결국 CRUD. 처음 입사할때 블로그를 한번 만들어 보라고 했는데, 해외에서 사용할 꺼라고, 잘 만들어야 한다고, 그땐 난 mfc도 했는데 자바정도야 라는 헛된 망상에 잡혀있었고, 처음 개발에, 엄청난 실수와 화면 누락에 충격과 고배를 맛보아야 했습니다.
CRUD가 각각 어느시점에 어떻게 일어나는지에 대한 정확한 부분을 이해하고 있지 못하고 있었거든요.
학생땐 사실 실무적인것을 만드는것보단, 아이디어나 대략적인 프로토에 집중합니다.
따라서 이런 데이터를 다루는데 있어서 보여지는 부분 수정하는 부분 그리고 저장 시점에 대한 확실한 이해가 필요한데, 아마도 어떤 지식을 미리 얻을 수 있었다면, 이런 사용자 관점의 뷰포인트를 미리 얻었다면 좋지 않았었을까 생각이 되네요.
결론은 이런 데이터를 가공하는 시점에 아마도 알고리즘이 필요하겠거니 싶은데, 자바 전환후 그리고 예전에 비해 서버의 성능향상으로 고객이 많지 않아서 등등 굳이 알고리즘을 쓸 필요가 없는 곳.
아마도 추천 시스템이나, 인공지능, 챗봇, 그리고 사람들을 매칭해주는 곳에선 더 효율적인 알고리즘이 필요할 것입니다. 와챠나 개인 추천을 필요로 하는 곳도, 필요로 하겠죠. 하지만 제가 있던 곳은 그런곳이 아니었습니다. 고객은 만명이었죠.
서버가 죽을일도 많지 않은 곳.
결론은 회사에 따라 알고리즘이 쓰이는 곳이 있고, 아닌 곳이 있다.
갑론을박이 되는 이유는 회사마다 다르기 때문인 셈이니, 모두 각각 맞는 말을 하는 셈이죠 ㅎ
대중적으로 필수다 필수가 아니다는 말 자체보단, 회사가 알고리즘으로 뽑는 이유.
똑똑해보이니까.
요런 포커스에 맞추면 더 낮지 않나 싶네요.
인사 성향에 따라 크게 좌우될 내용입니다.
5. 직무에 대한 이해.
회사를 들어갈때 어떤일을 하는가?!
이게 초기 궁금한 사항입니다.
근데 이게 규칙이 있는게 아니라, 회사마다 달라서 구분지을수는 없어도,
대략적으로는 개발자 입장에서는 어느정도는 분류가 되더라고요.
인프라 — 서버 관리 및 네트워크
네트워크 — 아예 보안 및 방화벽 관리
개발 — 백엔드, 프런트, 풀스택 (솔루션 사용같은), 앱, 웹앱, PM, PL(경우에 따라 있기도 없기도), 솔루션 개발, 잡다모두
— 분야별로는 너무 많을 것 같아 이정도로
유지보수 — 전화 및 SR 처리, 업종별 지식 필요
대략적으로 게임 회사가 아닌 이상은 이런 업무 바운더리를 가진듯한데, 신입 초기에는 저보고 인프라를 가라고 해서, 뭔지도 모르고 마냥 좋아했던 생각을 가졌는데, 각각 업무별로 가지는 특성과 장단점이 있습니다.
이해도 없이 접근하다간 금방, 지치는 경우가 발생하기도 하고, 새로움이 없는 경우는 쉽게 나가 떨어지기도 할 것 같네요.
신입 초기 내가 어떤 업무를 어떻게 해서 무엇을 배우고 뭘 어떻게 할지에 대한 고민이 없으면, 그냥 하는 일을 하게 되는 사람이 되지 않나 (제가 지금 그런거 같은)
6. 사수에 대한 환상
누구나, 좋은사수 나를 키워주고,나를 성장시켜줄 사수 나를 키워줄 사수에 대해 흥미로워하고 앞으로 나의 로드맵을 그려주고 같이 성장을 동반할 사수에 대한 환상을 가지기 마련이라고 생각합니다.
저또한 사수에 대한 환상으로, 실력이 충만하게 늘어날 것을 기대했습니다만,
“설명은 없고 일이 있다”
충분한 시간과 설명은 없고 과제만 있다.
일은 있지만, 설명이 없는 상황들에 자주 놓이게되었습니다.
결과적으로는 그 상황을 극복하는 일들이 성장 요소가 되었다고는 생각이 되지만, 웹에 대한 웹로직이나 웹스피어 같은 개념 조차도 너무나 뒤늦게 알려주셔서, 실은 그것을 회사에서 배워야 한다고 생각한 부분이 오류였다는 걸 깨달은 시점은 좀 늦었습니다.
회사는 실적을 필요로 하고 성과를 필요로 하는 곳이지 개인의 성장을 도모하는 곳이 아니다.
개인의 성장을 같이 챙겨주는 회사와 비젼과 그런 스토리들을 들을때마다, 난 왜 저렇지 않지라는 생각들. 이 차올랐는데
결국 도움이 되는 건, 내가 스스로 배우고, 성장해야한다. 알아서 찾아야 하고 알아서 찾아서 해내는 것을 회사는 좋아한다는 것이었습니다.
좋은 사수가 있다면, 더 없이 좋겠지만, 사수가 없다면, 좋은 주변의 사람들은 사수처럼 포진 하는 노력도 필요하다는 생각을 해보네요.
7. 잘하는 사람에게 주늑 들지 말기
개발을 하다보면, 사람들을 만나다보면, 가끔 천재들을 만나게 됩니다.
천재는 천재입니다.
그들은 구글도 가고, 3가지 일을 동시에 하기도 하고, 풀스택을 완벽하게 해냅니다.
그들의 삶이 있다고 해서 막연한 동경과 할 수 없음에 대한 비관은 아무런 도움이 되지도 않습니다.
이 사실을 깨닫기로는 시간이 조금 더 필요 한데, 어떤 개발자든 각자의 이야기가 있고, 각자의 삶이 있고 이 모든 것이 존중받을 권리가 있다는 것이고, 그 부분을 알고 다양한 분야의 다양한 선배님들이 다양한 일을 하신다는 것.
그것을 깨닫는 일은 매우 중요한 것 같습니다.
누구나 잘할수도 못 할 수도 있습니다.
혹여 신입때 첫사수 질책으로 이 일을 떠나야 하나 고민하는 분이 있다면, 처음부터 잘하는 사람이 없다는 말은 거짓말이다. 그래도 모든 일은 하다보면 늘게된다. 이런 이야기를 해주고 싶네요.
만약 신입때
미리 좀 알았더라면 싶던 내용들,
혹여 필요한 곳이라면 어디든 이야기 하셔도 좋습니다.
- 치킨 올림
