사람과 AI가 함께 만들어가는 IT: ERWeb을 만드는 이유

AI가 코드를 빠르게 만들어 주는 시대에, 개발자는 무엇을 더 잘해야 할까요?

저는 그 답을 무엇을 만들어야 하는지 정하고, 만들어진 결과가 그 기준에 맞는지 확인하는 일에서 찾고 있습니다. 코드를 작성하는 속도가 빨라질수록 요구사항과 설계, 검증을 연결하는 일이 더 중요해진다고 생각합니다.

최근 모두의창업 지원서를 작성하며 그동안의 개발 경험과 ERWeb을 만드는 이유를 정리했습니다. 이 블로그의 첫 글에는 어떤 문제에서 출발했는지, 그리고 사람과 AI가 함께 일하는 개발 환경을 어떤 방향으로 만들고 있는지 담아 보려 합니다.

개발 현장에서 반복해서 마주한 문제

저는 26년 동안 IT 개발 분야에서 일해 왔습니다. 보안 연구와 게임 개발을 거쳐, 10년 넘게 프리랜서로 여러 프로젝트에 참여했습니다. 코드를 구현하는 일뿐 아니라 요구사항 정의서, QA 테스트 문서, 운영 매뉴얼을 직접 작성하고 검수와 인수인계에도 참여했습니다.

그 과정에서 비슷한 상황을 자주 보았습니다. 요구사항 분석과 기획이 늦어지면 개발에 쓸 수 있는 시간이 줄어듭니다. 일정에 맞춰 구현을 끝내고 나면 테스트와 문서화, 인수인계에 충분한 시간을 남기기 어렵습니다. 요구사항이 바뀌었을 때 어떤 설계와 코드를 수정해야 하는지, 어떤 테스트를 다시 확인해야 하는지 찾는 일도 사람의 기억과 수작업에 기대게 됩니다.

요구사항은 문서에, 설계는 다이어그램에, 구현은 코드에, 검증 기준은 별도의 테스트 문서에 남아 있습니다. 각각은 잘 작성되어 있어도 서로의 연결이 끊어지면 변경 사항을 빠뜨리기 쉽습니다. 다음 담당자는 결과물뿐 아니라 그 결과가 만들어진 이유까지 다시 찾아야 합니다.

이 경험을 통해 저는 개발의 어려움이 코드를 작성하는 데에만 있지 않다는 것을 배웠습니다. 요구사항이 실제 구현과 검증까지 이어지고, 그 연결을 다음 사람에게도 전달할 수 있어야 합니다.

AI가 빨라질수록 함께 볼 기준이 필요합니다

AI를 활용하면서 코드와 문서를 만드는 방식은 크게 달라졌습니다. 제가 경험한 개발 과정에서도 많은 내용을 짧은 시간에 만들어 볼 수 있게 되었습니다. 하지만 결과물을 빠르게 얻는 것과 그 결과가 올바른지 판단하는 것은 서로 다른 일입니다.

문서의 양이 많아지면 사람이 전체 내용을 읽고 이해하는 데에도 시간이 듭니다. 요구사항과 설계, 코드가 서로 같은 내용을 가리키는지 확인해야 하고, 수정 과정에서 예전 기준이 남아 있지는 않은지도 살펴야 합니다. 개발 경험이 적은 사람에게는 AI가 만든 결과를 판단하는 일 자체가 큰 부담이 될 수 있습니다.

그래서 저는 사람과 AI가 함께 참조할 수 있는 개발 기준이 필요하다고 생각합니다. 무엇을 만들기로 했는지, 왜 그렇게 설계했는지, 어떤 결과를 통과로 볼 것인지가 연결되어 있어야 합니다. 그 기준이 있으면 사람은 AI가 만든 결과를 검토할 수 있고, AI에게도 다음 작업에 필요한 맥락을 더 명확하게 전달할 수 있습니다.

데이터베이스 모델링 도구에서 시작한 ERWeb

ERWeb은 제가 개발 업무에 필요해 오랫동안 만들어 온 데이터베이스 모델링 도구에서 출발했습니다. 처음부터 큰 플랫폼을 만들려던 것은 아닙니다. 실제 업무에서 필요한 기능을 직접 구현하고 사용하는 과정이 먼저 있었습니다.

지금은 그 도구를 요구사항 모델링부터 설계, 개발, QA와 테스트까지 이어지는 개발 플랫폼으로 확장하고 있습니다. 데이터 모델과 소프트웨어의 구조를 표현하는 데서 더 나아가, 각 요소가 어떤 요구사항을 위해 존재하는지와 무엇으로 검증할지를 함께 다루려는 방향입니다.

예를 들어, 주문 취소 조건이 달라지는 상황을 생각해 볼 수 있습니다. 요구사항의 문장만 고치는 것으로 작업이 끝나지는 않습니다. 관련 데이터와 API, 화면의 안내, 취소 가능 여부를 확인하는 테스트도 함께 검토해야 합니다. 이때 변경된 요구사항과 관련 요소의 연결을 따라가며 확인할 수 있는 환경을 만들고 싶습니다.

