Google Sheets만 사용하는 이유

• 변화가 잦은 초기 비즈니스 환경에서는 가장 쉬운 해결책으로 문제를 빨리 풀고, 한계가 보일 때 요구사항 재평가 후 대체·보강하는게 현명함
• Google Sheets는 빠르게 변하는 환경에서 효과적인 문제 해결 수단으로, 복잡한 도구 개발보다, 실제 사용성과 낭비 감소에 유리함
• 글쓴이는 실무에서 범용 도구보다 전용 시스템을 서둘러 만들며 스코프 불확실성을 간과해 시간을 낭비했다고 회고
• 핵심 방법은 가장 작고 쉬운 해법으로 시작 → 실제 업무로 스코프 파악 → 필요 시 점진적 개선이라는 작게 시작·반복 전략
• 단, 모든 문제를 스프레드시트로 해결할 수는 없으며, 스코프가 드러나기 전까지 한시적으로 쓰는 것이 적절하고 조직 맥락에 맞춘 현명한 선별이 중요함

---

문제 해결을 위한 가장 쉬운 선택

• 어떤 문제든 가장 쉽게 적용할 수 있는 솔루션을 먼저 선택하는 것이 중요함
• 해당 방법이 더 이상 비즈니스에 맞지 않게 되면, 새로운 요구사항에 맞춰 기존 솔루션을 개선하거나 대안을 찾는 방식이 필요
• 필자가 경험한 환경에서는 대부분의 경우 새로운 Google Sheet를 만드는 것이 최적의 방법임

빠르게 변화하는 스타트업 환경과 도구의 유용성

• 약 9개월 전 직장에 입사해, 작고 시작 단계인 회사를 위한 새로운 툴과 서비스를 만드는 데 대한 기대감이 사라졌음
• 2달마다 비즈니스 방향이 바뀌는 환경에서 많은 프로젝트를 시작했다가 그만두게 됨
• 상당수의 경우, Google Sheet로 손쉽게 해결할 수 있었음에도 불구하고 불필요하게 복잡한 프로젝트에 시간과 노력을 투자함

시간 낭비 사례들

• 화물 관리 어드민 패널

  • 비즈니스를 위한 입고 화물 관리 및 추적용 어드민 패널 설계 및 제작에 2개월 소요
  • 패키지와 고객 데이터를 분류하고 더 잘 관리하도록 돕는 목적
  • 이 어드민 패널은 두 번 사용되고 다시는 사용되지 않음
  • Google Sheet로 쉽게 대체할 수 있었으며 현재 이 작업에 사용 중

• 관세 자동 계산 MVP

  • 특정 상품 주문 시 관세와 세금을 자동 계산하는 견적 시스템 MVP 제작에 3주 소요
  • 짐바브웨의 세금과 관세는 매우 복잡하여, 고객이 정확한 지불 금액을 알면 더 나은 고객 여정 제공 가능하고 제3자 관세 처리 회사의 모든 고객 문의 응답을 기다릴 필요 없어 프로세스 가속화
  • 결국 경쟁사의 세금 및 관세 분류표를 보고 Google Sheet에 복사하여 사용

• CRM 선택 과정

  • 비즈니스에 사용할 좋은 CRM을 찾기 위해 조사, 회의(1시간 이상), 검색에 2개월 소요
  • 다양한 CRM의 기능과 가격을 비교 및 대조하며 앉아서 분석
  • 결국 Oddo의 무료 버전을 사용하기로 했으나 비즈니스 내에서 많이 활용되지 않음
  • 놀랍게도 몇 주 전 Google Sheets에 CRM 템플릿이 내장되어 있음을 발견

Google Sheets 접근법의 원칙

