개발자는 아니지만 AI랑 시장감시 도구를 만들어봤습니다

이 글은 Market Surveillance Team의 서준원, 이민호 두 사람이 함께 만든 이상거래 상시감시 시각화 프로그램 개발기입니다.
"AI 덕에 대단한 거 해냈어요!" 같은 자랑글은 아니고요 😅, 개발이 본업이 아닌 두 사람이 AI와 부대끼며 실제로 뭘 배웠고 뭐가 아쉬웠는지 솔직하게 적어봤습니다.

들어가며

먼저 저희 소개부터 하겠습니다. 저희 둘은 개발자는 아닙니다. 컴플라이언스 부서 소속으로 시장감시가 본업이에요. 다만 업무 특성상 파이썬으로 스크립트 좀 짜고, SQL로 필요한 데이터 뽑아내는 정도는 늘 하던 사람들입니다. 딱 그 정도, "실무에 필요한 만큼"의 개발이죠.

그런데 지난 몇 달 동안 저희는 파이썬으로 데스크톱 프로그램을 하나 만들었습니다. 그것도 처음부터 끝까지요. 화면(GUI)도 있고, 데이터베이스에도 붙고, 여러 거래소에서 시세도 받아오고, 마지막엔 보고서 파일까지 알아서 뽑아주는… 나름 그럴싸한 놈입니다. 동료들 앞에서 발표하고 시연까지 했습니다!

사실 이 프로젝트, 시작은 회사에 Claude Code가 들어오기 한참 전이었습니다.

처음엔 정말 맨손으로 짰어요. 데이터 관련 스크립트야 좀 짜봤어도, "화면 있는 프로그램"은 완전히 다른 세계였습니다. 버튼 하나 원하는 위치에 놓겠다고 문서를 몇 시간씩 뒤지고, 차트가 생각한 모양대로 안 그려지면 원인 찾느라 하루가 그냥 날아가고… Stack Overflow와 공식 문서 사이를 무한 왕복하는 나날이었죠. 😵 "이게 되긴 되는 건가" 싶은 순간도 많았습니다.

그러다 전사적으로 Claude Code가 도입됐고, 개발 속도가 확 달라졌습니다. 다만 오해는 없으셨으면 하는데, "야 알아서 다 만들어줘" 하고 팔짱 끼고 있으면 되는 게 아니었어요. 만드는 내내 "아니 이게 대체 왜 이래…?" 를 백만 번쯤 물어야 했고, 그 삽질 덕분에(?) 저희도 개발자들이 쓰는 개념 몇 가지를 제대로 몸에 익히게 됐습니다.

이 글은 그 "익히게 된 것들"과, 그 과정의 삽질에 대한 기록입니다.

무엇을 만들었나

시장감시 업무라는 게, 다방면으로 확인해야 하는 작업이 진짜 많습니다. 특정 종목이나 계정에서 이상한 낌새가 보이면 화면이란 화면은 다 열어놓고 시세 보고, 계정 거래 패턴 뜯어보고, 입출금 살펴보고… 그리고 이걸 또 보고서로 정리해야 합니다. 손이 열 개라도 모자라요.

가장 큰 문제는 이 모든 게 여기저기 흩어져 있다는 거였어요. 대시보드 하나 뜨는 데 커피 한 잔 타올 시간이 걸리고, 데이터는 손으로 복붙하고, 차트는 하나하나 캡처해서 붙이고… 한 건 정리하고 나면 진이 다 빠졌습니다.

그래서 "이 흐름을 한 화면에서 끝내버리자" 하고 만든 게 이 프로그램입니다. 하는 일은 크게 다음 그림과 같아요.

핵심은 "입력 → 조회 → 시각화 → 보고서" 를 한 줄로 쭉 이어버린 겁니다. 예전엔 뿔뿔이 흩어져 있던 일들이 이제 버튼 몇 번이면 끝나요.

백문이 불여일견이니, 실제 화면부터 보여드릴게요. 아래는 종목 하나를 조회했을 때 뜨는 화면입니다. 거래소별 시세, 관련 뉴스, 프로젝트 발행 정보가 한 화면에 쫙 모입니다.

