그리드를 내 입맛대로 손보는 법

그리드 튜닝이란? 왜 필요한가

"그리드"는 엑셀처럼 행과 열로 데이터를 보여 주고 편집하게 해 주는 화면 부품입니다. "튜닝"은 그 부품의 기본 동작을 우리 업무에 맞게 살짝 바꾸는 일을 말합니다.

OPEN_GRID는 처음부터 많은 기능을 갖추고 있지만, 모든 회사·모든 화면이 똑같이 동작하길 원하지는 않습니다. 예를 들어 "전화번호를 보여줄 때 가운데 네 자리를 별표로 가리고 싶다", "행을 지우기 전에 한 번 더 확인하고 싶다", "엑셀로 내보낼 때 날짜 형식을 우리 회사 양식으로 바꾸고 싶다" 같은 요구가 생깁니다. 이렇게 기본 동작 위에 우리만의 규칙을 덧입히는 일이 바로 튜닝입니다.

OPEN_GRID의 튜닝이 특별한 이유는 원래 코드(자동차 본체)를 한 줄도 고치지 않고 동작을 바꿀 수 있다는 점입니다. 본체를 안 건드리니, 나중에 OPEN_GRID가 새 버전으로 업데이트되어도 우리가 덧입힌 규칙이 깨지거나 충돌할 걱정이 적습니다. 이 방식의 이름이 override(오버라이드, "덮어쓰기")입니다.

참고로 OPEN_GRID의 현재 정식 버전은 1.0.4입니다. override 튜닝 기능은 정식 출시인 1.0.0부터 제공되며, 이 자료에 보이는 "v1.0.0" 표기는 그 기능이 처음 포함된 릴리스를 가리킵니다. (1.0.1~1.0.4는 버그 수정·라이선스 정비·문서 보강 패치입니다.)

파일 구조 — 어떤 파일이 무슨 일을 하나

OPEN_GRID의 핵심 코드는 src/core/ 폴더 한곳에 모여 있습니다. 파일이 많아 보이지만, 역할별로 묶어 보면 "한 부서씩 일을 나눠 맡은 회사"처럼 깔끔하게 정리됩니다.

역할별로 묶어 본 핵심 파일

한눈에 보는 파일 트리

소스(src/)·빌드 산출물(dist/)·배포 페이지(deploy/)·설계 문서(docs/)의 구조를 트리로 정리했습니다.

완성품(빌드 산출물)은 어떤 모습인가

개발용 코드(src/)는 빌드를 거쳐 dist/ 폴더의 실제 배포 파일이 됩니다. 사용자는 코어(open-grid.js), React용, Vue용, 그리고 스타일(style.css)을 골라 가져다 씁니다. 엑셀 기능에 쓰이는 무거운 부분(xlsx)은 따로 떼어 두어, 필요할 때만 불러오도록 했습니다. 튜닝 부품인 OverrideKernel의 타입 정의(OverrideKernel.d.ts)도 빌드 결과물에 포함되어 있어, 이미 사용할 준비가 되어 있습니다.

튜닝과 직접 연결된 두 가지 핵심 사실

• 6개의 "알고리즘 교체 슬롯"이 부서들에 미리 심어져 있습니다 — 정렬 비교 방식(sortComparator, DataLayer), 필터 판정(filterPredicate, DataLayer), 표시 형식(displayFormatter, CellRenderer), 내보내기 값 변환(cellSerializer, ExportManager), 합계 계산(summaryOp, FooterManager), 그룹 묶는 기준(groupKeyFn, GroupTreeManager). 이 슬롯들이 뒤에 나올 strategy 튜닝의 연결 지점입니다.
• 알림(EventEmitter)·취소(TriggerManager)·덮어쓰기(OverrideKernel)는 역할이 다릅니다. 알림은 "구경만", 트리거는 "막거나 취소", 오버라이드는 "동작 자체를 감싸 바꾸기"입니다. 세 가지가 서로 부딪히지 않게 깔끔히 나뉘어 있습니다.

UML 설계 그림 — 이 그림은 무엇을 말하나

UML은 "코드를 그림으로 그린 설계도"입니다. 글로 길게 설명할 구조를 한 장의 그림으로 보여 줍니다. 여기서는 프로젝트 전체 구조 10장과, 튜닝(override) 설계 5장을 차례로 보고, 각 그림이 무엇을 말하는지 한 단락씩 풀어 봅니다.

가. 프로젝트 전반 설계 그림 10종

