DEVOCEAN

안녕하세요 ! DEVOCEAN YOUNG 2기 Devship 조🛥️의 김현우입니다 !

감사하게도 DEVOCEAN 측에서 저희의 관심 분야에 맞춰 원하는 서적을 제공해주셔서, 즐거운 마음으로 같이 책도 읽고 의견도 공유하는 시간을 가졌습니다 :)

저희가 선택한 도서는 <이펙티브 엔지니어> 입니다.👩‍💻🧑‍💻

<이펙티브 엔지니어> 는 시간과 에너지를 절약하여 더욱 효율적인 개발자가 되기 위한 가이드라인을 제공해줍니다 !

본문은 총 3부로 나뉘어 마인드셋, 실행, 투자 등의 관점에서 효율적으로 일을 처리할 수 있는 다양한 방법론을 제시해주는데요,

저희는 각 파트별로 가장 인상 깊었던 부분을 정리하여 공유하는 방식으로 책읽기를 진행했습니다.

✅ 목차

1부. 올바른 마인드셋을 갖춰라 - 정경륜

2부. 실행, 실행, 실행 - 김현우

3부. 장기적인 가치를 구축하라 - 이동재

1부. 올바른 마인드셋을 갖춰라 - 정경륜

1장. 레버리지가 높은 활동에 집중하라

레버리지를 늘리는 세 가지 방법

1. 특정 활동을 완료하는 데 드는 시간 줄이기

2. 특정 활동의 생산량 늘리기

3. 레버리지가 높은 활동으로 전환하기

위의 방법을 실행하기 위한 질문 세 가지

1. 이 활동을 더 짧은 시간에 완료하려면 어떻게 해야 할까?

2. 이 활동으로 생산되는 가치를 증가시키려면 어떻게 해야 할까?

3. 이 시간을 투자해 더 큰 가치를 생산할 수 있는 다른 활동이 있을까?

책에서 말한 레버리지 포인트에 에너지를 집중하는 것에 매우 공감되었습니다. 우리의 시간은 한정되어 있고 해야 할 일은 많으니까요.

그래서 투자 대비 효용이 높은 활동을 위주로 계획을 꾸리고 점검 해야겠다는 생각을 했습니다.

2장. 학습을 위해 최적화하라

학습을 목표로 최적화하는 것이 이펙티브 엔지니어를 위한, 레버리지가 높은 활동이라고 합니다.

성장 마인드셋을 갖춰라

레버리지란 생산한 효과 / 투자한 시간을 뜻합니다. 즉, 투자한 시간당 생산한 가치 및 효과를 의미합니다.

그래서 이펙티브 엔지니어가 되려면 레버리지가 높은 활동을 해야 한다고 합니다. 레버리지를 늘리고 실행하기 위해선 아래의 방법을 고민해 볼 수 있습니다.

어떤 마인드셋을 가지느냐에 따라 삶의 방향도 크게 달라진다고 합니다. 고정 마인드셋을 지닌 이들은 성격과 지능 모두 미리 정해져 있기 때문에 자신이 잘하는 일만 노력한다고 합니다.

반면 성장 마인드셋을 지닌 이들은 자신의 지능과 기술을 노력하여 성장시킬 수 있다고 믿습니다.

그래서 도전과 실패를 반복하며 결국 성공으로 가게 된다고 합니다.

책의 내용에 정말 공감하는 게 실패를 두려워하고 자신의 한계를 결정짓는 순간 해당 영역에서 더 이상 성장하기 어렵다고 생각합니다.

저 또한 항상 성장하는 개발자가 되기 위해 끝없이 부딪히고 나아가야겠다는 다짐을 다시 했습니다.

그 외 학습을 위해 최적화 하는 방법

• 자신의 학습률에 투자할 것

• 학습에 도움이 되는 근무 환경에서 일할 것

  • 빠른 성장

  • 교육

  • 자율성

  • 속도

  • 사람

• 근무 시간을 활용해서 새로운 기술을 발전 시킬 것

  • 많은 코드를 작성하고 보고 배울 것

  • 혹독한 코드 리뷰를 부탁하고 다양한 프로젝트에 참여할 것

