이 기사에서 배울 수 있는 것

• 셀 수가 많은 Excel을 보았을 때 "대량 레코드를 쌓아두는 간이 DB"라고 단정 짓는 것의 함정
• 셀 수가 많아지는 이유의 3가지 분류와, 각각에 따라 "Excel이 적합한지"에 대한 판단이 달라지는 점
• Excel에 맡겨도 되는 범위와, DB·업무 시스템에 맡겨야 하는 범위의 구분 방법

1. 서론

지난 기사 「Excel/VBA와 모던 개발 사이」를 공개한 후, X(Twitter)나 Hatena Bookmark에서 여러 반응을 받았습니다. 그중에서도 인상적이었던 것은 기사에서 소개한 "8000셀 규모의 수식 연쇄"라는 표현에 대한 반응입니다. 규모의 크기에 놀라는 목소리, "모처럼 Excel을 손에서 놓을 기회인데"라는 목소리, 현장이 Excel을 손에서 놓지 못하는 것을 흥미로워하는 목소리 등 온도 차는 다양했습니다.

이러한 반응들을 살펴보며 깨달은 것은, Excel이라는 동일한 단어를 사용하고 있어도 사람마다 떠올리는 Excel의 용도가 크게 다르다는 점입니다. 고객 대장이나 안건 관리표처럼 행에는 레코드, 열에는 속성을 나열하는 "간이 데이터베이스(DB)"와 같은 용도를 떠올리는 사람이 있는가 하면, 개별 사례마다 데이터를 가져와 복잡한 처리를 수행하고, 알기 쉬운 표 등으로 만들어 확인하며, 장표를 발행하는 등의 "업무 처리 템플릿"으로서의 용도를 떠올리는 사람도 있는 것 같습니다.

셀 수가 많은 Excel이라고 하면, 대량의 레코드를 쌓아두고 있을 것이라고 생각하는 사람도 많을 것입니다. 하지만 셀 수가 많아지는 이유는 그뿐만이 아닙니다. 이번에는 이 차이를 정리하겠습니다.

2. Excel이 DB 대신 사용되면 위험한 이유

Excel을 "간이 DB"로 사용하는 것, 즉 고객 대장이나 안건 관리표처럼 대량의 레코드를 지속적으로 축적·갱신·검색하는 용도로 사용하는 것에 대해서는 많은 기사와 공식 자료에서 위험성이 지적되고 있습니다. 구체적으로는 다음과 같은 문제가 발생하기 쉽습니다.

• 여러 명에 의한 동시 업데이트로 내용이 충돌하거나 덮어씌워짐
• 변경 이력이 남지 않음
• 승인 플로우(Flow)나 권한 관리 메커니즘이 없음
• 참조 무결성(다른 값과의 모순)이 보장되지 않음
• 대량 데이터의 검색·추출 성능이 낮음
• 중복 데이터 관리가 어려움
• 파일이 분산되어 어떤 것이 최신인지 알 수 없게 됨
• 행 삭제나 덮어쓰기로 데이터가 소실됨
• 타 시스템과의 연계 기반으로서 취약함

Microsoft의 공식 지원 페이지 「Access 또는 Excel을 사용하여 데이터 관리하기」에서도, 여러 사용자가 데이터 무결성을 유지하고 싶다면 Access가 적합하며, Excel은 복잡한 수치 데이터의 분석이나 계산에 적합하다고 설명되어 있습니다 [1].

note.com의 기사에서도 이전에 "Excel이 나쁜 것이 아니라, Excel을 DB 대신 사용하는 것이 위험하다"라는 정리를 본 적이 있습니다 [2]. 여러 명의 업데이트·이력·승인·정확성·타 시스템 연계가 필요한 업무에서는 데이터의 본체는 DB나 시스템 측에 두고, Excel은 보고·가공하고·출력하기 위해 사용해야 한다는 주장으로, 매우 적절한 정리라고 생각합니다.

"DB"라고 해도 단일한 형태가 아니라, 상주 서비스를 구축하는 본격적인 DBMS나 SQLite와 같이 파일만으로 완결되는 것 등 규모와 요건에 따라 선택지가 다양하지만, 여기서는 깊게 다루지 않겠습니다. 여기서 말하고 싶은 것은, 대량 레코드의 지속적인 축적·갱신·검색이라는 용도에서는 Excel보다 적합한 수단이 따로 있다는 것입니다.

3. 셀 수가 많은 이유는 DB 용도뿐만이 아니다

하지만 Excel의 셀 수가 많다고 해서 반드시 "간이 DB"로 사용되고 있다고 단정할 수는 없습니다.

셀 수가 많아지는 이유는 적어도 다음의 3가지로 나눌 수 있습니다.

A. 다수의 사례·레코드를 집적하고 있다

