10/04/2024

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

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


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

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

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

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

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

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

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

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

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

9/23/2024

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 생태계에서 도태되고 있던 데스크탑 환경의 안정성 및 새로운 표준으로 자리매김 할 것으로 예상된다.

8/19/2024

비기술 관리자의 함정

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. 지나친 단순화

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

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

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

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

결론

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

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

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

8/09/2024

린스타트업

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으로 합류를 눈앞에 두고 있다.

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


7/13/2024

당신은 받는 사람인가요. 아니면, 주는 사람인가요?

 


일반적인 사람들은 세 가지 입장 중 하나를 기본으로 삼으면서 일을 한다.

“받는 사람”, “맞추는 사람” 그리고 “주는 사람”.

받는 사람은 항상 다른 사람보다 자신의 이익을 우선시하고 줄 때는 그 이익을 증진시키려는 의도를 지니고 있다.

맞추는 사람은 상호성을 믿기에 누군가 가려운 곳을 긁어주면, 본인도 그 사람의 등을 긁어준다.

반면에 주는 사람은 다른 사람에 초점을 맞추기 때문에 도와주면 보답할 것이라고 믿는다.

프로젝트를 진행할 때, 이런 입장차가 눈에 보이게 된다. 중요한 것은 문제보다는 태도와 동기이다.

주는 사람과 맞추는 사람은 최상의 결과에 중점을 둔 협업 작업에 적합하다. 반면, 받는 사람은 다른 사람과 협업하지만 자신에게 도움이 되는 경우에만 한다.

주는 사람은 함께 일하는 동료에게 도움이 필요할 때 가장 먼저 자원하여 돕는 사람이 될 가능성이 매우 높다.

주는 사람과 맞추는 사람의 차이점은 맞추는 사람은 호의를 베풀었으니 언젠가는 도움을 받을 것을 기대한다는 점이다.

받는 사람은 도움을 줄 수 있지만 본인이 불리하지 않은 상황에서만 도울 수 있다. 동료를 돕는 것이 자신의 작업이 지연되어 자신에게 부정적인 영향을 끼친다면 돕지 않을 것이다.

프로젝트가 잘 마무리되어 축하할 시점에는 받는 사람은 가능한 한 많은 영광을 얻으려 할 것이다. 주는 사람은 다른 사람의 기여를 감사하게 여기고, 맞추는 사람은 서로 인정을 해줄 것이다.

프로젝트는 서로 직접 일한 적이 없는 사람들이 자주 배치되고 협업한다.

리드의 대부분은 함께 일하는 팀원이 어떤 범주에 속하는지 알 수 없는 입장에서 일을 시작하게 된다. 그리고 어떤 타입인지 파악을 하게된다.

이는 일부 위험을 줄이는데 매우 중요한 것이기에., 리드는 항상 이런 상황을 이해하고 관찰해야 한다.

7/09/2024

DevOps로의 전환을 앞두고

레거시 시스템은 오랫동안 존재해 왔고, 조직은 수년간 이를 사용하였다. 중간중간 어려움은 있었겠지만 익숙해졌다.

대부분 이런 시스템들은 수십년 전에 개발되었으며 현재 상황에 부응하도록 설계되지 않았다. 그 결과 현 시스템을 유지관리하려면 레거시 버전과 OS를 사용해야 했다. 이런 작업들은 현 시대에 개발을 하는 개발팀에게 큰 부담이 될 수 있다.

우선 DevOps에 대해서 모르시는 분도 계실테니, 개념부터 정리한다.

DevOps란 무엇인가?

DevOps는 배포를 더 자주 빈번하게, 신뢰 가능하도록, 시간 소모를 줄이는 것을 목표로 하는 업무의 집합이다. DevOps는 코드 변경과 배포 사이의 시간을 줄여준다.

기존 방식처럼 개발(Dev)팀과 운영(Ops)팀을 나누는 것이 아닌, 팀 간의 경계를 없애기에 이 조직에 소속된 사람은 개발과 운영을 모두 알고 있어야 한다.


기존 방식과 차이점은 라이프사이클을 더 자주 빠르게 진행할 수 있게 해주는 부분에 있다. 더 빠르게 피드백을 받고 더 유연해진다는 장점이 있다.

