신규 개발 프로젝트와 리버스 엔지니어링의 차이

프로젝트의 시작점에 따라 요구사항 개발 접근 방식은 크게 달라집니다.

신규 개발 프로젝트는...

• 처음부터 고객, 기획, 외부 이해관계자와 협의하여 필요한 기능, 성능, 제약 조건을 하나씩 정의합니다.
• 이 과정에서는 외부 협의, 고객 요구 분석, 문서화 작업이 무엇보다 중요합니다.

반면, 리버스 엔지니어링 프로젝트는...

• 이미 완성된 시스템이나 레거시 소프트웨어를 바탕으로 기존에 구현된 기능과 제약사항을 거꾸로 분석하여 도출합니다.
• 사양서나 공식 요구 문서가 존재하지 않는 경우가 많으므로 코드, 하드웨어, 구동 로그, 유사 제품 등 실제 구현 결과를 기반으로 요구사항을 유추·정리해야 합니다.

각 유형에서의 요구사항 개발자 역할

신규 개발 프로젝트에서 요구사항 개발자는

고객과 다양한 이해관계자(품질, 기획, 하드웨어, 소프트웨어 등)와 긴밀히 소통하며

진짜 중요한 요구사항이 무엇인지 정의하고, 이를 표준 포맷에 맞춰 공식적으로 문서화합니다.

요구의 우선순위나 변경 가능성에 대해 사전에 충분한 협의를 통해 일관성 있는 기준을 세웁니다.

리버스 엔지니어링 프로젝트에서 요구사항 개발자의 역할

이 경우 요구사항 개발자는 이미 구현된 코드, 장비, 동작 기록, 과거 이슈 자료 등을 꼼꼼히 파악하여 시스템이 실제로 어떻게 동작하는지, 숨어 있는 요구나 제약이 무엇인지를 문서화합니다.

공식 자료가 부족하므로 내부 개발자, 유지보수 담당, 품질팀 등과의 협의가 더 중요해집니다.

그러나 현실적으로 테스트 산출물, 아키텍처 설계조차 정리되어 있지 않거나 리버스가 제대로 이뤄지지 않았다면 사양개발자는 ‘기준’을 잡는 데 한계가 있을 수밖에 없습니다.

이런 상황에서는

• 실제 코드와 시스템 동작을 이해하고 변경·개선·기준을 실질적으로 만드는 역할은 주로 개발자(설계자, 테스터 포함)가 앞장서야 합니다.
• 사양개발자는 현황을 정확히 정리하고, 나중에 근거 자료와 기록을 명확히 남기는 역할을 하면 됩니다.

[신규 개발]
고객 <-> 사양 담당자 <->  개발자 <-> 품질팀
(외부 협의, 요구 정의, 공식 문서화)

[리버스]
코드/제품 -> 개발자 -> (테스트/설계자 중심 개선) -> 사양 담당자(정리·문서화)
(내부 탐색, 기능 유추, 근거 보강, 사후 기록)

외부 협의가 어려운 리버스 상황의 현실과 대처법

리버스 엔지니어링 프로젝트에서는 사양 개발자가 기존 고객이나 외부 이해관계자와 협의하기가 매우 어렵거나 의미가 없는 경우가 많습니다.

납품된 지 오래된 시스템이거나, 담당자가 모두 변경된 상황이라면 외부 역시 시스템 내부 동작을 모르는 경우가 흔합니다.

이럴 때는

• 내부 인력을 최대한 활용해 코드, 하드웨어, 로그, 테스트 결과 등 가능한 모든 근거 자료를 모읍니다.
• 개발자, 설계자, 유지보수 담당자 등이 실제 시스템 동작을 이해하고 필요한 개선·기준을 먼저 정의합니다.
• 사양 담당자는 이 결과를 바탕으로 “무엇이 사실이고, 무엇이 가정/추정인지”를 명확히 구분해 문서로 남깁니다.

실무 Tip.

- 불확실한 부분, 가정 사항은 반드시 문서에서 별도로 표시합니다.
- 내부 기준이 정리되지 않은 상태에서는 사양 담당자가 주도적으로 기준을 만드는 것이 현실적으로 어렵습니다.

따라서 현업 개발자와 긴밀히 협력하여 우선 실제 동작 기준, 구현 내역, 테스트 결과 등을 정리한 뒤 사후 문서화를 진행하는 것이 바람직합니다.

간혹 “리버스 사양서 작성이 무의미하지 않냐”는 개발자들이 있습니다. 그러나 사양서는 코드보다 훨씬 높은 재사용성과 지식 자산 가치를 가집니다. 특히 고객사와의 협의 시 불필요한 시간을 크게 줄일 수 있습니다. 글로벌 선진 제조사들은 이를 핵심 경쟁력으로 삼아, 다음 프로젝트의 속도와 품질을 좌우하는 기반으로 적극 관리하고 있습니다.