시스템 소프트웨어 개발 과정에서 다양한 업체들과 협력이 필요합니다. 아래 그림처럼 복잡한 생태계를 가지고 있으며, 특히 제품 개발 업체(OEM) 개발자들은 칩셋 업체 개발자들과 자주 협력합니다.
보통 OEM 업체는 칩셋 업체에게 기술 지원을 요청할 때 Service Request(SR)라는 ‘티케팅 서비스’를 사용합니다.
예를 들어, OEM 업체가 퀄컴의 SM8650 칩셋을 사용하고 있다고 가정해 봅시다. 어떤 기술 문제가 생겼을 때, 이메일로 지원을 요청할 수 있습니다. 하지만 대부분의 경우, 퀄컴 개발자는 “SR 티켓을 먼저 열어주세요”라고 답할 것입니다. 이는 퀄컴뿐 아니라 대부분의 칩셋 업체도 마찬가지입니다. 각 회사마다 정해진 기술 지원 절차가 있습니다.
칩셋 업체 개발자들과 네트워킹을 해 보면, 기술 지원 과정에서 많은 스트레스를 받는다는 이야기를 종종 들을 수 있습니다. 이러한 스트레스를 줄이기 위해, OEM 개발자가 주의해야 할 다섯 가지 사항을 소개합니다.
1. 재현 경로를 숨기지 마세요
드라이버에 버그가 있을 경우, OEM 개발자는 칩셋 업체에 티켓을 열어 지원을 요청합니다. 그런데 이때 문제가 발생한 정확한 재현 경로를 공유하지 않는 경우가 있습니다. 심지어 문제가 OEM 개발자의 실수로 생긴 것일 수도 있습니다.
재현 경로가 없으면 칩셋 업체 개발자는 문제를 찾는 데 많은 시간과 노력을 들여야 합니다. 따라서 재현 방법과 필요한 조건을 가능한 한 명확히 제공해야 합니다.
2. 자신이 추가한 코드를 숨기지 마세요
OEM 개발자는 칩셋 업체가 제공한 BSP 코드에 자신만의 코드를 추가할 수 있습니다. 하지만 기술 지원을 요청하면서 자신이 추가한 코드가 있다는 사실을 숨기는 경우도 있습니다.
칩셋 업체는 일반적으로 ‘레퍼런스 보드’를 기반으로 문제를 확인합니다. 이 보드는 칩셋 업체가 제공한 BSP 코드만으로 구성되어 있어, OEM 보드와 동작이 다를 수 있습니다.
추가한 코드가 있다면 반드시 알려야 칩셋 개발자가 원인을 정확히 파악할 수 있습니다.
3. 특정 샘플에서만 발생하는 문제는 숨기지 마세요
일부 이슈는 하드웨어의 노이즈나 전원 문제로 인해 특정 샘플 보드에서만 발생합니다. 그런데 OEM 개발자가 이러한 사실을 숨기면, 칩셋 업체는 문제를 재현할 수 없어 많은 시간을 낭비하게 됩니다.
특정 보드에서만 문제가 발생한다면, 그 사실을 정확히 공유해야 합니다.
4. 충분한 로그와 ELF 파일을 제공하세요
기술 지원을 요청할 때는 로그 파일과 문제 발생 시점의 ELF 바이너리 파일을 함께 제공해야 합니다. 버전에 맞는 ELF가 없거나 로그가 불충분하면 분석 시간이 길어질 수 있습니다.
기술 지원 요청 시, 로그와 ELF는 필수입니다.
5. 시간을 벌기 위해 지원 요청을 남용하지 마세요
가끔 OEM 개발자가 자기 책임을 회피하거나 일정을 늦추기 위해 칩셋 업체에 기술 지원을 요청하는 경우도 있습니다. 이런 방식은 장기적으로 협업 신뢰를 깨뜨릴 수 있습니다.
이런 문제를 일으키는 OEM 개발자는 소수일 수 있지만, 협업을 잘하기 위해서는 무엇보다 정직함(honesty) 이 중요합니다.