• 항상 배울 것

  • 새로운 언어와 프레임워크를 배울 것

  • 수요가 많은 기술에 투자할 것

  • 책을 읽고 강연, 컨퍼런스, 모임에 참여할 것

  • 블로그를 개설하고 글을 쓰면서 설명해볼 것

  • 인맥 네트워크를 구축하고 유지할 것

1부 올바른 마인드셋과 관련된 내용을 읽으면서 저 스스로의 마인드셋이 어땠는지 돌아보게 되었고 앞으로의 저를 위해 올바른 마인드셋을 생각을 해볼 수 있는 기회가 되었습니다.

2부. 실행, 실행, 실행 - 김현우

4장. 반복 속도에 투자하라

이펙티브 엔지니어는 개발 주기 반복 속도를 높이는 데 많은 투자를 합니다.

해당 장에서는 이러한 투자가 왜 레버리지가 높은 활동인지, 개발 주기 반복 속도를 최적화하기 위해서는 어떤 도구와 태도를 갖추어야 하는지에 대해 살펴봅니다.

학습은 ‘복리 계산된다’는 말이 있습니다. 따라서 개발 주기 반복 속도를 더 일찍 높일수록 무엇이 더 효과적인지를 더 빠르게, 그리고 더 많이 배울 수 있습니다.

시간 절약 도구에 투자하라

도구는 근무 시간의 한계 너머로 영향력을 키울 수 있게 해주는 승수입니다.

따라서 거창하지 않더라도, 도구로 시간을 절약할 수 있는 영역을 찾아 자체적으로 도구를 만들고 그 가치를 증명해내는 과정은 필수적이다.

• 컴파일 단계 단축 (→ 컴파일 가속화 → 생산성 향상)

• 핫 리로딩 : 서버를 재시작하지 않아도 자동으로 새로운 버전의 코드를 넣어볼 수 있어 작업 흐름을 점진적으로 변경 가능.

• 지속적 통합 (continuous integration) : 어떤 변경이 코드를 망가뜨렸는지 쉽게 찾을 수 있어 시간 절약 가능.

디버깅과 검증 과정을 단축하라

현실에서는 문제를 디버깅하거나, 작성한 코드가 예상대로 작동하는지 검증하는 작업이 엔지니어링의 많은 부분을 차지합니다.

따라서 디버깅과 검증 과정의 반복 속도를 높이기 위한 투자는 필수적입니다.

버그를 수정하거나 기능을 개발하는 중에 문득 똑같은 동작을 반복하고 있는 것을 깨닫는다면, 해당 흐름을 따라 정확히 원하는 지점에 이르는 장치를 만들기 위한 노력이 필요합니다 !

예를 들어 iOS용 SNS 앱을 만드는 중에 친구를 초대하는 작업 흐름에서 버그를 발견한 상황에서..

사용자가 일반적으로 거치는 약 세가지 인터렉션 과정을 똑같이 탐색하기보다는 앱을 시작할 때 초대 작업 흐름의 버그가 있는 부분으로 바로 이동하도록 손을 봄으로써 더욱 단순한 작업 흐름을 구축할 수 있다는 것입니다.

프로그래밍 환경을 마스터하라

개발자로 일하는 동안 일상적으로 사용하는 기본 도구는 대체로 유지되기 때문에, 프로그래밍 환경 내에서 더 큰 효율을 추구하는 것은 중요합니다.

사람마다 소요 시간이 다를 법한 간단한 작업들로는..

• 버전 관리 변경사항 추적하기

• 단위 테스트나 프로그램 실행하기

• 새로운 변경사항 적용 후 개발 서버에서 웹 페이지 다시 로딩하기

• 텍스트 에디터에서 코드나 데이터의 형식 변경하기

  등이 있을 것입니다.

  이렇듯 작업을 지연시키는 일상적인 동작들을 의식하고, 이를 더 효율적으로 수행할 방법을 알아내야 합니다.

프로그래밍 기본기를 숙달하기 위한 몇가지 방법은 다음과 같습니다.

• 좋아하는 텍스트 에디터와 IDE를 능숙하게 다뤄라.

• 생산적이고 수준 높은 프로그래밍 언어를 적어도 하나는 배워라.

• 유닉스나 윈도우의 shell command에 익숙해져라.

• 마우스보다 키보드를 우선 사용하라.

• 수동 작업 흐름을 자동화하라.

• Interactive Interpreter로 아이디어를 테스트하라.

