SI에서 서비스 개발로: 채용 요건을 학습 계획으로 바꾸기
SI에서 서비스 팀으로 옮긴 데에는 도움과 운이 컸습니다. 반복 가능한 전략은 목표 채용 요건을 읽고 관련 역량과 경험을 만드는 것입니다.
출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다.
gpt-5.6-sol모델을 사용해 생성·편집했습니다.
SI와 솔루션 개발에서 소비자 서비스 회사로 옮긴 과정은 잘 짜인 계획이 아니었다. B2C 서비스를 만들고 싶다는 욕구는 강했지만 가는 길을 몰랐다. 먼저 경험한 개발자가 Spring을 알려 주고 공부할 것을 짚어 줬으며, 나중에는 기회도 소개해 줬다. 다른 사람의 도움과 운이 결과에서 큰 비중을 차지했다.
커리어 이야기를 나중에 완벽한 전략처럼 고치면 이 부분을 잃는다. 책을 많이 읽고 코드를 많이 쓴 것도 사실이다. 그 노력은 기회를 잡을 준비가 됐다는 뜻이지, 기회를 혼자 만들었다는 뜻은 아니다.
이미 가진 경험에서 출발한다
처음에는 펌웨어에서 C와 C++을 썼고, 이후 SI와 솔루션 프로젝트에서 C#과 ASP.NET을 다뤘다. Spring은 과제에서 조금씩 만났고 초반에는 제대로 이해하지 못한 채 동작만 시키기도 했다. 파견과 출장, 고객사 프로젝트가 원하던 제품 개발 경로는 아니었지만 엔지니어링 경험은 계속 쌓였다.
프로젝트 사이에 시간이 나면 책을 봤다. 신뢰하던 개발자가 회사 일 바깥의 예제를 보여주고 구체적인 학습 방향을 알려 줬다. 마지막 무렵에는 Spring으로 만든 프로젝트도 있었으므로 다음 역할은 완전한 제로에서 시작한 점프는 아니었다.
옮긴 서비스 회사는 작았다. 백엔드만 한다는 좁은 역할도 없었다. 잘하지 못하는 화면 작업까지 서비스에 필요한 것을 맡았다. 전환의 핵심은 좋은 간판이나 직함이 아니라 배우고 싶었던 소비자 서비스를 실제로 운영하는 경험을 시작했다는 데 있었다.
채용 공고를 학습 목차로 바꾼다
같은 전환을 더 의도적으로 해야 한다면 가고 싶은 역할부터 정할 것이다. 해당 회사들의 채용 공고를 모아 비교한다. 어떤 언어와 프레임워크, 배포 경험, 제품 경험이 반복되는가? 그중 직접 설명하고 보여줄 수 있는 것은 무엇이고 이름만 들어 본 것은 무엇인가?
이 비교는 ‘SI를 벗어나고 싶다’는 막연한 바람을 학습 계획으로 바꾼다.
- 구체적인 목표 역할이나 회사군을 고른다.
- 채용 공고에서 반복되는 요건을 뽑는다.
- 부족한 항목을 공부하고 연습한다.
- 관련 기술을 사용하는 결과물을 만든다.
- 가능하다면 로컬 코드에서 멈추지 않고 출시하고 운영한다.
이 과정을 따른다고 채용이 보장되지는 않는다. 채용에는 지원자가 통제할 수 없는 시기와 인맥, 회사 사정이 있다. 다만 눈에 띄는 기술 책을 무작정 읽는 것보다는 반복 가능한 방법이다.
사람의 도움과 실행을 함께 본다
멘토나 추천이 준비를 대신하지는 않는다. 반대로 준비했다고 해서 관계가 중요하지 않은 것도 아니다. 내 경우 무엇을 배워야 하는지 알려 주고 역할을 소개한 사람이 경로를 바꿨다. 이를 우연이라며 지워 버리면 커리어에서 얻은 근거도 함께 사라진다.
그 소개도 Spring을 배우지 않고, 익숙한 스택에만 머물고, 완벽히 정의된 백엔드 자리만 기다렸다면 의미가 없었을 것이다. 제품 일을 하겠다는 뚜렷한 목표와 작은 팀에서 넓게 실행할 만큼의 연습이 함께 필요했다.
교훈은 거창하지 않다. 원하는 일을 더 정확히 고르고, 회사가 요구하는 것을 살핀 뒤 코드와 운영 경험으로 빈틈을 메운다. 믿을 만한 사람이 방향을 줄 때는 도움을 받는다. 이직에는 여전히 운이 필요할 수 있지만, 준비는 그 운이 작동할 자리를 만든다.