업무, 업계, 처우, 연봉 등에 대한 이야기
개발자 부트캠프 열풍이 식어가고 있지만 요즘도 입문하는 사람들이 종종 연락을 해서 물어본다.
그중 자주 질문하는 내용이 이렇다.
- 비전공자라고 처우/대우가 다른지
- 어떤 업무를 하는지
- 어떤 언어/기술을 선택하는 게 좋은지
- 등등
하나씩 답변을 해보려고 한다.
체감상 비전공자 비율이 꽤 높은 직군인데 10명 모이면 4,5명은 비전공자다.
정확한 통계를 찾진 못했으나 실제 컴퓨터 공학을 전공하고 개발자 커리어를 포기한 경우도 꽤 많으니 전공자가 아니라고 해서 딱히 자격지심을 가질 필요는 없다.
이 바닥에서 가장 무서운 애들은 초등학교 때부터 '혼자' 공부해서 개발 시작한 애들이다.
소수지만 분명히 존재하고 그다음은 특성화 고등학교를 거쳐 바로 커리어를 시작한 회사에선 막내지만 대부분 실력이 출중한 친구들이다.
그러니 학교/전공이 꼭 중요한 건 아니다.(다만 어디서나 아웃라이어는 존재한다.)
안타깝지만 보통은 좋은 환경이 아닐수록 이런 차별이 존재할 수 있다. 특히 연봉을 후려치기 하려고 하는 회사일수록 대표가 이런 류의 가스라이팅을 하기도 한다. 일을 하게 되면 알겠지만 생각보다 전공을 해도 못 하는 개발자도 존재하고, 전공하지 않고도 뛰어나게 잘하는 사람들도 존재한다. 보통은 얼마나 계속 관심을 갖고 학습을 하는지에 달려있지 전공 여부만으로 갈리지 않는다.
이건 약간 경영학 전공하면 사업 잘하는지와 비슷한 질문 같기도 하다.
생각해 보면 한국 특성상 성적 맞춰서 과를 선택하는 경우도 많으니 그리 크게 신경 쓸 필요는 없고, 다만 부족한 전공지식을 쌓으려는 노력을 계속하는 건 중요하다. 부족함을 느끼고 채우는 사람과 그렇지 않은 사람은 꽤 격차가 벌어지기도 하니 말이다.
첫 회사로 중소 SI(70명 규모, 연매출 100억대)를 갔는데 연봉이 2949였다(심지어 3개월 간 수습기간은 70% 지급). 신입이 6명이었고 이 중 전공자가 3명, 비전공자 3명이었다. 여담이지만 6명 중 DB 시험 1등 했다. 이 중 4명(전공 2, 비전공 2)이 수습 통과 했는데, 나는 수습만 하고 이직했다. 그때, 수습 통과한 전공자 2명은 아직 이 회사에 다니고 있는데 놀랍게도 연봉은 아직 3000대로 알고 있다.
그러니 전공/비전공은 너무 크게 신경 쓰지 않아도 된다.
연차에 따라 다르겠지만 연차가 높아질수록 회의 지옥에 빠진다.(아직 경험하진 못 했으나 대부분 시니어 개발자를 보면 이렇다.)
나 같은 1~3년 차 주니어 개발자도 커뮤니케이션 70%, 개발 30% 정도다.
일이 익숙해질수록 회의, 커뮤니케이션 비중이 더더욱 높아진다.
이 커뮤니케이션엔 아래 내용이 포함된다.
- 코드 리뷰
- (어떤 업무를 위해) 다른 팀에 업무 요청 하는 방법에 대해 사내 문서/개발 문서 탐색 후 필요한 업무 요청
- 함께 업무를 하는 PM/개발자/기획자에게 질문 및 토론
등등
커뮤니케이션이 잘 되면 개발은 생각보다 빠르게 끝난다. 업무 진행 속도도 당연히 빨라질 뿐 아니라, 리뷰도 한결 수월해진다. 어떤 방식으로 개발을 할 것인지, 어떤 개발 컨벤션(다 같이 어떤 형태로 개발을 맞춰서 할 것인지를 말한다)을 맞출 것인지 등이 주 커뮤니케이션 대상이다. 연차가 높아질수록 다른 직군과의 커뮤니케이션 능력이 더 중요해진다. 이 기획이 정말 필요한 것인지, 이대로 개발을 했을 때 어떤 문제가 있을 수 있으니 이런 방향으로 개발은 하기 어렵다든지 등 마치 악마의 변호인이 된 것처럼 안됩니다! 를 이유를 잘 설명하며 말할 수 있어야 한다. 그러기 위해선 기획을 빠르게 파악해서 견적을 볼 수 있는 능력이 필요해진다.
커뮤니케이션 스타일은 보통 2가지로 갈린다.
1. 어떻게든 혼자서 많은 걸 해결하려고 하는 성향의 사람
2. 조금 찾아보고 바로 동료에게 요청을 하는 성향의 사람
둘 다 장단점이 있는데 우선 1번의 사람은 초반엔 시간이 걸리지만 중후반이 갈수록 알아서 잘한다.
2번의 사람은 초반부터 업무 요청을 통해 빠르게 업무를 해결하나 같은 질문을 하는 경우가 종종 발생한다.
1번의 사람은 너무 시간이 길어지지 않게 주의해야 하고, 2번의 사람은 같은 질문을 하지 않게 잘 기록을 해두면 좋다. 개인적으로는 1번, 2번 성향 둘 다 겪어보니 누가 더 낫고 그런 건 아니다.
개발은 우리가 생각하는 그 프로그래밍 언어와 프레임워크의 조합으로 기능을 만드는 걸 말한다.
보통은 기획과 피그마가 있지만, 없는 상태에서 개발자가 기획에 참여하며 개발을 하는 경우도 있다.
IT 회사는 3가지 종류로 나뉘는데 SI/SM/서비스 회사다.
- 프로젝트 수주를 받아 개발을 한 후 납품하는 형태
- B2B, B2G(정부 프로젝트를 받는 형태)도 있고, 대기업의 경우 사내 프로젝트를 받기도 함
- 대기업 중엔 LG CNS, 현대오토에버, SK C&C 등이 있다.
- 대부분 기획, 설계는 위에서 이미 정해져 있고, 개발자들은 그대로 개발만 함
- 보통 기술 스택이 꽤 노후된 경우가 많고, 코드 퀄리티가 높지 않은데 프로젝트 납품 이후 안정화 기간이 지나면 신경을 쓰지 않는 경우가 많기 때문이다.
- SI 특성상 갑 회사에 납품기한, 요구사항을 맞춰야 하는 것 때문에 잦은 야근 + 이해 안 되는 요구사항 등의 이유로 악에 바친 개발자들이 주석에 욕을 남기기도 한다.
간단하게 말하면 시스템을 만들어 납품하는 업무가 주라고 생각하면 된다.
자세한 정보는 아래 글을 참조하면 도움이 될 듯싶다.
https://yozm.wishket.com/magazine/detail/2432/
https://yozm.wishket.com/magazine/detail/2407/
- 자사 솔루션을 판매하는 형태
- 이미 판매한 솔루션을 계속 유지보수, 관리하는 업무를 함께 진행
- SI에서 개발 완료된 프로젝트를 SM에서 인수인계받아 운영하기도 함
- SM도 꽤 오래된 개발 스택으로 개발된 프로젝트를 운영해야 하는 경우가 많다. 요즘 자바 22, 23 얘기하고 있는데 1.6, 1.5로 된 프로젝트를 유지보수 하기도 한다.(10년 전에 만들어진 프로젝트 이야기)
- 운영 업무가 주로 되기 때문에 SI보다 프로젝트를 좀 더 깊게 이해해야 하는 경우가 많다. 성능 개선도 이 쪽에서 더 많아 이력서 쓰기엔 좀 더 좋다.(보통은 SI에 비해 조금 더 여유롭다.)
간단하게 말하면 만들어진 시스템을 운영하고 유지보수하는 업무가 주라고 생각하면 된다.
자세한 정보는 아래 글을 참조하면 도움이 될 듯싶다.
https://yozm.wishket.com/magazine/detail/2533/
- 네카라쿠배는 이 서비스 회사를 말한다.(스타트업도 여기 포함된다.)
- 말 그대로 자사 서비스를 운영하면서 기능을 개발한다. 특정한 고객의 요구사항은 SI처럼 정해진 시간까지 반드시 해야 할 일은 아니다.
- 코드 품질을 꽤 신경을 많이 쓴다. 테스트 코드를 쓰거나 스택이 꽤 최신이라면 보통은 서비스 회사다.
- 스타트업의 경우 개발자가 기획부터 참여하기도 한다. 특히 DX(Developer Experience)가 중요한 업무를 하게 된다면, 개발자를 대상으로 개발을 하기 때문에 개발자가 기획자 그 자체가 되기도 한다. 보통 이런 업무는 사내 개발자를 위한 개발 툴을 만드는 정도로 개발에 진심인 회사들이거나 개발자를 위한 툴을 만드는 곳이 그렇다.(IDE, DB 등)
- 비중이 10% 정도 될 듯싶다. 보통 SI, SM에선 프런트/백엔드 구분 없이 개발을 하기도 하는데 보통 서비스 회사에선 직군이 대부분 구별되어 있다.
- 스카웃 제의도 많다. 꼭 그런 건 아니고 대기업 SI에도 꽤 제안을 많이 받는다.
- 현재 내가 다니는 회사도 서비스 회사(스타트업)에 속한다.
참고
https://brunch.co.kr/@rememberapp/209
회사별로 업무 스타일은 차이가 있을 수 있다.
어쩌다 보니 SI, SM, 서비스 회사 모두 경험을 해봤고 모두 장단점이 있는데 성향에 따라 자신한테 맞는 형태가 있다. 개인적으로는 서비스 회사 쪽이 더 맞아서 이 쪽을 희망했고 이 쪽으로 오게 되었다.
해보면 안다. 프런트도 해보고, 백엔드도 해보고, 인프라도 해보고, 앱 개발도 해보면 자신이 어떤 분야에서 즐거움을 느끼는지가 다르다. 언어도 마찬가지라 이것저것 해보면 된다. 물론 시간이 걸린다. 그리고 처음부터 모든 게 다 즐겁진 않다. 개인적으로는 초반엔 프런트에 즐거움을 느껴 프런트엔드 개발자로 커리어를 준비했으나 빠른 취업을 위해 Java/Spring 백엔드로 커리어를 시작했고, 하다 보니 백엔드에도 즐거움을 느껴 계속 백엔드로 커리어를 쌓게 됐다.
하나 더 미리 말 하지만 2024년 기준 프런트엔드 취업 시장은 꽤 힘들다. 앱 개발은 더 힘들다.
그중 특히 iOS, 플러터 등은 더더욱 힘들다.
그렇지만 그게 즐거운 사람들은 그 힘든 길을 뚫고 간다.
백엔드 커리어를 쌓으면서도 프런트 공부는 종종 했다. 첫 이직 할 때 만든 포트폴리오도 풀스택으로 React + Java/Spring으로 만들었다. 백엔드 개발자여도 보통 어드민 화면은 직접 만들기도 하니 프런트를 익혀서 나쁠 것은 없다. 작년에도 Next.js 튜토리얼 한 번 정도는 해봤으니 꾸준히 보긴 하는 듯하다. (그렇지만 이미 백엔드가 더 즐겁긴 하다.)
목적이 중요하다고 생각한다.
1. 특정 언어나 프레임워크에 재미와 매력을 느끼는 사람들
이런 경우는 힘들더라도 자기 하고 싶은 언어/스택으로 가야 한다.
이런 케이스는 워낙 좋아해서 남들보다 훨씬 깊게 한다. 그게 취업으로 이어지기 때문에 하는 걸 추천한다.
2. 언어나 프레임워크 딱히 잘 모르겠고 취업이 가장 큰 목적인 사람들
내 경우인데 이런 경우는 Java/Spring 추천
한국에서 수요가 가장 많다. 우선 이력서 쓸 회사가 많다. 한국은 대부분 이 스택을 쓴다.
여기서 좀 더 벗어나야 Kotlin, Spring 정도인데 이건 Java와 크게 다를 건 없어 힘들진 않다.
만약, 해외 생각이 있다면 다니면서 JS 풀스택을 좀 준비해 두면 좋을 듯싶다. 외국은 Java/Spring 보단 JS, PHP가 많은 것 같으니 말이다.
3. 프리랜서를 하고 싶다.
이 경우는 PHP/Laravel 혹은 JS 풀스택 추천
보통 찍어내기 좋은 경우는 이 쪽이다. 나도 경험이 없는 영역이지만 크몽이나 위시켓 같은 개발 외주 사이트를 보면 자주 보인다. 스타트업 중엔 이렇게 외주로 받은 프로젝트가 PHP로 되어 있어서, 회사가 성장하고 난 후엔 개발자를 구하지 못해 울며 겨자 먹기로 프로젝트를 마이그레이션(같은 기능을 하는 서비스를 다른 언어/스택으로 개발하는 것) 하기도 한다. 이런 회사는 채용공고에도 PHP와 Java가 함께 쓰여있기도 하다.
한국 특성상 Java/Spring 개발자 비율이 압도적으로 높기 때문에 채용이 힘들어서 보통 그렇다.
4. 희귀한 개발자가 되고 싶다.
Python, Go, Rust 하는 곳을 찾아가면 된다.
보통 이런 언어 하는 회사는 사람을 꽤 가려 뽑는다. 남들이 많이 안 하는 언어는 반대로 공통적으로 쓰는 표준이 적다는 말이기도 하고 이슈가 생겼을 때 자료를 찾기가 어렵다. 3개 중에선 Python이 그나마 찾기 편할 것 같으나 그것도 영어로 찾을 때 기준이다. Go, Rust로 갈수록 GitHub Issues를 겨우 뒤져서 해결이 가능할 지도 모른다. 그렇지만 주변에 고연봉 받는 개발자가 가장 많은 언어도 이 쪽이었다.
대충의 가이드라인이긴 하지만 도움이 되면 좋겠다.
여기까지가 기본적인 내용이고 연봉까지 쓰려고 했으나 이건 다음 글에 쓰려고 한다.
연봉이 워낙 천차만별이라 글 하나로 다뤄도 될 듯싶다.
그럼 오늘은 여기까지!