• 변경사항과 관련 있는 단위 테스트를 빠르고 쉽게 실행할 수 있게 하라.

엔지니어링 외적인 병목을 무시하지 마라

이펙티브 엔지니어는 작업 속도를 늦추는 병목이 코드 작성과 관련이 없거나 안전지대를 벗어난 영역에 있더라도 이를 찾아서 해결합니다.

이때 병목은 타인에게 의존하는 부분에서 흔히 발생합니다. 따라서, 소통은 사람과 관련 있는 병목을 개선할 때 상당히 중요합니다.

• 타 영역의 팀에 의존해야 하는 상황 : 정기적인 일정 확인, 우선순위와 기대치를 명확히 전달.

  → 미리 계획을 세우고 대안 모색.

• 주요 의사 결정권자의 승인이 필요한 상황 : 초기 피드백을 받고 최대한 빨리 승인을 받는 데 집중.

• 리뷰 프로세스로 인한 지연 상황 : 리뷰 일정을 미루지 말고 미리 계획을 수립해 조율.

5장. 개선하려는 사항을 측정하라

이펙티브 엔지니어에게 지표는 진행 상황을 측정하는 도구이자, 진행 상황을 주도하는 중요한 도구입니다.

따라서 해당 장은 주요 지표 선택의 중요성과, 관련하여 갖추어야 할 태도에 관해 설명합니다.

지표를 활용해서 발전을 주도하라

좋은 지표가 주는 이점

• 올바른 대상에 집중하게 해준다 : 목표와 관련한 명확한 지표를 정의해야만 변경사항이 미친 영향을 적절히 측정할 수 있다.

• 좋은 지표를 시간 경과에 따라 시각화하면 향후 발생할 회귀 버그를 방지하는 데 도움이 된다.

• 좋은 지표는 발전을 주도한다.

• 좋은 지표는 시간이 흐르는 동안 효율성을 측정하고, 현재 하는 활동과 그 대신 할 수 있었던 활동을 비교할 수 있게 해준다.

원하는 행동을 장려하려면 올바른 지표를 골라라

어떤 지표를 선택하느냐가 어떤 작업을 할지에 큰 영향을 미칩니다. 따라서 잘못 설정된 지표는 노력의 효과를 드러내지 못하거나, 오히려 역효과로 이어지기도 합니다.

이에 관한 몇가지 예는 다음과 같습니다.

• 주당 근무 시간 vs 주당 생산성

  : 주당 근무 시간이 급격히 늘어날 경우 생산성은 이에 비례해 증가하지 않습니다.

  오히려 추가 근무 시간당 한계 생산력이 급격하게 떨어지고, 오류와 버그 비율, 번아웃과 이직률이 늘어나면서 각각에 따르는 추가 비용이 발생합니다.

  따라서 주당 근무 시간을 늘려서 생산량을 늘리려는 시도는 지속 가능하지 않습니다.

  → 이때는 관심 영역에서의 생산성을 제품 품질, 사이트 속도, 사용자 성장 같은 요소로 특정하고 주당 생산성에 맞춰 지표를 정하는 것이 더욱 합리적입니다.

• 클릭률 vs. 롱 클릭률

  : 숏 클릭이란 겉으로 보기에는 관련 있는 링크로 보여 클릭했다가 다른 링크를 찾기 위해 검색 페이지로 돌아오는 것을 의미합니다.

  따라서 ‘숏 클릭’이 결과를 왜곡할 경우 클릭률로 최적화를 하는 것은 문제가 될 수 있습니다.

  → 따라서 숏 클릭과 롱 클릭 간의 명확한 구분에 따른 지표 설정은 필수적입니다.

지표는

1. 가장 큰 효과를 내고,

2. 실행하기 좋으며,

3. 즉각 반응하되 견고한 것

   으로 정해야합니다.

데이터 무결성을 의심하라

데이터는 사람에 따라 그 해석 방향이 달라지기 때문에 매우 쉽게 오용될 수 있습니다. 해당 장에서는 이러한 데이터 오용으로부터 스스로를 보호할 최선의 방책은 ‘의심’이라고 말합니다.

• 지표에 관한 한 자신의 직감이 수치와 일치하는지 비교하여 확인하기

• 다른 방향에서도 똑같은 데이터에 이를 수 있는지 시도해보기 → 이때의 지표가 여전히 타당한지 확인하기

