블로그 글을 너무 오래 쉬었다. 가장 최근 글이 9일 전(7월 20일)인데, 글을 안 썼을 뿐 프로젝트는 계속 굴리고 있었다.
그간 만든 것들:
- 검색량 증가에 따른 주가 급등·급락 모니터링
- 가상 외주 시나리오로 만드는 도자기 공예 예약 시스템
- 저장 없이 이미지도 붙이고 텍스트도 남길 수 있는 자유 연습장
이 중 끝까지 간 건 주가 모니터링이고, 지금은 도자기 공예 클래스 예약 시스템을 만들고 있다. 이것저것 서비스를 만들면서 깨달은 게 몇 가지 있어서 정리해둔다.
Table of contents
Open Table of contents
1. 시작하기 전에 ‘가능성’부터 검증한다
프로젝트 개요를 짤 때 “이건 이걸로 구현하자”고 정해둔 방법이, 막상 실제로 구현하려 들면 한계에 부딪히는 경우가 종종 있었다.
- 생각지도 못한 요금을 내야 한다든가
- 확장성에 불리하다든가
- 최신 자료를 반영하지 못해서 뒤늦게 다시 확인해야 한다든가
초반에 “이걸로 하자”고 정했으면, 실제로 그 방법으로 될지를 그 시점에 검증하는 게 중요하다는 걸 느꼈다. 나중에 벽을 만나 통째로 갈아엎는 것보다, 처음에 5분 확인하는 게 훨씬 싸다.
2. AI가 너무 잘해서 — 대안과 trade-off를 놓친다
기능을 구현할 때 나는 보통 “어떤 방법으로 만들 수 있을까”를 먼저 고민하고 AI에게 물어본다. 그런데 요즘 AI가 정말 좋아졌다. 예전엔 AI가 거짓말도 하고 코드도 잘 못 짜서 디버깅하는 재미라도 있었는데, 요즘은 그냥 맡기면 다 구현해버린다.
편한 만큼 함정이 생겼다. AI가 구현한 방법에 대해 대안을 생각하지 않고 그대로 쭉 이어가는 경우가 많아졌고, 그러다 보니 다른 선택지와의 trade-off를 따질 일이 줄었다.
이번 주가 모니터링을 만들면서 그 대가를 치렀다. “파이썬 예제에 많이 쓰인다”는 이유로 주가 정보를 pykrx로 가져왔는데, rate-limit에 걸리고 제대로 된 API 사용법 자료도 부족한 문제에 부딪혔다. 알고 보니 KRX가 주는 공식 open API가 있었다. 여러 대안을 미리 살펴보지 않아서 생긴 일이라고 생각한다. AI가 첫 번째로 내놓은 방법이 곧 최선은 아니었다.
3. 내가 약한 부분일수록 여러 안을 요청한다
반대로, 내가 약한 영역에서는 AI를 다르게 쓴다. 여러 안을 한꺼번에 받아서 고르는 방식이다.
나는 디자인 감각이 정말 없다. 그래서 UI를 바꾸고 싶어도 말로 설명하기가 힘들고, 레퍼런스를 복붙해서 설명하려 해도 그 레퍼런스를 찾는 것조차 버거울 때가 있다. 요즘 쓰는 방법은 클로드에게 디자인 시안을 여러 개 제안해달라고 하는 것이다. 그러면 서로 다른 컨셉의 디자인이 여러 개 나오는데, 그중 하나를 골라 다듬어나간다.
디자인뿐 아니라 객관적으로 딱 떨어지는 답이 없는 부분 — 문구를 넣는다든가 하는 — 도 마찬가지다. 여러 선택지를 받아서 고르거나, 거기서 아이디어를 얻어 변형해 적용한다. 정답이 하나가 아닌 영역에서는, 하나의 답을 받는 것보다 여러 개를 펼쳐놓고 고르는 게 나한테 맞았다.
마무리 — AI 시대에 내 값어치를 어디서 찾을까
요즘 정말 AI 성능이 좋아졌다. 그래서 한편으로는 개발자를 포함한 인력의 가치가 점점 줄어드는 것 같다는 생각도 든다. 취업은 어려워지고, 취업 시장에서 내 가치만큼 받지 못하는 것 같은 느낌도 있다.
그래서 요즘은 내가 할 수 있는 방법으로 직접 수익을 낼 방법을 고민하고 있다. 가상 외주 시나리오로 도자기 공예 예약 시스템을 만드는 것도, 크몽 같은 데서 외주를 시작해보기 위한 준비 과정 중 하나다. 실제 의뢰가 있다고 가정하고 처음부터 끝까지 만들어보면서, 외주라는 형태에 필요한 감각을 미리 익혀두려는 것이다.
세 가지 배움을 한 줄로 묶으면 결국 같은 이야기다 — AI에게 다 맡기되, 어디서 내가 판단을 얹을지는 놓치지 말자. 시작 전 검증도, 대안 비교도, 여러 안 중 고르기도, 전부 “AI가 준 것을 그대로 받지 않고 한 번 더 고르는” 자리다. 아마 그 고르는 감각이 AI 시대에 내가 값어치를 얹을 수 있는 지점이 아닐까 싶다.
더 들여다볼 것
- KRX 공식 open API 제대로 쓰기 —
pykrx대신 공식 API로 갈아탈 때의 인증·요청 형식·rate-limit 정책. 이번에 대충 넘어간 부분이라 제대로 정리 필요. - 기술 검증 체크리스트 만들기 — “시작 전 가능성 검증”을 매번 감으로 하지 말고, 요금·확장성·자료 최신성·rate-limit 같은 항목을 고정된 체크리스트로. 다음 프로젝트 개요 단계에서 한 번씩 훑도록.
- AI가 내놓은 첫 안의 대안 강제로 떠올리기 — 기능 하나를 구현하기 전에 “이거 말고 다른 방법은?”을 최소 한 번은 묻는 습관. trade-off를 놓치지 않기 위한 최소 장치.