[나의 앱개발기] 개발자 아닌 직장인이 만든 일정 관리 프로그램, 일정지기 개발기

행사 하나 끝내고 나면 늘 비슷한 후회가 남았습니다. 포스터를 사흘 늦게 올렸다거나, 신청 마감 공지를 깜빡했다거나, 추첨 결과를 알린다는 걸 잊고 있다가 문의가 들어와서야 아차 싶었다거나.

일이 어려워서가 아니었습니다. 챙길 게 스무 개쯤 되는데 그게 전부 제 머릿속에만 있었다는 게 문제였죠. 담당자가 바뀌면 그 스무 개가 통째로 증발하고요.

그래서 만들었습니다. 저는 개발자가 아닙니다. 전공도 아니고 회사에서 코딩하는 사람도 아니에요. 그런데 지금 이 프로그램은 실제로 조합 행사 운영에 쓰이고 있습니다. 어떻게 만들었는지, 무엇을 몇 번이나 갈아엎었는지 그대로 적어보려고 합니다.

* 왜 노션도 엑셀도 답이 아니었나.

처음엔 당연히 있는 도구를 썼습니다. 엑셀에 체크리스트를 만들고, 노션에 보드를 팠죠. 그런데 몇 달 쓰다 보니 공통된 한계가 보이더라고요.

아무도 안 봅니다. 정확히는, 봐야겠다고 마음먹은 사람만 봅니다. 마감이 지나도 문서는 조용하잖아요. 문서가 사람을 찾아오는 게 아니라 사람이 문서를 찾아가야 하니까요.

제가 원한 건 딱 하나였습니다. "마감이 다가오면 담당자한테 알아서 연락이 가는 것." 이걸 만족하는 무료 도구를 찾다가, 결국 직접 만드는 쪽이 빠르겠다는 결론에 도달했습니다.

* 비개발자가 고른 개발 도구 조합.

서버를 빌리고 배포를 배우는 순간 끝이라고 봤습니다. 유지비가 들거나 관리가 필요하면 저는 못 버티거든요. 그래서 고른 조합이 이겁니다.

역할	선택한 도구	고른 이유
데이터베이스	구글 스프레드시트	내용을 눈으로 확인·수정 가능
서버 / 로직	구글 앱스 스크립트	무료, 서버 관리 불필요
화면	HTML 웹앱	링크 하나로 모두 접속
알림	텔레그램 봇	무료, 조합 단톡방 연동
코드 작성	AI(클로드)와 대화	문법 몰라도 진행 가능

핵심은 비용 0원, 서버 관리 0입니다. 구글 계정만 있으면 되고, 데이터가 스프레드시트에 그대로 쌓이니까 프로그램이 이상하게 굴어도 시트를 열어서 눈으로 확인할 수 있죠. 이 마지막 부분이 생각보다 큰 안심이었습니다.

AI를 쓰는 방식도 짚고 넘어가야겠네요. "코드 짜줘"라고 던지는 게 아니라, "이런 상황에서 이게 불편한데 어떻게 하면 좋을까"를 계속 설명하는 식이었습니다. 결국 제가 한 일은 문제를 정확히 말하는 것과, 나온 결과를 써보고 어디가 어색한지 다시 말하는 것. 그 반복이었어요.

* 이 프로그램의 핵심 아이디어 : 템플릿.

가장 먼저 정한 건 데이터 구조였습니다. 행사(Events), 업무(Tasks), 템플릿(Templates) 세 덩어리로 나눴어요.

1. 행사 유형별로 표준 업무 흐름을 저장해둡니다.

야구 응원 같은 소모임 행사는 늘 비슷한 순서로 굴러갑니다. 일정 확정하고, 포스터 만들고, 카페에 공지하고, 신청서 받고, 마감하고, 추첨하고, 당첨자에게 연락하고. 이 흐름을 17개 업무로 정리해서 템플릿에 넣어뒀습니다. 커피트럭, 임단협, 대의원대회, 선거, 오찬간담회까지 6종을 만들어뒀고요.

2. 각 업무는 행사일 기준 상대 날짜로 저장합니다.

여기가 이 프로그램의 심장입니다. 업무마다 마감일을 절대 날짜로 적는 게 아니라, 행사일로부터 며칠 전인지를 저장해요.

마감일 = 행사일 + D오프셋(예: -14일)

이러면 행사명과 날짜만 입력해도 17개 업무의 마감일이 한 번에 자동 계산돼서 타임라인으로 펼쳐집니다. 처음 이게 돌아가는 걸 봤을 때가 이 프로젝트에서 가장 짜릿한 순간이었어요. 매번 손으로 만들던 체크리스트가 3초 만에 생기니까요.

