8장 아키텍처*패턴

아키텍처 고민하기

아키텍처를 결정하는 요인

• 요즘 특정 아키텍처가 유행한다해서 도입 하면 안된다.
• 아키텍처를 결정할 때는 (1)기능 요구 사항, (2)품질 속성 또는 비기능 요구사항을 고려하라.
• (1) 기능 요구 사항: 소프트웨어로 해결하고자 하는 문제와 관련
• (2) 품질 속성: 품질 속성과 관련. 예를들어, 24/7 운영되는 서비스인지 아닌지에 따라 아키텍처가 달라짐.
• 가용성, 성능, 보안 못지않게 중요한 품질 속성이 바로 유지보수성이다.

트레이드오프

• 품질 속성을 높이면 시스템의 복잡도가 증가한다.
• 품질 속성을 높이면 복잡도와 비용이 증가하고 서로 상충하는 품질 속성도 존재하기 때문에 아키텍처를 선택할 때 높이고자 하는 품질 속성 간의 절충이 중요하다.
• 모든 게 완벽한 아키텍처가 아닌 가장 나쁘지않은 아키텍처를 선택해야 한다.

아키텍처 변경

• 아키텍처를 바꾸기 위해 모든 걸 다시 개발하는 걸 '빅뱅 방식'이라고 한다.
• 빅뱅 방식은 기존 로직에 대한 학습 + 새로운 요구 사항 도입 등 해야 할 일이 아져 실패로 이어질 확률이 높다.
• 규모가 적으면 한 번에 새로 만드는 것도 괜찮지만 보다 현실적인 방법은 점진적으로 구조를 변경하는 것이다. (ex. 모놀리식에서 서비스 분리)
• 아키텍처를 함부로 변경해서는 안된다. 비용이 증가하고 시스템은 더 복잡해지는데 실질적으로 얻는 이점이 없다면 돈만 낭비한 것에 불과하다.

9장 업무 관리

처음부터 끝까지

개발자는 요구사항 분석부터 구현, 출시까지 모든 과정을 관리하고 마무리할 수 있어야 한다.
다음은 업무를 관리할 때 기초가 되는 것들이다.

• 업무 나누기
• 위험 관리
• 요구 사항 이해 및 변경 대응
• 일정 관리(또는 계획)

업무 나누기

• 개발 규모가 커졌을 때 흔히 하는 실수 중 하나가 생각나는 대로 개발하는 것이다.
• 업무의 크기에 따라 일하는 방식을 배워야 한다.
• 요구 사항 분석이 1주일 이상 소요될 것 같다면 이 작업을 다시 기획자 리뷰, 현업 리뷰 작업으로 나눠야 한다.
• 계획을 세우려면 일의 규모를 파악해야 한다.
• 규모를 파악하려면 해야 할 작업 목록이 필요하다.
• 작업 목록에 넣어야 하는 항목 중 하나가 개발 기능 목록이다. 개발 기능 목록은 세세하게 작성해야 한다.
• 개발 자체에 대한 업무도 작업 목록에 넣어야 한다. (ex. 개발 환경 구축, 운영 환경 구축)

일 잘하는 방법도 공부하기: 구현 기술 외에 일을 잘하기 위한 다른 역량 학습도 꾸준히 해야 한다.

완료의 의미

• 생각했던 코드를 작성했다고 해서 완료된 것은 아니다.
• 코딩 + 스스로 검증 과정까지 거쳐야 '거의 다 한 것' 정도의 상태이다.

위험 관리

• 본인이 느끼기에 뭔가 잘 진행되지 않고, 모르는 게 있을 때 또는 명확하지 않은 점이 생겼다면 위험 신호라고 느껴야 한다.
• 위험 신호를 감지하면 빠르게 공유해야 한다.
• 해결책을 모를 때는 빨리 도움을 요청하라.
• 위험 상황을 관리하기 위해 미리 위험 목록을 작성해보자. 위험 요소는 어떤 것들이 있는지 검토해보고 5개 이상 찾아서 목록을 만들어보자.

