자산관리 숫자, 지금 어디까지 믿어도 될까?

01 · 오래된 공책과 새 계산기

빨강 · 상세 화면 숫자가 크게 달라질 수 있어요

메인 화면은 거래원장 1,556건을 읽고 그때그때 FIFO로 다시 계산해요. 반면 일부 전략 상세 화면은 예전에 저장해 둔 realized_events라는 결과표를 읽어요.

메인 계산기 약 +2억 1,036만원 거래 1,556건 → FIFO 이벤트 1,209개

오래된 저장표 약 -2,091만원 특정 자산의 FIFO 이벤트 3개만 남아 있음

두 결과의 차이: 약 2억 3,128만원 (231,275,853원)

계산표가 다른 이유는 “계산 공식”보다 “들어 있는 자료의 범위”가 다르기 때문이에요. 저장표에는 2026년 7월 7일 매도 2건에서 나온 3개 분할 결과만 남아 있고, 다른 자산의 1,206개 FIFO 이벤트는 저장되어 있지 않아요. 그래서 여러 자산의 수익 기록은 메인 계산에는 들어가지만, 오래된 저장표에는 빠져 있어요.

이 저장표는 현재 자동으로 전체 거래를 다시 만들지 않아요. DB에는 저장표를 다시 만드는 기능은 있지만, 모든 자산에 대해 자동 실행하는 경로가 확인되지 않았고 저장 시각도 기록되어 있지 않아요. 정확히 언제 만들어졌는지는 확정할 수 없지만, 현재 남은 행이 특정 자산 2개뿐이라는 점은 확인됐어요.

중요: 이 2억 3천만원은 돈이 사라졌다는 뜻도, 메인 손익이 0원이라는 뜻도 아니에요. 오래된 답안지는 일부 문제만 풀었고, 메인 계산기는 전체 문제를 다시 푼 상태예요. 따라서 상세 화면을 고치기 전에는 메인 화면의 재계산 결과를 기준으로 봐야 해요.

빨강 보충 설명 · 시스템 안쪽 지도

원본은 하나, 답을 만드는 길이 두 개예요

DB를 학교 서랍장이라고 생각해 보세요. 실제 매수·매도 영수증은 한 서랍에 모여 있어요. 문제는 그 영수증으로 손익 답을 만드는 방법이 두 갈래라는 점이에요.

원본 영수증 · transactions 실제 매수·매도 수량, 금액, 수수료, 날짜를 보관하는 원장

길 1 · 메인 화면의 새 계산기

화면을 열면 원본 영수증 전체를 다시 읽어요.

계정별로 FIFO를 계산하고, 그 순간의 실현손익을 만들어요.

원장이 바뀌면 다음 계산에도 바로 반영돼요.

길 2 · 예전에 적어 둔 메모판

계산 결과를 lots와 realized_events에 미리 저장하는 기능이에요.

일부 전략 상세 화면은 원본을 다시 계산하지 않고 이 메모판을 읽어요.

지금 realized_events는 3건, lots는 0건이에요.

확인된 사실

메인 화면은 전체 거래원장으로 FIFO를 다시 계산해요.
전략 상세 화면 일부는 저장된 realized_events를 직접 합산해요.
새 거래가 들어온 뒤 모든 자산의 저장표를 자동 재생성하는 실행 경로가 확인되지 않았어요.
저장표에는 만든 시각과 계산 버전이 없어요.

코드 구조로 본 추정

처음에는 같은 계산을 매번 하지 않으려고 결과를 미리 저장했을 가능성이 커요. 이후 메인 화면은 더 안전한 “매번 다시 계산” 방식으로 바뀌었지만, 일부 전략 화면은 옛 메모판을 계속 읽도록 남은 것으로 보여요.

원래 작성자의 설명 기록은 없어서 이 부분은 추정이에요.

왜 자동으로 고쳐지지 않았을까요? 새 거래 수집은 원본 영수증 transactions를 바꿔요. 메인 화면은 다음 요청에서 새 원장을 다시 계산해요. 옛 저장표를 전체 자산 기준으로 다시 쓰는 자동 작업은 실행되지 않아요. 생성 시각·원장 버전·두 결과 비교 경고가 없어서 오래된 상태를 스스로 알리지 못해요.

향후 실제 수정 설계

나중에 고치는 안전한 순서

