노션 수식 Formula 입문, 처음 막히는 함수부터 정리한다

지난 겨울 언제가의 화요일 오전, 창가 쪽 책상에 노트북을 펴면 화면보다 먼저 보이는 게 데이터베이스의 빈 칸이다. 마감일은 적어 놨는데 남은 날짜는 눈으로 세고, 완료 체크는 눌렀는데 상태 문구는 손으로 고친다. 속성은 많은데 판단은 계속 사람이 한다. 노션 수식 Formula는 이 반복 판단을 데이터베이스 안에 적어 두는 칸에 가깝다.

수식은 계산보다 규칙에 가깝다

노션 수식은 엑셀처럼 특정 셀 주소를 끌어와 계산하는 방식과 조금 다르다. 데이터베이스의 한 행이 가진 속성을 읽고, 그 값에 따라 텍스트·숫자·날짜·체크 결과를 돌려준다. 그래서 처음에는 함수 이름을 많이 외우는 것보다 “어떤 속성을 보고 어떤 결과를 만들 것인가”를 먼저 잡는 편이 덜 헷갈린다.

예를 들어 작업 데이터베이스에 마감일, 완료, 우선순위 속성이 있다고 치면 수식은 이런 질문을 처리한다. 마감일이 지났는가. 완료 체크가 켜졌는가. 우선순위가 높은가. 결과는 “지연”, “완료”, “확인 필요” 같은 문구가 될 수도 있고, 남은 일수 같은 숫자가 될 수도 있다.

입문 단계에서 수식 칸을 만들기 전에는 결과 형식을 먼저 정해야 한다. 숫자로 계산할지, 날짜로 돌려줄지, 사람이 읽을 문구로 보여 줄지에 따라 필요한 함수가 달라진다. 표시용 문구를 너무 빨리 붙이면 나중에 계산에 다시 쓰기 애매해진다. 이 지점에서 많이 꼬인다.

짜증이 났다.

조건 판단은 if부터 작게 쓴다

노션 Formula에서 가장 자주 만나는 함수는 if다. 조건이 맞으면 A, 아니면 B를 보여 주는 구조다. 완료 체크가 켜졌으면 “완료”, 아니면 “진행”을 표시하는 식으로 쓴다. 체크박스, 상태, 날짜 비어 있음 같은 판단에 붙이기 쉽다.

처음부터 조건을 여러 겹으로 넣으면 괄호가 금방 꼬인다. 수식이 어려워서라기보다 읽는 순서가 흐트러진 경우가 많다. 먼저 기준 하나만 잡는 쪽이 낫다.

• 참과 거짓이 갈리는 기준을 하나 정한다
• 참일 때 보여 줄 값을 짧게 쓴다
• 거짓일 때 보여 줄 값을 따로 둔다

조건이 늘어나면 ifs처럼 여러 조건을 이어서 처리할 수 있다. 다만 분기마다 한 번 쓸까말까 한 예외까지 전부 넣으면 수식 칸이 지저분해진다. 반복해서 쓰는 판단만 수식으로 빼고, 애매한 값은 상태 속성에서 직접 고르는 편이 관리가 쉽다.

근데 조건문에서 놓치기 쉬운 게 빈 값이다. 값이 없다는 상태와 조건에 맞지 않는 상태는 다르다. 마감일이 비어 있는데 “여유”라고 나오면 해석이 틀어진다. empty로 먼저 빈 값을 걸러 두면 결과가 덜 흔들린다.

날짜 함수는 마감 관리에서 바로 드러난다

마감일, 시작일, 완료일을 쓰는 데이터베이스라면 날짜 함수가 빨리 필요해진다. now는 현재 시점을 기준으로 판단할 때 쓰고, dateBetween은 두 날짜 사이 차이를 계산할 때 자주 나온다. dateAdd는 기준 날짜에 기간을 더해 새 날짜를 만들 때 쓴다.

예를 들어 마감일까지 남은 기간을 표시하려면 마감일과 현재 시점을 비교해야 한다. 이때 마감일 속성이 비어 있으면 계산 결과가 어색해질 수 있다. 그래서 날짜 수식은 보통 빈 날짜 확인, 날짜 차이 계산, 표시 문구 만들기 순서로 짜는 편이 안정적이다.

