Show Cover Slide

Who I Am — 흐름을 구조로 만드는 사람

글을 쓰는 이유

안녕하세요.
이 글은 제가 해온 일들을 돌아보며, 제가 어떤 방식으로 일해왔는지를 정리해보려는 시도입니다.

완성된 정의를 제시하려는 글은 아닙니다.
정리되지 않은 채 흘려보낸 시간과 판단들을 이제야 조금씩 언어로 꺼내보고 있는 중입니다.

개인의 열량은 같은 직무에서도 다르게 나타납니다.
저는, 나에게 자연스러웠던 사고방식과 일하는 방식을 정리하면서, 앞으로의 방향을 스스로 찾아가려 합니다.

나에 대한 회고

많은 조직에서 저는 빠른 사람으로 기억되었습니다.

새로운 기술을 포팅하거나,
기존 시스템과 외부 서비스들을 빠르게 연결하고,
누군가 해결하지 못했던 문제를 대신 풀어내는 역할을 맡았습니다.

그래서 “빠른 개발자”, “문제를 해결해주는 사람”으로 불렸습니다.
그 말이 틀린 것은 아니지만, 저는 속도를 목적으로 삼아 일한 적은 거의 없습니다.

빠르다는 평가는 결과일 뿐이었습니다.
그 결과를 가능하게 만든 것은 ‘속도’가 아니라, ‘구조’에 대한 집착이었습니다.

내가 잘하는 것 : 속도를 만든 것은 구조였다

비즈니스에서 원하는 결과를 빠르게 전달할 수 있었던 것은, 항상 구조를 먼저 생각했기 때문입니다.

• 이 요청은 어디서 시작되었는가?
• 무엇이 핵심이고, 무엇은 과감히 버릴 수 있는가?
• 어떤 선택이 팀 전체의 부담을 줄여줄 수 있는가?

항상 이런 질문들을 먼저 던졌습니다.
그리고 최소한의 구조를 만들고, 그 위에 실행을 쌓아 올렸습니다.

돌이켜보면,
저는 문제를 직접 푸는 것보다,
문제가 다시 생기지 않도록 판단과 실행이 가능한 기반을 만드는 일에 더 매력을 느껴왔습니다.

그 일이 저를 오래 집중하게 만들었고, 결국 빠른 결과를 가능하게 했습니다.

보이지 않는 구조는 쉽게 잊힌다

특히 스타트업에서는 역할이 뚜렷하지 않습니다.

구조를 설계하거나, 프로세스를 재정리하는 일이 있어도 겉으로 보이는 것은 단지 “문제가 해결되었다”는 결과일 뿐입니다.

그나마 남는 것은 프레임워크나 코드 구조 같은 산출물 정도입니다.

그리고 시간이 지나면,

“결국 별 거 아니었네.”
라는 말로 정리되기도 했습니다.

‘아키텍트’라는 표현은 변화하는 시대의 흐름 속에서 점차 중요성을 잃어갔습니다.

구조를 만들고, 문제를 ‘별 것 아니게’ 만든 과정은 조명받지 못했고, 그 의미 역시 쉽게 사라져갔습니다.

그 과정 속에서 저는 저를 표현할 언어도 갖추지 못했습니다.

시대의 흐름 속에서 조용히 구조를 만들어왔지만, 그 중요성을 설명할 방법은 점점 더 잃어갔습니다.

아키텍트라는 말의 고민

저는 저를 컴퓨팅으로 비즈니스의 고민을 해결하는 사람으로 설명해왔습니다.
하지만 이 설명은 너무 추상적이었고, 공감을 얻어내기 어려웠습니다.
그래서 한동안은 ‘엔지니어’라는 단어로 제 역할을 정의하곤 했습니다.

그러나 시간이 지나면서,
제가 해온 일들을 돌이켜보고, 그것들을 설명할 수 있는 더 정확한 언어를 찾고 싶어졌습니다.