모두 실제 코드와 1:1로 대조해 검수를 마친(결함 0·회귀 0) 그림입니다.

1. 4계층 조감도

component

전체를 위에서 내려다본 지도입니다. 위에서부터 프레임워크 어댑터 → 안내데스크(파사드) → 6개 도메인 부서 → 순수 계산 엔진과 화면(DOM) 순으로, 일이 어느 방향으로 흐르는지를 한 장에 담았습니다.

2. 안내데스크 + 6부서 합성도

class

안내데스크(OpenGrid)가 여섯 개의 핵심 부서를 어떻게 품고, 필요한 도구를 각 부서에 넣어 주는지를 보여 줍니다. "누가 누구를 가지고 있나"를 한눈에 알 수 있습니다.

3. 데이터 보관소(DataLayer) 모델

class

데이터를 담는 부서의 속을 들여다본 그림입니다. 각 행이 어떤 정보를 들고 있고, "안 바뀜·추가됨·수정됨·삭제됨" 같은 상태를 어떻게 기억하는지 그 구조를 보여 줍니다.

4. 데이터 채워 넣기(setData) 흐름

sequence

그리드에 데이터를 한꺼번에 넣을 때 일이 일어나는 순서를 시간 순으로 그렸습니다. 넣기 전후의 트리거 점검, 필터 적용, 트리·그룹으로 나뉘는 갈림길까지 차례대로 따라갈 수 있습니다.

5. 가상 스크롤 렌더 사이클

sequence

데이터가 아주 많아도 빠른 비결을 보여 줍니다. 화면을 다시 그릴 적절한 타이밍을 잡고, "지금 눈에 보이는 범위"만 계산해 그 부분만 그리는 과정을 순서대로 설명합니다.

6. 셀 편집 라이프사이클

sequence

셀 하나를 고치는 전 과정입니다. 편집해도 되는 셀인지 판단하고, 입력 도구(에디터)를 띄우고, 다 고치면 값을 확정해 닫기까지 — 클릭에서 저장까지의 흐름을 따라갑니다.

7. 그리드↔그리드 행 이동

sequence

한 그리드의 행을 다른 그리드로 끌어다 옮길 때의 순서입니다. 드래그나 셔틀로 행을 옮기면서, 열을 서로 짝짓고, 3단계 이벤트가 차례로 발생하는 과정을 보여 줍니다.

8. 행 상태 전이도

state

한 행이 "안 바뀜 → 추가됨 → 수정됨 → 삭제됨" 같은 상태들 사이를 어떤 조건에서 오가는지를 신호등처럼 그렸습니다. 어떤 동작이 어떤 상태 변화를 일으키는지 알 수 있습니다.

9. 빌드 · 배포 파이프라인

activity

개발 코드가 배포 파일로 바뀌는 작업 라인입니다. 라이브러리 빌드 → 데모 사이트 빌드 → 코드 난독화 순으로 이어지는 공정을 순서도로 보여 줍니다.

10. 프레임워크 어댑터 통합

component

React·Vue 어댑터가 코어를 어떻게 감싸 안고, 각 프레임워크의 생애주기(생성·소멸)에 맞춰 그리드를 켜고 끄는지를 보여 줍니다.

나. override 튜닝 설계 그림 5종

"본문을 한 줄도 안 고치고(C1) 어떻게 커스터마이징할 수 있나"를 풀어낸 설계 그림들입니다.

11. 도입 전 모습 (BEFORE)

before

override가 없던 시절의 그림입니다. 옵션·이벤트·트리거만으로는 바꿀 수 있는 게 제한적이었다는 점, 즉 "왜 새 방법이 필요했는가"의 출발점을 보여 줍니다.

12. 도입 후 모습 (AFTER, 상세)

after

튜닝 부품(OverrideKernel)이 더해진 뒤의 구조입니다. 두 가지 튜닝 방식(본문 무수정 순수 래핑 ✅ / 슬롯 교체 🔧), 무한 반복을 막는 안전장치, 프레임워크 연결까지 자세히 담겨 있습니다.

13. 도입 전후 한 세트 비교

before · after

앞의 BEFORE와 AFTER를 한 장에 나란히 놓고, override가 둘을 어떻게 잇는지 화살표로 보여 줍니다. "본문을 안 고친다(C1)"는 약속이 그림 범례로 정리되어 있습니다.

14. 여러 튜닝이 겹칠 때의 합성 방식

composition

