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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read More

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 문화를 만들어가며 언젠가는 남아있는 레거시 시스템에 작별 인사를 하는 날을 상상해본다.

Read More

스포티파이 스쿼드 모델

우연히 스포티파이의 팀 스쿼드 모델 글(https://hybridhacker.email/p/the-spotify-squad-model-explained?ref=dailydev)을 읽게되었다. 예전에 모 회사에서 매킨지 컨설팅을 받아서 진행했던 구조랑 똑같다.

관련해서 내용을 정리한다.

팀 스쿼드는 애자일 개발에 대한 색다른 접근 방식이고 스포티파이에서 대중화한 개념이다.

본 내용에 대해서는 2014년 스포티파이 엔지니어링 블로그에 게시된 비디오에 소개되었다.

이 아이디어는 각 분대가 독립적인 스타트업인 것처럼 각각 자신의 프로젝트를 관리할 자율성을 갖춘 미니 팀을 만드는 것이다.

Squad

스쿼드는 소규모 스타트업 팀과 유사한 가장 기본 단위이다.

스쿼드는 하나의 공통 목표를 가진 임무 중심의 다기능 팀이다. 상호간 의존성을 줄이고 가능한 한 빨리 움직일 수 있는 자율성과 자유를 최대한 제공한다.

스쿼드는 아래의 특징을 가지고 있다.

• 최적화된 규모: 8명 미만으로 구성되기에 관리가 어렵지 않고 민첩함과 효과적인 협업이 가능한 규모다.
• 집중된 업무: 각 팀은 명확한 골을 가지고 운영된다.
• 교차 가능: 팀은 개발, 디자인, 관리, QA 등 다양한 분야의 구성원으로 구성되기에 독립적으로 운영할 수 있다.
• Agile Practices: 스쿼드는 일반적으로 Scrum과 같은 애자일 방법론을 사용하여 관리하고 유연성과 지속적인 개선을 보장한다.
• 자율성: 스쿼드는 작업 방식, 사용 기술 및 골을 가장 잘 달성하는 방법을 결정할 자율성을 갖는다.
• 성과: 각 팀은 업무 결과를 소유하여 탐여 구성원 간의 책임감과 의무감을 함양시킨다.
• 빠른 실행: 빠른 의사결정과 신속한 업무 실행이 가능하다.

수년에 걸쳐 스포티파이의 팀 수는 지속적으로 증가하였다. 추가로 더 많은 구조가 도입되었다.

Tribe

부족은 동일한 비즈니스 도메인 또는 기능 영역에서 작업하는 팀의 모임이다.

부족의 역할은 자원을 제공하고 분대 간의 협력을 촉진하는 것이다.

부족은 분대 전체의 정렬을 유지하여 각 스쿼드가 독립적으로 작동해도 충돌하거나 표류하지 않도록 돕는다.

프로젝트의 세부 사항을 관리하기보다는 스쿼드가 성공할 수 있는 최상의 환경을 제공하는데 중점을 둔다.

Chapter

부족내에서 유사한 역할을 수행하는 구성원들은 챕터로 그룹화된다. (e.g. 프론트개발자, 백엔드개발자, QA, 관리자 등)

챕터는 스쿼드 전체의 역량 영역을 구성하는 방법이다.

각 챕터에는 특정 분야의 경험이 풍부한 리더가 있으며, 이들은 서로 다른 스쿼드에서 일하더라도 구성원의 성장과 발전을 담당해야 한다.

Guild

길드는 트라이브나 스쿼드 등 소속에 관계없이 회사 내 누구나 가입할 수 있는 집단이다.

길드는 회사 전체에 걸쳐 개발, UX 또는 데이터 분석과 같은 주제를 중심으로 구성된다.

지식, 경험, 툴등에 대한 정보를 공유하고 광범위한 토론을 하는 비공식 커뮤니티이다.

위 구조가 잘 동작이 되려면., 많은 것들이 필요하다.

• 리더십에 대한 지원
  • 권한 부여: 리더는 팀에게 결정을 내릴 수 있는 권한을 부여하고 그들의 능력에 대한 자신감이 있어야 한다.
  • 투명성: 팀 활동을 조직 목표에 맞게 조정하기 위해 열린 소통 채널이 필요하다.
  • 자율성 지원: 팀이 프로젝트에 대한 소유권을 갖도록 장려하고 책임감을 키워야 한다.
• 문화
  • 실험 장려: 시행착오를 학습 과정의 일부로 볼 수 있는 환경 조성이 필요하다.
  • 실패에 대한 관점: 실패를 성장과 배움의 기회로 보는 태도를 키워야 한다.
  • 개방적인 소통: 프로세스를 개선하고 문제를 신속하게 해결하기 위해 팀 내 및 팀 간 정기적인 피드백 루프를 장려한다.
• 성장
  • 지식 공유: 조직 전체에 지식과 기술을 전파하여 집단 능력을 향상 시킨다.
  • 기술 개선: 개인의 성장이 조직의 변화 요구사항에 맞춰지도록 조정
• 기술 변경 사항
  • 분리된 릴리즈: 각 팀은 독립된 릴리즈 기능을 구현하여 더 빠르고 자주 업데이트
  • 모듈형 아키텍처: 느슨하게 결합된 구조를 채택하여 다른 영역에 영향을 적게 주고 변경할 수 있는 능력을 향상
  • CI/CD: 원활하고 안정적인 코드 통합 및 배포를 보장

스포티파이는 스쿼드 모델을 채택하면서 가장 큰 이점을 팀이 올바른 결정을 내리는데 필요한 정보와 권한을 모두 갖고 있다는 점을 강조한다. 속도와 에너지가 강하다는 이유이다.

하지만, 일부 단점도 존재했다.

• 자율성에 대한 과도한 의존: 과도한 자율성은 결속력을 약하게 만들고 조직 목표에 어긋나는 결과를 가져올 수 있다.
• 강력한 리더십에 대한 의존: 이 모델이 올바르게 동작되려면 팀을 세세하게 관리하지 않고도 팀을 효과적으로 안내하고 코칭할 수 있는 리더가 필요하다.
• 리소스 집약도: 자율적인 다기능 팀을 효과적으로 관리하려면 상당한 리소스가 필요하다.
• 적용의 어려움: 좋은 모델이지만, 전통적인 회사의 경우 적용이 어려울 수 있다.
• 혼합된 결과: 일부 조직은 모델의 혜택을 받는 반면 다른 조직은 생산성과 효율성에 영향을 받는다.

해당 모델을 적용하는 방법

스쿼드 모델을 실험을 시작하려면 어떻게 해야 할까?

최소 요건

팀 구조에 대해 생각하기 전에 더 넓은 범위의 팀이나 부서가 몇 가지 최소 요구 사항을 충족해야 한다.

• 문화적으로 결정을 내리고 자율성을 보장하며 변화에 적응할 준비가 되어 있어야 한다.
• 팀 내의 리더는 권한을 부여하고 새로운 아이디어에 개방적이어야 한다. 그리고 마이크로매니징을 피해야 한다.
• 독립적인 서비스 개발 및 배포를 위한 유연한 기술 환경이 준비되어 있어야 한다.

올인은 위험

한번에 이 모델을 도입하는 것은 피하는 것이 좋다. 모든일에 적합하지 않기 때문이다. 전통적인 구조와 공존이 가능하기에 하이브리드 모델로 접근할 수 있다. 전통적인 팀 구조와 프로세스를 유지하면서 신규 프로젝트나 특정 기능을 개발할 경우 팀을 만들 수 있다.

Action Item:

• 모델 적용으로 이익을 얻을 수 있는 적합한 프로젝트를 선택해야 한다.
• 프로젝트에 적합한 역량을 갖춘 구성원을 선택해야 한다.

임무 부여

스쿼드 모델의 중요한 개념 중 하나는 모든 스쿼드에는 임무가 있다는 것이다.

스포티파이의 경우 응용 분야가 주된 영역이지만, 스쿼드 임무는 무엇이든 될 수 있다. 예를 들어서 “이 기능을 구현하세요.” “지표를 개선하여 90%에 도달하게 하세요.” “고객 유지율을 향상시키려면 이 부분을 개선하세요.” 와 같은 것들이다.

리더십 관점에서 가장 중요한 것은 사명을 명확히 하는 것이다.

스쿼드 스스로 규칙 설정

모든 스쿼드 팀은 자체 규칙과 프로세스를 설정해야 한다. 그리고 이 규칙을 문서화해야 한다. 작성된 문서는 공유되면서 아래의 효과를 얻는다.

• 미래 스쿼드는 다른 스쿼드가 한 일에서 영감을 얻을 수 있다.
• 팀 자체는 프로젝트가 완료된 후 이 문서를 이용하여 회고할 수 있다.

유의 사항

이 모델을 도입하기 전에 아래 사항을 유의해야 한다.

• 구성원들이 소소한 관리 없이 업무를 스스로 할 수 있어야 한다.
• 외부 영향을 피해야 한다. 집중력과 자율성을 유지하기 위해 팀 외부의 간섭을 최소화하려고 노력해야 한다. (외부에 있는 사람들은 스쿼드와 같은 목표가 아니다.)
• 실패에 대비해야 한다. 실패도 학습 과정의 일부이기에 성공을 위해 필요하다는 점을 인식해야 한다.
• 스쿼드가 최선을 다해 작전을 수행하는데 필요한 모든 정보를 갖고 있어야 한다.

Read More

레딧(Reddit)의 아키텍처 진화의 여정

본 포스팅은 https://blog.bytebytego.com/p/reddits-architecture-the-evolutionary?ref=dailydev 의 글을 읽고 관심 가는 내용만 정리한 글이다.

레딧은 “인터넷 첫 페이지”가 되고자 하는 비전을 가지고 2005년에 설립되었다. 오래 시간동안 세계에서 가장 인기있는 큰 규모의 커뮤니티로 발전했고, 월간 사용자 수가 약 10억명이 넘는 큰 규모의 서비스로 성장했다.

최근 IPO도 성공적으로 진행하였고, 많은 사용자들의 콘텐츠가 성공의 주된 요인이겠지만, 사용자가 증가함에 따라 아키텍처도 진화한 점도 기술적 요인이라 볼 수 있다.

초기

초기 레딧은 Lisp으로 만들어졌다가 2005년 12월 Python으로 재작성되었다.

Lisp도 훌륭한 언어이지만, 사용자층이 많지 않다보니 라이브러리가 부족한 단점이 존재했다. 레딧 창업자 중 한명인 Steve Huffman은 이 문제를 아래와 같이 표현했다.

“우리는 다른 사람들의 어깨위에서 서비스를 구축하고 있는데, 상황이 어렵다. 기댈 어깨가 많지 않다.”

아키텍처의 핵심 구성 요소

아래 그림은 레딧의 상위 아키텍처의 구성 요소를 보여준다.

1. CDN은 Fatly의 CDN을 진입 대문으로 사용한다.
2. Frontend은 2009년 초기에는 jQuery를 사용하다가 나중에 Node.js와 Typescript로 전환하였다.
3. R2는 모놀리스 애플리케이션이다. Python을 이용하여 구축한 모놀리식 애플리케이션이다.

인프라 관점에서 레딧은 2009년에 베어메탈 서버를 없애고 모두 AWS로 이전했다. S3를 사용해서 썸네일을 호스팅하고 로그를 저장했다. 애플리케이션 서버들은 모두 EC2로 전환했다.

현재 우리 레거시 시스템도 비슷한 구조다.

R2

R2는 레딧의 핵심이다. 거대한 모놀리식 애플리케이션이며 아래 그림과 같이 구성되어 있다.

사용자 트래픽을 견디기위해 동일한 애플리케이션을 여러 서버에 배포하여 운영한다.

로드 밸런서는 앞에 위치하여 적절한 애플리케이션에 라우팅 작업을 수행한다.

사용자 투표와 같은 작업은 리소스를 많이 사용하기에 RabbitMQ를 통해 비동기 대기열로 작업한다.

데이터 저장 관점에서는 Postgres를 사용한다. 로드를 줄이기 위해 DB앞에 Memcache를 배치하여 부하를 줄인다.

이런 변화는 기존 아키텍처를 유지 할 수 없다라는 결론에 다다랐다.

Golang 마이크로서비스와 GraphQL

레딧은 2017년에 GraphQL을 도입하는 여정을 시작했다. GraphQL은 클라이언트가 원하는 데이터만 요청할 수 있도록 하는 Spec이다. 각 클라이언트마다 조금씩 다른 데이터를 요청하는 경우에 탁월한 선택이다.

2021년 초에 몇 가지 주요 목표를 가지고 GraphQL로의 전환을 시작했다.

• 모놀리식 폐기
• 동시성 향상
• 유연한 구조

GraphQL Federation은 여러 개의 작은 GraphQL API(하위그래프)를 하나의 커다란 GraphQL API(수퍼그래프)로 결합하는 방법이다. 수퍼 그래프는 클라이언트 애플리케이션이 쿼리를 보내고 응답하는 대문 역할을 수행한다.

수퍼그래프는 클라이언트가 수퍼그래프에 쿼리를 보내면 해당 쿼리를 응답하는데 필요한 데이터가 있는 하위 그래프를 파악한다. 관련 부분을 하위 그래프로 라우팅하고, 응답을 수집하여 결합한 응답을 클라이언트에 전달한다.

2022년 레딧의 GraphQL팀은 Subreddit, Comments와 같은 기능에 몇 가지 새로운 하위 그래프를 추가했다. 전환 단계에서 파이썬 모놀리스와 새로운 Go 하위 그래프가 함께 동작하여 쿼리를 수행한다. 더 많은 기능들이 Go 하위 그래프로 이관됨에따라 모놀리스는 결국 폐기될 수 있다.

아래의 그림은 점진적인 전환을 보여준다.

래딧의 주요 요구사항은 모놀리스에서 새로운 Go 하위 그래프로의 기능 마이그레이션을 점진적으로 처리하는 것이다.

문제가 발생할 경우 모놀리스로 다시 전환할 수 있는 기능을 갖추면서 오류율과 대기 시간을 평가하면서 트래픽을 새로운 곳으로 점점 늘리기를 원했다.

하지만, 불행하게도 GraphQL Federation은 점진적 트래픽 마이그레이션을 지원하는 방법을 제공하지 않는다. 그래서 레딧은 아래와 같이 Blue/Green 하위 그래프 배포를 선택했다.

위 접근 방식에서는 파이썬 모놀리스와 Go 하위 그래프가 스키마의 소유권을 공유하게 된다. 로드 밸런서는 게이트웨이와 하위 그래프 사이에 위치하여 구성에 따라 새로운 하위 그래포 또는 모놀리스로 라우팅한다.

위 설정을 사용하면 모놀리스 또는 새로운 하위 그래프에서 처리하는 트래픽 비율을 제어할 수 있기에 마이그레이션 과정에서 레딧의 안정성이 향상되게 된다.

현재도 레딧은 중단을 최소화하면서 마이그레이션을 계속 진행중이다.

CDC 및 Debezium을 사용한 데이터 복재

처음에는 레딧은 기본 데이터베이스에서 생성된 WAL 세그먼트를 사용하여 데이터 복제를 지원했다. WAL은 커밋되기전 DB에 대한 모든 변경사항을 기록하는 파일이다. 쓰기 작업중 오류가 발생하면 로그에서 변경 사항을 복구할 수 있다.

레딧은 복제본 데이터를 읽을 수 있는 S3에 WAL 파일을 지속적으로 보관했다. 그러나 이 방식에는 문제가 있었다.

• 일일 스냅샷을 밤에 실행했기에 낮 시간대의 데이터와 불일치가 발생
• DB의 스키마 변경이 빈번하였기에 스냅샷 생성 및 복제에 문제가 발생
• 복제 프로세스 취약성 및 백업 실패 발생

데이터 복제 안정성을 높이기 위해 레딧은 Debezium 및 Kafka Connect를 사용하는 CDC(Change Data Capture)을 사용하기로 결정했다.

Debezium은 지연 시간이 짧은 데이터 스트리밍 플랫폼을 제공하는 오픈소스 프로젝트이다.

해당 프로젝트 한국어 설명이 없어서, 작성해서 기여했다. (https://github.com/debezium/debezium/blob/main/README_KO.md)

Postgres에서 행이 추가, 삭제 또는 수정될 때마다 Debezium은 변경사항을 수신하고 Kafka Topic에 Produce한다. Connect는 Topic에서 변경사항을 읽고 대상 테이블을 업데이트한다.

아래는 위에서 설명한 프로세스이다.

Debezium을 이용한 것은 여러 대상 시스템에 실시간 데이터 복제를 가능하게 했기 때문에 큰 변화가 생겼다.

우리도 Modernization 작업 시 CDC를 고려중에 있다. 오픈소스를 채택하려면 내부 역량이 꽤 올라가야 할 것으로 판단된다.

끝으로,

레딧의 아키텍처 여정은 수년에 걸쳐 시장의 변화에 따라 지속적인 발전을 거듭해왔다. 당장은 와닿지 않지만, 사용자가 폭발적으로 증가할 것으로 판단되는 서비스를 운영하고 있다면 레딧처럼 진화를 해야 한다.

Read More

엔지니어는 상품이 아니다.

 

엔지니어는 개발팀의 대다수를 차지하며 Project Manager 혹은 아키텍트보다 더 많이 필요하다. 이런 점으로 인해 많은 사람들은 엔지니어를 상품으로 생각할 수 있다. 그러나 이것은 실수이다.

때때로, 일을 할 때 엔지니어링 리소스를 상호 교환 가능한 것처럼 인지한다. 이것은 잘못된 것이다. 사람들은 서로 다른 기술과 능력을 가지고 있다. 현재 이 일을 하고 있는 A가 그 일을 한다면 적은 노력으로 가능하다. 하지만 다른 사람이 그것을 한다면 끝내지 못할 가능성이 높다.

엔지니어가 상호 교환 가능하고 차별화되지 않는다고 생각할 때, 큰 문제들이 발생할 수 있다. 엔지니어링의 상품화는 채용 문제와 결합되기 때문에 채용에서 문제가 발생 할 수 있다. 함께 일하는 구성원들의 역량이 높아지려면 항상 더 뛰어난 사람을 고용해야 한다는 사실을 깊이 이해하지 못할 수 있다.

• 고성장 회사라면 최고의 시절에는 그 전에 뽑았던 사람보다 항상 뛰어난 사람들이 채용되어야 한다. 미래에 더 큰 회사를 위한 기반을 지속적으로 구축해야 하기에, 현재를 유지하는 기반보다 더 강력한 기반을 구축해야 한다.
• 현재 팀을 위해 훌륭한 인재를 채용하는 것외에, 내일의 리더도 키우거나 채용해야 한다. 1년 안에 한 팀을 2개로 나누면 각 팀에는 우수한 엔지니어로 구성된 인력이 필요하다.
• 최고의 엔지니어는 어떤 관리자와 함게 일하는게 좋은지에 대해 분별력이 뛰어나다. 매우 강력한 엔지니어팀이 없으면 훌륭한 엔지니어나 관리자를 고용할 수 없다. 사람들은 자신보다 더 나은 사람들과 함께 일하고 싶어하기 때문에 언제든지 팀의 수준을 높이거나 품질을 조정할 수 있다.

훌륭한 팀을 구성하고 있다면, 좋은 인재를 고용할 수 있다. 이런 일은 다른 조직에 위임할 수 없다. 엔지니어링팀이 판단해야하기 때문이다. 훌륭한 엔지니어를 조직에 영입할 때 그들을 조립 라인의 투입물처럼 취급하지 않아야 한다. 기술 차이가 존재하지 않는 척하기보다는 기술 차이를 인정해야 한다.

“최고의 복지는 좋은 동료이다.”

Read More

PARA가 삶을 더 편하게 만드는 방법

4개로만 이루어진 폴더 시스템은 개인 및 비즈니스에서 지식을 활용하는데 도움이 된다.

“나쁜 아이디어를 저장하기 위한 좋은 시스템이 없다면, 아마도 좋은 아이디어를 저장할 시스템도 없을 것이다.” - 데이비드 앨런

구글드라이브나, 노션, 옵시디언의 폴더 구조를 PARA로 변경하지 않았다면, 내가 원하는 문서를 찾는데 많은 시간을 소비했을 것이다. 지금은 PARA 방법론 덕분에 내가 원하는 것을 찾는데 조금의 시간만 소요된다.

PARA 방법론으로 지식을 정리하여 몇 초 안에 필요한 모든 것을 찾을 수 있는 방법을 설명하고자 한다.

PARA의 작동 원리

PARA는 매우 유연하며 결과 지향적이고 간단하고 빠르게 구현된다. 폴더 및 카테고리가 존재하는 서비스에서 모두 작동된다. 본 글에서는 Google Drive를 예로 설명한다.

효율성은 동작이 단순해야 한다. 나의 구글 드라이브에는 Projects, Areas, Resources, Archive (=PARA)의 4개의 폴더만 존재한다. 

각 폴더를 단계별로 살펴보면 파일이 어느 폴더에 위치해 있는지 쉽게 이해할 수 있다.

Projects

이 폴더에는 진행 중인 프로젝트가 위치한다. “Projects”에 있는 모든 폴더의 공통점은 명확한 시작 날짜와 종료 날짜이다.

프로젝트 폴더 내부의 각 폴더에는 “Completed”라는 명확한 정의가 있다. 시간순으로 폴더를 유지하려면 각 폴더에 시작 날짜와 종료 날짜로 레이블을 지정한다.

날짜 라벨이 어떻게 생겼는지 아래를 살펴보자.

2023-2024는 시작 날짜와 종료 날짜를 의미한다. 요즘IT에 글을 기고하고 있고, 한국생산성본부랑 작업을 하는 것과 Aalto University에서 EMBA 수업을 듣고 있기에, 시작날짜와 종료날짜를 지정해서 관리한다.

프로젝트가 완료되면 폴더를 Projects에서 Archive로 이동하고 유용한 리소스는 Resources로 추출한다.

Areas

“Areas” 폴더는 Projects와 정반대이다. Areas 폴더에는 미리 정의된 날짜 없이 진행 중인 작업에 대해 레이블을 지정한다. 작업이 반복적으로 발생하기 때문에 “Areas”에 있는 것들은 완료가 되지 않는다.

“Areas” 폴더에는 개인적인 것, giljae.com 포스팅 등 계속 유지해야 하는 것들이 위치한다. “Projects”와 다르게 해당 폴더는 시간 레이블을 설정하지 않는다.

Resources

리소스 폴더는 보물 상자이다. 이 폴더는 단편적으로 제공되는 지식이 함께 모이는 곳이다. 완료된 프로젝트를 Archive로 옮겼던 것을 기억하는가?

폴더를 Archive로 이동하기 전에 프로젝트내의 문서, 이미지 및 기타 자료들을 살펴보고 재사용하고 싶은 유용한 리소스가 있다면, Archive대신 Resources로 이동한다.

리소스내의 폴더는 지속적인 관심을 끄는 것들이 위치된다.

예를 들어서 일반적인 리소스 폴더는 프로젝트 관리, 기술 문서, 기타 재사용 가능한 것들이 위치할 수 있다.

프로젝트 폴더와는 다르게 리소스 내의 폴더에는 시작 날짜와 종료 날짜가 없다. 폴더 이름에 라벨을 붙이는 것은 쉽게 찾기 위함이다. 따라서 폴더는 같은 관심사의 것들이 영역별로 구성된다.

리소스 폴더를 생성하면 깔끔하게 자료를 구성하는 효과를 느끼게 된다. 이 폴더는 지금까지 배우거나 경험한 것들을 명확하게 기록해 놓은 것이다.

Archive

아카이브의 컨셉은 꽤 단순하다. 특정 프로젝트가 완료되고 모든 관련 지식을 리소스 폴더로 필터링 하면 프로젝트 폴더를 아카이브로 이동한다. 이게 전부다.

PARA(Projects, Areas, Resources, Archive)는 지식을 정리하는 강력한 도구이다. 폴더와 파일을 구조화함으로써 지식을 잘 활용하고 과거 학습 내용을 다시 볼 수 있다. 이렇게 관리를 하면 시간과 에너지를 많이 절약해준다.

나는 현재까진 만족하며 PARA를 이용하고 있다. 이 글을 읽는 당신의 삶에 PARA를 적용해봤으면 좋겠다.

Read More