• Google Sheet 만들기가 모든 문제의 최선의 솔루션은 아니지만, 필자의 상황에서는 종종 그러함
• 실제 작업을 시작하기 전까지 문제의 전체 범위를 결코 알 수 없는 상황에 자주 처함
• 프로젝트를 계획하지 말아야 한다는 의미는 아님
• 팀은 워크플로우와 필요한 정보를 논의해야 하지만, 실제 작업을 시작하기 전까지는 문제의 전체 범위를 알 수 없음
• 문제의 전체 범위가 파악되면 보유한 솔루션을 만들거나 개선 시작 가능
• 이 방식은 최선의 경우 필요하지 않은 모든 기능을 추가하는 추가 작업 부담을 피하고, 최악의 경우 실패할 프로젝트에 시간을 소비하지 않도록 도움
• 문제의 전체 범위를 파악하는 방법으로 가장 작고 쉬운 기본적인 솔루션을 수행하고, 필요한 경우 그 후 반복하는 것이 지금까지 최선이었음

제한점과 조심해야 할 점

• 이러한 방식에는 단점도 있으며, 예를 들어 몇몇 조직에서는 수천 행의 스프레드시트로 모든 트랜잭션과 정보를 기록함
• Google Sheets는 문제 전체 범위 파악 전에만 유용함
• 어떤 문제가 Google Sheet로 해결 가능한지에 대한 경험과 판단력이 필요
• 시간을 낭비하지 않고 실제로 사용할 수 있는 도구 개발을 중시해야 함
• 하지만, 모두에게 적용되는 조언은 아니므로 각자 상황에 따라 신중히 판단하는 것이 필요

결론

• 가장 작은 노력, 가장 단순한 솔루션부터 시작하고, 필요할 때만 확장하거나 고도화하는 방식이 스타트업이나 변화 많은 환경에 매우 적합한 전략임
• 개인적인 개발 실험은 자유롭게 하되, 비즈니스에서는 꼭 필요한 것만 만들고 불필요한 일에 시간과 에너지를 들이지 않는 태도가 중요함

[shalome7]

저도 기본적으로 동의하는데, google sheets 보다 지금은 Notion Database 를 초기베이스라인 용도로 사용하는 것을 선호해요. 비슷하긴 한데 어차피 템플릿 셋팅은 1명. 다른 사람은 그 기반위에 데이터를 관리하면다면 난잡한 상황을 방지할 수 있고. app script 보다는 못하지만 좀 더 쉽게 자동화 구현도 되고. 초기 셋팅 난이도가 살~짝 높다면 높지만 크지 않고, 유연성 등은 비슷한 것 같아서요. 게다가 최근 row 단위 권한 관리까지 되니 Good.

[shakespeares]

Notion이 러닝커브가 낮아서 좋은 것 같아요.

[GN⁺]

Hacker News 의견

