[아이티데일리] 인스웨이브가 AI 시대 엔터프라이즈 시스템 개발의 표준으로 ‘스펙(Spec)’을 강조했다. 시스템을 소스코드가 아닌 명세서(스펙) 단위로 관리하고 운영 배포까지 검증 가능한 구조를 갖춰야 한다는 게 핵심이다.
인스웨이브는 지난 20일 서울 여의도 페어몬트호텔에서 ‘2026 인스웨이브 솔루션스데이’를 개최하고 이 같은 내용을 공유했다.
인스웨이브 김낙천 팀장이 20일 열린 ‘2026 인스웨이브 솔루션스데이’에서 ‘제대로 된 설계서를 그리다’를 주제로 발표하고 있다. (사진=양승갑 기자)
우선 인스웨이브 김낙천 팀장은 ‘제대로 된 설계서를 그리다’를 주제로 AI 시대에 시스템을 스펙으로 관리해야 하는 이유를 강조했다. 스펙은 시스템이 무엇을, 어떻게 동작해야 하는지를 표준화된 형식으로 정의한 명세서를 의미한다.
우선 김 팀장은 AI가 생성하는 코드의 규모와 이를 관리하는 인력 사이의 불균형을 지적했다. 김 팀장은 “AI가 한 타임에 쏟아내는 소스의 양이 약 5,000개 정도 되는데, 이를 관리해야 하는 사람은 IT 인력 기준으로 한 사람 정도 된다”며 “한 사람이 5,000개의 화면을 책임지는 시대”라고 말했다.
그러면서 “운영은 할 수 있겠지만, 어떤 문제가 생겼을 때 누구도 책임질 수 없는 상황이 발생한다는 게 가장 큰 문제이자 현실”이라며 “확인과 추적이 불가능한 소스가 증가한다는 의미”라고 부연했다.
특히 공공·금융 분야에서는 이 문제가 더 까다롭다. 일반 기업은 AI가 만든 코드를 운영 서버에 그대로 올리는 경우도 적지 않지만, 공공·금융권에서는 코드 검토 주체, 승인 절차, 보안 리스크 검증 방식이 명확하지 않아 그대로 적용하기 어렵기 때문이다. 김 팀장은 “이걸 하기 위해서 서드파티 솔루션이나 솔루션 벤더를 불러 여러가지 작업들을 하고 있다”고 전했다.
이 같은 상황에서 인스웨이브가 제시한 해법은 분석(Analyze)·명세(Specify)·생성(Generate)·검증(Assure) 등으로 이어지는 구조다. 김 팀장은 “어느 하나도 빠지면 사실 크게 의미가 없고 네 개가 완벽해야 의미가 있는 체계”라고 강조했다.
이 4단계의 핵심에 놓인 것이 바로 스펙이다. 김 팀장은 “가트너 같은 애널리스트를 비롯한 글로벌 전문가 대부분이 ‘AI 시대에는 명세가 굉장히 중요하다’고 말한다”며 “시스템을 소스가 아니라 명세서, 즉 스펙으로 관리해야 한다”고 설명했다.
인스웨이브가 정의한 스펙은 △화면 설계서 △메타데이터 △테스트 플랜 등으로 구성된다. 화면 설계서는 사람이 읽을 수 있도록 마크다운으로, 메타데이터는 기계가 잘 읽을 수 있도록 JSON으로 작성되며, 테스트 플랜은 시나리오와 케이스로 묶인다.
인스웨이브는 이러한 스펙을 만들기 위한 표준 입력 형태로 △기존 시스템의 레거시 소스 △피그마 URL △자연어 프롬프트 △손으로 그리거나 캡처한 이미지 등을 정의해 두고 있다. 김 팀장은 “이 네 가지 입력값들이 한 곳으로 모인 게 바로 표준 스펙 패키지”라고 설명했다.
인스웨이브 김완수 프로가 20일 열린 ‘2026 인스웨이브 솔루션스데이’에서 ‘설계를 올바르게 완성하다’를 주제로 발표하고 있다. (사진=양승갑 기자)
이어 인스웨이브 김완수 프로는 ‘설계를 올바르게 완성하다’를 주제로 AI가 만든 코드를 운영 환경에 안전하게 올리기 위한 검증 체계를 소개했다. 검증은 △검출 △증명 △판정 △모니터 등으로 구성된다.
김 프로에 따르면 검출 단계에서는 스펙대로 코드가 완성됐는지, 규제 위반은 없는지, 다른 화면에 영향을 미치지 않는지를 시스템이 자동으로 검사한다. AI가 만든 소스에서 흔히 나타나는 환각 증상이나 누락된 코드도 이 단계에서 걸러진다.
이어지는 증명 단계에서는 인스웨이브의 AI 기반 테스트 자동화 솔루션 ‘테스트스퀘어’가 활용된다. 스펙 기반 시나리오에 따라 자동으로 테스트가 진행되고, 변경된 부분이 기존 화면에 미치는 영향까지 회귀 테스트로 검증한다. 김 프로는 “스펙이 생성될 때 그 기준에 맞춰 시나리오도 자동으로 완성된다”고 말했다.
검출과 증명이 자동화 영역이라면 판정 단계에서는 사람이 직접 개입한다. 인스웨이브는 △의도 △스펙 기준 △AI 실행 기록 △코드 원본 △사전 통제 △환경 스냅샷 △사람 결재 △외부 시스템 기록 등을 충족해야 운영에 올릴 수 있는 환경으로 정의한다. 김 프로는 “모든 걸 채워줘야 책임질 수 있는 한 건이 완성된다”고 말했다.
김 프로는 이렇게 AI가 만든 코드라도 사람이 책임의 근거를 남기는 구조를 ‘어슈어드 체인지(Assured Change)’라고 설명했다. 김 프로는 “소스는 AI가 만들고 책임은 사람이 질 수 있는 근거들을 마련할 수 있는 것”이라고 말했다.
마지막 모니터 단계는 운영 배포 이후의 안정성을 담당한다. 모니터링 솔루션 ‘엣지스퀘어(EdgeSquare)’이 운영 환경의 이상 징후를 실시간으로 추적하고 오류로 판단되면 자동 롤백한다. 롤백된 정보는 시스템에 누적돼 다음 변경 작업에 반영된다.
김 프로는 “오류율이 점점 줄어들고 문제가 생겨도 그 문제로 끝나는 게 아니라 그 문제까지 대처할 수 있는 자산을 보유하게 되는 것”이라고 말했다.
그러면서 “자산의 정의가 옛날에는 소스 코드였다면 이제는 설계서, 스펙이 자산의 정의가 되지 않을까 생각한다”며 “코드가 아니라 스펙이 중요하다. 그 기준을 인스웨이브가 만들어서 (고객에게) 제공하겠다”고 말했다.
댓글
0