캐논·코닥 제조 브랜드 프로젝트, 요구사항 어디부터 정할까요

핵심 요약 — 캐논코리아 카메라 펌웨어 업데이트 유틸리티와 코닥 브랜드 인스턴트 프린터 앱, 두 제조 브랜드 프로젝트 모두 개발 기간은 2개월이었는데 가장 어려웠던 지점은 화면이 아니라 기기·버전 조합 테스트였어요. 제조 브랜드 프로젝트는 소프트웨어 혼자 완결되지 않고 실제 하드웨어와 맞물려야 해서, 요구사항 정의 단계에서 “지원 범위”를 숫자로 좁혀두는 일이 유독 중요해요. 직접 만들고 운영해본 개발사 기준으로 두 사례를 나란히 놓고 정리했어요.

“저희 카메라는 몇 개 기종이나 지원되나요?” “폰은 아이폰만 되나요, 안드로이드도 되나요?” 제조 브랜드의 소프트웨어 상담에서 화면 이야기보다 먼저 나오는 질문이에요. 이런 프로젝트는 앱이나 프로그램 혼자 완성되지 않고, 실제로 존재하는 기기와 맞물려야 비로소 완성되거든요.

---

1. 제조 브랜드 프로젝트는 왜 소프트웨어만으로 안 끝날까요

일반 웹서비스나 앱은 서버·클라이언트 통신만 안정적이면 대부분 풀려요. 하드웨어를 만드는 회사의 프로젝트는 변수가 하나 더 붙어요. 카메라 펌웨어 버전, 프린터 기종처럼 개발사가 마음대로 바꿀 수 없는 물리적 조건이 소프트웨어 동작을 좌우해요.

그래서 요구사항 정의서에는 “무슨 기능이 필요한가”만큼 “어떤 기기·환경까지 지원해야 하는가”가 명확해야 해요. 이 범위가 흐리면 개발이 아니라 검증(테스트)이 끝없이 늘어나요.

2. 캐논코리아 — Windows·Mac을 함께 지원해야 했던 이유

저희가 2022년 12월 출시한 캐논코리아 카메라 펌웨어 업데이트 유틸리티는 [제조 · 데스크톱 유틸리티] 프로젝트예요. 개발 기간 2개월, 기획 1·디자인 1·개발 2명이 투입됐어요. 요구사항의 핵심은 Windows에서만 되던 업데이트를 Mac에서도 쓸 수 있게 하는 것이었어요.

운영체제가 하나 늘어나는 요구사항은 코드를 두 벌 쓰는 문제가 아니에요. 파일 접근·USB 연결 권한 처리 방식이 서로 달라 같은 기능을 두 환경에서 각각 검증해야 해요. 실제로 가장 부담이 컸던 건 코드를 쓰는 일이 아니라 다양한 펌웨어 버전과 장치 조합의 테스트였어요. 출시 이후 펌웨어 업데이트 관련 고객 문의가 줄었고, 기존에 어려웠던 Mac 사용자도 업데이트를 쓸 수 있게 됐어요.

3. 코닥 — 아이폰·안드로이드를 모두 받아야 했던 이유

2020년 2월 출시한 코닥 브랜드 인스턴트 프린터 블루투스 연동 앱도 결이 비슷해요. 정확히는 코닥 본사가 아니라 코닥 브랜드 인스턴트 프린터를 만드는 제조 파트너사(Prinics Co., Ltd.)가 발주한 [제조 · 하드웨어 연동 App] 프로젝트예요. 플랫폼은 iOS였고, 연결 검증은 Android 기기까지 포함했어요. 개발 기간 2개월, 투입은 캐논 프로젝트와 같은 기획 1·디자인 1·개발 2명이었어요.

