솔류션 아키텍트에 대하여

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2022-10-29
2022-10-29
8356

![Solution architect](https://docs.google.com/drawings/d/e/2PACX-1vTXwvFJUirzTI1wlMrEnlsxd8Vwfq64Ab1jna8Sh5xYLQ-0dD2qUCPlBNjnsmNxBBPxOnJVBxbB6jq0/pub?w=800&h=422)

## 솔류션 아키텍트란

솔류션 아키텍트(Solution Architect - SA)는 시스템과 컴포넌트, 기능들을 결합 및 통합하는 일을 한다. 비즈니스 요구사항을 기술 언어로 번역하여서 전달하는 업무도 함께 수행한다. 이 과정에서 다양한 기술 제공 업체, 내부 기술팀, 기획팀, 사업팀과 협업하면서 비즈니스 방향, 고객 가치, 기술이 서로 일치하는지를 확인한다.

특히 클라우드 시대에 솔류션 아키텍트의 역할이 중요해지고 있다. 클라우드는 클라우드에서 제공하는 다양한 기술과 서비스, 외부 협력업체와의 통합이 중요한데, 이런 특성이 솔류션 아키텍트의 요구사항과 일치하기 때문이다.

## 깊게 혹은 넓게

일반적인 생각과 달리 아키텍트는 전문가로 분류하지는 않는다. 이들은 특정 기술에 대한 심층적인 지식 보다는, **솔류션에 대한 광범위하지만 얕은 지식**을 더 중요하게 생각한다. 오해는 하지 말자 기술에 대한 심층적인 지식이 필요 없다는게 아니다. 한, 두개 정도 기술에 대한 심층적인 지식을 있으면 SA 역할을 더 잘 수행 할 수 있기는 하지만, 폭 넓은 지식이 더 높은 가치를 가질 수 있다는 것이다.

![image](https://docs.google.com/drawings/d/e/2PACX-1vQyMNJGOEriEwJNORgpLIDVpmxP0ZomkYVeVkLljYc401EwRorqe4-sdOPSE-WXFJxDQ9Ni6EjIGkgM/pub?w=466&h=374)

전문지식은 가치가 있기 때문에 피라미드의 상단을 확장하는 것은 이득이 된다. 하지만 알고있는 것은 **유지 관리**해야 가치를 지속시킬 수 있다. 문제는 소프트웨어 세게에서 고정된 것은 없으며, 매우 빠르게 변한다는 것이다. 당신이 Django의 전문가가 되었다고 하더라도 해당 전문지식을 1년동안(6개월이면 전문성을 잃어버리기에 충분히 긴 시간이다.) 사용하지 않으면 전문성을 지속 할 수 없다.

피라미드의 꼭대기에 있는 것을 유지하기 위해서는 시간 투자가 필요하다. 궁극적으로는 기술적 깊이를 계속해 나가는 것이다.

아키텍트 역할을 하게 되면 지식의 본질이 바뀐다. 아키텍트의 가치의 상당 부분은 기술에 대한 폭넓은 이해와 이를 바탕으로 문제를 해결 할 수 있는 기술(솔류션)의 제안 능력이다. 예를들어서 아키텍트는 문제를 해결하는 5가지 솔류션을 알고 있는 것이 한 기술에 전문가가 되는 것보다 더 유리하다.

아키텍트에게 중요한 부분은 상단과 중단 부분이며, 깊이보다 넓이가 더 중요하다. 왜냐하면 아키텍트는 프러덕트의 기능을 기술적 제약에 맞게 결정해야 하기 때문이다. 제약에는 성능, 기능, 품질, 시간, 시장 이 표함되기 때문에 다양한 솔류션에 대한 폭넓은 이해가 중요하다.

당신은 이 모든 것들에 대한 전문지식을 유지 할 수가 없다. 아키텍트는 힘들게 얻은 전문 지식을 희생하고 그 시간을 포트폴리오 확장에 쓰는게 현명한 전략이다. 운이 좋다면 깊이와 넓이를 모두 유지하는 아키텍트를 만날 수 있을 것이다. 이들은 엄청난 시간과 노력을 투자하여서 그러한 능력을 얻었다. 이런 아키텍트는 오버워크가 일상화된 상위 5% 정도의 엔지니어들이다. 선택은 여러분의 몫인데, 팀을 이루어서 역할을 분담하는게 훨씬 효율적일 것이다. 실제 SA를 유지하는 AWS와 같은 회사들도 이러한 전략을 사용한다.

## 솔류션 아키텍트의 책임

* 현재 사내에서 사용하고 있는 기술을 분석하고 개선방안을 모색한다.
* 제안된 기능 업데이트를 성공적으로 수행하기 위해서 필요한 요구사항을 문서화하고 모니터링 한다.
* 컴퓨터 리소스가 프로젝트에서 사용가능한 상태로 제대로 작동하는지 확인하기 위해서 사내 기술 전문가와 협력한다.
* 효과적인 프레임워크의 제안과 구축
* 프로젝트 제약 조건을 설명하고 관리 / 모니터링한다.
* 제안된 솔류션에 대한 세부적인 기능과 제약을 제공한다.
* 프로젝트의 목표를 정의하고 적절한 방식으로 실행되는지 관리 한다.

## 솔류션 아키텍트의 주요 기술

* 문제해결을 즐겨야 한다. SA는 소프트웨어와 하드웨어를 사용하여 문제를 해결한다.
* 폭넓은 기술의 이해와 설명 : 솔류션 아키텍트는 다양한 기술 부서와 협력해야 한다. 따라서 기술의 장점과 단점, 제약사항을 잘 설명 할 수 있어야 한다.
* 프로젝트 관리 기술
* 강력한 분석 능력. 비즈니스 요구사항을 검토하고, 현재 시스템을 검사하여 확장 가능하고 사용 가능한 솔류션을 설계 할 수 있어야 한다.
* 다양한 이해관계자와 소통할 수 있는 능력. 다른 부서, 팀과 협업 할 수 있어야 한다. 응집력있는 단위로 함께 작업하면 운영이 원할해지며 프로젝트의 성공확률이 높아진다.
* 결단력. SA는 다양한 솔류션들을 검토하여 최적의 안을 제안해야 한다. 장/단점, 제약사항 등이 상충될 수 있기 때문에 이들을 종합하여 이해관계자에게 자신있게 명확한 지침을 제공할 수 있어야 한다. 이는 분석능력과 커뮤니케이션 능력이 뒷받침될 때 가능한 기술이다.

## 엔트프라이즈 vs 솔류션 vs 도메인 아키텍처

소프트웨어 산업이 고도화 되면서 아키텍트도 분화되고 있다.

### 엔터프라이즈 아키텍트

EA(Enterprise Architects)는 기술이 비즈니스 요구사항과 일치하는지 확인한다. EA는 조직이 현재와 미래의 목표를 효과적으로 달성 할 수 있는 방법을 결정한다. 여기에는 기업에 대한 분석, 계획, 설계, 구현이 포함된다.

EA는 그 목표가 포괄적이라서 기업마다 역할에 차이가 있을 수 있다. 실제 EA에 대한 서로 다른 몇 가지 설명들이 있다. 하지만 사업 구조를 분석하고 계획을 수립하는 것은 공통 목표이다.

![Enterprise Architects](https://docs.google.com/drawings/d/e/2PACX-1vRX3YiPUj_BKlJaf8CME81paDVqakohzbWPCs_sfkfLa8BAb_sM8cfPBmVa4TJD0TuyaHhIhVvM5GhN/pub?w=728&h=746)

### 솔류션 아키텍트

솔류션 아키텍트는 특정 비즈니스 문제/솔류션에 중점을 둔다. 이들은 제안된 솔류션이 비즈니스의 전략적 요구와 일치하는지 확인하며, 종종 엔터프라이즈 아키텍트와 상의한다.

### 도메인 아키텍트

도메인 아키텍트는 특정 도메인에서 활동하는 전문가이다. Data Architect, Integration Architect, Technical Architect 가 여기에 포함된다.

![image](https://docs.google.com/drawings/d/e/2PACX-1vQJbTy_nY_LQRdSv7lkZ7XZjanyLuC3DKjyE1Jky4nmVEsj2AhcA4veN-CUoukHS1dIcIp_S16_Ni5L/pub?w=728&h=340)

## 더 나은 아키텍트가 되기 위한 팁

### 의사소통

1. 복잡한 문제나 해결책을 논의할 때 시각자료를 사용한다.
2. 전문용어를 사용하지 않는다.
3. 간결하게 핵심을 전달한다.
4. 복잡한 주제를 비유로 전달한다.
5. 대상을 이해하고 커뮤니케이션을 조정한다. 예를 들어 인프라 담당자의 관심사는 노력과 비용일 것이다. 기술적인 세부사항으로 시간을 끌지 말자. 기술적 세부사항은 기술 전문가인 상대방에게 맡긴다.
6. 좋은 질문을 하기 위해서 기다리십시오.

### 분석

![분석](https://docs.google.com/drawings/d/e/2PACX-1vTjXFE6s_jDSqVUateAj-ufwgpr9dI_4Xwj1oMm-ObTmFa31tzluKbrx2SeEl2BBHSgLi5xFX5Biq2c/pub?w=1208&h=606)

1. 아무것도 가정하지 않는다. 사실로 부터 시작한다.
2. 위에서 부터 아래로 살핀다. 즉 기술 솔류션을 보기전에 비즈니스 요구사항을 먼저 확인한다.
3. 기능, 응용 프로그램, 기술, 비용 등 여러 관점에서 솔류션을 모델링 한다.
4. 이해 관계자와 함께 솔류션을 검토한다. 이해 관계자의 견해를 존중하고 이해해야 한다. 그렇지 않으면 잘못된 디자인이 만들어질 수 있다.
5. 시스템 사고를 한다. 단기적 사고가 아닌 전체를 바라보고 생각해야 한다. 제안된 솔류션으로 의도하지 않은 결과가 발생할 수 있는지를 검토한다.
6. 컴포넌트를 최적화하는 것은 기술 담당자에게 맡긴다. 아키텍트는 시스템을 최적화에 노력을 기울인다.
7. 누가 어떻게 유지보수 할 것인지를 검토한다. 유지보수하기 힘든 소프트웨어는 좋은 소프트웨어가 아니다.
8. 데이터 기반으로 사고 한다. 고객을 분석할 수 있는 데이터를 수집해야 한다. SA는 DevOps, Data 팀과 협력하여 데이터 파이프라인을 구축하도록 독려해야 한다.

### 문서화

![문서화](https://docs.google.com/drawings/d/e/2PACX-1vRSMooggVU68E28rZ-ikXLxgGL4SCwCHBZhEZlEzNlp961Bafh2NOGIhNu8AL8YmyAykFdi3pQBuBrs/pub?w=1036&h=486)
아키텍트는 많은 문서를 다루어야 한다. 문서화는 필수이며, 여기에서 **무엇을, 어떻게, 왜** 해야 하는지를 설명한다.

대부분의 사람들이 문서화를 싫어한다. 싫어하는 사람이 많다는 것은 문서화를 잘 하는 사람이 적다는 것을 의미하며, 이는 당신의 차별적인 능력이 될 수 있다.

문서화 관련해서는 구글의 [Technical Writing Courses](https://developers.google.com/tech-writing)를 읽어보도록 하자.

아래는 좋은 문서를 만들기 위한 팁이다.

* 문서의 목적과 대상을 이해해야 한다. 문서가 전달해야하는 정보가 무엇인지 누구에게 전달해야 하는지를 알아야 한다. 때때로 누구에게 전달해야 하는지가 더 중요 할 수 있다.
* 간결하고 요점을 유지한다.
* 일관된 용어를 사용한다.
* 챕터는 독립적이어야 한다. 대부분의 사람들은 기술 문서를 선형적으로 읽지 않는다. 관심있는 섹션으로 먼저 이동한다. 따라서 각 장이 독립적으로 충분한 맥락, 시각자료, 요약을 제공하는지 확인해야 한다.
* 표와 이미지를 적절하게 사용하자.
* Grammarly와 같은 도구를 사용한다.
* 문서협업 기능을 사용하여 피드백을 이끌어낸다.

## Governance

아키텍트는 비즈니스 전반에 걸친 대표자들로 구성된 위원회에 솔류션을 제안할 기회를 많이 가질 것이다. 본질적으로 엔지니어인 아키텍트에게  이러한 과정들을 지루게 느낄 수 있겠지만 동의와 지원을 얻어낼 수 있는 중요한 과정이다. 아키텍트 업무의 특성상 이들의 승인없이 다음 단계를 진행하기가 어려울 것이다.

이 과정을 부드럽게 완료하기 위한 몇 가지 팁이 있다.

1. 위원회의 누가 솔류션의 헛점을 찾아낼 수 있을지를 이해해야 한다. 위원회에 솔류션을 제안하기 전에 이들을 만나서 설계의도를 논의 한다. 이들은 우려사항을 얘기할 것인데, 이 우려사항은 프로젝트를 성공적으로 진행하기 위한 핵심 포인트가 될 수 있다. 몇 번의 피드백 과정을 거쳐서 설계를 수정하거나 적절한 응답을 준비 할 수 있다.
2. 새로운 패턴이나 기술을 제공하는 솔류션을 사용해야 할 경우 공급업체로 부터 검증을 받는다. 검증을 받았음을 설계문서에 포함한다면 설계의 채택확률이 높아질 것이다. 클라우드에서 서비스를 받고 있다면 MSP(Managed Service Provider)와 좋은 관계를 유지하도록 하자.

## 끊임 없는 학습

![Learn](https://docs.google.com/drawings/d/e/2PACX-1vQC-fxlaOwuJtuyI1Bi5w1MMzP-w9UI4ZS3GDnY8Pei47EQo4ItIn7FsXJybM6rKhNV5yxGSx8M0uue/pub?w=928&h=526)

끊임없이 배워야 한다. 안타깝게도 내가 만난 많은 사람들이 배움에 대한 열정을 잃은 것 같다.

또 다른 실수는 많은 아키텍트들이 기술 개발에 초점을 마추려한다는 것이다. 기술적인 능력도 도움이 되지만 아키텍처의 역할을 훨씬 더 중요하고 광범위 하다.

많은 아키텍트(기술자를 포함)들이 **불완전한 지식은 쓸모 없거나 오히려 위험하다**는 생각을 가지고 있다. 그렇지 않다. 우선 완전한 지식이은 없다는 것을 알아야한다. 실제 아키텍트 역할을 수행 할 때는 내가 얼마나 완전에 가까운 지식을 가지고 있는지가 아닌, 내 지식이 불완전할 수 있다는 것을 이해하고 다른 전문가, 문서를 통해서 솔류션을 완성시켜나가는 **개방된 자세** 가 더 중요하다.

이런 개방된 자세를 가지고 있다면, 불완전하더라도 많이 알 수록 도움이 된다.

이것은 진화의 단계와 같다. 완전한 눈이 도움이 되지만 불완전한 눈도 도움이 된다. 아무 것도 없는 것보다는 안점이 있어서 빛을 향해 나아갈 수 있는게 생존에 도움이 되며, 수정체가 없어서 상이 흐릿하더라도 시신경집합이 있는게 도움이 된다. 컬러가 안되더라도 흑백으로 바라볼 수 있는 눈이 도움이 된다.

지식도 마찬가지다. 알고 있으면 도움이 된다.

학습을 위한 팁은 아래와 같다.

1. 자갈이 아닌 바위에 촛점을 맞춘다. API Gateway 제품을 학습해야 한다면, 사용 목적, 핵심 기능, 제약 사항을 아는 것은 반드시 알아야 하지만 제품의 내부 동작은 그렇지 않다. (여기에서 그렇지 않다는 것은 필요 없다는게 아닌 더 낮은 우선순위라는 의미다.)
2. 가능하면 분산 메시징 아키텍처, 디자인 패컨, 클라우드 개념과 같은 특정 기술에 구애받지 않는 기본 사항을 배운다. 기술은 항상 변하지만 기본 개념은 영구적이다.
3. 다양한 관점을 추구해야 한다. 저자, 사업가, 백앤드 개발자, 보안 담당자의 관점으로 전환하여 그들의 설명이 내 **mental model**과 일치하는지를 살핀다. 특히 아키텍트는 뛰어난 시각화 능력을 가지고 있어야 한다. 주제를 완전히 이해해야 시각화 할 수 있다. 어떤 주제를 시각화 할 수 없다면, YouTube, 인프그래픽등을 검색해보자.
4. 실제 만들어 본다. 내 경험상 주어진 기술에 대한 이해를 촉진하는 가장 좋은 방법이다. 클라우드를 잘 활용하면 이 과정을 보다 빠르고 쉽게 진행 할 수 있다.
5. 전문가에게 묻는다. 시간을 아끼는 가장 좋은 방법이다.
6. 지식저장소를 만든다. Notion, Confluence 등에 내 생각을 정리한다.

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories