AI 시대의 소프트웨어 개발

먼저, 이 기사는 포엠(Poem)적인 내용입니다.

제멋대로인 미래 예상도를 상상한 내용으로 구성되어 있습니다.

Claude Code, Codex를 비롯하여, 온갖 코드 생성 툴이 세상에 나오고 있습니다.

이것들은 매우 강력한 개발 파트너가 될 것임이 틀림없을 것입니다.

AI 코드 생성(AI Code Generation)이 탄생하기 전과 현재에는 어떤 변화가 있을까요.

제 개인적인 견해를 정리해 보고자 합니다.

먼저, 워터폴 모델(Waterfall Model)이란, 일반적으로 요구사항 정의(Requirements Definition) → 설계(Design) → 구현(Implementation) → 단위 테스트(Unit Test) → 결합 테스트(Integration Test)... 와 같이 물의 흐름처럼 위에서부터 순서대로 공정을 진행해 나가는 개발 모델임은 자명한 사실입니다.

한편, 프로토타입 모델(Prototype Model)이란, 일단 원형을 작성하여 테스트나 동작을 보고 기능 개선을 진행해 나가는 개발 기법입니다.

코드 생성 AI의 등장에 의해, 소프트웨어 개발의 상당수는 워터폴 모델에서 프로토타입 모델로 이행할 것이라고 예측할 수 있습니다.

실제로 코드 생성 AI를 이용해 본 적이 있는 사람이라면 잘 아는 사실이겠지만, AI에게 요구사항 정의를 전달함으로써 설계 공정을 건너뛸 수 있습니다.

즉, "일단, 만들어 본다" 가 용이하게 가능해진다는 뜻입니다.

AI에게 일단 머릿속에 있는 이미지를 전달하여, 일단 사용할 수 있는 것을 만들어 달라고 한다.

그 후, 실제로 사용해 보면서 "이런 기능이 필요해" 라거나 "이 부분에 버그가 있어" 라고 깨달았을 때, AI에게 추가 요구사항이나 수정 의뢰를 한다.

다음과 같은 흐름으로 소프트웨어 개발이 이루어지는 이미지입니다.

AI 코드 생성의 강점은, 추가 요구사항에 대해서도 인간이 복잡한 사고를 하지 않아도 AI 측에서 코드를 보고 수정 방법을 제안하고 구현을 해준다는 점입니다.

사람이 설계했을 경우에는 중간 단계에서의 사양(Specification) 추가는 큰 재작업(Rework)이 되거나 대폭적인 변경을 해야 하는 경우도 많지만, 그 부분도 AI가 생각해 줍니다.

실제로 AI로 개발을 해보면 그것을 많이 실감할 수 있을 것입니다. "이런 기능 추가라면 기존 처리의 상당 부분을 다시 검토해야 하니까 어렵겠지" 라고 생각되는 사양 추가라도 의외로 유연하게 대응해 줍니다.

그 부분도 문제없습니다. AI에게 맡기면 됩니다.

• 어느 정도 완성된 타이밍에 테스트 설계(Test Design)를 의뢰한다.
• 생성된 테스트 설계를 확인한다.
• 사람이 실시하거나 테스트도 AI에게 의뢰한다.

이러한 것들이 가능해집니다.

요구사항 정의 단계에서 테스트 설계에 대해서도 포함해 둔다면 더욱 용이합니다. 구현과 동시에 테스트 코드(Test Code)도 생성하도록 하면 되기 때문입니다.

그 테스트 코드를 기능 추가 타이밍에 실행함으로써, 디그레션(Degression, 퇴보) 체크도 가능해집니다.

사양서에 대해서도 코드로부터 역으로 생성을 의뢰할 수 있습니다. 워터폴 모델로 비유하자면 '강 거슬러 올라가기'와 같은 조작이네요.

소스 코드로부터 데이터베이스(Database) 정의나 API 정의를 ER도(ER Diagram)나 OpenAPI로 변환한 문서를 작성할 수 있습니다.

물론 요구사항 정의서도 개발 당시에 주었던 것에서 변해 있으므로, 그 부분도 AI에게 최신 버전을 작성하도록 할 수 있습니다.

사용 설명서나 LP(Landing Page) 생성도 가능합니다.

아니요, 전혀 이해하지 않아도 된다는 뜻은 아닙니다.

소프트웨어 개발에 대해 전혀 지식이 없어도 프로덕트(Product)는 제작할 수 있을 것입니다.

다만, 그 품질에 대해서는 AI가 담보해 주지 않습니다.

물론 기본적인 동작 확인은 구현 시에 해주지만, 보안(Security) 측면에서 문제가 있는 코드도 포함되어 있을 가능성은 제로가 아닙니다. (동작하는 것과 보안 등의 비기능 요구사항(Non-functional Requirements)은 별개의 문제)

따라서 지식이 있다면 "이 구현은 SQL 인젝션(SQL Injection) 문제는 없나요? 패스 파라미터 인젝션(Path Parameter Injection) 문제는 없나요?" 등과 같이 확인할 수 있고, 실제로 문제가 없는지 확인할 수도 있습니다.

실제로 RLS(Row Level Security)로 설계하도록 시켰는데, URL의 경로를 바꾸는 것만으로 본래 액세스해서는 안 되는 데이터에 액세스할 수 있는 버그가 발견되기도 했습니다. (물론 수정을 의뢰하고, 다른 기능에도 동일한 문제가 없는지 수평 전개도 시켰습니다)

이처럼 생성 AI가 우수하더라도 아직 인간이 개입할 여지는 존재합니다.

이것은 제 사견입니다만, "독학으로 지식도 기술도 있지만, 아직 제품 개발을 해본 적이 없는 신입 엔지니어" 와 같은 이미지로 받아들이면 좋을 것 같습니다.

앞서 언급했습니다만, 앞으로는 일단 만들고, 기능 추가나 개선을 해 나가는 "프로토타입 모델 개발" 이 주류가 되지 않을까 생각합니다.

워터폴 모델 (Waterfall Model)이 유효한 것은 하드웨어를 동반하는 개발뿐이며, 소프트웨어만으로 이루어지는 개발에서는 앞으로 상당히 희귀한 존재가 되지 않을까 생각합니다.

AI에 대해 너무 의존하지도, 그렇다고 너무 공포심을 갖지도 않는 적절한 거리감을 유지하며 함께해 나감으로써, 향후 소프트웨어 개발은 더욱 진보를 이룰 것이라고 생각합니다.