2009년, Flash와 ActiveX가 하이엔드 웹 UI의 표준처럼 여겨지던 시절이었습니다.
저는 작은 웹에이전시에서 개발팀장을 맡고 있었습니다.
매일 웹페이지에 Flash 코드를 붙이고 ActiveX를 연결했습니다. 그런데 무엇보다 싫었던 것은 제가 짠 HTML이 점점 지저분해지는 것이었습니다.
아무리 들여쓰기를 예쁘게 하고 줄을 맞춰도 마음에 들지 않았습니다.
지금은 너무도 흔한 TypeScript는 존재감조차 없던 시절이었고, Flash와 ActiveX 코드는 언제 터질지 모르는 시한폭탄처럼 느껴졌습니다.
그러던 중 어느 날 생각했습니다.
“나도 데이터 그리드를 내 손으로 한번 만들어보자.”
그렇게 개발을 시작했고, 수차례 시행착오를 겪은 뒤 2013년에 드디어 AXISJ라는 오픈소스를 공개하게 되었습니다.
https://dev.axisj.com/samples/AXGrid/index.html#AXexec
그렇게 AXGrid가 만들어졌습니다.
얼마 전 문득 옛날 AXGrid 데모 페이지에 접속해봤습니다.
놀랍게도 아직 살아 있었습니다.
2013년 날짜가 찍힌 데이터를 보여주는 Grid가 2026년의 Chrome에서도 움직이고 있었습니다.
13년 전의 코드를 다시 보고 있으니 기분이 묘했습니다.
그때는 몰랐습니다.
제가 앞으로 데이터 그리드를 몇 번이나 다시 만들게 될지.
첫 번째, AXGrid. jQuery의 시대
AXGrid를 만들던 시절의 웹 개발은 지금과 많이 달랐습니다.
jQuery로 DOM을 찾고, 이벤트를 연결하고, HTML을 만들고, 직접 화면을 변경했습니다.
Grid 역시 마찬가지였습니다.
기능이 하나 늘어날 때마다 상태와 DOM을 어떻게 맞출 것인지 고민해야 했고, 코드는 점점 스파게티처럼 복잡해졌습니다.
하지만 당시에는 그것보다 더 중요한 목표가 있었습니다.
“웹에서도 업무 시스템에 제대로 사용할 수 있는 Grid를 만들어보자.”
대용량 데이터, 정렬, 편집, 컬럼 고정, 셀 병합, 페이징 같은 기능을 하나씩 구현했습니다.
많은 시행착오가 있었지만 AXGrid를 만들면서 업무용 UI가 얼마나 복잡한 문제인지 처음 제대로 경험했습니다.
그리고 기능이 많아질수록 새로운 고민이 생겼습니다.
이 복잡한 코드를 어떻게 더 잘 나눌 수 있을까?
그 고민이 두 번째 Grid로 이어졌습니다.
두 번째, ax5ui-grid. 모듈화를 꿈꾸다
두 번째는 ax5ui-grid였습니다.
https://ax5ui.axisj.com/ax5ui-grid/demo/11-collector.html
AXGrid를 만들면서 가장 아쉬웠던 것 중 하나가 구조였습니다.
하나의 UI 컴포넌트가 커질수록 기능들은 서로 얽히기 시작합니다.
Grid만의 문제도 아니었습니다.
Modal, Picker, Menu, Calendar 같은 여러 UI 컴포넌트에서 비슷한 문제를 반복해서 해결하고 있었습니다.
그래서 ax5ui에서는 조금 다른 목표를 세웠습니다.
“UI를 더 작은 책임으로 나누고 재사용 가능한 구조로 만들자.”
저에게 ax5ui-grid는 단순히 AXGrid의 다음 버전이 아니었습니다.
첫 번째 Grid를 만들면서 배운 것을 바탕으로 모듈화된 UI 컴포넌트란 무엇인가를 고민했던 두 번째 시도였습니다.
Frozen Row와 Column, Summary, Inline Editing, Merge Cells, Excel Export 같은 업무용 기능들은 여전히 필요했습니다.
하지만 관심은 단순히 기능을 하나 더 만드는 것에서 어떤 구조로 만들어야 오래 유지할 수 있는가로 조금씩 이동하고 있었습니다.
그러던 중 웹 개발의 중심이 또 크게 바뀌기 시작했습니다.
React였습니다.
세 번째, axui-datagrid. React와 TypeScript
2017년에는 axui-datagrid를 만들었습니다.
이번에는 React와 TypeScript였습니다.
https://github.com/jsdevkr/axui-datagrid
기존 Grid를 React Component로 감싸는 정도로는 만들고 싶지 않았습니다.
React 방식으로 다시 생각해보고 싶었습니다.
jQuery 시절에는 DOM이 중요한 대상이었습니다.
DOM을 찾고, 값을 읽고, 변경하고, 이벤트를 연결했습니다.
React에서는 생각하는 방법부터 달라졌습니다.
DOM을 어떻게 변경할까?
보다
상태가 무엇이고, 그 상태에서 화면이 어떻게 표현되어야 할까?
를 먼저 생각하게 됐습니다.
TypeScript도 중요한 변화였습니다.
Grid는 생각보다 API가 굉장히 많습니다.
Column 정의부터 Editor, Formatter, Selection, Sort, Event까지 수많은 데이터 구조가 서로 연결됩니다.
JavaScript에서는 문서를 열어봐야 알 수 있었던 것들을 TypeScript에서는 코드 자체로 더 명확하게 표현할 수 있었습니다.
세 번째 Grid를 만들면서 저는 다시 한번 느꼈습니다.
프레임워크가 바뀌면 단순히 문법만 바뀌는 것이 아니라 프로그램을 설계하는 방식도 함께 바뀐다는 것을요.
그리고 이 정도 만들었으면 충분하다고 생각했습니다.
솔직히 말하면,
이제 다시는 데이터 그리드를 만들지 않을 줄 알았습니다.
Grid는 생각보다 정말 피곤한 컴포넌트입니다.
그런데 2026년.
저는 또 만들고 있습니다.
네 번째, BGrid
이름은 BGrid(BeautifulGrid) 입니다.
만들고 나니 너무 예뻐서 이름을 이렇게 지었습니다.
React와 TypeScript를 사용합니다.
그런데 재미있는 것은 이제 React와 TypeScript 자체는 더 이상 새로운 목표가 아니라는 점입니다.
이제는 너무 당연한 도구가 되었습니다.
그 대신 완전히 새로운 변화가 찾아왔습니다.
AI입니다.
요즘 저는 예전처럼 모든 코드를 처음부터 끝까지 혼자 작성하지 않습니다.
AI와 이야기하면서 설계하고, 코드를 작성하고, 테스트하고, 다시 고칩니다.
처음에는 AI를 조금 더 편리한 자동완성 정도로 생각했습니다.
하지만 계속 사용하다 보니 생각이 달라졌습니다.
우리가 라이브러리를 설계하는 방법 자체도 조금씩 달라질 수 있겠다는 생각이 들었습니다.
사람이 읽는 API에서, 사람과 AI가 함께 읽는 API로
예전에는 좋은 API를 만들 때 이런 것을 생각했습니다.
개발자가 이해하기 쉬운가?
이름이 일관적인가?
문서가 충분한가?
예제가 이해하기 쉬운가?
이것들은 지금도 중요합니다.
그런데 한 가지 독자가 더 생겼습니다.
AI coding agent입니다.
AI에게 어떤 라이브러리를 사용해서 기능을 만들어달라고 하면 AI는 마법처럼 그 라이브러리를 이해하는 것이 아닙니다.
TypeScript 타입을 읽고, API 이름을 보고, 문서를 찾고, 예제를 읽고, 그 안에서 규칙을 추론합니다.
생각해보면 사람이 새로운 라이브러리를 배우는 과정과 그렇게 다르지도 않습니다.
그래서 BGrid를 만들면서 새로운 질문을 하고 있습니다.
“AI가 이해하기 좋은 오픈소스는 어떤 모습이어야 할까?”
명확한 TypeScript 타입.
예측 가능한 API.
충분한 실행 예제.
일관된 Naming.
구조화된 Documentation.
그리고 AI가 프로젝트의 전체 맥락을 이해할 수 있도록 제공하는 문서.
이런 것들이 단순히 Developer Experience를 위한 것만은 아닐 수도 있습니다.
앞으로는 Developer Experience와 AI Developer Experience가 함께 중요해질 수 있다고 생각합니다.
BGrid는 그 가능성을 시험해보는 프로젝트이기도 합니다.
그런데 13년 동안 변하지 않은 것이 있습니다
최근 옛날 Grid들을 다시 보면서 재미있는 사실을 발견했습니다.
기술은 정말 많이 바뀌었습니다.
jQuery에서 React로.
JavaScript에서 TypeScript로.
DOM 중심 개발에서 Component Architecture로.
그리고 이제 혼자 코딩에서 AI와 함께 코딩하는 방식으로 넘어가고 있습니다.
그런데 Grid의 예제를 열어보면 묘하게 익숙합니다.
13년 전에도 이런 요구가 있었습니다.
컬럼 고정해주세요.
셀에서 바로 수정할 수 있게 해주세요.
셀 합칠 수 있나요?
마지막에 합계 보여주세요.
키보드로 이동할 수 있게 해주세요.
2026년에도 비슷합니다.
프레임워크는 몇 번이나 바뀌었는데 고객의 요구사항은 놀라울 정도로 비슷합니다.
그래서 이런 생각이 들었습니다.
The tools changed. The problems didn't.
도구는 바뀌었지만 우리가 해결해야 하는 문제는 그렇게 많이 바뀌지 않았습니다.
네 번 만들고 나서야 조금 알 것 같습니다
첫 번째 AXGrid에서는 웹에서 제대로 동작하는 업무용 Grid를 만들고 싶었습니다.
두 번째 ax5ui-grid에서는 모듈화된 UI Component를 만들고 싶었습니다.
세 번째 axui-datagrid에서는 React와 TypeScript 방식으로 Grid를 다시 설계하고 싶었습니다.
그리고 네 번째 BGrid에서는 AI와 함께 개발하는 시대의 오픈소스 UI Component가 어떤 모습이어야 하는지 고민하고 있습니다.
돌아보면 네 프로젝트는 같은 것을 네 번 만든 것이 아니었습니다.
매번 그 시대에 제가 중요하다고 생각했던 질문을 가지고 Grid를 다시 만들었습니다.
그래서 아마 계속 다시 만들었던 것 같습니다.
오픈소스를 다시 시작하며
요즘 같은 시대에 다시 오픈소스를 만드는 것이 이상해 보일 수도 있습니다.
AI에게 이야기하면 순식간에 코드가 만들어지는 시대니까요.
저도 그런 생각을 했습니다.
“이제 누가 UI Component Library를 찾아서 설치할까? 그냥 AI에게 만들어달라고 하지 않을까?”
그리고 잠깐 이런 생각도 했습니다.
“난 이제 끝났구나.”
그런데 BGrid를 만들면서 오히려 반대로 생각하게 됐습니다.
AI가 코드를 더 많이 작성할수록 잘 만들어진 기반 코드의 가치가 더 커질 수도 있습니다.
AI에게 매번 Grid를 처음부터 만들게 하는 것과, 오랫동안 고민해서 만들어진 Grid를 도구로 주고 그 위에서 업무를 해결하게 하는 것은 다른 문제입니다.
무엇보다 토큰을 엄청 절약할 수 있습니다.
AI가 모든 것을 직접 만들어야 할 이유는 없습니다.
사람도 그렇게 개발하지 않으니까요.
우리는 좋은 라이브러리와 좋은 오픈소스를 가져다 쓰면서 더 중요한 문제에 집중해왔습니다.
AI도 결국 그렇게 될 수 있다고 생각합니다.
그래서 2026년에 다시 오픈소스 Grid를 시작했습니다.
13년 전에는 제가 네 번째 Grid를 만들게 될 거라고 생각하지 못했습니다.
이번이 마지막일지도 모르겠습니다.
그런데 첫 번째 AXGrid 데모가 13년이 지난 지금도 브라우저에서 돌아가는 모습을 보고 있으니 함부로 장담하지 않는 편이 좋을 것 같습니다.
어쩌면 몇 년 뒤 또 이렇게 말하고 있을지도 모르겠습니다.
“다섯 번째 Grid를 만들고 있습니다.”
그때는 또 어떤 시대가 되어 있을지 궁금합니다.
지금은 일단,
네 번째를 잘 만들어보려고 합니다.
그러기 위해서는 여러분의 관심이 필요합니다.
Demo: https://bgrid.axisj.com/
GitHub: https://github.com/axisj/beautiful-grid
BGrid가 괜찮다고 느껴지셨다면 GitHub에서 Star 하나 눌러주시면 큰 힘이 됩니다.
그리고 실제로 사용해보시고 불편한 점이 있다면 Issue나 의견을 남겨주세요.