brunch

매거진 미국 연구원과 엔지니어의 길

라이킷 18 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 예나빠 Dec 17. 2024

아키텍트는 어떤 역량과 경력이 필요한가?

도메인 전문가의 길

<면책조항>
이 시리즈 글에서 발행하는 내용은 개인적인 사견이며 내가 거쳐온 전현직 회사의 의견을 대표하지 않는다. 또한 해당 회사들에서 접했던 어떠한 기술적인 내용, 대외비에 해당하는 사항을 일절 포함하지 않는다.

1. 아키텍트란 어떤 직무인가

2. 아키텍트는 어떤 역량과 경력이 필요한가

3. 나는 어떻게 아키텍트가 되었는가

지난 글에서 아키텍트 직무에 대해 개괄하면서, 아키텍트는 시스템 반도체 개발 과정의 최전단에서 일하는 사람이라고 했다. 최종적으로 생산될 반도체의 개념적인 구성과 논리적인 구조를 설계하는 직군이다. 오늘은 아키텍트가 되기 위해 어떤 역량이 필요하며 어떻게 경력을 쌓아야 하는지 이야기한다.

아키텍트는 어떤 역량이 있어야 하는가

아키텍트 업무를 수행하기 위해서는 컴퓨터 구조에 대한 폭넓은 지식, 설계하는 시스템이 적용되는 응용 분야에 관한 도메인 지식, 모델링 스킬셋, 논리적 사고력, 커뮤니케이션 및 글쓰기 능력, 그리고 아키텍쳐 설계 경험이 필요하다. 배경 지식은 일반화와 전문화의 조합으로 이뤄진다. '마이크로프로세서'와 같은 일반적인 컴퓨터 구조 지식을 바탕으로, 특정 도메인의 대표 알고리즘, 표준/API와 같은 상위 수준의 전문 지식이 함께 조화되어야 한다.

1. 컴퓨터 구조 지식

아키텍트로서 가장 기본은 컴퓨터 구조(Computer Architecture: CA)에 대한 폭넓은 지식이다. ‘아키텍트’라는 이름에 걸맞게 ‘아키텍처’에 밝아야 하는 것은 당연하다. 명령어 집합(Instruction Set), 캐시, 메모리 유닛, 가상/물리 주소, 명령어 파이프라인, 비순차 실행, 병렬화(SIMD, SIMT, HW Thread 등) 등 마이크로프로세서의 주요 기본 지식은 머리에 담겨 있어야 한다.

대부분의 대학에서 CS/EE 트랙 공통으로 컴퓨터 구조 과목을 포함하고 있다. 아키텍트가 되려면 학부 시절에 이 과목을 반드시 이수해야 한다. 사실 학부 수준의 CA 과목만으로는 부족한 경우가 많다. 아키텍처 분야는 시간에 따라 계속 발전하기 때문이다. 교과서로 배우는 아키텍처는 이미 오래된 세대의 제품을 기반으로 한다. 따라서 필요하다면 대학원에서 심화된 CA 과목을 이수하는 것도 고려해야 한다. 대학원 수업은 교과서뿐만 아니라 최근 논문을 읽고 발표하는 세미나 형식으로도 진행되어 최신 트렌드를 따라잡는 데 도움을 준다.

가능하면 대학원 진학 시 ‘컴퓨터 구조’를 연구하는 연구실에 합류하는 것이 좋다. 이러한 연구실에서 수행하는 연구 활동은 컴퓨터 구조 지식을 바탕으로, 특정 도메인을 주제로 한 새로운 아키텍처를 설계하는 일을 한다. 이는 실제 업계에서 아키텍트가 하는 일과 일정 부분 유사하다.

2. 도메인 지식

아키텍트는 대표적인 도메인 전문가다. 프로그래밍이나 회로 설계와 같은 범용적인 스킬셋을 발전시키는 것이 아니라, 특정 분야에 대한 깊은 도메인 지식을 축적하며 전문성을 발전시키는 커리어를 걷는다. 예를 들어 GPU 아키텍트라면 기본적으로 ‘3차원 그래픽스’에 대한 이해도가 높아야 하고, NPU 아키텍트라면 AI에 대한 도메인 지식이 풍부해야 한다.