▲ 실제 구동 화면(종목 조회 탭). 거래소별 캔들 차트·뉴스·발행정보를 한 화면에 모았습니다. 공개를 위해 종목명·계정·수치는 전부 임의로 만든 예시 데이터로 대체했습니다. (그래서 종목이 실존하지 않는 "MOON"이에요.)

화면을 아래로 조금만 내리면, 거래소별 캔들 차트가 나란히 뜨고 그 아래엔 거래소별 수익률을 한 차트에 겹쳐 비교해줍니다. 어느 거래소가 먼저 튀는지, 격차가 벌어지는지 한눈에 보이죠.

▲ 같은 종목 조회 화면 하단. 거래소별 캔들 차트와 거래소별 수익률 비교 차트. (예시 데이터)

그래서 이거, 뭘로 만들었냐면

여기서 저희가 제일 겁먹었던 부분을 짚고 넘어가야겠어요. 바로 "화면" 입니다.

SQL로 데이터 뽑고 파이썬 스크립트 짜는 건 그래도 해봤어요. 그런데 버튼이 있고, 창이 뜨고, 마우스로 클릭하는 프로그램은 저희한테 완전 미지의 영역이었습니다. 웹으로 만들어야 하나? 앱으로? 뭘로 시작해야 할지조차 몰랐어요.

그래서 Claude에게 솔직하게 물었습니다. "우리는 파이썬은 좀 하는데 화면 만드는 건 처음이야. 사내에서 도는 데스크톱 프로그램 만들려면 뭐가 좋을까?"

그랬더니 대뜸 "이거 쓰세요" 하고 하나 던져주는 게 아니라, 선택지들을 비교표로 쫙 정리해줬어요. 파이썬으로 GUI를 만들 때 쓰는 대표 프레임워크들을 개발 난이도·디자인·사용성 기준으로 나란히요.

▲ Claude가 정리해준 비교표를 저희 상황에 맞게 다시 옮긴 것. (PySide 최종 선택)

이 표를 보면서 저희 상황에 하나씩 대입해봤습니다. 우리는 ① 이미 파이썬을 쓰고, ② 차트가 많아 '보기 좋은' 데스크톱 화면이 필요하고, ③ 사내에서 배포하니 라이선스도 신경 써야 했습니다. 디자인·사용성이 뛰어난 건 PyQt와 PySide 둘이었는데, PySide는 PyQt와 기능은 사실상 같으면서 라이선스가 더 유연하다길래 최종적으로 PySide6(파이썬용 Qt) 를 골랐습니다.

여기서 하나 배운 게 있어요. AI에게 "정답 하나만 줘"라고 하기보다 "선택지랑 근거를 정리해줘"라고 하니, 판단은 저희가 직접 할 수 있더라는 겁니다. 골라준 게 아니라, 고를 수 있게 도와준 거죠. 결국 최종 결정은 사람이 했습니다. 🙆

화면 골격만 정해진 게 아니었습니다. 구상한 시각화 자료를 구현하기 위해 필요한 도구들을 선택해야 했고, AI가 추천해 준 여러 패키지를 비교해서 각각 테스트해 보는 과정이 요구되었습니다.

• PySide6 — 화면(창·버튼·탭) 그 자체
• lightweight-charts — TradingView 차트 래퍼
• Plotly — 그 외 각종 분석 차트
• pandas — 늘 쓰던 데이터 가공 (이건 저희도 알죠 😎)
• ccxt — 여러 거래소 시세를 한 방식으로 받아오는 도구
• psycopg2 — 데이터 저장소 연결
• cryptography — 접속 정보 암호화
• python-docx — 마지막에 Word 보고서 뽑기

"알아서 정해줘"가 아니라 "왜 이걸 골랐는지 설명해줘"로 접근하니, 나중에 문제가 터졌을 때 어디를 봐야 할지 감이 잡히더라고요.

…라고 쓰면 여기서 글이 끝나는데, 저희가 진짜 하고 싶은 얘기는 지금부터입니다. 👇

AI와 일하며 (제대로) 배운 것들

