AI로 구현이 빨라졌다.

코드를 작성하고, 테스트를 작성하고, 조사하고, 설계의 초안을 만드는 것.

이러한 부분들은 이전보다 상당히 짧은 시간 안에 할 수 있게 되었다.

그렇게 되면 문득 의문이 생긴다.

이제 대규모 인원으로 개발할 필요가 있을까?

회사에서 만드는 것보다 개인적으로 만드는 것이 더 빠르지 않을까?

애자일 (Agile)이나 PBI 관리는 아직 필요한 것일까?

이 부분에 대해 생각한 내용을 정리한다.

PBI는 Product Backlog Item의 약자.

스크럼 (Scrum)이나 애자일 (Agile) 개발에서 사용하는 프로덕트 백로그 (Product Backlog)의 한 항목을 말한다.

거칠게 말하면 "할 일 목록의 한 건"이다.

예를 들어,

• 로그인 기능을 만든다
• 검색 기능을 개선한다
• 관리 화면을 추가한다
• 결함을 수정한다

이런 것들이 PBI가 된다.

단, 본래의 PBI는 단순한 태스크 (Task)가 아니다.

중요한 것은,

• 왜 만드는가
• 누구의 과제를 해결하는가
• 어떤 가치가 있는가
• MVP (Minimum Viable Product)는 어디인가
• 이번에 하지 않을 것은 무엇인가

와 같은 정보다.

즉 PBI는 단순한 작업 관리가 아니라,

의사결정의 기록

이기도 하다.

워터폴 (Waterfall)은 개발을 위에서 아래로 순차적으로 진행하는 방식이다.

요구사항 정의
↓
설계
...

이름 그대로 폭포처럼 일방향으로 흐른다.

이 방식은 요구사항이 안정되어 있다면 합리적이다.

먼저 결정한다.

설계한다.

구현한다.

테스트한다.

다만, 도중에 변경 사항이 들어오면 부담이 크다.

"역시 이 기능은 필요 없어"

"다른 사양으로 하고 싶어"

"사용자의 반응이 예상과 달랐어"

라고 되면, 되돌리는 작업 (rework)이 커진다.

그래서 변화가 많은 프로덕트 개발에서는 애자일 (Agile)처럼 작게 만들어서 확인하는 방식이 사용되어 왔다.

AI에 의해 구현 비용은 상당히 낮아졌다.

예를 들어,

• 조사
• 설계 초안 작성
• 코딩 (Coding)
• 테스트 코드 작성
• 리팩터링 (Refactoring)
• 문서 작성

이러한 부분은 상당히 빨라졌다.

예전에는 몇 시간 걸렸을 작업이 몇십 분 만에 끝나는 경우도 있다.

그렇게 되면 개발자로서는 이렇게 생각하게 된다.

PBI를 깔끔하게 쓰는 것보다 AI에게 만들게 하는 것이 더 빠르지 않을까?

이는 자연스러운 감각이라고 생각한다.

워터폴 (Waterfall)은 일방향이다.

요구사항
↓
설계
...

하지만 AI 시대의 개발은 왕복이 훨씬 빠르다.

요구사항 ←→ 설계 ←→ 구현
↑ ↓
└──────────────┘

요구사항을 조금 바꾼다.

설계를 즉시 수정한다.

구현을 즉시 만든다.

돌려보고 다시 생각한다.

이 왕복이 굉장히 고속이 된다.

그렇게 생각하면 더 이상 "폭포"가 아니다.

오히려,

분수 형태

에 가깝다.

아래에서 위로 뿜어져 올라오고, 다시 떨어지며 순환한다.

즉,

애자일 (Agile)인가 워터폴 (Waterfall)인가

라는 분류 자체가 조금 낡은 것이 되어가고 있는지도 모른다.

이 부분이 중요하다.

AI에 의해 코드를 쓰는 속도는 올라갔다.

하지만,

• 무엇을 만들어야 하는가
• 어디까지 만들어야 하는가
• 누구의 과제를 해결하는가
• 정말로 가치가 있는가
• 이번 MVP는 어디인가
• 무엇을 하지 않을 것인가

는 여전히 어렵다.

오히려 구현이 빨라진 만큼 의사결정의 중요성은 높아지고 있다.

왜냐하면, 만들 수 있는 것이 늘어날수록,

무엇을 만들지 않을 것인가

를 결정해야 하기 때문이다.

PBI 관리가 번거로운 것은 이해한다.

다만, PBI의 가치는 "태스크 관리"가 아니라,

