IT리뷰

소프트웨어 아키텍처101(2022.02.08)

jb213 2022. 6. 26. 23:36

https://www.hanbit.co.kr/store/books/look.php?p_code=B1494466807

SA. 소프트웨어 아키텍처. 말로는 많이 들어봤는데 사실 뭘 하는 것인지는 잘 모르고 있었다.

그저.. 막연하게 일반 개발 이외에 존재하는 포지션 정도로(정확히는 소프트웨어 아키텍트겟지만) 이해했다.

 

'소프트웨어 아키텍처'를 검색하고 이런저런 포스팅을 보면서 느끼고 다시 생각해본 게 있다.

기본적으로 IT산업이라는 게 어떤 product, 결과물을 기준으로 돌아가는 곳이라는 거다. 그렇기 때문에 그 product를 잘 만드는 것이 1차적 관심요소가 된다. 여기에는 product가 '잘' 만들어졌는지 평가하는 score 또한 함께 고려될 거다. 즉 내적인 완성도와 별개로 외적인 완성도가 일단 우선이 되고 그게 성공하면 내적인 완성도를 손봐야 하는 때가 온다. 그런데 만약 내적인 완성도를 손봐야 하는데 맨 처음 선택한 여러 소프트웨어 방법들이 고치기 어렵거나 레거시가 엄청나다면..? 그리고 제한된 시간 안에 내적인 완성도를 높여야 하는데 그게 차질이 조금 크게 난다면..? 이를 방지하기 위해서는 SA가 product를 만드는 맥락 속에 포함되어 가장 '합리적'이라고 생각되는 방법을 조율할 필요가 있다(라고 이해했다).

 

서론부터 굉장히 거대하고 복잡한 내용처럼 보이지만 이런 애매모호한 내용을 생각해줄 포지션과 담당영역이 필요했기 때문에 비교적 높은 관심과 보수를 받는 것이 아닐까. 

 

책에서 말하는 SA의 핵심적 요구사항 8가지는 아래와 같다.

그리고 책에서는 이 8가지에 대해서 각 챕터별로 설명하고 있다.

 

- 아키텍처 결정을 내린다.

어떤 기술을 선택할지 가이드를 내려준다. 결정하는 사람이 아니다.

 

- 아키텍처를 지속적으로 분석한다.

아키텍처와 현재 기술 환경을 분석하고 개선하기 위해 해결 방안을 제시한다. 대부분의 아키텍처 구조는 쇠락하기 때문에 설계를 변경하게 된다. 

 

- 최신 트렌드를 계속 유지한다.

최신 기술과 업계 트렌드를 따라가야 된다. 이것과 관련해서 24장을 주의깊게 읽어봤는데(왜냐면 이쪽은 특히 중요한 분야라고 해서 뭐가 다른가 궁금해서) '20분 규칙'이 있다고 한다. 

20분 정도 모르는 전문용어를 배우고 '모른다는 사실을 알고있는 것들'로 표시한다. 그런데 시간이 중요하다. 저녁이 아니라 아침 출근 후 커피 마신 뒤(여기까지 용납) 이메일 확인 전 20분에 하라고 한다. SA 대가가 알려주는 비법이니 비교적 확실한 트렌드 습득 방법이겠다. 생각해보니 아침에 정보성 메일을 읽을 때나 들을 때가 가장 기억력이 높았다. 10분도 아닌 20분이면 출근시간에 한번 해볼만하지 않나 생각한다.

 

- 아키텍처 결정의 컴플라이언스를 보장한다.

 

 

- 다양한 기술과 경험에 노출된다.

기술의 깊이보다는 폭에 초점을 두라. 테크 제너럴리스트의 관점을 갖는 것도 좋겠다. 

 

- 비즈니스 도메인 지식을 보유한다.

'IT회사에 간 문과 여자' 라는 책에서도 비슷한 얘기를 마지막 부분에서 본 적이 있다. 회계나 감사에 대한 지식이 있다면 IT쪽이라도 도움이 많이 된다라는 얘기였다. 일정 부분 동의하는 바다. 결국 이 부분이 말하는 건 IT서비스업계가 만드는 건 product이기 때문이 아닐까. 어떤 것을 '만드는' 게 코딩한다라는 동사와 유사하게 엮을 수 있다고 본다. 예전에는 일정 부분은 '쓴다'와 동의어라고 생각한 적이 있다. 그리고 1개의 언어로 쓰인 코드를 다른 언어로 바꾸면서 작성할 때는 '코드 통역'을 한다면 이런 걸까 라는 생각을 한 적도 있다. 하지만 결국은 '쓴다' 보다는 '만든다'에 더 가깝다고 생각하는 편이다. 그 이유는 작가가 글을 쓰면 독자는 쓴 글을 보지만 코드는 개발자가 쓰면 소비자는 그 코드를 보는 것이 아니라 그 코드가 만든 product를 보기 때문이다. 

 

- 대인 관계 기술이 뛰어나다.

이런 소프트웨어 스킬은 앞으로 점점 더 중요해질 것이다.

 

- 정치를 이해하고 처세를 잘한다.

어느 정도는 협상하는 것이 필요하다고 생각한다. 가끔은 SA는 결과적으로 이득이 될 결정을 반발에도 '무릅쓰고' 해야 할 필요도 있다. 이때 이 반발의 강도를 조금씩 줄일 수 있는 방법이 협상이다. 

 

 

SA를 찾으면서 참고했던 블로그도 같이 링크해본다.

https://wnsgml972.github.io/platform/2021/03/06/importance-software-architecture/

 

 

 

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.