개발자와 AI의 관계

 

개발자들은 종종 AI에 회의적이다. 하지만 AI 도구의 잠재력은 좋아하든 싫어하든 더 빠른 릴리즈와 더 나은 제품을 만들 수 있게 도와준다.

Stack Overflow에서 2024년에 진행한 개발자 설문 조사에 의하면 개발자의 43%만 AI 도구의 결과를 신뢰했다. 반대 의견은 AI가 복잡한 작업을 처리하는데 어렵다고 말했다.

이런 상황에도 ChatGPT는 코딩의 새로운 시대를 열었다고 생각한다. 더 이상 Google, Stackoverflow에서 코딩에 대해 질문이나 답을 할 필요가 없다.

이번에 Cursor AI IDE를 이용하자고 함께 일하는 동료들에게 제안했다.

이유는 일부 개발자들이 Copilot or ChatGPT를 이용하여 코딩에 도움을 받고 있기 때문이다.

Cursor를 사용해보니 AI에 긍정적인 개발자의 경우 생산성이 향상 될 것으로 판단되었기 때문이다.

본 글은 AI를 개발에 이용하면서 느낀 것들에 대한 정리이다.

AI가 개발자를 대체할 것인가?

나의 대답은 당장은 대체하지 않을 것이다. 그러나 AI는 이미 개발자가 코드를 작성하는데 도움을 주고 있다.

ChatGPT, Copilot, Codex등 AI 기반 코딩 어시스턴트는 개발자가 더 나은 코드를 더 빨리 작성하도록 도움이 된다.

개발자의 진정한 가치는 그들이 만드는 것을 어떻게 만들어야 하는지 아는 것이다.

AI가 비즈니스의 가치를 이해하고 무엇을 먼저 개발해야 하는지를 알때까지는 시간이 필요할 것이다. 그래서 개발자의 역할은 항상 있을 것이라 생각된다.

신뢰할 수 있는가?

AI가 아무것도 없이 prompt만으로 처음부터 끝까지 요구사항에 맞는 코드를 작성할 수 있다고 믿을 수는 없다. 그렇지만 생산성을 높이기 위해 사용할 수 있다는 것에 부정하지 않는다.

개발자가 작업하는 영역중에서 수동적으로 처리해야 하는 부분에 대해서 AI의 잠재력을 주로 활용했다. 다이어그램을 만들때도 prompt를 작성한 후 AI가 만드는 동안 다른 작업에 몰두 할 수 있었다.

그리고 API를 만들고 테스트를 생성하도록 요청한다. 이렇게 하면 코드를 테스트하고 오류를 식별하는 데 걸리는 시간이 크게 줄어든다.

물론, AI가 생성한 테스트 스크립트를 검토해야하지만 그럼에도 매우 효율적이다. AI에게 명확한 경계를 제공하면 잘 작동하고 많은 시간을 절약할 수 있다.

AI가 작성한 코드를 신뢰하려면 검토를 해야 한다. 업무를 지시한 사람이 AI가 작업한 작업물에 책임을 져야 한다.

생산성이 향상되고, 품질이 좋아지더라도 AI에게 prompt를 작성하는 사람은 항상 선장이 되어야 한다. AI의 도움을 받는 다는 것은 지름길을 선택한 것이다. 지름길에는 리스크가 있을 수 있다. 그래서 결과에 대해 주의를 기울여야 한다.

AI 진화는 아직 빙산의 일각이라 생각한다. AI에 대한 믿지 못하는 상황이 100% 사라지지 않을 것이기에 AI의 품질은 더욱 향상 될 것이다.

1. AI가 신뢰할 수 있는 코드를 작성할 수 있는 상황이 발생할 수 있을까?
2. AI는 인간이 작성한 방대한 양의 코드를 학습했다.
3. 인간은 100% 신뢰할 수 있는 코드를 작성하지 못한다. 실수가 발생한다.

따라서 AI가 신뢰할 수 있는 코드를 작성할 가능성은 낮다.

위 논리에 따라 100% 완벽한 코드를 AI가 작성하긴 어려울 것 같다. 그래서 검토를 할 수 있는 개발자가 필요하다.

