개요
본 문서는 건설 인력 관리 기업 '서우에이치알'의 노션(Notion) 워크스페이스 구축 컨설팅 내용을 정리한 자료입니다. 이 세션에서는 현장별 데이터 관리, 팀 정보 입력, 각종 데이터베이스 연동 및 자동화 구축 과정을 다룹니다. 핵심 목표는 복잡한 현장 데이터를 체계적으로 관리하고, 수동 입력으로 인한 오류를 최소화하며, 데이터베이스 성능을 최적화하는 것입니다.
특히, Make(구 Integromat)를 활용하여 여러 데이터베이스에 정보를 자동으로 분배하는 프로세스와, 노션 템플릿 생성 시 발생하는 '동기화 블록'의 문제점 및 해결 방안에 대해 심도 깊게 논의합니다. 또한, '직영'과 '도급'이라는 각기 다른 정산 방식의 비즈니스 로직을 노션 시스템에 어떻게 반영하고 계산하는지에 대한 실제 적용 사례를 통해 실무적인 인사이트를 제공합니다. 이 문서는 노션을 활용해 복잡한 비즈니스 관리 시스템을 구축하려는 사용자에게 유용한 지식 자료가 될 것입니다.
주요 학습 포인트
•
Make(구 Integromat)를 활용한 노션 데이터베이스 간의 데이터 입력 및 연동 자동화 방법
•
노션 워크스페이스 성능 최적화를 위한 데이터베이스 구조 설계 (인라인 DB vs 전체 페이지 DB)
•
노션 템플릿 생성 시 '동기화 블록' 사용의 한계점과 이에 대한 실무적 대안
•
'직영'과 '도급' 등 복잡한 비즈니스 정산 로직을 노션의 관계형 데이터베이스와 수식(Formula)으로 구현하는 방법
•
실시간 협업 및 디버깅을 통해 노션 시스템을 구축하고 문제를 해결하는 전 과정
요약
1. 초기 데이터베이스 구조 설계 및 페이지 생성
•
주제: 서우HR 프로젝트의 기본 페이지 구조와 핵심 데이터베이스 2개를 설정하는 초기 단계입니다.
•
핵심 요점:
1.
기본 페이지 구성
•
'서우 HR' 메인 페이지 내에 데이터 입력, 검색, 진행 현황, 완료 현황을 관리하는 섹션을 구분하여 생성합니다.
•
사용자는 주로 '진행 중 현장' 페이지를 통해 각 프로젝트에 접근하게 될 것을 예상합니다.
2.
데이터 입력 프로세스 정의
•
현장 정보를 입력한 후 '입력 완료' 버튼(체크박스)을 클릭하면, 해당 현장의 상태가 '진행 중'으로 변경되고 관련 데이터가 하위 섹션으로 이동하는 흐름을 설계합니다.
•
이는 데이터 입력 시점과 실제 작업 착수 시점을 구분하여 관리의 정확성을 높이기 위함입니다.
3.
데이터베이스 초대 방식 논의
•
페이지 내 '총괄' 속성에 이름을 입력하는 것과 실제 데이터베이스 접근 권한을 부여하는 것은 별개의 작업임을 명확히 합니다.
•
주목할 발언: "입력하고 나중에 DB랑 그거 하나하나 다 개별적으로 초대를 해야 돼요. 여기에 있는 거랑 상관없어요."
•
이는 노션의 공유 및 권한 설정에 대한 중요한 실무 지식입니다.
4.
현장 고유 번호 체계 수립
•
현장 고유 번호를 알파벳과 숫자의 조합(예: A001, A002...)으로 부여하고, 번호가 소진되면 다음 알파벳(예: B001)으로 넘어가는 규칙을 정합니다. 이는 현장을 시간순으로 정렬하고 관리하기 위함입니다.
2. Make를 활용한 팀 정보 입력 자동화 제안
•
주제: 여러 데이터베이스에 동일한 팀 정보를 반복적으로 입력할 때 발생하는 오타 및 데이터 불일치 문제를 해결하기 위해 자동화 도구 'Make'의 도입을 제안합니다.
•
핵심 요점:
1.
문제점 인식: 수동 입력의 위험성
•
'물량', '서브', '목표', '공수' 등 여러 데이터베이스에 팀 이름을 각각 입력해야 하는 상황에서 오타가 발생하면 데이터가 정상적으로 연동되지 않는 치명적인 문제가 발생할 수 있습니다.
•
주목할 발언: "팀에서 오타가 나게 되면 아예 문제가 너무 커져 버리잖아요. 나중에 데이터도 안 들어가 그럴 거라서."
2.
해결책: 자동화 시나리오 설계
•
상위 페이지의 '팀 입력' 속성에 팀 이름을 한 번만 입력하면, Make가 이를 감지하여 관련된 모든 하위 데이터베이스('물량 서브', '목표 공수' 등)에 해당 팀 이름으로 새 레코드(페이지)를 자동으로 생성하는 시나리오를 구상합니다.
•
이를 통해 데이터의 정합성을 보장하고 사용자의 반복 작업을 줄일 수 있습니다.
3.
자동화 대상 범위 논의
•
현장 고유 번호나 출력 인원 이름은 건별로 입력해야 하므로 자동화 대상에서 제외하고, 반복적이고 오류 발생 가능성이 높은 '팀 이름'에 자동화를 집중하기로 결정합니다.
3. 성능 최적화를 위한 데이터베이스 전체 페이지 전환
•
주제: 단일 페이지에 여러 개의 인라인(in-line) 데이터베이스가 존재할 경우 발생하는 노션의 성능 저하 문제를 해결하기 위해, 각 데이터베이스를 '전체 페이지'로 전환하는 작업을 진행합니다.
•
핵심 요점:
1.
성능 저하 문제 인지
•
사용자가 특정 현장 페이지(예: 광평개발)에 접근할 때부터 속도가 느려지는 현상을 확인합니다.
•
주목할 발언: "이 DB가 하나, 하나의 페이지에 있으면은 이 데이터베이스에 들어가면 속도가 아예 엄청 느려질 거예요."
•
이는 노션의 기술적 특성으로, 한 페이지에 로드할 데이터가 많을수록 성능이 저하됩니다.
2.
해결 방안: 전체 페이지로 전환
•
각 인라인 데이터베이스를 개별 '전체 페이지'로 변환합니다. 이렇게 하면 메인 페이지 로드 시 해당 DB의 데이터를 불러오지 않아 초기 로딩 속도가 크게 향상됩니다.
•
데이터베이스를 수정하거나 조회할 때는 해당 전체 페이지 링크로 직접 이동하여 작업합니다.
3.
데이터베이스 ID와 링크 관리의 중요성
•
전체 페이지로 전환하면 각 데이터베이스의 고유한 ID를 관리하기 용이해지며, 이는 추후 자동화(Make) 설정 시 필수적입니다.
•
컨설턴트는 전환 작업 후, 각 현장 페이지 내에 관련된 전체 페이지 데이터베이스들의 링크를 모아두어 관리의 편의성을 높이는 방안을 제시합니다.
4. 데이터베이스 연동 및 초기 데이터 세팅
•
주제: 전체 페이지로 전환된 각 데이터베이스의 고유 ID를 가져와 메인 현장 관리 페이지에 입력하고, 자동화 시나리오를 실행하기 위한 초기 데이터를 설정하는 과정입니다.
•
핵심 요점:
1.
데이터베이스 ID 입력
•
자동화(Make)가 각 데이터베이스를 정확히 식별할 수 있도록, '물량', '물량 서브', '목표 공수' 등 모든 관련 DB의 전체 페이지를 열어 해당 고유 ID를 복사하고, 이를 현장 관리 페이지의 지정된 속성에 붙여넣습니다.
•
중요 참고사항: 컨트롤(Ctrl) 키를 누른 채 데이터베이스를 클릭하면 새 탭으로 열려 ID를 복사하기 편리합니다.
2.
자동화 시나리오(Make) 테스트
•
설정된 DB ID를 바탕으로 Make 시나리오를 실행합니다. 웹훅(Webhook)으로 현장 고유 번호를 받고, 이를 기준으로 관련 팀 정보를 검색하여 각 하위 데이터베이스에 팀 이름 레코드를 자동으로 생성하는 과정을 테스트합니다.
•
이 과정에서 생성된 레코드의 속성 색상이 원본과 다른 사소한 문제가 발견되었으나, 기능상 문제는 없으므로 그대로 진행하기로 합니다.
3.
초기 데이터 입력 및 정리
•
자동화가 완료된 후, 팀 이름 등을 입력했던 상위 페이지의 입력란은 비워줍니다. 이 입력란은 데이터를 생성하기 위한 '트리거' 역할만 하므로, 생성 후에는 데이터를 남겨둘 필요가 없습니다.
•
주목할 발언: "(여기는) 선택 값을 넣는 거니까... (입력 후) 다 지우는..."
5. 조건부 자동화 로직 설계 및 테스트
•
주제: 신규 현장과 기존 현장에 팀이 추가되는 경우를 구분하여 자동화 로직을 다르게 적용하는 방법을 설계하고 테스트합니다.
•
핵심 요점:
1.
시나리오 분기 설정
•
신규 현장: '물량' 데이터베이스에 아무 데이터가 없는 초기 상태. 이 경우, 현장 고유 번호 생성과 팀 정보 생성을 모두 실행합니다.
•
기존 현장 팀 추가: '물량' 데이터베이스에 이미 데이터가 존재하는 상태. 이 경우, 현장 고유 번호는 더 이상 생성하지 않고, 새로 추가된 팀 정보만 하위 데이터베이스에 생성합니다.
2.
로직 구현 방법
•
Make 시나리오에서 '물량' 데이터베이스를 먼저 검색하여 데이터 존재 여부를 확인하는 필터(Filter) 단계를 추가합니다.
•
데이터가 없을 때만 '현장 고유 번호 생성' 모듈이 실행되도록 조건을 설정합니다.
•
주목할 발언: "물량이 있으면 얘네가 안 올라가고 밑으로만 가면서 팀 이름만 다 입력을 시키는 거예요."
3.
오퍼레이션 효율화
•
이 조건부 로직은 불필요한 데이터 생성을 막고, Make의 작업 단위인 '오퍼레이션'을 절약하는 효과도 있습니다.
6. 템플릿의 '동기화 블록' 문제점 발견 및 해결 과정
•
주제: 현장 페이지 템플릿에 포함된 '동기화 블록(Synced Block)'이 새 페이지 생성 시 링크가 끊어지는 문제를 발견하고, 이를 해결하기 위한 대안을 모색합니다.
•
핵심 요점:
1.
문제 현상:
•
반복 사용되는 버튼이나 블록을 쉽게 관리하기 위해 '동기화 블록'을 사용했으나, 이 템플릿으로 새 현장 페이지를 만들자 동기화 블록의 원본이 삭제되었다는 메시지와 함께 내용이 사라지는 문제가 발생했습니다.
•
주목할 발언: "팸플릿으로 만들 때 따라오지가 않나요? ... 네, 그런가 봐요."
2.
원인 분석:
•
동기화 블록은 원본 블록과 '링크'되는 개념인데, 템플릿으로부터 새 페이지가 생성되는 과정에서 이 링크가 정상적으로 복제되지 않고 끊어지는 것으로 추정됩니다. 이는 노션의 기술적 한계일 수 있습니다.
3.
해결 방안 모색:
•
동기화 블록 사용을 포기하고, 템플릿 내에 필요한 버튼이나 블록을 직접 개별적으로 배치하기로 결정합니다.
•
이로 인해 초기 설정이 다소 번거로워지는 단점이 발생합니다. 예를 들어, 현장 고유 번호를 각 버튼의 필터 값에 수동으로 일일이 설정해주어야 합니다.
•
주목할 발언: "제가 이것 때문에 동기화 블록을 만들었다가 안 됐었네요." (컨설턴트의 자기 성찰)
•
중요 참고사항: 노션 템플릿 내에서 다른 페이지나 블록을 참조하는 동기화 블록, 관계형 필터 등을 사용할 경우, 템플릿 복제 시 링크가 깨질 수 있음을 유의해야 합니다.
7. '직영'과 '도급' 비즈니스 로직 시스템 반영
•
주제: 회사의 핵심 비즈니스 모델인 '직영'과 '도급'의 차이를 이해하고, 각기 다른 정산 방식을 노션 시스템에 반영하여 정확한 비용 및 수익 계산이 가능하도록 구현합니다.
•
핵심 요점:
1.
용어 정의 및 차이점:
•
직영: 투입된 인력의 공수(man-day)를 기준으로 정산. 리스크는 낮지만 큰 수익을 내기 어려운 구조. (예: 1공수당 2만 원의 고정 수수료)
•
도급: 약속된 전체 물량(업무량)을 기준으로 정산. 하이 리스크, 하이 리턴 구조로, 효율적으로 작업을 완료하면 큰 수익을 얻을 수 있지만 손실이 발생할 수도 있음.
2.
시스템 반영:
•
직영 현장: '물량'이 곧 '투입 공수'와 동일한 개념이 되므로, 매일 투입된 공수만큼 물량 데이터가 누적 증가하는 방식으로 관리. '목표 공수' 개념은 의미가 없어집니다.
•
도급 현장: 계약된 총 물량을 기준으로 '목표 공수'를 설정하고, 실제 투입된 '실공수'와 비교하여 생산성과 수익성을 분석.
3.
계산 방식의 유연성:
•
컨설팅 중인 현장은 '직영'으로 시작했다가 성과에 따라 '도급'으로 전환될 가능성이 있는 특수한 경우입니다.
•
현재 시스템은 물량 기반으로 설계되었으므로, 직영 현장은 물량 데이터를 매일 수정/업데이트하는 방식으로 운영하기로 합니다.
•
주목할 발언: "물량이 곧 공수가 되니까. 뭐 오늘까지 스물네 개였, 이십사 공수였는데 다음날 육 공수 추가되면 물량이 또 삼십으로 늘어나는 이런 현상이요."
8. 실시간 데이터 입력 및 시스템 디버깅
•
주제: 실제 현장 데이터를 입력하며 발생할 수 있는 다양한 오류(계산 오류, 필터 미적용, 데이터 누락 등)를 실시간으로 찾아내고 수정하는 과정입니다.
•
핵심 요점:
1.
데이터 수정 방법:
•
입력이 완료된 후 데이터에 오류가 발견되더라도(예: 출력 인원 누락, 물량 변경), 자동화를 재실행할 필요 없이 '서치(Search)' 페이지에 모아놓은 전체 데이터 뷰에서 직접 수정하면 모든 관련 페이지에 반영됩니다.
•
주목할 발언: "이미 다 들어가 있는 건 관계가 다 엮여져 있으니까 누를 필요 없어요."
2.
필터 설정 오류 수정:
•
신규 현장을 세팅할 때, 각 데이터베이스 뷰에 해당 '현장 고유 번호' 필터를 반드시 걸어주어야 다른 현장의 데이터가 섞여 보이지 않습니다. 이 초기 설정을 누락하여 발생한 문제를 즉시 수정했습니다.
3.
계산 로직 검증 및 수정:
•
직영 현장의 경우, '식대'를 계산에 포함하지 않는 비즈니스 규칙이 있음을 확인하고, 관련 수식(Formula)에서 식대 항목을 제외하여 수익 계산이 정확하게 이루어지도록 수정했습니다.
•
또한, '총 공사 금액'과 '투입비 합계'가 일치해야 하는 직영 현장의 특성에 맞춰, 데이터가 다르게 나오는 원인(물량 서브 DB의 단가 입력 오류)을 찾아내 해결했습니다.
9. 최종 정리 및 향후 계획 수립
•
주제: 컨설팅을 통해 구축된 시스템을 최종 점검하고, 이를 기반으로 표준 템플릿을 제작하며, 사용자 매뉴얼 제작을 위한 다음 미팅을 계획합니다.
•
핵심 요점:
1.
템플릿 제작:
•
테스트와 디버깅이 완료된 '종로 강평 개발' 페이지의 데이터를 모두 지우고, 이 구조를 표준 '현장 템플릿'으로 저장할 계획입니다.
•
이렇게 하면, 향후 새로운 현장이 추가될 때마다 '새 페이지 만들기' 버튼 클릭 한 번으로 모든 데이터베이스 구조와 자동화 연동 준비가 완료된 페이지를 생성할 수 있습니다.
2.
사용자 편의성:
•
복잡한 백엔드 설정(DB 구조, 자동화)과 달리, 실제 사용자는 각 단계에서 정해진 버튼만 클릭하면 되도록 시스템이 설계되었습니다.
•
주목할 발언: "만드는 게 복잡해요. 뒤에 돌아가는 게 복잡하지. 사용하시는 분들은 여기 있는 버튼만 잘 눌러주시면 돼요."
3.
향후 계획:
•
사용자들이 시스템을 원활하게 사용할 수 있도록 '사용자 매뉴얼'을 공동으로 제작하기로 합니다.
•
다음 미팅(7월 1일) 일정을 확정하고, 그전까지 클라이언트 측에서 추가 테스트를 진행하며 발견되는 버그나 개선점을 공유하기로 합니다.