• 남은 기간 계산: 마감일과 현재 시점 비교
• 반복 일정 생성: 기준일에 기간 더하기
• 빈 날짜 방어: 날짜 속성이 비었는지 먼저 확인

날짜 수식에서 특히 조심할 부분은 “판단하는 날짜”와 “보여 주는 문구”를 섞지 않는 일이다. 내부 계산에는 날짜 그대로가 필요하고, 화면에는 사람이 읽기 좋은 문구가 필요하다. 둘을 한 칸에 몰아넣으면 처음에는 깔끔해 보여도 나중에 다른 수식에서 재사용하기 어렵다. 그래서 결국 계산용 수식과 표시용 수식을 나누는 방식이 편할 때가 많다.

예를 들면 남은 일수 속성은 숫자로만 두고, 마감 상태 속성에서 “3일 남음”, “마감 지남”처럼 보여 줄 수 있다. 숫자 속성은 정렬과 필터에 쓰기 좋고, 문구 속성은 읽기 좋다. 역할을 나누면 수정할 때 손이 덜 간다. 이건 꽤 중요하다.

텍스트와 숫자는 표시용인지 계산용인지 먼저 나눈다

텍스트 함수는 계산을 한다기보다 결과를 읽기 좋게 다듬는 쪽에 가깝다. concat은 여러 값을 붙일 때 쓰고, format은 숫자나 날짜를 텍스트로 바꿔 보여 줄 때 쓴다. 숫자만 덩그러니 보이는 대신 앞뒤에 단어를 붙이면 화면에서 읽기 편하다.

다만 텍스트로 바꾼 값은 다시 계산에 쓰기 까다로워진다. 3이라는 숫자와 3일 남음이라는 문구는 노션 입장에서 다른 값이다. 거의 없음이라고 생각했던 예외가 여기서 튀어나온다. 나중에 정렬하거나 조건을 걸 때 문구가 발목을 잡는다.

숫자 함수는 점수, 금액, 횟수처럼 값이 명확한 속성에 잘 맞는다. round는 반올림할 때 쓰고, 비교 연산은 기준 이상인지 확인할 때 붙인다. 체크박스는 참 또는 거짓으로 갈리는 값이라 조건문과 같이 쓰기 좋다.

예를 들어 숫자 속성이 비어 있으면 “입력 필요”를 띄우고, 값이 있으면 계산 결과를 보여 줄 수 있다. 여기서도 빈 값 처리가 먼저다. 값이 없다는 것과 값이 낮다는 것은 다른 상태다.

덜 헤매는 작성 순서와 흔한 실수

수식을 만들 때는 함수 목록을 펼쳐 놓고 고르는 것보다 작성 순서를 고정해 두는 편이 낫다. 먼저 데이터베이스에서 읽을 속성을 정한다. 그다음 결과가 텍스트인지 숫자인지 날짜인지 정한다. 마지막으로 빈 값, 완료 값, 진행 중 값 같은 예외를 붙인다.

짧은 수식으로 결과를 확인하고 조건을 하나씩 더하는 방식이 안전하다. 긴 수식을 한 번에 만들면 오류 위치를 찾기 어렵다. 괄호 하나가 빠졌는지, 값 형식이 맞지 않는지 확인하는 데 시간이 더 든다. 식은땀이 흘렀다.

속성 이름도 대충 붙이면 나중에 손해다. 계산, 수식, 결과 같은 이름은 데이터베이스가 커질수록 의미가 흐려진다. 마감 상태, 남은 일수, 완료 표시처럼 결과가 드러나는 이름이 낫다. 속성 이름 자체가 작은 설명서 역할을 한다.

자주 하는 실수는 대체로 비슷하다. 계산용 수식에 꾸미는 문구를 붙인다. 빈 값을 조건에서 빼먹는다. 조건을 너무 많이 겹쳐서 고치기 어려운 덩어리로 만든다. 이런 문제는 함수 지식보다 설계 순서와 관련이 깊다.

• 조건은 작은 if로 나누기
• 날짜는 계산용과 표시용 분리하기
• 빈 값부터 먼저 처리하기