GnuCash 5.9 출시

 (gnucash.org)
2P by GN⁺ | ★ favorite | 댓글 1개
  • GnuCash 5.9는 안정 5.x 시리즈의 열 번째 릴리스로, 5.8 이후 발견된 버그 수정과 CSV 날짜 파싱·온라인 시세 개선을 함께 담음
  • 이번 버전은 조정 창, MySQL 백엔드 오류 메시지, 거래 복사/붙여넣기, 계정 삭제 크래시, Windows 키패드 소수점 로케일 오류 등 12개 버그를 고침
  • 온라인 시세에는 YH Finance(FINANCEAPI) API 키 설정과 financeapi 소스가 추가됐고, CSV 가져오기는 로케일 기반 날짜와 영문 월 표기를 더 잘 처리함
  • Windows 10 이상, macOS 10.13 High Sierra 이상용 패키지와 Flathub flatpak이 제공되며, 직접 빌드하려면 Gtk+·Guile·Boost 등 지정된 최소 의존성이 필요함
  • 독일 AQBanking 사용자는 번들에 포함된 AQBanking 6.5.4를 쓰게 되며, 새 PIN/TAN 구현 베타는 GnuCash nightly builds에서만 제공됨

GnuCash 5.9 릴리스 성격

  • GnuCash 5.9는 안정 5.x 시리즈의 열 번째 릴리스임
  • GnuCash는 GNU General Public License(GPL)로 배포되는 무료 오픈소스 회계 프로그램이며, GNU/Linux, *BSD, Solaris, macOS, Microsoft Windows를 지원함
  • 개발은 1997년에 시작됐고 첫 안정 릴리스는 1998년에 나옴

5.8 이후 수정된 주요 문제

  • 조정(reconcile) 중 새 거래를 추가해도 조정 창에 나타나지 않던 문제가 해결됨
  • MySQL 백엔드는 잘못된 자격 증명에 대해 "bad or corrupt data" 대신 "access denied" 오류를 보고함
  • 거래 복사/붙여넣기와 잘라내기/붙여넣기 동작이 수정됨
    • 거래 잘라내기/붙여넣기가 대상 계정으로 거래를 이동하지 않던 문제가 포함됨
  • sqlite 백엔드에서 새 파일 생성 시 예제 Python 스크립트가 오류를 출력하던 문제가 고쳐짐
  • Transaction Journal 보기에서 거래 변경 커밋 후 커서 위치가 어긋나던 문제가 수정됨
  • 조정 날짜 파싱 실패, 계정 삭제 크래시, 상대 날짜 오프셋의 분기 계산 오류가 해결됨
  • Windows에서 키패드 소수점 입력이 로케일과 맞지 않던 문제가 고쳐짐
  • 송장 게시 화면의 계정 드롭다운 목록 상자가 너무 작던 문제와 간헐적인 시세 가격 문제가 수정됨

온라인 시세와 CSV 가져오기 개선

  • 온라인 시세 인프라에 YH Finance(FINANCEAPI) API 키 설정이 추가됨
    • Online Quotes 페이지에서 관련 설정을 다룰 수 있음
    • financeapi가 알려진 시세 소스에 추가됨
  • CSV 날짜 파서는 ICU와 Boost를 활용하도록 개선됨
    • ICU 기반 Locale 날짜 형식으로 현재 로케일의 날짜를 파싱함
    • "3 May 2023" 또는 LC_TIME=zh_TW.utf8에서 "2024年9月13日" 같은 입력을 처리할 수 있음
    • d-m-y, m-d-y, y-m-d 형식은 Boost의 UK/US/ISO 파서로 보강됨
    • "30 Sep 2023", "May 4, 1978", "2023-Dec-25" 같은 영문 월 표기 날짜도 CSV 가져오기에서 처리 가능함
    • Boost 파서는 두 자리 연도를 인식하지 못하므로 "30 Sep 24"는 유효하지 않음
  • CSV Import Assistant의 소개 페이지가 개선됨

