MyStock을 처음 만들기 시작했을 때만 해도 이렇게까지 복잡한 이야기가 될 거라고는 생각하지 않았다. KIS Open API로 계좌 잔고를 확인하고, 보유 종목을 보고, 필요한 정보를 조금씩 붙여가면 되는 개인용 프로그램이었다. Python을 새로 공부해서 직접 만들 생각도 없었다. 이미 오래 개발 일을 해왔지만, 새로운 언어나 프레임워크를 다시 익히는 과정 자체가 목적은 아니었기 때문이다. 그래서 처음부터 한 가지 원칙을 정했다. 내가 Python 소스를 직접 작성하거나 세세하게 읽지 않고도, 필요한 프로그램을 계속 발전시킬 수 있는지 확인해보기로 했다.처음부터 코드를 이해하려고 시작한 프로젝트가 아니었다회사에서 개발할 때의 방식과 MyStock에서의 방식은 처음부터 달랐다. 회사 업무에서는 내가 ..
티스토리 메인을 보다가 AI 코딩 관련 글 하나가 눈에 들어왔다.요즘 나도 ChatGPT와 Codex를 가지고 놀고 있으니 그냥 한번 눌러봤다. 읽다 보니 MCP, Skills, Sub-agent, Context Engineering 같은 용어들이 줄줄이 나왔고, 흠... MCP는 VS Code에서 본 적은 있다. 근데 관심 없었다. 대충 AI가 외부의 뭔가와 연결해서 쓰는 놈인가 보다 했고, 필요하면 그때 보면 되겠지 싶었다. 다른 용어들도 비슷했다. 그런데 Context Engineering이라는 부분은 읽다 보니 묘하게 익숙했다.Context Engineering... 이건 뭐지...?내가 이해한 Context Engineering은 프롬프트 한 번을 잘 쓰는 것보다, AI가 일을 제대로 할 수 있..
이번 대화의 출발점은 새로운 기능을 개발하려는 계획이 아니었다. MyStock의 최초 개발 대화 기록을 잃어버린 일을 계기로, 앞으로는 하나의 개발 모듈이 완료될 때마다 TPUB를 바로 발행해 개발 과정과 판단 기록을 남겨야겠다는 생각이 들었다. MyStock 개발을 처음 시작했을 당시에는 아직 TPUB라는 방식을 만들기 전이었기 때문에, 최초 대화에 남아 있던 개발 과정은 별도의 기록으로 보존하지 못한 상태였다.그러던 중 우연히 AI Skill을 다루는 유튜브 영상을 보게 됐다. 영상을 보면서 가장 먼저 든 생각은 단순했다.“이거 TPUB랑 비슷한데?” ChatGPT에게 요즘 AI 분야에서 자주 등장하는 Skill이라는 개념이 정확히 무엇인지 질문했다. 처음에는 Skill을 특정 작업을 위한 재사용 가..
정말 시작은 단순한 이유였다. 증권사 앱을 오가며 확인하던 정보를 한 화면에서 보고 싶었고, Python은 모르지만 AI에게 코딩을 맡기면 내가 원하는 프로그램을 만들 수 있지 않을까 생각했다. 그런데 MyStock을 계속 만들다 보니 관심사가 조금씩 달라졌고, 프로그램 자체보다 더 궁금한 것이 생겼다. 내가 코드를 직접 작성하지 않고 요구사항과 구조를 정확하게 전달한다면 AI는 실제 소프트웨어 개발을 어디까지 맡을 수 있을까? 그리고 그 과정에서 내가 Codex에게 기능 명세뿐 아니라 변경 범위, 레이어의 역할, 모듈 간 책임, 건드리면 안 되는 영역까지 반복해서 지정하고 있다는 것을 깨달았다. 처음에는 AI가 엉뚱한 곳을 수정하지 못하게 하기 위한 제약이라고 생각했다. 하지만 이야기를 계속하다 보니 ..
이번 작업은 AI에게 구현을 맡겨보는 실험이 아니다. 회사 업무에서 요구사항 정리와 설계 수정, 실제 구현은 내가 직접 진행하고, AI에게 맡긴 영역은 범위를 명확히 지정한 일부 라이브러리 문제 분석, 구현이 끝난 뒤의 코드 리뷰, 그리고 릴리즈 노트 초안 정리였다. 처음부터 AI 리뷰를 계획했던 것도 아니다. 기획에서 UX 변경 요청이 들어왔고, 그 변경을 반영하는 과정에서 여러 곳에 흩어져 있던 상태 관리까지 하나의 기준으로 정리하게 됐다. 수정 범위가 점점 넓어졌고, 작업이 끝났을 때 변경 파일은 43개까지 늘어 있었다. 기능은 내가 의도한 방향으로 구현했지만, 이 정도 범위를 한 번에 수정하면 사소한 실수가 섞일 가능성이 있다. 그래서 구현을 다시 AI에게 맡기는 대신, 반대로 완성된 변경분을 최..
처음 TPUB를 만들려고 했던 이유는 단순했다.AI와 개발하면서 쌓이는 긴 대화 내용을 버리지 않고, 개발 과정의 고민과 판단을 블로그 기록으로 남기고 싶었다.처음에는 프롬프트만 잘 관리하면 된다고 생각했다Google Drive에 AI Prompt Library를 만들고 TPUB.md 같은 규칙 파일을 관리하면, 어느 대화에서도 동일한 기준으로 결과를 만들 수 있을 것이라고 생각했다.하지만 실제 테스트 과정에서 예상하지 못한 문제가 발생했다.문제는 규칙이 아니라 실행 과정이었다좋은 규칙 파일을 만드는 것만으로는 충분하지 않았다.AI가 작업을 시작할 때 최신 규칙을 확인하고, 참조 자료를 읽고, 정의된 출력 형식에 맞춰 결과물을 만드는 과정이 필요했다.최신 규칙 확인참조 자료 확인현재 대화 기반 콘텐츠 추..
AI에게 같은 설명을 반복하기 싫었다. "어떻게 하면 자주쓰는 프롬프트를 매크로 형식으로 만들어 관리할 수 없을까...?" 하는 고민에서 시작했다. 그래서 ChatGPT와 수없는 대화 끝에 Google Drive로 연동하여 나만의 AI Prompt Library를 만드는 것으로 결론에 도출하였다.AI와 협업하면서 새로운 문제가 생겼다MyStock과 TPublisher를 만들면서 AI와 함께 개발하는 방식을 계속 실험하고 있다. 처음에는 AI를 코딩을 도와주는 도구라고 생각했다. 하지만 프로젝트가 커질수록 조금 다른 문제가 보이기 시작했다.AI에게 개발을 시키는 것보다, AI에게 현재 상황과 기준을 전달하는 과정이 더 중요했다.새로운 작업을 시작할 때마다 같은 설명을 반복하고 있었다.프로젝트 목적코딩 스타..
AI를 개발 도구로 사용하기 시작했다MyStock을 만들면서 AI를 활용한 개발 방식을 본격적으로 경험하게 됐다. 처음에는 단순한 호기심이었다.AI에게 개발을 시키면 어디까지 가능할까?처음에는 AI를 코드를 만들어주는 도구라고 생각했다. 하지만 프로젝트를 진행할수록 생각이 조금씩 바뀌었다. 설계 방향을 고민하고, 문제 상황을 설명하고, 결과를 검토하는 과정에서 AI는 단순한 도구가 아니라 함께 고민하는 협업 대상에 가까워졌다.AI와 작업하는 방식에도 규칙이 필요했다프로젝트가 커질수록 새로운 문제가 생겼다. 개발 자체보다 AI에게 현재 상황을 설명하고 원하는 결과를 전달하는 과정이 점점 커졌다. 예를 들면 이런 작업들이 반복됐다.개발일지 작성GitHub PR 생성블로그 발행코드 리뷰 요청사람 개발자와 협업..