• 지표에서 다른 속성이 보인다면 해당 속성을 측정해서 결론에 일관성이 있는지 확인하기.

또한, 데이터 무결성에 대한 신뢰도를 높이는 데 쓸 수 있는 몇가지 전략은 다음과 같습니다.

• 나중에 유용하게 쓰일 수 있으니 데이터를 자유롭게 기록하기.

• 데이터 정확성을 곧장 확인할 수 있는 도구를 만들기.

• 종단 간 (end-to-end) 통합 테스트를 작성해 전체 분석 파이프라인을 검증하기.

• 수집한 데이터는 곧바로 검사하기.

  • 데이터 측정과 분석을 추가 활동이 아닌 제품 개발 작업 흐름의 일부로 생각하기.

• 한 지표를 여러 방법으로 연산하여 데이터 정확성 교차 검증하기.

• 이상해보이는 수차가 있으면 빠르게 조사하기.

6장. 아이디어는 일찍 그리고 자주 검증하라

사용자의 비중이 큰 서비스의 경우, 최대한 빨리 피드백에 맞춰 최적화를 진행하고, 고객의 수요와 피드백을 적절히 반영하여 개발 주기를 반복하는 것이 중요합니다.

따라서 해당 장에서는 아이디어를 일찍, 그리고 자주 검증하는 것이 올바르게 작업하는 데 어떻게 도움이 되는지를 살펴봅니다.

A/B 테스트로 제품 변경사항을 꾸준히 검증하라

테스트를 충분히 거쳐 깔끔하게 설계된 확장성 좋은 소프트웨어 제품이라고 해도 사용자 참여도가 떨어지거나 고객이 구매하지 않으면 큰 가치를 전달하지 못합니다.

이때 A/B 테스트는 변경에 따른 효과를 구분하고 해당 효과를 낸 요인이 무엇인지 검증하기 위한 아주 강력한 도구입니다.

A/B 테스트 프레임 워크는 일반적으로 사용자에게 무작위로 버킷을 할당하고 그들이 볼 변형된 제품을 버킷이 정하도록 합니다.

버킷 할당이 편향되지 않았다는 가정 하에, 실험군과 대조군의 지표에 통계적으로 유의미한 차이가 있다면 이는 변경사항의 차이에서 기인한다고 볼 수 있습니다.

A/B 테스트는 변경사항의 효과를 측정함으로써 해당 버전이 출시되었을 때 거둘 효과를 평가할 수 있을 뿐 아니라, 특정 변경 사항이 지표를 개선할 것이라는 확신을 증명하는 도구로도 사용될 수 있습니다.

A/B 테스트는 이론을 검증하고 개발 주기를 반복하면서 효과를 내고 변경사항을 찾아가는 반복적인 제품 개발 방식을 장려합니다.

따라서 사내에서 A/B 테스트 프레임워크를 제작함으로써 반복 개발 주기를 최적화한다면 이는 레버리지가 매우 높은 투자에 해당할 것입니다.

의사결정을 위한 피드백 과정을 구축하라

아이디어를 검증할 피드백 과정을 구축하는 것은 간혹 매우 어렵게 느껴집니다. 그러나 의사 결정 과정에서 이를 위한 피드백 과정이 구축되어 있지 않다면, 이는 단순 추측을 통한 작업에 불과할 수 있습니다.

검증의 핵심은 실험을 실행하려는 의지가 과학적 방법을 적용하고 있음을 입증하는 것입니다.

따라서 우리는 효과가 있을 수 있는 것에 대한 가설을 세우고, 이를 테스트할 실험을 설계하고, 좋고 나쁜 결과에 대해 이해하고, 실험을 실행한 후, 그 결과로부터 배우려는 자세를 취해야 합니다.

7장. 프로젝트 추정 기술을 향상시켜라

특정 제품에 대해 장기적이고 체계적인 계획을 세우기 위해서는 정확한 추정이 필요하기 때문에, 프로젝트 추정은 이펙티브 엔지니어가 익혀야 할 어려운 기술 중 하나입니다.

따라서 우리는 1) 프로젝트 추정의 정확성을 높이고 2) 변화하는 요구 조건에 적응하는 능력을 꾸준히 키워가야만 합니다.

정확한 추정치를 활용하여 프로젝트 계획을 추진하라

