본문 바로가기

전체 글

 (111)
JSON Schema 런북 출력이 숫자만 남을 때 — expect 제한을 400자로 늘리기 명령 출력의 라벨과 실패 후 확인 경로가 70자 제한으로 잘리던 문제를 재현 필드 상한 확대와 wrongFirst 구조 추가로 고쳤다. 처음 생성된 런북을 열었을 때 기대 출력에는 `37 50.6 731.8`처럼 라벨 없는 숫자만 남아 있었고, 명령이 실패한 뒤 어디를 확인해야 하는지도 알 수 없었다.전제 환경 — JSON Schema / Python 3 / HTML한 줄 답 — 런북의 실제 출력이 잘린 원인은 `expect`를 산문처럼 70자로 제한한 것이었고, 출력 상한을 400자로 늘리고 산문 총량 검사를 분리해 해결했다.화면에 이렇게 찍혔다면가치가 별로 없는 콘텐츠어떻게 얽혀 있나런북 생성과 출력 손실 지점[작업 노트] ↓[LLM 구조화 출력] ↓[필드별 글자 수 제한] ├─ ex..
업무 문서에 없는 사실을 그럴듯하게 채워 넣는 이유 그럴듯하게 채우기 전에, 실제로 본 자리를 살핀다. · AI 생성 일러스트빈칸을 견디기 어려울수록 추론은 기록의 얼굴을 하고 들어온다. 나는 처음에 결과가 어색하면 요구를 더 세게 쓰면 된다고 생각했다.‘사람답게’ 같은 말에 힘을 주면 글도 그쪽으로 움직일 것 같았다. 그러나 강한 형용사는 기준이 아니었다. 무엇이 어색했는지 보지 않은 채, 느낌에게 일을 맡긴 셈이었다.그다음에는 원래 적힌 값에서 구할 수 있는 내용이라면 문서에 넣어도 된다고 여겼다. 계산이 맞다는 사실이 그 결과를 실제로 보았다는 뜻은 아닌데, 머릿속에서는 둘이 쉽게 붙었다. 답을 낼 수 있다는 능력이 답을 확인했다는 이력으로 바뀐 것이다."계산은 맞는데, 이게 실제로 나온 건 아니잖아요." 업무 문서의 빈칸은 이상할 만큼 사람을 부지..
LIMIT 6 집계 비용 분리 런북 넓은 조인 집계를 두 컬럼 집계로 분리하고 SQL 구조를 고정한다. 최근 6건만 반환하는 대시보드가 2초 이상 걸린다. LIMIT을 적용해도 집계 SQL과 디스크 읽기가 줄지 않는다.전제 환경 — Django ORM · Django 테스트 클라이언트 · 데이터베이스 EXPLAIN요약운영 요청별 시간과 쿼리 수부터 측정최근 ID 확정과 하위 집계를 분리상위 테이블 없는 두 컬럼 집계 적용목록 상태 카운트를 일괄 조회결과값과 SQL 구조를 함께 회귀 검사전체 그림LIMIT 이후에도 남는 집계 비용[인증 요청] |[최근 ID 6개] | +--> [상위+하위 넓은 조인] --X--> [GROUP BY·임시 파일] | +--> [하위: parent_id,status] --> [..
원래도 그랬어요 처음 붙은 설명 아래에는 아직 불리지 않은 사실이 남아 있다. · AI 생성 일러스트 처음 나는 규칙이 움직이지 않는 이유를 재료가 들어오지 않았기 때문이라고 보았다. 비어 있다는 설명은 손에 잘 잡혔고, 이미 채워진 칸을 다시 살피는 일보다 마음도 덜 복잡했다. 원인이 입구에 있으면 그 뒤의 과정은 무죄가 된다.실제 기록을 확인하자 내가 세운 설명은 금세 힘을 잃었다. 필요한 것은 이미 제자리에 있었고, 옮겨지는 도중 몇몇 내용이 빠지고 있었다. 나는 없는 것을 찾느라, 있던 것이 어디에서 사라지는지는 뒤늦게 물었다.처음의 판단은 엉성한 추측만은 아니었다. 직장에서는 빠진 재료가 문제였던 일이 자주 있었고, 익숙한 원인은 다음 사건에도 먼저 출근한다. 다만 경험이 길을 알려 주는 순간, 다른 길을 가리..
아직 바깥에는 안 갔어요 내 손을 떠난 일은 여러 경계를 지나며 비로소 완료의 모양을 얻는다. · AI 생성 일러스트완료는 내 손을 떠난 뒤에 드러난다 나는 손을 댄 내용이 제자리에 있고 점검도 무사하면, 사람들이 보는 결과도 이미 달라졌다고 여겼다. 내 손끝에서 끝난 일이 바깥에서도 끝났으리라는, 꽤 단정한 착각이었다. 완료라는 말이 내 책상 둘레만 돌고 있다는 사실은 늦게 보였다.내가 확인한 것은 내가 만든 것의 상태였고, 확인하지 않은 것은 그것이 실제로 쓰이는 자리였다. 둘은 가까워 보여서 자주 같은 것으로 취급된다. 서류에 도장을 찍은 순간과 그 서류가 상대의 손에 들어간 순간을 한 칸에 적는 셈이었다.예전 결과가 그대로 남아 있는 것을 보고서야 나는 완료의 경계를 너무 안쪽에 그었다고 판단했다. 손을 놓은 지점이 곧 ..
AI 런북을 숫자 계약으로 교정하는 법 필드 상한과 기대 출력 검사를 생성 후 계약으로 고정한다. 9개 섹션은 맞지만 결과가 긴 기술 에세이처럼 보인다. 기대 출력에 관측값 대신 성공 조건이 적힌다.전제 환경 — n8n / Python 3 / JavaScript / HTML구조런북 생성과 숫자 계약 검사 흐름[작업 기록] | v[LLM 런북 생성] --X temperature: 0.4 | v[9개 섹션 구조화] | v[HTML 렌더링] | v[글자 수 검사] --X 상한 초과 | v[기대 출력 검사] --X 한다/된다 | v[저장]정리하면temperature: 0.4 제거프롬프트를 5.7KB로 축소필드별 글자 수 상한 적용서술형 기대 출력 차단3회 연속 형태..
문은 같아도 같은 표면 아래에는 서로 다른 역할과 남겨야 할 흔적이 있다. · AI 생성 일러스트닮은 표면이 판단의 방향을 훔칠 때“둘 다 비슷하게 생겼으니, 하는 일도 같지 않을까요?” 나는 나란히 놓인 대상이 같은 몫을 나누어 맡는다고 먼저 여겼다. 드나드는 입구가 같고 겉에 붙은 표식도 비슷했으니, 차이보다 대칭이 먼저 눈에 들어왔다. 판단은 이미 그 순간 절반쯤 끝나 있었다.지나간 변경의 기록을 거슬러 보니 하나는 단순한 짝이 아니었다. 별도의 필요가 생겼을 때 뒤늦게 보태진 자리였고, 닮은 외관은 서로 다른 사정을 가리고 있었다. 나는 현재의 모양을 과거의 의도라고 잘못 읽었다.처음부터 무모하게 짐작한 것은 아니었다. 눈앞의 단서들을 성실히 묶었지만, 묶는 방식이 너무 반듯했다. 비슷한 것은 같은 것이라는 ..
승인은 됐는데 먼저 붙인 이름을 걷어 내자 서로 다른 문턱과 새로운 길이 보인다. · AI 생성 일러스트먼저 붙인 말이 판단의 길을 좁힌다 처음 세운 문턱은 통과할 자격을 가려내려다, 아직 심사받을 차례조차 오지 않은 것까지 밀어냈다. 나는 엄격함이 안전과 같은 말이라고 먼저 믿었다. 그러나 넓게 닫힌 문은 위험뿐 아니라 정상적인 시작도 막았다.잘못은 조건을 빠뜨린 데만 있지 않았다. 나는 일이 도착하는 순서보다 마지막에 갖춰야 할 모양을 먼저 보고 있었다. 완성된 모습에서 출발하니, 덜 갖춰진 시작은 모두 결함처럼 보였다.먼저 떠오른 판단에는 묘한 선점 효과가 있다. 빈 종이에 처음 그은 선처럼 이후의 확인을 그 방향으로 정렬한다. 일하는 사람은 사실을 찾는 동안에도, 이미 고른 설명에 어울리는 사실을 더 빨리 알아..

티스토리툴바