AI에게 코드를 시키는 일과
AI를 운용하는 일은
다른 문제입니다.

무엇을 만들었나

센서 1,000대  매장 20곳 출입구 · 들어옴(in)과 나감(out)을 따로 보고한다
  │
  ▼
MQTT 브로커  메시지를 받아 나눠주는 우체국. 외부 서버 없이 앱 안에 넣었다
  │
  ▼
수집        같은 사건이 두 번 오면 한 건으로 접고, 시각·값이 이상하면 격리한다
  │
  ▼
저장        SQLite · 묶어서 쓰기 · 오래된 건 요약본으로 접고 지운다
  │
  ▼
판정        조용해진 센서 · 불가능한 값 · 권한 · 알림을 어디까지 올릴지
  │
  ├─ 대시보드   매장별 상태와 추이를 한 화면에 (패널 10장)
  ├─ 관제실     지금 이 순간 파이프라인이 어디까지 소화하는지
  └─ 센서팜     센서 1,000대 개별 상태 + 부하를 직접 만들어 던지는 발생기

• 센서가 말을 멈추면 알아챕니다. 값이 안 오는 것과 값이 이상한 것은 다른 사고라서 따로 판정합니다. 센서마다 발신 주기가 달라 주기를 관측해 기준을 스스로 맞춥니다 — 고정 기준을 두면 느린 센서가 매번 고장으로 잡힙니다.
• 있을 수 없는 값은 격리합니다. 문 하나로 1초에 수천 명이 들어올 수는 없습니다. 그런 값은 버리는 게 아니라 따로 세어 둡니다 — 지운 것과 걸러낸 것은 다르게 취급해야 나중에 원인을 찾습니다.
• 알림을 단계로 올립니다. 한 번 튄 값과 10분째 응답 없는 센서를 같은 무게로 알리면 아무도 안 봅니다. 담당자 → 관리자 → 비상으로 올라가고, 복구되면 내려옵니다.
• 오래된 데이터는 스스로 접습니다. 원본을 영원히 두면 디스크가 먼저 죽습니다. 시간이 지나면 분·시간 단위 요약으로 접고, 더 지나면 지우고, 빈 공간을 회수합니다.
• 부하를 직접 만들어 던질 수 있게 했습니다. 발신 속도를 현실(분당 1건) · 정상(17/s) · 빠름(500/s) · 폭주(5,000/s) · 극한(20,000/s) 로 눌러서 바꾸고, 이상치도 주입합니다. 아래 발견들은 전부 이 발생기로 재현한 것입니다.

그래서 무엇을 발견했나

돌아가는 것까지는 어렵지 않았습니다. 부하를 올리자 전부 여기서 갈렸습니다.

1. 01
   수신은 되는데 저장이 0 — 그런데 아무 흔적도 없었습니다 센서는 보내고 있고 화면의 수신 건수도 오르는데, 저장만 되지 않았습니다. 대기열도 0, 폐기도 0이라 어디로 샜는지 단서가 없었습니다. 원인은 버려진 게 아니라 접힌 것이었습니다 — 처리 주기가 밀리면 한 주기에 같은 센서를 두 번 세게 되고, 그러면 같은 센서·같은 밀리초가 만들어져 중복 방지 규칙이 전부 하나로 합쳐버립니다. 유실을 막으려고 넣은 장치가 유실을 만들고 있었습니다. 한 주기에 명부를 한 바퀴까지만 돌도록 상한을 걸어 중복 22,426건 → 0건, 저장량 +25%.
2. 02
   추측으로 두 번 헛짚고, 진단을 먼저 만들어 5초 만에 찾았습니다 위 문제를 고친 방법입니다. 화면의 정합성 표시가 "중복으로 접은 건수"를 보고 있지 않아서, 시스템이 스스로 "유실 0 · 정상"이라고 말하고 있었습니다. 코드를 고치는 대신 그 숫자를 화면에 올리자 원인이 즉시 드러났습니다. 재현 조건이 까다로워 세 번 만에 잡았는데, 앞의 두 번이 실패한 이유는 같았습니다 — 화면 없이 검증했습니다. 거기엔 UI가 없으니 "화면이 멈춘다"가 재현될 리 없었습니다.
3. 03
   한 번은 무해한 호출이, 초당 수천 번이면 흉기입니다 화면이 매 프레임 "이 센서 살아있나?"를 물었고, 그 호출이 잠금을 잡았는데 같은 잠금을 수집 쪽이 쓰고 있었습니다. 화면 한 장이 프레임당 잠금을 1,000번 잡아 수집을 굶겼습니다. 900만 행짜리 전체 집계를 매 주기 두 곳에서 부르던 것도 같은 부류였습니다. 한 번에 복사해 오는 방식으로 잠금 1회로 줄였습니다. 함수 하나만 보면 멀쩡한데 호출 빈도를 보면 아니었던 경우이고, 이 프로젝트에서만 세 번 나와 규칙으로 승격했습니다.