• 항상 간과되는 점임. 스프레드시트는 데이터베이스와 빠르고 쉽게 커스터마이즈 가능한 UI, 그리고 반복적이고 디버깅이 쉬운 데이터 처리 환경을 한곳에 모아두었음. 전 세계 직장인 모두가 이미 이해하고 쓰는 툴이고, 제작자가 자유롭게 원하는 대로 구현할 수 있는 자유도도 제공함. 휴대성 역시 뛰어남. 코딩을 못하는 사람들에게 특히 창의적이고 강력한 툴이라고 확신함. 물론 이런 자유에는 단점도 따르지만, 온라인화 여부나 어떤 벤더가 좋냐 하는 논쟁에도 불구하고 스프레드시트에 대한 깊은 애정은 조금도 줄어들지 않음. 우리가 만든 저작 도구 중 가장 뛰어난 도구라고 생각함. 스프레드시트와 유사한 모델로 HyperCard를 꼽겠음. 다양한 앱, 데이터, UX 등을 엮어낼 수 있었던 유연한 작업대였음. HyperCard가 영원히 기억되었으면 하는 마음임

  • 맞음, 스프레드시트는 진입 장벽이 정말 낮음. 심지어 농장 한가운데에서 핸드폰으로 Google Sheets에 작물 성장 기록을 입력함. 전파가 약해도 오프라인 모드로 기록해두었다가 집에 오면 동기화함. 기록이 엉망이더라도 없는 것보단 훨씬 나음. 농업은 데이터가 많이 필요하지만 의외로 데이터가 부족한 환경임. 학습 주기가 1년 단위로 길고, 1년이 매번 달라짐

  • 코딩을 할 수 있는 사람에게는 Appscript가 스프레드시트를 거의 슈퍼파워로 만들어줌. 혹시 모르는 사람들을 위해 말하자면, Google Sheets에 내장된 웹 IDE에서 그냥 JS만 써야 하는 건 아님(사실 그것도 꽤 쓸 만함). clasp를 쓰면 로컬 IDE에서 Typescript로 개발하고, 빌드 과정에서 JS로 컴파일해 스프레드시트에 바로 배포할 수 있음. 툴체인을 세팅해두면 개발 경험(DX)도 꽤 괜찮음

  • 강하게 동의함. 데이터베이스+UX+로직이 하나로 통합된 작업대의 가치는 우리가 계속해서 반복해 만들어내는 듯한 앱의 핵심임. 그래서 Visual Basic도 여전히 쓰이고 있음. 물론 방향이 확실하게 정해진 뒤에는 최고의 방법은 아니지만, 빠르게 반복해가며 진짜 요구 사항을 파악하는 데에는 더할 나위 없음

  • 더 나은 방법으로 스프레드시트를 데이터베이스 백엔드로 활용할 수 있으면 좋겠다고 생각함. 대부분의 사람들이 스프레드시트로 하는 일의 상당수가 데이터베이스에서 더 잘 처리될 것임. 하지만 데이터베이스는 교육이 더 필요하고, 교육이 부족하면 오히려 스프레드시트보다 더 안 좋은 결과가 나올 수 있음

  • 왜 스프레드시트에서 커스텀 UI를 갖춘 완전한 데이터베이스로 점진적으로 이전하는 현실적인 전환 경로가 없는지 항상 의문이었음. 스프레드시트가 그 역할의 바로 직전 단계인데, 몇 가지 필수 기능(구조적 데이터, 네이티브 SQL, 커스텀 UI 요소, IDE 통합 등)만 있으면 충분히 가능할 것 같음

• "Ask HN: Is the world run by badly updated Excel sheets?"라는 글이 떠오름. 스프레드시트의 한계를 직접 겪으려면 경험이 필요함. 버전 관리가 없음, 테스트도 없음. 변하지 않고 짧은 수명인 작업에는 좋은데, 지속적으로 진화해야 한다면 문제가 됨. https://news.ycombinator.com/item?id=33611431 참고. 그 스레드에 이런 댓글이 있었음: 결국 회사 내에서는 Excel 소유자의 방식에 맞춰 모두가 적응함. 싫으면 자기가 새 Excel을 만들어서 복붙하면 그만이라서 다들 직접 관리함. 아는 프로젝트 매니저는 여러 저자가 만든 스프레드시트 버전을 계속 조율하는 것이 일상이었음

  • 2000년대 미국에서 코더로 시작했을 때, 내 업무는 윈도우 네트워크 드라이브에 항상 누군가가 애지중지 돌봐야 하는 스프레드시트를 웹앱으로 바꿔주는 것이라 생각했음. 그렇지만 여전히 많은 기업들이 스프레드시트 기반으로 잘 돌아가기도 함. 결국 확장성 문제가 터질 때가 오고, 그 땐 앱으로 옮겨야 하는데 완벽하려고 하다가 아무것도 못 할 바엔 일단 해내는 게 중요함

  • "버전 관리가 안된다"고 했는데, 사실 Excel에도 버전 관리 기능이 있긴 함. '변경 내용 추적'을 쓰면 다른 사람의 변경 사항을 승인 또는 거부할 수 있음. 다만 이 기능을 Rube Goldberg식 스프레드시트 자동화로 일 처리하는 사람들은 거의 안 씀. 필요하다면 쓸 수는 있음

  • 정보가 여러 스프레드시트에 흩어져 있을 때 문제가 생기는 걸 많이 봄. 참여자들은 어떤 스프레드시트에 어떤 정보가 있는지, 어떤 게 기준인지 모르는 경우가 많음. 그래서 누군가 A 파일만 갱신하는 걸 모르고, 다른 사람은 B만 손대는 식의 충돌이 자주 생김. 실제 프로그램이나 데이터의 문제보다는 파일을 프로젝트 내에서 관리하는 방식이 문제였음. 복잡한 공유폴더, 네트워크 어딘가에 방치된 파일 등 관리의 미로가 됨

