현장성은 GPS 두 칸으로 검증된다 — BBS의 작은 디테일들이 만드는 신뢰

BBS 운영을 도와본 사람이라면 한 번쯤 듣는 질문이 있습니다.

이 관찰, 책상에서 만든 거 아니에요?

월말이 다가오면 관찰 건수 목표가 부족한 관찰자들이 사무실에 앉아 카드를 채워서 제출합니다. 사진이 있어도, 어제 다른 라인에서 찍은 걸 갖다 붙입니다. 카드만 보면 진짜 관찰과 구별이 안 됩니다.

책상 BBS 가 늘어나는 사업장의 BBS 통계는 무의미해집니다. SAFE 비율이 95% 인데 사고는 그대로 납니다. 데이터가 거짓말을 하면 데이터 기반 안전 관리 자체가 무너집니다.

그래서 우리는 가장 단순한 한 가지를 박았습니다.

class BbsObs(Base):
    start_latitude  = Column(Float, nullable=True, comment='관찰 시작 위도')
    start_longitude = Column(Float, nullable=True, comment='관찰 시작 경도')
    end_latitude    = Column(Float, nullable=True, comment='관찰 종료 위도')
    end_longitude   = Column(Float, nullable=True, comment='관찰 종료 경도')

관찰을 시작 한 시점의 위경도와, 제출 한 시점의 위경도. 두 좌표를 같이 박은 이유는 둘 다 의미가 있기 때문입니다.

• 시작 좌표가 사업장 밖 이면 → 사무실/집에서 시작한 관찰입니다.
• 시작과 종료 좌표가 동일 하면 → 한 자리에 앉아 12개 행동을 다 평가한 관찰입니다. “걸어 다니며 본 관찰” 이라면 좌표가 조금이라도 움직여야 정상입니다.
• 두 좌표 사이 거리가 사업장 반경의 두 배 이상 이면 → 차로 이동하면서 채운 관찰입니다.

좌표가 거짓말을 막지는 않습니다 — GPS 도 조작 가능하니까요. 다만 조작에는 의도가 필요하다 는 점이 중요합니다. 그냥 책상에 앉아 카드를 채우면 GPS 가 자연스럽게 사무실을 가리킵니다. 의도하지 않으면 거짓말이 안 되는 구조가 만들어지면, 대부분의 책상 BBS 는 그 자체로 드러납니다.

GPS 의 짝은 현장 사진 입니다. 각 행동에는 BbsObsBehaviorAttachment 가 1:N 으로 붙습니다. 사진/동영상이 어느 시점에 찍혔는지 의 EXIF 가 살아있으면, 관찰 시각과 사진 시각이 얼마나 어긋나는지 보입니다. 1시간 어긋난 사진은 재사용한 사진 일 가능성이 높아요.

이런 검증은 사람이 손으로 하기에는 너무 잡일이라, 통계 화면 한 켠에 “신뢰도 의심 관찰” 이라는 뷰가 따로 있습니다. 관리자가 의심스러운 관찰만 모아서 보고, “이 관찰자는 책상 BBS 의심이 높습니다” 라는 시그널이 자연스럽게 떠오릅니다. 처벌이 아니라 코칭(BbsCoachCard) 의 대상이 됩니다.

BBS 데이터가 흘러가는 통계 화면(bbs/overview) 은 4축으로 잘립니다.

• 사업장 (org_site)
• 팀 (org_site_team)
• 영역 (org_site_area)
• 위치 (org_site_area_location)

이 4축이 obs_behavior 의 7개 ID 컬럼 + 7개 permanent_id 컬럼 위에서 그대로 떨어집니다. 카드 12개짜리 overview 대시보드는 각 카드가 “어느 축의 어느 노드를 그룹핑 했는가” 의 조합입니다.

통계는 위로 올라갈수록 더 보이지만, 권한은 위로 올라갈수록 더 닫힙니다.

권한은 같은 계층을 역방향 으로 씁니다. 토큰의 org_id 와 조회 대상 org_site 의 org_id 가 다르면 403. 매니저는 자기 팀까지만, 사이트 매니저는 자기 사업장까지만. 둘이 정확히 반대 방향으로 작동하기 때문에 “필요 이상으로 보면 안 되는 데이터” 가 자연스럽게 잘립니다.

BBS 가 관찰만으로 끝나는 회사는 BBS 가 죽습니다. 데이터가 다음 흐름으로 이어져야 합니다.

BBS 관찰
   │
   ├──→ 후속조치 (common/action)
   │      need_action=True 인 행동이 ActionActivity 출처가 됨
   │      (polymorphic source_module=BBS_OBS_BEHAVIOR)
   │
   ├──→ AI 패턴 분석 (bbs/ai)
   │      조직/사업장/팀/영역/위치 + 멤버별 행동 패턴 AI 요약
   │
   ├──→ 매니저 개인 대시보드 (bbs/my_activity)
   │      "내 관찰", "내 팀 평균", "부서 평균과 나의 차이"
   │
   └──→ 사업장 종합 대시보드 (bbs/overview)
          12 카드의 사업장 운영 현황

common/action 으로의 연결이 가장 결정적입니다. 불안전 행동 발견 → 시정조치 → 효과성 검증 → 재조치 의 사슬은 부적합 시리즈에서 이미 자세히 풀었지만, 그 사슬의 입구 한 곳이 BBS 입니다. “BBS 가 발견을 만들고, action 모듈이 끝맺기를 만든다” — 두 모듈이 polymorphic source 한 쌍으로 연결됩니다.

bbs/my_activity 의 매니저 개인 대시보드 도 인상적입니다. 같은 데이터를 조직 단위 로 묶은 게 bbs/overview 라면, 본인 단위 로 묶은 게 bbs/my_activity 입니다. 두 sub-module 은 자체 테이블이 없습니다. cross-module aggregator 라서 service + schema 만 있고 model 폴더가 없어요. “테이블이 없는 모듈” 이 도메인 모듈로 정당하다는 것 — 책임 경계가 다르면 모듈이 갈라진다는 원칙의 한 형태입니다.

1. PART 01

   카드를 마스터/사업장/관찰 3단으로 쪼개고, 관찰은 카드를 ‘복사’ 한다

2. PART 02

   행동 한 줄에 40 컬럼을 둔 진짜 이유는 ‘그때 그 조직과 그때 그 위험등급’의 보존이다

3. PART 03

   피드백은 AI 초안과 사람이 실제 전달한 한마디를 두 컬럼으로 분리한다

4. PART 04

   GPS 두 줄과 사진 EXIF 가 ‘책상 BBS’ 를 자연스럽게 드러내고, 데이터는 action/AI/대시보드로 흐른다