들어가며
본업에서는 C/C++로 검증 프레임워크를 짠다. 안전 크리티컬한 시스템을 다루다 보니 성능과 메모리 제어가 타협 불가능한 조건이고, 컴파일러가 잡아주는 타입 안전성에도 익숙하다. 그런데 정작 주식·코인 포트폴리오를 분석하는 사이드 프로젝트(toss-portfolio-analyzer)는 처음부터 끝까지 파이썬으로 짰다. 언어를 왜 다르게 골랐는지 — 그냥 “편해서”로 넘기기 전에, 이 프로젝트의 성격을 먼저 짚어야 한다.
이건 제품이 아니라 콘텐츠다
업비트랑 토스증권 API를 엮어서 주식·코인 통합 관리 앱을 만들면 수요가 있을지 고민한 적이 있다. 결론은 명확했다 — 제품으로는 약하고, 소재로는 훌륭하다. 뱅크샐러드·토스 자산탭 같은 마이데이터 사업자들이 이미 이 자리를 차지하고 있고, 개인이 API를 하나씩 붙이는 방식으로는 커버리지에서 구조적으로 밀린다. 게다가 증권 API 키를 개인이 만든 앱에 넣을 사람이 얼마나 될지도 의문이다.
그래서 방향을 틀었다. 팔 걸 만들지 말고, 공개할 걸 만들자. 두 개의 서로 다른 API를 붙여서 신뢰할 수 있는 하나의 뷰를 만드는 과정 자체를 글과 오픈소스로 내놓으면, 위에서 말한 장벽이 전부 사라진다. 그리고 이 결정 하나가 언어 선택에도 그대로 영향을 미쳤다. 목표가 “안정적으로 배포된 상용 앱”이 아니라 “빠르게 조립하고, 빠르게 검증하고, 그 과정을 빠르게 글로 옮기는 것”이라면, 기준이 되는 건 실행 성능이 아니라 검증 속도다.
실제로 겪어보니
toss-portfolio-analyzer를 만들면서 파이썬이 유리했던 지점은 추상적인 얘기가 아니라 전부 구체적으로 겪은 것들이다.
- API 스키마를 몸으로 확인하는 속도: 토스증권 API는 문서가 완전하지 않아서,
requests로 raw JSON을 찍어보고 그 자리에서 구조를 확인한 뒤 파싱 로직을 짜는 식으로 진행했다. 컴파일 없이 인터프리터에서 바로 실행하고 결과를 보는 루프가, 헤더 파일부터 정의해야 하는 C++ 워크플로우보다 압도적으로 빨랐다. - 버그를 잡는 속도: 이 프로젝트를 만들면서 accountNo/accountSeq 헤더 문제, 통화 키 대소문자 불일치, SQL 바인딩 개수 오류, 날짜 필터가 폴백 후보까지 걸러내던 버그까지 다섯 가지를 실제로 겪었다. 전부 에러 메시지를 즉석에서 출력해보고, 한 줄 고치고, 바로 재실행해서 확인하는 식으로 해결했다. 디버그 사이클이 짧을수록 “이 가설이 맞나”를 확인하는 데 드는 비용이 준다.
- 웹 뷰어가 며칠이 아니라 몇 시간 만에 나옴: Streamlit 하나로 파이차트·표·일별 추이 차트가 붙은 대시보드가 나왔다. C++이었다면 프론트엔드 스택을 통째로 새로 붙여야 했을 일이다.
- 데이터 생태계: pandas로 holdings 응답을 DataFrame으로 바꾸고, plotly로 바로 시각화하는 흐름 자체가 금융 데이터를 다루기 위해 이미 검증된 도구들이다. 이걸 C++로 직접 짰다면 프로젝트의 절반은 데이터 처리 인프라를 만드는 데 썼을 것이다.
반대로 본업에서 C++을 쓰는 이유 — 성능, 메모리 제어, 안전 크리티컬 요구사항 — 은 이 프로젝트엔 하나도 해당하지 않는다. 계좌 하나 조회해서 표로 보여주는 데 밀리초 단위 최적화가 필요할 리 없다. 오히려 이 프로젝트는 스코프가 계속 바뀌는 게 정상이다. CLI로 시작했다가 Streamlit으로, 다시 정적 HTML 리포트로 — 요구사항이 바뀔 때마다 가볍게 방향을 트는 게 더 중요했고, 무거운 언어로 짰다면 그때마다 치르는 비용이 훨씬 컸을 것이다.
법적 경계도 결국 같은 이유로 얇게 가야 한다
이 프로젝트는 조회 전용으로 선을 긋고 있다. 매수·매도 추천이나 목표가 제시로 넘어가면 유사투자자문 영역에 걸릴 수 있어서다. 수익률을 공개하더라도 절대금액 없이 검증 사례로만 쓰고, 종목명이 필요하면 마스킹하는 식으로 접근한다. 이 글도 투자 권유가 아니라 기록이다.
이 경계 설정도 사실 같은 원칙의 연장선이다 — 스코프가 좁고 가벼워야 방향을 틀기도, 접기도 쉽다. 무겁게 짜놓은 제품과 무겁게 약속해놓은 콘텐츠는 둘 다 되돌리기 어렵다.
이 결정을 기록하는 방법: ADR
이런 결정들이 나중에 “왜 이렇게 짰었지”로 흩어지지 않도록, 레포에 docs/를 두고 **ADR(Architecture Decision Record)**로 쌓기로 했다. 결정 하나당 짧은 파일 하나 — 배경, 고른 안, 버린 안과 이유, 결과만 담는다. 이 글이 사실상 그 첫 번째 ADR인 셈이다: “왜 C++이 아니라 파이썬인가.”
정적인 설계 의도는 docs/의 ADR로, 동적인 실행 상태(마지막 동기화 시각, 검증 게이트 통과 여부, 드라이런 여부)는 앱 안의 상태 탭으로 나눠서 관리할 계획이다. 이 둘을 섞으면 문서는 안 읽히고 화면은 지저분해진다. 그리고 이 상태 탭이야말로 **“믿고 손을 놓을 수 있는 루프를 짓는다”**는 이 블로그의 태그라인과 정확히 맞물리는 지점이다 — 손을 놓으려면, 놓아도 되는지 보여주는 창이 있어야 한다.
마치며
본업과 사이드 프로젝트의 언어가 다른 건 이상한 일이 아니다. 성능이 기준이면 C++이 맞고, 검증 속도가 기준이면 파이썬이 맞다. 이 프로젝트는 후자였고, 그 판단은 지금까지는 옳았다. 다음 ADR은 코어 로직과 UI를 분리한 이유가 될 것 같다.
댓글