추정 : 프로젝트에 드는 시간과 작업량에 관한 최선의 추측

목표 : 사업적 지향점

→ 추정과 목표 사이의 간극을 효과적으로 다루는 방법

• 프로젝트를 더 작은 작업으로 분해하기.

• 작업에 이틀 이상이 걸린다면 더 작게 분해하여 각 작업을 추정하기.

• 자신 또는 다른 누군가가 원하는 작업 시간 말고, 작업에 실제로 드는 시간을 기준으로 추정하기.

• 추정을 최상의 시나리오가 아닌 확률 분포로 생각하기.

  • 우리가 의존하는 정보는 불완전하므로 추정을 결과 범위에 대한 확률 분포라고 생각하기.

  • “이 기능을 지금부터 4주 이내에 완성할 가능성이 50%이고, 8주 이내에 완성할 가능성이 90%입니다”

• 실제 업무 담당자가 추정하게 하기.

• 기준점 편향에 주의하기.

• 하나의 업무를 여러 방법을 사용해 추정하기.

  • 프로젝트를 더 작은 작업으로 분해해서 각 작업을 추정 → 상향식으로 추정치 산출하기.

  • 과거 비슷한 기능을 만드는 데 걸렸던 시간, 데이터 수집하기.

  • 만들어야 하는 서브 시스템의 개수를 계산 → 각 시스템을 만드는 데 필요한 평균 시간을 추정하기.

• 이상적인 인월을 조심하기.

  • 단순 인원을 추가한다고 해서 프로젝트 타임라인이 단축되지 않음 !

• 기존 데이터로 추정치를 검증하기.

• 범위가 커질 수 있는 작업을 타임 박스로 제한하기.

  • 시간 제약이 비교적 적거나 없는 활동에 정해진 양의 시간, 즉 타임박스를 배정하기.

• 다른 이들의 추정에 이의를 제기하도록 허용하기.

구체적인 프로젝트 목표와 측정 가능한 마일스톤을 정의하라

해결 중인 문제를 기반으로 프로젝트의 구체적인 목표를 정의하고, 마일스톤을 활용해서 해당 목표에 맞춰 진행 상황을 측정해야 합니다.

먼저, 구체적으로 정의된 목표는 총 두가지의 혜택을 가져다줍니다.

• 잘 정의해둔 목표는 작업 목록에서 꼭 해야 할 일과 하면 좋은 일을 구분하는 중요한 필터 역할을 합니다.

  • 목표가 구체적일수록 기능을 구별하는 데 도움이 됩니다.

  • 예를 들어 .. “홈페이지 사용자 지연 시간의 95 백분위수를 0.5초 이하로 감소시키기”

• 핵심 이해 관계자들 사이에 명확성과 공통의 이해가 형성됩니다.

  • 공통의 이해가 형성되면 팀 전체의 목표에 해를 끼칠 수 있는 지엽적인 트레이드오프에 대해 팀원들은 더욱 책임감을 느끼게 됩니다.

구체적인 목표를 정의하는 것보다 더 효과적인 것은 목표 달성을 위해 측정할 수 있는 마일스톤을 세우는 것입니다.

이때, 명시적인 기능을 포함한 구체적인 마일스톤이 있을 때 더욱 정직하게 업무의 진행 상황을 공유하고 완성도를 측정할 수 있습니다.

“구체적인 목표는 결승선까지의 경주 트랙을 설치하는 것이며, 마일스톤을 선정하는 것은 결승선을 향해 제대로 가고 있는지 주기적으로 확인할 수 있게 거리를 표시하는 것과 같다”

마라톤 중간에 전력 질주하지 마라

• 근무 시간이 늘어나면 시간당 생산성이 떨어집니다.

  • 부족한 업무량만큼 근무 시간을 늘린다고 하여 생산량이 이에 비례해 증가하지 않음.

• 생각보다 일정이 더 지연됐을 수 있습니다.

  • 일정이 지연되었다 = 앞서 했던 작업을 과소평가했다.

  • → 남아 있는 작업을 포함해 전체 프로젝트를 과소평가했을 가능성이 크기 때문에, 후반 과정에 대한 추정을 재고해야 할 수 있음.

• 추가 근무 시간으로 인해 팀원들이 번아웃을 경험할 수 있습니다.

