AI로 주식투자가 될까 싶어 모델 셋을 붙여봤다. 정정된 건 위험 목록이 아니라 "AI가 충동을 줄여준다"는 내 전제였다

AI로 주식투자가 될까 싶어 모델 셋을 붙여봤다. 정정된 건 위험 목록이 아니라 "AI가 충동을 줄여준다"는 내 전제였다

손실 중인 보유 종목이 하나 있다. 회사에서 받은 주식이 얼마간 있고, 몇 년 전에 내 돈으로 더 산 게 있다. 그 종목에 큰 발표가 나온 다음 날이었다.

평소 같으면 기사 몇 개 읽고 넘어갔을 텐데, 그날은 다른 게 궁금했다. 나는 하루 종일 AI로 코드를 짜고 문서를 읽고 로그를 뒤진다. 그 도구로 공시를 읽으면 어떻게 되나. 회사 하나 분석하는 건 코드베이스 하나 파악하는 것보다 자료가 적으면 적었지 많지는 않을 텐데.

그래서 한 모델한테 묻는 대신 셋을 붙였다. Claude에게 "AI를 투자에 쓰는 게 왜 위험한지" 목록을 뽑게 하고, 그걸 ChatGPT에 넘겨 반박하게 하고, 다시 Gemini에 넘겨 양쪽을 검증하게 했다. 한 모델이 틀리면 다른 모델이 잡을 거라고 생각했다.

의도한 건 됐다. 위험 목록이 나왔고, 서로 꽤 세게 고쳤다. 일곱 항목 중 다섯 개는 내가 처음 적은 표현이 부정확하다는 지적을 받고 문장이 통째로 바뀌었다. 나머지 둘은 내가 아예 생각 못 한 항목으로 추가됐다. 여기까지는 기대한 그림이었다.

문제는 그다음이었다. 목록이 다 정리된 뒤에 읽어보니, 내가 애초에 깔고 시작한 전제 하나가 그 목록 안에서 조용히 뒤집혀 있었다. "AI를 쓰면 충동적으로 사고파는 일이 줄어든다"는 전제였다. 나는 그걸 논의의 결론으로 쓰려고 했는데, 오히려 반대라는 지적이 나왔다. 그리고 내가 그 뒤에 설계한 안전장치는, 두 달 전 내 발행 파이프라인에서 이미 한 번 무너졌던 것과 정확히 같은 모양이었다.

첫 질문에 이미 답이 절반 들어 있었다

시작을 잘못했다는 걸 나중에 알았다.

처음 던진 질문은 이랬다. 보유 수량과 매수 단가를 적고, 지금 얼마나 손실인지 적고, 앞으로 어떻게 하면 좋겠냐고 물었다. 사람한테 물어볼 때 하는 방식 그대로다.

이 문장 안에는 세 가지가 이미 들어가 있다. 매수 단가라는 기준점, 손실을 회복하고 싶다는 방향, 그리고 내가 이미 그 주식을 들고 있다는 사실. 모델은 이 맥락을 무시하지 않는다. 무시하지 않도록 학습된 물건이다. 그래서 답은 자연히 "이 기준점 위에서 무엇을 하면 좋은가"가 된다. 애초에 그 기준점이 의사결정에 들어갈 이유가 없다는 얘기는 안 나온다.

여기서 "반대 근거도 찾아줘"를 붙이면 해결되는 줄 알았다. 안 된다. 그 문장에는 이미 "나는 사고 싶다"거나 "나는 들고 있다"가 실려 있어서, 반박이 나오긴 하는데 견딜 만한 세기로 나온다. 마지막 문단에 위로가 붙는 경우도 있다. 반박을 요청한 사람이 반박당하고 싶어 하지 않는다는 걸 아는 상태로 쓴 반박이다.

이건 AI 챗봇에 불만을 아홉 줄 쏟았을 때 겪은 것과 같은 자리다. 그때도 내가 깐 프레임을 모델이 이어받아서 정교하게 발전시켜줬고, 나는 그게 검증이라고 착각했다.

포지션을 숨기는 쪽으로 질문을 다시 짰다.

내 보유 여부와 매수 단가는 제공하지 않는다.
이 기업의 Bull Case와 Bear Case를 각각 가장 강한 형태로 작성하라.
최종 매수·매도 결론은 내리지 마라.