아키텍트는 궁극적으로 '최적의' 아키텍처를 설계해야 한다. 해당 도메인의 전문 지식 없이는 좋은 아키텍처를 고안할 수 없다. 가장 상위 수준에서 시스템을 설계하기 때문이다. 설계할 반도체 위해서 동작하는 응용 프로그램이 어떤 알고리즘으로, 어떤 연산(Computing) 및 메모리 접근 특성을 갖고 있는지 이해해야 이에 최적화된 시스템을 설계할 수 있는 것이다.

물론 x86 CPU, 마이크로 프로세서와 같이 범용성 높은 시스템 반도체의 아키텍처를 설계하는 이들도 있다. 또한 메모리, 전력/에너지 관리와 같이 시스템의 특정 영역에서 전문성을 발전시킨 아키텍트들도 있다. 이러한 시스템 반도체 또는 직군은 범용성을 지향하는 것처럼 보일수 있다. 그리고 이들이 아키텍쳐를 설계하는 시점에도 다양한 응용 분야를 상정한 벤치마크를 돌려 성능 평가를 한다. 하지만 이러한 평가 시점에 각 응용 분야가 갖는 연산, 메모리 접근 특성을 비교하며 분석하기 때문에 도메인 지식이 역시 요구된다.

또한 아무리 범용적인 목적의 반도체라 할지라도 몇가지 응용 분야에 가중치를 두어 설계를 한다. 모든 응용을 '잘' 처리할 수 있는 하드웨어를 설계하는 것은 불가능하기 때문이다. 시스템 반도체는 범용성을 높일수록 많은 응용을 처리할 수 있는 유연성(Flexibility)는 높아지지만, 그만큼 설계 비용은 높아지고 성능, 전력 소비 효율은 떨어진다. 사실 시스템을 설계할 때 범용성과 전문성은 각각 장단점이 있어서 이들을 적절히 섞어야 한다. 요지는 아무리 범용성 높다 할지라도 목적하는 응용 분야들에 대한 도메인 지식을 갖출수록 좋은 아키텍트를 설계할 수 있다는 것이다.

3. 모델링 스킬셋

지난 글에서도 잠깐 언급했지만, 아키텍트가 갖춰야 할 대표적인 스킬셋은 '모델링'이다. 설계된 아키텍처는 '스펙' 문서로만 존재하지 않는다. 스펙을 작성하기 전, 아키텍트는 자신의 아키텍처를 기능적으로 검증하고, 성능과 비용을 평가하기 위해서 '모델'을 구축한다. 모델은 이후 회로 설계 엔지니어에 의해 구현될 실제 하드웨어를 모사하는 일종의 소프트웨어다.

하드웨어인데 소프트웨어라니 혼란스러울 수도 있을 것이다. 쉽게 말해 모델은 일종의 가상화(Virtualization)된 시스템이다. 물리적으로는 소프트웨어 형태로 존재하지만, 그 소프트웨어가 수행하는 작업은 모사(模寫)된 하드웨어의 계산 및 메모리 연산인 것이다.

예를 들어, CPU를 모델링한 소프트웨어는 명령어 파이프라인, 스케줄러, 연산기, 레지스터, 캐시 및 메모리 계층, 가상 주소 변환기와 같이 실제 CPU 반도체로 구현될 기능 블록들이 모두 모듈화해 담는다. 그리고 각 모듈은 컴파일된 명령어들을 인출-디코딩-실행-출력-메모리 쓰기 등의 실제 CPU의 명령어 파이프라인에서 처리하는 방식을 동일하게 수행한다. 그 과정에서 Load/Store와 같은 메모리 명령이 발생하면 물리 주소를 가상 주소로 변환해 캐시로 접근하고, 캐시는 적중/실패 결과에 따라 하위 계층의 메모리로 또 다시 접근하는 등 실제 하드웨어에서 벌어지는 일련의 과정을 모사하게 된다.

