useblocks — 자동차 SW 개발의 요구사항·명세·테스트·아키텍처 의사결정을 코드와 함께 Git 저장소 안에서 관리하는 추적성·컴플라이언스 툴체인 기업. 핵심 명제는 “이 산업에 부족한 것은 속도가 아니라 입증” — 엔지니어들은 이미 빠르게 움직이고 있지만, 그것이 안전·규정을 충족한다는 사실을 보여주는 구조가 과거에 머물러 있다는 진단.
창업 배경
- BMW 프로젝트에서 ISO 26262 환경 아래 개발하던 순수 엔지니어 팀에서 출발. 추적성이 선택사항이 아니라 엄격한 요구사항이었던 환경에서, 기존 DOORS·Polarion·Codebeamer 같은 ALM 도구가 IDE·Git 중심으로 일하는 엔지니어의 작업 방식과 맞지 않는다는 사실을 절감.
- DOORS·Polarion·Codebeamer는 중앙집중형 데이터베이스 + 변경 주기 수개월 + 전담 툴 관리자라는 세계를 전제로 설계됨 → SDV의 빠르게 움직이는 SW 세계와 구조적 부정합.
- 결정적 깨달음: 더 나은 데이터베이스가 아니라 완전히 다른 패러다임. 아티팩트를 코드 안으로 가져오기.
공동창업자 3인
- 데이얼 보스테(Daniel Woste) — 공동창업자 겸 CEO
- 마르코 하인만(Marco Heinemann) — 공동창업자 겸 CTO
- 막스 파빙거(Max Pabinger) — 공동창업자 겸 CSO.
X-as-Code 패러다임
핵심 개념. 요구사항·명세서·테스트 케이스·아키텍처 의사결정 같은 모든 엔지니어링 아티팩트를 소스코드와 나란히 두고 구조화된 텍스트로 저장 + Git 버전 관리 + 동일한 CI/CD 파이프라인 처리.
| 조건 | 의미 |
|---|---|
| 텍스트 중심 | 사람·기계 모두 읽을 수 있는 형태 |
| 스키마 인식 | 구조화된 의미 — 단순 위키나 워드 문서가 아님 |
| 버전 관리 | Git 커밋·머지·diff와 같은 흐름으로 변경 이력 관리 |
| 귀속 가능성 | 누가 무엇을 바꿨는지 추적 |
엔지니어가 IDE에서 작업 중인 기능과 연결된 요구사항을 즉시 확인 + 변경 커밋 시 추적성 자동 갱신. 별도 도구 로그인이나 수동 동기화 단계 없음. 이렇게 되면 컴플라이언스는 코드 작성 뒤 따로 덧붙이는 행정 절차가 아니라, 코드 작성 행위 자체에서 자연스럽게 따라오는 부산물.
Sphinx-Needs — 오픈소스 기반
useblocks의 오픈소스 추적성 도구. 월 30만 회 이상 다운로드(2026-04 기준). 자동차뿐 아니라 항공우주·의료·로보틱스 등 안전 임계 SW 개발 영역에서 채택.
ubCode·Pharaoh
상업 도구. 2026-04 사용자 그룹 미팅에서 50명 엔지니어와 함께 2시간 안에 Park Assist 시스템 구현 실험 — Sphinx-Needs + ubCode + Pharaoh + GitHub Copilot + 실제 HW 결합. 구조화된 명세·추적성이 AI 기반 안전 임계 개발의 핵심 인프라가 될 수 있음을 시연.
추적성의 의미 — 보안·안전·품질의 단일 질문
파빙거의 분석. “과연 그것을 입증할 수 있는가?”라는 질문이 세 영역에서 동일한 형태로 등장:
| 영역 | 질문 |
|---|---|
| 보안 | 공격 가능한 경로가 존재하지 않는다는 것을 입증할 수 있는가? |
| 안전 | 모든 요구사항이 빠짐없이 반영되었음을 입증할 수 있는가? |
| 품질 | 개발 프로세스가 완전하다는 것을 입증할 수 있는가? |
세 영역이지만 결국 하나의 질문. 대부분의 답은 “수작업으로 다시 검증하지 않고서는 입증할 수 없다” — 시스템 완전성에 대한 지식이 시스템 자체가 아니라 특정 개인의 머릿속에 있기 때문(보안 분야에서 single point of failure로 부르는 구조).
SDV가 만든 협업 압력
파빙거에게 진정한 전환점은 ADAS가 아니라 SDV. 단순한 복잡성 증가가 아니라 누가 누구와 협업하는가를 바꿔놓음:
- 전통 차량 개발은 분리된 도메인 + 각자 툴체인·릴리스 주기
- SDV는 하나의 SW 업데이트가 동시에 여러 도메인에 영향. OTA가 더해지면 시장에 나간 차량도 고정되지 않음
- 데이터 사일로가 생산성·파트너 협업의 핵심 저해 요인. 진짜 문제는 컴퓨팅 파워·개발자 역량이 아니라 조율 그 자체
- ADAS·자율주행은 확률적 동작·시나리오 커버리지·AI 모델 거버넌스 같은 새로운 종류의 요구사항 추가 — 전통적 V-모델이 다루도록 설계된 대상이 아님
AI 에이전트를 위한 인프라
모든 엔지니어링 아티팩트를 구조화·추적가능한 텍스트로 Git 저장소에 두는 것은 단지 좋은 개발 방식이 아니라 AI 에이전트를 위한 거의 이상적인 인프라. 요구사항·명세·테스트가 기계 가독 형태로 연결돼 있으면 에이전트는 특정 코드 조각이 왜 존재하는지·어떤 규제와 연결되는지·어떤 제약을 만족해야 하는지 전체 맥락을 파악 가능.
“단순히 워드 문서 위에 채팅 인터페이스를 덧붙이는 방식이 아니라, 아티팩트 그래프 자체를 에이전트가 추론하는 기반으로 만드는 것이 핵심입니다.” — 파빙거
Microsoft·GitHub와의 협업이 이 방향에 가시성 부여. AI 보조 개발의 올바른 기반으로서 텍스트 기반·추적가능한 엔지니어링이 지목되고 있다는 점이 도입 속도를 앞당기고 있다는 진단.
Eclipse SDV·S-CORE 참여
useblocks는 Eclipse S-CORE 프로젝트에 적극 참여. 그 외 OpenBSW 같은 Eclipse SDV 오픈소스 프로젝트에서도 useblocks 툴체인이 이미 사용 중. useblocks 자신의 역할 정의 — “SDV 툴체인 안에서 추적성·컴플라이언스를 담당하는 레이어”.
“차별화 요소가 아닌 인프라 영역에서는 경쟁 이전의 협력(pre-competitive collaboration)이 모두에게 순이익입니다. 어떤 OEM도 독자적인 요구사항 포맷을 갖고 있다고 해서 경쟁 우위를 얻지는 못합니다. 진정한 차별화는 사용자 경험 층위에서 발생합니다.” — 파빙거
사례 — Mercedes-Benz Tech Innovation (요구사항 5명 → 169명)
Mercedes-Benz Tech Innovation 마커스 레트슈타트(Markus Rettstatt) 부사장이 언급한 사례. 추적성·요구사항 관리에 참여하는 개발자가 5명에서 169명으로 증가 — 기존 ALM 도구의 라이선스·툴 관리자 의존 모델에서는 불가능했던 폭넓은 참여를 X-as-Code 구조가 가능하게 한 결과. 추적성 구조 변화가 단지 도구 차원이 아니라 실제 개발 참여 방식까지 변화시킨 사례로 인용.
입증의 비용 — 시니어 엔지니어 시간의 도난
파빙거의 진단:
- 프로젝트 전체 맥락을 가장 잘 이해하는 가장 숙련된 엔지니어가 시스템 설계 대신 수작업 추적성 그래프 따라가기·감사 컴플라이언스 근거 재구성·규제 변경 영향 파악에 시간 소모
- 직접 비용: 시니어 엔지니어 몇 주씩 새 기능 대신 정당성 입증에 매달림
- 더 위험한 비용: 시스템 완전성 지식이 조직 자산이 아니라 특정 개인의 머릿속에 귀속 → 그 사람이 다른 프로젝트로 이동하면 팀은 더 느리게·더 낮은 확신으로 다시 시작
- 그 외 오버헤드는 조율에서 발생 — 안전·사이버보안·개발 팀이 각자 도구에서 일하는데 공통 표현 체계가 없어 변경 영향 파악에 수작업 회의
한국 시장
“한국의 자동차 산업 생태계는 세계적으로도 가장 인상적인 수준에 속한다고 생각합니다. 완성차 업체들의 높은 의지와 야심, 반도체 분야에서의 리더십, 소비자 전자 분야에서 축적된 전문성, 그리고 티어 1 공급업체들이 보여주는 정밀한 제조 역량이 결합돼 있다는 점은 전 세계적으로도 소수의 국가만이 갖고 있는 매우 독특한 강점입니다.” — 파빙거
체계적·품질 중심 엔지니어링 문화에서 useblocks 툴링이 가장 큰 가치를 만들 수 있다고 평가. 한국 기업과의 협업에 적극 의향.
핵심 명제
“이 산업에 부족한 것은 속도가 아닙니다. 부족한 것은 입증입니다. 엔지니어들은 이미 빠르게 움직이고 있습니다. 다만 자신들이 만든 것이 안전하고, 추적가능하며, 규정을 충족한다는 사실을 제대로 보여줄 수 없을 뿐입니다.” — 파빙거 (GitHub Shift 행사에서 클레이 넬슨 발언 인용·확장)
“팀들은 이미 빠르게 움직이고 있습니다. 다만 자신들이 만든 것이 안전하고 규정을 준수하고 있다는 점을 지속적이고 자동화된 방식으로 입증하지 못하고 있을 뿐입니다.”