백상현의 개발 철학
먼저 증명하고, 그다음에 살을 붙입니다.
떠오른 생각을 흘려보내지 않고, 작은 실험으로 옮깁니다. AI와 함께 만드는 일이 빨라질수록 무엇을 확인할지, 어디까지 맡길지, 어떤 결과를 받아들일지는 더 또렷해야 한다고 생각합니다.
글 · 백상현
작은 불편 → 증명할 질문 → PoC → 사용하며 개선
글의 순서 보기
01
시작은, 매일 반복되던 작은 귀찮음이었습니다.
AI 소식은 매일 쏟아집니다. 새 모델이 나왔다고 하면 찾아보고, 쓸 만한 도구가 보이면 또 다른 페이지를 엽니다. 흐름을 놓치고 싶지는 않은데, 매번 소식을 찾아다니는 일은 번거로웠습니다. 그러다 이런 생각이 들었습니다. “이걸 매일 직접 찾지 않아도 되게 만들 수 없을까?”
baeksang.dev는 그 작은 질문에서 시작했습니다. 처음부터 지금의 사이트 전체를 구상한 것은 아닙니다. 먼저 확인하고 싶었던 것은 하나였습니다. 내가 찾아 읽던 AI 뉴스를 자동으로 모아 볼 수 있을까. 그 가능성을 먼저 검증하고, 필요한 것을 붙여 가며 지금의 모습으로 만들었습니다.
지금 이곳에서는 매일 AI·개발 소식을 모아 다이제스트로 전합니다. 제게 이 사이트는 완성된 결과물을 진열하는 공간이면서, 작은 불편이 어디까지 자랄 수 있는지 계속 확인하는 과정이기도 합니다.
02
생각이 떠오르면, 에이전트에게 바로 건넵니다.
아이디어는 책상 앞에 앉아 있을 때만 생기지 않습니다. 걷다가 떠오르기도 하고, 무언가를 쓰다가 불편함을 느끼는 순간에 생기기도 합니다. 나중에 정리하겠다고 넘기면, 생각뿐 아니라 그때 왜 필요하다고 느꼈는지까지 잊어버리기 쉽습니다.
제 폰과 컴퓨터에는 항상 켜져 있는 에이전트가 있습니다. 아이디어가 떠오르면 그 에이전트에게 바로 이야기합니다. 음성으로 생각을 전달하고, 메모해 두라고 하거나 지금 해 볼 작업을 시킵니다. 무엇이 귀찮았는지, 무엇을 바꾸고 싶은지, 어떤 가능성을 확인하고 싶은지를 그 순간에 건네는 것입니다.
문장이 잘 정리되어 있지 않아도 괜찮습니다. 떠오른 생각을 에이전트와 대화하며 구체화하고, 확인하고 싶은 것이 분명해지면 작은 PoC로 옮깁니다. 메모와 작업 지시가 같은 대화 안에서 이어지니, 생각이 떠오른 순간과 무언가를 시작하는 순간 사이의 간격을 줄일 수 있습니다.
03
한 가지가 되는지부터 봅니다.
AI와 대화하다 보면 기획은 금세 커집니다. 기능이 늘고, 문서가 길어지고, 아직 만들지 않은 서비스가 이미 완성된 것처럼 보이기도 합니다. 하지만 설명이 촘촘해졌다는 사실만으로 가장 중요한 문제가 풀렸다고 볼 수는 없습니다.
저는 거창한 기획에 앞서 “이번에 무엇을 증명하고 싶은가?”를 묻습니다. 그 질문에 답할 수 있는 최소한의 구현, PoC부터 만듭니다. PoC는 핵심 아이디어가 실제로 가능한지 확인하는 작은 실험입니다. 모든 기능을 갖추는 대신, 가장 중요한 로직이 작동하는지를 먼저 봅니다.
이 사이트라면 “필요한 뉴스를 자동으로 모아 볼 수 있는가?”가 출발점입니다. 가능성을 확인했다면 그다음에는 읽을 만한 결과인지, 계속 쓰는 데 무엇이 필요한지를 살펴봅니다. 한 가지를 확인한 뒤 다음 질문으로 넘어갑니다.
이 방식에서 계획은 실험을 도와주는 역할을 합니다. 무엇을 만들고 어떤 결과가 나오면 다음으로 넘어갈지 정하되, 아직 확인하지 않은 가정을 모두 확정된 사실처럼 쌓아 두지는 않으려고 합니다.
04
AI에게 맡길수록, 제 역할을 분명히 합니다.
AI를 잘 쓰는 데 가장 중요한 것은 역할의 범위라고 생각합니다. 사람은 무엇을 하고 AI는 무엇을 할 것인지, 어떤 결과를 사람이 확인해야 하는지가 분명해야 합니다.
이런 질문을 받으면 피라미드를 짓는 일에 빗대어 설명하는 편입니다. 예전에는 설계뿐 아니라 벽돌을 나르고 쌓는 데도 많은 시간이 들었습니다. AI는 그 실행에 드는 시간을 줄여 줍니다. 그만큼 저는 무엇을 지을지, 구조가 목적에 맞는지, 완성된 것이 제대로 작동하는지에 더 많은 시간을 써야 한다고 생각합니다.
구현을 맡기는 범위가 넓어져도 판단까지 저절로 해결되지는 않습니다. AI는 그럴듯한 오류를 만들 수 있고, 긴 요청 속에서 중요한 조건을 놓칠 수도 있습니다. 그래서 한 번에 거대한 작업을 넘기기보다 확인할 수 있는 크기로 진행하고, 결과를 보며 다음 방향을 정합니다.
무엇을 증명할지와 무엇을 성공으로 볼지는 제가 정합니다. AI와 함께 구현하고, 나온 결과가 그 기준에 맞는지 확인합니다. 제가 말하는 협업은 이 역할이 서로 이어지는 방식입니다.
05
지식이 많아지는 것과, 제 상황을 판단하는 것은 달랐습니다.
처음에는 AI가 가능하다고 말하면 제 프로젝트에도 맞는 선택이라고 생각했습니다. 직접 만들고 출시해보니 기술의 장점보다 먼저 물어야 할 것이 생겼습니다. 어느 플랫폼에서 쓸지, 운영과 업데이트를 얼마나 감당할 수 있을지, 지금 해결하려는 문제가 무엇인지 같은 조건입니다.
AI는 저보다 많은 기술을 압니다. 제가 쌓는 경험의 가치는 그 답을 현실에 놓고 보는 데 있다고 느낍니다. 모든 분야를 혼자 깊게 알기는 어렵지만, 일을 맡기고 결과를 판단할 만큼 여러 분야의 맥락을 이해하는 일이 중요해졌습니다.
원하는 결과와 차이가 나면 요구사항뿐 아니라 중간 검증과 작업 환경도 돌아봅니다. 작은 결과를 먼저 보고, 차이를 설명하고, 그때 알게 된 판단 기준을 다음 작업에 남기며 조금씩 맞춰갑니다.
06
작동하는 씨앗에, 필요한 만큼 살을 붙입니다.
PoC가 작동하면 비로소 다음 문제가 보입니다. 한 번 되는 것과 계속 쓸 수 있는 것 사이에는 차이가 있습니다. 실제 입력에서도 결과가 괜찮은지, 실패했을 때 다시 이어 갈 수 있는지, 읽거나 쓰는 사람이 불편하지 않은지를 살펴야 합니다.
그래서 처음부터 모든 것을 크게 만드는 대신, 확인한 결과 위에 필요한 기능과 구조를 더합니다. 구현하고, 사용하고, 불편한 부분을 고치는 과정을 반복합니다. 뉴스가 필요해서 시작한 이 사이트도 그렇게 자랐습니다.
자동화도 계속 쓰면서 다듬는 대상입니다. 반복해서 하던 일을 맡겼다면 실제로 수고가 줄었는지, 결과를 믿고 쓸 수 있는지 확인해야 합니다. 제게 중요한 것은 자동화했다는 사실보다, 그 자동화가 일상에서 도움이 되는가입니다.
07
하네스는 이 과정을 이어 주는 작업 환경입니다.
이곳에서 말하는 하네스는 아이디어를 전달하고, AI와 구현하고, 결과를 검증하며 다음 작업으로 이어 가도록 묶어 둔 환경입니다. 도구를 무엇으로 채웠는지보다 그 도구들이 어떤 질문을 해결하도록 연결되어 있는지가 중요합니다.
떠오른 생각을 남기는 입력 방식, AI에게 맡길 작업의 범위, 결과를 확인하는 기준이 서로 이어져야 합니다. 하나의 도구가 모든 일을 끝내 준다고 기대하기보다, 각 단계에서 필요한 역할을 맡기고 제가 판단할 지점을 분명히 하려고 합니다.
하네스 역시 작업을 하면서 바뀝니다. 실제로 도움이 되는 것은 남기고, 불필요하게 복잡한 부분은 덜어 냅니다. 만들고 싶은 것을 더 자주 시도하고, 그 결과를 더 잘 확인할 수 있는 환경을 만드는 것이 목적입니다.
이 생각에 이르기까지
처음에는 AI가 된다고 하면 되는 줄 알았습니다. 직접 앱을 출시하고 사이트를 운영하며 무엇부터 확인하게 됐는지, 우연히 개발을 시작했던 때부터 돌아봤습니다.
AI가 많은 일을 해주는 시대, 우리는 무엇을 알아야 할까 →