RicoCheesethe studio log · v2.0
Live · KRRead posts
목록으로
뉴스PUBLISHED · 2026년 7월 21일·8 MIN READ

만들 수 있다고 해서, 만들어야 할까? (You can build it. Should you?)

AI 도구로 누구나 소프트웨어를 만들 수 있는 시대, 20년 차 개발자 Jenna Pederson이 과거의 자신에게 보내는 편지 형식으로 '무엇을 만들어야 하는가'라는 질문의 무게를 되짚는다.

#ai#career#discuss#programming#productivity
You can build it. Should you?

개요 #

"만들 수 있는가?"라는 질문은 이제 너무 쉬워졌다. 답이 거의 항상 "그렇다"이기 때문이다. 20년 넘게 개발자들이 소프트웨어를 만드는 일을 도와온 Jenna Pederson은 과거의 자신에게 보내는 편지 형식의 글에서, 도구가 빠르게 바뀌는 시대일수록 정말 중요한 질문은 따로 있다고 말한다. "우리가 이걸 만들어야 하는가?(Should we build it?)"

그는 만드는 능력과 만드는 지혜를 혼동해서는 안 된다고 강조한다. 코딩을 몰라도 "영어라는 새로운 프로그래밍 언어"로 오후 한나절이면 앱을 만드는 시대가 왔지만, 무엇이 만들어질 가치가 있는지를 판단하는 기준은 오히려 더 높아져야 한다는 것이다.

본문 #

"만들 수 있는가"는 더 이상 어려운 질문이 아니다 #

Pederson의 커리어 대부분의 기간 동안 "만들 수 있는가?"는 어려운 질문이었다. 시간, 예산, 복잡도가 발목을 잡았고, 때로는 기술 자체가 아직 존재하지 않았다. 하지만 그런 제약은 대개 일시적이었고, 사람과 시간과 돈만 충분하면 거의 무엇이든 가능했다. 진짜 질문은 언제나 다른 곳에 있었다. 이걸 만들어야 하는가? 이게 우리 시간을 쓸 최선의 대상인가? 고객이 실제로 겪는 문제를 해결하는가, 아니면 새 문제를 만들어내는가? 우리는 무엇을 만들지 않기로 선택하고 있는가?

질문 자체는 변하지 않았지만, 질문을 둘러싼 환경이 변했다. Lovable, Bolt, Replit, Claude Code, Codex 같은 도구들 덕분에 소프트웨어를 만드는 장벽은 그 어느 때보다 낮아졌다. "만들 수 있는가?"에 대한 답은 거의 항상 "그렇다"가 됐고, 그래서 우리는 그냥 만든다. 이 질문이 주던 마찰이 사라지면서, 무엇이 만들어질 가치가 있는지 가려내는 기능도 함께 사라졌다.

건축 중인 목조 골조 Photo by Ulrick Trappschuh on Pexels

실험은 언제나 프로덕션이 된다 #

우리는 15분이면 되니까 만들고, 나중에 다시 다듬으면 되니까 만들고, 궁금하니까 만든다. 문제는 실험이 이상하리만치 자주 프로덕션이 된다는 점이다. 팀용으로 만든 내부 도구에 이제 누군가가 의존하고 있고, 어느새 오픈소스로 공개까지 됐다. 아이 축구팀을 위해 주말에 만든 프로젝트는 최신 API 변경 이후 업데이트가 필요해졌다. 자기 자신을 위해 AI로 뚝딱 만든 앱이라면? 축하한다, 이제 당신이 그 앱의 평생 유지보수 담당자다.

소프트웨어는 언제나 만들기보다 유지하기가 어려웠다. 테스트를 다시 돌아가게 만드느라 통째로 날린 스프린트, 의존성이 끌고 들어온 보안 취약점 수정, 세금 계산 서비스가 교체되면서 터져 나온 반올림 오류로 시스템 곳곳에서 1페니를 추적하던 기억. 엔지니어링 자원이 귀했기에 우리는 그 비용을 감수했고, 그 희소성이 오히려 "무엇이 존재할 가치가 있는가"라는 더 중요한 질문을 던지게 만들었다.

AI는 소프트웨어를 만드는 일을 극적으로 쉽게 만들었다. 그리고 새로 만들어진 앱, 기능, 스크립트, 내부 도구, 주말 프로젝트 하나하나가 결국 누군가의 책임이 된다. 만들기 전에 멈춰 서서 질문하게 만들던 마찰은 이미 대부분 사라진 상태에서 말이다.

코드는 애초에 차별점이 아니었다 #

만들기가 쉬워지면서 소프트웨어는 서로 닮아가기 시작했다. 모두가 같은 모델, 같은 도구, 같은 빌딩 블록을 쓸 수 있으니, 남들과 똑같은 소프트웨어를 만들기도 그만큼 쉬워졌다.

그렇다고 만들기를 멈추자는 이야기가 아니다. 기준선이 옮겨갔다는 뜻이다. 이제 차별점은 남들이 보지 못한 것을 봤는지, 고객과 그들의 문제를 깊이 이해했는지, 기능을 하나 더 얹는 대신 불필요한 것을 덜어냈는지, 할 수 있다는 걸 증명하려고 만든 게 아니라 풀 가치가 있는 문제를 풀었는지에 있다.

Pederson은 코드가 애초에 차별점이었던 적이 없다고 돌아본다. 함께 일했던 최고의 엔지니어들이 기억에 남은 이유는, 어떤 문제가 풀 가치가 있는지를 처음부터 알았기 때문이었다.

기준을 함께 끌어올려야 한다 #

그는 앞으로 "이게 애초에 존재해야 하는가?(Should this exist at all?)"라는 질문을 자신이 만드는 것뿐 아니라 남들이 만드는 것에 대해서도 더 자주 던지게 될 것이라며, 그 이야기는 다음 편지로 미뤄둔다.

글은 이렇게 마무리된다. 얼마나 빨리 만들 수 있는지 자축하고 싶어질 것이고, 그래도 된다. 하지만 만들기가 쉬워졌다고 해서 무엇이 존재할 가치가 있는지에 대한 기준까지 낮추지는 말 것. "만들 수 있는가?"에 답하기가 쉬워지는 속도만큼, "만들어야 하는가?"에 답하는 기준도 빠르게 끌어올려야 한다.


이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.