MyStock - 자동갱신 하나 때문에 참 멀리 돌아왔다

자동갱신 하나 때문에 참 멀리 돌아왔다. MyStock 개발 초반에는 금융이나 주식 데이터의 생태를 잘 모르는 상태에서 기능 구현에 급급했다. AI에게 원하는 기능을 설명하고, 일단 내가 원한 기능이 동작하는지를 확인하면서 하나씩 기능을 추가했다. 그런데 기능이 늘어날수록 이 방식으로 계속 가면 신규 기능 하나를 추가할 때마다 AI가 확인해야 할 범위가 넓어지고, 추론과 디버깅에 드는 시간도 계속 길어질 것 같았다. 그래서 자동갱신 기능을 추가하기 전에 리팩토링부터 시작했다. 코드를 직접 작성하지 않고 AI에게 리팩토링을 맡긴다고 해서 금방 끝나는 일은 아니었다. 기존 동작을 유지하면서 책임을 나누고, 구조를 정리하고, 다시 확인하는 데 생각보다 상당한 시간이 들었다. 그렇게 한참을 돌아 이제서야 처음 ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 9. 2.
• textsms

Context Engineering...? 난 그런 거 모르는데...

티스토리 메인을 보다가 AI 코딩 관련 글 하나가 눈에 들어왔다.요즘 나도 ChatGPT와 Codex를 가지고 놀고 있으니 그냥 한번 눌러봤다. 읽다 보니 MCP, Skills, Sub-agent, Context Engineering 같은 용어들이 줄줄이 나왔고, 흠... MCP는 VS Code에서 본 적은 있다. 근데 관심 없었다. 대충 AI가 외부의 뭔가와 연결해서 쓰는 놈인가 보다 했고, 필요하면 그때 보면 되겠지 싶었다. 다른 용어들도 비슷했다. 그런데 Context Engineering이라는 부분은 읽다 보니 묘하게 익숙했다.Context Engineering... 이건 뭐지...?내가 이해한 Context Engineering은 프롬프트 한 번을 잘 쓰는 것보다, AI가 일을 제대로 할 수 있..

• format_list_bulleted AI/ChatGPT
• · 2026. 9. 2.
• textsms

MyStock 리팩토링 - 마무리, 재미없지만 없어서도 안 될 작업

MyStock의 첫 리팩토링을 마무리하며 버전은 0.1.0으로 올렸다. 앞으로 새기능을 위한 사전 밑작업이기 때문에 티도 안나고 시간과 토큰만을 잡아먹는 작업이었다. 미래를 위한 투자라고 생각하고 진했지만, 정말 가장 무료하고 재미없는 작업이었다. MyStock은 대시보드를 시작해 시황분석, 투자현황, 투자분석으로 기능이 계속 늘어났고, 기능이 늘어날수록 MainWindow에는 Worker와 QThread, cache, 요청 상태, 갱신 처리 같은 책임도 함께 쌓였다. 당장은 동작했지만 이 상태에서 기능을 계속 추가하면 변경 범위와 영향 관계를 매번 다시 추적해야 했다. 특히 나는 ChatGPT와 구조와 요구사항을 검토하고 실제 코드 분석과 구현은 Codex를 통해 진행한다. 구조가 불명확하면 기능 하..

• format_list_bulleted Laboratory/협업기록
• · 2026. 9. 1.
• textsms

MyStock - Phase 5, 소스가 아니라 기능의 책임을 분리했다

MyStock 리팩토링 Phase 5에서는 먼저 무엇을 더 고칠지부터 다시 확인했다. Phase 3과 Phase 4에서 원래 작업하려던 구조가 이미 앞선 Phase에 반영되어 있었기 때문이다. 이번에는 계획을 그대로 실행하지 않고 Step 0에서 현재 구조를 확인한 뒤, 실제로 MainWindow에 남아 있는 책임만 작업 범위로 잡았다.실제로 남아 있던 것은 세 가지였다확인 결과 투자 현황 화면과 관련된 ETF 현재 구성종목, ETF 과거 구성비, Trade history의 비동기 요청 책임이 아직 MainWindow에 남아 있었다. 세 기능 모두 화면 표시뿐 아니라 Worker/QThread, cache, 요청 상태와 lifecycle까지 함께 관리하고 있었다. 그래서 Phase 5에서는 세 기능을 한..

