네가 만든 걸 누가 써?

최근에 어떤 분께서 제가 만든 제품을 보시더니, 그걸 누가 쓰냐는 말씀을 하셨습니다. 큰 기업에서나 할 법한 프로젝트를 너가 해서 누가 쓰냐는 말은 정말 많은 고민을 낳았습니다. 그리고 그 고민에 대한 이야기는 15년차 개발자와 함께 겪은 여정들을 편집해 이 글로 완성했습니다.

좀 더 쉽게 만들 수 없나요?

한 명의 개발자로서 프로그램을 만들고자 하는 욕구나 욕망이 이는 데는 거창한 목표가 있어서가 아닙니다. 그냥 지나칠 수 없는 한 마디가 없던 목표를 만들게 합니다.

"HMI 화면 디자인하기 불편한데, 좀 쉽게 만들 수 없나요?"

무엇에 끌렸을까요. 좀 더 쉽게 해달라는 말이었을까요.

해줄 수 있다는 설렘과 귀찮은데 하는 상반된 마음은 AI가 만들어 줄 수 없는 사람에게서 얻을 수 있는 소중한 니즈였습니다.

가짜 니즈일 수 있어도 현업에서 일하면서 어렴풋이 가지고 있었던 고민이었기에 바로 만들기 시작했습니다. 2024년 본격적으로 새로운 프로젝트를 파서 작업 궤도에 올렸습니다.

내가 곧 고객이다

그렇게 진짜 고객없는 제품 만들기가 시작되었습니다. 2년의 시간동안 라이브러리 전체를 갈아엎기만 수십번, 아예 설계를 부수고 다시 쌓기를 3번을 반복했습니다.

무대 공연 설비를 다루고, 공조기 모니터링 제어 툴을 만들고, 자동차 레이싱용 의자 설계 및 제어부터 김밥 커팅 기계, 스시 자동 제작 기계, 나아가 컨베이어 벨트까지. 설계부터 제어, 모니터링 했던 지난 날들의 경험이 몇 번이고 부수고 짓는 작업을 반복하고 만들었습니다.

그 시기에 Opus 4.6가 출시했습니다. 2026년 2월 6일. 설날을 앞두고, 내가 짜는 코드보다 더 잘 짜준다는 느낌을 받은 AI의 등장에 하나 둘씩 AI에 맡기기 시작했습니다. 더 좋은 제품이 탄생할 것이라는 생각에 설레였습니다.

그러나 큰 착각이었습니다. AI는 제품을 완성시키지 못했습니다. 설계도를 주고, 70% 결과물을 만드는데는 너무나 탁월했으나, 100%를 마무리짓는 단계까지 가질 못했습니다. 마치 일부러 만들기 싫은 것마냥 TDD 코드를 위한 코드만 계속해서 작성하고 있는 모습을 보게 됩니다.

버그도 하나의 객체에 대해 2~3개 정도 나오던 버그가 10개가 넘어가기 시작했습니다. 사용하지 않는 메서드는 방치되었고, Bolier-Plate 코드는 늘어만 갔습니다.

A1에 대한 결과를 A2를 만들고, 그 결과를 다시 A3을 만들고, 또 A4를 만드는 모습에서 오히려 수정해야할 코드양만 늘어났고, 개발기간은 지체되기 시작했습니다.

이렇게 두고 볼 수 없어 다시 처음부터 하나하나 꼼꼼히 검토하고 AI가 짜면 수정하고, AI가 잘 짜지 못하는 부분은 다 다시 짜는 행위를 반복해 대부분의 코드를 직접 짜 퀄리티를 높이는 방향으로 다시 잡았습니다.

완벽주의

퀄리티를 포기할 수 없었던 마음에 부수고 지을 때마다 규모와 기능은 커져만 갔습니다.

처음에 "쉽게 만들어 달라는" 요구는 점차 무거운 기능들이 추가된 또 다른 대기업 제품처럼 보이기까지 했습니다.

AI의 성능이 급격히 좋아졌던 2026년 2월이후 3월부터 본격적으로 스킬에 하네스 엔지니어링 설계 체계를 디테일하게 다듬기 시작했고, 모든 문서와 코드들을 일일이 검증했습니다. 잠을 자고 먹는 시간을 제외하고 이 프로젝트에 매달렸습니다.