여기서는 “지원 OS”가 아니라 지원 기기 개수 자체가 문제였어요. 아이폰·안드로이드를 통틀어 기종은 셀 수 없이 많고, 기종마다 블루투스 반응 속도나 배터리 응답 방식도 조금씩 달라요. 가장 어려웠던 지점도 정확히 여기였어요. 아이폰·안드로이드의 수많은 기기와 사진 인화 장치 간의 연결 및 오류 처리가 핵심 난제였어요. 개발 이후 잦았던 오류가 줄고, 사진 인화기와 휴대폰 연동이 안정화됐어요. 자세한 과정은 코닥 프린터 앱 사례에 정리돼 있어요.

4. 두 사례의 공통점 — “테스트가 가장 어려웠다”는 말의 진짜 의미

캐논과 코닥, 만든 제품도 플랫폼도 달랐지만 답은 같았어요. 둘 다 “가장 어려웠던 지점”으로 화면이나 기능이 아니라 기기·버전 조합 테스트를 꼽았어요. 우연이 아니에요. 요구사항 단계에서 지원 범위를 정하는 순간, 그 범위가 곧 검증해야 할 조합의 개수가 되거든요.

자사 실무 기준 예시 — 두 프로젝트 비교

구분	캐논코리아	코닥(Prinics)
요구사항 유형	크로스플랫폼(Windows·Mac)	크로스디바이스(iOS·Android 다양한 기종)
개발 기간	2개월	2개월
투입 인원	기획 1·디자인 1·개발 2	기획 1·디자인 1·개발 2
가장 어려웠던 지점	펌웨어 버전×장치 조합 테스트	기기 연결·오류 처리

공식 외부 기준 (참고)

항목	내용	출처 유형
요구사항 오류를 유지보수 단계에서 뒤늦게 고칠 때의 비용	사양 단계에서 바로 고칠 때 대비 최대 약 100배까지 증가할 수 있음	소프트웨어공학 일반 연구(공식)

⚠️ 위 표는 두 프로젝트의 실측 배수가 아니라 소프트웨어공학에서 일반적으로 알려진 경향이에요. 다만 지원 기기·버전 범위를 뒤늦게 바꾸면 이미 검증한 조합을 다시 검증해야 한다는 방향은 두 프로젝트에서도 동일하게 확인됐어요.

5. 크로스플랫폼과 크로스디바이스는 요구사항이 다르게 움직여요

같은 “지원 범위 넓히기”라도 둘은 성격이 달라요. 크로스플랫폼(캐논, 운영체제 대응)은 지원 대상이 유한해요. Windows·macOS 몇 버전 이상처럼 목록으로 딱 떨어져요. 반면 크로스디바이스(코닥, 소비자가 실제로 들고 있는 폰 대응)는 제조사도 개발사도 통제할 수 없는 조합이에요. 안드로이드 기기 모델만 해도 전 세계에 수만 종이 있다는 업계 조사가 있을 정도예요.

그래서 요구사항 정의서 문장도 달라야 해요. 크로스플랫폼은 “지원 OS와 최소 버전을 목록으로 명시” 하면 되지만, 크로스디바이스는 “전 기종 지원”이 아니라 “대표 기종을 먼저 확정하고 출시 후 확대” 하는 방식으로 적어야 견적과 일정이 현실적으로 나와요. 이 구분 없이 “많이 지원해주세요”로 뭉뚱그리면, 규모가 있는 제조 브랜드 si project일수록 이 차이가 후반에 뒤늦게 드러나요.

지원 범위가 아직 안 정해졌어도 괜찮아요. 기기 목록부터 같이 정리해봐요 →

6. 제조 브랜드 요구사항 정의서에 꼭 넣을 것

용어 정리 — 크로스플랫폼은 하나의 소프트웨어가 Windows·Mac처럼 서로 다른 운영체제에서 동작하도록 만드는 것이고, 크로스디바이스는 제조사가 만들지 않은 다양한 소비자 기기와도 호환되도록 만드는 것이에요. 실무에선 “이 기능은 크로스플랫폼만, 저 기능은 크로스디바이스까지 검증한다”처럼 구분해서 써요.

최소한 이 네 가지는 항목 단위로 넣어야 해요.

