하드웨어 회사에서 소프트웨어 엔지니어로 일한다는 건 어떤 느낌일까 — HW 일정에 끌려다니는 SW 개발의 현실

Source: Dev.to

“하드웨어는 바꿀 수 없으니 소프트웨어로 고쳐라”

하드웨어 회사에서 소프트웨어 엔지니어가 가장 많이 듣는 말이다.

한 번은 하드웨어 팀이 디스플레이를 잘못된 방향으로 물리적으로 장착했다. 조립은 이미 끝난 상태였고, 이를 떼어 다시 붙이는 것은 비용이나 시간 면에서 의미가 없었다. 그래서 소프트웨어에 들어온 요청은 간단했다: “소프트웨어에서 디스플레이 출력 방향만 뒤집어 주세요.”

이것은 일회성 사건이 아니었다. 하드웨어 설계에서 문제가 발생하면 수정 비용이 크기 때문에, 매일같이 그 해결책이 소프트웨어 쪽으로 넘어온다. 소프트웨어 입장에서는 원래 계획에 없던 작업이 갑자기 나타나지만, 마감일은 변하지 않는다.

소프트웨어를 하드웨어처럼 대하는 조직

반대 상황도 존재한다.

몇 줄의 코드만으로 해결될 수 있는 수정이 “이미 최종 확정됐으니 변경이 불가능합니다.” 라는 반응을 받기도 한다.
하드웨어 중심 조직은 설계 승인 후 변경에 매우 보수적이다. 금형을 다시 만들거나 보드를 재설계하는 데는 실제 비용이 들기 때문에, 이런 사고방식 자체는 이해가 된다.

문제는 그 동일한 기준이 소프트웨어에 적용될 때이다. 소프트웨어의 핵심 강점은 유연성인데, 하드웨어와 같은 프로세스에 가두면 비효율이 따라온다. 간단히 해결할 수 있는 문제도 우회 로직을 추가하거나 부가 기능을 억지로 끼워 넣게 된다. 반복될수록 코드가 복잡해진다.

하드웨어가 지연되면 소프트웨어 일정이 압축된다

제품 개발에는 마감일이 있다. 고객에게 약속한 납기일은 쉽게 움직이지 않는다.

개발 순서는 보통 하드웨어 → 소프트웨어이다. 센서와 기계 부품이 준비돼야 펌웨어를 올릴 수 있고, 튜닝과 검증은 실제 하드웨어에서 이루어져야 하므로 이 순서는 타당하다.

하지만 설계 변경이나 부품 문제로 하드웨어 단계가 지연되면 전체 마감일은 그대로인데 소프트웨어에 할당된 시간이 줄어든다. 하드웨어 팀이 작업을 마치고 나면 그들의 입장은 “우리는 넘겨줬으니 남은 시간 안에 나머지를 해결해라.” (또는 앞서 언급한 대로 “소프트웨어로 해결 방법을 찾아라.”)가 된다.

원래 한 달이던 소프트웨어 개발 기간이 2주로 압축될 수 있다. 작업량은 줄어들지 않는다. 한두 번이라면 초과 근무로 버틸 수 있겠지만, 매 프로젝트마다 반복되면 그것이 정상처럼 느껴진다.

그렇다면 이 환경이 전부 나쁜가?

불만만 나열하려는 것이 아니다.

이런 환경에서 일하면 자연스럽게 하드웨어를 이해하는 소프트웨어 엔지니어가 된다. 회로도를 읽고 물리적 제약 위에 소프트웨어를 설계하는 감각을 익히게 되는데, 순수 소프트웨어 환경에서는 얻기 힘든 경험이다.

“이 하드웨어 문제를 소프트웨어로 해결해라” 라는 요청에 계속 대응하면서 문제 해결 능력의 범위가 넓어진다. 정의된 요구사항을 구현하는 능력과 물리적 제약을 창의적으로 우회하는 능력은 서로 다른 두 가지 스킬이다.

하드웨어 회사의 소프트웨어 엔지니어가 되는 것은 불편하지만, 성장 측면에서는 독특하게 보람 있는 환경이다.