#7 - AI 코딩의 함정: 검증된 테스트 코드가 제품을 망칠 때

이번 주말 MyStock의 .env를 없애고 JSON Local Config로 바꾸는 작업을 하면서 예상하지 못했던 구조를 하나 발견했다. 처음에는 설정 파일 형식만 바꾸면 되는 작업이라고 생각했다. App Key와 Secret Key, 계좌정보처럼 GitHub에 올릴 수 없는 값을 .env 대신 로컬 JSON에 저장하고, 프로그램 안에서 사용자가 직접 등록할 수 있게 만들면 될 거라고 봤다. 그런데 실제 변경 범위를 따라가기 시작하자 수정해야 할 코드가 생각보다 너무 많았다. 단순히 .env를 읽는 부분이 많은 정도가 아니었다. STOCK, ETF, ISA, IRP처럼 테스트와 초기 구현에서 편하게 사용하던 계좌 이름과 슬롯이 프로그램 곳곳에서 계좌를 구분하는 기준처럼 사용되고 있었고, 그 영향은 UI..

• format_list_bulleted AI/Accidents
• · 2026. 10. 5.
• textsms

MyStock - Dropbox DB 동기화 기준과 Setup UX

MyStock은 집과 회사처럼 여러 PC에서 같은 데이터를 사용하고 있었고, SQLite DB는 Dropbox를 통해 서로 오가고 있었다. Schema 7이라는 새 기준을 만든 순간부터 Local DB와 Remote DB가 서로 다른 상태로 존재할 가능성이 생겼다. 한 PC는 이미 새 구조를 사용하고 있는데 Dropbox에는 이전 Schema의 DB가 남아 있을 수도 있었고, 반대로 새로 실행한 PC의 Local DB는 오래됐지만 Remote에는 현재 구조의 DB가 올라가 있을 수도 있었다. 그래서 마지막 단계에서 먼저 정해야 했던 것은 Setup 화면이 아니었다. Local과 Remote 중 어느 DB를 언제 기준으로 삼을 것인지, 그리고 둘의 상태가 다를 때 프로그램이 어디까지 자동으로 판단해도 되는..

• format_list_bulleted Laboratory/협업기록
• · 2026. 10. 4.
• textsms

MyStock - 하드코딩된 계좌 구조를 걷어내고 DB를 다시 설계하다

처음에는 App Key나 Secret Key처럼 외부에 공개할 수 없는 정보를 JSON으로 옮기고, 사용자가 직접 계좌정보를 등록할 수 있게 만들면 끝날 줄 알았다. 그런데 실제 코드를 따라가 보니 STOCK, ETF, ISA, IRP, FINANCIAL처럼 오래전부터 사용해온 계좌 이름과 슬롯이 단순한 설정값이 아니었다. API를 호출할 계좌를 고르는 기준이 되기도 했고, 화면의 그룹과 순서를 결정하거나 작업의 소유 계좌를 구분하는 데까지 사용되고 있었다. 더 큰 문제는 이 전제가 프로그램 코드 안에서 끝나지 않았다는 점이었다. DB에 데이터를 저장하고 다시 복원하는 과정에서도 비슷한 계좌 구분 방식이 이어지고 있었다. 여기서 선택해야 했다. 기존 구조를 최대한 유지한 채 JSON 설정만 덧붙일 수도 ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 10. 4.
• textsms

MyStock - .env를 없애려다 계좌 구조의 문제를 발견하다

MyStock은 한국투자증권을 비롯해 여러 OpenAPI를 사용한다. App Key, Secret Key, API Key 같은 인증 정보가 필요했고, 초기에는 이런 값과 계좌 관련 설정을 .env 파일에 넣어 사용했다. .env에는 외부에 공개하면 안 되는 인증 정보가 들어 있기 때문에 GitHub에는 포함하지 않았다. 소스 코드는 GitHub를 통해 여러 PC에서 쉽게 맞출 수 있었지만, .env만큼은 새 환경마다 따로 복사하거나 다시 만들어야 했다. 처음 문제로 느낀 건 딱 그 정도였다. 여러 PC에서 MyStock을 사용하다 보니 소스는 자동으로 맞춰지는데 인증 정보와 계좌 설정만 따로 관리해야 하는 게 점점 번거로워졌다. 그래서 사용자가 프로그램 안에서 OpenAPI의 App Key와 Secret..