생산성은?

같이 일하는 동료들의 의견을 받아봐야 알겠지만, 내가 판단했을 때는 AI 도구를 사용하는 개발자는 코드 생성, 리팩토링, 테스트 등에 대해서 사용하지 않는 개발자보다 20% ~ 30% 더 생산성이 나올 것 같다.

코딩에서 AI를 사용하게 되면 시간 절약이 꽤 된다. 다만, 코드를 어느정도 이해하는 수준을 지니고 있을 때 가능한 이야기이다. 내가 어떤 코드를 짜야하는지, 이 코드가 제대로 된 코드인지 판단할 수 없는 사람일 경우에는 큰 도움이 되지 않는다고 생각한다. 이런 사람들을 개발자라고 부르진 않으니까.

결론

AI 코딩 어시스턴트는 생산성을 높이고, 생산성에 대한 경쟁 우위를 유지할 수 있다고 생각한다. 물론, 코드를 이해하고 컨트롤 할 수 있는 개발자일때만 가능하다.

시대가 변하고 있다. 새로운 기술을 최대한 활용하는 것이 중요하다. 증기기관이 처음 나왔을 때, 기계와 대결한 “John Henry”의 이야기를 상기했으면 한다.

개발자들이여 AI에 대해 회의적으로 접근하지 마세요!

AI 코딩 어시스턴트를 작업에 통합하는데 익숙해지도록 하세요.

당신의 지시를 따르는 어시를 고용한다고 생각하세요.

Read More

풀스택 개발자, 현실적으로 가능한가?

본 글은 지극히 개인적인 관점이라는 점을 서두에 언급한다.

과거 동안 “풀스택 개발자”라는 용어가 인기를 끌었고, 동료들에게도 원하는 이상향이 “풀스택”이다. “풀스택”은 현대 애플리케이션 개발 시 모든 측면을 처리하는데 능숙한 프로그래머를 지칭한다. 즉, 풀스택 개발자는 프론트엔드(사용자 인터페이스)와 백엔드(서버)을 모두 개발 할 수 있는 전문가이다.

두 영역을 작업할 수 있는 능력은 엄청나다. 이 능력을 유지하기 위해서는 기술이 계속 발전하는 상황에서 최신 도구 및 프레임워크, 패턴, 아키텍처 그리고 다양한 기술들을 얻기위한 지속적인 학습이 필요하다. 이것 외에 클라우드, DevOps 혹은 AI 서비스 연동과 같은 것들을 융합해야 한다.

“풀스택”이라는 용어가 탄생했는지는 과거를 살펴볼 필요가 있다. 현재까지 개발자는 항상 새로운 기술에 적응하고 다양한 도구를 활용하여 애플리케이션을 만들어야 했다. 과거에는 사용자 인터페이스(UX)가 단순 했기에 개발자는 주로 비즈니스 로직을 최적화 하는데 주력했다. 그러다가 Web 2.0 시대가 되면서 프론트엔드의 개발 가능성이 크게 성장했다.

이런 상황이 발생하자, 다방면에 뛰어난 개발자에 대한 수요가 커졌다. 그 당시 많은 스타트업(Uber, Airbnb)들이 탄생했고, 그들의 성공은 사용자 경험을 개선하고 기술 기반 비즈니스를 만드는 것에 대한 중요성을 보여주었다.

시장의 변화로 인해 다재다능한 개발자에 대한 Needs가 증가했다. 풀스택 개발자를 고용하면 각 분야별 개발자를 고용하는 것보다 비용이 낮아지기 때문이다. 그리고 새로운 기능을 빠르게 개발 할 수 있기에 풀스택의 중요성이 강조되었다. 아마도 Node.js가 출시되면서 “풀스택”에 대한 중요성이 더 강조되었던 것 같다. 이유는 프론트엔드와 백엔드 모두 Javascript라는 동일한 언어를 사용하기에 이론적으로 둘다 작업하기 위한 기술을 갖추었다고 판단되기 때문이다.

