시스템 SW 개발자 이력서 예시

하드웨어와 사용자 프로그램 사이에서 장치가 실제 서비스에 투입되기까지 필요한 소프트웨어를 개발해 온 공서진입니다. 가람스토리지에서 3년간 NVMe 드라이버와 시험 자동화를 맡았고, 이후 누리AI칩에서 NPU 커널 드라이버와 사용자 공간 런타임을 개발하고 있습니다. 드라이버 초기화부터 메모리 관리, DMA 전송, 런타임 실행 큐, 고객 서버 배포와 장애 분석까지 담당 범위를 넓혀 왔습니다. 성능 개선뿐 아니라 커널 버전별 호환성과 장애 복구 가능성도 제품의 일부로 다룹니다. 현장에서 재현되는 문제를 로그와 덤프로 좁혀 원인을 구분하는 엔지니어입니다. 첫 실리콘 bring-up 과정에서 초기화 문제 23건을 해결했습니다. 증상만 따라가기보다 레지스터 덤프를 비교해 PCIe 링크 학습 타이밍과 펌웨어 준비 신호 순서 차이를 원인으로 분류했습니다. 런타임에서는 프로세스가 장치 하나를 독점하던 구조로 동시 실행이 막힌 점을 확인했고, 컨텍스트 단위 시분할 방식을 택해 동시 실행 컨텍스트 64개를 지원했습니다. 명령 제출 경로의 락 경합도 제거하면서 소형 요청 처리량을 2.3배 높였습니다. 성능과 동시성을 높이면서도 장치 오류가 전체 서버 재부팅으로 번지지 않도록 컨텍스트 단위 복구 기능을 구현했습니다. 고객 서버 배포는 10대, 100대, 전체의 3단계로 나누고, 각 단계에서 커널 오류 로그가 0건일 때 다음 단계로 진행했습니다. 그 결과 배포 후 30일 동안 드라이버 관련 서버 재부팅은 0건이었습니다. 초기 동작, 운영 안정성, 문제 재현 가능성을 함께 고려하는 것이 제 개발 기준입니다. [핵심 역량] - NPU·NVMe 리눅스 커널 드라이버 개발 - PCIe·DMA 경로 설계 및 성능 분석 - C++ 사용자 공간 런타임과 장치 오류 복구 - 커널 버전별 호환성 관리 및 단계 배포 - 커널 덤프 분석, 시험 자동화, 장애 재현 문서화

라온컴퓨팅의 자체 가속기 소프트웨어 스택을 데이터센터 환경으로 확장하는 직무에 지원합니다. 가속기 성능은 장치 내부 연산만으로 결정되지 않고, 호스트와 장치 사이의 데이터 이동, 커널 드라이버의 초기화와 메모리 관리, 런타임의 요청 처리, 배포 뒤 장애 복구까지 이어지는 경로에서 결정됩니다. 저는 SSD와 NPU를 대상으로 이 경로의 여러 계층을 개발해 왔습니다. 특히 드라이버와 런타임이 맞닿는 지점에서 성능과 운영 조건을 함께 살펴 온 경험이 해당 직무와 연결됩니다. NPU 드라이버에서는 DMA 스캐터-개더 경로를 재설계해 호스트와 장치 간 전송 대역폭을 1.7배 높였습니다. 런타임의 소형 요청 처리에서는 명령 제출 경로의 락 경합을 제거해 처리량을 2.3배 개선했습니다. 두 작업 모두 단일 수치만 좇기보다 전송 경로와 동시 실행 구조의 병목을 분리해 손댄 경험입니다. 운영 측면에서는 고객 데이터센터 서버 420대의 배포 절차를 마련하고, 10대에서 100대, 전체로 범위를 넓히는 단계별 조건을 설정했습니다. 커널 오류 로그가 0건인 경우에만 다음 단계로 넘어가도록 해 배포 후 30일간 드라이버 관련 재부팅 0건을 기록했습니다. 또한 커널 버전 6종의 호환성 매트릭스를 관리하고, 장애 31건의 커널 덤프를 분석해 평균 분석 기간을 7일에서 3일로 줄였습니다. 라온컴퓨팅에서도 성능 개선과 호환성 검증, 단계 배포를 하나의 운영 경로로 보고 드라이버와 런타임의 경계에서 확인해야 할 문제를 구체적으로 좁혀 나갈 계획입니다. 이 판단 기준은 SSD 드라이버부터 NPU 가속기까지 제품을 다루며 쌓은 실무 경험에 기반합니다.

리눅스 커널 메일링 리스트에 PCIe 장치 드라이버 오류 처리 패치 3건을 제출했고, 그중 2건이 머지되었습니다. 리뷰어의 지적 7건을 반영하여 패치를 4차례 수정했으며, 재현 환경과 테스트 절차를 패치 설명에 상세히 기재했습니다. 리뷰에서 요구하는 설명과 검증 근거를 직접 확인하며 기술적 완성도를 높였습니다. 사내에서는 커널 디버깅 스터디를 1년간 운영했습니다. 장애 재현 환경 구성 가이드를 작성하고 지원팀 교육을 병행한 결과, 교육 이후 지원팀이 단독으로 1차 분석한 장애 비율이 20%에서 55%로 높아졌습니다. 개인 블로그에는 패치 리뷰 과정에서 익힌 기준을 글 3편으로 정리했습니다. 문제를 해결한 뒤 재현과 검토에 필요한 정보를 남기는 방식으로 업무를 마무리해 왔습니다.