• format_list_bulleted Laboratory/협업기록
• · 2026. 10. 4.
• textsms

#6 - AI 코딩의 또 다른 함정: 사용자의 결정을 AI가 덮어쓸 때

AI 사건일지를 쓰면서 프로젝트 맥락을 잃는 문제는 어느 정도 정리했다고 생각했다. 새 대화에서는 Repository와 _devlog를 다시 확인하고, 확인할 수 없는 내용은 임의로 연결하지 않도록 규칙도 만들었다. 그 규칙 중 하나가 UNKNOWN = ASK, NOT INFER였다. 모르면 추측하지 말고 나에게 물어보라는 뜻이다. 그런데 이번에는 조금 다른 문제가 생겼다. AI가 모르는 내용을 추측한 것이 아니었다. 이미 정해진 정책도 알고 있었고 작업 목적도 알고 있었는데, 자기 판단으로 사용자의 결정을 바꿨다.AI 코딩에서 문제가 된 것은 코드가 아니었다MyStock은 기능의 목적과 실제 동작은 내가 결정하고, ChatGPT와 요구사항을 정리한 뒤 Codex가 구현하는 방식으로 개발하고 있다. 구현..

• format_list_bulleted AI/Accidents
• · 2026. 10. 4.
• textsms

MyStock - Dropbox 동기화 #3 DB File Sync 구현과 UI

1부에서는 Dropbox를 이용해 SQLite DB를 안전하게 주고받을 수 있는지 POC로 확인했고, 2부에서는 언제 Pull하고 언제 Push할지, 충돌이 나면 어떻게 멈출지 정책을 정했다. 이제 구현 방향은 정리된 상태였다. Pull은 Startup에서만 하고, Runtime 중 DB를 갈아끼우지 않으며, Local과 Remote가 모두 바뀌었으면 자동으로 덮어쓰지 않는다. Windows와 macOS 모두에서 같은 정책으로 동작해야 한다는 조건도 포함했다. 이 조건을 기준으로 ChatGPT와 구현 경계를 정리했고, 실제 MyStock 소스 조사와 Production Sync 구현, 회귀 검증은 Codex에 맡겼다.Production Sync 적용Codex가 실제 Startup과 persistence ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 10. 3.
• textsms

MyStock - Dropbox 동기화 #2 DB File Sync 정책 설계

지난글에서 SQLite DB를 Snapshot으로 만들어 Dropbox에 올리고 다시 받을 수 있는지 POC를 통해 확인했다. Upload와 Download, DB 무결성 확인, 오래된 revision으로 최신 파일을 덮어쓰지 못하게 하는 충돌 처리까지 실제 Dropbox에서 검증했으니 처음에는 이제 MyStock에 붙이기만 하면 될 것 같았다. 그런데 파일을 안전하게 주고받을 수 있다는 것과 여러 PC에서 하나의 DB를 안전하게 이어서 사용하는 것은 전혀 다른 문제였다.DB 서버 대신 File Sync가장 단순한 방법은 사실 DB 서버를 두는 것이다. 회사 PC와 집 PC가 같은 DB 서버를 바라보면 어느 파일이 최신인지 비교할 필요가 거의 없다.회사 PC ─┐ ├─ DB Server집 ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 10. 3.
• textsms

MyStock - Dropbox 동기화 #1 DB File Sync POC

