2026-11-12 (목)¶

오늘 요약 - 번호 체계가 다른 두 원천의 같은 대상을 공통 속성(PNU 등)으로 잇고 다른 속성으로 다시 확인하는 엔티티 매칭을 4번 물어서야 실제 데이터로 이해했다. - 젬마 도구 호출 실패는 파서·모델·우리 스키마 세 군데 책임이 섞여 있다는 것을 알았다. - Ansible은 절차형, OpenTofu는 선언형이라는 차이와 DE-9IM, HTTP 요청으로 파일 받기도 새로 알았다.

🗂️ 오늘의 세션 (8개)¶

시간	프로젝트	무엇을 했나
09:26~18:19	Dtonic	(기술 질문 없음) 학습 일지 예약 실행 점검·웹 보기
09:44~14:45	재난 과제	침수 시나리오용 데이터 정리·전달
11:57~11:57	전체	(기술 질문 없음) 추가 수집 데이터 질문(답 없음)
12:54~14:00	Dtonic	(기술 질문 없음) Loop 회의록 템플릿 자동화 검토
14:57~17:47	dhub2-manager	젬마 어시스턴트 실패 원인 분석
15:16~15:43	산출물	1단계 평가 발표자료 검토
15:47~16:25	disaster-dashboard	(기술 질문 없음) 동기화 기준을 태그→필드로
17:57~18:06	dhub2	dhub 설치 지식·앤서블과 토푸 차이

🛠️ 오늘 한 작업¶

1. 학습 일지 예약 실행 점검 (Dtonic · 09:26~18:00)¶

배경: 어제 만든 학습 일지 자동 실행이 제대로 돌지 확인이 필요했다.
진행:
로그아웃 후 재로그인만으로 충분한지 확인 → 충분하다는 답, 재시작 반영 확인
일지 저장소를 ~/Desktop/개인 아래에 바로가기로 연결
자동 fetch·pull은 로컬이 늘 최신이라 필요 없다고 정리
18시에 예약 실행이 정상적으로 시작됐는지 확인
결과: 18:00:05에 예약 실행이 정상 시작됐다.

2. 침수 시나리오용 재난 데이터 정리·전달 (재난 과제 · 09:44~14:45)¶

배경: 침수 시나리오를 다시 테스트하려는 쪽에서 데이터 전달 요청이 왔다. 이전에 모은 데이터와 dhub 파이프라인 수집분을 합쳐 정리해야 했다.
진행:
재난 컬렉션 파이프라인 18개 중 침수 원천 직접 수집이 4개임을 파악하고, 이전 수집본 143종과 겹치는 원천(34종, 침수 9종)을 대조 → 침수 관련은 중복을 합쳐 68종
리서치로 새 침수 원천 약 50종을 추가로 찾음
전달 기준을 정함: 데이터셋·파이프라인이 꼭 있을 필요 없이 API로 받아 CSV로 저장하면 됨. 무리 없는 기간만 받고 엑셀에 기간을 명시
신규는 OpenAPI로 받은 것만 남기자 침수가 68→29종으로 줄었는데, 이걸 미리 말하지 않아 혼선 → 전체에서 침수 관련 17종을 더 옮겨 46종
파일 원천은 파이프라인으로 주기 수집은 되지만 CSV 파싱까지는 안 되므로 제외하기로 함
데이터 목록.xlsx 작성: "수집 기간"은 받은 날이 아니라 데이터가 담고 있는 기간. 데이터 유형·침수 열은 빼고, 이전/신규 구분도 없앰
지역 구성은 강남구 기준으로 했다가, 최종적으로 폴더를 평탄화하고 서울시 단위 데이터에 "(서울시 기준)"을 붙이는 방식으로 바꿈
1개월이 안 되는 34종 중 채울 수 있는 것은 2026-06-11~07-10으로 맞춤(하수관로 수위는 10분 간격), 강우량 과거분은 파일로 채움
README에서 로컬·내부 사정 정보를 모두 지우고 최상위 README는 엑셀 "작성 기준" 시트로 옮김. 안내 문구 작성, 윈도우용 zip 생성
결과: 전체 172종(이전 대비 +29종), 그중 침수 46종을 별도 폴더에 복사. zip(182MB)과 안내문 준비 완료. dhub 파이프라인으로는 최대 약 170종을 수집할 수 있고, 지금 키로 바로 추가 가능한 것은 87종.

