반도체 설계 소프트웨어(EDA), 클라우드 인프라, AI 가속기 칩 설계 IP—국내 기술 생태계에서 이른바 ‘핵심기술 해외 의존’ 논란이 반복적으로 수면 위로 오른다. 뉴스를 접하는 개발자 입장에서는 막연한 위기감을 느끼면서도 정작 자신이 할 수 있는 일이 무엇인지 잘 보이지 않는다. 이 글은 그 질문에 직접 답하려 한다. 기술 주권 논쟁을 멀리서 구경하는 대신, 개발자 개인이 ‘핵심에 가까운 자리’를 어떻게 만들어가는지—커리어 설계 관점에서 구체적으로 다룬다.
‘핵심기술 의존’ 논란이 개발자 커리어에 던지는 진짜 질문
해외 의존 논란이 커질 때마다 정부 정책이나 대기업 투자 계획이 주로 언급된다. 그러나 이 흐름은 개인 개발자에게도 커리어 신호로 읽혀야 한다. 특정 기술 영역이 ‘국산화 필요’로 분류될 때, 그 분야를 실제로 다룰 수 있는 엔지니어는 구조적으로 희소해진다. 수요는 늘고 공급은 부족한 상황이다.
문제는 많은 개발자가 ‘핵심기술’을 추상적인 국가 과제로만 인식한다는 점이다. 실제로는 운영체제 내부 구조, 컴파일러 최적화, 네트워크 프로토콜 스택, 하드웨어-소프트웨어 인터페이스 같은 영역이 여기에 해당한다. 이 영역은 기술적으로 깊고 진입장벽이 높기 때문에 대부분의 개발자가 응용 계층 위에서만 일하다 커리어를 마무리한다. 바꿔 말하면, 한 단계만 더 내려가도 경쟁자가 급격히 줄어드는 구간이 존재한다.
따라서 ‘핵심에 가까운 자리’를 만든다는 것은 현재 위치에서 아래 계층으로 의도적으로 이동하거나, 그 이동을 위한 역량을 쌓는 과정이다. 이는 하루아침에 되지 않지만, 방향과 방법은 지금 당장 설정할 수 있다.
어느 계층에 있는지 먼저 파악하라
커리어 설계의 출발점은 자신이 현재 어느 추상화 계층에서 일하고 있는지를 파악하는 것이다. 소프트웨어 스택은 대략 다음 층위로 나눌 수 있다.
- 응용 계층: 웹 서비스, 모바일 앱, SaaS 제품 개발. 대부분의 개발자 인구가 여기 집중된다.
- 플랫폼·미들웨어 계층: 데이터베이스 엔진 내부, 분산 시스템 코어, 컨테이너 런타임, 클라우드 서비스 내부 구현.
- 시스템 소프트웨어 계층: 운영체제 커널, 드라이버, 컴파일러·인터프리터 구현, 런타임 환경(JVM, V8 등).
- 하드웨어-소프트웨어 경계: 펌웨어, 디바이스 드라이버, FPGA 로직, 칩 설계 검증 소프트웨어(EDA 툴체인).
현재 응용 계층에 있다면 당장 맨 아래로 내려갈 필요는 없다. 중요한 것은 한 계층 아래를 이해하고 그 경계 지점에서 가치를 만드는 포지션이다. 예를 들어 백엔드 서비스를 개발하면서 데이터베이스 내부 실행 계획과 스토리지 엔진을 깊이 이해하는 개발자는 같은 응용 계층 안에서도 훨씬 핵심에 가까운 자리를 차지한다.
한 계층 아래를 보는 구체적 방법
계층을 내려간다는 것이 추상적으로 들릴 수 있으므로, 현업에서 실제로 활용 가능한 방법을 짚는다.
사용하는 도구의 소스코드를 읽는 습관을 만든다. 오픈소스 생태계 덕분에 Linux 커널, CPython, PostgreSQL, Redis, LLVM 같은 시스템의 코드를 누구나 열어볼 수 있다. 처음에는 전체를 이해하려 하지 말고, 자신이 실제 업무에서 만나는 버그나 성능 이슈를 시작점으로 삼아라. “이 함수가 내부에서 어떻게 동작하는가”라는 질문 하나가 수십 줄의 커널 코드를 읽게 만든다.
시스템 프로그래밍 서적을 한 권 완독한다. 운영체제의 동작 원리를 설명하는 교재 중 위스콘신대 Remzi H. Arpaci-Dusseau & Andrea C. Arpaci-Dusseau가 저술한 Operating Systems: Three Easy Pieces는 온라인에서 무료로 공개되어 있으며, 현업 엔지니어가 실무 감각으로 읽기에도 적합하다. 이 책 한 권을 완독하고 나면 스케줄러, 메모리 관리, 파일 시스템이 왜 그렇게 설계됐는지를 이해하게 되고, 그 이해가 바로 한 계층 아래를 보는 눈이 된다.
컨트리뷰션을 통해 증명 가능한 기록을 만든다. 오픈소스 프로젝트에 패치를 올리는 행위는 이력서에 쓸 수 있는 실질적 증거가 된다. 처음에는 문서 수정이나 버그 리포트부터 시작해도 된다. 중요한 것은 프로젝트의 코드베이스를 실제로 들여다본 사람과 그렇지 않은 사람 사이의 간극이 채용 면접에서 명확히 드러난다는 점이다.
어떤 도메인이 ‘핵심에 가까운 자리’를 만들기 좋은가
모든 영역을 한꺼번에 공략할 수는 없다. 현재 국내외에서 해외 의존 이슈와 함께 수요가 커지고 있는 분야를 중심으로 방향을 좁혀보면 다음과 같다.
- 시스템 반도체·EDA: 칩 설계 검증, DFT(테스트 설계), RTL 시뮬레이션 관련 소프트웨어 엔지니어링. 전통적으로 전자공학 전공자 영역이었지만 소프트웨어 역량 수요가 빠르게 증가하고 있다.
- 컴파일러·런타임 최적화: AI 가속기와 GPU 연산을 위해 MLIR, LLVM 기반 컴파일러 최적화 엔지니어 수요가 국내외 반도체·AI 기업에서 꾸준히 늘고 있다.
- 클라우드 인프라 내부(스토리지·네트워킹): 국산 클라우드 강화 기조 속에서 분산 스토리지, 고성능 네트워킹 스택을 직접 구현할 수 있는 엔지니어는 지속적으로 찾기 어렵다.
- 임베디드·펌웨어: 자동차, 산업 IoT, 방산 분야에서 국산화 요구가 높으나 해당 역량을 갖춘 인력은 절대적으로 부족하다.
이 도메인들의 공통점은 학습 초기 진입 비용이 높다는 것이다. 반대로 말하면 조금만 깊이 파고들어도 시장 내 포지션이 빠르게 달라진다. 지금 당장 커리어 전환이 아니더라도, 부업 프로젝트나 사이드 스터디 형태로 해당 영역을 탐색하는 것만으로도 3~5년 후 선택지의 폭이 크게 달라진다.
포지션 이동을 위한 현실적인 6개월 로드맵
막연한 방향성이 아닌, 지금 당장 시작할 수 있는 행동 계획이 필요하다. 아래는 현업에서 응용 계층 개발을 유지하면서 한 계층 아래를 탐색하는 6개월 계획이다. 특정 도메인에 맞춰 조정할 수 있다.
- 1~2개월: 계층 파악 + 1개 토픽 선정. 현재 업무에서 가장 자주 부딪히는 블랙박스(예: DB 느린 쿼리, 메모리 증가 원인)를 하나 선택한다. 해당 시스템의 공식 문서나 소스코드를 읽으면서 내부 구조를 파악하고, 그 과정에서 생긴 질문을 TIL(Today I Learned) 형태로 기록한다.
- 3~4개월: 작은 구현 + 오픈소스 탐색. 선택한 토픽과 연관된 간단한 구현 프로젝트를 만든다. 미니 스케줄러, 간이 파일 시스템, 토이 컴파일러 등 작고 단순한 버전으로 충분하다. 동시에 관련 오픈소스 프로젝트의 이슈 트래커를 구독하고 코드를 정기적으로 읽는다.
- 5~6개월: 공개 + 네트워크. 만든 것을 블로그 글이나 GitHub 레포로 공개한다. 오픈소스에 작은 기여(문서, 버그 픽스)를 하나 이상 완성한다. 해당 도메인을 다루는 커뮤니티나 컨퍼런스(예: 커널 스터디, LLVM 관련 밋업, 임베디드 오픈소스 행사)에 청중으로라도 참여해 현장의 언어와 이슈를 체감한다.
6개월 후 포지션이 드라마틱하게 바뀌지 않을 수도 있다. 하지만 면접에서 “이 시스템의 내부를 열어봤고 이런 구현을 직접 해봤다”고 말할 수 있는 것과 없는 것은 전혀 다른 출발점이다.
핵심에 가까운 자리는 만들어지는 것이 아니라, 스스로 만드는 것이다
해외 기술 의존 논란은 앞으로도 반복될 것이다. 그 때마다 정책 발표와 예산 투입 이야기가 나오겠지만, 실제로 그 자리를 채우는 것은 결국 개발자 개인의 역량이다. 좋은 소식은 이 자리가 학벌이나 운이 아니라 의도적인 학습과 공개적인 실천으로 만들어진다는 점이다.
어느 계층에서 일하든 한 단계 아래를 들여다보는 습관, 자신이 만든 것을 공개하는 습관, 그리고 현장의 언어를 이해하는 감각—이 세 가지가 쌓이면 5년 후 커리어 선택지가 지금과는 다른 차원에 놓이게 된다. ‘핵심에 가까운 자리’는 정해진 타이틀이 아니라, 스스로 설계하고 점진적으로 이동해가는 포지션이다.
누스쿨 커뮤니티에는 시스템 소프트웨어, 인프라, 반도체 소프트웨어 분야에서 실제로 커리어를 쌓아온 멘토들이 있다. 방향이 막힌다면, 혹은 자신의 현재 위치에서 어떻게 한 계층 아래로 이동할 수 있는지 구체적인 조언이 필요하다면 멘토링을 활용해보길 권한다. 막연한 목표를 실행 가능한 계획으로 바꾸는 것, 그것이 멘토링이 가장 효과적으로 쓰이는 순간이다.
💬 댓글 0