MyStock에서 클라우드 동기화를 다시 고민하게 될 줄은 몰랐다. 초기 MyStock에서도 비슷한 시도가 있었다. 당시에는 계좌의 자금 흐름을 파악하기 위해 KIS OpenAPI에서 조회한 계좌 상태를 JSON 형태로 저장하고 Google Drive를 이용해 여러 환경에서 같은 데이터를 사용할 수 있도록 구성했다. 그런데 실제로 사용하면서 생각하지 못했던 문제가 생겼다. KIS OpenAPI에서 조회한 계좌 예수금의 의미와 값이 내가 기대한 것과 달랐고, 자금 흐름을 맞추기 위해 만든 JSON과 동기화 로직의 책임은 점점 커졌다. 결국 어느 순간 이런 질문으로 돌아왔다.나 혼자 쓰는 프로그램인데 굳이 이 정도의 동기화가 필요한가?당시에는 Google Drive Sync를 제거하는 쪽을 선택했다. 계좌 ..

• format_list_bulleted Laboratory/협업기록
• · 2026. 10. 3.
• textsms

MyStock - RISE ETF 구성종목 30일 데이터를 다시 살리기까지

최근 회사에서 MyStock을 실행하면서 조금 이상한 장면을 봤다. 로컬 DB가 없는 상태에서 프로그램을 실행했고, MyStock은 보유 종목을 확인한 뒤 필요한 초기 데이터를 다시 구성하고 있었다. 대부분의 ETF는 별다른 문제 없이 넘어가는 것처럼 보였는데, RISE 쪽에서만 XLS 파일을 가져오지 못했다는 식의 메시지가 눈에 들어왔다. 당시에는 업무 중이라 깊게 파고들지는 못했다. 다만 RISE는 예전부터 과거 구성종목의 실제 기준 날짜를 확정하기 애매해서 historical canonical 대상에서 제외해둔 상태였다. 그래서 일단 “아직도 그 문제인가?” 정도로 기억해뒀다. 퇴근 후 집에서 다시 확인하기로 했다. 목적은 단순했다.RISE도 지정한 날짜의 구성종목을 실제로 가져올 수 있는지, 그리..

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

STM32 UART Overrun, Copy & Paste로 드러난 문제와 FIFO 적용

STM32에서 UART를 사용하면서 Overrun을 크게 신경 쓰지 않고 있었다. CLI 입력은 사용자가 키보드로 한 글자씩 입력하는 용도였고, 사람이 입력하는 속도라면 MCU가 충분히 따라갈 수 있다고 봤기 때문이다. 실제로 평소 사용에서는 별문제가 없었다. 문제는 시리얼 터미널에서 문자열을 Copy & Paste 했을 때 나타났다. 붙여넣은 문자열 중간에서 몇 글자가 빠졌고, 확인해보니 UART Overrun이 발생하고 있었다.Copy & Paste와 CLI Echo사람이 직접 키보드를 누르는 것과 Copy & Paste는 UART 입장에서 전혀 다른 입력이다. 직접 입력할 때는 문자 사이에 충분한 간격이 있지만, Paste를 하면 여러 문자가 짧은 시간에 연속으로 들어온다. 여기에 CLI 포트는 수..

• format_list_bulleted Embedded
• · 2026. 9. 30.
• textsms

ESP-IDF 4.4.3 - 최신 macOS에서 빌드시 발생한 Python 의존성 문제

이번 추석 연휴에는 그동안 미루고 미뤘던 회사 MacBook을 정리하기로 했다. 입사하고 3년 동안 한 번도 포맷하지 않은 노트북이라 회사 일을 하면서 설치한 개발도구와 테스트 프로그램이 계속 쌓여 있었고, Python도 이것저것 설치하다 보니 어느 순간부터는 현재 환경이 정상적인지조차 판단하기 어려운 상태가 됐다. 마침 최근 회사에서 진행한 작업도 블로그에 하나씩 정리하고 있었고, 연휴 동안 그 기록을 먼저 마무리한 뒤 노트북을 초기화하기로 했다. 문제는 초기화 자체가 아니라 그다음이었다. 포맷 전까지 잘 빌드되던 기존 ESP32 프로젝트를 같은 ESP-IDF 4.4.3 환경으로 다시 구성했는데, 최신 macOS와 Python 환경에서는 예전에 보지 못했던 오류가 연달아 나타났다.3년 만의 개발환경 초..

• format_list_bulleted Embedded
• · 2026. 9. 29.
• textsms