만드는 내내 저희를 괴롭힌 건 "기능"이 아니라 "현상" 이었어요. 화면은 자꾸 멈추고, 프로그램은 예고도 없이 꺼지고, 데이터는 안 나오고… 매번 원인을 이해해야 다음으로 넘어갈 수 있었습니다. 이름만 알던 개념들을 이때 몸으로 이해하게 됐죠. 하나씩 풀어봅니다.

1. "왜 화면이 멈추지?" : 화면이랑 일은 따로 돌아야 하더라

조회 기능을 처음 붙였을 때, 조회 버튼을 누르면 프로그램 전체가 그냥 얼어붙었습니다. 창도 안 움직이고, 다른 버튼도 안 눌리고, 심지어 "응답 없음"까지 뜨더라고요.

원인은 알고 보니 단순했습니다. 화면 그리는 일이랑 데이터 받아오는 일을 같은 줄(Main Thread)에 세워놓으면, 무거운 일 도는 동안 화면이 통째로 멈춘다는 거예요. 카페에서 주문을 받는 직원이 원두 로스팅까지 하러 들어가버려 카운터가 빈 상황이랄까요. 😵‍💫

해결책은 무거운 일을 별도 일꾼(Worker Thread)에게 떠넘기는 것이었습니다. PySide6에는 QThread라는 일꾼이 있어서, 데이터 조회는 백그라운드에서 돌리고, 화면(메인 스레드)은 계속 쌩쌩 움직이게 두고, 일이 끝나면 "저 다 했어요~" 하고 신호(signal)를 보내 결과를 받는 구조로 바꿨어요.

"비동기"니 "스레드"니 하는 말은 저희도 들어는 봤어요. 근데 왜 필요한지는 이렇게 직접 화면을 멈춰 먹어보고 나서야 와닿더라고요. 이제는 다른 프로그램 쓰다 화면 멈추면 "아~ 무거운 일을 메인 스레드에서 돌렸구만" 하고 원인이 보입니다. 아는 척하기 딱 좋아졌어요 😎 (조회 중일 때 버튼이 👀 조회 → 🔍 조회 중... 으로 바뀌고 입력창이 잠기는 것도, 이 일꾼의 상태를 화면에 솔직하게 보여주려 넣은 장치입니다.)

2. "얘가 왜 갑자기 죽지?" : 안 죽는 프로그램 만들기

두 번째 벽은 진짜 멘붕이었는데요. 아무 이유도 안 알려주고 프로그램이 그냥 픽 꺼지는 것이었습니다. 어떤 종목은 멀쩡한데, 어떤 종목만 넣으면 창이 스윽 사라져요. 유언도 안 남기고요. 🫥

try/except 정도야 스크립트 짜면서 써봤지만, 이건 차원이 달랐습니다. 데이터 스크립트는 터지면 터미널에 빨간 에러라도 쭉 뱉는데, 화면 있는 프로그램은 아무 흔적도 없이 사라지더라고요. 여기서 두 개를 제대로 배웠어요.

• 로그(log): 예상 못 한 오류가 나면 원인 전체를 파일에 자동으로 남기게 했습니다(crash.log). 이름은 crash지만, 앱이 죽지 않고 버틴 오류까지 다 적힙니다. 그전엔 "그… 그냥 꺼졌어요…"밖에 못 했는데, 이제는 원인이 글로 남습니다. 사고 경위서 같은 거죠.
• 전역 예외처리: 예상 못 한 오류가 나도 프로그램 전체가 같이 죽는 대신, 오류를 붙잡아 "오류가 났지만 앱은 계속 돌아갑니다" 라는 안내창을 띄우고 꿋꿋이 버티게 만들었습니다. (심지어 백그라운드 일꾼에서 난 오류까지 잡도록요.)

이게 왜 중요하냐면, 이 프로그램은 저희만 쓰는 게 아니라 동료들이 쓸 물건이거든요. 동료가 "이거 안 돼요 ㅠㅠ" 하고 들고 오면, crash.log만 열어보면 무슨 일이 있었는지 대충 보입니다. "잘 되는 프로그램"이랑 "안 될 때도 안 죽고 왜 안 됐는지 알려주는 프로그램"은 급이 다른 물건이더라고요.

