Requirements, design specification & AI

2025-02-22 Jeonghyun Kim

Linkedin

In recent years, across semiconductor and software development, AI has become deeply embedded throughout the development process. One of the most notable areas is source code generation for prototyping. As AI’s code generation capabilities have advanced rapidly, prototyping—once constrained by cost and schedule pressure—can now be performed quickly and at very low cost.

A typical prototyping workflow now looks like this. First, the intended functionality or element (for example, a silicon IP or a Linux BSP driver) and its key external interfaces are described to an AI system. In response, the AI generates source code that is not only reasonable in structure, but also immediately executable (or simulatable). By running this code, developers can iteratively add functionality, extend interfaces, and evolve the design while considering connectivity with other elements. Repeating this cycle with AI, one eventually reaches a point where the code satisfies not only functional requirements but also overall design quality.

What is particularly interesting is that AI does not merely generate “working” code. It often incorporates industrial constraints that even intermediate or senior developers find challenging—such as MISRA C compliance, function call structures that account for code complexity, and modularization strategies that improve reusability.

This naturally leads to a reconsideration of requirements. Broadly speaking, requirements serve two main purposes. The first is to define what is to be built. The second is to describe what functionality the system currently being developed actually provides. However, as modern systems have grown extraordinarily complex in both functionality and structure, the long-held assumption that requirements can be defined to an 80–90% level of completeness before design begins is becoming increasingly unrealistic.

This issue has already surfaced even in conservative engineering domains such as the automotive industry. Around eight years ago, I participated in a project with a global European OEM involving a vehicle system that required a very high level of functional safety. One of the OEM’s explicit requests was to conduct the project in an agile manner. That experience highlighted how even safety-critical domains had begun to recognize the limits of traditional, requirement-first development models.

In this context, it is reasonable to question whether defining requirements as completely as possible at the start of a project is truly the most rational approach. Instead, rapidly prototyping based on customer needs, and then refining requirements using the executable artifacts produced through collaboration with AI, may be both more realistic and safer.

In many cases, AI demonstrates insights that rival—or even exceed—those of highly experienced domain experts. I have encountered multiple situations where requirements generated or refined by AI were more realistic and better structured than those written manually by humans.

A similar discussion arose in the automotive industry when Simulink was first widely adopted. Engineers frequently asked questions such as: “Do we still need to write a separate requirements specification if we start design directly in Simulink?” “If so, should we reverse-engineer documentation from the Simulink model?”

ISO 26262 provides an interesting perspective on this. It explains that a Simulink model itself represents a significant portion of both the application software requirements and the design, and that only limited additional specification is needed to achieve functional safety. This can be seen as a formal acknowledgment that the boundaries between requirements, design, and implementation have already blurred.

In today’s development environments, functional requirements, architectural design, prototyping, and implementation review are no longer independent phases. While an entire system may not be developed this way all at once, at the level of individual functions or elements, these activities have effectively merged into a single continuous process.

Under these circumstances, is it truly necessary for requirements and design specifications to be manually typed by engineers into traditional documents in order for a system to be considered safe or trustworthy?

This question closely parallels another familiar debate: is it safer for a human to drive, or for a sufficiently mature autonomous driving system to do so?

I believe that actively using AI throughout the engineering process—not only for code implementation but also for design and specification—is no longer something to be done quietly or defensively. The time has already come to embrace it openly and confidently. Not long ago, people asked how it could be acceptable to use a highly flexible language like C in systems requiring high safety and reliability. AI, I believe, will follow a similar trajectory.

From my perspective, even with today’s AI technology, we have already reached a point where AI can stand on equal footing with humans in many aspects of engineering. The remaining challenge is no longer whether AI should be used, but how it should be responsibly integrated into engineering processes.

최근 반도체와 소프트웨어 개발 현장을 보면, 개발 과정 전반에 AI가 깊숙이 활용되고 있다. 특히 prototyping 단계에서의 source code generation은 이미 일상적인 도구가 되었다. AI의 코드 생성 능력이 급격히 향상되면서, 과거에는 비용과 일정의 제약 때문에 쉽게 시도하기 어려웠던 prototyping을 매우 낮은 비용으로, 빠르게 수행할 수 있게 되었기 때문이다.

일반적인 prototyping 과정을 보면, 먼저 구현하고자 하는 기능이나 element(예: silicon IP, Linux BSP driver)의 역할과 주요 external interface를 AI에게 설명한다. 그러면 즉시 실행(또는 시뮬레이션) 가능한 수준의, 상당히 합리적인 소스 코드가 생성된다. 이 코드를 실행해 보면서 기능을 추가하고, 인터페이스를 확장하며, 다른 요소들과의 연결성을 고려한 설계로 발전시켜 나간다. 이러한 과정을 AI와 반복하다 보면, 어느 순간 기능적 요구뿐만 아니라 설계 품질까지 만족하는 코드에 도달하게 된다.