모델이 하드웨어를 모사하기 때문에 이를 또 다른 말로 '시뮬레이터(Simulator)'라고 부르고, 결국 모델링은 아키텍처 시뮬레이터를 구현하는 일이다. 시뮬레이터의 주된 두 가지 목적은 1) 기능 검증과 2) 성능 평가다. 따라서 시뮬레이터도 두 가지 형태로 존재하는데, 기능 검증을 위한 Functional Simulator(FS), 성능 평가를 위한 Performance(또는 Cycle-Accurate) Simulator(PS) 이다. FS는 기능 검증용이기 때문에 아키텍처상의 주요 모듈/블록/유닛의 고유 연산, 메모리 입출력 값만 정확하면 된다. 입력이 주입되었을 때 의도된대로 결과가 도출되기만 하면 되는 것이다. PS는 성능 평가용으로서 주요 모듈/블록/유닛에서 연산을 수행했을 때, 메모리를 접근했을 때 실제 하드웨어서 얼마큼의 지연시간(latency)을 소요하는지 모두 추적해야 한다. 최종적인 성능 값을 계산할 수 있기 때문이다. 그만큼 PS는 FS에 비해 구현 복잡도도 높고, 시뮬레이션 시간도 오래걸린다.

시뮬레이터는 객체지향 프로그래밍 언어로 구현한다. 그 이유는 하드웨어 시스템을 구성하는 여러 모듈/블록/유닛은 독립적으로 동작하기 때문에, 객체화 및 추상화라는 기본적인 철학을 갖는 객체지향 언어와 잘 어울리기 때문이다. 최근에는 Google의 Go나 Rust로 구현하는 사례들도 있지만, 여전히 업계에서는 대부분 시뮬레이터를 C++로 구현하고 있다. C++ 프로그래밍에 능숙해야 한다.

시뮬레이터는 일반 응용 소프트웨어와 개발 방법론이 다소 다르다. '클럭'이라는 동기에 맞춰 동시 수행되는 하드웨어의 모든 모듈을, 순차적으로 실행될 수 밖에 없는 소프트웨어로 모사하기 때문에 그만의 독특한 구현 방식이 존재한다. 또한 시뮬레이터 자체의 실행 속도가 느리기(하드웨어의 모든 동작을 모사하기 때문이다) 때문에 이를 가속하기 위해 멀티 쓰레드와 같은 병렬 프로그래밍 방법론도 동원되기도 한다. 따라서 이에도 친숙해야 한다. 다행스럽게도 학계에는 아키텍처 연구원들이 구현해 놓은 다양한 오픈소스 시뮬레이터들이 많다. 이러한 코드 분석을 시작으로 자연스럽게 모델링 스킬을 익혀나갈 수 있다.

4. 논리적 사고력 및 글쓰기 능력

아키텍트에게 논리적 사고력은 특히 중요하다. 자신이 설계한 아키텍처를 시뮬레이션하고 그 결과로 도출된 다양한 성능 지표의 숫자들을 보고 내부에서 벌어지는 현상을 유추할 수 있어야 한다. 가장 빈번히 수행하는 작업은 어느 지점이 병목인지 파악하는 것이다. 연산쪽이 병목인지, 아니면 메모리 접근이 병목인지를 확인하고 이를 해결하기 위해 연산기나 버퍼를 더 내장해야 하는지, 메모리 접근을 최적화해야 하는지를 결정할 수 있어야 한다.

또한 시스템 반도체의 가장 기본적인 평가 지표인 성능, 전력소모, 면적(Performance, Power, Area, PPA)간에는 상충관계가 존재하고, 설계 시점에 대한 예산 또는 목표치가 설정되어 있기 때문에, 주어진 예산 내에서 최고의 성능을 도출할 수 있도록 아키텍처 파라미터를 수정하면서 반복적으로 시뮬레이션 한다. 이 과정에서 각기 다른 모델에서 도출되는 결과값들을 비교 분석하려면 고도의 사고력이 동원되어야 한다.