3. 주말과 공휴일은 피해서 잡아줍니다.

실제로 써보니 바로 문제가 생겼습니다. 계산된 마감일이 토요일에 걸리는 거죠. 아무도 일 안 하는 날에 마감이 잡히니 무조건 하루가 밀립니다. 그래서 구글 공휴일 캘린더를 읽어와서, 주말이나 공휴일이면 다음 평일로 자동으로 밀어주는 보정을 넣었습니다. 단, 행사 당일 업무는 건드리면 안 되고요.

이런 게 실제로 써봐야만 나오는 요구사항이더라고요. 머리로 설계할 땐 절대 안 떠오릅니다.

* 알림을 다섯 번 갈아엎은 이야기.

가장 오래 붙잡은 부분입니다. 그리고 기능을 더하는 게 아니라 걷어내는 방향으로 갔던 유일한 부분이기도 해요.

처음엔 알림이 다섯 종류였습니다. 새 행사가 등록되면 알리고, 업무를 완료하면 알리고, 아침마다 오늘 할 일을 알리고, 지연된 업무를 알리고, 행사 전체 일정도 알리고.

결과는 짐작하시는 대로입니다. 알림이 너무 많아서 아무도 안 읽었습니다. 특히 "오늘 마감 업무가 없어요" 같은 메시지가 매일 아침 울리는 게 최악이었죠. 알림 피로가 쌓이면 정작 중요한 알림도 같이 묻힙니다.

그래서 전부 지우고 하나만 남겼습니다.

구분	처음 설계	최종
알림 종류	5가지	1가지
발송 시점	수시 + 매일	마감 하루 전부터
묶음 여부	한 번에 묶어서	업무별로 따로
담당자 표시	이메일 주소	@사용자명 호출
할 일 없는 날	없다고 알림	발송 안 함

남긴 규칙은 단순합니다. 마감 하루 전부터, 끝낼 때까지 매일 아침 9시에, 담당자를 호출해서 알린다. 알릴 게 없는 날은 아예 조용합니다.

메시지는 이런 모양이에요.

야구응원 / 포스터 안내 이미지 제작
(6/29 09:00 마감일정 25일 초과)
@담당자 호출

여기서 은근히 삽질했던 게 담당자 호출입니다. 이름을 그냥 적으면 그건 그냥 글자예요. 텔레그램에서 파란색으로 표시되면서 상대에게 알림이 울리려면 그 사람의 실제 텔레그램 사용자명이어야 하고, 그 사람이 그 방에 들어와 있어야 합니다. 그래서 이름과 사용자명을 짝지어두는 표를 코드에 넣었습니다.

마지막으로 붙인 게 바로가기 링크입니다. 알림 맨 아래 줄을 누르면 프로그램이 열리면서 그 업무가 있는 화면으로 바로 이동하고, 해당 업무 줄이 노란색으로 강조됩니다. 알림을 받고 두 번만 누르면 완료 처리가 끝나는 셈이죠. 알림과 실행 사이의 거리를 줄이는 게 결국 핵심이었습니다.

* 진짜 필요했던 건 알림이 아니라 가이드였습니다.

알림까지 만들고 나서 한동안 만족했는데, 새 담당자가 들어오면서 다시 벽에 부딪혔습니다.

"카페 게시글 마감 처리"라는 알림을 받았다고 칩시다. 처음 맡은 사람은 이걸 봐도 모릅니다. 어느 카페 어느 게시판인지, 제목을 어떻게 바꾸는지, 신청 폼은 어디서 닫는지. 결국 저한테 물어보게 되고, 그럼 프로그램을 만든 의미가 절반은 날아가죠.

그래서 업무마다 가이드를 붙일 수 있게 했습니다. 화면을 좌우로 나눠서, 왼쪽엔 가이드가 항상 떠 있고 오른쪽엔 업무 목록이 있습니다. 업무를 클릭하면 왼쪽에 그 업무의 가이드가 바로 나오고, 거기서 수정도 됩니다.

여기에 하나 더 넣은 게 스크린샷 붙여넣기입니다. 설명을 글로 백 줄 쓰는 것보다 화면 캡처 한 장이 훨씬 빠르잖아요. 가이드 입력창에 그냥 Ctrl+V를 하면 이미지가 구글 드라이브에 자동으로 올라가고 가이드에 그대로 표시됩니다.