고객 목록, 안건 관리표, 재고 대장, 신청 목록, 진척 관리표와 같이 행이 레코드를, 열이 속성을 나타내는 사용법입니다. 이것이 전장에서 지적한 "DB 대신 사용"의 전형이며, 규모가 커질수록 약점이 표면화됩니다.

B. 개별 사례에서 다루는 데이터량이 많다

1건의 안건·검사·신청·견적·보고 각각에 다수의 항목이 포함되는 경우입니다. Web UI나 외부 시스템에서 취득한 정보를 붙여넣어 처리하는 케이스도 포함됩니다. 이 경우 셀 수는 많아도 "1건 분량의 처리에 필요한 양이 많을" 뿐이며, 레코드를 축적하고 있는 것은 아닙니다.

C. 데이터를 수식으로 처리하는 단계가 많다

입력값의 정규화, 문자열의 분해·추출, 복수 조건 판정, 중간 결과의 단계적 구축, 최종적인 대조나 장표(Report) 반영 등, 계산 과정 그 자체를 셀 위에 전개하고 있는 경우입니다. 셀 수가 많은 이유는 처리 단계의 수가 많기 때문입니다.

이 3가지 분류 중, 전장에서 언급한 DB 대용으로서의 위험성이 해당되는 것은 A뿐입니다. B와 C는 오히려 Excel이 본래 잘하는 표 형식의 데이터 처리·시각화·장표화의 영역이며, "위험하니까 Excel에서 벗어나야 한다"라고 뭉뚱그려 말하는 것은 빗나간 판단입니다. 그리고 셀 수만으로는 용도를 판단할 수 없습니다.

4. 8000셀 사례는 무엇이었나

이전 기사에서 소개했던, 8000셀 규모의 수식 연쇄로 업무 로직이 구현된 Excel 파일 이야기를 되짚어 봅니다[3].

이 사례는 다수의 사례를 축적하는 DB와 같은 용도가 아니라, 개별 사례에서 다음과 같은 처리를 수행하는 매크로 포함 Excel 북입니다.

• 업무 시스템의 Web UI에서 취득한 정보를 이 Excel 북에 붙여넣으면, 그 내용을 수식으로 해석하여 해당 조작이 올바랐는지 확인합니다.
• 업무 시스템에서의 조작에 미비점이 있으면 지적하고, 문제가 없으면 그 상태를 저장해 둡니다.
• 나중에 다른 프로그램에서 출력된 결과를 붙여넣으면, 저장된 내용과 대조하여 결과가 올바른지 확인합니다.

업무의 구체적인 내용은 여기서 밝히지 않겠지만, 이러한 처리들이 다수의 시트와 총 약 8000셀의 수식 연쇄로 구현되어 있습니다. 그리고 업무 시스템의 Web UI 사양은 지금까지 몇 차례 변경된 적이 있지만, 그때마다 Excel 북의 템플릿 파일 수식을 변경함으로써 신속하게 대응해 왔습니다.

앞서 말한 3가지 분류에 대입하면, 이 사례는 다음과 같습니다.

• A. 다수의 사례·레코드를 집적하고 있다 → 아니오
• B. 개별 사례에서 다루는 데이터의 양이 많다 → 예
• C. 데이터를 수식으로 처리하는 단계가 많다 → 예

즉, 8000셀이나 된다고 해도 Excel을 DB 대용으로 쓰고 있는 것이 아닙니다. 건당 업무 데이터량이 많고, 그 처리 단계가 많기 때문에 셀 수가 늘어났을 뿐입니다. 이 구성은 오히려 Excel다운 업무 처리 템플릿의 한 예라고 할 수 있습니다.

Hatena Bookmark의 반응 중에 셀 수의 많음으로부터 대량 데이터의 축적을 연상한 것으로 보이는 코멘트가 있었는데, 그것도 무리는 아닌 반응이었다고 생각합니다. 셀 수라는 지표만으로는 Excel 파일의 용도를 판별할 수 없기 때문입니다.

5. 업무 처리 템플릿으로서 Excel의 강점

전장까지에서 Excel의 셀 수가 많은 이유 중 B와 C, 즉 개별 사례의 데이터량의 많음과 수식 처리 단계의 많음은 A의 DB적인 축적과는 별개라고 정리했습니다. 이 B와 C의 영역은 Excel이 본래 잘하는 용도가 그대로 살아나는 장면입니다.

개별 사례별 처리

건당 데이터를 붙여넣고, 입력 내용을 확인하고, 계산·판정을 수행하며, 결과를 대조하고, 장표를 발행한다. 이 일련의 흐름을 Excel은 잘 수행합니다. 여기서의 Excel은 DB가 아니라 처리 템플릿입니다.

표 계산·중간 처리·시각화

