개발자 취업하고 생각해보니 - FA에선 증명 못 하는 내 능력
- 블라블라
- 2016. 10. 15.
괴이한 제목의 글입니다만, FA에서 다른 업종으로 이직을 결심하고 나니 만감이 교차하네요. FA를 떠나게 되는 기분도 묘합니다.
이 글은 왜 FA 업체에선 내 능력을 증명하지 못하는 것일까에 대한 글입니다.
- 모든 FA 업체가 이런 건 아닙니다.
- 다른 계열사를 보니 우리 회사완 정반대. 사장님이 달라서 그런 듯. 사장님이 ...
9. 나도 증명 못 하는 내 능력
첫째,
제가 석사 3학기 때부터 연구실 후배들에게 하던 말이 있었습니다. 학기가 끝나면 놀 땐 놀더라도 책이나 신문도 챙겨보라고 말이죠. 글을 읽는다는 게 귀찮고 까다로운 일이라는 걸 저도 모르는 건 아닙니다.
졸업한 뒤에, 회사에 들어가면 많은 문서와 소스를 보게 될텐데, 미리 예방하는 차원에서 읽고 쓰는 연습을 해보자는 취지였습니다. 실제로 홈커밍날 선배들에게 들은 이야기이기도 했습니다.
문제는, 실제로 취업하고 보니 문서를 볼 일이 없다는 것입니다. (문서화 개념이 없는 회사 / 프로그래머)
둘째,
모든 기술에 민감할 필요는 없지만, 적당히 민감할 필요는 있습니다. 대학원생이 할 일 중 하나가 논문 읽기입니다. 그래서, 논문을 읽긴 읽었는데 교수님이 말씀하신 범위를 벗어난, 전혀 새로운 논문도 종종 봤었습니다.
적당히 민감하자는 취지였죠. (개발자에게 실제로 도움이 됩니다)
졸업하기 전엔 전자 신문과 네이버 뉴스 IT에 자주 들어갔습니다. 매일 들어가서 새로운 소식을 접해보고 이해해보려 노력했었습니다. 역시나, 적당히 민감하자는 취지에서였습니다. (다행히도, 이 버릇만큼은 아직도 유지하고 있습니다)
문제는, 실제로 취업하고 보니 회사 내 개발자들이 다루는 기술은 멈춰있습니다. (맨날 했던 거 똑같이)
셋째,
오로지 개발자들만 인수인계 절차가 단순합니다. 퇴사하는 사람은 소스만 남기니, 받는 사람도 오직 소스 코드만 ... ㅠㅠ 고로, 새로 입사한 사람은 맨땅에서 소스 코드만 보고 모든 것을 유추해야 합니다.
도무지 이런 무식한 짓을 왜 하고 있어야 하는가?
하루에도 열두 번은 넘게 생각해 봤었습니다. 기본적으로 전자, 전기 쪽 지식이 없는 사람들에겐 힘든 과정입니다. 매우 힘듭니다. 컴공 나온 사람에게도 힘듭니다.
문서화에 아무 의미를 부여하지 않으면서, 모든 것을 파악하라는 의중이 궁금했었습니다. 맨땅에 헤딩해서 얼마나 버티는가 ... 그런 싸구려 의식을 시험해 보려는 것이었을까요?
몇 달 후, 연봉 협상에 들어가게 되는데, 도대체 제 능력은 어떤 방식으로 파악됐을까요?
그리고 장비회사 개발자니 장비를 이해하는 건 당연합니다.
문제는, 장비 공부는 자기 계발 맞는데 디자인 패턴을 공부하면 시간 낭비랍니다.
실제로 회사에서 저녁 먹고 디자인 패턴을 잠깐 보고 있었는데 ...
"회사에서 책을 왜 봐? 그리고 그런 거 도움이 안 돼"
넷째,
프로그래머로서 고민을 많이 해봤습니다. 주석을 이렇게 적어야 보기 쉬울까, 네이밍을 이렇게 해야 이해하기 쉬울까, 문서 양식은 이런 게 좋을까 저런 게 좋을까, 테스트 과정에선 어떤 체크 리스트가 필요할까.
문제는, 윗분들이 됐다고 하면 된 거고 아니라고 하면 아닌 것이었습니다(기준이란 건 그날의 기분). 다시 말씀드리지만, 문서화 개념이 없는 회사.
다섯째,
회사에서 일하는 직원들은 공동의 목표를 향해 달려가는 줄 알았습니다.
"니가 만든 거라 난 잘 몰라"
"니가 손대서 이젠 잘 몰라"
개인이 처음부터 끝까지 책임지는 자세는 좋다고 생각합니다.
그러나, 회사 일이란 게 어디 혼자만 처음부터 끝까지 할 수 있을까요?
이 사람 저 사람이 함께 일할 수도 있으니 문서화와 네이밍 규칙은 아주 기본적인 것입니다. 헌데, 이런 걸 쓸데없다 무시하고 자기네들 마음대로 사용하니, 이 사람 것도 이해해야 하고, 저 사람 것도 이해해야 합니다.
그동안 회사는 잘 굴러왔으니 이해 못 하는 건 새로 입사한 네놈의 문제다 ... 지금 개발자들에겐 아무 문제가 없다 ... 라는 식으로 손가락질하는 이해할 수 없는 상황도 발생합니다.
헌데, 진짜 큰 문제는 ... 나만 손댄 건 내 책임이지만 너랑 나랑 손댔으면 네 책임이라는 겁니다.
이거에 대해선 할 말이 많은데, 회사에 규격화된 규칙을 갖고 일하는 게 맞는 거라 말을 해도, 내 스타일 건드리는 게 건방진 것이며, 남의 제어 소스 보고 왈가왈부하는 것도 건방지답니다.
누군가 프로젝트를 진행하다 다른 업무에 치여 소스를 다른 사람에게 넘기면, 그 사람은 그 소스를 모두 삭제하고 본인 스타일로 다시 작성합니다.
여섯째,
입버릇처럼 "난 실력이 모자라"라는 사람들이 특히 다섯 번째에 민감합니다. 자기 실력이 모자란 걸 알면 배우려는 노력이라도 해야지 ... 허구헌날 장비에 붙어있는 부품 스펙은 왜 쳐다보는 건지 ... 적당히 이해하고 나면 개발자로서의 능력을 키우는 데 중점을 둬야 합니다.
다른 분야 개발자도 마찬가집니다.
당연히 내가 만드는 프로그램의 성격과 고객이 원하는 게 뭐인지 알려면 제어 장비 건 각종 개념이건 이해를 해야 합니다. 뭐든 적당한 게 좋은데 ...
문제는, 프로그래머들이 기구팀 엔지니어처럼 군다는 겁니다(회의 시간이 가관. 프로그래머인지 기구팀 엔지니어인지 구분 불가). 이러니, 다른 팀들은 발전하는데 SW팀만 맨날 제자리.
모든 장비 회사가 이런 건 아닙니다.
마지막으로 한마디 하자면, 개발자로 길게 가고 싶다면 장비 회사는 피하라 조언(관련글)하고 싶습니다. (장비 회사에서 길게 가고 싶은 사람은 제외).
장비회사 개발자들이 말하는 실력 좋은 개발자란 개념 자체가 이상합니다. 설계 잘하고 문서 잘 쓰는 게 프로그래머의 능력 중 하나라고 생각했는데, 쓸데없는 짓을 왜 하냐고들 말을하니 ...
ps1. 거듭 말씀드리지만 모든 장비 회사가 그런 건 아닙니다. 장비 회사일수록 가능성이 높다는 정도랄까.
ps2. 내가 그 조직에 융화되어 살 것인가 다른 곳으로 갈 것인가.
ps3. 삼성이나 LG나 하이닉스에서 하위 업체에 소스와 관련된 문서를 달라고 했을 때, 말이 되는 문서를 만드는 회사가 과연 몇이나 될까?