그리고 템플릿에 가이드를 써두면, 새 행사를 만들 때 그 가이드가 업무마다 자동으로 복사됩니다. 한 번 정리해두면 다음 행사부터는 그냥 따라오는 거죠. 개인적으로는 이 기능이 알림보다 더 값어치 있다고 생각합니다. 알림은 잊지 않게 해주지만, 가이드는 못 하던 사람을 하게 만들어주니까요.

* 비개발자가 제일 많이 막힌 지점들.

기능보다 오히려 이런 데서 시간을 많이 썼습니다. 저처럼 만들어보려는 분들께 도움이 될 것 같아 적어둡니다.

1. 권한 승인.

새로운 종류의 기능을 추가하면 구글이 다시 허락을 요구합니다. 스크린샷 저장 기능을 넣었더니 "드라이브 호출 권한이 없습니다"라는 오류가 났어요. 코드가 틀린 게 아니라 승인 절차가 남았던 겁니다. 이걸 모르면 코드를 붙잡고 헤매게 되죠.

2. 개발용 주소와 배포용 주소.

알림에 넣은 바로가기 링크가 계속 "파일을 열 수 없습니다"로 뜨더라고요. 원인은 프로그램이 자기 주소를 알려줄 때 개발용 주소를 내놓는 경우가 있다는 거였습니다. 개발용과 배포용은 주소 자체가 다르기 때문에 그대로 쓰면 없는 페이지로 갑니다. 결국 실제 주소를 코드에 직접 적어두는 걸로 해결했습니다.

3. 화면이 느리게 느껴지는 문제.

기능은 다 되는데 탭을 옮길 때마다 "불러오는 중"이 뜨니까 답답했습니다. 그래서 한 번 불러온 내용은 저장해뒀다가 즉시 보여주고, 최신 내용은 뒤에서 조용히 받아와 달라진 게 있을 때만 화면을 다시 그리도록 바꿨습니다. 속도가 빨라진 게 아니라 기다림이 안 보이게 된 건데, 체감은 완전히 다르더라고요.

4. 화면 배치.

버튼 글자가 두 줄로 꺾이고, 왼쪽이 텅 비어 있고. 이런 사소한 것들이 실제로 쓸 때는 꽤 거슬립니다. 결국 여러 번 다듬었어요. 아이콘만 있던 버튼에 "편집", "삭제" 글자를 넣은 것도 그중 하나입니다. 아이콘만 있으면 처음 쓰는 사람은 못 알아봅니다.

* 이 방식, 추천할 만한가.

1. 좋았던 점.

돈이 안 듭니다. 서버도 없고 구독료도 없어요. 무엇보다 불편한 걸 발견하면 그날 저녁에 고칠 수 있다는 것이 가장 큽니다. 외주였다면 "다음 버전에"라고 미뤘을 것들을 바로 반영하니까 프로그램이 실제 업무에 계속 붙어 있게 되죠.

2. 아쉬운 점.

구글 앱스 스크립트는 빠릿한 도구가 아닙니다. 화면 전환에 1~2초씩 걸리는 걸 감수해야 해요. 사용자가 수백 명이 되면 버티기 어려울 거고요. 그리고 AI가 코드를 써준다고 해도 무엇이 필요한지 판단하는 건 결국 사람 몫입니다. 알림을 다섯 개에서 하나로 줄이자는 판단은 AI가 대신 해주지 않았습니다.

저는 개인적으로 사용자 수십 명 규모의 내부 업무 도구라면 이 방식이 정말 괜찮다고 봅니다. 반대로 외부 고객이 쓰는 서비스라면 처음부터 다른 길로 가는 게 맞고요.

* 마무리 정리.

결국 이 프로그램이 하는 일은 단순합니다. 행사 하나 입력하면 할 일이 자동으로 펼쳐지고, 때가 되면 담당자를 부르고, 처음 맡은 사람도 가이드를 보고 따라 할 수 있게 하는 것. 딱 그것뿐이에요.

돌아보면 어려운 기술을 쓴 부분은 거의 없었습니다. 오히려 시간을 잡아먹은 건 실제로 써보고 불편한 걸 찾아내서 다시 고치는 과정이었죠. 만들면서 배운 게 있다면, 처음부터 완성도 높게 설계하려는 것보다 일단 돌아가게 만든 다음 쓰면서 고치는 게 훨씬 빠르다는 것 정도네요.

비전공자도 이제 자기 업무에 딱 맞는 도구를 직접 만들 수 있는 시대가 된 것 같습니다. 저처럼 매번 같은 일을 반복하며 뭔가 놓치고 계신 분이라면, 생각보다 해볼 만하다고 말씀드리고 싶네요.