흥미로운 점은 AI가 단순히 “동작하는 코드”만 생성하는 것이 아니라는 것이다. MISRA C와 같은 코딩 규칙, 코드 복잡도를 고려한 함수 호출 구조, 재사용성을 고려한 모듈화 등 중·고급 개발자에게도 쉽지 않은 산업적 요구사항까지 반영한 결과물을 만들어낸다.

이제 requirement에 대해 다시 생각해 볼 필요가 있다. Requirement는 크게 두 가지 목적을 가진다. 하나는 “무엇을 만들 것인가”를 규정하는 것이고, 다른 하나는 “현재 만들어지고 있는 시스템이 어떤 기능을 제공하고 있는가”를 명확히 하는 것이다. 그러나 기능과 구조가 지나치게 복잡해진 오늘날의 시스템에서, 개발 초기에 requirement를 80~90% 수준까지 완성한 뒤 설계에 들어가는 방식은 점점 비현실적인 가정이 되고 있다.

이 문제는 자동차 산업처럼 보수적인 엔지니어링 문화를 가진 분야에서도 이미 오래전부터 제기되어 왔다. 약 8년 전, 높은 수준의 기능 안전이 요구되는 차량 시스템 프로젝트를 유럽의 글로벌 OEM과 수행한 적이 있는데, 당시 OEM이 요청한 개발 방식은 전통적인 방식이 아닌 ‘애자일’이었다. 이는 안전이 중요한 시스템에서도 기존 개발 패러다임이 한계에 도달했음을 보여주는 사례라고 생각한다.

이러한 맥락에서, requirement를 프로젝트 초기에 최대한 완성하려는 접근이 과연 가장 합리적인지 의문이 든다. 오히려 고객 요구사항을 기반으로 빠르게 prototyping을 수행하고, 그 과정에서 AI와 협업하여 얻은 실행 가능한 결과물을 바탕으로 requirement를 정제해 나가는 방식이 더 현실적이고 안전하지 않을까.

AI는 특정 개발 분야에서 경험 많은 전문 엔지니어보다도 더 넓고 깊은 insight를 보여주는 경우가 적지 않다. 실제로 사람이 작성한 requirement보다, AI가 생성한 requirement가 더 현실적이고 정제되어 있는 사례도 여러 번 경험했다. 과거 자동차 업계에 Simulink가 본격적으로 도입되었을 때, 많은 엔지니어들이 이런 질문을 던졌다. “Simulink로 설계부터 시작했는데, requirement specification을 다시 작성해야 하는가?” “그렇다면 Simulink 모델을 기준으로 역으로 문서를 만들어야 하는가?” ISO 26262에서는 이에 대해, Simulink 모델 자체가 application software의 requirement와 design을 상당 부분 대표하고 있으며, 일부 추가적인 사양화만으로도 기능 안전 요구를 만족할 수 있다고 설명한다. 이는 requirement와 design, 구현 사이의 경계가 이미 흐려졌다는 점을 제도적으로 인정한 사례라고 볼 수 있다.

오늘날의 개발 환경에서는 기능 요구사항, 구조 설계, prototyping 구현, 구현 결과 검토가 더 이상 분리된 단계가 아니다. 물론 하나의 시스템 전체가 한 번에 이렇게 개발되지는 않지만, 기능 단위나 element 단위에서는 이미 하나의 흐름으로 통합되고 있다.

이런 상황에서, AI를 활용해 생성된 requirement specification이나 design specification이 사람이 직접 타이핑한 문서가 아니라는 이유만으로 덜 안전하거나 덜 신뢰할 수 있다고 말할 수 있을까?

이 질문은 “사람이 운전하는 것이 더 안전한가, 아니면 충분히 성숙한 자율주행 시스템이 더 안전한가?”라는 질문과 본질적으로 같은 맥락에 있다고 생각한다. 나는 엔지니어링 과정, 특히 코드 구현뿐만 아니라 설계 사양화 과정에서도 AI를 적극적으로 활용하는 것이 더 이상 숨길 일이 아니라, 오히려 적극적으로 받아들이고 자랑스럽게 활용해야 할 시점에 이미 도달했다고 본다. 과거에 “높은 안전성과 신뢰성이 필요한 시스템에서 어떻게 C 언어처럼 자유도가 높은 프로그래밍 언어를 사용할 수 있느냐”는 질문이 던져졌던 것처럼, AI 역시 시간이 지나면 자연스러운 도구로 받아들여질 것이다.

그리고 개인적으로는, 현재의 AI 기술 수준만으로도 이미 사람과 동등한 위치에 도달했다고 생각한다. 이제 남은 과제는 AI를 쓸 것인가 말 것인가가 아니라, 어떻게 엔지니어링 프로세스 안에 책임 있게 통합할 것인가일 것이다.