솔루션 아키텍트 (Solution Architect) 고찰

칼럼을 읽고 나름대로 정리해보았다.

 

정의

 

솔루션 아키텍트(Solution Architect - SA)는 시스템과 컴포넌트, 기능들을 결합 및 통합하는 일을 한다.

비즈니스 요구사항을 기술 언어로 번역하여서 전달하는 업무도 함께 수행한다.

이 과정에서 다양한 기술 제공 업체, 내부 기술팀, 기획팀, 사업팀과 협업하면서 비즈니스 방향, 고객 가치, 기술이 서로 일치하는지를 확인한다.

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

 

 

 

업무

 

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

 

 

필요한 능력

 

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

 

 

종류

 

엔터프라이즈 아키텍트

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

어떤 회사가 자체 솔루션을 개발하려고 하는데 그 솔루션의 아이디어가 금방 다른 경쟁업체에 따라잡힐 기술이라던가, 곧 쓸모가 없어질 위기에 놓여있다던가, 수익성이 생기기 힘들다던가 등등의 항목들을 검토하여 회사의 방향을 잡아줄 수 있다. 사업 구조를 분석하고 계획을 수립한다는 것은 솔루션 아키텍트와 같다.

 

 

 

공부 방향

 

1. 지식의 깊이보다는 넓이

 

특정 기술에 대한 심층적인 지식 보다는, 솔루션에 대한 광범위하지만 얕은 지식을 더 중요하게 생각한다.

기회비용적인 이유이다. 심층적인 지식은 유지 관리해야 가치를 지속시킬 수 있는데, 문제는 소프트웨어 세계에서 고정된 것은 없으며, 매우 빠르게 변한다는 것이다.

예를 들어 테라폼의 심층 전문가가 되었다고 하더라도 해당 전문지식을 1년동안(6개월이면 전문성을 잃어버리기에 충분히 긴 시간이다.) 사용하지 않으면 전문성을 지속 할 수 없다.

 

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

왜냐하면 아키텍트는 프러덕트의 기능을 기술적 제약에 맞게 결정해야 하기 때문이다.

제약에는 성능, 기능, 품질, 시간, 시장 이 표함되기 때문에 다양한 솔루션에 대한 폭넓은 이해가 중요하다.

 

시간에는 기회비용적인 제한이 있기 때문에 모든 것들에 대한 전문지식을 유지 할 수가 없다.

따라서 아키텍트는 힘들게 얻은 전문 지식을 희생하고 그 시간을 포트폴리오 확장에 쓰는게 현명한 전략이다.

(그래서 SA팀을 이루어서 역할을 효율적으로 분담하는 전략을 취하는 AWS 같은 회사들도 있다.)

 

 

2. 의사소통

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

 

3. 문서화

 

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

 

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

 

4. 지식에 관한 개방된 자세

 

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

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

 

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

 

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

 

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

 

 

 

구글 엔지니어 테크니컬 라이팅 과정

https://developers.google.com/tech-writing

 

https://www.joinc.co.kr/w/solution-architecture-foundations