같은 동작에 튜닝을 여러 번 겹쳐 입혔을 때 어떤 순서로 실행되는지를 보여 줍니다. 먼저 등록한 것이 안쪽(원본에 가까움), 나중에 등록한 것이 바깥쪽이 되며, 안쪽 원본은 orig() 호출로 불려 나옵니다.

15. 무엇을 쓸지 고르는 판단 기준

decision

상황에 따라 override·strategy·trigger 중 무엇을 써야 하는지 판단을 도와주는 흐름도입니다. "동작을 감쌀까, 알고리즘을 갈아낄까, 막거나 취소할까"를 선택하는 지도 역할을 합니다.

override 튜닝 — 쉽게 풀어 보기

이제 핵심입니다. override는 그리드의 동작을 "본체를 안 고치고" 바꾸는 방법입니다. 어떻게 그런 일이 가능한지, 그리고 두 종류의 튜닝이 어떻게 다른지 차근차근 살펴봅니다.

두 가지 튜닝 방식 — ✅ 순수 래핑 vs 🔧 슬롯 교체

주요 API 한눈에

안전장치 — 튜닝이 사고로 이어지지 않게

• 겹쳐 입히기 순서(FIFO 합성): 같은 동작에 여러 튜닝을 걸면, 먼저 등록한 게 안쪽, 나중 게 바깥쪽이 됩니다. 바깥에서 orig()를 부르면 한 겹씩 안쪽으로 들어가 결국 원본까지 닿습니다.
• 무한 반복 방지(재진입 가드): 튜닝이 자기 자신을 끝없이 부르는 사고를 막습니다. 깊이를 32까지 허용하고, 같은 이름이 빙빙 도는 진짜 순환만 차단합니다. 정당하게 한 번 더 부르는 경우는 { reentrant: true }로 명시해 허용할 수 있습니다.
• 오류 처리(기본은 엄격): 튜닝 안에서 오류가 나면 기본적으로 그대로 알립니다(숨기지 않음). 꼭 필요할 때만 { onError: 'fallback' }로 "경고 후 원본 실행"을 켤 수 있습니다(되돌리기 불가가 명시되어 있습니다).
• 종료 시 자동 복구: 그리드를 닫으면(destroy) 걸어 둔 모든 튜닝이 자동으로 벗겨져 원래대로 돌아갑니다. 찌꺼기가 남지 않습니다.

꼭 알아 둘 주의점

• 증분 추가는 경로가 다릅니다: pushData·prefixData 같은 "조금씩 덧붙이기"는 정문(setData)을 거치지 않습니다. 그래서 setData에 건 튜닝은 이 경우엔 적용되지 않습니다. 필요하면 pushData에도 따로 튜닝해야 합니다.
• 정문(공개 메서드)만 감쌀 수 있습니다: 내부에서만 쓰는 비공개 함수나 부서 안쪽 메서드는 순수 래핑으로 닿지 않습니다. 그럴 땐 슬롯 교체(🔧)나 다른 방법을 씁니다.
• 핫패스 슬롯 주의: 그룹 기준(groupKeyFn)은 행마다 불리는 "뜨거운 길"이라, 이 슬롯에서 난 오류는 따로 격리되지 않습니다. 신중히 작성해야 합니다.

override · strategy · trigger 역할 구분

세 가지는 비슷해 보여도 쓰임이 다릅니다. 트리거(TriggerManager)는 동작을 막거나 취소할 때, 이벤트(EventEmitter)는 무슨 일이 일어났는지 구경만 할 때, 오버라이드(OverrideKernel)는 동작 자체를 감싸 바꿀 때 씁니다. 셋이 깔끔히 나뉘어 있어 서로 충돌하지 않으며, override 안에서 orig()를 부르면 기존 트리거도 함께 작동합니다(정문을 거치는 동작에 한함).

데모와 가이드로 더 알아보기

말로만 보면 어렵습니다. 실제로 동작하는 데모와, 상황별로 정리된 가이드 문서를 함께 보면 훨씬 빨리 이해됩니다. override 데모는 32가지 사례 × 5개 프레임워크(Vanilla·React·Vue·jQuery·AngularJS)로 준비되어 있습니다.

이 페이지는 사내 참고용 준비 자료입니다. 정확한 사실 출처는 SE 패널 기술 초안(GRID_TUNING_REFERENCE_SE.md)과 설계 권위본(docs/design/uml/_panel/94_final_synthesis.md), 그리고 실제 소스 코드입니다.