보유 종목을 평가할 때 쓸 만한 사고실험도 하나 나왔다. "지금 아무것도 안 들고 있고 현금만 있다면, 이 가격에 같은 금액을 새로 넣겠는가."

이 질문이 만능은 아니다. 실제로는 세금이 걸리고, 파는 데도 비용이 들고, 지금 들고 있기 때문에만 생기는 제약이 있다. 이미 산 사람과 아직 안 산 사람의 선택지는 완전히 같지 않다. 매수 단가에서 눈을 떼는 데는 쓸모가 있지만, 이 질문의 답을 그대로 주문 화면에 옮기면 그건 그것대로 다른 착각이다.

위험 목록을 뽑았더니 목록이 먼저 정정됐다

내가 처음 적은 위험 다섯 개가 어떻게 바뀌었는지가 이 논의에서 제일 재미있는 부분이었다.

내가 처음 쓴 표현 정정된 표현
AI가 아첨한다 사용자의 전제와 프레이밍을 이어받아 추론을 전개한다. 맞장구를 치려는 의도가 아니라 컨텍스트에 따라 결론이 갈리는 구조다
AI는 최신 정보에 약하다 정보 접근 속도가 아니라 정보 처리 속도를 올리는 도구다. 검색을 붙여도 기관이 이미 읽은 정보와 같은 걸 읽는다
AI 백테스트는 과최적화된다 과최적화는 퀀트와 기술적 분석을 포함한 모든 룰베이스 전략의 공통 문제다. AI 상품 마케팅에서 유독 과장될 뿐이다
AI에 책임을 외주화하게 된다 손절 기준을 AI에게 반복해서 다시 묻는 동안 원칙 자체가 갱신되고 흐려진다
입력 데이터가 오염된다 학습 데이터 오염(Model Collapse)과 검색 결과 오염(Retrieval Pollution)은 다른 층위다. 개인이 실제로 마주치는 건 후자다

추가된 두 개는 이랬다. 논리의 완성도와 사실의 정확도는 별개라는 것, 그리고 "AI가 분석했다"는 문구 자체가 신뢰도를 올린다는 것.

두 번째가 특히 불편했다. LLM은 확실한 내용과 불확실한 내용을 같은 문체로 쓴다. 표를 그리고 번호를 매기고 소수점 둘째 자리까지 적는다. 나는 그 문장의 완성도를 근거의 품질로 읽는다. 개발할 때는 이걸 조심하는데, 왜냐면 컴파일러가 대신 화를 내주기 때문이다. 주식에는 컴파일러가 없다.

앞의 것은 이렇게 확인해볼 수 있다. 같은 회사를 두고 두 번 시킨다.

이 종목이 앞으로 크게 오를 이유를 가장 설득력 있게 써라.
이 종목이 앞으로 수년간 회복 못 할 이유를 가장 설득력 있게 써라.

둘 다 잘 나온다. 문장력도 논리 연결도 우열을 가리기 어렵다. 예전에는 내 생각을 뒷받침할 자료를 찾으려면 검색하고 읽고 골라내는 시간이 들었다. 지금은 3초다. 확증편향을 실행하는 비용이 사실상 0으로 떨어졌다. 그게 이 도구가 투자에서 위험한 첫 번째 지점이었다.

"AI 자동매매"라는 이름은 검증 기준을 낮출 이유가 아니다

위 표의 세 번째 줄에서 한 번 걸렸다. 과최적화가 AI만의 문제가 아니라는 지적이다.

맞는 말이다. 과거 데이터에 맞춰 규칙을 깎다 보면 성과가 좋아지는 건 퀀트도 기술적 분석도 손으로 만든 매매 규칙도 똑같다. 그래도 AI 상품에서 유독 눈에 띄는 이유는 따로 있다. 전략을 만드는 비용과 그럴듯한 성과 그래프를 뽑는 비용이 같이 떨어져서, 검증되지 않은 백테스트가 빠르게 양산된다.