요구 사항은 바뀐다

• 요구 사항이 변경되는 것을 막을 수는 없다.
• 요구 사항이 바뀐다는 사실을 인정하고 요구 사항을 대하는 방식을 바꾸어야 한다.
• 요구 사항의 변동 폭을 줄이려면 왜 이런 요구 사항을 원하는지 이해하는 노력이 필요하다.
• 요구 사항이 논리적으로 이해가 안되는 경우에 해달란대로 해주면 안된다. 왜 그런 요구를 했는지 들어 보아야 한다.
• 요구 사항 변동 폭을 줄이는 방법으로는 개발 진행 중에 지속적으로 요구 사항 관리 정리를 하는 것이다. 개발 30~40% 진행된 시점에서 다시 요구 사항에 대한 의겸 수렴을 하고 또 진행 중에 하고 이런 식으로 말이다.
• 개발하지 않는 것도 요구 사항 변동 폭을 줄이는 방법 중 하나다. 정말 중요해서 오픈 시점에 꼭 필요한 요구 사항을 추려서 먼저 처리하고, 나머지 기능은 오픈 이후에 따로 일정을 잡아 처리하는 식이다.
• 결국 우선순위 문제다. 요구 사항을 제시한 관계자는 일정과 비용을 맞딱드리면 요구 사항에 대해 다시 생각해볼 수 밖에 없다.
• 하지만 일정과 비용을 처음부터 언급하지 말자. 합당한 이유와 근거를 통해 최대한 협의를 해도 협의가 어렵다면 언급하자.

일정

• 작업량을 산정할 때 본인의 능력을 과신하지 말자.
• 운영하는 시스템의 유지보수에 드는 시간을 잊으면 안 된다.
• 일정 변경이 필요하다면 미리미리 상급자에게 보고하라.

점진적 개발

• 점진적 개발은 결과물을 구분되는 조각으로 나누고 각 조각을 점진적으로 완성하는 방식이다.
• 점진적 개발의 핵심은 작업을 분할해서 더 빨리 가치를 제공하는 데 있다.
• 전체 기능을 마지막에 한 번에 오픈하는 방식이 아니라 3번에 걸쳐 차례차례 오픈하는 방식이다.
• 점진적으로 사용자가 요구하는 기능을 제공함으로써 빠르게 사용자 만족도를 높일 수 있고 사용자 피드백을 신속히 얻을 수 있다.

안 된다고 말하기

• 안 되는건 안 된다고 말할 수 있어야 한다.
• 안 된다고 말할 때는 할 수 없는 이유도 함께 전달해야 한다.
• 어려운 요구가 들어온다면 안 된다고만 하지 말고 대안을 찾아보자.

수작업 줄이기

• 다른 부서에서 필요한 정보를 주기적으로 전달해주어야 할 때는 자동화 프로그램을 만들어보자. 타 부서 동료의 시간, 내 시간, 의사소통 과정에서 소요되는 비용과 시간을 모두 아낄 수 있다.

이유와 목적 생각하기

• 경력이 쌓이고 지위가 올라가면 단순히 시키는 일만 하면 안 된다.
• 누군가에게 일을 맡길 때도 단순히 어떻게 하라고 지시만 하면 안 된다.
• 일에는 이유와 목적이 있다는 걸 생각하라
• 상급자로부터 업무 지시를 받으면 어떤 이유 또는 어떤 목적으로 그 일을 줬는지 알아내라. 이유와 목적을 모른 채 어떻게 일을 할지만 고민하면 엉뚱한 결과를 만든다.
• 일을 맡길 때는 단순히 만들어야 할 결과물만 알려주면 안 된다. 이유와 목적을 함께 알려주어야 한다.

이유와 목적을 모른 채 그저 시킨 일만 하는 고참이 되지 말자.