3. "데이터를 화면에 붙인다는 것" : 데이터 파이프라인

SQL로 데이터 뽑는 건 저희한테 익숙한 일입니다. 그런데 그 데이터를 실시간으로 화면에 붙이고, 차트로 그리고, 여러 소스를 엮는 것은 또 다른 얘기더라고요.

이 프로그램이 다루는 데이터는 크게 두 군데서 옵니다.

1. 내부 정보: 계정의 거래·주문·입출금 데이터. 목적별로 나눠 짜둔 조회 문(SQL)을 보내 필요한 것만 받아옵니다.
2. 외부 정보: 국내외 외부 API를 활용해 관련 필요한 정보를 받아옵니다.

이렇게 모은 데이터는 한 계정의 혐의를 한눈에 볼 수 있는 화면으로 정리됩니다. 아래는 특정 계정을 조회했을 때 뜨는 요약 대시보드예요. 부당이득·관여율·불공정 기간 같은 핵심 지표가 위에 뜨고, 유형별 상세가 카드로 쫙 깔립니다.

▲ 계정 조회 탭의 혐의 요약 대시보드와 유형별 상세 카드. (모든 UID·금액은 임의의 예시값)

그 아래로는 여러 소스를 엮어 만든 분석 차트들이 이어집니다. 시장 캔들 위에 이 계정의 체결·주문을 겹쳐 그리고, 연계 계정과의 체결·주문 중첩 비중까지 한 화면에 뿌려요. 예전엔 이걸 다 손으로 캡처해 붙였는데 말이죠.

▲ 시장가 대비 혐의자 주문가, 연계군과의 체결·중첩 비중 등 여러 데이터를 엮은 분석 차트. (예시 데이터)

여기서 새로 얻은 건 "성능도 설계의 일부" 라는 감각이에요. 조회 쿼리가 느리면 하염없이 기다려야 합니다. 그래서 "이 기간, 이 계정, 이 조건"으로 딱 필요한 만큼만 뽑도록 쿼리를 다듬고, 조회 기간도 최대 30일로 제한을 걸었어요. 예전엔 이런 제한을 보면 "왜 막아놨어" 싶었는데, 무리한 요청이 저장소에 부담을 준다는 걸 직접 겪고 나니 만든 사람 마음이 이해됩니다. 😌 익숙하던 SQL도, "사용자가 실시간으로 두드리는 화면 뒤"에 놓이니 완전히 새로운 고민거리가 되더라고요.

4. "화면은 어떻게 조립하지?" : 레고처럼 부품을 나눈다

스크립트는 위에서 아래로 쭉 실행되면 끝입니다. 그런데 화면 있는 프로그램은 사용자가 언제 뭘 누를지 모르니, 구조 자체가 완전히 달랐어요.

이 프로그램은 탭으로 나뉘어 있습니다. 종목 조회, 계정 조회, 입출고 조회, 보고서 작업 이렇게요. 처음엔 이걸 한 파일에 우겨넣으려다 금방 손을 못 대게 됐어요. 그래서 각 화면을 독립된 부품으로 뚝뚝 떼어내고, 부품끼리는 "신호"를 주고받게 했습니다. 예를 들어 한 탭이 조회를 시작하면 "나 지금 바빠!" 하고 신호를 쏘고, 그럼 다른 탭 버튼들이 알아서 잠깁니다.

마지막 탭인 보고서 작업이 이 흐름의 종착지예요. 조회한 내용을 골라 버튼 하나 누르면, 표와 차트가 들어간 Word 보고서가 자동으로 뚝딱 만들어집니다. (python-docx를 여기서 씁니다!)

▲ 보고서 작업 탭. 오른쪽은 자동 생성되는 보고서의 예시 모습입니다. (내용은 흐리게 처리한 예시이며, 실제로는 조회 내용이 표·차트로 채워집니다.)