• "문제 해결에는 항상 가장 쉬운 방식을 쓰고, 그 방식이 더 이상 비즈니스에 맞지 않으면 새로운 요구 사항에 따라 향상시키거나 대안 솔루션을 찾아라"는 조언에 동의함. 현재 가진 문제를 해결하는 데 집중해야지, 미래에 닥칠지 모를 문제나 바라는 문제를 미리 고민해봤자 맞추기 어려움. 현 솔루션이 미래에 부적합해질 수 있지만, 어떻게 부적합해질지는 예측하기 어렵기 때문임

  • 솔루션이 미래에 부적합해지는 방향은 예측하기 힘들지만, 그럼에도 미래의 솔루션을 막지 않거나 방해하지 않는 방식으로 현 솔루션을 고를 수도 있음. 옵션을 열어두고, 공급업체에 종속돼 벗어날 수 없는 상황은 피하는 게 좋음

  • 예측 가능한 대표적 부적합 사례는, 특정 벤더에 완전히 의존한 나머지 서비스에서 강제 퇴출당하거나 점점 비싸지는 요금을 감수해야 하는 경우임. 이건 충분히 예측 가능한 문제임

  • 더 많은 일을 하지 않고서도 문제 영역 전반을 다루는 방식으로 문제를 해결하면, 약간의 변화만으로도 변동되는 요구 사항들을 흡수할 수 있으니 솔루션의 견고성을 높일 수 있음. 그렇게 하면 자연스럽게 미래 문제까지도 커버함

• 미국의 유명 대형 기업에서 일하고 있음. 우리 부서는 스프레드시트 두 개에 크게 의존함. 내 공장에 대한 세 번의 인수합병을 거치며 살아남았음. 7년 전 입사했을 때부터 이미 오래된 양식이었음. 2년 전 새 매니저가 이걸 전사 시스템으로 이전시키려 했지만 실패했고, 조만간 그 시스템도 새로운 시스템으로 대체될 예정임. 하지만 2027년에도 여전히 스프레드시트를 쓸 것 같음

• 전 Google 직원임. 5년 동안 Sheets(내부적으로는 Trix라고 불림)만으로 프로젝트 관리, CRM, 분기별 기획, 리포팅, 인터뷰, 재무 등 모든 업무를 처리했음. 단순히 Google 제품이라서 쓴 게 아님(경쟁사 제품도 충분히 사용함). 스프레드시트가 목표 달성에 충분히 쓸 만할 정도로 빨리 만들 수 있다는 점이 압도적으로 편리해서, 일의 본질에 집중할 수 있는 환경이었음

  • Google에서 협업은 주로 리스트(google groups 만들기), gsheets, 그리고 실시간 자동 삭제되는 간단한 채팅으로 이루어진다고 들었음. 정말 Slack이나 Teams와 같은 소위 멋진 툴은 쓰지 않는 것인지 궁금함. 흥미로움

• "입사 9개월째"라는 누군가의 의견에, 맞든 틀리든 불과 1년이 채 안 된 경력에 이렇게 단정적인 의견을 내는 건 꽤 배짱이 있다는 생각임. OP가 놓친 점은 "임시방편만큼 영구적인 것도 없다"라는 진리임. 당장은 빠르고 즉흥적인 해법을 택하더라도, 그 솔루션의 라이프사이클을 온전히 통제할 때만 허용됨. 누군가가 만들어 달라고 해서 급히 전달했는데, 그 위에 지속적으로 새로운 용도를 더해가려 한다면… upfront cost가 조금 더 드는 툴을 강력히 주장하게 됨

  • 그 문제의 "몇 달마다 한 번씩…"이라는 말에서 거의 웃음이 나올 뻔했음. 저자는 간단한 툴로 일 처리하는 게 대원칙인 것은 잘 짚었음. 기존 툴을 그대로 쓸 수 있고, 필요를 무난하게 충족하면 가장 좋음. 실제 현장에서는 비즈니스 요구가 몇 달마다 새로 바뀌기 때문에 "임시방편이 영구 방편이 된다" 현상을 겪지 않을 수 있음. 하지만 대다수에겐 몇 년이 지나도 뒤처리를 하게 되고, "필요해지면 다시 짜자"는 시나리오는 거의 동작하지 않음. 그리고 저자는 아직 1년 뒤, 그 이상을 직접 경험해 본 적이 없음

  • 나는 특히 "몇 달마다…" 나온 부분이 인상적이었음. 한 4번은 경험해보고 나온 이야기인지 궁금함