머신러닝 모델을 평가할 때 보던 항목이 그대로 쓰인다.

  • 상장폐지된 종목을 빼고 돌린 것은 아닌지 (생존자 편향)
  • 거래비용, 세금, 슬리피지, 실제 체결 가능성을 넣었는지
  • 튜닝한 구간과 검증한 구간이 정말 분리돼 있는지
  • 여러 전략을 돌려놓고 제일 잘 나온 하나만 보여주는 것은 아닌지
  • 그 시점에 알 수 없었던 정보가 들어가 있지 않은지
  • 상승장과 하락장 성과를 따로, 최대 낙폭과 함께 제시하는지
  • 실제 계좌나 전진 검증 결과가 있는지
  • 모델, 프롬프트, 데이터가 언제 바뀌었는지 기록이 남는지

마지막 줄이 LLM 쪽에서 새로 붙는 항목이다. 프롬프트를 한 줄 고치면 결과가 달라지는데 그 한 줄을 아무도 버전 관리하지 않으면 재현이 안 된다. 재현이 안 되는 성과는 성과가 아니라 일화다.

편향은 모델 안이 아니라 검색 결과 쪽에 있었다

내가 처음에 세운 가설 중 하나는 아예 틀린 거였다.

"주가가 오르면 AI가 그 상승을 학습해서 다시 그 종목을 추천하고, 그게 다시 주가를 올린다." 이런 되먹임 고리가 있을 거라고 생각했다. 성립하지 않는다. 서비스로 쓰는 LLM은 온라인 학습을 하지 않는다. 오늘의 주가 변동이 오늘 모델 가중치에 반영되는 경로가 없다.

그런데 편향 자체는 있다. 위치가 다를 뿐이다.

주가 급등 또는 대형 발표
        ↓
관련 기사·블로그·커뮤니티 글 급증
        ↓
검색 결과 상위 점유
        ↓
RAG 컨텍스트에서 그 종목과 서사의 비중 증가
        ↓
답변에 같은 종목과 같은 논리가 반복 등장

모델이 뭘 새로 배운 게 아니라 입력의 분포가 바뀐 거다. 재학습 주기가 몇 달이라면 이쪽은 몇 시간에서 며칠이면 반영된다. 실전에서 체감되는 속도가 완전히 다르다.

그래서 대응도 달라진다. 모델을 바꾸는 건 이 문제에 거의 도움이 안 되고, 무엇을 컨텍스트에 넣을지를 통제해야 한다.

여기서 파생되는 위험이 하나 더 있는데, 이게 개인적으로 제일 서늘했다. 같은 모델에 같은 검색엔진을 쓰는 사람이 많아지면 추천 종목이 소수로 모인다. 각자는 독립적으로 분석했다고 믿는다. 실제로는 비슷한 걸 들고 있다. 분산했다고 생각하는 포트폴리오들의 상관계수가 같이 올라가고, 내릴 때 같이 판다. 알파가 사라지는 것보다 이쪽이 더 실질적인 위험이다.

역설적으로 커버리지가 얕은 종목은 이 편향에서 자유롭다. 기사가 적고 영어 자료가 없는 중소형주 같은 것들이다. 그런 종목에서는 공시를 빨리 읽고 구조화하는 처리 속도가 실제 우위가 될 수 있다. 대신 자료가 적을수록 잘못 읽을 위험도 커지니까, 원문을 직접 확인하는 비용을 본인이 다 떠안아야 한다. 이론상의 기회와 개인이 실행 가능한 기회는 구분해야 한다.

세 모델이 같은 답을 했다는 게 검증은 아니다

이 논의를 셋으로 돌린 이유가 여기서 무너졌다.

한 모델 안에서 Bull 역할과 Bear 역할을 나누는 방법이 있다. 세계 최고의 낙관론자와 세계 최고의 공매도 전문가를 붙이고 심판을 하나 더 세우는 식이다. 결론으로 빨리 수렴하는 걸 늦추는 데는 확실히 쓸모가 있다.

그런데 이 둘은 독립적이지 않다. 같은 가중치를 쓰고, 같은 학습 데이터를 봤고, 같은 영역을 똑같이 얕게 안다. 지배구조 개편의 법적 세부 구조처럼 모델이 원래 잘 모르는 영역이면 Bull도 Bear도 똑같이 얕은 소리를 한다. 겉으로는 논쟁인데 실제로는 하나의 반경 안에서 왔다 갔다 하는 것뿐이다.

