MyStock - 리팩토링 효과를 보다

오늘 클리앙에서 AI 코딩에 대한 글과 댓글을 봤는데, 댓글의 일부은 내 생각과 매우 비슷했고 AI 코딩 능력이 매우 뛰어나더라도 사람인 개발자의 영역은 여전히 (당분간) 존재할 것이라고 생각한다. 개발자얘기 : 요즘 코드리뷰 하다보면 맘이 착잡하네요. : 클리앙유럽에서 개발자로 재직중인 K입니다. 이제 개발자들이 그냥 AI코드를 여과없이 올리는 상황이고 매니저들은 암튼 기능 추가가 빠르니까 그걸 그냥 받아들이는 형국까지 와버렸네요. 그 결과,www.clien.netAI 코딩이 보편화될수록 개별 구현보다 설계와 테스트 결과를 중심으로 검증하게 되는 건 맞지만, 최소한 시스템 구조와 주요 컴포넌트의 연결, 현재 구현이 원래 설계 방향과 맞는지는 사람이 계속 추적해야 한다는 내용이었다. 매니저가 코드와 구조..

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

MyStock - 드디어 투자분석 마무리

MyStock 투자분석 화면에는 기존에 시장심리를 보조지표로 표시하고 있었다. 여기에 수급을 붙여 외국인·개인·기관의 매매 추세까지 함께 확인할 수 있으면 좋겠다고 생각했다. 시작할 때는 이렇게 여러 번 방향을 바꾸게 될 줄 몰랐다. 가격과 거래량, 실제 체결 옆에 개인·외국인·기관의 움직임을 보여주면 분석할 정보가 있었으면 좋겠다는 생각에 추가했는데 실제 화면을 만들고 보니 문제는 데이터를 가져오는 것이 아니라 어떤 데이터를 어떤 해상도로 보여줘야 내가 판단하기 쉬운가였다. 이번 작업에서 ChatGPT와 Codex를 사용했지만, AI가 답을 하나 내놓고 그대로 구현한 과정은 아니었다. AI가 선택지를 정리하고 구현하면 내가 실제 화면을 보고 다시 판단했고, 그 결과를 바탕으로 또 방향을 바꾸는 과정에 ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 9. 5.
• 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

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 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

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

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

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

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

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

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

MyStock - UI 개선과 PR Workflow 구축 필요성 인식

최근 급격한 코덱스의 코딩량 증가와 GitHub Connector 무한 지옥에 빠져 주간 사용량이 많이 소진되어 이번주를 버티기 위해 MyStock Dashboard와 시황 분석 화면의 사용성을 개선하는 작은 UI 수정으로 시작했다. 처음에는 몇 가지 화면 요소를 추가하고 조정하는 수준의 작업으로 생각했다. 하지만 실제 변경 과정에서는 단순한 UI 수정으로 끝나지 않았다. 테마 관리, 설정 저장, 선택 상태 표현 등 기존 화면 구조와 연결된 문제를 확인하게 되었고, 변경사항을 안전하게 관리하고 검증하는 과정의 필요성을 인식하게 되었다.UI 개선 작업의 시작이번 변경 사항은 다음과 같다.Dashboard 연금 포함 여부 Switch 추가Light/Dark Mode 전환 기능 추가시장 데이터 추이 기본값 1..

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

MyStock - 투자분석 숫자에서 판단으로

MyStock은 처음에는 KIS Open API를 이용해 개인 계좌 잔고와 보유 종목을 확인하기 위한 도구로 시작했다. 계좌와 종목 데이터를 가져와 화면에 표시하면 개인 투자 관리 도구로 충분하다고 생각했지만 실제 사용하면서 문제가 드러났다. 데이터 숫자는 정확했지만 투자자가 실제로 궁금해하는 질문에는 답하기 어려웠다. 중요한 질문은 "현재 얼마가 있는가"가 아니었다. "내가 왜 이 종목을 가지고 있고, 언제 매수했으며, 지금 시장 상황에서 어떤 위치인가"였다.최초 문제 인식: 잔고 조회만으로 충분하지 않았다처음에는 보유 종목의 가격 흐름과 매수 시점만 확인할 수 있으면 충분하다고 생각했다. 그래서 투자현황에 계좌별 종목 매매 사항을 추가하였지만 직관적이지 않았다. 그래서 투자 분석 화면은 가격 차트와 ..

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

MyStock - 시황분석 고도화

MyStock은 처음에는 개인 계좌의 투자 현황을 확인하기 위한 도구로 시작했지만 실제 사용 과정에서 보유 자산뿐 아니라 현재 시장 분위기까지 함께 확인하고 싶다는 필요가 생겼고, 시황분석 기능 개발로 확장되었다. 처음에는 시장 지수와 몇 가지 지표를 추가하면 충분하다고 생각했다. 하지만 실제 구현 과정에서는 API 조회 속도, 데이터 구조 차이, 차트 표현 방식, Qt Thread 안정성 문제까지 연속적으로 발생했다. 결과적으로 이번 작업은 단순 UI 추가가 아니라 "어떤 정보를 보여줄 것인가"와 "어떻게 안정적으로 제공할 것인가"를 다시 고민하는 과정이 되었다.미장 & 국장 지수 정보Codex가 시황분석 템플릿으로 생성한 S&P500, NASDAQ, KOSPI 정보이면 시장 기본흐름은 충분하였으나, ..

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

MyStock - ETF 내부를 보기 시작하다

MyStock은 처음에는 KIS API를 이용해 개인 계좌 잔고와 보유 종목을 확인하기 위한 간단한 프로그램으로 시작했다. 처음에는 API 데이터를 가져오고 계좌와 종목을 화면에 표시하면 개인 투자 관리 도구로 충분하다고 생각했다. 실제 사용 과정에서 문제가 발견됐다. 평가금액과 잔고 데이터는 정확했지만 장기 ETF 투자자로서 궁금한 질문에는 답하기 어려웠다. 중요한 질문은 "현재 얼마가 있는가"가 아니었다. "내 자산이 실제 어디에 투자되어 있고, 내가 가진 ETF 내부에서는 어떤 변화가 발생하고 있는가?"문제는 데이터 조회가 아니라 투자자가 확인해야 하는 정보의 기준이었다.투자현황이라는 화면을 다시 정의하다단순 보유종목 조회 화면은 투자자가 실제로 관리하고 싶은 정보를 충분히 표현하지 못했다. 투자현..

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

MyStock - 예수금에서 시작된 데이터 모델 재설계

MyStock 개발 초기에는 KIS Open API 데이터를 조회하고 JSON으로 저장하면 투자 관리 앱의 기본 구조는 완성될 것이라고 생각했다. 하지만 한투 앱과 MyStock 화면을 비교하는 과정에서 예상하지 못한 문제가 발생했다. 숫자가 틀린 것이 아니라 같은 숫자라도 금융 업무 기준에 따라 의미가 달랐다.문제의 시작: 왜 예수금이 다르지?처음 확인한 것은 단순한 예수금과 평가금액 차이였다. 환율, D+2 정산, API 갱신 시점 등 여러 가능성을 확인했다. 하지만 확인할수록 단순 표시 문제가 아니라 금융 데이터의 의미를 다시 정의해야 하는 문제라는 것을 알게 됐다.예수금이라는 이름의 함정기존 MyStock에서는 cash 값을 예수금으로 생각했다. 하지만 금융 시스템에서 현금처럼 보이는 값은 하나가..

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