개발팀의 일하는 방식은 어떻게 진화해왔을까?

SI 공장에서 AI 협업까지, 스타트업 개발 문화 3단계 변천사

by 해결사

코드보다 먼저 바뀐 것들

스타트업에서 일하다 보면 가끔 이런 질문을 받습니다. "개발팀은 도대체 어떻게 일하는 거예요?" 사실 이 질문의 답은 시대마다 달랐습니다. 개발팀이 일하는 방식, 즉 업무 프로세스와 조직 문화는 지난 20여 년 사이 세 번의 큰 전환점을 거쳤습니다. 지금 제가 몸담고 있는 스타트업의 개발팀을 바라보면서, 그 변화의 흐름을 한번 정리해보고 싶었습니다.


1단계: 공장처럼 돌아가던 시절 — SI 프로젝트형 개발 프로세스


"기획서 나왔어요, 디자인 팀 넘깁니다"

지금으로부터 10~15년 전만 해도, IT 조직을 자체적으로 갖춘 회사는 많지 않았습니다. 소프트웨어가 필요하면? 외주를 줬습니다. SI(시스템통합) 업체라는 전문 개발 회사들이 이 역할을 맡았고, 그 안에서 독특한 조직 구조와 업무 방식이 만들어졌습니다.

직군이 촘촘하게 나뉘어 있었습니다. 기획자, 웹 UI 디자이너, 웹 퍼블리셔, 개발자, QA. 각자의 영역이 뚜렷했고, 일은 릴레이처럼 순서대로 넘어갔습니다. 기획자가 요구명세서와 스토리보드, 와이어프레임을 투박한 PPT로 만들어 디자이너에게 넘기면, 디자이너는 그것을 그대로 시각화했습니다. 지금 우리가 흔히 말하는 'UX'는 사실 이 시절엔 기획자의 영역에 더 가까웠습니다. 디자인은 아름답게 만드는 일이었지, 사용자가 어떻게 느끼는지를 설계하는 일이 아니었던 셈이죠.

디자이너가 완성한 화면을 개발자가 바로 받지도 않았습니다. 그 사이에 '웹 퍼블리셔'라는 직군이 있었습니다. 디자인을 HTML과 CSS로 변환하는 역할이었는데, 지금 생각해보면 디자인 언어와 개발 언어 사이의 통역사 같은 존재였습니다.

이 방식은 나름의 논리가 있었습니다. 각 단계의 산출물이 명확했고, 책임 소재도 분명했습니다. 하지만 한 가지 치명적인 약점이 있었습니다. 느리다는 것이었죠. 앞 단계가 완료돼야 다음 단계가 시작되는 폭포수(Waterfall) 방식 특성상, 중간에 방향이 바뀌면 모든 것을 다시 해야 했습니다.


2단계: 빠르게, 함께, 반복하며 — 애자일 스타트업형 문화


"일단 만들어보고, 틀리면 빨리 고칩시다"

2010년대 중반부터 스타트업 붐이 일어났습니다. 투자를 받고, 아이디어 하나로 팀을 꾸리고, 제품을 직접 만드는 조직들이 생겨나기 시작했습니다. 문제는 이 팀들에겐 돈도 없고, 시간도 없다는 것이었습니다. 외주를 줄 여유 자체가 없었죠.

결국 이들은 직접 개발 조직을 꾸리기 시작했고, 그 과정에서 기존의 공장형 프로세스는 자연스럽게 해체되기 시작했습니다. 스타트업에는 기획서를 6개월 동안 갈고닦을 시간이 없었습니다. 대신 이런 질문을 던졌습니다. "이게 진짜 고객이 원하는 건지, 일단 작게 만들어서 확인해봅시다."

여기서 애자일(Agile) 방법론이 자리를 잡습니다. 스쿼드(Squad)라는 소규모 팀이 하나의 문제를 빠르게 해결하는 방식이었습니다. PM/PO를 중심으로 디자이너와 개발자가 함께 앉아 일했고, 기획과 디자인과 개발이 순서대로 진행되는 게 아니라 동시에, 반복적으로 이루어졌습니다.

디자이너의 역할도 크게 확장됐습니다. 예쁜 화면을 만드는 것에서 나아가, 사용자가 제품을 어떻게 경험하는지를 설계하는 UX 영역까지 담당하게 된 것입니다. 그리고 피그마(Figma)가 등장하면서, 디자이너가 만든 결과물이 개발자에게 훨씬 더 명확하게 전달될 수 있게 됐습니다. 웹 퍼블리셔라는 직군은 특수한 경우를 제외하고 서서히 사라지기 시작했습니다. 툴이 사람의 역할을 대체한 첫 번째 사례였습니다.