프로그램/
├─ 화면(뷰)들      # 눈에 보이는 부분
├─ 일꾼(워커)들     # 뒤에서 데이터 받아오는 부분
├─ 조회 문(SQL)들   # 저장소에 물어볼 내용
└─ 도구(유틸)들     # 날짜 변환, 숫자 포맷 같은 공용 기능

왜 이렇게 나누냐면, 나중에 한 곳 고칠 때 엉뚱한 데가 안 터지게 하려는 겁니다. 사실 이거 업무 문서 정리하는 거랑 똑같더라고요. 한 파일에 다 때려넣는 것보다 목적별로 폴더 나눠두면 미래의 우리가 절합니다.

5. "이걸 대체 어떻게 넘겨주지?" : 보안과 배포

마지막 벽은 그 유명한 "어? 내 컴퓨터에선 되는데?" 였습니다. 개발자들이 밈으로 쓴다는 그 말, 저희가 직접 겪을 줄은 몰랐어요. 다 만들어놓고 보니 이걸 동료 컴퓨터에서 돌리려면 파이썬 깔고, 패키지 잔뜩 설치하고… 넘어야 할 산이 히말라야였습니다.

그래서 배운 두 가지.

• 가상환경 + 실행 스크립트: 필요한 패키지 목록을 파일 하나에 적어두고(requirements.txt), 더블클릭 한 번이면 알아서 가상환경 만들고 패키지 깔고 프로그램까지 켜주는 실행 파일(run.command)을 만들었습니다. "내 환경"을 "남의 컴퓨터"에서 그대로 재현하는 거죠. 🪄
• 설정 암호화: 이 프로그램은 내부 데이터 저장소에 접속합니다. 그 접속 정보를 코드에 그냥 박아두면? 큰일 납니다. 진짜 큰일 나요. 😱 그래서 접속 정보는 암호화해서 저장하고(cryptography), 그걸 푸는 열쇠는 사용자 각자 환경에만 두도록 분리했습니다.

이때 "민감한 정보는 코드랑 절대 붙여두지 마라" 는 원칙을 뼈저리게 이해했어요. 개인정보랑 접속정보에 예민할 수밖에 없는 업무다 보니, 이 부분은 기능만큼이나 공들인 지점입니다.

참고로 이 글에 실린 스크린샷도 같은 원칙을 지켰습니다. 실제 계정·수치가 노출되지 않도록, 프로그램을 '예시 데이터 모드'로 띄워 완전히 임의로 만든 가짜 데이터로 화면을 채운 뒤 캡처했어요. 그래서 종목이 실존하지 않는 "MOON"이고, 계정번호도 전부 가짜입니다.

뒤따라 도전할 분들께 : 우리가 얻은 교훈

몇 달을 부딪혀보니, 기술 지식보다 오래 남는 건 "AI와 어떻게 일해야 하는가" 에 대한 감각이었습니다. 개발이 본업이 아니어도 뭔가 만들어보고 싶은 분들께, 저희가 몸으로 얻은 교훈 몇 가지를 정리해 드립니다.

교훈 1. "질문의 질"이 곧 결과물의 질이다

AI는 물어본 만큼만 답합니다. "차트 만들어줘"와 "이 기간의 종가를 시가 대비 수익률(%)로 바꿔서, 거래소별로 한 차트에 겹쳐 그려줘"는 완전히 다른 결과를 냅니다. 처음엔 저희도 뭉뚱그려 물었다가 몇 번을 다시 시켰는지 몰라요.

원하는 걸 구체적으로, 조건을 쪼개서 말할수록 결과가 좋아졌습니다. 그리고 이건 결국 "내가 뭘 원하는지 스스로 명확히 아는가" 의 문제더라고요. 개발이든 업무든, AI 시대의 진짜 실력은 질문하는 힘이었습니다.

교훈 2. 작동해도, 이해하지 못한 코드는 넘기지 말자

가장 크게 배운 겁니다. "되니까 그냥 넘어가면" 반드시 나중에 그 자리에서 문제가 터집니다. 실제로 저희도 조회 날짜 범위가 의도와 다르게 계산되던 버그를 겪었는데, 딱 "이해 없이 넘긴" 부분이었어요.