또한 아키텍트만큼 글쓰기 능력이 중요한 엔지니어 직군도 없다. 최종적으로 '아키텍처 스펙'을 작성해야 하기 때문이다. 아키텍처가 등장한 배경, 동작 방식과 이에 대한 도면, 모듈간 인터페이스, 상태 기계(State Machine), 하드웨어 연산의 주요 의사 코드를 정확하고 구체적으로 기술해, 그 스펙을 읽은 회로 설계 엔지니어가 RTL 설계를 즉시 착수할 수 있어야 한다. 따라서 논리적인 글쓰기 능력은 필수적이다. 어쩌면 모델링 스킬셋보다도 더 중요할 수 있다. 만일 미국의 시스템 반도체 회사의 아키텍트가 되려면, 당연하게도, 이를 영어로 작성할 수 있어야 한다.

5. 커뮤니케이션 능력

여느 엔지니어 직군과 마찬가지로 아키텍트들도 빈번히 협업을 한다. 특히 팀내의 여러 아키텍트들은 자신의 책임진 모듈을 설계하지만 이 모듈은 서로 연결되어 있기 때문에 설계시 수시로 소통을 해야한다. A 아키텍트가 설계한 모듈의 출력이 B 아키텍트가 담당한 모듈의 입력으로 주입되는 경우 이에 대한 규약을 서로 합의해야 한다. 사이클당 어느 정도 크기의, 어떤 종류의 데이터를 출력/입력할지를 사전에 결정하는 것이다. 그리고 서로의 아키텍처의 스펙, 모델링된 코드를 상호 리뷰해주면서 빈번히 소통한다.

아키텍처 설계 단계의 앞뒤에 존재하는 유관부서의 엔지니어들과도 수시로 소통한다. 실제 반도체로 구현되었을 시 해당 실리콘으로 작업하는 모든 엔지니어들과 업무상 연관되어 있다. 응용 소프트웨어를 분석하는 소프트웨어 엔지니어, 디바이스 드라이버나 컴파일러 엔지니어들과는 최적의 아키텍처를 구현하기 위해 수시로 소통한다.

또한 자주 만나게 되는 직군이 바로 RTL 회로 설계 엔지니어들이다. 아키텍트가 설계한 아키텍처를 실제 하드웨어로 구현하는 이들이기 때문이다. 아키텍처 설계 시점에 자신의 아이디어가 실제 하드웨어로 구현이 용이할 지, 쉽지 않다면 발생할 문제들을 상호 협의하며 점검한다. 스펙을 전달한 뒤 사후 처리도 해줘야 한다. 스펙에 모호한 지점이 발생할 수도, 의사코드에 버그가 있을 수도 있다. RTL 엔지니어들이 구현 과정에서 제기하는 여러가지 피드백에 따라 스펙을 보완하거나 버그를 고쳐줘야 한다.

따라서 다양한 직군의 엔지니어들과 빈번한 소통을 해야하기 때문에 원활한 의사소통 능력은 필수적이다. 자신의 의사, 의견을 정확히 논리적으로 전달하는 말하기 능력이 무엇보다 중요한 이유다.

아키텍트는 어떻게 될 수 있는가

그렇다면 이러한 역량을 키워 아키텍트가 되려면 어떠한 학계, 업계 경력을 쌓아야 하는지 살펴보자. 사실 정답은 없다. 아키텍트가 되는데 있어 한가지 길만 존재하지 않고 꽤 비정형화된 커리어 패스를 갖기 때문이다. 따라서 우선 향후 아키텍처 팀에 필요할 한가지 분야의 전문성을 띄는 커리어를 시작해야 한다. 이론적인 완성도가 높은 도메인 응용 SW 엔지니어, 또는 아키텍처 모델링 엔지니어, RTL 엔지니어, 아키텍처 연구원 등이다.

그리고 현재 직군에서 궁극적으로 아키텍트가 되기 위한 방향성을 설정하고 앞에서 말한 스킬셋을 보완해 나가야 한다. 특히 앞에서 말했듯 아키텍트들은 다양한 직군과 협업을 한다. 이러한 아키텍트들과 협업을 하는 직군에 종사하면 간접적으로 아키텍처 업무를 접할 수 있다. 특히 아키텍트들이 작성한 스펙 문서를 읽으면서 아키텍처 설계 능력과 향후 이정도의 문서를 작성할 역량을 갖춰야 할 것이라고 파악할 수 있다.

