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