모든 분야에서 뛰어난 사람은 존재하기 어렵다. 일반적으로 한 개발 분야에서는 뛰어나지만 다른 개발 분야에서는 뛰어나지 않은 상황이 많다. 이유는 필요한 모든 기술을 습득하는데 어려움이 있기 때문이다. 사용자 경험(UX)와 프론트엔드 기술에 뛰어난 개발자는 클라우드 기반의 마이크로서비스 아키텍처의 전문가가 될 가능성이 적다. 불가능하지는 않지만 필요한 고급 기술을 얻기는 매우 어렵다.

이제까지 많은 숙련된 전문가들과 일을 해왔지만, 프론트엔드와 백엔드 개발에서 모두 뛰어난 사람을 본적은 없었다. 그 이유는 개인적인 관심사가 크게 작용하기 때문이다. 어느 한쪽에 전문성이 깊으면서 다른 부분도 잘하는 분들을 뵌적은 있다.

앞으로는 백엔드의 복잡성이 줄어들고 사용자 경험에 더 집중되는 형태로 애플리케이션 개발이 진행될 것으로 예상된다. 그래서 백엔드에 전문성을 갖춘 분들은 프론트엔드에 관심을 가지고 준비하고, 프론트엔드에 전문성을 갖춘 분들은 반대로 백엔드에 관심을 가지고 준비하면 두 분야를 모두 잘하지는 못하겠지만, 풀스택에 가까워지는 상황이 발생하지 않을까 생각한다.

풀스택 전문가가 아니더라도 특정 분야에 대해서 이해가 있으면 커뮤니케이션을 할때 큰 도움이 되기 때문이다. 기술적으로 상대방을 이해하는 것이 효율적인 제품을 구축하는데 매우 중요하기 때문이다.

Read More

Linux Atomic desktops

지난 주말 오래된 노트북에 Fedora Atomic Desktop을 설치했다. 이제까지 사용했던 리눅스와는 생소한 개념을 갖고 있기에 여기에 글을 정리한다.

Linux Atomic Desktops이란?

Linux Atomic Desktops은 Fedora의 Atomic Host를 통한 Atomic update 개념을 활용한다. 이 아이디어는 데스크톱을 구성하는 최소한의 것들을 변경 불가능한 것으로 취급하여 애플리케이션 업데이트 및 변경 사항을 필요한 경우 쉽게 롤백할 수 있는 개념을 적용한 것이다. 이 접근 방식은 시스템 중단을 최소화하고 시스템 수정에 대한 안정성을 강하게 만든다.

이 개념은 약 10년전 Atomic Host 개발과 함께 시작되었다.

Linux Atomic Desktop은 어떻게 동작되는가?

Atomic update

• Transaction update: 업데이트는 단일 트랜잭션으로 적용된다. 업데이트 프로세스에 문제가 발생하면 이전 상태로 롤백하여 시스템이 안정적이고 사용 가능한 상태를 유지할 수 있도록 만든다.
• Ostree: Atomic update의 핵심은 부팅 가능한 파일 시스템을 관리하는 Ostree이다. 각 업데이트는 새로운 트리로 구성되기에 롤백과 병렬 설치가 가능하다.

컨테이너화

• Flatpak: 애플리케이션은 Flatpak을 사용하여 격리된 환경에서 실행된다. 이는 애플리케이션이 시스템에 엑세스 하는 것을 제한하여 보안을 강화하고 다양한 애플리케이션들이 서로 충돌없이 다양한 버전의 라이브러리를 사용할 수 있도록 만든다.
• Podman: 복잡한 애플리케이션의 경우에는 Podman이 Docker와 유사한 방식으로 컨테이너를 실행하기에 Atomic 개념에 부합된다.

Immutable Infrastructure

• Read Only System: 코어 시스템의 파일은 읽기 전용으로 처리되고 특정 영역에서만 변경이 허용된다. 이렇게 하면 시스템 손상 및 수정의 위험이 줄어든다. 읽기 전용으로 처리되는 주요 루트 폴더는 다음과 같다.
  • /usr: 바이너리와 라이브러리가 위치하는 곳
  • /boot: 부트 로더 파일이 위치하는 곳
