본문으로 건너뛰기Skip to content 1:1 문의 — [email protected]로 이메일 작성 Contact us — email [email protected]

팀 가이드: Compiler / SDK (AI 가속기 SW): 모델을 칩 위에서 실행시키는 소프트웨어 스택

NPU Compiler와 SDK의 역할, 공개 공고에서 확인되는 학위 요건의 차이, 논문과 오픈소스 기여를 과장 없이 보여주는 방법을 정리했습니다.

NPU software stack from model graph to executable program
VLSI Korea original editorial figure; sources checked Aug. 13, 2026.

편집 업데이트 (2026년 8월 13일): 공개 근거가 없던 회사별 연봉 숫자와 채용 규모, 학위·논문·오픈소스 기여의 보편적 순위를 삭제했습니다. 학위 요건은 현재 공개된 개별 공고의 minimum qualification과 preferred qualification을 나눠 다시 확인했습니다.

NPU(Neural Processing Unit, 신경망처리장치) Compiler/SDK 팀은 학습 프레임워크에서 만든 모델을 가속기에서 실행할 수 있는 프로그램으로 바꾸고, 그 프로그램이 장치에서 동작하도록 연결하는 소프트웨어를 만든다. 다만 Compiler, Runtime, SDK, Kernel의 경계와 채용 요건은 회사와 공고마다 다르다. 이 글은 2026년 8월 13일에 확인한 공개 제품 문서와 채용 공고만을 근거로 범위를 좁혔다.

Compiler and SDK responsibility map from framework input through runtime and application APIs
Compiler and SDK responsibility map. VLSI Korea original figure; source: FuriosaAI public software documentation, checked Aug. 13, 2026.

1. Compiler와 SDK가 맡는 일

퓨리오사AI의 공개 소프트웨어 문서는 Compiler가 DNN(Deep Neural Network, 심층신경망) 모델을 최적화하고 NPU에서 실행 가능한 코드를 생성한다고 설명한다. Runtime은 컴파일된 프로그램을 분석해 작업을 실행하고 자원을 스케줄링하며, Python/C SDK는 애플리케이션이 세션을 만들고 추론을 호출하는 인터페이스를 제공한다.

공개 공고에서 확인되는 Compiler 업무는 다음처럼 묶을 수 있다.

  • 그래프와 IR 최적화: 연산 그래프를 바꾸고, IR(Intermediate Representation, 중간표현)의 여러 단계에서 변환과 스케줄링을 수행한다.
  • 하드웨어 인지 최적화: scratchpad, buffer memory, instruction scheduling과 backend code generation을 장치 제약에 맞춘다.
  • 프레임워크 연결: Torch 같은 프레임워크의 모델을 컴파일 경로에 연결하고 지원되지 않는 연산과 정확도 문제를 추적한다.
  • 검증과 디버깅: 변환 전후의 의미가 같은지 test로 확인하고, 성능 회귀와 numerical mismatch의 원인을 좁힌다.

이 네 영역을 한 팀이 모두 맡는지, Compiler·Kernel·Runtime·SDK 팀으로 나누는지는 조직마다 다르다. 공개되지 않은 조직 규모나 내부 보고선은 일반화하지 않는다.

2. 필요한 기술을 공고 단위로 읽는 법

특정 도구를 모든 회사의 필수 조건처럼 말할 수는 없다. 대신 지원하려는 공고의 task와 qualification을 아래 세 층으로 나눠 보는 편이 정확하다.

  • 언어와 소프트웨어 기본기: C++와 Python, test, code review, Linux 기반 debugging.
  • Compiler 기본기: transformation pass, dataflow, scheduling, memory allocation, code generation, IR 설계.
  • 하드웨어·ML 연결: memory hierarchy와 병렬 실행, tensor 연산, quantization, 모델 구조와 inference 병목.

MLIR, LLVM, Triton은 이 능력을 연습하고 보여줄 수 있는 공개 생태계다. 다만 도구 이름만 적는 것으로는 부족하다. 입력, 실패 증상, 바꾼 pass 또는 kernel, test, 성능·정확도 결과를 함께 설명해야 한다.

3. 학사와 석사 요건: 회사가 아니라 공고를 확인한다

현재 공개 공고만 놓고 보면 두 회사의 기준은 같지 않다.

Side-by-side snapshot of public Compiler role qualifications at FuriosaAI and Rebellions
Public compiler posting snapshot. VLSI Korea original figure; sources: FuriosaAI and Rebellions careers, checked Aug. 13, 2026.

따라서 특정 회사가 학사 지원자를 항상 받거나 받지 않는다고 단정할 수 없다. 공고의 최소 요건은 지원 가능한 하한을 뜻하지만 실제 신입 선발 비율을 공개하지는 않는다. 같은 회사 안에서도 role과 시점이 바뀌면 요건이 달라질 수 있으므로 지원 직전 원문을 다시 확인해야 한다.

4. 논문과 오픈소스 contribution 중 무엇이 더 중요한가

공개된 두 공고에는 논문, MLIR·LLVM·Triton contribution, 인턴, GPA의 일률적인 점수표가 없다. 그래서 하나의 보편적 순위를 만들 수 없다.

  • Research 성격이 강한 지원: 논문은 문제 설정, 선행 연구, 실험 설계와 결과를 검증받았다는 증거가 될 수 있다. 지원 직무의 compiler·architecture 문제와 직접 연결되는지가 중요하다.
  • Productization 성격이 강한 지원: upstream contribution이나 production project는 기존 codebase 이해, review 대응, test와 유지보수 능력을 보여줄 수 있다.
  • 가장 강한 설명 방식: 논문의 아이디어를 재현해 code와 benchmark로 연결했거나, 공개 contribution에서 correctness·성능 문제를 해결한 과정을 함께 보여준다.

지원자는 명성이나 개수보다 본인이 소유한 범위를 분명히 써야 한다. 공동 논문이라면 본인의 실험과 구현을, 오픈소스라면 변경한 코드와 review·test를, 인턴이라면 공개 가능한 artifact와 측정 방법을 구분한다.

Evidence map for research and productization Compiler roles
Evidence map for research and productization tracks. VLSI Korea original figure; editorial synthesis from the cited public postings.

5. 보상 정보: 검증되지 않은 숫자는 싣지 않는다

이번에 확인한 두 공식 Compiler 공고에는 직무·level별 공개 pay band가 없다. 따라서 회사별 신입 연봉이나 해외 total compensation을 숫자로 비교하지 않는다. 독자 제보와 개인 offer는 오류를 찾는 단서가 될 수 있지만, 회사 정책이나 시장 범위를 증명하는 공개 근거는 아니다.

실제 offer를 비교할 때는 다음 항목을 분리한다.

  • base salary와 고정 현금
  • 성과급을 포함한 total cash
  • RSU·스톡옵션의 vesting, 행사가격, 희석과 유동성
  • signing bonus, 퇴직금, 복지와 relocation 조건

회사·직무·지역·career level·기준일과 보상 정의가 같은 공식 band가 공개되거나, 같은 범위를 독립적으로 지지하는 공개 자료가 확보될 때만 숫자를 추가한다.

6. 준비 순서

  1. 공고를 한 장으로 분해한다. responsibility, minimum, preferred를 표로 만들고 각 항목에 자신의 증거를 연결한다.
  2. 작은 compiler pipeline을 완성한다. 입력 모델이나 IR, 한두 개의 pass, code generation 또는 실행, test까지 끝까지 연결한다.
  3. 실패 사례를 문서화한다. 잘못된 결과나 느린 kernel을 어떻게 재현하고 원인을 좁혔는지 log와 측정 기준을 남긴다.
  4. 공개 review를 경험한다. 작은 문서·test 수정부터 시작해 maintainer 피드백에 대응하고, merge 여부보다 review 과정과 배운 점을 기록한다.
  5. 지원 트랙에 맞춘다. research role은 논문의 mechanism과 실험을, product role은 production code·debugging·performance artifact를 앞세운다.

7. 지원 전 체크리스트

  • 공고 URL과 확인 날짜를 저장했는가
  • minimum과 preferred qualification을 구분했는가
  • 학위, 논문, 오픈소스 중 직무와 직접 연결되는 증거를 골랐는가
  • 본인이 바꾼 코드, test, 측정 결과와 한계를 설명할 수 있는가
  • 보상 항목의 정의가 같은지 확인했는가

출처

다른 팀 가이드 보기

댓글

VLSI KOREA BRIEFING

반도체를 읽는 안목, 메일함으로.

엔지니어의 시각과 산업의 흐름을 함께. 무료로 구독하세요.

이미 구독 중인가요? 로그인