모델을 바꾸면 나아지긴 한다. 관찰되는 오차를 이렇게 쪼개보면 이유가 보인다.

오차 = 공유된 지식·소스에서 온 오차 + 모델별 고유 오차

Claude와 ChatGPT와 Gemini를 섞으면 두 번째 항은 줄어든다. 첫 번째 항은 안 줄어든다. 셋 다 웹 검색을 켜면 같은 기사, 같은 공시, 같은 통신사 재인용을 읽는다. 검색 단계에서 다시 합류한다. 세 모델이 같은 답을 했다는 사실이 강한 증거처럼 느껴지는데, 같은 오염된 기사를 셋이 나눠 읽었을 가능성과 구분이 안 된다.

여기서 나온 표현 하나가 이 논의 전체에서 제일 쓸모 있었다.

Model Diversity보다 Evidence Diversity가 중요하다.

모델을 세 개 쓰는 게 아니라 원천 자료를 세 갈래로 쓰는 것이다. 법적 구조는 규제기관 제출 문서로, 재무 숫자는 감사보고서와 주석으로, 경영진의 주장은 컨퍼런스콜 원문으로 확인한다. 그리고 검색은 끈다. 같은 원문을 모든 모델에 똑같이 넣으면 입력이 통제되니까, 답이 갈릴 때 그 차이를 모델의 해석 차이로 돌릴 수 있다.

완전한 해법은 아니다. 원문을 요약해서 넣는 순간 압축이 곧 해석이 되기 때문에, 통제했다고 믿었던 입력이 다시 흔들린다.

숫자와 인용은 안전장치가 아니었다

내가 두 번째로 틀린 지점이다.

"서사 말고 숫자로 달라고 하면 검증 가능해진다"고 생각했다. 개발에서 통하는 습관이다. 애매한 설명 대신 수치를 요구하면 대개 진위가 드러난다.

LLM은 매출도 영업이익도 PER도 자연스럽게 지어낸다. 숫자가 구체적이라는 건 그게 검증 가능하다는 뜻이지 검증됐다는 뜻이 아니다. 그리고 숫자는 구체적일수록 더 믿음직하게 읽힌다.

인용도 같다. 이런 문장을 본 적 있다.

2026년 2분기 사업보고서 III-2, 15페이지 기준

절 번호와 페이지까지 붙어 있다. 이 정밀함은 그 문서가 존재하는지와 아무 상관이 없다. 오히려 정밀할수록 확인해볼 생각이 덜 든다. 나는 이걸 시크릿 스캔 훅이 AWS 키를 그냥 통과시켰던 날에 한 번 배웠어야 했다. 그때도 훅이 돌고 있다는 사실 자체가 안심의 근거였지, 훅이 무엇을 보고 있는지는 아무도 안 봤다.

인용을 확인할 때 봐야 할 게 네 가지로 정리됐다. 그 문서가 실제로 있는가. 버전과 기준일이 맞는가. 그 위치에 그 문구가 정말 있는가. 그리고 문맥을 떼어내면서 의미가 변하지 않았는가.

마지막 항목이 제일 잡기 어렵다.

인용이 진짜인데 의미만 옮겨간 경우

이 논의에서 처음 알게 된 이름이 Semantic Drift다. 가짜 인용보다 훨씬 흔하고 훨씬 안 잡힌다.

원문: "사업 효율화를 검토 중이다."
요약: "회사가 구조조정을 시사했다."

출처는 진짜다. 페이지도 맞다. 그런데 원문보다 세고 구체적인 방향이 붙었다. "검토 중"과 "시사"는 다른 무게고, "효율화"와 "구조조정"도 다른 단어다. 이 요약을 열 번 읽으면 나는 회사가 구조조정을 예고했다고 기억한다.

요약은 중립적인 압축이 아니다. 무엇을 남기고 무엇을 버릴지 고르는 작업이라서, 고르는 순간 해석이 들어간다. 그래서 "공시 요약해줘"라는 요청에도 최소한 이 구분은 강제해야 한다는 결론이 나왔다.