• format_list_bulleted Laboratory/협업기록
• · 2026. 9. 1.
• textsms

ChatGPT 인수인계 사고 감사착수

MyStock 리팩토링 Phase 4를 마치고도 한 가지 의문이 남았다. Phase 4에서 정리하려던 AnalysisController가 이미 Phase 2에서 구현되어 있었고, Phase 3에서 다루려던 RefreshCoordinator도 마찬가지였다. 한 번이면 이전 작업 범위가 조금 넓어진 것으로 생각할 수 있었다. 그런데 두 Phase가 연속으로 같은 상황이었다. Phase 2에서는 대체 무슨 일이 있었던 걸까?나는 ChatGPT 대화방 하나를 하나의 일감으로 사용한다원인을 찾기 전에 내가 ChatGPT와 Codex를 사용하는 방식을 먼저 설명할 필요가 있다. 나는 ChatGPT 대화방 하나를 하나의 일감처럼 사용한다. 여기서는 작업 목적과 방향, 범위, 설계에 대해 ChatGPT와 논의한다. 논..

• format_list_bulleted AI/ChatGPT
• · 2026. 8. 31.
• textsms

MyStock - Phase 4, 또 고칠게 없었다

MyStock 리팩토링 Phase 4는 AnalysisController 경계를 정리하는 작업이 될 거라고 생각했다. 그런데 Step 0에서 현재 구조를 다시 확인하자 시작부터 예상이 빗나갔다. Phase 4에서 만들려고 했던 AnalysisController가 이미 존재했다.Phase 3에 이어 또 이미 끝난 작업을 만났다이상한 일은 이번이 처음이 아니었다. Phase 3에서는 Account와 Market의 반복 갱신 Timer를 RefreshCoordinator로 분리하려고 했지만, 확인해 보니 그 책임 역시 Phase 2에서 이미 이동된 상태였다. 결국 Phase 3은 production code를 다시 수정하지 않고 기존 구조의 경계와 회귀 동작을 테스트로 확인하는 쪽으로 마무리했다. Phase ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 31.
• textsms

MyStock - Phase 3, 고칠 코드가 없었다

Phase 2 작업을 끝내고 main에 머지했다. Phase 3의 목표인 RefreshCoordinator 구현이었다. Account와 Market의 자동 갱신 Timer 책임을 MainWindow 밖으로 옮기고, 기존 옵션과 기본값, 갱신 주기와 동작은 그대로 유지하는 작업이었다. Phase 2가 꽤 큰 작업이었기 때문에 Phase 3 계획을 다시 확인하면서 처음 든 생각은 단순했다.이건 큰 작업은 아니겠네.그런데 실제 작업은 예상과 전혀 다른 방향으로 흘러갔다.Phase 3를 시작했는데 이미 끝나 있었다Phase 2 작업을 완료한 후, 상태에서 Phase 3 작업을 Codex에게 진행시켰는데 프롬프트 실행후 얼마되지 않아 바로 작업 완료 및 Codex가 PR까지 요청한 상태로 마무리 되어있었다.그리고..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 30.
• textsms

MyStock - Phase 2, 구조 변경보다 기존 동작 유지가 중요하다