4. 04
   계산이 전부 맞아도 화면은 거짓말을 합니다 기준이 다른 수를 나란히 놓은 것만으로 세 곳이 틀렸습니다. 상단에 저장 176만 건과 수신 1,720건을 붙여놨는데 하나는 DB 전체 누적이고 하나는 이번 실행분이라 1,000배가 났습니다. 가동률이 화면마다 865/1,000과 1,000/1,000으로 갈린 것은 한쪽만 응답 확인까지 셌기 때문이고, 3,722 → 1,862로 반이 증발한 것은 하나가 사건 수, 하나가 메시지 수였기 때문입니다. 해법은 설명을 덧붙이는 게 아니라 라벨에 기준을 적고, 단위가 안 맞는 자리는 숫자를 비우는 것이었습니다.

무엇을 만들었나

공시 수집    미국 상장사가 의무로 내는 보고서 — 연차(10-K)·분기(10-Q)
  │            한 건이 수백 페이지라 사람도 통째로는 못 읽는다
  ▼
LLM 압축    핵심만 남기고 반복되는 법률 문구를 걷어낸다
  │
  ▼
쪼개기      의미가 끊기지 않는 단위로 자른다  자르는 기준이 답변 품질을 좌우한다
  │
  ▼
임베딩      각 조각을 좌표로 바꿔 저장 — "비슷한 뜻"을 거리로 찾기 위해
  │
  ▼
검색 → 답변  질문과 가까운 조각을 꺼내, 그 대목을 근거로만 답하게 한다

• "이 회사 부채가 늘었나?" 같은 질문에 공시 원문을 근거로 답합니다. 모델이 알고 있는 지식이 아니라 실제 제출 문서에서 찾아온 대목으로 답하게 만드는 것이 핵심입니다.
• 재무 수치는 LLM에게 맡기지 않습니다. 표에서 직접 뽑고, 빠진 항목만 LLM이 채웁니다. 숫자를 지어내는 것이 가장 위험하기 때문입니다.
• 뽑아낸 수치가 회계적으로 말이 되는지 스스로 검사합니다. 자산과 부채+자본이 맞지 않으면 그 자리에서 걸립니다.
• 같은 것을 두 번 부르지 않습니다. 이미 받은 공시는 요청 자체를 하지 않고, 호출이 거절당하면 예비 키로 넘어가 중단된 지점부터 이어서 진행합니다.

그래서 무엇을 발견했나

1. ▸
   LLM에 전부 맡기지 않는 하이브리드 파서 재무 수치는 HTML 테이블 파싱을 1차로 두고, 누락된 항목만 LLM 보충 패스로 채웁니다. 비용과 환각을 동시에 줄이는 구조입니다. 한국 DART는 XBRL 표준계정ID가 있어 LLM 파싱이 아예 불필요하다는 것도 확인해서, 같은 문제에 다른 해법을 적용했습니다.
2. ▸
   LLM 출력을 회계 항등식으로 검증 추출된 수치가 자산 = 부채 + 자본을 만족하는지 교차 확인합니다. 계정을 잘못 매핑하면 오차가 100% 단위로 튀기 때문에 즉시 걸립니다. 실제로 이 검증이 자본총계 대신 총자산을 읽던 결함을 잡았습니다 — LIKE '%자본총계%'가 부채와자본총계에 걸린 경우였습니다.
3. ▸
   프롬프트에도 테스트를 붙였습니다 프롬프트는 코드가 아니라는 이유로 검증 밖에 놓이기 쉽습니다. 필수 경고 문구가 빠지지 않았는지, 지시가 서로 충돌하지 않는지를 단위 테스트로 고정했습니다. 프롬프트를 수정하다 안전 문구를 지우는 사고를 구조적으로 막습니다.
4. ▸
   파이프라인 전체 정독 리뷰 · 결함 12건 문서화 돌아가는 코드를 처음부터 끝까지 다시 읽어 HIGH 3 · MED 4 · 잠복 5를 목록화했습니다. 가장 위험한 건 임베딩 차원이 안 맞을 때 유사도 함수가 예외도 로그도 없이 0을 반환하는 부분 — 모델을 교체하면 검색이 조용히 전멸합니다. 같은 코드가 3개 저장소에 복제돼 있다는 사실까지 확인해 "한 곳만 고치면 재발한다"를 문서에 박았습니다.