일반적인 DevOps pipeline을 구현하는 방식은 아래와 같다.

  • 코드는 소스 리포지토리에서 관리된다.
  • 모든 코드 변경 사항은 자동 빌드, 자동 테스트 등과 같은 자동화된 품질 검사와 코드 검토를 통과해야 한다.
  • 다양한 환경에 대한 배포는 자동으로 수행되어야 한다. (수동 또는 로컬에서 수행되지 않음)
  • 환경은 지속적으로 모니터링되며 장애 발생 시 회복성이 뛰어나야하고, 자체 복구 기능을 제공해야 하며, 수동 개입이 필요한 경우 개입할 수 있어야 한다.

이런 업무를 수행하려면 아래와 같은 지식을 지니고 있어야 한다.

  • 애플리케이션 개발
  • 스크립팅
  • 네트워킹
  • CI/CD에 대한 경험 혹은 최소 하나의 플랫폼을 사용할 수 있어야 함
  • 다양한 클라우드 경험

DevOps는 조직내 프로세스의 문화적 변화를 요구한다. 개발자와 IT 운영을 단일 구조로 통합해야 하며, 서로 긴밀하게 협력해야 한다. 거의 모든 것을 자동화되는 DevOps 사고 방식으로 생각을 바꿔야 한다.

DevOps는 개발팀과 운영팀을 결합하여 원활한 소프트웨어 개발 프로세스를 만드는 방법론이다. 이는 계획 및 개발에서 테스트 및 배포까지 전체 라이프사이클을 함께 작업하는 것이다.

현재의 고민

현재 진행하는 프로젝트가 막바지에 다가왔기에, 오픈 이후 운용 모습에 대해서 DevOps를 고려하고 있다. 현재 진행하는 프로젝트는 모든 영역에 대해서 현대화를 하지 않았기에 Batch, 인터페이스 일부는 레거시가 공존하는 구조기에 직면하는 문제들이 존재한다.

내가 경험한 것중 가장 큰 문제는 “마인드셋”을 바꾸는 것이다. 현재 조직은 현대화를 하려고 모인 동료들이기에 큰 문제는 없다. 다만, 기존 시스템을 사용하는 사람들의 마음을 바꾸는게 어렵다는 것을 그동안의 경험으로 많이 느꼈다.

사람들은 레거시 시스템이 비효율적인 부분이 있고, 비즈니스 상황에 맞춰 대응하려고 할때 지연과 비용을 초래함에도 불구하고 변화를 좋아하지 않는다. 이러한 저항은 현재 현상 유지에 대한 집착보다는 미지의 것에 대한 두려움에서 비롯된다고 느껴진다. 그러나 행동하지 않았을 때 비용은 훨씬 더 클 수 있다.

레거시에 어떤 문제가 발생했을때, 문제가 발생한 부분만 들여다보고 해결한다면, 사일로화된 작업 방식일 것이다. 전체적인 관점에서 어떤 해결 방법이 좋을지, 중장기적으로 이 방법이 적절한지 등을 고려해야 한다.

레거시 시스템은 정말 오래된 기술 스택으로 만들어졌다. 현 시점에 관련 개발자를 구하려고 해도 쉽지않다. 아무래도 다들 치킨집 사장을 하고 있을 가능성이 높다. 코드야 그렇다쳐도 그 당시 도입된 솔루션들은 대부분 EOL(End Of Life)된 상황이다. 이런 시스템은 분해하고 리모델링을 하기가 정말 쉽지 않다.

그럼에도

DevOps팀과 레거시 팀 간의 러브스토리를 상상해본다.

DevOps팀이 진행하는 업무는 아마도 레거시팀이 관심을 가지고 지켜볼 것이다. 변화하고 싶은 사람들에게는 매력적이고 설득력 있는 파트너처럼 보일 수 있다.

레거시 팀은 설득이 필요한 완고한 파트너와 비슷하고, 설득이 필요하다. 이런 관점에서 DevOps는 협업과 지속적인 개선이라는 원칙 기반하에 이점을 보여주고 비즈니스의 요구를 충족하는 제품을 만들어 낼 수 있는 방법을 계속 보여줘야 한다.

레거시 시스템과의 결별은 어려울 수 있지만 DevOps의 도움으로 유익한 경험을 제공할 수 있지 않을까? 그래야 레거시 시스템을 현대화하고 개발 프로세스를 개선하는 문화를 만들 수 있을 것이다.

가장 중요한 점은 레거시 시스템의 해체를 두려워하면 안된다.

이제 하나를 현대화 하였으니, DevOps 문화를 만들어가며 언젠가는 남아있는 레거시 시스템에 작별 인사를 하는 날을 상상해본다.