의사결정의 이력을 남기는 것

에 있다고 생각한다.

코드는 Git을 보면 알 수 있다.

하지만,

왜 이 기능을 만들었는가

왜 이 사양으로 했는가

왜 이번에는 여기까지 했는가

왜 이것은 보류했는가

는 남겨두지 않으면 사라진다.

특히 대형 프로젝트에서는 의사결정 이력이 사라지면 나중에 곤란해진다.

그래서 PBI는 앞으로,

작업 티켓

이 아니라,

의사결정 로그

로서 재정의되어 갈지도 모른다.

AI로 개발 속도가 올라가면 이렇게 생각하게 된다.

이거, 회사에서 많은 인원이 만드는 것보다 혼자 만드는 게 더 빠르지 않을까?

이것은 절반은 맞다.

소규모 프로덕트라면 개인이나 소수가 더 빠르다.

특히,

• 업무 툴
• 소규모 SaaS
• 사내 시스템
• 자동화 툴
• 니치 (Niche)한 웹 서비스

이러한 분야는 개인 개발의 강점이 나타나기 쉽다.

예전에는 혼자서는 만들 수 없었던 것을 AI 덕분에 혼자서도 만들 수 있게 되었다.

이것은 큰 변화다.

다만, 회사가 불필요해지는 것은 아니다.

회사의 가치는 코드를 쓰는 것만이 아니다.

회사에는,

• 계약 주체
• 책임의 소재
• 지속성
• 유지보수 체계
• 법무
• 영업
• 청구
• 서포트
• 보안
• 담당자가 부재해도 이어지는 시스템

이 있다.

즉 회사는,

개발력의 집합체

라기보다,

신용과 책임의 수용처

이기도 하다.

이 점이 개인과의 가장 큰 차이다.

가장 큰 차이는,

지속성과 책임의 수용처

라고 생각한다.

개인은 그 사람이 멈추면 전부 멈추기 쉽다.

회사는 누군가 한 명이 빠져도 조직으로서 계속할 수 있다.

기술력의 차이가 아니다.

지금은 개인이라도 회사보다 빠르게 만들 수 있는 경우가 있다.

하지만 클라이언트 입장에서 보면, 이렇게 보인다.

개인 = 능력은 높을지 모르지만, 의존 대상이 1명
회사 = 능력은 보통이라도, 지속되는 시스템이 있음

그래서 개인 개발자가 큰 일을 따내기 위해서는,

"저는 만들 수 있습니다"

만으로는 부족하다.

"저에게 무슨 일이 생겨도 시스템은 멈추지 않습니다"

를 보여줄 필요가 있다.

개인으로 일한다면, 앞으로는 코드 이외의 정비가 중요해질 것이다.

예를 들어,

• Git 관리
• README
• 설계서
• 환경 구축 절차
• 배포 절차
• 장애 대응 절차
• 백업 방침
• 유지보수 계약
• 인수인계 자료
• 대안으로 대응할 수 있는 협력자
• 소스 코드 에스크로 (Source Code Escrow)

이 정도다.

특히 클라이언트가 걱정하는 것은,

"당신에게 무슨 일이 생겼을 때, 이 시스템은 어떻게 되는가?"

이다.

이것은 기술의 문제가 아니다.

사업 지속의 문제다.

여기서 등장하는 것이 소스 코드 에스크로다.

소스 코드 에스크로란,

소스 코드나 설계 자료를 제삼자에게 맡겨 두었다가, 일정 조건이 발생하면 클라이언트에게 공개하는 시스템

이다.

예를 들어,

• 개발자가 사망했다
• 연락이 불가능해졌다
• 폐업했다
• 유지보수가 불가능해졌다
• 계약상의 공개 조건을 충족했다

와 같은 경우에 맡겨 두었던 정보가 공개된다.

이것은 개인 개발자에게 상당히 중요한 신용 보강이 된다.

외우는 법을 대충 말하자면,

에스크로 = 제삼자에게 맡기는 시스템

으로 이해하면 된다.

회사 개발은 앞으로,

많은 인원이 코드를 쓰는 곳

에서,

소수가 AI를 사용하여 의사결정을 하고 책임을 지는 곳

으로 변해갈 것이라고 생각한다.

과거의 회사 개발은 개발 공장에 가까웠다.

요건 정의를 하는 사람
설계하는 사람
구현하는 사람
...

처럼 분업화되어 있었다.

하지만 AI에 의해 작업 그 자체는 압축된다.

