
Excel 없이도 AI로 VBA를 개발하기 ─ LibreOffice로 약 95%의 코드를 공통화한 설계
요약
Excel이 없는 환경에서 LibreOffice를 활용해 AI로 VBA를 개발한 사례를 소개합니다. 환경 의존적 코드를 국소화하는 설계를 통해 코드의 95% 이상을 공통화하여 이식성을 높였습니다.
핵심 포인트
- 환경 의존 코드를 특정 모듈로 격리하는 설계의 중요성
- LibreOffice와 Excel 간 코드 재사용률 95% 달성
- AI 활용 시 유지보수성을 위한 모듈 분할 및 책임 분리 필요성
- 비즈니스 로직과 환경 의존 로직의 분리 전략
이 기사의 요점
-
Excel이 없는 환경에서도, LibreOffice를 사용하여 AI로 VBA를 개발할 수 있었다
-
약 3,000행 중, Excel에서 수정한 것은 130행뿐이었다
-
포인트는 「환경 의존 코드를 국소화하는 설계」
-
AI를 활용할수록, 설계의 중요성을 실감했다
-
업무에서는 Excel VBA를 개발하고 있다, 또는 개발하고 싶다
-
업무용 PC에는 소프트웨어를 추가로 설치할 수 없다
-
집에는 Microsoft Office가 없다
-
AI를 활용하여 VBA를 개발하고 싶다
-
Excel이 없는 환경에서도 AI를 활용하여 VBA를 개발하는 방법
-
Excel과 LibreOffice를 양립하기 위한 설계 방침
-
환경 의존 코드를 분리함으로써, 약 95% 이상의 코드를 공통화할 수 있었던 사례
-
AI 에이전트를 이용한 개발에서 얻은 설계상의 지견
-
LibreOffice Basic과 Excel VBA의 문법 차이
-
LibreOffice 고유의 제약이나 주의할 점
-
이식 시에 마주한 기술적인 문제
→ 이것들은 다음 기사에서 자세히 소개하겠습니다.
회사에서는 Excel VBA를 개발하고 있는데, 집에는 Excel이 없다. 이러한 환경인 분들도 많지 않을까요.
저도
- 회사 PC에서는 Excel을 이용할 수 있다
- 집에는 Excel이 없다
- 회사 PC에는 소프트웨어를 설치할 수 없다
라는 환경에서, 약 3,000행 규모의 매크로를 개발할 필요가 있었습니다.
그래서, 개발 환경으로서 LibreOffice Calc Basic을 채택하고, AI를 활용하면서 개발을 진행했습니다.
환경 의존 코드를 국소화하는 설계를 채택한 결과, 최종적으로 수정한 것은 약 130행뿐. 즉, 95% 이상의 코드를 그대로 이용할 수 있었습니다.
이 기사에서는, Excel이 없는 환경에서도 VBA를 개발할 수 있었던 설계와, 그 경험으로부터 얻은 「AI를 활용할수록 설계가 중요해진다」라는 지견을 소개합니다.
개발을 시작함에 있어, 처음에 생각한 것은 「Excel과 LibreOffice의 차이는 어디에 있는가」 하는 것이었습니다.
제 예상으로는, 가장 큰 차이는 셀의 입출력이었습니다.
한편으로, 비즈니스 로직 (Business Logic)은 어느 환경에서도 공통으로 동작할 것이라고 생각했습니다.
그래서, 유지보수성이나 AI에 의한 구현 효율을 고려하여, 책임(Responsibility)에 따라 모듈을 분할했습니다. 그중에서도, 셀에 대한 읽기/쓰기 등 환경에 의존하는 처리는 하나의 모듈로 집약하는 설계를 채택했습니다.
이 설계라면, 환경이 바뀌어도 수정의 대부분은 셀 입출력 모듈에 집약할 수 있다고 생각했습니다.
또한, 비즈니스 로직은 Excel이나 LibreOffice를 의식할 필요가 없어지기 때문에, 환경의 차이를 신경 쓰지 않고 구현할 수 있게 됩니다.
나아가, 책임에 따라 모듈을 분할함으로써, 기능 추가나 유지보수도 하기 쉬운 구성이 되었습니다.
AI에게 구현을 의뢰할 때도, 환경 의존 코드를 쓰지 않게 한다는 규칙을 만들기 쉬워집니다.
물론, 이 시점에서는 Excel과 LibreOffice의 차이를 모두 파악하고 있었던 것은 아닙니다.
실제로는, 배열 구조나 COM 객체 등, 셀 액세스 이외에도 환경 의존적이 되는 부분이 존재했습니다.
개발 완료 후, LibreOffice용 코드를 Excel VBA로 이식했습니다.
그때 수정이 필요했던 것은, 약 3,000행의 코드 중 130행이었습니다.
즉, 95% 이상의 코드를 그대로 이용할 수 있었습니다. Excel로의 이식 시에는, 셀 액세스 모듈 파일 1개를 교체하는 것만으로 대응할 수 있었습니다.
처음에 세운 「환경 의존적인 것은 주로 셀 액세스 주변일 것이다」라는 가설은, 대체로 옳았다고 할 수 있습니다.
물론, 설계 시에는 상정하지 못했던 차이도 있었습니다.
개발을 진행하는 과정에서, 셀 액세스 이외에도 환경 의존적이 되는 부분이 발견되었습니다. 특히, Scripting.Dictionary를 비롯한 COM 객체는, LibreOffice에서는 Excel과 똑같이 다룰 수 없었습니다. 그 때문에, LibreOffice 측의 제약을 기준으로 설계를 재검토했습니다.
그 결과, Excel로의 이식 시에 큰 설계 변경은 불필요했고, 수정은 셀 액세스 모듈 파일 1개의 교체만으로 끝났습니다.
구체적으로 어떤 차이가 있고, 어떻게 대응했는지에 대해서는, 다음 기사에서 자세히 소개하겠습니다.
이번 개발에서는, 사양 정리, 설계 상담, 구현, 테스트 코드 작성, 문서 작성 등, 많은 공정에서 AI를 활용했습니다.
특히, Utility 함수의 작성이나 변수명 제안과 같은 정형적인 작업에서는 매우 유용하여, 개발 속도의 향상을 실감했습니다.
반면에, 리팩터링 (Refactoring)이나 설계 정리, 생성된 코드의 리뷰는 직접 수행하고 있습니다.
AI는 구현을 가속화해 주었습니다. 하지만 설계나 리뷰까지 맡기는 것보다, 사람이 확인하는 것이 결과적으로 더 효율적이고 경제적이었습니다.
이번 개발에서 AI는 매우 유용했지만, 다음과 같은 점에는 주의가 필요하다고 느꼈습니다.
최근의 요구사항을 우선시하기 쉬움 - 설계 규칙이나 기존 사양보다, 직전의 지시에 따른 구현을 제안하는 경우가 있었습니다.
-
실제로 중요한 판정 로직이 삭제된 적도 있었으나, Git으로 관리하고 있었기에 복구할 수 있었습니다.
계산량을 고려하지 않은 구현을 제안할 때가 있음 - 동작하는 코드는 생성할 수 있지만, 알고리즘의 효율성까지 최적화되어 있다고는 할 수 없었습니다.
유지보수성이 낮은 코드를 제안할 때가 있음 - 책임 분할이 불충분한 코드나, 리팩터링 (Refactoring)을 하는 편이 더 읽기 쉬운 코드도 보였습니다.
AI에게 리뷰도 의뢰할 수 있지만, 그만큼 토큰 (Token)을 소비합니다.
따라서 설계나 품질을 확인하는 역할은 사람이 담당하고, AI는 구현 지원 도구로서 활용하는 것이 효율적이라고 느꼈습니다.
이번 개발에서는 처음에 책임별 모듈 분할이나, 환경 의존적 코드를 국소화하는 방침을 정해 두었습니다.
이러한 설계 방침이 있었기에 AI에게 구현을 의뢰할 때도 대상이 되는 모듈을 한정할 수 있었고, 불필요한 코드까지 참조하게 할 필요가 없었습니다.
결과적으로 토큰 사용량을 억제하면서 설계의 일관성도 유지하기 쉬워졌습니다.
이번 개발을 통해 가장 강하게 느낀 점은, AI의 성능 이상으로 설계가 중요하다는 것입니다.
AI는 구현을 크게 효율화해 주는 한편, 어떤 구조로 개발할지, 생성된 코드가 사양을 충족하는지를 판단하는 것은 사람의 역할입니다.
개발 환경에 제약이 있는 경우라도 설계를 먼저 확정하고, 사람과 AI의 역할을 의식하며 개발을 진행함으로써 효율적으로 개발할 수 있다고 느꼈습니다.
이번 개발에서는 집에 Excel이 없다는 제약 속에서, LibreOffice와 AI를 이용하여 Excel VBA 매크로를 개발했습니다.
개발 전에는 "Excel과 LibreOffice가 어느 정도 호환되는가"를 알 수 없는 상태였지만, 환경 의존적 코드를 국소화함으로써 작은 수정만으로 Excel로 이식할 수 있었습니다.
개발 중에는 예상치 못한 차이점도 발견되었지만, 제약이 더 큰 LibreOffice 측에 설계를 맞춤으로써 설계 전체를 크게 변경하지 않고도 대응할 수 있었습니다.
이번 경험을 통해 Excel이 없는 환경에서도 설계를 고안한다면, LibreOffice는 Excel VBA 개발 환경으로서 충분히 활용할 수 있다는 것을 실감했습니다.
이러한 사고방식은 LibreOffice에 국한되지 않고, 서로 다른 실행 환경으로 이식하는 소프트웨어를 개발할 때도 응용할 수 있다고 생각합니다.
또한, AI를 활용한 개발에서는 구현 그 자체보다 설계의 중요성을 다시 한번 실감했습니다.
이번에는 Excel이 없는 환경에서도 AI를 활용하여 VBA를 개발하기 위한 설계에 대해 소개했습니다.
다음에는 LibreOffice와 Excel VBA의 구체적인 차이점과, 그것들을 어떻게 흡수했는지에 대해 실례와 함께 소개하겠습니다.
- Class를 사용할 수 없음
- Dictionary와 Object의 취급
- 배열 구조의 차이
- COM 객체 (COM Object)
- Err 객체
- 디버깅 방법
등, 실제로 마주한 문제와 그 해결 방법을 정리할 예정입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기