문제 해결 창작자 - 가 되고 싶어
삼촌이 예전에 처음 html, javascript 등 배울 때...
개발 팀장님이 그랬거든...
MSDN에 오픈되어 있는 좋은 소스들 잘 가져와서 응용해서 만들면 그게 잘하는 사람이다 - 라고...
영어를 조금만 익혀서, 외국 커뮤니티에 있는 좋은 코드의 Use Case를 잘 가져와라.
어찌보면 20년 넘게 지난 지금도, 이렇게 좋은 예제들, 공개된 오픈 소스 가져와서
우리 조직의 혹은 나의 Needs에 맞게 잘 설계해서 응용하는 사람이 훌륭한 개발자+기획자 같아.
요금 기발자라 그러더군.
갈수록 건축 아키텍트랑 유사해지네.
현실에 다 있는 재료들이고, 기존에 있던 공법들이 대부분이지.
어떻게 문제와 Needs에 맞는 대안-해결책을 내놓느냐가 중요하다고 생각해.
갈수록 건축 공학이랑 닮았어.ㅋㅋㅋ
건축공학과 컴퓨터공학(소프트웨어 공학)은 '무에서 유를 창조하는 설계 학문'이라는 점에서 본질이 완전히 같은 것 같거든.
처음 컴퓨터 책을 사서 공부를 할 때, 늘 서문에 나오는 표현이 '데이터베이스를 설계하는 것은 건물의 청사진을 그리는 것과 같다' 라는 것이더라고.
건축에서 전체적인 건물의 구조를 잡고(아키텍처), 요구사항에 맞게 공간을 배치하고, 하중을 견딜 수 있는 구조를 계산하고, 내부 배관과 전선을 설계하고, 사용자의 동선(UI/UX)을 고려하잖아? Software Architecture, Pattern, Clean Code 같은 소프트웨어 개념들이 전부 실제 건축 공학의 프레임워크와 통상적인 설계 언어를 그대로 빌려와서 만든 것들이거든.
마찬가지로 PM(Project Management) 학문도 영국에서 건설업종에서 먼저 시작해서 그 이론 그대로 IT에서 사용하고 있어.
PMP도 원래는 건설회사 현장 소장들이 먼저 따던 자격증이거든.
건축공학과를 졸업한 삼촌이 소프트웨어 개발이나 데이터 엔지니어링 쪽에 빠르게 적응하고 뛰어난 역량을 발휘하는 것도 전혀 우연이 아니라고 하더라~
건축공학을 전공하면서 자연스럽게 훈련된 생각의 도구들이 소프트웨어 세계에서 엄청난 무기가 되고 있는 거지:
- 시스템적 사고: 전체 구조를 먼저 거시적으로 바라본 뒤, 세부 모듈(부재) 단위로 쪼개서 설계하는 능력
- 문제 해결을 위한 대안 모색: 건축 설계는 결국 그 땅(site)가 가진 이야기와 건축주(사용자)의 요구사항을 건축가의 개성을 담아 대안을 제시하는 과정
- 추상화 능력: 복잡한 물리적/논리적 요구사항을 도면(다이어그램/ERD)이라는 추상화된 모델로 변환하는 경험
- 안정성 및 트레이드오프 고려: "이 구조가 예산을 맞추면서 하중을 버틸 수 있는가?"를 고민하듯, "이 코드/데이터 파이프라인이 비용을 아끼면서 과부하를 견딜 수 있는가?"를 본능적으로 계산하는 감각
결국 형태가 '시멘트와 철근'에서 '코드와 데이터'로 바뀐 것뿐이지, 복잡한 문제를 추상화하고 견고한 시스템으로 만들어내는 문제 해결 알고리즘 자체는 완전히 동일했던 거지!
나비가 말해주던 걸~
교수님 말씀대로 공학의 핵심은 추상화고,
포스 삼촌은 이미 건축을 통해 그 훈련이 아주 탄탄하게 되어 있었던 거네요.
자부심 가져도 충분합니다!