그때 제 시선은 자연스럽게 ‘아키텍트’라는 단어에 머물렀습니다.

하지만 단순히 역할을 지칭하는 말로만 사용하고 싶지는 않았습니다.
저는 ‘아키텍트’라는 말이, 구조적 사고의 깊이와 판단 가능한 기반을 만드는 책임까지 담아야 한다고 생각하게 되었습니다.

그래서 저는 아키텍트를 이렇게 정의하고 싶습니다.

• 판단 가능한 구조를 만드는 사람
• 단순히 기술을 고르는 사람이 아니라, 기술을 고를 수 있는 조건을 만들어주는 사람.
• 무엇을 할지 결정하는 사람이 아니라, 왜 그렇게 해야 하는지를 조직이 스스로 설명할 수 있도록 돕는 사람.

그것이 제가 바라보는 아키텍트의 역할입니다.

아키텍트가 필요한 이유

조직이 작고 미숙할 때는, 문제 자체를 해결하는 것이 최우선입니다.

하지만 조직이 성장하면, 더 이상 문제 하나하나를 해결하는 것만으로는 충분하지 않습니다.

문제는 다시 생겨나고, 흐름은 점점 복잡해집니다.

이때 필요한 것은

• 더 많은 인력,
• 더 많은 프로젝트,
  이런 것들이 아니라, 문제를 다시 생기지 않게 만드는 구조입니다.

저는 아키텍트를

문제를 해결하는 사람이 아니라,
문제를 다시 생기지 않게 하는 구조를 설계하는 사람
이라고 생각합니다.

구조를 만들어 사람들이 스스로 판단하고, 조직이 스스로 성장할 수 있게 하는 것.

그것이 아키텍트가 필요한 이유입니다.

공학자로서 바라보는 SW 아키텍트

공학자의 시각에서 소프트웨어 아키텍트를 바라보면, 핵심은 구조적 사고와 재현 가능한 기준 설정이라고 생각합니다.

SW 아키텍트는 단순히 코드나 시스템을 다루는 사람이 아닙니다.
아키텍트는 다음과 같은 책임을 집니다:

• 복잡도를 통제할 수 있는 구조를 설계하는 것
• 요구사항을 구조적 문제로 변환하는 것
• 시스템의 생애주기를 고려해 의사결정을 내리는 것
• 기술적 선택의 이유와 한계를 설명할 수 있는 것

공학자의 기준에서는, 결과물이 아니라 구조와 기준이 먼저 존재해야 합니다.
구조와 기준이 결과물을 지속 가능하게 만듭니다.

따라서 SW 아키텍트는

“빠르게 만들 수 있는가”보다
“빠르게 만들어도 무너지지 않는 구조를 설계할 수 있는가”
를 고민해야 합니다.

아키텍트 업무의 시대적 변화

과거에는 코드 작성 자체에 많은 시간이 소요되었습니다.

컴파일러와 개발 도구가 지금처럼 발달하지 않았고, 테스트 환경과 배포 자동화 역시 충분히 갖춰지지 않았습니다.

그 결과, 아키텍트는

• UML을 통한 시스템 모델링,
• Pseudocode를 이용한 알고리즘 설계,
• 상세하고 정교한 문서화
  에 집중해야 했습니다.

코드 생산이 고비용·고위험이었기 때문에, 구조를 사전에 치밀하게 설계하는 것이 핵심 업무였습니다.

하지만 지금은 상황이 많이 달라졌습니다.

• 개발 도구와 프레임워크의 고도화,
• 오픈소스 생태계의 확장,
• DevOps 기반의 자동화된 배포 환경,
  이 모든 것이 코드 작성과 검증 속도를 극적으로 높였습니다.

이제 아키텍트는

• 완벽한 사전 설계보다,
• 변화와 확장에 견딜 수 있는 유연한 구조를 설계하는 것
  에 더 집중해야 합니다.