내부 정리와 개발자-facing 변경

  • 복사된 항목 처리 구조가 정리됨
    • copied_class와 copied_leader_guid가 정적 변수에서 copied_item 구조의 일부로 이동함
    • clear_copied_item 호출이 copied_item 사용 전에 필요하다는 점이 더 분명해짐
  • 파일 기록에서 파일을 열 때 커밋되지 않은 편집을 올바르게 처리함
  • gnc_difftime은 time64를 double로 캐스팅하기 때문에 사용하지 않도록 deprecated 처리됨
  • 사용하지 않는 gnc_pricedb_substitute_commodity, gnc_pricedb_lookup_at_time64가 제거됨

번역과 문서 변경

  • 새로 추가되거나 업데이트된 번역은 Assamese, Chinese(Simplified), Chinese(Traditional), Croatian, Dutch, English(United Kingdom), Hebrew, Hungarian, Macedonian, Norwegian Bokmål, Portuguese(Brazil), Russian, Spanish, Swedish, Turkish임
  • 문서 쪽 변경은 GitHub CI actions 버전 업데이트임
  • 문서 번역은 German이 새로 추가되거나 업데이트됨
  • 번역 참여는 Weblate의 GnuCash 프로젝트에서 안내됨

AQBanking 관련 안내

  • 독일 AQBanking 사용자를 위한 별도 안내가 포함됨
  • AQBanking 작성자는 업데이트된 PIN/TAN 코드 마무리 작업을 계속 진행 중임
  • 이 릴리스의 Flatpak, macOS, Windows 번들에는 마지막 안정 버전인 AQBanking 6.5.4가 포함됨
  • 안정 AQBanking이 동작하지 않는 경우, 새 구현 베타가 포함된 GnuCash nightly builds를 고려할 수 있음
  • 열려 있는 버그 전체 목록은 GnuCash 버그 목록에서 확인 가능함

배포 패키지와 빌드 조건

  • GnuCash 5.9는 Microsoft Windows 10 이상과 macOS 10.13 High Sierra 이상용 사전 빌드 올인원 패키지로 제공됨
    • Windows는 설치 프로그램 형태임
    • macOS 패키지는 드래그 앤드 드롭 애플리케이션 번들이 들어 있는 디스크 이미지임
  • Flathub.org에서 flatpak으로도 제공됨
  • 다운로드 파일에는 tarball, Windows 설치 파일, Apple Silicon용 dmg, Intel Mac용 dmg, 문서 tarball이 포함됨
  • 소스 코드는 SourceForge와 GitHub에서 bzip2 또는 gzip 형식으로 받을 수 있으며, Git 저장소에서 직접 체크아웃할 수도 있음
  • 직접 컴파일하려면 다음 최소 의존성이 필요함
  • 정확한 의존성 목록과 버전은 소스의 README.dependencies 파일을 참조해야 함