• 추가 근무는 팀 내 역할 관계를 망가뜨릴 수 있습니다.

• 마감 기한이 다가올수록 의사소통 간접 비용이 늘어납니다.

  • 지속적인 확인, 상황 업데이트를 위한 회의가 자주 이루어질 것 → 간접 비용 증가.

• 기한을 향한 전력 질주 때문에 기술 부채가 유발됩니다.

  • 기한이 다가올수록 마일스톤을 지키기 위해 원칙을 무시하는 일이 불가피하게 발생.

  • → 프로젝트가 끝난 후 갚아야 할 기술 부채가 쌓이게 됨.

이처럼 초과 근무는 장기적인 관점에서 다양한 위험과 비용이 동반됩니다.

따라서 이때 취할 수 있는 최고의 전략은

1. 목표 기한 내에 얼마나 완성할 수 있는지를 가늠하여 출시할 내용을 재정의하거나

2. 더 현실적인 날짜로 기한을 미루는 것입니다.

그럼에도 초과 근무가 불가피할 경우에는,

• 지금까지 타임라인이 지연된 주요 원인을 모두가 이해하고 공유하는 과정을 거쳐야 합니다.

• 프로젝트 계획과 타임라인을 현실적으로 수정해야 합니다.

• 프로젝트가 수정한 타임라인보다 더 지연될 경우 전력 질주를 일부 포기해야 합니다.

3부. 장기적인 가치를 구축하라 - 이동재

8장. 품질과 실용주의 사이에서 균형을 유지하라

프로덕트 또는 코드의 품질은 과해서도, 부족해서도 안된다. 프로덕트 또는 코드의 품질만을 추구한다면 그만큼 개발 속도가 느려지기 때문에 실용적이지 못하다.

반대로 코드의 품질을 너무 추구하지 않는다면 당장은 빠르게 개발할 수 있더라도 어느 순간부터 이전에 대충 만든 코드로 인해 이를 다루는데에 훨씬 많은 시간이 들어가게 된다.

그래서 항상 프로덕트와 코드의 품질은 균형을 유지해 실용성을 추구하는 것이 중요하다. 지속 가능한 품질과 개발문화를 위한 대표적인 방법은 다음과 같다.

지속가능한 코드리뷰 프로세스

비교적 유연한 코드리뷰 기준이 필요하다.

예를 들어 비즈니스 로직, 컨트롤러 코드 리뷰 O, 뷰(인터페이스) 코드 리뷰 X와 같이 리뷰 대상을 분리하고 코드를 프로덕션 레벨로 푸시한 뒤 리뷰하는 등

개발 주기 반복 속도는 늦추지 않되 미래를 위해 고품질 코드베이스에 투자

복잡성을 관리하기 위한 추상화

엔지니어링 생산성을 크게 높여주는 올바른 추상화를 적절히 도입함으로써 올바른 추상화를 구축하는 데에 드는 비용보다 추후 추상화를 이용해 절약하는 비용을 극대화하자.

좋은 추상화는 다음과 같은 특성을 가진다.

• 배우기 쉽다.

• 문서가 없어도 사용이 쉽다.

• 잘못 사용하기 어렵다.

• 요구 조건을 충족시킬 정도로 충분히 강력하다.

• 확장성이 좋다.

• 대상 사용자에게 적합하다.

테스트 자동화

광범위한 자동 테스트는 새로운 코드의 품질을 검증하고 기존 코드의 변경사항이 회귀 버그를 일으키지 않게 보호한다.

또한 코드가 망가졌을 때에도 책임자를 효율적으로 식별하는 데에 도움이 된다.

시간이 지나 뒤늦게 발생하는 코드 문제는 그 원인을 찾는 데에도 많은 시간이 들어감은 물론이고 책임의 소재도 파악하기 어렵다.

테스트도 물론 트레이드 오프가 존재하기 때문에 모든 것에 자동 테스트를 만든다거나 100% 커버리지를 추구하는 것은 바람직하지는 않다.

첫 테스트를 작성하는 것이 가장 어렵다.

이를 극복하고 몇 개의 좋은 테스트, 테스트 패턴, 라이브러리를 차차 갖춰나가면 테스트를 작성하는데 드는 수고도 줄어들며

테스트를 더 작성하는 피드백 선순환을 만들게 되어 개발 시간을 더 많이 절약하는 결정적 계기로 작용할 수 있다.