이 시기의 핵심 가치는 '속도'였습니다. 완벽한 제품을 천천히 만드는 것보다, 불완전하더라도 빠르게 시장에 내놓고 반응을 보는 것이 훨씬 중요했습니다. MVP(최소기능제품)라는 개념이 모든 대화에 등장했고, 가설을 세우고 검증하는 사이클이 개발 문화의 중심이 됐습니다.


3단계: 지금 우리가 경험하는 변화 — AX(AI 전환) 시대


"AI가 코딩을 한다면, 우리는 무엇을 해야 할까"

그리고 지금입니다. AI 기술의 급격한 발전은 개발 조직에 다시 한번 근본적인 질문을 던지고 있습니다.

PM은 리서치와 PRD(제품요구서) 작성을 AI의 도움을 받아 훨씬 빠르게 합니다. 디자이너는 와이어프레임 초안을 AI로 뽑아내고, 개발자는 코딩과 테스트 코드 작성에서 AI를 실질적인 협업 도구로 씁니다. 불과 몇 년 전까지 사람이 며칠 걸려 하던 일들이, 몇 시간 혹은 몇 분 안에 초안이 나오는 세상이 됐습니다.

이 변화가 가져오는 함의는 단순히 "생산성이 올라간다"는 것에 그치지 않습니다. 더 중요한 질문이 생겨납니다. AI가 실행을 대부분 담당할 수 있다면, 그렇다면 사람은 무엇에 집중해야 할까요?

제가 지금 경험하고 있는 3단계의 개발 문화는 바로 이 질문에 대한 답을 찾아가는 과정입니다. 핵심은 이렇습니다.

문제를 어떻게 정의하고 구조화할 것인가. AI는 주어진 문제를 잘 풀어냅니다. 하지만 진짜 문제가 무엇인지 발견하는 것, 고객의 어떤 불편함을 해결해야 하는지 정의하는 것은 여전히 사람의 몫입니다.

얼리반젤스(Earlyvangelists) 같은 핵심 고객을 어떻게 찾아낼 것인가. 제품과 시장이 만나는 지점, 이른바 PMF(Product-Market Fit)를 만들어내기 위해 진짜 고객을 찾고, 그들의 목소리를 듣고, 제품에 반영하는 일은 여전히 깊은 인간적 통찰이 필요합니다.

제품이 회사의 숫자에 어떻게 기여할 것인가. 결국 제품팀이 존재하는 이유는 비즈니스 목표와 연결돼 있습니다. AI가 실행을 도와주는 만큼, 사람은 제품과 비즈니스의 연결고리를 더 선명하게 그려야 합니다.

흥미로운 점은, 이 3단계에서는 PO, 디자이너, 개발자, QA의 경계가 점점 흐려진다는 것입니다. AI를 사용하면 디자이너도 간단한 코드를 만들고, 개발자도 UX 관점의 의견을 냅니다. 어떤 역할이냐보다, 어떤 문제를 얼마나 깊이 이해하고 있느냐가 더 중요한 시대로 접어들고 있는 것입니다.


도구는 바뀌었지만, 질문은 같다

돌아보면 세 단계 모두 결국 같은 질문에 대한 답을 찾고 있었습니다. "어떻게 하면 고객의 문제를 더 잘 해결할 수 있을까?" 다만 그 질문에 답하는 방법이 달라졌을 뿐입니다.

1단계에서는 정해진 프로세스가 답이었습니다. 2단계에서는 빠른 반복이 답이었습니다. 그리고 지금 3단계에서는, 실행보다 사고에 집중하는 것이 답이 되고 있습니다.

저는 지금 이 변화를 실시간으로 겪고 있습니다. 솔직히 말하면, 적응이 쉽지는 않습니다. 하지만 분명한 것은, 이 변화를 받아들이는 팀과 그렇지 않은 팀의 차이는 앞으로 더 크게 벌어질 것이라는 점입니다. AI가 실행을 돕는 세상에서, 더 좋은 질문을 던지는 사람이 더 좋은 제품을 만들 것입니다.

여러분의 개발팀은 지금 어느 단계에 있으신가요?

매거진의 이전글UI/UX의 정답은 '미니멀리즘'이 아니다