• 대형 스프레드시트에 질린 사람들에겐 MS Access가 꽤 쓸만한 해법이었음. 스프레드시트에 구조화와 유지보수성을 더해주면서도 접근성과 개발 난이도는 지켜줌. 많은 코딩 지식 없이도 훌륭한 UI를 만들 수 있었음. 20년이 지난 지금, Access를 대체하는 솔루션이 뭔지 나도 잘 모르겠음

• OP 말에 완전히 동의함. 한 가지 덧붙이자면, Google Sheets에서 처리하기엔 너무 복잡한 요구가 생겼을 때, Google Colab(혹은 Jupyter notebook)이 그 한 단계 상위 선택지가 됨. 본격적인 앱 짓기 전에 항상 자문함: 1. 이게 그냥 스프레드시트로 될까? 2. 안 되면 Jupyter notebook으로 될까? 참고로 Sheets와 Colab 간의 연동도 훌륭함

  • 내 생각엔 jupyter notebook은 그냥 python script 쓰기보다 훨씬 복잡한 단계임. python script에도 주석 달 수 있고, 굳이 "로컬 웹서버를 띄워놓고, 주석을 보기 위해 코드블록단위로 실행하는" 방식은 별로임

  • 기존 google sheet에 있던 걸 colab notebook으로 업그레이드하려면 어떻게 하는지 궁금함. gspread python 패키지로 시트의 raw data는 읽어올 수 있지만, 기존 그래프나 상호작용 요소까지 jupyter notebook에서 바로 가져오긴 어려울 것 같음. 결국 다시 만들어야 할 듯함

  • Google Apps Script도 좋은 대안임. 데이터 가져오기 등 간단한 스크립트만으로도 꽤 많은 걸 할 수 있음

• 비즈니스 자동화의 가장 큰 문제 중 하나는 소위 '그림자(shadow)' IT, 저코드 플랫폼, 그리고 완전한 '정식' 프로젝트 사이에 존재하는 간극임. "google form으로 대충 만들기"와 "react 앱에 CI/CD, 테스트, CDN 다 깔기" 사이에 적정한 마이그레이션 경로가 비어있음. 둘 다 호환되지 않는 벽 쳐진 정원 같은 대안들만 있음

  • 그 중간 단계가 바로 ERP나 CRM 같은 SAAS 솔루션이라고 생각함. 대부분 합리적인 데이터 내보내기 기능도 있음

• Google Sheets로 모든 재무 관리를 하고 있음. Expense Tracker UI도 직접 만들어서 지출 내역 5,000건 이상을 몇 년간 누적했음. 최근에는 vibe coding으로 Google Service Account를 이용한 웹 UI 도구도 만들고, 그걸 PWA로 만들어서 휴대폰에서도 사용함. 간단한 용도(특히 1인용 애플리케이션)라면 DB 대신 Google Sheets로 충분함

  • 나도 오랜 기간 같은 방식을 고수했음. 관련 특화 앱도 많이 써봤지만, 항상 내가 만든 방식으로 돌아옴. (재밌게도, 20년 전 Microsoft Money가 요즘 나온 어떤 앱보다 내가 원하는 것에 더 가까움) 기능 추가하고 싶긴 한데, 직접 만들려고 하면 항상 반복적으로 필요한 보일러플레이트 코드에 지쳐 중도 포기하다가 결국 내 익숙한 솔루션으로 돌아오곤 함. (이건 vibe coding이 나오기 전 이야기라, 이제 다시 시도해볼 수도 있을 듯함)