기준점을 먼저 저장해요DB와 현재 메인·상세 화면 수치를 백업해, 언제든 원래 상태로 돌아갈 수 있게 해요.
계산기를 하나로 통일해요모든 화면이 같은 FIFO 계산기를 사용하게 하고, 전략 상세 화면도 메인 화면과 같은 결과를 받아요.
옛 표는 바로 지우지 않아요lots와 realized_events를 읽는 것만 멈추고, 비교와 복구를 위해 잠시 보존해요.
화면끼리 답을 비교해요메인·자산 상세·전략 상세의 손익이 같아야 통과하는 자동 검사를 만들어요.
어려운 거래도 시험해요계정 분리, 수수료, 중복 체결 숨김, 매수 기록이 부족한 매도까지 같은 규칙으로 확인해요.
옛 표의 미래를 결정해요속도가 충분하면 제거해요. 꼭 필요하면 생성 시각·원장 버전·자동 재생성을 가진 안전한 캐시로 다시 만들어요.
조금씩 배포하고 되돌릴 길을 남겨요먼저 비교 모드로 확인하고, 차이가 없을 때만 화면을 전환해요. 이상하면 즉시 백업 버전으로 돌아가요.

목표 구조: 원본 거래원장 → 하나의 FIFO 계산 서비스 → 메인·자산 상세·전략 상세

02 · 연결 상태 읽는 법

노랑 · “연결 정상”은 계좌 읽기 성공과 달라요

컴퓨터가 자산 정보를 가져올 때는 서로 다른 문을 통과해요. 앞문이 열렸다고 뒷문까지 열린 것은 아니에요.

웹사이트가 켜짐

공개 가격 API가 작동함

개인 계좌 자료를 가져올 수 있음

공개 가격 문

로그인 없이 현재 가격만 보여 주는 문이에요. 이 문이 열리면 “가격 확인 가능”이라고 표시될 수 있어요.

개인 계좌 문

잔고와 거래를 읽는 비밀 문이에요. 이 문은 HTTP 401처럼 “인증이 안 됨”으로 막힐 수 있어요.

또 다른 증권사 연결은 예전 성공 기록을 보여 주지만, 최근 자동 수집은 토큰이 만료되어 실패하고 있어요. 그래서 새 거래나 출금이 화면에 늦게 나타날 수 있어요. 점검 당시 가격 시점만 맞춰 보았을 때의 차이는 약 6천원이었어요.

03 · 빠진 비용

노랑 · 수수료와 세금이 빠지면 이익이 좋아 보여요

거래 기록 중에는 매매 수수료와 세금이 0원으로 들어온 경우가 있어요. 실제로 돈을 냈다면, 화면의 손익이 그만큼 덜 나쁘거나 더 좋아 보일 수 있어요.

가능한 차이: 약 100만원

이 숫자는 세금 신고서가 아니에요. 실제 거래명세서의 수수료를 넣어야 정확한 답이 나와요. 지금은 “이익이 조금 부풀려졌을 수 있다”는 경고로 보면 돼요.

04 · 작은 빈칸

노랑 · 거래 한 줄의 짝이 비어 있어요

어떤 매도 기록에는 “언제 산 것인지” 연결할 구매 기록이 하나 부족해요. 지금 금액으로 계산한 영향은 약 100원 이하라서 아주 작아요.

그래도 작은 빈칸을 그대로 두면 나중에 거래가 많아질 때 계산을 설명하기 어려워져요. 기록을 찾아 한 줄을 채우거나, 외부에서 들어온 기록이라고 표시해야 해요.

05 · 다시 계산한 부분

초록 · 메인 계산은 다시 확인했어요

보이는 거래 1,556건을 따로 읽어 FIFO 방식으로 다시 계산했어요.

FIFO는 “먼저 산 것부터 팔았다고 보고 이익을 계산하는 규칙”이에요. 이 독립 계산 결과가 메인 화면의 실현손익과 맞았어요.

따라서: 메인 계산기의 덧셈과 기본 순서는 현재 믿을 만해요. 다만 입력 기록과 수수료, 연결 상태를 고치기 전에는 최종 정산 숫자로 쓰면 안 돼요.

다음 검사 순서

지금 해야 할 일

개인 계좌 연결의 인증을 다시 살펴보기
“웹사이트 정상”과 “계좌 자료 수집 성공”을 따로 표시하기
오래된 저장표를 새로 만들거나 사용하지 않기
빠진 거래 한 줄과 실제 수수료를 거래명세서로 확인하기