본문 바로가기

growth/dev

난 소프트웨어 아키텍트가 될 수 있을까?

반응형

아키텍처 강의를 들었다

지난 3일간 교육을 들었다. 소프트웨어 아키텍처 강의다. 회사에서 새로운 업무를 맡기에 앞서 준비하는 과정이 필요했다. 이번 교육도 그 과정 중 하나다. 한 대학교에서 교수로 재직하고 계신 분이 강사로 오셨다. 소프트웨어 공학을 전공하신 이 분은, 교수지만 창업도 준비하고 있고, 강의 시작 직전에도 코딩을 하다 오셨다고 소개했다. 요즘 개발하는 것이 하나 있는데, 거기에도 교육에서 다룰 아키텍처 내용을 적용하고 있다고 했다. 학교에서 소프트웨어 공학을 배울 때도, 이 많은 것들을 하면 좋기는 한데 과연 실무에 적용할 수 있을까 걱정했다. 하지만, 실제로 하고 계신다고 하니 대단하다 싶었다.

 

사전 설문조사에서 작성한 내용으로 몇몇 수강생들을 인터뷰했다. 모두 소프트웨어 개발을 하는 사람들이지만, 개발을 하게 된 배경과 전공은 다양했다. 특히 눈에 띄는 전공은 철학과 유아교육과였다. 전공이 적성에 맞지 않아 개발을 시작하게 되었다고 한다. 그리고 지금은 일이 재미있느냐는 질문에 그렇다고 답했다. 나는 어쩌다 소프트웨어 개발을 하게 되었을까 생각해보게 되었다. 중학교 다니는 내내 딱히 무슨 일을 하고 싶다는 건 없었고, 당장 눈앞의 공부만 했을 뿐이다. 학교를 졸업할 무렵 회계사가 되고 싶다는 생각을 했고 특성화 고등학교를 갈까 하고 견학도 했지만, 대학부터 가고 생각하라는 주변의 만류에 인문계고를 가게 되었다.

 

Software Architecture Design (PxHere 공개 이미지)

 

어쩌다 소프트웨어 개발을

고등학교 1학년을 마칠 무렵, 문과와 이과를 선택하는 기로에서 나는 회계사라는 꿈을 가지고 문과를 선택했다. 숫자에 능숙해야 할 것 같은 느낌과는 달리 회계학과는 경상계열이었다. 3년간 국영수와 사회탐구 과목을 공부했지만, 나는 결국 수능을 잘 보지 못했다. 수시 모집으로 지원했던 학교들은 최저학력기준이라는 이름과 달리 높은 기준을 요구하는 수능 점수를 맞추지 못해 모두 탈락하고, 정시 모집에서는 세 군데를 전략적으로 지원했어야 했다. 모험을 하는 곳, 아슬아슬한 곳, 안전한 곳. 컴퓨터학부는 안전한 곳에 속했다.

 

결과적으로 나는 컴퓨터학부를 가게 되었고, 다른 곳은 모두 떨어졌다. 나에게 소프트웨어 개발은 모든 도전에서 실패한 뒤 강제된 선택이었다. 재수를 고민했지만, 일단 학교를 다녀보기로 했다. 혼자서 독학해서 이런저런 프로그램을 만들어 보기도 했지만, 학문으로서 배우는 것은 처음이었기 때문이다. 다행히 학문은 생각보다 재미있었고, 결과도 좋았다. 그렇게 전산학에 발을 붙이게 되었다. 3학년이 되었을 때 소프트웨어 공학이란 강의를 들었고, 개발하고자 하는 사람과 개발하는 사람 사이의 커뮤니케이터로서 일을 하고 싶다는 생각이 스쳤다. 하지만, 그 생각은 학기말 시험을 지나 방학이 되면서 사라졌다.

 

Communication Meeting (PxHere 공개 이미지)

 

아키텍트는 무엇을 하나

사실 이번 교육 기간 동안 다루는 내용은 학교에서 배웠던 것들이다. 학교에서는 한 학기 동안 다룰 내용을 단 몇 시간 내에 전달하고자 하니, 그리 깊고 많은 내용을 다루기는 어렵다. 그래서인지 다 들어본 것들이었다. 다만 다른 점이라면, 일을 하는 입장으로서 소프트웨어 공학을 어떻게 실제 업무에 적용할 수 있을지. 단순히 학문적인 관점이 아닌, 실용적인 관점에서 SE를 적용하는 이야기를 들을 수 있다는 점이다. 그래서인지 지금껏 들었던 교육 중에 가장 재미있고 와닿는 교육이었다. 첫 내용은 Software Development Life Cycle. 10년 전 학교에서 들었던 소프트웨어 공학 강의가 생각났다. 그리고 내가 생각했던 그 일이 생각났다. 커뮤니케이터.

 

일을 제대로 하는 것을 좋아했다. 애매하게 해서 애매한 결과를 얻는 것보다는, 조금 돌아가더라도 제대로 해서 제대로 된 결과를 얻고 싶었다. 소프트웨어 공학은 그런 일을 한다. 일을 맡기는 사람은 사실 자신이 무엇을 원하는지 정확히 모른다. 대략적인 그림만 가지고 있을 뿐이다. 그런 사람의 요구를 받아서 일을 맡은 사람은, 무엇을 만들어야 할지 정확히 모른다. 무언가를 만들기에는 애매한 말들만 들었기 때문이다. 아키텍트는 그 중간에서 애매함을 명확함으로 만드는 역할이다. 관련된 사람들의 요구사항을 수집하고 분석해서 정확한 설계도를 만들어낸다.

 

이젠 제대로 할 시간

회사에서 만 4년을 보내면서 이것을 잊고 살았다. 매번 제대로 정리된 요구사항 없이 항상 대략 적으로 이해하고, 대략적으로 개발하고, 대략적으로 검증했다. 그런데 최근 일이 생겼다. 회사 차원에서도 소프트웨어 설계에 대한 중요성을 인식하고, 아키텍처를 제대로 설계해 품질 좋은 소프트웨어를 만들기 원하는 것 같다. 아키텍트를 키우기 위한 회사 차원의 교육도 준비 중이라고 한다. 다음 달부터 새로 들어가는 프로젝트를 위해서도 소프트웨어 설계가 필요한 상황이다. 그래서 이번에 급하게 알아봐서 이번 교육을 듣게 된 것이다. 그리고 내가 잊고 있었던 커뮤니케이터, 아키텍트로서의 꿈이 생각났다.

 

이번 교육을 통해, 프로세스 모델, 도메인 모델링부터 요구 공학, 유스 케이스 등 각종 다이어그램을 다시 리마인드하고 실습도 했다. 실습 중에 팀원들과 다이어그램을 그리고 짧은 토론하는 게 꽤나 재밌었다. 정확한 요구 사항이 무엇인지 분석하고, 더 좋은 설계는 없는지 얘기하는 게 참 오랜만이었다. 교육 기간에 비해서 다룰 내용이 너무 많아서 많은 실습을 하지는 못 했지만, 그래도 오랜만에 올바른 방법이 무엇인지 다시 그 감각을 되찾는 데는 충분했다. 다음 주 회사에 돌아가서 틈이 나면, 대략적으로라도 미리 구조를 잡는 연습을 해봐야겠다.

 

난 아키텍트가 될 수 있을까?

'growth > dev' 카테고리의 다른 글

갑자기, 나만의 업무 트래커 개발하기 (1)  (0) 2022.06.20
클로링
클로링 씀.