무료 오픈소스로 AI 음성을 어디까지 구현할 수 있을까?

블로그에 작성한 개발 경험을 짧은 영상으로 만들기 위해 MyShorts를 구상하면서 처음에는 ChatGPT가 대본부터 이미지, 캐릭터 파츠와 모션까지 제작하는 방식을 생각했다. 실제로 이미지 파츠와 JavaScript를 이용해 5초짜리 로봇 애니메이션을 만드는 실험도 진행했다. 움직이는 캐릭터를 만들 수 있다는 가능성은 확인했지만, 다음 질문이 남았다. 영상마다 새로운 장면과 캐릭터가 등장한다면 제작에 필요한 자료를 매번 같은 방식으로 준비해야 할까? 이미지와 모션 파츠를 AI로 만드는 작업에도 생성 비용과 사용량이 들어간다. 유료 영상 생성 서비스를 추가로 구독하지 않고 영상을 제작하고 싶었던 만큼, ChatGPT가 모든 결과물을 직접 만드는 구조가 적절한지도 따져 볼 필요가 있었다. 그래서 제작 작업..

• format_list_bulleted Laboratory/실험노트
• · 2026. 10. 10.
• textsms

MyStock - 계좌 중심 투자 분석을 위한 JSON 품질 개선

MyStock에 투자 데이터를 쌓고 JSON으로 내보내 LLM에 분석을 맡기는 이유는 단순히 시장 동향을 알아보기 위해서가 아니다. 내가 실제로 보유한 상품과 거래 내역을 기준으로, 현재 시장에 어떻게 대응하고 앞으로 어떤 매매 전략을 검토해야 할지 판단 근거를 얻고 싶었다. 처음에는 계좌 정보에 시장 지표, ETF 구성종목, 가격과 거래량, 투자자별 수급까지 담으면 충분할 것으로 생각했다. ChatGPT를 비롯한 LLM에 JSON을 전달하니 그럴듯한 분석 보고서가 나왔다. 미국 증시와 국내 산업 동향, 금리와 환율, 반도체 업황도 제법 자세하게 설명했다. 그런데 보고서를 읽고 나면 항상 같은 질문이 남았다.그래서 나보고 어쩌라고...?시장 상황은 알려주지만, 그 시장에서 내 계좌가 어떤 위치에 있는지,..

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

#8 - AI 코딩의 함정: 프로젝트 역할을 모르는 AI가 작업을 꼬이게 만들 때

이번 사건의 시작은 MyStock의 JSON Export 품질 개선이었다. MyStock은 내가 사용하는 투자 분석 프로그램으로, 계좌와 ETF 정보를 JSON으로 내보내면 LLM이 시장 상황과 연결해 분석하도록 구성하고 있다. 기존 분석 결과를 살펴보니 데이터는 상당히 들어 있는데도 ETF 구성종목이나 수급 변화가 충분히 활용되지 않는 부분이 있었다. 그래서 JSON에 담기는 사실과 분석 지침을 개선하고, 실제 분석 결과가 달라지는지 확인하려 했다. 새 대화방을 열면서 투자 데이터 분석용 인스트럭션인 MyStock.md를 실행했다. 당시에는 JSON을 분석하는 일이 출발점이었으니 자연스러운 선택이었다. 하지만 개발까지 이어질 작업이라는 점에서 중요한 것을 놓쳤다. ChatGPT가 MyStock 프로젝트..

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

ChatGPT를 이용한 YouTube Shorts 영상 생성 실험

지난 실험노트에서는 블로그의 AI 협업 사고일지를 YouTube Shorts로 바꾸는 방법을 살펴봤다. OpenAI API나 별도의 영상 생성 서비스를 쓰면 편하겠지만, 이미 내고 있는 ChatGPT 구독료에 추가 비용까지 얹을 생각은 없었다. 결국 대화형 ChatGPT에서 영상 제작 자료를 직접 만들어야 한다는 결론이었다.ChatGPT Work 영상 생성 결과와 맥락 문제첫 실험에서 Work는 약 20분 만에 38초짜리 숏츠를 만들어냈다. 로봇 캐릭터에 한국어 음성, 자막, BGM까지 붙은 MP4였다. 기술적으로는 성공인데... 너무 AI스럽고, 무엇보다 재미가 없었다. ㅡㅡ;; 그동안 ChatGPT를 갈구면서 쌓아온 AI 코딩 사고일지에는 황당한 상황과 그때의 판단이 녹아 있다. 그런데 Work 결과..