Excel은 표 형식의 데이터를 그 자리에서 처리하고, 중간 경과를 그대로 셀 위에 전개할 수 있습니다. 프로그램이라면 중간 변수나 로그 속에 숨겨져 버릴 처리 과정을, Excel에서는 이용자가 그 자리에서 간단히 확인할 수 있다는 장점이 있습니다.

장표·제출 자료·확인용 UI

셀 병합, 테두리, 색상, 폰트, 인쇄 범위, 페이지 설정과 같은 기능을 조합하면, 업무상 필요한 확인 자료나 제출 자료를 쉽고 유연하게 작성할 수 있습니다. DB나 Web 프레임워크를 조합한 시스템으로 동일한 것을 구현하려면 상당한 개발 비용이 드는 경우가 적지 않습니다.

업무 로직을 포함하는 템플릿

수식, 입력 규칙, 조건부 서식, 이름 정의, VBA, 버튼, 시트 구성을 조합함으로써 업무 애플리케이션으로서 기능하는 Excel 파일을 만들 수 있습니다. 그 템플릿을 적절히 개발하고 배포하며, 필요에 따라 업데이트하는 체제를 갖춘다면 Excel은 개인의 소유물인 파일이 아니라 유지보수 가능한 업무 자산으로 다룰 수 있습니다.

앞 장에서 소개한 "Excel이 나쁜 것이 아니라, Excel을 DB 대신 사용하는 것이 위험하다"라는 기사는 A의 관점, 즉 Excel을 DB 대신 사용할 때의 위험성을 정확하게 논하고 있습니다. 본 기사는 그 지적을 부정하는 것이 아니라, 거기에 B와 C, 즉 개별 사례의 처리 템플릿으로서의 관점을 더하여 Excel의 실무 용도에 대한 전체상을 보완하는 것이라고 이해해 주시면 감사하겠습니다.

6. Excel에 맡길 부분과 시스템에 맡길 부분을 나누기

지금까지의 정리를 바탕으로 보면, 논점은 "Excel을 사용할 것인가 사용하지 않을 것인가"가 아니라, "Excel에 무엇을 맡기고 무엇을 맡기지 않을 것인가"임을 알 수 있습니다.

Excel에 맡기지 않는 것이 좋은 것

• 다수 레코드의 장기 보존
• 여러 명에 의한 동시 업데이트
• 엄격한 권한 관리 · 승인 플로우 (Approval Flow) · 감사 로그 (Audit Log)
• 참조 무결성 (Referential Integrity) 보장
• 대량 데이터의 검색 · 추출
• 데이터의 유일한 정본 (Single Source of Truth) 관리
• 타 시스템과의 고신뢰 연계 기반

Excel에 맡겨도 괜찮거나 적합한 것

• 개별 사례별 입력 · 처리 · 확인
• 대표적인 계산 · 일시적인 가공
• 장표 발행 · 확인용 UI · 수기 가시화
• 업무 로직을 표 형식으로 표현하는 템플릿
• DB나 업무 시스템에서 출력된 데이터의 확인 · 가공 · 장표화

최근에는 Excel을 활용하는 기사가 많이 나오고 있어, 마치 Excel 만능주의자처럼 보일지도 모르겠습니다. 하지만 과거에 간이 DB처럼 운용되는 Excel 파일이 업무 환경에 다수 존재했을 때는, 그것들을 일소하는 데 힘을 쏟았습니다. 그리고 업무 시스템의 기능 충실화 등을 통해 해당 Excel 파일들이 가진 기능을 흡수함으로써 그것들을 없앨 수 있었습니다. 현재 Excel 활용에 주력하고 있는 이유는, 간이 DB처럼 운용되는 Excel 파일이 이제 더 이상 없기 때문입니다. 다수 레코드의 축적 · 검색 · 업데이트는 업무 시스템에 맡기고, Excel은 개별 사례별 처리 · 대조 · 확인 · 장표 발행에 사용하며, 그 템플릿을 개발하여 자동 배포하는 체제를 운용하고 있습니다.

다만, B나 C의 영역에서 Excel을 계속 사용한다고 하더라도, 검증 없이 방치해도 된다는 뜻은 아닙니다. Raymond Panko의 스프레드시트 오류 연구에 따르면, 셀 단위의 오류율은 낮더라도 큰 스프레드시트에서는 적어도 하나의 잘못된 최종값이 존재할 가능성이 높으며, 게다가 그 오류는 검출 및 수정이 어렵다는 점이 지적되었습니다 [4]. 또한, Felienne Hermans 등의 연구는 스프레드시트의 수식에 대해 소프트웨어의 "코드 스멜 (Code Smell)" 개념을 응용할 수 있음을 보여줍니다 [5]. 이 연구가 밝혀낸 것은, 수식이 많은 Excel은 단순한 표가 아니라 유지보수해야 할 코드에 가까운 성질을 가지고 있다는 것입니다. 이처럼 스프레드시트는 프로그래밍 훈련을 받지 않은 사람이 업무 로직을 표현하기 위한 환경으로서 이전부터 연구 대상이 되어 왔습니다 [6].