이 예시는 ERWeb이 풀고자 하는 문제를 설명하기 위한 것입니다. 실제 기능과 동작 범위는 앞으로 구체적인 개발 사례와 검증 결과를 통해 소개하겠습니다.

사람과 AI가 공유하는 Source of Truth

제가 ERWeb에서 지향하는 Source of Truth는 개발 과정에서 함께 참조하고 변경을 판단하는 기준입니다. 요구사항, 데이터 모델, 설계, 코드, 인프라, QA와 테스트의 관계를 구조화하고, 실제 작업과 검증에서 활용할 수 있도록 만드는 것이 목표입니다.

그 흐름을 간단히 표현하면 다음과 같습니다.

1. 01요구사항
2. 02설계·모델링
3. 03구현·코드 변환
4. 04인프라
5. 05QA·테스트
6. 06검증

검증 결과를 요구사항과 설계에 다시 반영합니다.

각 단계의 결과가 앞선 요구사항과 이어지고, 검증에서 발견한 문제를 다시 요구사항과 설계에 반영할 수 있어야 합니다. 요구사항이 바뀌면 어떤 부분을 검토해야 하는지 찾을 수 있고, 테스트 결과를 볼 때도 무엇을 확인한 것인지 알 수 있어야 합니다.

사람이 이해할 수 있는 모델을 AI도 활용하도록 연결하는 방법으로 MCP를 통한 접근도 개발 방향에 포함하고 있습니다. 중요한 것은 사람이 모델을 이해하고 검토할 수 있으며, AI 역시 그 기준을 바탕으로 작업하도록 만드는 일입니다. 최종적인 판단에는 합의한 요구사항과 실제 검증 결과가 필요합니다.

Unibase와 함께 이어 가려는 방향

ERWeb과 함께 개발하고 있는 Unibase는 간결한 문법과 SQL 등 개발에 필요한 기능을 통합하는 프로그래밍 언어와 컴파일러 기술입니다. 작성한 코드를 여러 언어와 프레임워크로 변환할 수 있도록 만드는 것을 목표로 하고 있습니다.

ERWeb에서는 무엇을 만들지와 각 요소의 관계를 정의하고, Unibase에서는 그 내용을 실제 구현으로 이어 가는 방법을 발전시키고 있습니다. 두 기술을 결합해 요구사항과 설계에서 구현과 검증으로 이어지는 흐름을 만들고자 합니다.

기술 환경이 달라져도 시스템이 해결하려던 문제와 설계의 의미는 유지할 수 있어야 한다고 생각합니다. 여러 언어와 프레임워크로의 변환, 다른 실행 환경에 대한 대응은 그 방향을 실현하기 위한 개발 과제입니다. 지원 대상과 완성도는 구현과 검증을 통해 하나씩 확인해 나가겠습니다.

실제로 계속 쓰는 제품을 만들기 위해

저는 두 차례의 스타트업 경험을 통해 기술을 구현하는 것만큼 고객의 문제를 정확히 이해하는 일이 중요하다는 것을 배웠습니다. 기대했던 성과를 얻지 못한 경험도 있었습니다. 그 경험은 이번에는 실제 사용자가 무엇 때문에 어려움을 겪는지, 어떤 기능을 계속 사용하는지를 함께 확인해야 한다는 기준이 되었습니다.

모두의창업 지원서에도 스타트업과 소규모 개발팀, 프리랜서의 실제 프로젝트에서 ERWeb의 활용성을 검증하고 싶다고 적었습니다. 요구사항 변경을 관리하는 부담이 줄어드는지, 설계와 구현을 함께 검토하기 쉬워지는지, 검수와 인수인계에 도움이 되는지를 확인하고 싶습니다.

개인과 팀을 위한 제품, 기업 도입, SaaS 협업 환경은 그 검증을 바탕으로 발전시키려는 사업화 방향입니다. 지원서 작성 시점에는 상용화 이전 단계로 정리했으며, 가격과 기능별 제공 범위는 초기 사용자의 이용 방식과 도입 수요를 확인한 뒤 결정할 계획입니다.

이 블로그에 남길 이야기

이곳에는 ERWeb과 Unibase를 만들며 마주한 문제와 설계 판단, 실제 구현과 검증 과정을 기록하려 합니다. 무엇을 만들었는지뿐 아니라 어떤 이유로 선택했고, 어디까지 확인했으며, 무엇이 더 필요한지도 함께 남기겠습니다.

제가 만들고 싶은 개발 환경에서는 사람이 요구사항과 설계를 이해하고 판단하며, AI가 그 기준을 바탕으로 구현을 돕습니다. 그리고 함께 만든 결과를 테스트로 확인하고, 다음 사람이 이어 갈 수 있도록 개발의 기준과 과정을 남깁니다.

사람과 AI가 함께 만들고, 개발의 기준을 남깁니다.

ERWeb을 만드는 이유이자, 이 블로그를 시작하는 이유입니다.