아키텍트 성장 로드맵. 출처: 예나빠 뇌피셜

위 그림은 내가 생각하는 아키텍트 성장 로드맵이다. 미리 말하지만 절대적인 것은 아니다. 필자의 업계 경험, 만났던 아키텍트 동료들의 배경 등을 바탕으로한 것으로, 그외의 길도 존재할 수 있을 것이다. 자신이 이러한 커리어 패스에 빗겨났다 해도 너무 실망하지 않았으면 좋겠다.

우선 아키텍트는 그 자체로 도메인 전문가 이기 때문에 대부분 한 분야에서 일정 경력을 축적한 경력자인 경우가 많다. 우리로 치면 수석(부장)급 정도의 경력을 보유한 이들이다. 물론 주니어 레벨의 아키텍트들도 존재하고 실제로 채용도 한다. 다만 그 경우가 많지 않고, 그들도 대부분 아키텍처 연구를 하던 대학원생이 인턴을 통해 합류하는 경우다.

일단 아키텍트 엔지니어의 전공은 컴퓨터 과학(CS)과 전기전자(EE) 계열로 나눠진다. 특히 아키텍트는 EE보다 CS계열을 전공한 이들이 더 많다. 하드웨어 설계니 EE계열이 더 많을 것으로 생각하기 쉽지만, 앞 글에서 말했듯 아키텍처 설계 업무는 수리적, 알고리즘적인 사고와 연관이 높고, 특히 객체지향 모델링 스킬셋이 필수적이기 때문이다. CS의 커리큘럼을 소화하면 이러한 1차 요구사항을 자연스럽게 해결할 수 있다. EE의 커리큘럼은 회로 이론, 전자기학 등의 반도체 세부 수준을 소화하기 때문에 학부시절에 이러한 스킬셋을 배양할 기회를 갖기 다소 어려울 수 있다.

CS계열의 전공자라면 학부시절에 컴퓨터 구조 과목은 확실히 이수하고, C/C++ 프로그래밍 실력을 충분히 쌓아 두어야 한다. 파이썬과 같은 스크립트 언어도 해두면 도움이 된다. 모델링시 스크립트를 활용할 기회가 의외로 많기 때문이다. 그리고 운영체제, 컴파일러, 시스템 프로그래밍과 같은 하드웨어 시스템과 연관된 과목들은 가능하면 들어 두어야 한다. 배경 지식을 쌓는데 큰 도움이 된다.

EE계열도 학부 커리큘럼에 컴퓨터 구조, 마이크로 프로세서 설계 등의 과목이 있을 것이다. 아키텍트가 되려면 이를 반드시 이수하여 아키텍처 지식을 확보해야 한다. CS와 달리 객체지향 프로그래밍 과목은 개설되어있지 않거나, 선택 필수인 공대 공통으로 개설되어 큰 관심이 없다면 수강하지 않을 수도 있다. 반드시 수강해 스킬셋을 확보해 두어야 한다. 특히 다양한 프로그래밍 프로젝트를 진행하는 CS와 달리 EE에서는 프로그래밍 기회가 많지 않으므로 일회성 수강에 그치지 말고 개별 프로젝트라도 진행해 충분히 C++ 실력을 갖춰두어야 할 것이다. 또한 신호처리, 영상처리, 암호학, 통신이론과 같이 특정 도메인을 깊이 있게 공부하는 과목들도 들어두면 좋을 것이다. 향후 해당 도메인의 아키텍트가 된다면 근본이 되어줄 지식이 된다.

CS/EE 공히 최소 석사까지는 해두는 것을 추천한다. 사실 학부 커리큘럼 및 인턴십 경험으로는 향후 아키텍트로 나아가는 역량을 쌓는데 한계가 있다. 대학원 커리큘럼 및 랩에서 진행하는 연구 주제를 통해, 더 깊이 있는 지식을 쌓아 향후 도메인 전문성을 확보할 수 있기 때문이다. 그리고 만일 박사까지 할 생각이 있다면, 가능하면 ‘컴퓨터 구조’를 연구하는 랩으로 진학하는 것이 좋다. 연구 주제 자체가 아키텍처이고, 연구 활동에서 수행하는 일들이 아키텍처 설계, 모델링으로서 현장에서의 아키텍트의 업무와 매우 유사하다. 또한 영문 논문을 작성하고 발표하는 일을 하면서 자연스럽게 논리적인 글쓰기 능력도 길러진다.