기술부채의 상환

금융 부채와 마찬가지로 기술 부채도 원금 상환에 실패하면 쌓여가는 이자를 상환하는 데 쏟아야 할 시간과 에너지가 늘어난다.

어느 순간을 지나면 기술 부채는 발전을 방해하기 때문에 주기적으로 기술 부채를 상환해야 할 필요가 있다.

당장의 업무나 개발 일정이 촉박하면 기술 부채의 상환이 후순위로 느껴질 수 있지만 주기적으로라도 기술 부채 상환 일정을 만들어 작은 것부터 시작해 점차 기술 부채 상환의 가치를 팀에게 알려줄 수 있다.

다만 우리에게 주어진 시간은 제한적이므로 기술 부채의 이자가 높은 것부터 우선순위를 매겨 진행해나가는게 중요하다.

9장. 운영 부담을 최소화하라

스타트업과 같이 한정된 인력과 자본만을 가지고 시장 내에서 퍼포먼스를 내기 위해서는 집중하는 것이 매우 중요하다.

프로덕트를 위해 도입하는 솔루션이 자주 망가지거나 지속적으로 유지보수를 해야하는 솔루션이라면 운영 부담이 매우 늘어난다.

예를 들어 인스타그램은 인수될 당시 4천만명의 유저를 단 13명의 직원이 커버하고 있었는데 효율적인 운영을 위해 인스타그램 팀은 매력적이거나 도발적인 신기술 대신 가능한 확고하게 검증된 기술을 선택하고 도입했다.

이처럼 운영 부담을 최소화하는 다양한 인스타그램 팀의 원칙들은 다음과 같다.

단순하게 운영하기

단순한 솔루션은 이해하기 쉽고 당연히 유지보수도 용이하다.

시스템의 아키텍처를 잘 설계하면 추가적인 시스템을 도입하지 않고 동일한 유형의 컴포넌트를 추가함으로써 확장을 노려볼 수 있다.

레버리지가 높은 단순성에 집중해보자.

빨리 실패하는 시스템 만들기

빨리 실패하는 것이란 지금 당장 작은 고장으로 인해 프로그램이 다운되지 않도록 임시방편의 우회로를 선택하는 것과 반대되는 방법이라고 할 수 있다.

이렇게 우회로를 선택할 경우 시스템은 느리게 실패한다.

지금 당장 문제가 생기지 않더라도 추후 그 우회로로 인해 다른 곳에서 예상치 못한 문제가 동반될 수 있기 때문이고 그 문제의 원인을 찾기도 매우 힘들어진다.

빨리 실패하기 위해서는 문제를 우회하는 것이 아니라 문제가 발생할 경우 그 문제를 즉시 드러냄과 동시에 실제 원인에 가깝게 접근해 해결책을 찾아내는 것이다.

기계적인 작업의 자동화

어떤 문제가 발생했을 때 매번 급하게 수동으로 임시조치하는 것과 이 문제의 해결책을 자동화하기 위한 비용을 선불로 지급하는 것으로 나누어 생각해볼 수 있다.

그러나 이 중 하나를 쉽게 선택할 수 있을 정도로 답이 이분법적으로 나오는 경우는 드물다. 자동화가 도움이 되는 대표적인 경우는 다음과 같다.

• 코드, 인터랙션, 시스템이 예상대로 작동하는지 확인

• 데이터 추출, 변환 및 요약

• 오류율 급증 감지

• 새 장비에 소프트웨어를 빌드하고 배포하기

• db 스냅샷 캡처와 저장

• 주기적으로 배치 계산 실행하기

• 웹서비스 재시작하기

• 코드가 스타일 가이드라인을 준수하는지 확인하기

• 머신러닝 모델 트레이닝

🧐 느낀 점

실제 프로젝트를 진행하는 과정 뿐만 아니라, 현재 학생의 관점에서도 적용해볼 만한 조언들이 생각보다 많았던 것 같습니다.

매우 현실적일 뿐더러 당장 실행에 옮길수 있을 만한 방법들이 제시되어 있어 더욱 흥미롭게 읽었던 것 같아요 ㅎㅎ

DEVOCEAN 덕분에 팀원들과 함께 정말 유익한 경험을 공유할 수 있었습니다 :)

감사합니다 🙌