부진했던 React 프로젝트와 오래된 Delphi 습관이 프레임워크를 만들게 된 계기

이것은 파트 2입니다. Part 1에서는 '느낌으로 코딩한 MVP'를 AI 에이전트가 계속 확장할 수 있는 무언가로 바꾸는 방법을 보여줍니다. UECA-React가 탄생하게 된 과정은 이렇습니다.

문제가 있던 프로젝트

2022년, 저희 회사는 레거시 웹 앱을 재작성하고 있었습니다: 서버는 .NET Core를 사용하고 클라이언트는 Blueprint.js와 MobX를 이용한 React였습니다. 저희는 소규모 팀이었습니다. 전담 디자이너도, 비즈니스 분석가도 없었죠.

저는 다른 프로젝트에 참여하다 옆에서 지켜보고 있었습니다. 1년 동안의 작업 끝에 코드는 사방에 props가 주입된 저수준(low-level) React 더미 같았고, 개발자마다 레이아웃을 구축하는 방식이 달랐습니다. 이건 안 될 것 같았습니다. 프로젝트가 중단되고 팀이 해체될까 봐 걱정했습니다.

그래서 제가 돕기로 결정했습니다.

Delphi 습관

저는 원래 웹 개발자가 아닙니다. 저는 Delphi로 성장했고, 처음 접한 것은 1995년이었습니다. 그때 저를 사로잡았던 것은 프론트엔드 개발이 얼마나 명확할 수 있는지였습니다: 컴포넌트는 속성(properties), 이벤트(events), 그리고 시각적 부분(visual part)을 가지고 있으며, 이들을 조합하여 애플리케이션을 구축합니다.

Delphi에서도 저는 저수준 코드를 작성한 적이 없습니다. 항상 재사용 가능한 빌딩 블록을 먼저 만들고 그것들로 애플리케이션을 조립했습니다. 또 다른 아이디어는 예전 리포트 작성기 IDE에서 얻었습니다: **메시지 버스(message bus)**입니다. 컴포넌트는 누가 응답할지 알 필요가 없고, 단지 누군가가 응답해 줄 것이라는 사실만 알면 됩니다.

첫 버전을 작성하여 팀에 보여주었습니다. 개발자들은 보수적이었고, 경계심을 가졌습니다. 하지만 이 패턴은 즉흥적인 여지를 거의 남기지 않습니다. 문서에서 말하는 방식대로, 마치 레일 위를 달리는 것처럼 코드를 작성해야 합니다.

몇 개의 화면을 거치자 속도 차이가 명확했습니다. 몇 달 안에 팀원들은 스스로 그 복잡하게 얽힌 화면들을 다시 작성하기 시작했습니다. 프로젝트는 구원받았고, 일자리들도 지켜졌습니다. 아직도 모두 거기서 일하고 있습니다.

이름과 첫 AI의 도움

'Unified Encapsulated Component Architecture'(UECA)라는 이름은 ChatGPT에서 나왔으며, 이 모델이 제가 첫 문서를 작성하는 데 도움을 주기도 했습니다. 저는 심지어 ChatGPT가 존재하기 전부터 기계가 생성한 코드를 염두에 두고 이 패턴을 설계했습니다. 모델들이 충분히 좋아졌을 때, 그 아이디어는 단순히 작동했습니다. 저는 MUI 컴포넌트를 Copilot으로 감싸기 시작했고, 이후 Claude Code로 넘어갔습니다.

다음 계획

가장 놀라운 부분은 버전 3.0이었는데, 이때 AI 에이전트가 제가 작성한 코드의 버그를 찾아내고, 테스트 코드를 작성하며, 프레임워크의 트레이스 뷰어까지 구축했습니다. 이것이 다음 포스팅 주제입니다.

한편으로는:

• npm: https://www.npmjs.com/package/ueca-react
• UECA-React 자체로 빌드된 앱에서 설명하는 아키텍처 및 아이디어: https://nekutuzov.github.io/ueca-react-website-public/