5. ▸
   API 한도·비용 설계 섹션별 토큰 예산, 보일러플레이트 제거, 키 이중화(429/503 시 백업 키 자동 폴백), 수집 로그 기반 재개 — 이미 받은 건 API 호출 자체를 하지 않습니다. 이 설계로 DART 재무 27,729건을 한도에 한 번도 걸리지 않고 완주했습니다(421만 행).

무엇을 만들었나

후보 좁히기   조건에 맞는 종목만 남긴다 — 실시간 구독은 100종목이 물리 상한이다
  │
  ▼
실시간 시세   증권사 서버에서 체결·호가를 계속 받는다
  │
  ▼
신호 판정    전략이 "지금 사라 / 팔아라"를 판단  전략은 갈아끼울 수 있는 부품
  │
  ▼
주문 · 체결  주문을 내고, 안 채워지면 취소하고, 채워진 만큼만 관리한다
  │
  ▼
청산 · 방어  손절 · 시간 마감 · 비상 정지 · 응답이 끊기면 스스로 정리

• 사람이 화면을 보고 있지 않아도 돌아갑니다. 종목을 고르고, 사고, 지키고, 파는 것까지 프로그램이 합니다. 사람은 어떤 전략을 켤지와 언제 멈출지만 정합니다.
• 전략을 부품처럼 갈아끼웁니다. 고객마다 매매 방식이 다르기 때문에, 전략 하나를 파일로 만들어 끼우면 본체를 고치지 않고 동작하도록 경계를 나눴습니다.
• 과거 데이터로 먼저 검증합니다. 실제 돈을 넣기 전에 20년치 시세로 같은 전략을 돌려 성과·최대 손실·거래 횟수를 봅니다.
• 위험할 때 멈추는 장치를 여러 겹 넣었습니다. 비상 정지, 주문 폭주 차단, 미체결 자동 취소, 프로그램이 응답을 멈추면 스스로 정리하는 장치까지. 실제 돈이 걸린 시스템에서 가장 많이 손본 부분입니다.
• 밖에서도 확인하고 멈출 수 있습니다. 텔레그램으로 현재 상태를 받고 원격으로 정지시킵니다.

그래서 무엇을 발견했나

1. ▸
   전략 교체가 가능한 프레임워크 구조 고객 전략을 DLL 하나로 끼우면 본체 수정 없이 동작하도록 계약 인터페이스를 분리했습니다. "계약 표면 = 고객 진입점의 전이 폐포"로 경계를 정의해, 어디까지가 공개 API이고 어디부터가 내부인지를 명확히 했습니다.
2. ▸
   알고리즘 유출 방지를 빌드로 강제 전략 로직이 판매본 DLL에 섞이면 디컴파일로 노출됩니다. 어셈블리를 8개로 쪼개고 DTO 경계 + 참조 방향 + 빌드 구성 3겹으로 막았습니다. 사람이 조심하는 대신 빌드 스크립트가 위반을 차단합니다.
3. ▸
   실계좌 진입 전 하드닝 감사 독립된 관점으로 전수 감사해 CRITICAL 4건을 잡았습니다. 그중 하나는 비상 정지 스위치가 신규 매수뿐 아니라 청산까지 막고 있던 것 — 위험할 때 팔지도 못하게 되는 결함이었습니다. 청산은 방어 주문으로 분류해 폭주 방지 게이트에서 면제하도록 고쳤습니다.
4. ▸
   거래 안전장치 매도 초과 주문 방지(매도가능수량 소비 모델), 동시호가 시각 계단 처리, 미체결 자동 취소, 재시작 시 보유종목 실시간 구독 유실 복구, dead-man's switch. 실시간 구독 100종목 물리 상한이라는 제약에서 출발해 유니버스를 먼저 좁히는 구조로 재설계했습니다.

1. ▸
   회귀 결함을 기억이 아니라 검출로 막기 같은 유형의 버그가 반복되자 "세 곳 동시 수정"을 테스트로 강제했습니다. 옵션을 하나 추가하면 저장·복원·렌더 세 곳에 결선해야 하는데, 빠뜨리면 리플렉션 회귀 테스트가 잡습니다. 빌드는 통과하는데 런타임에만 조용히 실패하는 종류를 겨냥한 장치입니다.
2. ▸
   Gemini 배치 분류 종목 3,000개를 배치 10 × 동시 3으로 처리해 테마·촉매·실적 요약을 생성합니다. 키 이중화와 재시도 헬퍼를 두어 호출이 거절당해도 작업 전체가 멈추지 않고 이어지게 했습니다.