빠르게 변화하는 기술 환경 속에서
완성된 설계가 아니라,
변화에 강한 구조를 만드는 것이 현대 아키텍트의 과제입니다.

설계 공급 부족과 자동화의 등장

빠르게 변화하는 개발 환경 속에서, 모든 프로젝트에 충분한 구조 설계와 아키텍트가 투입되는 것은 어려웠습니다.

설계의 공급은 개발 속도와 요구사항 증가를 따라가지 못했습니다.

그 결과,

• 복잡도를 수작업으로 통제하는 대신 운영과 배포를 자동화(DevOps) 하고,
• 기능을 직접 개발하는 대신 서비스(SaaS) 형태로 소비하는 흐름이 강화되었습니다.

DevOps는

인프라와 배포의 복잡도를 자동화하여,
설계의 부재를 운영 자동화로 보완하려는 시도였습니다.

SaaS는

개별 기능을 추상화하고,
빠르게 통합할 수 있도록 한 결과물이었습니다.

이러한 변화는,
구조를 섬세하게 설계하는 대신
빠른 조합과 연동을 통해 빠르게 결과를 만들어내는 개발 환경을 만들어냈습니다.

지금의 개발 문화는,
정교한 구조 설계보다
변화에 대응하는 조합 능력을 더 중요하게 요구하고 있습니다.

아키텍트에게 요구되는 새로운 역할

아키텍트는 단순히 과거의 방식을 답습해서는 안 됩니다.

지금의 환경에서는

• DevOps를 통한 자동화,
• SaaS를 통한 기능 추상화,
  이런 흐름을 단순히 따라가는 것이 아니라, 구조적으로 이해하고 조합하는 능력이 요구됩니다.

즉, 어떻게 자동화와 SaaS를 활용하여, 조직에 맞는 효율적이고 유지 가능한 개발 구조를 만들 것인가를 설계하고 제안할 수 있어야 합니다.

아키텍트는

• 흐름에 휩쓸리는 것이 아니라,
• 흐름을 구조적으로 해석하고,
• 조직의 리듬에 맞는 현실적인 대안을 만들어야 합니다.

저는, 조직이 변화 속에서도 흔들리지 않고 성장할 수 있는 기반을 설계하는 것 그것이 지금 아키텍트에게 주어진 새로운 역할이라고 생각합니다.

그리고 저는, 그 목표를 달성하기 위해 고민하고, 실행하려 합니다.

앞으로 만들고 싶은 구조

빠르게 흩어지는 실행을 방향성과 문맥으로 잇는 구조를 만들고 싶습니다.

조직이 일회성 결과에 머무르는 것이 아니라,

• 실행이 흐름을 만들고,
• 흐름이 다시 구조를 만들고,
• 구조가 조직 전체의 판단과 실행을 뒷받침할 수 있도록.

구체적으로는,

• 변화에 강하고,
• 확장이 가능하며,
• 사람들이 스스로 이해하고 유지할 수 있는
  살아있는 구조를 만들고자 합니다.

기술만을 위한 구조가 아니라, 사람과 실행을 연결하는 구조.

그것이 앞으로 제가 만들어가고 싶은 방향입니다.

맺으며 — 정의를 만들어가는 과정

저는 아직 완성된 정의를 가진 것은 아닙니다.

아키텍트라는 단어를 누구나 공감할 수 있는 하나의 형태로 설명할 수는 없습니다.

하지만 분명한 것은, 저는 스스로 아키텍트의 의미를 만들어가고 있다는 점입니다.

• 구조적 사고를 반복하고,
• 변화하는 흐름 속에서 구조를 해석하고,
• 조직에 맞는 현실적인 대안을 찾아내려는 시도.

이 글은, 그 과정을 기록한 첫 번째 시도입니다.

앞으로도 고민하고, 부딪히고, 수정해가며 저만의 아키텍트 정의를 완성해가려고 합니다.