• format_list_bulleted Laboratory/실험노트
• · 2026. 10. 10.
• textsms

블로그 글을 Youtube Shorts로 생성하려면...?

요즘은 블로그 글보다 짧은 영상이 먼저 눈에 들어올 때가 많다. 유튜브를 켜면 숏츠가 연달아 나오니 나도 한번 시류에 탑승해 볼까 싶었다. 소재를 새로 찾을 필요는 없었다. 그동안 AI와 협업하면서 겪었던 사건일지 중에는 글로 읽어도 황당한 이야기가 제법 있다. 특히 신입 GPT가 인수인계 문서를 잘못 이해해 후임 GPT의 업무까지 진행한 사건은 로봇 캐릭터로 짧은 상황극을 만들면 재미있을 것 같았다. 한 편에 30~40초 정도면 충분하지 않을까? 대본의 방향과 내용은 내가 판단하고, 이미지부터 애니메이션, 음성과 편집은 평소처럼 AI에게 맡길 생각이었다. 가볍게 시작했는데, 영상을 만들기도 전에 비용 문제가 먼저 등장했다.AI 영상 생성 도구와 구독 비용유튜브에서 본 AI 숏츠 몇 개의 링크를 Cha..

• format_list_bulleted Laboratory/실험노트
• · 2026. 10. 9.
• textsms

AI 코드 리뷰가 놓친 10µs 인터럽트

지난 9월, STM32의 제한된 SRAM에서 PnC(Plug and Charge) 기능을 구현하기 위해 메모리 확보 작업을 진행했다. 당시 SECC 통신을 담당하는 GQSE 모듈의 UART 수신 구조를 슬롯 방식에서 링버퍼로 변경하고, 송신은 512바이트 스트리밍 방식으로 재설계했다. RX 링버퍼는 기양산 모델에서 8KB, 신규 모델에서는 32KB를 사용하도록 구성했다. 관련 내용은 이전 STM32 메모리 확보 작업에서 정리했다. 현재는 당시 검증했던 테스트 코드를 실제 개발(양산) 코드에 하나씩 반영하고 있다. 변경 범위가 크기 때문에 부분적으로 적용한 뒤 Codex 코드 리뷰와 테스트, GitHub Connector Review를 반복하면서 병합하는 방식으로 진행 중이다. 그 과정에서 흥미로운 일이 ..

• format_list_bulleted Embedded
• · 2026. 10. 8.
• textsms

하루 걸릴 리팩토링을 3시간 만에 - AI 코딩과 Connector Review

전기차 충전기 펌웨어에서 OCPP Configuration Key는 오랫동안 하나의 구조체와 테이블로 관리해 왔다. OCPP 표준 설정과 충전기 자체 기능을 제어하는 Custom Key를 한곳에 두고 읽기·쓰기 함수를 공용으로 사용하는 방식이었다. 처음에는 그 편이 단순했고, 관리하기에도 편했다. 그런데 충전기 기능이 늘어나면서 상황이 달라졌다. 충전사업자(CPO)별로 요구하는 기능이 조금씩 달랐고, 같은 충전기라도 어느 CPO와 연결되는지에 따라 사용해야 하는 Custom Key가 달랐다. 여기에 PnC(Plug and Charge) 관련 설정까지 추가되면서, 통합 구조체 안에 계속 Key를 늘리는 방식은 점점 부담이 됐다. 공용 코드가 문제였던 것은 아니다. 공용으로 관리할 설정과 CPO 전용으로 관..

• format_list_bulleted Embedded
• · 2026. 10. 8.
• textsms

#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