구분 정의
Fact 원문에서 직접 확인되는 사실과 수치
Company Claim 회사가 주장하거나 전망한 내용
Interpretation 모델이 부여한 의미
Assumption 아직 확인되지 않은 전제
Unknown 현재 자료로는 판단할 수 없는 것
Counter Evidence 현재 가설을 약화시키거나 뒤집는 근거

원문 대조를 시킬 때 쓴 프롬프트는 이렇게 생겼다.

아래 분석문과 원문을 대조하라. 각 문장을 다음 중 하나로 표시하라.

- Exact Support: 원문이 직접 지지함
- Partial Support: 일부만 지지함
- Semantic Drift: 원문보다 의미가 강해지거나 달라짐
- Unsupported: 원문에서 찾을 수 없음
- Contradicted: 원문과 충돌함

페이지나 절 번호를 추정하지 마라. 못 찾으면 '확인 불가'로 표시하라.

"추정하지 마라. 못 찾으면 확인 불가로 표시하라"는 줄이 없으면 모델은 빈칸을 그럴듯하게 채운다. 코드 짤 때 널 체크 빼먹은 것과 비슷한 실수다.

표를 채운 것과 확인한 것은 다르다

위의 여섯 칸짜리 구조를 처음 봤을 때 나는 이걸로 문제가 풀렸다고 생각했다. Fact와 Interpretation이 분리돼 있으니 이제 Fact만 믿으면 되는 거 아닌가.

Fact 칸을 채운 것도 같은 모델이다.

이 지적을 받고 나서 출력 스키마에 열을 하나 더 붙였다. 검증 상태 열이고, 기본값이 '미검증'이다. 사람이 원문을 열어서 대조한 항목만 손으로 '검증'으로 바꾼다. 모델은 이 열을 수정할 수 없다.

ID 구분 내용 원문 인용 위치 기준일 검증 상태
F-01 Fact 미검증
C-01 Company Claim 미검증
A-01 Assumption 해당 없음 검토 필요
U-01 Unknown 해당 없음 추가 자료 필요

구조화가 신뢰도를 올려주지는 않는다. 어디를 확인해야 하는지 보여주고 확인하는 비용을 낮출 뿐이다. 표가 예쁘게 채워진 상태와 내용이 사실인 상태 사이에는 아무 관계가 없는데, 표를 보고 있으면 그 둘이 자꾸 붙는다.

그리고 전부 다 확인할 필요는 없다는 것도 같이 정리됐다. 우선순위가 있다. 결론을 바꾸는 숫자, 지분 관계와 법적 구조, 경영진의 확정적 약속으로 읽히는 문장, 전년 대비인지 전분기 대비인지 같은 비교 기준, 페이지와 절 번호가 유난히 구체적인 인용, 그리고 여러 출처가 똑같이 반복 인용하고 있는 단일 주장. 마지막 항목은 출처가 여러 개처럼 보이지만 계보를 따라가면 하나인 경우다.

"원문을 보라"는 말로는 부족했다

여기까지 오면 다음 얘기는 뻔하다. 원문을 봐라. 그런데 원문이라는 게 한 종류가 아니다.

내가 그날 읽은 것만 나열해도 규제기관에 제출된 공시가 있고, 회사가 만든 IR 자료가 있고, 컨퍼런스콜 녹취가 있고, 증권사 리포트가 있었다. 이걸 다 "원문"이라고 부르면서 같은 무게로 읽고 있었다. 법적 책임이 따라붙는 문서와 홍보 목적으로 만든 장표를 나란히 놓고 읽은 셈이다.

논의에서 나온 우선순위는 열 단계였다.

  1. 규제기관 제출 공시와 법적 효력이 있는 문서
  2. 감사보고서와 재무제표 주석
  3. 회사의 실적 발표 자료와 공식 IR 문서
  4. 컨퍼런스콜 원문과 녹취록
  5. 공식 IR FAQ와 회사 관계자 답변
  6. 경영진 인터뷰
  7. 증권사와 전문가 분석
  8. 언론 기사
  9. 블로그, 커뮤니티, SNS
  10. AI가 만든 요약과 그 요약의 재요약

이게 진실의 순위표는 아니다. 공시도 누락될 수 있고 경영진 전망에는 이해관계가 있다. 어디부터 열어볼지 정하는 운영 순서에 가깝다.