Phase 2에서 MainWindow에 모여 있던 실행 책임은 Account, Refresh, Analysis, Market 쪽으로 하나씩 이동했다. 구조를 기능별 책임으로 나눈다는 방향 자체는 어렵지 않았다. 내가 중간중간 다시 확인했던 것은 리팩토링의 개념이 아니라, Codex가 실제 MyStock 코드에서 어떤 책임을 어디까지 옮겼고 그 객체들이 기존 실행 흐름과 어떻게 연결되는지였다. 코드를 직접 수정하면서 따라간 작업이 아니었기 때문에 Step 결과만 보면 pending/latest/stale, Worker retire, shutdown 같은 표현이 계속 등장했다. Before / After로 놓고 나서야 전체 구조는 보이기 시작했다. 그런데 구조를 이해하고 나니 다른 문제가 더 크게 보였다. ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 30.
• textsms

MyStock - Phase 2, MainWindow에서 실행 책임을 걷어냈다

지난 글에서는 MyStock의 구조를 한 번에 바꾸지 않고 Account부터 점진적으로 분리하기로 했고, Phase 1에서 실제로 그 첫 작업을 진행했다. Phase 2는 그 다음 작업이었다. 그런데 이번 작업에서 나는 Python 리팩토링 코드를 직접 수정하지 않았다. ChatGPT와 다음에 어떤 책임을 분리할지 검토했고, 그 내용을 Step별 프롬프트로 정리해 Codex에 전달했다. 실제 저장소 분석과 구현, 테스트는 Codex가 진행했다. 오히려 나는 Codex가 돌려주는 결과를 읽고도 무슨 작업을 했다는 것인지 잘 들어오지 않는 경우가 많았다. RefreshCoordinator, pending/latest/stale, QuoteStore 같은 이름은 계속 나오는데, 코드 자체를 보고 따라가는 방식..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 29.
• textsms

MyStock - Phase 1, 구조를 나눈 뒤 숨어 있던 버그를 찾았다

지난 글에서는 자동 갱신 기능을 다시 살펴보다 MyStock의 구조를 재검토했고, 전체 구조를 한 번에 변경하는 대신 AccountFeature부터 점진적으로 분리하기로 했다. 이번에는 그 판단을 실제 코드에 적용했다. 기존 기능을 모두 새 구조로 옮기는 것이 아니라 계좌 데이터의 책임부터 분리하고, 이미 안정화된 Worker와 QThread 동작은 최대한 유지하는 것이 첫 번째 Phase의 목표였다. 그런데 Phase 1 구현을 끝내고 직접 동작을 검증하던 중 예상하지 못한 문제가 하나 나타났다.Phase 1에서 Account 상태의 주인을 정했다첫 번째 작업은 MainWindow가 가지고 있던 계좌 관련 책임을 AccountFeature로 옮기는 것이었다. Phase 1에서는 AccountSnapsh..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 29.
• textsms

에필로그 - TPublisher

AI(ChatGPT / Codex)와 함께 개발하면서 쌓인 대화를 글로 만들고, 그 결과를 티스토리까지 자동으로 발행한다. 여기서 부터 시작했고 처음에는 정말 이 정도면 될 줄 알았다.ChatGPT → TPublisher → Tistory막상 시작해보니 생각처럼 단순하지 않았다. ChatGPT 공유 링크로 대화를 가져오는 방식부터 한계가 있었고, 결국 ChatGPT가 만든 결과물을 ZIP Package로 받아 처리하는 구조로 방향을 바꿨다. 그리고 이미지가 포함된 본문을 붙여넣는 과정이 느렸을 때는 처음에 TPublisher의 Clipboard 처리를 의심했다. 하지만 확인해보니 실제 병목은 Tistory Editor가 Base64 이미지가 포함된 HTML을 처리하는 과정에 있었다. 자동 발행을 살려보기..

• format_list_bulleted Laboratory/에필로그
• · 2026. 8. 28.
• textsms

MyStock - 자동 갱신 추가하려다 구조를 다시 설계하게 된 이유