1. 지원 기기·OS 목록 — 모델명·버전 범위로.
2. 테스트 기기 수급 주체 — 실물 기기를 누가, 몇 대, 언제.
3. 연결 실패 시나리오 — 끊기거나 응답 없을 때 어떻게 안내·복구할지.
4. 출시 후 신규 기기 대응 범위 — 새 모델이 나올 때 누가 검증할지.

운영사 Tip — 저희는 하드웨어 연동 프로젝트를 볼 때 “지원 목록에 없는 기기에서 오류가 나면 그건 버그인가요, 지원 범위 밖인가요”를 계약 전에 먼저 물어봐요. 답이 정리돼 있으면 검수 단계에서 다툴 일이 크게 줄어요. 저희는 같은 기능 수보다, 그 기능이 몇 가지 기기 조합에서 실제로 동작하는지부터 봐요.

7. 흔한 실수 — 견적은 코드만 보고 검증은 안 보는 것

가장 흔한 실수는 견적서에 “기기 조합 테스트”가 별도 항목으로 없는 경우예요. 화면 설계와 개발 공수만 계산하고, 지원 기기가 늘수록 곱으로 커지는 검증 시간은 “개발”에 뭉뚱그려 넣는 견적서가 많아요. 그러면 중반에 “생각보다 오래 걸린다”는 이야기가 나오는데, 그 이유의 상당수가 애초에 견적에 없던 테스트 시간이에요.

견적서를 받으실 때 지원 기기·OS 목록이 숫자로 적혀 있는지, 테스트 기기를 누가 준비하는지만 확인하셔도 편차가 크게 줄어요. 요구사항 정의서를 처음 작성하는 방식이 궁금하시면 요구사항 정의서 작성 가이드도 참고해보세요.

8. 자주 묻는 질문

제조 브랜드 프로젝트는 요구사항 정의서에 하드웨어 스펙까지 넣어야 하나요?

네, 그래야 견적 편차가 줄어요. 지원할 기기·모델 목록, OS 또는 펌웨어 버전 범위, 연결 방식(블루투스·USB 등)을 숫자와 목록으로 적어야 개발사가 테스트 범위를 정확히 계산할 수 있어요. “주요 기기 지원”처럼 적으면 업체마다 다른 조합을 상상해서 견적이 벌어져요.

지원 기기 범위를 넓게 잡을수록 좋은 거 아닌가요?

그렇지 않아요. 지원 범위가 늘어나면 테스트해야 할 조합이 곱으로 늘어나요. 대표 기종이나 주요 OS 버전으로 좁혀 먼저 안정화한 뒤, 출시 후 사용 데이터를 보고 지원 범위를 넓히는 방식이 일정과 비용 모두에서 안전해요.

제조 브랜드 SI 프로젝트는 요구사항 정의부터 검수까지 어떻게 진행하나요?

먼저 지원 기기·플랫폼 범위를 확정한 요구사항 정의서를 작성하고, 이를 근거로 견적과 일정을 잡아요. 개발 중에는 실기기로 조합 테스트를 진행하고, 검수 단계에서는 정의서에 적은 대표 기기·환경에서 정상 동작하는지를 기준으로 판정해요. 지원 범위 밖 기기의 오류는 별도 협의 대상으로 미리 구분해두는 게 좋아요.

관련 글: 카메라 펌웨어 업데이트, 왜 이렇게 불편할까 — 캐논코리아 유틸리티 사례 · 하드웨어 연동 앱 외주, 왜 까다로울까요 — 코닥 프린터 앱 체크포인트 6가지 · 요구사항 정의서 어디까지 써야 하나요

---

캐논과 코닥, 두 프로젝트를 나란히 보니 결국 같은 이야기였어요. 제조 브랜드의 소프트웨어는 화면이 아니라 “어떤 기기까지 책임질 것인가”에서 비용과 일정이 갈려요. 저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 캐논·코닥 같은 제조 브랜드와도 함께해 왔고요. 지원해야 할 기기 범위가 아직 흐릿하셔도 괜찮아요. 비슷한 프로젝트를 상담받아보세요 →