박사 과정을 하게되면 졸업 전까지 아키텍처가 아닌 한 도메인의 전문가가 되어야 한다. 아키텍처는 도메인 없이 존재하지 않는다. 그리고 학위 과정 시 시스템 반도체 회사의 아키텍처 팀에서 인턴십 경험을 쌓고, 팀에 좋은 인상을 주었다면 졸업과 동시에 아키텍트로 커리어를 시작할 수도 있다. 드물지만 불가능한 경로도 아니다. 이미 대학원 시절에 아키텍처 연구를 진행한 경험이 있고, 도메인 지식이 축적되어 있기 때문에 필요한 역량과 스킬셋이 충족되기 때문이다.

회사마다 아키텍처 연구조직이 있는 경우도 있다. 만일 박사후 아키텍트보다 연구원의 길을 가고자 할 수도 있다. 이 경로를 걷다가 향후 생각이 바뀌어 아키텍트로 충분히 변신할 수도 있다. 그만큼 하는 일이 유사하기 때문이다.

만일 석사까지만 하고 업계에서 엔지니어 커리어를 시작한다면, 가능한 아키텍트들과 협업하는 직군으로 나아가야 한다. CS는 졸업후 소프트웨어 엔지니어가 주를 이룰 것이다. OS, 컴파일러, 디바이스 드라이버와 같은 시스템 소프트웨어 분야가 그나마 가능성이 높다. 프론트엔드, 백엔드, 풀스택 엔지니어는 해당사항이 없다. 도메인 보다는 SW 기술 스택에 기반한 스킬셋 전문성 위주로 커리어가 발전될 것이기 때문이다.

응용 분야로 시작하고자 하면, 시스템 반도체와 연관 있는 도메인 분야로 시작해야 한다. 가령 GPU 아키텍트라면 그래픽스 전문성을 가진 도메인 소프트웨어 엔지니어들이 지향할 수 있다. Unreal이나 Unity와 같은 게임 엔진, RenderMan, Arnold, Hyperion과 같은 렌더러를 개발하던 렌더링 엔지니어들이다. 다만 이러한 도메인 SW 엔지니어들은 시스템 반도체 회사 내에 해당 직군이 존재하지 않고, 종사 업계도 다르기 때문에 향후 반도체 업계의 아키텍트로 지원시 그만큼 해당 도메인에 대한 철저한 전문성(탄탄한 이론)을 차별화 포인트로 삼아 승부해야 한다.

만일 아키텍처 랩에서 석사를 하면서 아키텍처 모델링에 스킬셋을 쌓았다면 이를 갈고 닦아, 모델링 엔지니어로 커리어를 시작할 수 있다. 미국의 시스템 반도체 회사에는 모델링만 전문으로 담당하는 별도의 팀이 존재하거나 아키텍처 팀에서 모델링 엔지니어를 별도로 채용하곤 한다. 모델링 엔지니어는 아키텍트와 긴밀하게 협업하기 때문에 경력을 쌓으면서 자연스럽게 도메인 지식을 축적해 아키텍트로 변신할 수도 있다.

EE는 석사 졸업 후 다양한 길이 있지만, 향후 아키텍트가 되려면 일단 ‘RTL 엔지니어’로 시작해야 한다. 회로 설계 엔지니어는 아키텍트가 작성한 스펙을 파악해 디지털 시스템을 설계하는 직군이다. 아키텍처 팀에서 이러한 역량을 가진 이들도 필요하다. 아키텍처는 궁극적으로 RTL로 구현될 것이기 때문에 이에 대한 이해도가 높은 아키텍트가 있으면 큰 도움이 되기 때문이다. RTL 엔지니어가 향후 아키텍트로 변신을 하기 위해서 현재 몸담고 있는 도메인 바꿔가며 커리어를 발전시키면 안된다. 도메인 전문성보다는 회로 설계라는 스킬셋 전문성만 쌓이기 때문이다.