• 통제 가능 영역
  • /etc: ostree에서 변경사항이 추적되고 관리된다.
• 계층형 패키지: 사용자는 기본 이미지 위에 레이어 형태로 RPM 패키지를 설치할 수 있다. 이는 추적되고 Atomic하게 관리된다.

장점

• 신뢰성: 업데이트와 잠재적 충돌의 영향을 최소화하기에 데스크톱 환경의 안정성이 향상된다.
• 일관성: 각 인스턴스를다른 인스턴스와 일관성을 유지하여 소프트웨어 버전 및 동작의 불일치를 줄인다.
• 보안: 애플리케이션의 격리와 시스템 구성 요소의 변경 불가로 인해 보안을 강화한다.
• 롤백 및 재현성: 쉬운 롤백 기능과 환경을 재현하는 기능으로 관리와 문제 해결이 편리해진다.

단점

일반적으로 “컨테이너 = 복잡하다” 라고 주장하는 사람들에게는 어려울 수 있다. 근데 실제 사용해보면 사용자는 이 차이를 잘 느끼지 못한다. Flatpak을 사용해본 경험이 있다면, 전혀 다를게 없다고 느낄 수 있다.

다른 배포판은 없는가?

물론 “Immutable distro (불변 배포판)” 라는 이름으로 이런 개념이 적용된 배포판이 존재한다. 최근에는 Atomic이라는 용어를 사용하고 있다. 아래는 “Immutable distro” 목록이다.

1. Carbon OS

carbonOS는 Flatpak 및 컨테이너 우선 접근 방식을 취한다. carbonOS는 시스템 업데이트시 검증된 부팅을 제공하는 것을 목표로 한다.

2. Fedora Silverblue

Siverblue는 불변성을 갖춘 Fedora Workstation의 변형이다. (내가 사용하고 있다.)

사용자 인터페이스 및 경험은 Fedora Workstation과 변함이 없다.

Siverblue는 테스트 및 컨테이너 기반 소프트웨어 개발에 유용한 안정적인 경험을 제공하는 것을 목표로 한다. 업데이트 후 문제가 발생하면 이전 버전으로 롤백할 수 있다.

3. Flatcar 컨테이너 리눅스

Flatcar는 컨테이너 워크로드에 맞춰 커뮤니티에서 만든 리눅스 배포판이다.

컨테이너를 실행하는데 필요한 도구만 포함된 최소한의 OS 이미지가 제공된다.

4. NixOS

NixOS는 사용 가능한 가장 진보된 리눅스 배포판 중 하나이다. 패키지 관리자를 여러 운영체제에서 사용할 수 있다.

5. GUIX

GUIX는 NixOS와 비슷하지만, 안정적인 시스템 사용 및 업그레이드에 대한 제어를 위한 고급 사용자를 위해 제작되었다.

6. 바닐라 OS

Vanilla OS는 불변 OS 분야에서 최근에 진입한 기업이다. 신뢰성과 변경 불가능한 기능을 갖춘 쉬운 데스크탑 환경을 제공하는 것을 목표로 한다.

7. BlendOS

BlendOS는 다른 배포판의 모든 장점을 제공하는 것을 목표로 한다.

불변성과 업데이트에 대한 안정성을 확보하면서 RPM, DEB등 다양한 패키지를 이용해 애플리케이션을 설치할 수 있다. (개인적으로 궁금한 배포판이다.)

결론

Linux Atomic Desktops는 데스크탑 환경이 관리되고 유지되는 방식에 많은 변화를 가져다준다. 그리고 사용자에게 일관된 데스크탑 경험을 제공한다. 이 기술이 성숙해지게 되면 Linux 생태계에서 도태되고 있던 데스크탑 환경의 안정성 및 새로운 표준으로 자리매김 할 것으로 예상된다.

Read More

