개요
이 문서는 노션(Notion)과 메이크(Make, 구 Integromat)를 활용하여 건설 현장의 복잡한 데이터를 관리하고 자동화하는 시스템 구축 컨설팅 3일차 내용을 정리한 자료입니다. 주요 논의는 기존 데이터베이스 구조의 문제점을 개선하고, 현장별로 동적으로 변화하는 데이터베이스 ID를 처리하는 Make 시나리오 설계, 총괄 관리자의 권한 설정 자동화, 그리고 월간 리포트 생성을 위한 데이터 연동 및 자동화 방안에 초점을 맞추고 있습니다.
본 문서는 실제 컨설팅 과정에서 논의된 구체적인 문제점, 해결 아이디어, 구현 방식, 그리고 실무적 고려사항들을 상세히 담고 있어, 유사한 시스템을 구축하거나 기존 시스템을 개선하고자 하는 담당자에게 실질적인 가이드가 될 수 있습니다. 특히, 노션의 유연성과 메이크의 자동화 기능을 결합하여 복잡한 업무 프로세스를 어떻게 효율화할 수 있는지에 대한 깊이 있는 통찰을 제공합니다.
주요 학습 포인트
•
노션 데이터베이스 구조 최적화 (템플릿화 및 통합 관리)
•
Make를 활용한 동적 데이터베이스 ID 처리 및 자동화 시나리오 구성
•
노션 내 페이지 버튼과 웹훅을 연동한 자동화 트리거 설계
•
동적 데이터베이스 사용 시 Make 모듈(Search Object)의 한계점 및 우회 방안
•
복잡한 권한 관리를 위한 외부 도구(매직 밀 키트) 활용 검토
•
월간 리포트 자동 생성을 위한 데이터 연동 및 계산 로직 수립
•
실제 업무의 유동성(예: 월별 작업 걸침, 직영 작업)을 시스템에 반영하는 방법론
요약
1. 도입 및 데이터베이스 구조 변경 사항 브리핑
•
주제: 이전 작업 내용 회고 및 변경된 데이터베이스 구조 설명
•
핵심 요점:
1.
어제 작업의 어려움: 컨설턴트는 이전에 진행한 작업이 매우 어려웠음을 언급하며, 특히 데이터베이스 구조 변경과 자동화 설정이 도전적이었다고 말합니다. ("와, 이거 대박이던데요. 지금 얘네가 대박이에요.")
2.
데이터베이스 구조 단순화: 기존에 공유용과 사무용으로 나뉘어 있던 '현장' 데이터베이스를 하나로 통합했습니다.
•
불필요한 중복을 제거하고 관리를 용이하게 하기 위함입니다.
3.
데이터베이스 중앙화: 외부에 흩어져 있던 여러 데이터베이스들을 특정 페이지 내부로 모두 '원본' 형태로 이동시켰습니다.
•
이는 추후 '템플릿' 형태로 시스템을 복제하거나 배포할 때, 모든 원본 데이터베이스가 템플릿 내에 포함되도록 하기 위함입니다.
•
부가 설명:
◦
어제 녹화가 제대로 되지 않아 이전 작업 내용을 다시 브리핑하는 상황입니다.
◦
데이터베이스 구조 변경은 템플릿화를 염두에 둔 사전 작업의 일환입니다.
2. Make 자동화: 현장별 동적 데이터베이스 ID 처리 (1)
•
주제: 여러 현장에 동일한 Make 시나리오를 적용하기 위한 동적 데이터베이스 ID 처리 방법 설명
•
핵심 요점:
1.
문제 정의: 각 현장(예: 안양 테일)마다 고유한 데이터베이스(출력일보, 작업일지, 물량 등)가 생성되며, 이 데이터베이스들의 ID를 Make 시나리오에 동적으로 전달해야 합니다.
2.
솔루션 개요:
•
'현장' 정보가 담긴 메인 데이터베이스에 각 현장별로 사용될 하위 데이터베이스(출력일보, 작업일지 등)의 ID를 미리 저장해둡니다.
•
노션 페이지 내에 버튼을 만들고, 이 버튼을 클릭하면 해당 현장의 정보(예: 현장명, 현장 고유번호)와 함께 미리 저장된 DB ID들이 Make 시나리오로 전달되도록 합니다.
3.
구현 방식 (초기 아이디어):
•
현장 정보 입력 후 '입력 완료' 버튼을 클릭하면, 해당 현장 페이지 내에 필요한 원본 데이터베이스들이 자동으로 생성됩니다.
•
생성된 원본 데이터베이스들의 ID를 확인하여, 메인 '현장' 데이터베이스의 해당 현장 항목에 수동으로 입력해야 합니다. (이후 이 부분이 자동화될 가능성 시사)
•
부가 설명:
◦
컨설턴트는 이러한 DB 구성 경험이 이전에는 없어 어제 작업에 어려움을 겪었다고 언급합니다.
◦
이 방식은 작업자 수가 많지 않을 경우(수천 명이 아닌 경우)에 적합하다고 판단되어 변경되었습니다.
•
중요 참고사항:
◦
초기에는 생성된 DB ID를 수동으로 메인 현장 DB에 입력해야 하는 번거로움이 있습니다.
3. Make 자동화: 동적 DB ID를 사용한 시나리오 구성 상세
•
주제: Make 시나리오에서 동적으로 변경되는 데이터베이스 ID를 처리하는 구체적인 설정 방법
•
핵심 요점:
1.
Make 모듈 설정 방식 차이:
•
기존 방식: Select from the list를 사용하여 Make 모듈 내에서 특정 데이터베이스를 직접 선택하면, 해당 DB의 필드들이 자동으로 로드됩니다. 이 경우 DB ID는 고정됩니다.
•
새로운 방식: DB ID가 현장마다 바뀌므로, Make 모듈에서 데이터베이스를 선택할 때 Manual로 설정하고, 데이터베이스 ID를 이전 단계에서 가져온 변수(동적 ID)로 입력합니다.
2.
필드 수동 매핑: 데이터베이스 ID를 변수로 처리하면, 해당 데이터베이스의 필드(예: 작업, 물량, 제목 등)를 Make 모듈에서 수동으로 지정(매핑)해줘야 합니다.
•
예시: '목표 공수'를 업데이트하는 모듈에서 '작업' 필드와 '물량' 필드에 어떤 값을 넣을지 직접 설정해야 합니다.
3.
사용자 경험:
•
설정: 새로운 현장이 생길 때마다 이 Make 시나리오를 복제하거나 수정할 필요는 없습니다. 하나의 시나리오를 계속 사용합니다.
•
데이터 입력: 새로운 현장이 추가되면, 해당 현장의 데이터베이스 ID들을 관리용 테이블(예: '현장' DB)에 입력해주면 됩니다.
•
사무직원의 Make 수정 불필요: 일단 시나리오가 설정되면, 사무직원이 Make 자체를 수정할 일은 없습니다.
•
부가 설명:
◦
이 방식은 컨설턴트도 처음 시도해보는 방법이며, 이를 통해 레벨업했다고 언급합니다. ("덕분에 레벨업 했습니다.")
◦
버튼 클릭 시, 해당 페이지의 고유 번호(예: 마곡 휘강의 A001)를 기준으로 매칭되는 데이터베이스 ID들을 가져와 시나리오가 동작합니다.
•
중요 참고사항:
◦
초기 세팅의 복잡성: Make 시나리오를 처음 구성할 때 필드를 수동으로 매핑해야 하는 작업이 필요합니다.
◦
유지보수의 용이성: 일단 세팅이 완료되면, 새 현장 추가 시 Make 시나리오를 건드리지 않고 데이터만 추가하면 되므로 유지보수가 비교적 쉽습니다.
4. Make 자동화: 동적 DB ID 사용 시 Search Object 모듈의 한계와 해결책
•
주제: 데이터베이스 ID가 동적으로 변할 때 Make의 Search Object 모듈에서 발생하는 필터링 제약과 그 해결 방안
•
핵심 요점:
1.
문제점: Search Object 모듈에서 데이터베이스 ID를 변수로 지정하면, 특정 필드 값을 기준으로 검색 대상을 필터링하는 기능(예: '입력 완료' 체크박스가 체크되지 않은 항목만 검색)을 사용할 수 없습니다.
•
이유: 데이터베이스 ID가 고정되어 있지 않으면, Make가 해당 데이터베이스의 필드 구조를 미리 알 수 없어 필터링 조건을 설정할 수 없습니다.
2.
기존 방식과의 비교:
•
고정 ID: DB ID가 고정되면, Search Object 모듈에서 필드를 직접 선택하여 필터링 조건을 설정할 수 있습니다.
•
동적 ID: 필드 목록이 나타나지 않아(이전 단계의 일반적인 필드만 나타남) 직접적인 필터링이 불가능합니다.
3.
해결 방안:
•
1단계 (데이터 전체 로드): Search Object 모듈에서는 필터링 없이 해당 데이터베이스의 모든 항목을 일단 다 가져옵니다.
•
2단계 (경로 필터링): 가져온 전체 데이터에 대해 다음 단계의 '라우터(Router)' 모듈이나 '필터(Filter)'에서 조건을 설정하여 필요한 데이터만 다음 단계로 넘깁니다.
◦
예시: 웹훅으로 전달된 특정 이름 및 팀과 일치하는 항목만 다음 경로로 진행시킵니다.
4.
부작용: 필터링을 후순위로 미루면서, 시나리오 실행의 성공/실패 여부를 Search Object 단계에서 명확히 알 수 없게 됩니다.
•
예를 들어, B1 구간을 B2로 잘못 입력하면 관계가 안 맺어지지만, 사용자는 이를 즉시 알기 어렵습니다.
•
부가 설명:
◦
이 문제는 노션 페이지 내 버튼을 통해 값을 전달하는 방식과 관련하여 발생합니다. 페이지 버튼은 해당 페이지의 고유값(예: A001)을 전달할 수 있어 유용하지만, 이로 인해 Search Object 모듈의 한계가 드러납니다.
◦
오류 발생 시, 최종 단계(예: 작업 일지 업데이트)가 실행되지 않아 체크박스가 체크되지 않는 것으로 간접적인 확인은 가능합니다. 담당자는 이를 보고 문제 발생을 인지하고 수정해야 합니다.
•
중요 참고사항:
◦
오류 감지의 어려움: 사용자가 입력 오류를 범했을 때, 시스템이 이를 명확하게 알려주지 못하고, 간접적인 증상(체크박스 미체크)으로만 파악해야 합니다.
◦
데이터 처리 방식 변경: 조건부 검색이 아닌, 전체 검색 후 조건부 필터링으로 로직을 변경해야 합니다.
5. 총괄 사용자 권한 관리 문제 및 '매직 밀 키트' 소개
•
주제: 총괄 관리자가 여러 현장의 링크된 데이터베이스를 보기 위한 권한 설정의 복잡성 및 자동화 솔루션 제안
•
핵심 요점:
1.
권한 문제 발생 상황:
•
총괄 관리자는 여러 현장의 데이터를 한 페이지(예: '총괄 관리 페이지')에서 링크된 데이터베이스 형태로 보려고 합니다.
•
이때, 해당 '총괄 관리 페이지'에만 접근 권한을 부여하면 링크된 데이터베이스의 내용을 볼 수 없습니다.
•
이유: 링크된 데이터베이스는 원본 데이터베이스의 '뷰(View)'일 뿐이며, 내용을 보려면 원본 데이터베이스 각각에 대한 접근 권한이 필요합니다. 원본 데이터베이스들이 '총괄 관리 페이지'의 상위 계층(또는 다른 위치)에 있기 때문입니다.
2.
수동 권한 부여의 번거로움: 각 현장의 원본 데이터베이스(작업 일지, 목표 공수, 출력 일보 등)마다 총괄 관리자를 개별적으로 초대(권한 부여)해야 합니다. 이는 현장이 많아질수록 매우 번거로운 작업입니다.
3.
자동화 솔루션: 매직 밀 키트 (Magic Mill Kit)
•
푸르공(일본 개발자)이 만든 노션 확장 기능 모음입니다.
•
이 중 Notion Plus 모듈의 Invite Guest 및 Revoke Invitation 기능을 사용하면 게스트 초대 및 권한 회수를 자동화할 수 있습니다.
•
Make 시나리오에서 이 모듈을 호출하여 버튼 클릭 등으로 여러 DB에 대한 권한을 한 번에 부여하거나 회수할 수 있습니다.
4.
매직 밀 키트 비용 및 조건:
•
가격: 컨설턴트 레퍼럴 통해 199달러 (정가 209달러).
•
라이선스: 평생 사용 가능.
•
업데이트 지원: 1년간 무료 지원. 이후 업데이트를 받으려면 소정의 금액으로 구독 갱신 필요.
•
권한 관리 모듈은 기능상 큰 업데이트가 없을 것으로 예상되어, 한번 구매로 계속 사용할 수 있을 것으로 보입니다.
•
부가 설명:
◦
컨설턴트는 이 권한 문제를 해결하는 것이 이번 컨설팅의 마지막 주요 이야기 중 하나라고 언급합니다.
◦
매직 밀 키트는 PDF 변환, 자바스크립트 실행, 유튜브 대본 가져오기 등 다양한 부가 기능을 제공합니다.
◦
고객사는 매직 밀 키트 사용 여부를 결정해야 합니다. 현재 현장 수에서는 수동 작업도 가능하지만, 확장성을 고려하면 자동화가 유리할 수 있습니다.
•
중요 참고사항:
◦
권한 상속의 이해: 노션에서 링크된 데이터베이스를 사용하려면, 뷰가 있는 페이지뿐만 아니라 원본 데이터베이스에도 접근 권한이 있어야 합니다.
◦
외부 도구 사용 결정: 비용 및 관리 측면을 고려하여 매직 밀 키트와 같은 외부 도구 사용 여부를 신중히 결정해야 합니다. 부가세는 별도입니다.
6. 출력일보 및 실공수 데이터베이스 필드 조정
•
주제: 건설사에 제공될 출력일보(측정 공수)와 내부 관리용 실공수 데이터베이스의 필드를 목적에 맞게 정리
•
핵심 요점:
1.
출력일보 (측정 공수 DB) 필드 변경:
•
건설사에 보여주는 자료이므로, 내부 관리용 정보인 '관리자 공수', '관리자 단가', '관리자 금액' 필드는 제거합니다.
•
필요한 필드: '측정 공수' (총 공수 개념으로 변경 가능성 논의), '작업자 단가' (기존 '일반 작업자 단가'에서 '일반' 제외), '총 인건비', '식대'.
2.
실공수 DB 필드:
•
실공수 DB는 주로 내부 검토 및 실제 투입된 공수를 관리하는 목적으로, 세부 필드 조정은 상대적으로 적습니다.
•
실공수는 키인(수동 입력) 방식으로 데이터를 유지하기로 합니다.
•
부가 설명:
◦
출력일보는 외부(건설사) 제출용이므로, 민감하거나 불필요한 내부 정보는 제외하는 방향으로 필드를 조정합니다.
◦
필드명 변경 시 혼동을 줄이기 위해 명확한 이름으로 수정합니다 (예: '일반 작업자 단가' -> '작업자 단가').
•
중요 참고사항:
◦
데이터베이스의 사용 목적(내부용/외부용)에 따라 필드 구성과 공개 범위를 신중하게 결정해야 합니다.
7. 월간 리포트에 물량 데이터 연동 및 기성률 관리 방안 논의 (1) - 엑셀 현황 공유
•
주제: 현재 엑셀로 관리 중인 물량 데이터 및 기성률 계산 방식을 공유하고, 이를 노션 월간 리포트에 어떻게 통합할지 논의 시작
•
핵심 요점:
1.
현재 엑셀 관리 방식:
•
작업 항목별로 수량을 입력하고, 사전에 세팅된 단가표를 VLOOKUP 함수로 가져와 계약 금액을 산출합니다.
•
건설사로부터 대금을 지급받을 때, 인건비 기준으로 받기도 하고 물량 기준으로 받기도 합니다. (현장마다, 시기마다 다를 수 있음)
•
건설사에서 제공하는 물량 명세서와 내부 관리 데이터를 비교하여 지급액을 확인합니다.
2.
기성률 계산 (엑셀):
•
공사 귀속월: 작업이 실제 진행되고 대금이 청구되는 기준 월.
•
유보 개념: 특정 물량에 대한 대금 지급을 다음 달로 미루는 경우.
•
월별로 지급받은 금액을 입력하고, 총 받아야 할 금액 대비 실제 받은 금액의 비율(지급률/기성률)을 계산하여 관리합니다.
3.
엑셀 관리의 어려움:
•
데이터가 월별로 가로로 확장되는 구조라 데이터베이스화하기 어렵습니다. ("옆으로 가는, 이게 머리에 진행되면 이걸 복사해서 옆으로 가요.")
•
실시간 추적이 어렵고, 작업자의 엑셀 이해도 및 수동 작업에 따른 오류 가능성이 있습니다.
•
데이터 취합 및 가공이 특정 담당자에게 집중되어 병목 현상 발생.
4.
노션에서의 핵심 요구사항: 물량 대비 돈을 제대로 받고 있는지, 못 받고 있는지를 명확히 파악하는 것.
•
부가 설명:
◦
고객사 담당자는 엑셀의 메커니즘을 설명하며, 특히 기성률 관련 부분은 인수인계 시에도 어려운 부분이었다고 언급합니다.
◦
데이터가 깔끔하게 정형화되어 있지 않고, 수동 계산 및 판단이 많이 개입됩니다.
•
중요 참고사항:
◦
기존 엑셀 방식의 복잡성과 비정형성을 이해하는 것이 노션 시스템 설계의 중요한 출발점입니다.
◦
사용자의 핵심 요구사항(돈 관리)에 집중하여 시스템을 단순화할 필요가 있습니다.
8. 월간 리포트에 물량 데이터 연동 및 기성률 관리 방안 논의 (2) - 노션 구현 아이디어
•
주제: 엑셀의 물량 및 기성 관리 기능을 노션 월간 리포트에 구현하기 위한 구체적인 데이터베이스 연동 방안 모색
•
핵심 요점:
1.
물량 데이터 연동:
•
목표: '물량 서브' 데이터베이스에 있는 '총 공사 금액'을 '월간 리포트'로 가져와야 합니다.
•
조건: '물량 서브' DB에는 날짜 정보가 없고, '목표 공수 서브' DB에는 작업일지로부터 연동된 날짜 정보가 있습니다. '물량 서브'와 '목표 공수 서브'는 1:1 매칭됩니다.
•
구현 방안:
1.
'목표 공수 서브' DB에서 날짜 정보를 가져옵니다. (작업일지 입력 시 '목표 공수 서브'에 날짜 기록)
2.
이 날짜를 기준으로 '물량 서브'의 '총 공사 금액'을 해당 월의 '월간 리포트' 항목과 관계형으로 연결합니다.
◦
결과적으로, 작업일지에 데이터를 입력하면 해당 작업의 물량 금액이 정확한 월의 리포트에 자동으로 반영됩니다.
2.
공사 귀속월 처리: 작업일지에 입력된 작업 날짜를 기준으로 월간 리포트에 데이터가 귀속되므로, 엑셀의 '공사 귀속월'과 유사한 기능이 구현됩니다.
3.
월별 데이터 중복 방지: 특정 작업(예: 6월 정문혁 팀의 1층 B1 재래식 계단)이 6월 월간 리포트에 포함되었다면, 작업 날짜가 다르지 않는 한 7월 리포트에는 중복으로 들어가지 않습니다. (날짜 기반 필터링)
4.
수익 및 기성률 계산 필드 추가:
•
수익: 총 공사 금액 - 총 인건비 (합계)
•
기성금 (건설사 지급액): 수동 입력 필드 추가
•
기성률: 기성금 / 총 공사 금액
•
기성일 및 상태: 기성금 지급일, 상태(예: 기성 전, 기성 완료) 필드 추가
•
부가 설명:
◦
"이거 건설 숫자요. [웃음] 처음. 이게 사실 제야. 계약이 구두 계약이라는 게 큰 진짜 문제인 것 같아요." - 구두 계약의 문제점과 이로 인한 데이터 관리의 어려움을 토로.
◦
팀명 표기 방식 통일 (예: '우방성' -> '우방성 팀')
◦
차트를 통해 월별 합계 등을 시각화할 수 있으나, 세부 항목별 기성률을 한 화면에서 보기는 어려울 수 있습니다. (체크박스로 특정 항목만 계산하는 방식은 너무 복잡해 보류)
•
중요 참고사항:
◦
유동적인 계약 조건과 지급 방식(구두 계약 등)으로 인해 시스템으로 모든 경우를 완벽하게 자동화하기 어려울 수 있으며, 일부 수동 조정이 필요할 수 있습니다.
◦
데이터 입력의 정확성이 전체 리포트의 신뢰도에 큰 영향을 미칩니다.
9. 노션 UI 변경점 및 관계형 자동화 준비 (출력일보)
•
주제: 최근 노션 UI 변경 사항을 간략히 언급하고, 출력일보와 월간 리포트 간 관계형 자동화를 위한 Make 시나리오 구성 시작
•
핵심 요점:
1.
노션 UI 변경점:
•
데이터베이스 보기 복제 기능 등의 UI 요소 위치가 변경되었습니다. (예: 표 보기 옵션이 제목 옆 플러스 버튼으로 이동)
•
데이터베이스 잠금 기능이 추가되었습니다.
2.
관계형 자동화 목표 (출력일보): 총괄 담당자가 '출력일보'에 데이터를 입력하고 특정 버튼을 클릭하면, 해당 내용이 '월간 리포트'의 '측정 공수' 및 '실공수' 관련 항목과 자동으로 관계형 연결되도록 합니다.
3.
Make 시나리오 구성 시작:
•
트리거: 웹훅(Webhook)으로 시작합니다. 노션 페이지 내 버튼을 클릭하면 이 웹훅 URL이 호출되도록 설정합니다.
•
초기 데이터 확보: 웹훅 실행 시, 어떤 현장의 데이터인지 식별하기 위해 '현장 고유 번호'가 필요합니다. 이 고유 번호는 해당 노션 페이지(출력일보 입력 페이지)에 미리 수동으로 입력되어 있어야 합니다. (이후 이 부분의 자동 입력 방안 모색)
•
DB ID 조회: 전달받은 '현장 고유 번호'를 사용하여, 사전에 현장 정보를 저장해둔 마스터 DB에서 해당 현장의 '월간 리포트 측정 공수 DB ID'와 '월간 리포트 실공수 DB ID'를 조회합니다.
•
부가 설명:
◦
컨설턴트는 웹훅 시나리오를 테스트하기 위해 시나리오를 켜둔 상태에서 노션 버튼을 클릭하여 데이터가 정상적으로 수신되는지 확인하는 과정을 설명합니다.
◦
'현장 고유 번호'를 페이지에 미리 입력해두는 것은 현재로서는 불가피한 수동 작업으로 보입니다.
•
중요 참고사항:
◦
웹훅 실행 조건: Make 시나리오가 켜져 있어야 웹훅이 정상적으로 동작합니다.
◦
초기 설정의 중요성: '현장 고유 번호'와 같은 핵심 식별자를 정확히 입력하는 것이 자동화의 전제 조건입니다.
10. 월간 리포트 항목 자동 생성 자동화 (매월 실행)
•
주제: 매월 특정일에 다음 달의 월간 리포트 항목들을 자동으로 생성하는 Make 시나리오 구상
•
핵심 요점:
1.
문제 정의: '출력일보'에서 데이터를 '월간 리포트'로 연결하려고 할 때, 해당 월/팀에 맞는 '월간 리포트' 항목(예: "2025년 07월 우강성팀")이 미리 존재해야 합니다. 이것이 없으면 관계형을 맺을 수 없습니다.
2.
해결 방안: 매월 특정일(예: 매월 25일 오전 10시)에 Make 시나리오를 실행하여 다음 달의 월간 리포트 항목들을 자동으로 미리 생성합니다.
3.
필요한 데이터베이스:
•
팀 데이터베이스: 팀장 이름 목록(예: 우강성, 정문학, 진경남)을 관리하는 DB. 상태 값(예: 출력 중, 계약 종료, 공사 완료, 퇴출)을 포함할 수 있습니다.
•
현장 마스터 데이터베이스: 현장 정보 및 상태(예: 진행 중, 완료)를 관리하는 DB.
4.
자동 생성 로직:
•
매월 25일, Make 시나리오가 실행됩니다.
•
'현장 마스터 DB'에서 상태가 '진행 중'인 현장들만 선택합니다.
•
선택된 각 현장에 대해, '팀 DB'에서 현재 '출력 중'(또는 계약 중)인 팀장들의 이름을 가져옵니다.
•
가져온 팀장 이름과 다음 달 정보를 조합하여 '월간 리포트 (측정 공수)' 및 '월간 리포트 (실공수)' DB에 새 레코드(항목)를 생성합니다. (예: "다음달 년월 팀명")
5.
이점: 수동으로 매월 리포트 항목을 만들 필요가 없어지고, 관계형 연결 시 대상 항목이 없어 발생하는 오류를 방지합니다.
•
부가 설명:
◦
팀이 중간에 빠지거나 계약이 종료되는 경우를 고려하여 '팀 데이터베이스'에 상태 값을 두어, 현재 유효한 팀에 대해서만 리포트 항목을 생성하도록 할 수 있습니다.
◦
이 자동화는 사무직원이 매월 수동으로 리포트 항목을 생성하는 부담을 덜어줍니다.
•
중요 참고사항:
◦
스케줄링: Make 시나리오의 실행 주기를 정확히 설정해야 합니다 (예: 매월 25일).
◦
데이터 정합성: '팀 데이터베이스'와 '현장 마스터 데이터베이스'의 상태 정보가 최신으로 유지되어야 정확한 자동 생성이 가능합니다.
◦
사용자는 자동 생성된 항목들을 확인하는 정도로 관리 부담이 줄어듭니다.
11. 사용자 교육 및 시스템 단순화 요구사항 논의
•
주제: 구축된 시스템의 사용자 교육 필요성 및 현장 사용자의 단순한 인터페이스 요구에 대한 논의
•
핵심 요점:
1.
사용자 교육의 필요성: 복잡한 시스템일수록 사용자가 기능을 제대로 활용하기 위해 매뉴얼 제작 및 교육이 필수적입니다.
•
컨설턴트는 "매뉴얼 만드셔야 된다. 그거는 항상 강조를 드려요."라고 언급합니다.
2.
현장 사용자의 특성:
•
현장 작업자들은 주로 모바일 환경에서 시스템을 사용하며, 컴퓨터 사용이 익숙하지 않을 수 있습니다.
•
복잡한 기능보다는 단순한 클릭 몇 번으로 정보를 입력하거나 확인할 수 있는 직관적인 인터페이스를 선호합니다. ("클릭 몇 번이나 그냥 이미지로 바로 볼 수 있게끔 나오기를 항상 원하셨거든요.")
3.
단순화의 어려움: 현재 논의되는 시스템은 데이터 관계가 복잡하여 웹페이지로 단순화하는 것이 얼마나 가능할지 미지수입니다.
4.
입력 방식 제안 (단순화 시도): 노션의 '양식(Form)' 기능을 활용하여 데이터 입력을 단순화하는 아이디어를 탐색합니다.
•
양식을 만들고 해당 양식 링크를 버튼에 연결하여 클릭 시 바로 입력 폼이 뜨도록 하는 방식입니다.
•
단, 이 방식이 항상 100% 안정적으로 동작하지 않을 수 있다는 우려(웹훅 충돌 등) 때문에 일단은 기존 버튼 방식으로 진행하기로 합니다.
•
부가 설명:
◦
"다들 뭔가 배우기는 싫어하고 그냥 결과만 보고 싶어 하니까." - 사용자들의 일반적인 성향에 대한 언급.
◦
현재까지 구성된 Make 시나리오는 4~5개 정도로, 이미 상당한 복잡성을 가지고 있습니다.
•
중요 참고사항:
◦
시스템의 복잡성과 사용자의 사용 편의성 사이의 균형을 맞추는 것이 중요합니다.
◦
최종 사용자(특히 현장 인력)의 IT 활용 능력을 고려하여 교육 계획을 수립해야 합니다.
12. 작업일지-물량서브-월간 리포트 관계형 자동화 심화 및 월별 작업 걸침 문제
•
주제: 작업일지 입력 시 목표 공수 서브, 물량 서브를 거쳐 월간 리포트까지 자동으로 관계 맺는 로직 구체화 및 작업이 여러 달에 걸쳐 진행될 경우의 처리 방안 논의
•
핵심 요점:
1.
관계형 자동화 흐름:
•
사용자가 '작업일지'에 데이터를 입력하고 '입력 완료' 버튼을 클릭합니다.
•
1단계: '작업일지'와 '목표 공수 서브'가 관계형으로 연결됩니다. (이때, 작업일지에 동일 작업이 여러 날에 걸쳐 기록될 수 있으며, 각 기록이 '목표 공수 서브'의 해당 항목에 누적 연결됩니다.)
•
2단계: '목표 공수 서브'는 '물량 서브'와 1:1로 연결되어 있으므로, 이를 통해 '물량 서브'의 정보(특히, 총 공사 금액)에 접근합니다.
•
3단계: '물량 서브'의 정보와 '작업일지'의 '작업 날짜'를 기준으로, 해당 월의 '월간 리포트(측정 공수, 실공수)' 항목들과 '물량 서브'를 관계형으로 연결합니다.
2.
월간 리포트 중복 연결 방지:
•
한 작업(예: 1층 B1 재래식 계단)에 대해 '월간 리포트'와의 관계형 연결은 최초 작업일 입력 시 한 번만 이루어지도록 합니다.
•
'목표 공수 서브' 또는 '물량 서브'에 '월간 리포트 연결 상태'와 같은 필드를 두어(예: 연결 전/연결 완료), 이미 연결된 작업은 다시 연결되지 않도록 제어합니다.
3.
작업의 월별 걸침 문제:
•
상황: 작업이 6월 30일에 시작하여 7월 5일에 끝나는 경우, 이 작업의 비용과 물량을 6월과 7월 중 어느 월간 리포트에 귀속시킬지 결정해야 합니다.
•
현재 시스템 동작: '작업일지'에 입력된 '작업 날짜'를 기준으로 월간 리포트에 연결됩니다. 따라서 6월 30일 작업분은 6월 리포트에, 7월 1일 작업분은 7월 리포트에 반영될 수 있습니다. (물량은 최초 작업일 기준으로 한 번만 반영)
•
실무적 유동성: 실제로는 7월 1일 작업했더라도 정산 편의상 6월 30일로 날짜를 조정하여 6월 리포트에 모두 포함시키고 싶을 수 있습니다.
•
제안된 해결책:
◦
'작업일지'의 '작업 날짜' 필드는 총괄이 정산 기준에 맞게 수동으로 수정할 수 있도록 합니다. (예: 실제 7월 1일 작업이나 6월 30일로 입력)
◦
변경된 경우를 추적하기 위해 '실작업 날짜' 필드를 추가하여, 원래 날짜와 변경된 날짜를 모두 기록합니다. 필드 설명에 "월간 리포트 작성으로 인한 날짜 변경 시 기록" 등으로 명시합니다.
4.
물량 배분 문제: 작업이 여러 달에 걸쳐 진행될 때, 총 물량(및 공사 금액)을 작업 진행률에 따라 각 월별로 배분하여 리포트에 반영할 것인지, 아니면 최초 작업 시작 월에 전체 물량을 귀속시킬 것인지에 대한 복잡한 문제가 제기됩니다.
•
현재 시스템은 최초 작업일 기준으로 전체 물량을 한 번만 연결하는 방식입니다. 비율 배분은 훨씬 더 복잡한 로직을 요구합니다.
•
부가 설명:
◦
"이거는 또 체크가 나중에 많이 쌓이면 불가능할 것 같은데." - 수동 조정이 많아지면 관리가 어려워질 수 있음을 우려.
◦
"아, 자, 요건 하면 할수록 사실 아무도 안 하는 이유가 있다. [웃음 소리]" - 시스템 구축의 어려움을 토로.
◦
컨설턴트는 현재 Make 시나리오에서 값 전달 관련 기술적 문제를 겪고 있으며, 이는 별도로 해결할 예정이라고 말합니다.
•
중요 참고사항:
◦
유동성과 시스템화의 충돌: 실제 업무의 많은 '유도리'를 시스템으로 모두 자동화하는 것은 매우 어렵거나 비효율적일 수 있습니다. 어느 수준까지 시스템화하고 어느 부분에서 수동 조정을 허용할지 결정해야 합니다.
◦
데이터 정확성 확보 방안: 날짜 변경과 같은 수동 조정이 발생할 경우, 그 이유와 원래 데이터를 추적할 수 있는 장치를 마련하는 것이 중요합니다.
◦
물량을 월별로 비율 배분하는 것은 현재 논의된 시스템 범위를 넘어설 수 있으며, 추가적인 복잡성을 야기합니다.
13. 직영 작업 처리 및 마무리 논의
•
주제: 일반 도급 작업 외 '직영' 작업의 특성 및 이를 노션 시스템에서 어떻게 처리할지에 대한 논의, 그리고 컨설팅 세션 마무리
•
핵심 요점:
1.
직영 작업의 특성 (엑셀 기준):
•
주로 공수 기준으로 정산되며, 사전에 예측하기 어려운 돌발적인 작업(잔일 등)이 많습니다.
•
물량이 작업 중 계속 늘어날 수 있어 월별 정산 시 해당 직영 작업을 찾아 공수를 합산하는 방식이 복잡합니다.
•
엑셀에서는 연간 누적 방식으로 관리하거나, 월별로 해당 월의 직영 공수만 집계하여 처리하기도 합니다.
•
건설사에서는 직영을 선호하지 않는 경향이 있으며, 때로는 직영 비용을 기존 도급 물량의 단가 조정으로 처리하기도 합니다.
2.
노션에서의 직영 처리 방안:
•
'작업일지' 데이터베이스에 작업 유형을 선택하는 필드(예: 도급, 직영, 지원 등)를 두어 직영 작업을 구분합니다.
•
직영 작업도 일반 작업과 마찬가지로 '작업일지'에 입력되면, 설정된 로직에 따라 '월간 리포트'에 반영될 수 있습니다.
•
직영 작업으로 인해 추가되는 금액이나 공수는 해당 월의 리포트에 합산될 것입니다. 별도의 복잡한 DB 구조 변경 없이 처리가 가능할 것으로 예상됩니다.
3.
물량 서브의 작업 기간 표시: '물량 서브' 항목이 실제 언제부터 언제까지 작업되었는지 표시하는 것은 현재로서는 불필요하다고 판단되어 넘어갑니다. (총괄은 목표 공수에서 확인)
4.
Make 시나리오 디버깅: 컨설턴트는 앞서 발생한 Make 시나리오의 값 전달 오류(첫 번째 작업일 이후 관계형 상태 업데이트 문제)를 별도로 확인하고 수정하기로 합니다.
5.
자사 프로그램 개발 관련 질문: 고객사에서 자체적으로 개발 중인 프로그램이 현재 노션으로 구축하는 시스템과 유사한 데이터베이스 구조를 가질 가능성에 대해 질문합니다. 컨설턴트는 사스(SaaS) 형태의 프로그램이라면 유사한 기반으로 설계될 수 있다고 답변합니다.
•
부가 설명:
◦
직영 작업은 예측 불가능성과 유동성이 크지만, 노션에서는 '작업일지'의 한 유형으로 처리하여 기존 시스템 흐름에 통합할 수 있을 것으로 보입니다.
◦
컨설팅 과정에서 많은 암묵지가 드러나고 이를 시스템화하는 과정의 어려움에 대해 서로 공감합니다.
•
중요 참고사항:
◦
직영 작업의 특성을 고려하여, '작업일지' 입력 시 필요한 정보를 명확히 기록하도록 가이드해야 합니다.
◦
시스템 구축은 반복적인 테스트와 디버깅 과정을 통해 안정화됩니다.
•
향후 일정:
◦
다음 컨설팅은 내일 모레 1시에 진행.
◦
23일은 오프라인, 24, 25일은 온라인으로 진행 예정.