STM32 - KVAS 인증서 메모리 구조 재설계

STM32의 SRAM을 확보하는 작업을 계속하다 보니 이제는 단순히 버퍼 크기를 줄이는 것만으로는 부족했다. LVGL Display Buffer를 줄이고 UART 수신 구조를 다시 설계하면서 큰 메모리부터 하나씩 정리했지만, 앞으로 추가해야 할 PnC 인증서 처리를 생각하면 여전히 여유가 부족했다. 결국 지금까지 별문제 없이 사용하던 인증서 메모리 구조도 다시 볼 필요가 있었다.3KB 인증서를 계속 들고 있어야 할까기존 구조에서는 약 3KB 크기의 KVAS 인증서 정보를 OCPP 관련 구조체가 상시 메모리에 갖고 있었다. 구현만 생각하면 이 방식이 편하다. 부팅 시 KVAS 인증서를 이용해 배터리팩 정보를 암호화하기 위한 세션키를 생성할 때 바로 인증서를 참조할 수 있고, 인증서 만료 시점에 서버에서 갱..

• format_list_bulleted Embedded
• · 2026. 9. 27.
• textsms

STM32 UART Ring Buffer를 위한 8KB SRAM 확보

STM32G484에서 UART 수신 구조를 기존 슬롯 방식에서 링버퍼로 바꾸면서 예상하지 못했던 문제가 하나 생겼다. 수신 자체는 훨씬 유연해졌지만, 파서에 넘겨야 할 데이터가 항상 연속된 메모리 형태로 존재하는 것은 아니었다.링버퍼와 연속 데이터 문제링버퍼는 버퍼의 끝까지 데이터를 채운 뒤 다시 처음으로 돌아가면서 계속 사용할 수 있다. 문제는 하나의 메시지가 링버퍼 끝과 시작에 걸쳐 저장될 수 있다는 점이다. 논리적으로는 하나의 프레임이지만 실제 메모리에서는 두 구간으로 나뉜 상태가 된다.Ring Buffer[ ... Message A-1 ][ Message A-2 ... ] ↑ wrap-around논리적으로는 하나의 메시지물리적으로는 두 구간으로 분리UART RX 버..

• format_list_bulleted Embedded
• · 2026. 9. 27.
• textsms

STM32 UART RX 구조 변경, 슬롯 방식에서 8KB Ring Buffer로...

충전기 내부 통신 구조를 단순하게 보면 다음과 같다.┌─────────┐ UART ┌───────────┐ UART ┌────────────┐│ ESP32 │ │ STM32G484 │ │ SECC(GQSE) │└─────────┘ └───────────┘ └────────────┘ESP32는 서버 통신을 담당하고, SECC는 EVCC와의 ISO 15118 통신을 담당한다. 그리고 그 사이에서 STM32가 양쪽 데이터를 중계한다. 문제는 이 구조에서 가장 메모리 여유가 적은 STM32가 중계 역할을 맡고 있다는 점이었다. PnC 인증서 처리를 준비하면서 이 구조적 제약이 그대로 드러났다. EVCC와 서버 사..

• format_list_bulleted Embedded
• · 2026. 9. 26.
• textsms

6KB PnC 인증서를 위한 STM32 UART TX 버퍼 512바이트 스트리밍

충전기 내부 통신 구조를 단순하게 보면 다음과 같다. ESP32는 서버 통신을 담당하고, SECC는 EVCC와의 ISO 15118 통신을 담당한다. 그리고 그 사이에서 STM32가 양쪽 데이터를 중계한다.┌─────────┐ UART ┌───────────┐ UART ┌────────────┐│ ESP32 │ │ STM32G484 │ │ SECC(GQSE) │└─────────┘ └───────────┘ └────────────┘문제는 이 구조에서 가장 메모리 여유가 적은 모듈이 중계 역할을 맡고 있다는 점이었다. PnC 인증서 처리를 준비하면서 이 구조적 제약이 그대로 드러났다. 인증서 관련 데이터는 6KB를 넘어..

• format_list_bulleted Embedded
• · 2026. 9. 26.
• textsms