MyStock은 처음에는 KIS Open API를 이용해 계좌 잔고와 보유 종목을 확인하는 개인 투자 관리 도구로 시작했다.계좌 잔고 조회보유 종목 확인평가 금액 확인그리고 필요에 따라 계좌 및 지수 정보를 갱신 주기를 설정할 수 있도록 하였는데, 이것은 최초 설계 단계에서 구상한 기능이 아니라 검증 단계에서 자동 갱신 기능이 있으면 좋겠다는 내 의견을 반영하여 Codex가 추가한 기능이다. 기능 구현 당시에는 자동 갱신이 잘 되는지 확인이 중요 관점이었고, 그 외 다른 부분은 고려대상이 아니었다. 그런데 어제 클라우드 싱크 기능 제거 후, MyStock 동작상에 문제가 없는지 확인 과중 중에 한가지 이상한 부분을 발견하였다. 대시보드나 시황정보에만 자동 갱신 Interval을 설정하게 되어있고, 대시보..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 28.
• textsms

MyStock - Google Drive Sync를 제거한 이유

MyStock 초기 개발 목적은 KIS Open API를 이용해 개인 투자 현황을 확인 했지만, 실제 사용 과정에서 단순 잔고 조회만으로는 부족한 부분이 있었다. CMA 잔액 변화, 투자 계좌 이동, 현금 흐름을 확인하고 싶었다. 그래서 당시에는 계좌 상태를 저장하는 Snapshot 구조와 Google Drive Sync를 설계했다.KIS API ↓계좌 Snapshot 생성 ↓Local JSON 저장 ↓Google Drive Sync ↓상태 비교 및 관리당시 판단은 합리적이었다. 데이터 보존, 여러 환경에서 동일 데이터 유지, Local과 Cloud 데이터 일치가 필요했기 때문이다.하지만 Sync 구조는 점점 커졌다기능이 추가되면서 단순 저장 기능이 아니라 동기화 시스템이 되었다.cash_flow.jso..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 27.
• textsms

TPublisher - 추론 모델 비교와 AI 협업 방식의 변화

TPublisher 안정화 단계에서 가장 어려웠던 부분은 코드를 어떻게 수정할지가 아니었다. 현재 구조를 얼마나 변경해야 하는지 판단하는 일이 먼저였다. 새로운 기능을 추가하는 단계와 이미 동작하는 프로그램을 안정화하는 단계는 접근 방식이 달라야 했다. 그래서 리팩토링 방향을 결정하기 위해 Sol Medium과 Luna Extra High에게 같은 문제를 검토하게 했다. 두 모델은 문제를 바라보는 방식에서 차이를 보였다.Sol Medium - 안정성을 우선한 점진적 개선Sol Medium은 현재 구조를 유지하면서 문제가 확인된 부분만 개선하는 방향으로 접근했다.기존 동작 유지변경 범위 최소화영향도 낮은 영역부터 개선테스트 가능한 단위로 변경결론은 대규모 구조 변경보다 안정화 단계에 맞는 최소 변경이 적합..

• format_list_bulleted Laboratory/협업기록
• · 2026. 8. 27.
• textsms

TPUB를 정리하다 깨달은 AI 협업 방식

TPUB는 AI 협업 과정에서 발생한 문제와 판단 과정을 블로그 마크다운으로 정리하기 위한 규칙으로 시작했다. 이후 하나의 명령으로 현재 대화를 분석하고, 발행할 콘텐츠와 필요한 패키지까지 일관된 형식으로 생성할 수 있도록 규칙을 계속 확장해왔다. 부족한 부분이 발견될 때마다 규칙을 추가하는 방식으로 수정하다 보니, 규칙이 늘어날수록 문제는 규칙의 개수가 아니라 각 규칙의 책임 영역이 섞이는 것이었다. 그리고 아무리 규칙을 추가하거나 강화시키더라도 내가 의도한 방향으로 동작하지 않고 동일 대화방이라도 그때그때 다른 결과물이 생성되니 종잡을 수가 없었다.사람과 LLM은 같은 명령을 다르게 이해한다내가 "TPUB 발행해줘"라고 요청할 때 기대한 것과 LLM이 이 요청을 처리하는 방식에는 차이가 있었다. 사람..

• format_list_bulleted AI/ChatGPT
• · 2026. 8. 26.
• textsms