각종 훌륭하다는 스킬들은 다 썼습니다. superpowers, andrej-karpathy-skills, garrytan/gastack과 같은 스킬들을 사용하면서 이들과 라이브러리의 차이점과 스킬들의 차이점을 분석하고 수정하기를 반복했습니다.

반복된 채우기는 비대해진 라이브러리가 되었습니다. mcp도 연결하고, 중간 통신을 위한 게이트웨이도 고려하다보니, 어느 순간 쉽게 라는 단어와 거리가 먼 프로그램을 제작하고 있었습니다.

그렇게 출시하고 처음들은 말

"이렇게 느리고 무거운데 누가 써?"

답답했던 퀄리티를 올리기 위한 작업들에 시간만 쏟아부어 만들다보니 어쩔 수 없었다고 외쳤지만, 실제 사용자들은 등을 돌리는 선택을 낳았습니다.

통신, 이벤트, 컨트롤, 화면 UI/UX, 게이트웨이, 서버, 배포라인, 실무 로직, 알람, DB, 로그를 AI와 인터뷰 과정에서 설계를 돕게 만들었습니다. 그 설계로 라즈OS와 윈도우OS에서도 동작하도록 자동배포까지 해주는 과정은 심었습니다.

숙련된 사람도 일주일 걸릴 문제를 7시간 안에 해결할 수 있다는 자신감을 주었다고 생각했습니다. 그러나 그 과정을 모르는 사용자들에겐 그저 사용하기 무겁고 답답한 툴에 불과했습니다.

뭐가 그리 답답하냐는 말에 이 설계를 위해서 1시간 넘게 기다려야하는 상황이 답답하다고 합니다.

혹은 너무 꼼꼼히 물어보는 질문에 하나하나 답을 하는 과정에서 피로감을 느꼈다고 합니다.

실무에서 겪었던 상황이라 당연했던 질문이, 열번을 넘어가자 이 녀석이 자동으로 진행을 했으면 좋겠는데, 계속 질문하니 답을 하고 생각하는 과정이 반복되어 불편하다는 말이었습니다.

그것은 단순히 버튼 만들어서 연결하고 동작을 보고 싶은 경우에도 똑같은 불편함으로 이어졌습니다.

AI가 다 해주던데

"프롬프트 엔지니어링"
"컨텍스트 엔지니어링"
"하네스 엔지니어링"
"에이전트 엔지니어링"
"루프 엔지니어링"
...

한번쯤 들어봤을 엔지니어링 기법들은 전부 AI를 어떻게 잘 쓸 수 있을까에 대한 고민에서 나온 단어들입니다. 문제는 이 단어에서 가장 친숙한 "프롬프트 엔지니어링"이라는 단어가 ChatGPT가 처음 출시한 2022년 11월 30일 이후 단 4년도 안되는 기간에 "루프 엔지니어링"이라는 단어까지 발전했다는 것입니다.

발전에 쫓겨 어느순간 모든 방법들을 사용해보고 경험해보고 적용해보고만 있었습니다.

"뒤처지진 않을까?"

프로그램을 만드는 기간이 쌓이니 자연스럽게 뒤처지기 싫다는 마음으로 이어졌습니다. 2년이라는 기간은 그 무서움을 더 실감케 만들었습니다.

처음으로 돌아갔습니다.

쉽게를 기준으로 하나의 큰 모듈이었던 라이브러리를 여러 모듈로 쪼개고 부분부분 구현을 에이전틱 엔지니어링 방식처럼 연동하는 방식으로 전환했습니다.

처음으로 돌아가고 깨달았던 것은, 어느순간 관객과 소통하지 않는 사람이 되어가고 있었습니다.

AI는 정말 편리한 도구가 맞습니다. 그래서 개발이 즐거웠고, 힘들지만 하루하루 재밌게 일했습니다.

하지만 가장 밀접해야할 사용자와 소통과는 멀어졌습니다. 누가 쓰냐는 말은 새로운 문장이 아니었습니다.

물론 이렇게 나온 프로그램을 다시 만든다해도 제로 베이스는 아닐겁니다. 결국 내가 사용하는 프로그램을 넘어서서, 사람들이 사용하는 프로그램이 되기까지의 과정이 될테니까요.

여러분들은 어떤 프로그램을 만들겠습니까? 내가 좋은 프로그램입니까? 고객이 좋은 프로그램입니까?