지금까지 복잡한 수식 연쇄는 "만든 본인만이 이해할 수 있다"라고 말하곤 했습니다. 하지만 지난 기사에서 썼듯이, AI가 시트 구조 · 수식 · VBA를 조합하여 해석할 수 있게 되고 있으며, Excel 북을 안전한 개발 대상으로 다루기 위한 하네스 (Markdown화 · Git 관리 · AI를 통한 수정 제안 · diff 확인 · 테스트 · 복원이라는 루프)에 대해서도 구체적으로 정리했습니다 [7]. B나 C의 영역에서 Excel을 남겨둔다면, 방치하는 것이 아니라 이러한 개발 지원을 결합함으로써 유지보수 대상으로 다루는 것이 현실적이라고 생각합니다.

요약

Excel을 A의 대량 레코드용 간이 DB로 사용하는 것은 위험합니다. 다수 인원 업데이트, 변경 이력, 승인 플로우, 참조 무결성, 대량 데이터의 검색 · 추출, 타 시스템과의 연계 기반으로서는 Excel보다 적합한 수단이 따로 있습니다.

하지만 Excel의 셀 수가 많은 이유는 그뿐만이 아닙니다. B의 개별 사례에서 다루는 데이터량이 많을 경우나, C의 데이터를 수식으로 처리하는 단계가 많을 경우에도 셀 수는 많아집니다. B나 C의 용도는 Excel이 본래 잘하는 표 계산 · 가시화 · 장표 발행 · 업무 로직 구현의 영역이며, 일률적으로 "위험하니까 탈(脫) Excel 해야 한다"라고 결론지어 버리면 Excel의 강점을 오판하게 됩니다.

중요한 것은 Excel을 사용할지 말지가 아니라, Excel에 무엇을 맡기고 무엇을 DB·업무 시스템에 맡길 것인가입니다. 그리고 개별 사례의 처리 템플릿으로서 Excel을 사용한다면, AI·Git·테스트를 통한 개발 지원을 결합함으로써 유지보수 가능한 개발 대상으로 취급하는 것이 앞으로의 현실적인 선택지가 될 것이라고 생각합니다.

관련 기사

「탈(脫) Excel」의 한계와 활(活) Excel

• 왜 Excel/VBA는 경시되는가: 기술 계층 구조(Technical Hierarchy)와 현장·관리의 비대칭성
• 그 「기술적 부채 (Technical Debt)」의 정의는 누구를 위한 것인가?: 현장의 개선을 막는 「엇갈림」을 풀다
• Excel과 AI의 공존 전략――DAG×UI를 이해하지 못하는 현재의 AI와 「탈 Excel」의 함정
• 「취미 프로그래밍」이 최강인 이유: 도메인 전문가×AI에 의한 내재화 개발의 설계 사상

xlsm_devkit / 모던 개발의 시도

• Excel/VBA와 모던 개발 사이 ─ 2026년에 잇따라 등장한 XLIDE·xlflow·xlsm_devkit
• 시트 변경을 AI가 추종하게 만들기 ─ xlsm_devkit 신기능과 「탈 Excel」 재고

참고한 기사·자료

• Excel이 나쁜 것이 아니라, Excel을 DB 대신 사용하는 것이 위험하다

• Access 또는 Excel을 사용하여 데이터 관리 - Microsoft 공식 지원

• Raymond R. Panko, "What We Don't Know About Spreadsheet Errors Today" (2016)

• Felienne Hermans et al., "Detecting and refactoring code smells in spreadsheet formulas," Empirical Software Engineering(2015) - Bonnie A. Nardi, James R. Miller, "The Spreadsheet Interface: A Basis for End-User Programming," INTERACT '90 (1990)

Access 또는 Excel을 사용하여 데이터 관리 - Microsoft 공식 지원 ↩︎

Raymond R. Panko, "What We Don't Know About Spreadsheet Errors Today: The Facts, Why We Don't Believe Them, and What We Need to Do" (2016). arXiv:1602.02601 ↩︎

Felienne Hermans, Martin Pinzger, Arie van Deursen, "Detecting and refactoring code smells in spreadsheet formulas," Empirical Software Engineering(2015). ↩︎ -
Bonnie A. Nardi, James R. Miller, "The Spreadsheet Interface: A Basis for End-User Programming," INTERACT '90 (1990). ↩︎

「Excel/VBA와 모던 개발 사이 ─ 2026년에 잇따라 등장한 XLIDE·xlflow·xlsm_devkit」 제3장에서 자세히 기술했습니다. ↩︎

Discussion