dzone에 재미있는 글(https://dzone.com/articles/pitfalls-of-a-non-technical-manager)이 올라와서 여기에 정리한다.

이 글은 소프트웨어 산업 분야에서 일하는 비기술 관리자 즉, 개발팀을 리드하는 비기술 관리자를 대상으로 한다.

기술자와 비기술자 사이에는 엄청난 의사 소통의 차이가 있다. 전문가 집단에서는 이 둘은 “다른 세계”라고 표현한다.

두 세계 사이를 아래 이미지가 잘 설명하고 있다.

대략 내용은 이렇다.

관리자: “사용자가 사진을 찍으면 앱에서 위치가 국립공원인지 확인해야 합니다.”

개발자: “GIS 조회는 매우 쉬워요. 조금의 시간만 주세요.”

관리자: “그리고 새의 사진인지 확인하세요.”

개발자: “연구팀과 5년의 시간이 필요해요.”

위의 내용을 이해할 수 없다면, 대규모 프로젝트와 참여 멤버들을 관리할 때는 어떻게 해야 할까?

우선, 비기술 관리자를 정의해보자. 아래 내용중 하나라도 해당된다면, 당신은 비기술 관리자이다.

1. 실제 프로그래밍을 한 적이 없다.
2. 담당하고 있는 프로젝트의 코드와 아키텍처를 전혀 모른다.
3. 기술 회의에 참석하지 않는다. (아키텍처 미팅, 코드 리뷰, 기술 논의등)
4. 개인적으로나 직장에서 프로그래밍을 하지 않는다.

저자가 이 글을 쓴 이유는 비기술 관리자가 빠지기 쉬운 몇 가지 실수 그리고 함정들에 대해서 알게 하기 위함이다.

이 글을 읽는 사람중에 비기술 관리자가 있다면, 본인의 상황과 비교해보고 조언을 해주길 바란다.

비기술 관리자의 함정

1. 프로세스가 모든 것을 고칠 것이다.

비기술 관리자들은 대부분의 문제가 개발 프로세스를 변경하면 해결될 수 있다고 생각한다. 이는 모든 문제가 프로세스를 조정하면 해결될 수 있으며 사람의 질과 업무의 질이 덜 중요하다는 것을 의미한다.

관리자는 개발자가 사무실에 더 오래 머물러야 하고, 압박과 스트레스를 유지하기 위해 비현실적인 완료일을 만들어야 한다고 생각한다. (개발자들이 열심히 하고 있음에도) 소프트웨어 개발을 기계적 프로세스로 보는 것이 비기술 관리자의 가장 큰 실수이다. 프로세스라는 것은 패턴이 비슷하거나 반복되는 작업에 적합한 솔루션이지, 창의적인 작업에는 적합하지 않기 때문이다.

2. 질보다 양

마감일이 다가오면 마감일을 앞당기거나 요구 사항 범위를 줄이는 것보다 코드 품질을 희생하여 마감일을 지키려는 의도가 강해진다. 이유는 코드는 나중에 언제든지 리팩토링 할 수 있지만, 마감일은 지키기 힘든 목표이기 때문이다.

이 부분은 참 어렵다. 코드 품질을 유지하기 위해 마감일을 미루거나 오픈 범위를 줄여야 한다.

“저는 이미 약속했어요…” 라고 얘기하면서 마감일을 지키도록 드라이브 한다.

3. 애자일에서 릴리즈 날짜에 대한 약속

납품 날짜를 지정할 때 개발 작업의 복잡성과 규모를 이해했는지?

종종 Lean, Agile 방법론으로 진행한다고 말할 때, 개발팀에 대해서만 얘기한다. Agile의 중요한 측면은 개발팀외에 회사 전체가 이 모델을 받아들여야 한다는 것이다.

마감일을 말해주는 대신에 2~4주마다 개발 진행 상황을 볼 수 있다고 말할 수 있을까?

4. 관리자 vs 리더

기술적인 노하우가 없다면 개발팀 관리자는 바다에 떠다니는 나무 조각에 불과하다. 장애물을 헤치고 나아갈 능력도 없고 여러가지를 고려하여 의사 결정을 내릴 수 도 없다.

결국, 관리자 타이틀은 가지고 있지만, 리더로 여겨지지는 않을 것이다.

5. 모든 개발자는 똑같다.

기술 작업의 본질을 이해할 수 없다. 개발자들은 코드에 대해 아는 것, 코드로 대화하는 문화가 있다. 10배 잘하는 개발자가 다른 개발자와 동일하게 대우 받게 된다. 개발자는 항상 자신의 작업, 얼마나 열심히 일했는지, 작업에 걸린 시간을 정당화해야 한다.

어떤 회사든 최고의 개발 인재를 채용하고 유지하려면 올바른 문화를 만드는 것이 중요하다.

6. 보상

비기술 관리자는 다양한 사람들이 하는 일을 실제로 구별할 수 없기 때문에, 그들이 하는 기술적 작업을 평가하고 구별할 수 없다. 이런 점으로 인해 최고의 개발자가 보상 받지도 못하는 문화로 이어진다.

그러면 누가 보상을 받고 큰 급여를 받을까? 답은 명확하다. 가장 많이 말하는 사람이다. 가장 큰 목소리를 내는 사람이 일을 잘하는 사람으로 인지하게 된다.

왜? 평가하고 구별할 능력이 없기 때문이다.

실제로 잘하는 사람은, 이런 환경에서 일하는 것을 결코 원하지 않을 것이다.

7. 작업을 이해할 수 없음

관리하고 있는 사람들이 하는 일을 이해하지 못하는 것보다 더 불행한 일이 있을까? 개발자들이 하는 일을 알지 못한 채 어떻게 그들을 대적하거나 변호할 수 있을까?

개발팀을 관리한다면 프로그래밍 개념에 대해서 알아야 한다. 숙련된 기술자만이 다른 기술자로부터 존경을 받는다.

“왜 개발자들은 경영 업무를 이해하려고 하지 않을까?” 라고 묻는 사람이 있을 수 있다. 답은 관리자가 개발자를 돌보는 역할이지, 그 반대가 아니라는 것이다.

8. 지나친 단순화

아인슈타인이 말했다. “모든 것은 가능한 한 단순하게 만들어야 하지만, 더 단순하게 만들어서는 안된다.”

안타까운 현실은 대부분의 관리자가 프로그래머에게 기술적 개념이나 문제를 설명할 때 좀 더 쉬운 용어나 쉬운 설명을 해달라고 요구한다는 것이다.

이런 접근 방식의 가장 큰 단점은 기술적인 내용을 지나치게 단순화함으로써 프로그래밍의 본질적인 복잡성과 기술 작업의 특성을 전달 받지 못한다는 것이다.

이로 인해 개발자가 하는 모든 일이 지나치게 단순화되어 편향이 생길 수 있다.

결론

이 글을 읽은 우리는 관리자가 비기술자일 때 발생하는 문제를 알게 되었다. 개인적인 경험에 의하면, 관리자가 자신이 관리하는 사람들과 그 사람들이 하는 일을 진정으로 이해하지 못하면 어떤 것도 해결할 수 없다는 것이다. 비기술 관리자에게 관리를 받고 있자면 문제가 생기면 개발자는 관리자가 프로그래밍 개념, 매커니즘, 아키텍처, 직면하는 문제 등을 알고 있는지 확인하는 것이다.

이렇게 일해야 하는게 맞을까요?

개발자가 맞추는 것이 아니라, 그 조직을 관리할 수 있는 관리자 혹은 기술적 능력 부족을 극복할 수 있는 관리자와 매칭해주는 것이 정답이라고 생각한다.

Read More

린스타트업

Business Design 수업을 듣고 있다. 2번째 모듈 수업에서는 Lean startup method에 대해서 배우고 있다.

린 스타트업 방법론은 2000년대 초반 Steve Blank가 고객 개발 방법론을 도입하면서 시작되었다. 고객 중심 접근 방식을 강조한 Blank는 스타트업 초기 단계에서 잠재 고객을 참여시키는 행위가 매우 중요하다고 얘기한다.

소비자 중심 접근 방식은 제품을 출시할 때 많이 사용되는 방법이다. 새롭거나 파괴적인 혁신을 창출하는 것이 아니라 소비자가 원하는 것을 제공하고 기존 요구 사항을 충족시키는 것에 더 가깝다고 언급한다.

새로운 제품이나 서비스를 만들때, 과거에는 “우리가 만들면 그들이 사용할 것이다.” 라는 접근 방식으로 리소스를 많이 소비하면서 운영되었다는 점을 Blank는 깨달았다. 그래서 초기 가설을 검증하고 고객 요구에 맞는 제품을 만들 확률을 높이는 것을 목표로 하는 방식을 제안했다.

스타트업은 자금이 고갈되기 전에 결함을 식별하고 빨리 수정하지 않으면 성공할 수 없다. Blank의 아이디어는 Lean Startup 기반을 구축했다.

Eric Ries는 Steve Blank의 아이디어에 큰 영향을 받았다. 그는 스타트업 창업에 대한 새로운 접근 방식을 만들었다. 그가 벤처 투자사에 재직하는 동안 스타트업 컨설팅을 하면서 실무에 적용할 기회를 얻었다. 그리고 이런 경험을 기반으로 “Lean Startup”을 기술했다.

Ries는 “린 스타트업은 빠른 반복과 고객 통찰력, 거대한 비전, 큰 야망을 강조하는 제품 개발을 바라보는 새로운 방식”이라고 얘기한다. 그의 책에서는 스타트업은 극도의 불확실성 속에서 새로운 것을 창조하도록 설계된 기관이라고 언급한다. 벤처를 시작하고 자신이 무엇을 하고 있는지 모른다면 어떤 아이템인지는 의미없다고 한다.

핵심 원칙

스타트업이라는 불확실성이 있는 상황에서는 전체 사업 계획 작성을 생략하는 것이 좋다. 대신 린 스타트업은 사업 계획의 핵심 사항들을 일련의 가설로 나눌 것을 제안한다. 그리고 이런 가설을 과학적으로 테스트할 수 있는 조치를 취하도록 조언한다. 예를 들어서 MVP(Minimal Viable Product)를 만들고 잠재 고객 그룹에게 제공하여 사업 아이템을 검토하는 것이 중요하다.

이런 행위는 가설이 “참”인지 “거짓”인지 밝히기 위한 실험이다. “참”이라면 스타트업은 인내심을 갖고 제품이 빛날때까지 지켜보면 된다. 그러나 “거짓”이라면 “피벗”을 해야 한다.

이것이 린스타트업의 핵심 개념이다. 린 스타트업의 핵심은 “빌드-측정-학습” 에 대한 피드백 루프로 동작된다.

<source: https://productmantra.net/2013/11/09/lean-startup-loop-scattered-versus-progressive-learning/>

스타트업은 아이디어를 제품으로 변환한다. 고객과 상호 작용하면서 정성/정량 관점에서 피드백과 데이터를 수집한다. 스타트업에 만드는 초기 제품은 실험이다. 지속 가능한 비즈니스를 구축하는 것에 대한 학습이다. 빌드부터 측정 그리고 학습까지 마무리되는 루프이다.

학습

가설을 테스트하는 과학적 접근 방식을 ‘검증된 학습”이라고 한다. 비즈니스 가설을 테스트하고, 테스트 결과를 학습하고, 수집된 데이터를 사용하여 의사 결정을 하고 제품을 개선하여 Needs를 충족시키는 민첩한 프로세스로 동작된다. 이런 과정을 통해 가설이 타당한지 아이디어가 가치가 있는지를 알 수 있다. 가능성이 아이디어는 빠르게 실패할 수 있도록 도와준다.

빠른 실패

낭비를 최소화하는 것이 목표인 린스타트업은 “빠른 실패”를 적극 권장한다. 아무도 원하지 않는 제품이나 서비스에 낭비되는 시간과 자원을 줄이는 것이 중요하기 때문이다. 빠르게 실패하면서 배우고, 다시 아이디어를 생각하고, 전환할 수 있는 충분한 시간을 확보할 수 있다.

MVP

MVP(최소 실행 가능 제품)는 “최소한의 노력과 최소한의 개발 시간으로 빌드-측정-학습” 루프를 돌릴 수 있는 개념이다.

최소라는 개념은 유동적이고 상황에 따라 다르다. 관점에 따라 최소로 보이거나 과도하게 보일 수 있기 때문이다. 따라서 최소 표준을 신중하게 정의해야 한다.

MVP는 품질이 낮거나 저렴하게 만드는 것을 의미하지 않는다. 핵심 기능을 제공하는 것을 목표로 두고 가능한 최소 비용으로 개발해야 한다. 그리고 고객 검증 단계로 전환해야 한다.

고객 검증

항상 고객과 함께 기능을 검증하는 린 스타트업의 목표는 효율성과 낭비를 감소하는 것이다. 매우 모순적으로 보일 수 있다. MVP가 준비되면 실제 사용자를 대상으로 테스트를 진행한다.

개발 중인 제품이 시장의 니즈를 만족하는지 판단하고, 자원 소모를 최소화하며, 추가하거나 제거해야 할 기능을 결정하는데 도움을 준다.

피벗

고객 검증 과정이 끝나면, 전략적 가설이 옳았는가? 에 대한 결과를 알 수 있다. 테스트를 통해 긍정적인 면을 확인할 수 있다.

피벗을 통해 스타트업은 계획을 고수하기보다 실 피드백과 데이터를 기반으로 접근 방식을 조정하거나 개선할 수 있다.

위에서 언급한 것들이 린스타트업의 핵심이다. 빌드-측정-학습 루프를 통해 현재 전략을 유지할지 혹은 전환할지를 결정하는 것이다.

한계

“사람들은 제품을 보여주기 전까지는 자신이 원하는 것이 무엇인지 알지 못한다.” 라고 스티브 잡스가 말했다. 이 말에는 많은 의미가 있다. 모든 스타트업이 린 방식을 따른다면 파괴적 혁신이 나올 수 없을지도 모른다.

계획적이지 않다.

린 방식에서는 스타트업 초기에 자세하고 복잡한 사업계획을 수립하는데 너무 많은 시간을 소비하는 것은 역효과를 낳는다고 얘기한다. 어느정도는 동의한다. 그리고 비즈니스 모델 캔버스 사용을 장려한다.

그러나 캔버스가 포착하지 못하는 것들도 존재한다. 그리고 대부분의 사람들은 실패를 예상하면서 행위를 하지 않는다. 그들의 꿈, 비전에 대한 밝은 미래를 상상한다.

린스타트업에서는 계획을 적게 수립하라고 얘기하지만, 다시 해석하면 가설 기반으로 수립하라는 의미이기도 하다.

빠른 실패

MVP 기반으로 제품을 검증하지만, MVP는 최종 제품의 모습을 표현하지 않는다. 그래서 초기 기능 표준을 잘 수립해야 한다. MVP는 매우 유용하다. 하지만, 최종 모습으로 보면 안되고 가설을 검증하는 목적으로 사용되어야 한다.

결론

린스타트업도 전통적인 방법과 비슷하게 시작된다. 시장 조사, 법률 및 규제 준수 조사, 사업 계획 수립등 다만, 린스타트업은 MVP로 시작되기에 기존 방식에서 시간과 리소스를 절약해준다고 볼 수 있다.

고객 검증에 중점을 둔다는 것은 혁신적이고 파괴적으로 이어지지 않지만, 고객 요구에 맞는 제품을 만드는데 도움이 된다. 신속하게 작업하고, 빠르게 가설을 검증하여 고객이 원하는 제품을 만들 가능성이 높아진다.

현재 진행하고 있는 프로젝트도 회사에서 진행한 방식과 다르게 MVP부터 만들어서 진행을 했었다. 베이스가 되는 프로젝트는 전통적인 방식으로 시작되었지만, 2개의 MVP를 sub로 만들었고, main으로 합류를 눈앞에 두고 있다.

비용과 시간을 줄일 수 있었지만, 고객 검증을 위한 피드백 수집부터 반영까지는 보이지 않는 참여 멤버들의 노고가 상당하다는 점을 인지해야 한다. 결국 일은 사람이 하는 것이기에…

Read More