읽고 나서 든 생각은, 이걸 개발할 때는 이미 하고 있다는 것이었다. 장애 원인을 볼 때 애플리케이션 로그와 누가 슬랙에 요약해준 문장을 같은 근거로 쓰지 않는다. 로그를 먼저 열고 요약은 나중에 맞춰본다. 주식 자료에서만 그 순서가 없었다.

용도별로 소스를 나누는 것도 같이 정리됐다. 지분 관계와 법적 구조는 공시와 규제기관 문서에서 확인한다. 재무 숫자는 재무제표와 주석에서 본다. 회사가 무엇을 하겠다고 말했는지는 IR과 컨퍼런스콜에서 확인한다. 시장이 그걸 어떻게 해석하는지는 리포트와 기사에서 본다. 아래 계층 자료로 위 계층의 사실을 대신 증명하지 않는다는 게 규칙이다. 기사 세 개가 같은 말을 한다고 해서 공시가 확인된 게 아니다.

계보를 따지는 습관도 여기서 나왔다. 검색 결과 열 개가 나왔을 때 출처가 열 개인지, 아니면 하나의 보도자료를 열 군데가 옮겨 적은 것인지는 완전히 다른 얘기다. 후자가 훨씬 흔하다. 출처 개수를 세기 전에 어디서 나온 것인지를 먼저 따라가야 한다.

같은 질문을 2주 뒤에 다시 던지는 이유

검색 품질이 고정값이 아니라는 것도 이번에 처음 의식했다. 시간에 따라 변하는 함수다.

시점 주로 잡히는 자료 위험
발표 직후 수십 분 공시 원문, 속보 맥락 부족, 오독
수 시간 반복 기사, 요약 기사 같은 원문의 대량 재인용
1~2일 초기 전문가 코멘트 제한된 정보로 내린 빠른 결론
수일~2주 컨퍼런스콜 후속 분석, 증권사 리포트 컨센서스 편향, 논리 수렴
수주~수개월 실행 결과와 후속 공시 사후 합리화, 당시 가설의 변형

내가 질문을 던진 건 발표 다음 날이었다. 그 시점에 검색으로 잡히는 건 대부분 속보와 그 재인용이었다는 뜻이다. 모델이 게을러서가 아니라 그때 인덱스에 그것밖에 없었다.

그래서 급하지 않으면 같은 질문을 나중에 한 번 더 던지는 게 낫다는 결론이 나왔다. 여기서 중요한 게 하나 있는데, 두 번째 답을 첫 번째 답 위에 덮어쓰지 않는 것이다. 둘을 나란히 두고 비교할 때 봐야 하는 건 결론이 바뀌었는지가 아니라 입력이 무엇이 달라졌는지다. 새 원문이 추가돼서 결론이 바뀌었다면 그건 정보가 늘어난 것이고, 같은 자료를 보고 결론만 달라졌다면 그건 모델이나 내 질문이 흔들린 것이다.

손실 구간에 자유도를 줄이는 장치를 설계했다

여기까지 정리하고 나서 내가 만든 게 있다.

문제 정의는 이랬다. 평온할 때는 위의 규칙을 다 지킬 수 있다. 손실이 커지면 못 지킨다. 그때 내가 실제로 하는 행동은 뻔하다.

Bull Case 요청
   ↓
더 강한 Bull Case 요청
   ↓
회복 시나리오를 뒷받침할 새 근거 요청
   ↓
추가 매수 정당화

이걸 막으려고 손익 구간별로 AI의 자유도를 제한하는 상태 머신을 그렸다.

수익 구간    → 일반 분석 허용
-20%        → Bear Case 강제 생성
-30%        → 신규 Bull 생성 금지, Counter Evidence만 허용
-40%        → 새 분석 금지, 최초 가설과 현재 사실의 비교만 허용

항공기 조종실과 수술실에서 쓰는 체크리스트 발상을 그대로 가져온 것이다. 스트레스 상황에서는 판단의 자유도를 줄이고 절차를 단순하게 만든다. 나는 이게 꽤 괜찮은 설계라고 생각했고, Electron과 Supabase로 어떻게 붙일지까지 머릿속으로 그리고 있었다.

검문소와 통행증 발급처가 같으면

이 설계가 작동하려면 판단력이 흐려진 그 사용자가 자기가 만든 규칙을 우회할 수 없어야 한다.