그러면 중요해지는 것은,

• 무엇을 만들 것인가
• 왜 만드는가
• 어디까지 만들 것인가
• 누구에게 가치를 전달할 것인가
• 어떤 리스크를 감수할 것인가
• 누가 책임을 질 것인가

가 된다.

즉 회사 개발은,

구현 조직

에서,

의사결정과 책임의 조직

으로 변해가는 것이 아닐까.

AI 시대에 가치가 올라가는 것은 단순히 코드를 쓸 줄 아는 사람이 아니다.

물론 기술력은 필요하다.

다만 그것만으로는 부족하다.

앞으로 강한 사람은,

• 과제를 정리할 수 있다
• 사용자의 어려움을 이해할 수 있다
• MVP (Minimum Viable Product)를 결정할 수 있다
• 우선순위를 정할 수 있다
• 기술과 비즈니스를 연결할 수 있다
• AI를 사용하여 고속으로 검증할 수 있다
• 만든 후의 운용까지 생각할 수 있다
• 클라이언트를 안심시킬 수 있다

이런 사람이라고 생각한다.

즉,

만들 수 있는 사람

보다,

무엇을 만들어야 하는지를 생각하고, 책임 있는 형태로 전달할 수 있는 사람

의 가치가 올라간다.

AI는 구현 작업의 상당 부분을 빼앗을지도 모른다.

하지만 전부를 빼앗지는 않을 것이다.

남는 것은,

• 판단
• 책임
• 신용
• 문맥 이해
• 합의 형성
• 우선순위
• 지속성
• 가치의 정의

라고 생각한다.

AI는 코드를 쓸 수 있다.

하지만,

"이 회사에 지금 이것을 만들어야 하는가?"

는 여전히 인간 측의 문제다.

AI는 선택지를 제시할 수 있다.

하지만 선택할 책임은 인간에게 남는다.

개인 개발자에게 지금은 상당히 기회라고 생각한다.

왜냐하면 AI에 의해 '만들 수 있는 범위'가 단번에 넓어졌기 때문이다.

예전이라면 회사여야만 만들 수 있었던 것을 지금은 개인도 만들 수 있다.

단, 개인이 회사에 이기기 위해서는 조건이 있다.

그것은,

회사 같은 안심감을 갖는 것

이다.

단순히,

"저는 구현할 수 있습니다"

만으로는 약하다.

앞으로는,

"저는 만들 수 있습니다"

여기에 더해,

"유지보수할 수 있습니다"

여기에 더해,

"저에게 무슨 일이 생겨도 인수인계할 수 있습니다"

여기에 더해,

"정보는 정리되어 있습니다"

여기에 더해,

"책임 범위도 명확합니다"

까지 말할 수 있는 개인이 강하다.

즉 지향해야 할 것은,

개인 개발자

라기보다,

1인 기업 같은 개인

일지도 모른다.

앞으로의 개발은 아마 이렇게 될 것이다.

소수 인원
×
AI
...

대규모 인원이라는 것 자체의 가치는 낮아진다.

반면,

책임지고 전달할 수 있다는 것

의 가치는 올라간다.

회사는 사라지지 않는다.

하지만 회사의 역할은 변한다.

개인도 약하지 않다.

하지만 개인인 상태로는 신뢰 측면에서 뒤처진다.

따라서 앞으로는,

회사 = 신뢰와 책임의 메커니즘
개인 = 고속의 실행력
AI = 구현과 검증의 가속 장치

라는 구도로 되어가는 것이 아닐까.

AI 시대의 개발에서는,

만들 수 있는지 여부

의 가치는 상대적으로 낮아진다.

대신에,

무엇을 만드는가

왜 만드는가

어떻게 전달하는가

어떻게 지속하는가

의 가치가 올라간다.

이는 회사 개발에도 개인 개발에도 해당되는 말이다.

개인이 만들 수 있는 시대가 되었다.

하지만, 개인으로서 지속할 수 있다고는 단정할 수 없다.

회사에 속하는 의미가 옅어지는 부분도 있다.

하지만 회사가 가지고 있던 신뢰나 지속성은 여전히 필요하다.

그래서 앞으로 강한 사람은,

혼자서 만들 수 있으면서도, 회사만큼 안심시켜 줄 수 있는 사람

이라고 생각한다.

AI 시대의 개발자에게 요구되는 것은 단순한 구현력이 아니다.

구현력에 더해,

의사결정력

신뢰 설계

지속성 설계

까지 포함된 능력이라고 생각한다.