GnuCash 5.9 문서

  • GnuCash 5.9 문서는 GnuCash 웹사이트의 Documentation page에서 확인할 수 있음
  • GnuCash v5 (current stable release) 아래에서 여러 언어로 온라인 읽기와 다운로드를 제공함
  • 다운로드 형식은 pdf, epub, mobi를 포함함
  • 문서는 macOS와 Windows 애플리케이션 번들에도 포함됨
  • GnuCash Documentation 5.9 소스는 SourceForge 또는 GitHub에서 받을 수 있고, Git 저장소에서 직접 체크아웃할 수도 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • GnuCash를 사업 회계에 쓰고 있고 필요한 기능은 충분히 해줌
    VC들이 블로그에서 권하는 QuickBooks는 쓰지 않는데, 편한 기능은 있지만 그 가격을 낼 만큼은 아니고 VC 자금이나 CPA도 필요 없음
    GnuCash를 SQLite와 함께 써본 적은 없지만 시간이 나면 실험해보고 싶고, 신뢰성이 어떤지 궁금함
    예전에 Oracle EBS의 기술/기능 엔지니어로 일해서 보조원장까지 서로 얽힌 복잡한 스키마를 다뤘고, GnuCash에 수익 인식 기능을 추가하는 생각도 늘 해왔음
    SQLite 스키마를 보면 한번 시도해볼 수 있을지도 모름

    • QuickBooks에서 이전하는 사람이 다른 사람을 돕고 싶다면, qb-escape QuickBooks→GnuCash 변환기가 도움을 필요로 함: https://github.com/erikmack/qb-escape/
    • GnuCash에서 SQLite는 안정적임
      몇 년 전에 XML에서 SQLite로 옮겼고 문제 없었음
    • 개인용이나 아주 작은 사업에는 훌륭하지만, 진짜 스타트업을 GnuCash로 운영하려 한다면 큰일 날 수 있음
      직접 겪어본 바로는 GnuCash 신봉은 해롭고, 비즈니스 세계는 GnuCash를 싫어하며 QuickBooks만 신경 씀
      2000년대 초부터 비영리와 스타트업에서 이 싸움을 해왔고, 예전에는 나도 “우리는 반드시 GnuCash를 써야 한다”는 사람이었음
      이상적인 세계라면 GnuCash든 QuickBooks가 아닌 어떤 도구든 소기업 회계의 선택지가 되겠지만, 현실에서는 Intuit가 API와 파일 형식으로 QuickBooks 외의 선택을 어렵게 만들었음
      QuickBooks를 쓰지 않으면 은행, 투자자, 급여 시스템, 세무 시스템, 회계사가 모두 힘들어지고, 어떤 경우에는 보조금이나 감사도 막힐 수 있음
      선의의 오픈소스 신봉자들이 GnuCash 사용을 요구하는 상황을 자주 보는데, 그런 사람이 되지 말아야 함
      세상은 QuickBooks를 선택했고, 그 선택은 압박과 부패한 권력 브로커링 속에서 이뤄졌지만 이미 결정됐음
      괜찮은 SaaS 선택지가 있을 수는 있지만 Intuit가 허용하는 동안만 존재하고, QuickBooks와 경쟁하는 것은 Intuit에 인수되어 사라질 가능성이 큼
      여러 비영리와 사업체에서 GnuCash를 골랐다가 자금 마감, 은행 요건, 대출 요청, 보조금 신청 때문에 급히 플랫폼을 바꿔야 했고, 결국 회계 담당자가 60시간 넘는 주로 모든 것을 다시 하게 됐음
      GnuCash는 멋진 프로젝트이고 모두가 쓸 수 있으면 좋겠지만, 실제 사업에는 임의적이고 인위적인 이유들 때문에 쓸 수 없음
      회계 담당자가 와서 NetBeans를 쓰라고 강요하면 용납하지 않을 테니, 도구 선택에서는 그들에게도 같은 예의를 보여야 함
    • 자유 소프트웨어가 공짜 맥주처럼 무료라는 성질 덕분에 성공한 또 하나의 사례로 보임

  • 개인 회계 소프트웨어를 많이 써봤지만, 오래된 PalmOS용 Pocket Money를 빼면 모두 지출 입력이 너무 불편했음
    가게 방문 전체를 “Lidl에서 식료품” 같은 한 거래로 기록하면 참을 만하지만, 영수증 각 줄을 분할 거래의 별도 항목으로 넣으려 하면 과거 기록 기반의 좋은 제안 없이 매번 다시 입력해야 함
    예를 들어 거래 상대가 Lidl이면 “br”만 쳐도 food:bread와 가격을 제안하고, 거래 상대가 Victoria Secret이면 clothing:bra와 다른 가격을 제안하는 식으로 정교할 수 있는데, 써본 것 중 지원하는 게 없었음
    정말 오래된 PalmOS 3.0 Pocket Money는 매우 편했고, 데스크톱이든 모바일이든 나머지는 이 부분에서 훨씬 나쁨
    거래를 매우 자세히 기록한다면 중첩 “계정”보다 중첩 분류가 더 낫다고 봄
    거의 외형상의 차이지만 “현금”과 “food:meat:pork”가 같은 종류의 객체라는 게 이상함
    돈을 “food:meat:pork”로 이체하는 게 아니라 그것에 지출하는 것이고, 상품이 아니라 가게로 돈을 보내는 것임
    전문 회계 시스템도 모니터, 노트북, 컴퓨터, 마우스마다 회사 자산 계정을 따로 두지는 않는 것으로 알고 있음
    혹시 아직 못 찾은 건지, 추천할 만한 게 있는지 궁금함

    • 영수증의 각 항목까지 추적하는 게 실제로 그렇게 유용한지 의문임
      일부 구매 유형에는 쓸모 있을 수 있지만, 들어가는 노력에 비해 그만한 가치를 만들지 못하는 불필요한 세부 작업일 가능성이 큼
    • 과거에 여러 도구를 써봤고, 2009년쯤 독점 OS X 소프트웨어, 특히 iBank에 짜증이 난 데다 GNUCash와 KDEMoney도 마음에 들지 않아 결국 직접 간단한 오픈소스 앱을 만들었음
      네이티브 Cocoa 앱이고 최근에는 Linux용 Qt 포트도 있으며, 그 뒤로 매일 쓰고 있음
      예전에는 분류를 아주 자세히 나눴지만 지금은 별 의미를 못 느끼고, 앱은 분할 거래를 지원하지만 보통 “식료품”, “음료”, “필수품” 정도의 분류만 씀
      다만 “커피” 같은 것은 “Drinks:Coffee”로 두어 특정 항목에 얼마나 쓰는지 볼 수 있게 함
      결국 그 정도로 정확히 기록하는 노력과 실제 활용 가치 사이의 균형 문제로 보이고, “Car:Fuel”, “Car:Service” 같은 식도 마찬가지임
    • 재정을 추적하기 시작했을 때 스프레드시트만으로는 금방 한계가 왔고, 기존 선택지도 필요에 맞지 않았음
      대부분의 사람에게 이 정도의 상세 추적은 과할 수 있지만, 나에게는 시간이 많이 들지 않음
      결국 직접 앱을 만들었음: https://github.com/VMelnalksnis/Gnomeshade
      계정에 대해서도 비슷하게 느껴서 거래를 이체와 구매 두 부분으로 나눴고, 덕분에 여러 통화를 처리하면서 분류를 계정과 분리해 다룰 수 있음
      언급한 자동 제안은 들여다보지 않았고, 자주 사는 물건의 영수증을 파싱하는 쪽으로 갔음
    • 아마 너무 세분화하고 있는 듯함
      나는 “식료품”, “소모품”, “의류” 정도로만 나눔
      필요한 게 정확히 무엇인지는 완전히 이해하지 못했지만, 나는 10년도 더 전에 GnuCash에서 KMyMoney로 옮겼음
      Walmart에서 예전에 항목별로 입력했다면 다음에 Walmart에 가서 신용카드 명세를 가져올 때 총액이 비슷한 지난 Walmart 거래를 시작점으로 잡아줘서 약간 도움이 됨
      그리고 KMyMoney는 계정 대신 분류를 쓰지만, 계정 방식이 회계 원칙에는 더 맞음
    • 영수증에 이런 용도의 QR 코드 형식이 있으면 좋겠음
      대략 가게 이름/위치, 총액, 세금 분리 필드, 단순 구매라면 “연료”나 McDonald’s 영수증의 “음식” 같은 일반 분류, 그리고 Costco처럼 식료품과 의류를 함께 살 수 있는 곳을 위한 항목 묶음이 들어갈 수 있음
      주요 분류는 여러 나라가 소비자물가지수 분류에 쓰는 것을 참고할 수 있음
      https://www150.statcan.gc.ca/n1/pub/71-607-x/2018016/cpi-ipc...
      https://www.bls.gov/news.release/cpi.t01.htm
      https://www.stat.go.jp/english/data/cpi/158c.html
      https://www.ecb.europa.eu/stats/macroeconomic_and_sectoral/h...

  • GNUCash 모델은 별로 좋아하지 않음
    쓰기가 좀 번거롭고 원하는 통계를 뽑아내기도 꽤 어려워서, 예전에는 여러 다른 패키지를 써보고 정착했었음
    그래도 내가 수십 년 전 첫 직장을 얻었을 때 GNUCash는 존재했고, 지금도 존재함
    이 정도의 지속성을 보여준 다른 패키지는 거의 없는 듯함

    • 90년대 중반 유틸리티 디자인을 갖고 있다는 점이 매력적임
      동시에 바로 그 90년대식 인터페이스 때문에 엄청 답답함
      GNUCash처럼 인터페이스 디자인이 거의 발전하지 않은 유틸리티를 본 적이 없음
      프로토타입을 만들고 “완벽해!”라고 한 뒤 사용자 입력은 무시하고 백엔드 작업으로 넘어간 느낌임
    • 이 지속성은 엄청난 가치가 있음
      90년대 말부터 gnucash를 써왔고, 2000년까지 거슬러 올라가는 모든 데이터 파일을 갖고 있음

  • 몇 년 전에 써봤지만 결국 HLedger에 정착했음
    GnuCash처럼 내 데이터를 소유하고 통제할 수 있으면서도, HLedger에서는 Sublime Text에서 직접 편집해 대량으로 무언가를 고치거나 바꿀 수 있음
    물론 내 사용 사례는 꽤 기본적이고 업무 핵심 시스템은 아니어서 사람마다 다를 수 있음

    • GnuCash를 쓰지 않을 타당한 이유임
      XML 형식이 훌륭하지 않다는 데는 동의하지만, 나는 SQLite 형식을 써서 그 위에 스크립트를 작성할 수 있음
    • Firefly III를 쓰고 있음: https://firefly-iii.org
      자체 호스팅 웹 앱이라 대부분 휴대폰에서 쓰는 내게는 좋음
      꽤 폭넓은 API가 있고, 텍스트 파일만큼 대량 편집이 쉽지는 않더라도 비교적 단순할 것임
      규칙 시스템도 있어서 대량 편집에 활용할 수 있음
    • GnuCash를 쓰고 있는데, 대량 변경이나 쉬운 스크립팅이 안 되는 점이 꽤 성가심
      예를 들어 CSV 가져오기에서 작은 실수를 했을 때 특히 그렇음
    • hledger와 ledger를, 특히 lots 기능을 여러 해 써왔음
      hledger의 좋은 점 중 하나는 매우 유연한 CSV 규칙 시스템임
      여기에 간단한 Python 스크립트를 붙여 자본이득 기록에 필요한 추가 정보를 넣었음
      결국 원시 입력 데이터는 기록이 담긴 CSV 파일들이고, 출력은 여러 상세 수준의 재무 보고서가 됨
    • gnucash XML을 ledger로 변환하는 작은 스크립트를 실제로 돌리고, 변환 결과와 원본 XML을 git으로 추적하고 있음
      gnucash UI에 입력하면서 꽤 자주 실행하면 변경 사항을 읽기 쉬운 git 로그와 diff로 볼 수 있음
      다만 “대량 변경” 능력은 빠져 있음
      gnucash가 그냥 XML이라 직접 편집할 수도 있겠지만 아직 감히 해보지는 않았음
      [0] 기반: https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...

  • 해커스페이스 회계에 GnuCash를 쓰고 있음
    이걸 쓰거나 근처 메이커스페이스 회계 담당자가 추천한 “wave”라는 사이트를 쓰는 선택지였음
    wave에 가입해서 조금 만져봤지만 확신이 없었고, 몇 주 뒤 wave를 쓰기로 마음먹었더니 아무 이유 없이 계정이 잠겨 있었음
    그래서 GnuCash로 갔음
    좋은 소프트웨어이고, 결국 libgnucash 라이브러리에 동적으로 링크하는 코드를 작성해서 회원 회비의 월별 청구서를 자동 생성하게 했음

    • GnuCash를 자동화하는 더 나은 방법, 예를 들어 Bash나 Python 스크립트 같은 건 없는지 궁금함
    • 흥미로운데, 코드를 공유할 수 있는지 궁금함

  • 개인 재무 소프트웨어로 Beancount 또는 일반적인 평문 회계를 선택하기 전에 GnuCash를 자세히 살펴봤음
    결정적으로 걸린 부분은 GnuCash의 내부 XML 또는 SQLite 형식이었음
    원시 데이터 수집이나 보고서 생성 스크립팅에 그다지 잘 맞지 않는데, Beancount나 HLedger 같은 평문 도구는 바로 그 점을 목표로 함
    평문 도구와 비교하면 GnuCash는 너무 닫힌 정원처럼 느껴짐
    평문 형식은 처음에 더 많은 작업이 필요하지만, 익숙해지고 스크립팅 배경이 있다면 훌륭함

    • 각자 취향이겠지만 내 경험은 정반대임
      평문은 사람 눈에는 단순해 보이지만 구조적으로 파싱하기는 악몽이고, 평문 편집을 스크립팅하는 것도 지저분함
      반면 데이터베이스는 이런 용도로 만들어졌음
      평문 회계에 대한 불만과 개선 시도에 많은 시간을 쓴 뒤 지금은 SQLite를 쓰고 있고, 엄청난 개선이었음
    • XML/DB 스키마가 문서화되어 있다면, 실제로는 Beancount/Ledger의 평문 형식보다 더 낫고 견고함
      나는 KMyMoney의 XML 백엔드를 쓰고, 데이터를 Ledger 형식으로 변환하는 스크립트도 갖고 있음
      자유 형식 텍스트가 아니기 때문에 오히려 그 스크립트를 쓰기 쉬웠음
    • Beancount + Fava 조합이 꽤 좋아 보이는데, 써본 경험을 들려줄 수 있는지 궁금함
    • SQLite로 충분하지 않다면 GnuCash는 SQL 백엔드도 지원함
      나는 거의 10년째 그렇게 운영 중임

  • GnuCash는 마음속에 특별한 자리가 있음
    대학 졸업 후 첫 몇 년 동안 빠듯한 수입으로 매우 빡빡한 예산을 굴렸고, 장을 볼 때마다 영수증을 집에 가져와 장부에 성실히 입력했음
    항상 모든 것이 맞아떨어졌지만 일이 엄청 많았음

  • 스웨덴의 프리랜스 컨설턴트로서 지난 10년 넘게 GnuCash를 여러 번 살펴봤지만 늘 같은 문제가 있었음
    우리 경제와 국세청 체계에 맞춰져 있지 않음
    스웨덴에서는 매출이 연 300만 SEK 미만이면 “förenklat årsbokslut”, 대략 “간소화 장부 마감”을 쓸 수 있음
    실제로는 지출과 수입을 관리하는 아주 기본적인 프로그램을 직접 만들고, 필요한 숫자를 생성해 매년 국세청 온라인 앱에 수동으로 입력하면 됨

    • 나도 간소화 장부를 쓰는 1인 프리랜서임
      복식부기는 초기 학습 곡선을 넘고 나면 단식부기보다 더 많은 노력이 들지 않았음
      흔한 오류를 자동으로 피하게 해주기 때문임
      GnuCash를 20년 동안 잘 쓰고 있고, 취약한 스프레드시트나 어설픈 Access DB로 돌아갈 생각은 없음

  • 한동안 GnuCash를 썼지만, 온라인 동기화 설정을 맞추는 데 시간을 너무 많이 쓰게 됐음
    수동으로 내려받아 가져와야 하는 계정은 마찰 때문에 가져오기를 미루게 됐음
    지금은 Quicken Classic에 돈을 내고 쓰는데, 매년 쓰는 돈 중 가장 만족도가 높음
    온라인 계정 연결이 꾸준히 기대대로 작동하고, 전반적으로 훨씬 덜 골치 아프게 일을 끝내줌

    • 미국, 캐나다, EU 두 나라, 멕시코의 계정을 신경 써야 함
      Quicken Classic처럼 은행 연결이 안정적으로 작동하는 유료 선택지가 있으면 좋겠지만, 미국과 주요 EU 경제권 하나라도 동시에 커버하는 단일 제품도 없는 것 같고, 내가 필요한 모든 지역은 더더욱 어려움
      Quicken Classic은 미국과 캐나다 전용임
      이런 선택지, 또는 합리적으로 함께 써서 이 목적을 달성할 수 있는 여러 선택지를 알고 있는지 궁금함
      거래 데이터 접근 회사들이 미국-EU 간 다리를 개인이 직접 쓰기 좋은 방식으로 건너지 않는 것을 보면, 양쪽 관료 체계의 비호환 같은 이유가 있는 듯함
      아니면 충분히 많은 사람이 이렇게 국제적인 생활을 하지 않아서일 수도 있음

  • GnuCash로 사업을 운영했고, 급여와 401k 계정 관리 등도 했음
    안정적이었고, 지출이 제한적인 사업이나 장부 담당 배경이 있다면 비용 추적도 충분했음
    회계사에게 줄 대차대조표와 손익계산서를 생성할 수 있었던 점은 정말 좋았음

답변달기