실제 권한 구조는 이렇다. 나는 시스템 프롬프트를 편집할 수 있다. 손익 상태를 입력하는 것도 나다. 새 대화를 여는 것도 나다.

-30% 구간에서 "신규 Bull 생성 금지"가 걸려 있어도, 그 줄을 지우거나 새 세션을 열면 그만이다. 이건 커밋먼트 디바이스가 아니라 셀프 체크리스트고, 강제력이 없으니까 제일 필요한 순간에 제일 먼저 버려진다. 조종실 체크리스트가 실제로 작동하는 이유는 조종사가 성실해서가 아니라 부기장과 관제탑과 블랙박스가 밖에 있어서다. 조종사가 체크리스트를 편집할 수 있으면 그건 체크리스트가 아니다.

이 얘기를 읽는 순간 지난달 말에 뜯어낸 코드가 떠올랐다.

이 블로그 발행 파이프라인에는 원래 AI 문체 게이트가 있었다. 글마다 -ai-check.md 파일을 만들고, 발행 스크립트가 그 파일에서 판정: 합격 문자열을 grep 해서 없으면 발행을 막았다. 코드로 강제하고 있으니까 안전하다고 생각했다.

그 문자열을 쓴 게 검사받는 에이전트 본인이었다. 검문소와 통행증 발급처가 같은 조직이었다. 그 게이트가 발행을 실제로 막은 기억이 없다. 글이 다 좋아서가 아니라 자기한테 불합격을 주는 검사자가 없었기 때문이고, 7월 29일에 그 grep을 지웠다. 감시 훅 12개가 4개월 동안 0회 발화한 것도, 두 달 반 죽어 있던 게이트도 전부 같은 자리에서 나온 얘기다.

손실 구간 상태 머신은 그것과 완전히 같은 구조였다. 나는 같은 실수를 코드에서 한 번, 돈에서 또 한 번 하려던 참이었다.

막는 대신 두 가지를 했다

하나는 권한 분리다. 판단하는 곳과 집행하는 곳을 같은 프로세스에 두지 않는다.

AI는 손절 기준을 설계하는 데 쓴다. 실제 집행은 증권사에 stop 주문으로 미리 걸어둔다. 그 주문은 내가 그 순간에 어떤 기분인지와 무관하게 작동한다. 대화 안에 적어둔 규칙과 체결 시스템에 걸어둔 주문은 강제력이 다르다. 전자는 내가 지울 수 있고 후자는 취소하려면 별도의 행동이 필요하다. 그 마찰 하나가 전부다.

이게 새로운 아이디어는 아니다. 권한 분리는 시스템 설계에서 늘 하던 것이고, 그걸 내 자제력 문제에 그대로 적용한 것뿐이다. 다만 이 비유를 알아채는 데 논의 여덟 턴이 걸렸다.

다른 하나는 차단을 포기하고 기록을 남기는 것이다.

내가 -30%에서 더 강한 Bull을 계속 요청하는 걸 막을 방법은 없다. 내 서비스고 내 계정이다. 그래서 막는 대신 전부 남기기로 했다. 수정 불가능한 append-only 로그다.

2026-08-15  Bull 생성 (근거: A, B)
2026-08-19  Bull 생성 (근거: A, B, C)   ← 손실 확대 후
2026-08-22  Bull 생성 (근거: A, B, C, D) ← 손실 추가 확대 후

이 세 줄을 나란히 보면 내가 뭘 하고 있는지 알아보기 어렵지 않다. 손실이 커질 때마다 낙관적 근거가 하나씩 늘어난다. 새로 확인된 사실이 있어서가 아니라 손실이 커져서다.

체크리스트가 아니라 블랙박스 쪽에 가깝다. 사고를 막지는 못하고 사고가 났을 때 뭐가 있었는지 보여준다. 그런데 내 경우에는 차단보다 이쪽이 작동할 가능성이 높아 보인다. 규칙은 지울 수 있지만 내가 3일 간격으로 같은 요청을 세 번 했다는 기록은 지워도 내가 기억한다.

뒤집힌 전제