3. Loop 회의록 템플릿 자동화 검토 (Dtonic · 12:54~14:00)¶

배경: 매주 회의 후 다음 주 Loop 템플릿을 사람이 만들고 있어 자동화를 원했다.
진행:
Loop은 페이지 내용을 프로그램으로 쓰는 공식 수단이 거의 없다는 점 확인
제목(주차)은 Power Automate에서 날짜로 계산해 템플릿 파일 복사 시 이름으로 쓰는 방안 제시
실제 방식이 "Loop 앱에서 바로 페이지 생성 + 템플릿 적용"이라 Power Automate 방식은 쓸 수 없음이 드러남
결과: 방향을 다시 골라야 하는 상태로 멈춤.

4. 젬마 어시스턴트 실패 원인 분석 (dhub2-manager · 14:57~17:47)¶

배경: 젬마로 앱·대시보드가 안 되는 문제를 일부만 고치는 게 아니라 모든 리소스가 되게 하고 싶었다.
진행:
재현 기록의 실패 13건을 "마지막에 막힌 원인"별로 분류 → 타입 문제(#3561)만 고쳐서는 대시보드가 해결되지 않음
할 일 4가지 정리: 타입 되돌리기, 남은 <|"|> 표기 풀기, 문자열 plan 풀기, 승인 시 제안 번호만 받기. 2번 처리는 이미 됐다고 생각했지만 main에 코드가 없음을 확인
개발 클러스터 어시스턴트 로그 확인 → 새 증상(코드 줄바꿈이 \n 두 글자) 발견
젬마 공식 채팅 템플릿을 보고 책임을 나눔: 숫자 문제는 파서, 줄바꿈 문제는 모델
근본 원인 조사: vLLM v0.24부터 생긴 버그, 수정 PR은 리뷰 없이 닫힘. 우리 payload가 타입 없는 객체라 그 버그에 그대로 노출됨
재난 컬렉션에서 대시보드·앱 요청 4번 재테스트 → 대시보드 1번만 승인 카드까지 성공, 그것도 운(계획을 똑같이 베껴 씀)
결과: 원인 구조는 정리됐고, #3561 수정 + 승인 시 제안 번호만 받기 두 가지를 하면 이번 실패 3건의 원인이 사라진다. 코드 수정은 아직.

5. 1단계 평가 발표자료 검토 (산출물 · 15:16~15:43)¶

배경: 재난안전AI 1단계 평가 발표자료 초안에서 디토닉 담당 칸(29·52·53번)에 틀린 부분이 있는지 봐 달라는 요청.
진행:
협약 계획서·단계보고서·1차년도 산출물과 수치·표현 대조
"원천 간 대응표", "위치 정밀도 구분", DE-9IM 등 슬라이드 용어의 뜻과 실제 구현 여부 확인 → 대응표·DE-9IM·H3 모두 설계 단계이고 D.Hub 파이프라인엔 미적용
"식별자 매칭 83건"은 대응표 전체가 아니라 번호가 똑같았던 한 쌍의 결과 → "번호 일치 83건 실측 확인"으로 고치는 것을 확정 수정 1번으로 기록
2·3페이지는 연구계획이라 크게 바꿀 게 없다고 판단
결과: 수정 목록(확정 1건, 후보 8건)을 memory 파일에 모아 둠. pptx는 아직 고치지 않음, 나중에 한 번에 반영 예정.

6. 대시보드 동기화 기준을 태그→필드로 변경 (disaster-dashboard · 15:47~16:25)¶

배경: 남은 일 중 "동기화 기준 태그" 작업. 개발 환경에서는 태그를 너무 쉽게 바꿀 수 있어 태그와 무관하게 동기화되길 원했다.
진행:
현재는 normalized_at 하나가 아니라 정규화 태그 + 공통 열 8개를 둘 다 본다는 점 확인
normalized_at 하나만 보기보다 공통 열 8개 전부를 보는 쪽이 낫다고 판단해 태그 조건 제거
H3 동기화 파이프라인을 거치면 공통 열이 반드시 전부 생긴다는 것을 코드로 확인
작업 내역을 feat/auth-poc 브랜치에 커밋 6개로 나눔(푸시 안 함)
남은 "시맨틱화(use_llm 범주 정규화)"는 사건 텍스트를 분류할 필요가 있는지 의문이라 보류로 메모. category에 값이 있는 건 사건 모양 5개뿐이고 나머지는 attrs JSON에 남아 있음을 확인
결과: 태그를 바꿔도 동기화 결과가 같고 대시보드의 20개도 예전과 같음. 시맨틱화는 보류.

7. dhub 설치 업무에 필요한 지식 (dhub2 · 17:57~18:06)¶

배경: dhub를 판매하면 현장 설치를 해야 하는데, 앤서블 플레이북 명령만 알면 되는지 궁금했다.
진행:
명령 한 줄은 현장 준비와 인벤토리 작성이 끝난 뒤의 마지막 단계라는 답
이 업무를 계속하면 어떤 지식이 늘지 물음 → 플레이북만 돌리면 반복이고, 막힐 때 원인을 파고들어 설치기에 반영하면 인프라·플랫폼 경력이 된다는 답
앤서블과 토푸의 차이를 물음 → 절차형 vs 선언형. 이 저장소는 인터넷 되는 현장은 ansible, 폐쇄망은 tofu이고 tofu로 옮기는 중
설치하며 생긴 문제를 파악해 수정한 이력이 저장소에 있는지도 물음
결과: 필요한 지식 영역(현장 분류, Linux·K8s, 스토리지 등)과 두 도구의 차이를 정리받음.

8. 학습 일지 웹 보기 검토 (Dtonic · 18:10~18:19)¶

배경: 일지 요약이 만족스러워서, GitHub 앱 대신 웹으로 만들어 보면 어떨지 궁금했다.
진행:
웹으로 만들면 나아지는 점은 있지만 어디에 올리느냐에 따라 공개 범위가 달라져 그것부터 정해야 한다는 답
비용은 0원이라는 답(요금 기준은 가입할 때 다시 확인)
로컬 미리보기 서버를 띄워 화면을 확인
결과: 로컬 미리보기까지 봄. 어디에 올릴지(공개 범위)는 아직 정하지 않음.

🔧 오늘 해결한 문제¶

1. 젬마 도구 호출 인자가 깨져 앱·대시보드 생성 실패 (→ 작업 4)¶

증상: 젬마로 앱·파이프라인 요청 시 422 The assistant repeated a failing tool call., 대시보드는 plan does not match plan_hash로 글로만 답함
원인 → 해결: vLLM v0.24 젬마 파서가 타입 정보를 버려 숫자가 문자열이 되고(타입 없는 payload가 이를 노출), 젬마가 코드 줄바꿈을 \n으로 쓰며, 승인 때 계획을 다시 써서 지문이 어긋남. 원인만 규명, 수정(타입 되돌리기·제안 번호 승인·조건부 줄바꿈 보정)은 아직.
👉 vLLM Gemma 도구 인자 문자열 변환으로 422 실패

🧠 부족했던 개념¶

1. 데이터 원천 간 엔티티 매칭 · 🔁 4번 물음¶

어떻게 드러났나: 발표자료 검토 중(→ 작업 5) "원천 간 대응표가 뭐냐"로 시작해, "번호가 다른데 같은 건물인 건 어떻게 알았냐", "실제 데이터로 보여 달라", "FMS랑 건축물대장은 어떻게 잇냐"로 4번 바꿔 물었다.
헷갈린 점: 번호(식별자)가 다르면 같은 대상인지 알 방법이 없다고 생각했다. 또 83건이 "번호가 다른데 맞춘 것"이라고 오해했는데, 실제로는 번호가 똑같았던 경우였다.
핵심: 시스템마다 ID 체계가 다르면 양쪽에 공통으로 있는 다른 속성(필지번호 PNU, 위치, 이름)으로 짝을 짓고, 다른 속성(사용승인일·면적·층수)으로 다시 확인한다.
근거의 확실도에 따라 등급을 매긴다: A 식별자 일치 > B PNU 일치 > C 위치 근접·이름 유사 > D 참고. 결과는 원본을 건드리지 않고 별도 대응표에 기록한다.
함정: PNU가 같아도 재건축, 한 필지 여러 동, 교량·역처럼 건물이 아닌 시설은 다른 대상일 수 있다. 공통 키가 없으면 중간 원천을 다리로 건너간다.
👉 데이터 원천 간 엔티티 매칭

2. LLM 도구 호출 형식과 출력 파서 · 🔁 2번 물음¶

어떻게 드러났나: 젬마 실패 원인을 보던 중(→ 작업 4) "결국 젬마 파서 문제냐", "우리 문제가 아닌 거냐, payload를 any로 둔 우리 잘못 아니냐"를 물었다.
헷갈린 점: 책임이 파서 하나에 있거나, 아니면 우리 쪽에 있다는 둘 중 하나로만 봤다. 실제로는 오류마다 책임이 달랐다.
핵심: 모델은 정해진 형식(Claude는 JSON, 젬마는 <|"|>로 감싼 자체 표기)으로 인자를 쓰고, 서빙 쪽 파서가 이를 JSON으로 바꾼다. 이 변환에서 정보가 사라질 수 있다.
숫자가 문자열로 온 건 파서가 타입을 버린 것, \n이 글자로 온 건 모델이 자기 형식을 어긴 것이다.
파서는 도구 스키마에 타입이 적힌 곳만 되돌려 주므로, 스키마를 타입 없는 객체로 두면 버그에 그대로 노출된다. 단 anyOf 안까지는 따라가지 않아 타입을 적는 방식도 중요하다.
👉 LLM 도구 호출 파서와 타입 복원

3. 인프라 자동화 도구: Ansible과 OpenTofu · 🔁 2번 물음¶

어떻게 드러났나: dhub 현장 설치 업무를 생각하다가(→ 작업 7) "앤서블 플레이북 명령(또는 tofu)만 쓰면 되는 거 아니냐"고 물었고, 이어서 "앤서블과 토푸의 차이가 뭐냐"를 따로 물었다.
헷갈린 점: 자동화 도구가 있으면 설치는 명령 한 줄이라고 생각했다. 두 도구도 이름만 알고 어떻게 다른지는 몰랐다.
핵심: Ansible은 "무엇을 순서대로 할지"를 YAML로 적는 절차형이다. 상태를 기억하지 않고, 매번 작업마다 "이미 돼 있나"를 확인한다. 주 용도는 서버 설정.
OpenTofu는 "최종 상태"를 HCL로 적는 선언형이다. state 파일에 만든 것을 기록하고, plan으로 차이를 미리 본 뒤 차이만 적용한다. 선언에서 빼면 지운다. 주 용도는 인프라 생성.
비유: Ansible은 레시피 따라 하기, Tofu는 완성 사진과 비교해 빠진 것만 채우기. Tofu는 Terraform이 라이선스를 바꾼 뒤 갈라진 오픈소스판이라 사용법이 거의 같다.
어느 도구든 입력(인벤토리·플레이북·시크릿)은 고객마다 새로 써야 하고, 그 전에 현장 분류(인터넷 여부·DNS·VIP·GPU)가 먼저다. 명령은 일의 10% 정도다.
👉 인프라 자동화와 설치 현장 지식

4. HTTP 요청으로 파일 다운로드 자동화¶

어떻게 드러났나: 침수 데이터 정리 중(→ 작업 2) "파일은 브라우저로 직접 받아야 하는 것 같은데 파이프라인은 어떤 원리로 가져오냐"고 물었다.
헷갈린 점: 파일 다운로드는 사람이 버튼을 눌러야 하는 일이라고 생각했다.
핵심: 다운로드 버튼도 결국 HTTP 요청이다. 코드가 같은 요청(페이지 HTML에서 파일 키를 뽑고 다운로드 주소 호출, 또는 화면이 쓰는 내부 API 호출)을 보내면 자동화된다.
받은 파일의 키(파일명·수정일·첨부 ID)를 수집 기록에 남겨 바뀐 것만 다시 받는다.
한계: 공식 API가 아니라 사이트 개편 시 예고 없이 깨지고, 로그인·신청이 필요한 자료는 못 받는다.
👉 HTTP 요청으로 파일 다운로드 자동화

5. DE-9IM 공간 관계 판정¶

어떻게 드러났나: 발표자료 2페이지를 보다가(→ 작업 5) "DE-9IM은 뭐냐"고 물었고, 이어서 실제 파이프라인에 적용됐는지도 물었다.
헷갈린 점: 용어 자체를 몰랐고, H3와 어떤 관계인지도 몰랐다.
핵심: 두 도형의 관계(포함·교차·접촉·분리)를 판정하는 OGC 국제 표준 모델. 도형을 내부·경계·외부로 나누고 3×3=9칸의 교차 여부로 관계를 정한다. PostGIS ST_Relate, Shapely 등이 이 방식이다.
H3와 2단계로 쓴다: 격자로 후보를 빠르게 거른 뒤, 남은 후보만 DE-9IM으로 정밀 판정한다(속도와 정확도 둘 다).
👉 DE-9IM 공간 관계 판정

6. 로그 스트리밍과 -f 옵션¶

어떻게 드러났나: 젬마 재테스트를 백그라운드로 돌리는 동안(→ 작업 4) "log -f 뜻이 뭐냐"고 물었다. 그때 답은 테스트 결과 정리로 넘어가서 -f 설명은 받지 못했다.
헷갈린 점: 로그 명령에 붙는 -f의 의미를 몰랐다.
핵심: -f는 follow. 로그를 한 번 출력하고 끝내지 않고, 새 줄이 생길 때마다 계속 이어서 보여 준다(tail -f, kubectl logs -f, docker logs -f). 멈출 때는 Ctrl+C.
👉 로그 스트리밍과 -f 옵션

🩹 오늘 드러난 약점¶

추상 설명으로는 매칭 원리가 안 잡힌다 — 근거: 엔티티 매칭을 4번 바꿔 묻고, 실제 데이터 표를 보고서야 이해함 → 다음에: 처음부터 "실제 행 두 개를 나란히 보여 줘"라고 요청한다.
문서의 설계 용어와 실제 구현을 구분하지 못한다 — 근거: 대응표·DE-9IM·H3가 파이프라인에 있는지 매번 따로 물음 → 다음에: 발표 문구마다 "구현됨 / 설계만"을 먼저 표시해 두고 본다.
원인을 한 곳으로 몰아서 본다 — 근거: "결국 파서 문제냐", "우리 잘못 아니냐"처럼 이분법으로 물음 → 다음에: 생성(모델)→변환(파서)→검증(우리) 단계별로 어디서 정보가 사라졌는지 나눠 본다.
인프라·운영 도구 기초가 비어 있다 — 근거: -f 옵션, Ansible과 Tofu의 차이, 자동화 도구가 해 주는 범위를 물음 → 다음에: 이 저장소의 ansible role 하나와 tofu .tf 하나를 나란히 읽고, kubectl·tail 옵션은 직접 쳐 본다.

🧪 복습 퀴즈¶

1. 두 데이터의 PNU(필지번호)가 같으면 같은 건물로 묶어도 될까?

답 보기

안 된다. 재건축으로 건물이 바뀌었거나, 한 필지에 건물이 여러 동이거나, 교량·역처럼 건물이 아닌 시설이면 다른 대상이다. 사용승인일·면적·층수 같은 다른 속성으로 다시 확인해야 한다.

2. 젬마 도구 호출에서 숫자가 문자열로 온 문제와, 코드 줄바꿈이 \n 두 글자로 온 문제는 각각 누구 책임인가?

답 보기

숫자 문제는 형식대로 쓴 값을 파서가 타입을 버리고 읽은 것이라 **파서**. 줄바꿈 문제는 젬마 형식에 없는 `\n` 표기를 모델이 JSON 버릇대로 쓴 것이라 **모델**. 타입 없는 `payload` 스키마는 숫자 문제에 노출되게 만든 우리 몫이다.

3. 리소스 하나를 설정에서 지우고 다시 실행하면, Ansible과 OpenTofu는 각각 어떻게 동작할까?

답 보기

Ansible은 상태를 기억하지 않아 그 작업을 그냥 건너뛸 뿐, 이미 만든 것은 남는다(지우는 작업을 따로 적어야 한다). OpenTofu는 state와 선언을 비교해 빠진 리소스를 **알아서 지운다**(`plan`에서 미리 보임).