그래서 습관을 하나 들였습니다. AI가 코드를 주면 "이거 왜 이렇게 되는지 한 줄씩 설명해줘" 라고 되묻는 것. 이해하고 넘어가면 다음에 비슷한 문제를 스스로 고칠 수 있지만, 이해 없이 넘어가면 매번 AI에게 처음부터 다시 물어야 합니다. AI를 '대신 해주는 사람'이 아니라 '가르쳐주는 사람'으로 쓸 때 실력이 남더라고요. (앞서 기술 스택을 고를 때 "왜 이걸 골랐어?"를 물었던 것도 같은 맥락이에요.)

교훈 3. 한 번에 크게 말고, 작게 쪼개서 자주 확인하자

"완성된 프로그램 하나 만들어줘"는 잘 안 됩니다. 나와도 어디가 잘못됐는지 찾기가 지옥이에요. 🫠 저희가 잘 굴러갔던 방식은 버튼 하나, 화면 하나, 기능 하나씩 만들고 그때그때 눌러보며 확인하는 거였습니다.

작게 만들고 → 바로 돌려보고 → 되면 다음으로. 이 리듬이 문제가 생겼을 때 원인의 범위를 좁혀줍니다. 방금 바꾼 데서 터진 거니까요.

교훈 4. "되게 만드는 것"과 "고치기 쉽게 만드는 것"은 다르다

기능을 급하게 갖다 붙이다 보면 파일 하나가 수천 줄까지 불어납니다. 당장은 돌아가지만, 나중에 한 줄 고치려고 그 긴 파일을 스크롤하다 보면 후회가 밀려와요.

그래서 지금은 만들기 전에 "어디에, 어떤 역할로 둘지"부터 그려봅니다. 화면 코드, 데이터 코드, 쿼리, 공용 도구를 폴더로 나눠두면 미래의 내가 편합니다. 이건 코딩이라기보다 정리 습관에 가까웠어요. 업무 문서 폴더 나누는 감각 그대로요.

교훈 5. 미래의 나(와 동료)를 위해 흔적을 남기자

프로그램에 로그를 남기게 한 것, 이 블로그 글을 쓰는 것 모두 같은 이유입니다. 오늘의 나에게 당연한 게 내일의 나에겐 하나도 안 당연합니다. 왜 이렇게 짰는지, 어떻게 켜는지, 무엇이 안 됐는지… 흔적을 남겨야 다음에 잊어버리지 않아요.

마치며 : 개발이 본업이 아닌 우리에게 AI란

Claude Code를 쓰기 전, 맨손으로 코드를 짜던 시절엔 프로그램이 종종 "마법 상자" 처럼 느껴졌습니다. 멈추면 멈추는 거고, 꺼지면 꺼지는 거고, 원인 찾겠다고 문서 사이를 며칠씩 헤맸죠. 근데 지금은 그 상자 안에서 무슨 일이 벌어지는지 어렴풋이 보입니다. 화면 멈추면 "무거운 일을 메인 스레드에서 돌렸네", 갑자기 꺼지면 "예외 처리를 안 했구만", 느리면 "쿼리가 너무 많이 도나?" 하고 짐작하게 됐어요.

AI가 저희를 개발자로 만들어준 건 아닙니다. 대신 "현상을 원인으로 번역하는 눈" 을, 그리고 그걸 예전보다 훨씬 빠르게 얻는 방법을 얹어줬어요. 그리고 이 눈은 저희 본업인 시장감시에서도 똑같이 쓸모가 있습니다. 이상 징후 뒤의 원인을 파고드는 일이니까요. 결국 하는 일이 비슷하더라고요.

파이썬이랑 SQL 좀 다룬다고 프로그램을 뚝딱 만들 수 있는 건 아니었습니다. 그렇다고 AI한테 다 맡기고 손 놓으면 되는 것도 절대 아니었고요. 그 사이 어딘가, 끊임없이 "왜?"를 물고 늘어지는 사람에게만 AI는 진국인 동료가 되어주더라고요. 그러니 궁금한 게 있으면 일단 물어보면 좋을 것 같습니다. 😄