안녕하세요, まさきん입니다.
집안 할 일 관리에서 조금 충격적인 숫자를 봤습니다. 규칙 문서에 적어 둔 규칙이 실제로는 절반밖에 지켜지지 않고 있었거든요. 이번에는 그걸 어떻게 세었고 어떻게 고쳤는지 기록해 두려고 합니다.
※글 게시 시점의 정보입니다. 최신 조건은 공식 사이트에서 확인해 주세요.
- “할 일에는 이모지 아이콘을 붙인다”는 규칙을 약 한 달 전부터 문서에 적어 두었다
- 미완료 할 일을 전부 세어 보니 164건 중 83건에 아이콘이 없었다
- 빠져 있던 건 AI가 자동으로 할 일을 등록하는 경로였다
- 대책은 “입구에서 필수로 만들기”와 “매일 아침 조금씩 줍는 안전망”의 이중 구조로 했다
- 확인하기 어려운 속성일수록 지켜지는지 모르는 채로 남는다
집안 할 일은 Notion과 AI로 돌리고 있다
저희 집 할 일 관리는 Notion 데이터베이스로 하고 있습니다. 아이가 넷이다 보니 자잘한 용무가 끊임없이 생깁니다. 그래서 한곳에 모아 두지 않으면 도저히 돌아가지 않아요.
특징이라면 할 일의 상당수를 제가 손으로 만들지 않는다는 점입니다. AI 정기 작업이 매일 아침과 밤에 자동으로 등록합니다. 재고 조사처럼 할 일을 정리하는 작업도 정기 작업이 해 줍니다.
아침 정보 정리 구조는 아침 브리핑 글에 썼습니다. 밤의 가계 점검은 카드 사용 자동 점검 글에서 소개했고요. 이번 이야기는 그 뒤편에서 움직이는 할 일 등록에 관한 것입니다.
”아이콘을 붙인다”는 규칙
약 한 달 전, 운영 규칙 문서에 한 줄을 추가했습니다. “할 일에는 내용에 맞는 이모지 아이콘을 붙인다”는 내용입니다.
이유는 단순합니다. 목록으로 볼 때 알아보기 쉬우니까요. 장보기인지, 학교 일인지, 돈 문제인지. 아이콘이 있으면 글자를 읽기 전에 눈에 들어옵니다.
AI 정기 작업도 이 문서를 읽고 움직이는 전제였습니다. 그래서 적어 둔 순간부터 지켜질 거라고 믿고 있었죠.
세어 보니 절반이 아이콘 없음
어느 날 문득 궁금해져서 세어 봤습니다. 미완료 할 일 전부를요.
결과는 164건 중 83건이 아이콘 미설정이었습니다. 거의 절반입니다. 규칙을 적은 지 한 달 정도 지났을 때의 상태였습니다.
솔직히 조금 더 잘 지켜지고 있을 줄 알았습니다. 목록을 훑어볼 때도 절반이 비어 있다는 느낌은 없었거든요. 익숙한 화면일수록 빠진 부분을 알아채기 어려운 건지도 모르겠습니다.
빠진 건 자동 등록 경로였다
하나하나 살펴보니 경향이 뚜렷했습니다. 아이콘이 없는 건 자동으로 등록된 할 일에 몰려 있었어요.
즉, 규칙은 문서로는 존재했습니다. 하지만 할 일을 만드는 처리 안에는 들어가 있지 않았던 거죠. AI가 매번 그 한 줄을 떠올려 준다는 보장은 어디에도 없었습니다.
사람도 마찬가지일 거예요. 매뉴얼에 적혀 있어도 바쁜 날에는 빠뜨립니다. 적어 둔 것과 실제로 손이 움직이는 것은 별개더라고요.
세는 것 자체가 힘들었다
이번에 가장 애먹은 건 사실 세는 작업이었습니다.
Notion 데이터베이스는 여러 방법으로 내용을 조회할 수 있습니다. 뷰로 목록을 보거나, SQL 같은 조회를 걸거나요. 행을 한꺼번에 가져오는 방법도 있습니다. 그런데 제가 시도한 어떤 방법으로도 아이콘 유무는 돌아오지 않았습니다.
결국 164건을 한 건씩 페이지로 가져와서 확인했습니다. 시간도 걸렸고, AI 사용량도 꽤 잡아먹었습니다.
| 확인 방법 | 아이콘 유무 | 이번에 받은 인상 |
|---|---|---|
| 뷰를 통한 조회 | 돌아오지 않았다 | 화면 눈대중은 놓친다 |
| SQL 같은 조회 | 돌아오지 않았다 | 조건으로도 쓸 수 없다 |
| 행 일괄 조회 | 돌아오지 않았다 | 건수는 알 수 있다 |
| 한 건씩 페이지 조회 | 알 수 있다 | 확실하지만 무겁다 |
이건 제가 쓰는 조회 경로에서의 이야기입니다. 환경이나 도구에 따라 다를 수도 있습니다.
그래도 교훈은 컸다고 느낍니다. “쉽게 셀 수 없는 속성은 지켜지고 있는지 아무도 모른다”는 것이죠.
83건에는 그 자리에서 아이콘을 붙였다
센 김에 83건 전부에 그 자리에서 아이콘을 붙였습니다. 할 일 내용을 보고 거기에 맞는 이모지를 고르는 식으로요.
다만 이건 지금 있는 것을 고쳤을 뿐입니다. 내일 또 자동 등록이 돌면 같은 누락이 늘어납니다. 정말 고쳐야 할 곳은 누락이 생기는 입구 쪽이었습니다.
대책은 “입구”와 “안전망”의 이중 구조
고민 끝에 대책을 이중으로 했습니다.
| 대책 | 어디서 효과가 있나 | 내용 |
|---|---|---|
| 입구에서 필수로 만들기 | 할 일을 만드는 순간 | 생성과 같은 호출에서 아이콘을 넘긴다 |
| 안전망으로 줍기 | 매일 아침 정리 작업 | 아이콘 없는 것을 1회 최대 25건까지 고친다 |
둘 중 하나로는 부족하다고 생각했습니다. 입구만 막으면 새 처리를 추가할 때 또 샙니다. 안전망만 두면 매일 고칠 것이 계속 쌓이고요.
공장 품질 관리에서는 실수를 주의가 아니라 구조로 막는다는 사고방식이 자주 이야기됩니다. 이른바 포카요케(실수 방지 장치)죠. 이번 이중 대책도 그 발상에 가까운 것 같습니다.
입구에서 필수로 만드는 규칙
첫 번째는 등록하는 쪽의 규칙입니다. 문구는 이렇게 정했습니다.
“할 일을 만드는 모든 처리는 생성과 같은 호출에서 아이콘을 넘긴다.”
핵심은 “같은 호출에서”라는 부분입니다. 만든 뒤에 붙이러 가는 방식이면 그 두 번째 단계가 빠집니다. 한 번에 끝내면 샐 틈이 없죠.
Notion API에서는 페이지를 생성할 때 아이콘도 지정할 수 있습니다. 공식 레퍼런스에서 생성 시점에 icon을 넘길 수 있다는 걸 확인했습니다. 그러니 기술적으로는 한 번에 끝낼 수 있는 셈입니다.
망설여지면 기본 이모지로 충분
또 하나 추가한 건 망설일 때의 탈출구입니다. 분야별로 기본 이모지를 정해 두고, 망설여지면 그걸로 괜찮다고 했습니다.
완벽한 이모지를 고르는 것보다 비워 두지 않는 걸 우선합니다. 딱 맞는 하나를 찾다 보면 AI도 망설이다가 결국 안 붙일지도 모르니까요. 기준을 낮추더라도 반드시 채워지는 형태가 낫다고 생각했습니다.
매일 아침 안전망 설계
두 번째는 빠져나간 것을 줍는 안전망입니다. 매일 아침 자동 정리 작업에 점검 항목을 하나 추가했습니다.
- “오늘 할 일”과 “오늘 할 수 있는 일” 두 개의 뷰를 본다
- 그중에서 아이콘이 없는 할 일을 찾는다
- 1회에 최대 25건까지 내용에 맞는 아이콘을 붙인다
- 나머지는 다음 날 아침 이후에 맡긴다
전체는 보지 않습니다. 164건을 한 건씩 가져오는 무게는 이미 겪어 봤으니까요. 그걸 매일 아침 하는 건 현실적이지 않다고 봅니다.
”어디까지 했는지”를 기억시키지 않는다
여기서 조금 고민한 게 진행 상황 관리였습니다. 지난번에 어디까지 고쳤는지 저장해 두는 장치도 만들려면 만들 수 있습니다.
하지만 만들지 않기로 했습니다. “오늘 할 일”과 “오늘 할 수 있는 일”은 매일 내용이 바뀌는 뷰입니다. 이 두 개를 매일 보다 보면 언젠가 전체에 닿을 겁니다.
상태를 갖는 구조는 그 상태 자체가 망가질 수 있습니다. 저장 위치가 사라지거나 중간에 멈추거나요. 상태를 갖지 않는 안전망이 오래 내버려 둬도 버티지 않을까요.
상한을 두는 이유
1회 25건이라는 상한에도 의미가 있습니다. 어쩌다 대량으로 빠지더라도 아침 처리가 부풀지 않게 하기 위해서입니다.
자동으로 도는 처리는 제동 장치가 없으면 폭주하기 쉽습니다. 상한이 있으면 최악이라도 25건 분량의 수고로 끝납니다. 다 못 주운 건 다음 날 아침으로 넘기면 된다고 딱 잘라 정했습니다.
반영한 곳은 정기 작업 3개
이 규칙을 넣은 건 할 일을 등록하는 정기 작업 3개입니다.
| 정기 작업 | 시간대 | 넣은 내용 |
|---|---|---|
| 할 일 정리 | 심야부터 이른 아침 | 등록 시 필수화와 아침 안전망 |
| 리마인더 가져오기 | 아침 | 등록 시 필수화 |
| 메일 정리 | 밤 | 등록 시 필수화 |
원래는 각 작업 본체의 절차서를 고치는 게 맞습니다. 다만 그 자리에서 절차서를 고칠 수 없는 사정이 있었습니다. 그래서 각 작업의 지시문 쪽에 “예외 규정”으로 덧붙여 두었습니다.
남은 과제는 규칙의 이중 관리
이 방식에는 분명한 약점이 있습니다. 같은 규칙이 두 곳에 있는 상태가 되었다는 점입니다.
절차서와 지시문 중 한쪽만 고치면 어긋남이 생깁니다. 나중에 어느 쪽이 맞는지 모르게 될 수도 있습니다.
사실 예전에도 비슷한 일로 호되게 당한 적이 있습니다. 사양에는 적었는데 구현에는 들어가 있지 않았던 일이었죠. 그때는 이틀 동안 빠진 채로 알아채지 못했습니다.
기록과 실제가 어긋나는 이야기는 해지 완료라고 적어 둔 구독 글에서도 썼습니다. 적어 둔 곳이 두 군데면 어긋남은 조용히 일어나는 것 같아요. 절차서를 고칠 수 있을 때 하나로 합칠 생각입니다.
아직 구멍이 남아 있는 곳
하나 더 솔직하게 적어 두겠습니다. 집 Mac에서 돌고 있는 등록 스크립트에는 아직 필수 한 줄을 넣지 않았습니다.
당분간은 아침 안전망이 24시간 이내에 주울 것으로 보고 있습니다. 다만 안전망이 보는 건 두 개의 뷰뿐입니다. 거기에 올라오지 않는 할 일은 조금 시간이 걸릴 수도 있습니다.
입구와 안전망의 이중 구조로 했다고는 해도 입구의 일부는 아직 열려 있습니다. 안전망은 어디까지나 마지막 받침대라는 위치입니다.
규칙과 AI에 대해 생각한 것
이번 일로 AI나 자동화에 규칙을 맡길 때의 주의점이 보였습니다.
- 문서에 적은 규칙은 처리 안에 들어가야 비로소 지켜진다
- 확인할 수 없는 속성은 지켜지는지 알 수 없다
- “나중에 붙이기”보다 “만들 때 붙이기”가 새지 않는다
- 완벽을 요구하는 기준보다 반드시 채워지는 기준이 강하다
- 상태를 갖지 않는 점검은 잘 망가지지 않고 계속하기 쉽다
모두 회사에서는 당연하게 하는 이야기일지도 모릅니다. 그런데 집안 구조가 되면 갑자기 느슨해집니다. 저만 보고 있으니 확인할 기회가 없는 거죠.
예전에 학교 연락을 놓친 이야기도 썼습니다. 그때도 구조를 만든 쪽의 착각이 원인이었습니다. 만들고 끝이 아니라 한 번은 세어 보는 게 중요하다고 느낍니다.
“적었으니 지켜진다”가 아니라 “구조로 만들었으니 지켜진다”. 이 발상은 가계의 고정비에도 그대로 통한다고 생각합니다. 예를 들어 휴대폰 요금은 한 번 구조를 바꿔 두면 매달 계속 효과가 납니다.
누르면 라쿠텐 로그인 페이지가 열립니다. 로그인하면 캠페인 내용이 표시됩니다.
흔한 실패와 함정
이번 경험과 일반론을 합쳐 보면 이런 함정이 있을 것 같습니다.
- 규칙을 적은 시점에 지켜지고 있다고 착각한다
- 사람이 만드는 것과 AI가 만드는 것에 같은 규칙이 적용되는지 확인하지 않는다
- 세기 어려운 속성을 세지 않은 채 내버려 둔다
- 고친 건수만 보고 입구를 고치지 않는다
- 안전망에 전수 점검을 시켜 처리가 너무 무거워진다
- 규칙을 두 곳에 적고 한쪽만 업데이트한다
저에게 해당된 건 적어도 첫 번째와 마지막입니다. 짚이는 데가 있다면 한 번 세어 볼 가치가 있을지도 모릅니다.
시작하기 전에 확인할 것
- 지키게 하고 싶은 규칙을 하나로 좁혔다
- 그 규칙이 지켜지는지 세는 방법을 확인했다
- 할 일을 자동으로 만드는 처리를 모두 적어 냈다
- 생성과 같은 한 번의 호출로 그 속성을 넘길 수 있는지 확인했다
- 망설일 때의 기본값을 정했다
- 규칙을 적는 곳을 한 군데로 모을 수 있을지 생각했다
자주 묻는 질문
Q. 왜 아이콘에 그렇게까지 신경 쓰나요?
아이콘 자체보다 “규칙이 지켜지고 있는가”를 재는 표식으로 알기 쉬웠기 때문입니다. 눈으로 봐도 유무가 확실하니까요. 다른 규칙에서도 같은 일이 일어나고 있을지 모른다고 생각했습니다.
Q. Notion API로 생성할 때 아이콘을 붙일 수 있나요?
공식 레퍼런스에서는 페이지 생성 시점에 icon을 지정할 수 있다고 안내하고 있습니다. 이모지 외에 외부 이미지 등도 고를 수 있는 것 같습니다. 생성 후에 페이지를 업데이트해서 붙일 수도 있습니다.
Q. 아이콘 없는 할 일을 한꺼번에 세는 방법이 있나요?
제가 시도한 뷰나 SQL 같은 조회에서는 아이콘 유무가 돌아오지 않았습니다. 행 일괄 조회도 마찬가지였고요. 결국 한 건씩 페이지를 가져와 확인했습니다. 다른 방법이 있는지는 사용하는 환경에서 확인해 보세요.
Q. 안전망을 매일 전체 대상으로 돌리지 않는 이유는요?
전체를 한 건씩 확인하는 건 수고도 AI 사용량도 크기 때문입니다. 매일 보는 두 뷰에서 상한을 두고 주우면 언젠가 전체에 닿을 거라고 봤습니다. 무거운 점검은 오래가지 못하기 쉽다고 생각합니다.
Q. “지난번에 어디까지 했는지”를 저장하지 않으면 불안하지 않나요?
저장하는 장치는 그 자체가 망가지는 지점이 되기도 합니다. 매일 내용이 바뀌는 뷰를 보고 있으면 기억해 둘 필요가 없다고 판단했습니다. 언젠가 전체에 닿으면 충분하다고 딱 잘라 생각하고 있습니다.
Q. 규칙의 이중 관리는 어떻게 해소할 예정인가요?
본체 절차서를 고칠 수 있을 때 그쪽으로 하나로 합칠 생각입니다. 그때까지는 지시문 쪽 예외 규정과 어긋나지 않도록 조심하려고 합니다. 예전에 사양과 구현이 어긋나 이틀 동안 누락된 적이 있어서 신중하게 진행하려 합니다.
Q. 사람이 할 일을 만들 때도 같은 생각을 쓸 수 있나요?
쓸 수 있다고 봅니다. 템플릿에 아이콘을 처음부터 넣어 두는 건 입구에서 필수로 만드는 발상 그 자체입니다. 사람도 나중에 붙이는 것보다 만들 때 붙어 있는 편이 덜 새지 않을까요.
참고한 공식 정보
정리
규칙에 적어 둔 규칙은 한 달 동안 절반밖에 지켜지지 않았습니다. 164건을 세어 보고서야 겨우 알게 된 사실입니다.
고치는 방법은 이중으로 했습니다. 입구에서 필수로 만드는 것과 매일 아침 조금씩 줍는 안전망입니다. 안전망은 상태를 갖지 않고, 상한을 둔 채 매일 보는 뷰에서 줍습니다. 규칙의 이중 관리와 집 Mac 쪽 구멍은 아직 남아 있습니다.
완벽한 구조는 아닙니다. 그래도 “적으면 끝”에서 한 걸음은 나아간 것 같아요. 자동화해 둔 게 있다면 한 번만이라도 세어 보시는 건 어떨까요.
누르면 라쿠텐 로그인 페이지가 열립니다. 로그인하면 캠페인 내용이 표시됩니다.
이 글에는 제휴 광고가 포함되어 있습니다. 이 사이트의 링크를 통해 상품·서비스에 신청하시면 제휴사로부터 보상을 받을 수 있습니다. 또한 운영자는 라쿠텐 그룹 소속 직원으로, 사원 추천 프로그램을 통해 보상을 받는 경우가 있습니다. 기사 내용과 평가는 광고 유무와 관계없이 운영자의 실제 경험과 조사를 바탕으로 작성했지만, 위 관계를 이해하신 후 읽어 주시기 바랍니다. 자세한 내용은 면책조항·제휴 링크 안내를 참고해 주세요. 면책조항·제휴 링크 안내
이 글에는 기계 번역이 포함되어 있습니다. 정확한 조건은 라쿠텐 모바일 공식 사이트의 다국어 페이지에서 확인해 주세요.
라쿠텐 모바일의 통신 지역·전파 상황이 궁금하신 분은, 공식 전파 개선·조사 요청 양식 을 통해 문의하실 수 있습니다.