각 엔지니어 직군의 보유 역량과 아키텍트로의 직군 전환을 위한 보완 역량. 출처: 예나빠 뇌피셜

정리하자면, 학부나 대학원 시절에 컴퓨터 구조에 대한 전반적인 배경 지식, 향후 모델링시 필요한 객체 지향 프로그래밍 능력을 충분히 기르고, 대학원에 진학해서는 도메인 지식과 모델링 스킬셋을 축적한 뒤, 향후 아키텍처 팀에서 필요로 할 전문성을 갖는 직군의 커리어를 시작하면 된다. 그리고 커리어를 쌓아가면서 향후 아키텍트로 직군을 전환할 수 있도록 부족한 역량과 스킬셋을 보완해 나간다. 만일 도메인 쪽에서 시작했다면 아키텍처 측면을, 회로 설계 쪽에서 시작했다면 도메인 측면에서 역량을 채워 나간다. 만일 특정 도메인의 아키텍처 자체를 주제로 박사 학위를 취득했다면 졸업후 직접 아키텍트로 지원해 볼 수 있다.

출발점은 달라도 목적지는 같다

아키텍트로의 길이 다소 복잡한 커리어 패스를 갖는 이유는, 다다르기 위한 단 하나의 테크트리가 존재하지 않기 때문이다. 그만큼 좋은 아키텍처를 설계하기 위해서는 이 분야간의 지식과 스킬셋이 충돌해야 한다. 실제로 미국 시스템 반도체 회사에서 종사하는 아키텍트들은 다양한 배경을 갖고 있다. 아키텍처 팀은 응용 분야의 연구 동향, 소프트웨어 기술, 알고리즘과 도메인 전문 지식, 모델링 기술, RTL 수준의 시스템 이해도를 보유해야 한다. 하지만 이를 전부 할 수 있는 사람은 없기 때문에 분야별 전문가가 모여 상호 보완, 협업을 통해 하나의 완성품을 만들어 나가는 것이다.

그렇게 아키텍처 팀에서 경력을 쌓으면, 구성원들은 서로의 전문분야를 조금씩 흡수하며 '진정한 아키텍트'가 되어간다. 따라서 소프트웨어 엔지니어, 모델링 엔지니어, RTL 엔지니어, 연구원은 잠재적으로 모두 아키텍트가 될 수 있지만, 그 전제조건은 그 모두가 함께 팀을 이뤄야 한다는 것이다. 이들의 커리어 출발점은 다르지만 결국 단 하나의 목적지로 귀결한다. 아키텍트가 되는 시점에 모두 ‘도메인 전문가’가 되어 있다는 것이다. 이러한 과정을 염두해 아키텍처로의 커리어를 설계해야 할 것이다.

다음 글에서는 마지막으로 필자는 어떤 경로를 통해 GPU 아키텍트가 되었는지 그 과정을 소개할 것이다. 많은 기대 바란다.

- 예나빠

표지 이미지: Book Cover of 'The Art of Hardware Architecture: Design Methods and Techniques for Digital Circuits' Springer 2012

엔지니어 커리어에 관해 질문있으시면 언제든 아래 글에 댓글 남겨주시기 바랍니다.

질문받겠습니다.

ChatGPT보다는 대답 잘해보죠. | 그동안 미국 취업/이직을 염두에 두고 있는 공학도나 직장인들을 위한 글을 브런치에 써왔고, 지금도 글을 연재하고 있습니다. 한국에 있을 엔지니어들에게 해

brunch.co.kr/@airtight/213

예나빠 브런치 북/매거진 소개

자기계발/정보전달/칼럼

글로벌 엔지니어 성장 로드맵 - 한국의 공학도/경력자들을 위한 자기 계발서 (출간예정)

미국 오기 전에 알았으면 좋았을 것들 - 미국 진출을 원하는 한국 경력자들을 위한 자기 계발서

미국 연구원과 엔지니어의 길 - 미국 기업 연구원/엔지니어에 대한 정보 전달