논의를 시작할 때 나는 이렇게 정리해두고 있었다. AI를 쓰면 충동적으로 사고파는 일이 줄어든다. 감정적으로 결정하기 전에 한 번 물어보게 되니까.

틀렸다는 지적이 나왔고, 반박할 말이 없었다.

AI는 마찰을 만들지 않는다. 사기 직전에 "이거 사도 될까"라고 물으면 3초 만에 그럴듯한 이유가 나온다. 실제로 일어나는 건 이 순서다.

매수 충동
   ↓
질문
   ↓
주문 제작된 정당화
   ↓
확신 강화
   ↓
더 빠른 주문

숙고가 늘어나는 방향은 기본값이 아니다. 그렇게 만들려면 마찰을 밖에서 따로 설계해서 붙여야 한다.

여기에 하나가 더 붙었다. AI가 준 논리로 진입하면 "내가 왜 샀는지"와 "언제 틀렸다고 인정할 것인지"가 내 문장으로 남지 않는다. 남은 게 없으니까 손실이 났을 때 다시 물어보게 되고, 모델은 바뀐 상황에 맞는 새 논리를 또 만들어준다. 그래서 포지션마다 최소한 이건 내 손으로 쓰기로 했다. 무엇을 기대하고 샀는지, 그 근거가 어느 문서 어디에 있는지, 무슨 일이 생기면 틀린 것으로 볼지, 그리고 언제 다시 볼지. 네 줄이면 된다. 네 줄을 못 쓰겠으면 아직 살 이유가 정리되지 않은 것이다.

"AI는 방향성 없는 중립적 도구"라는 표현도 부정확하다는 얘기가 같이 나왔다. RLHF로 학습된 모델은 무방향이 아니라 사용자에게 동의하고 도움이 되어 보이는 쪽으로 분명히 기울어 있다. 기울기를 인지하지 못하면 중립이라고 믿는 만큼 방심하게 된다.

그래서 지금 지키기로 한 것

거창한 워크플로우를 다 만들지는 않았다. 아직 아무 코드도 안 짰다. 지금 실제로 지키는 건 넷이다.

질문할 때 매수 단가와 손실률을 안 쓴다. 첫 분석에서는 기업과 사건만 놓고 본다. "지금 현금만 있다면 이 가격에 살 것인가"로 바꿔 묻는다.

AI가 인용한 숫자와 페이지는 최소 한 번 원문에서 확인하기 전에는 안 믿는다. 확인 안 한 항목은 확인 안 했다고 표시해둔다. 표가 채워진 것과 사실인 것은 다르다.

손절 기준이 필요하면 대화 안에 적지 않고 증권사 주문으로 건다.

큰 발표 직후에는 사실 추출과 판단을 분리한다. 발표 당일에는 확정된 사실만 뽑아두고, 같은 질문을 2주 뒤에 다시 던진다.

이 넷 중 셋은 AI 사용법이 아니라 내 행동에 대한 규칙이다. 그게 이 논의의 실제 결론에 가깝다. 프롬프트를 아무리 정교하게 짜도 손실 구간에서 내가 그 프롬프트를 안 쓰면 소용이 없고, 그때 안 쓸 거라는 건 내가 이미 알고 있다.

처음 궁금했던 건 AI로 주식투자가 되느냐였다. 공시 읽고 비교하고 반대 논리 만드는 건 잘한다. 예전에 반나절 걸리던 걸 30분에 한다. 그런데 그 속도가 붙는 자리는 분석만이 아니었다. 내가 이미 하고 싶었던 걸 정당화하는 속도도 같이 붙었고, 그쪽이 훨씬 빨랐다.


이 글은 투자자문이 아니며 특정 종목의 매수·매도·보유를 권유하지 않습니다. 본문의 위험 목록과 워크플로우는 LLM을 리서치 도구로 쓸 때의 일반적인 주의사항이고, 실제 투자 판단과 그 결과에 대한 책임은 투자자 본인에게 있습니다. 세무·법률·회계 쟁점은 세무사·변호사·회계사에게 확인하시기 바랍니다.

댓글

이 블로그의 인기 게시물

Google I/O 끝나고, 1편을 다시 펼쳤다

AI랑 4개월 일하면서 네 번 같은 자리에서 막혔다

M4 맥북에서 로컬 LLM으로 5일을 살아본 후