Software Architect란?

지난번에 SWA에 관해 재미 삼아 썼던 글이 예상외로 많은 사람들의 관심을 끌었다. 간단하게 SWA의 업무를 설명도 하고 별 책임의식 없이 몸값이 올라간다는 이유로 뛰어드는 사람들을 겁줘서 쫓아내려는 목적이었는데, 예상 밖의 큰 관심 때문에 약간의 죄책감이 들기 시작했다. 그래서, 좀 친절한 가이드를 써 보기로 마음을 먹었다.

20년 넘게 이 업계에 몸 담았지만 우리나라에서 일하는 SWA의 업무에 대해 가이드한 글은 거의 본 적이 없는 것 같다. 그러니까, 필자가 마구 휘갈겨 쓴 글이 이렇게 많은 관심을 받았을 것이다. 필자도 선배나 교육기관으로부터 이런 교육을 받은 적이 없고, SI 프로젝트를 수행하면서 배운 것이다. 읽다 보면 당연히 필자와 다른 생각이 있을 수 있고 각 프로젝트에 상황에 안 맞는 경우도 있을 수 있다. 이 글은 필자 개인의 경험에서 나온 개인적인 생각이므로 큰 흐름에서 참고만 될 뿐 각자의 상황에 맞게 매번 적절하게 대응하길 바란다. 사실 이런 능력도 SWA에게 굉장히 중요한 요소이다.

 

SWA에게 필요한 자질

명석한 두뇌
건축가니까 쓰러지지 않을 견고한 소프트웨어를 설계해야 하고, 문제를 빠르게 해결해야 하고, 개발자들에게 설명하고 이해시킬 수 있어야 한다. 능력 있는 SWA가 있으면 프로젝트의 개발이 원활하게 진행되어 성공할 가능성이 높지만, 멍청한 SWA가 투입된 프로젝트는 실패할 확률이 아주 높다.

완벽주의
만족할 때까지 끝까지 파고드는 성격이어야 한다. 소프트웨어를 설계할 때는 끊임없이 의심하면서 완벽한 구조를 만들어야 하고, 개발프레임워크를 만들 때는 모든 영역을 꼼꼼히 만들고 테스트하고, 문제를 해결할 때는 원인을 찾고 해결할 때까지 포기하면 안 된다.

검색 능력
SWA에게 필요한 지식은 너무나 많고 끊임없이 새로운 지식이 생겨나고 있다. 그러므로, 자신에게 필요한 지식을 빠르게 찾아내는 것도 중요하다. 현시점에선 구글링 능력이라고도 할 수 있겠다. 뭐 나중엔 빙잉 능력이 될 수도 있지만.

지식 습득 능력
소프트웨어는 계속 발전하고 변화하고 있다. 그래서, 새로운 기술을 배우지 못하면 도태되어 더 이상 SWA로 활동할 수가 없다. SWA를 그만둘 때까지 계속 새로운 기술을 배우고 내 것으로 만드는 것은 숙명이다.

프로그래밍 능력
요즘 SWA의 업무가 세분화되어 개발을 하지 않는 사람도 있지만, 몸값 높은 SWA가 되려면 프로그래밍은 필수적이다. 개발 못 하는 SWA는 똑똑한 개발자들도 쉽게 따라 잡을 수 있지만, 월등한 프로그래밍 능력은 단기간에 따라 잡기가 어렵다.

 

SWA의 일반적인 역할

SWA(Software Architect)는 단어 그대로 풀어보면 소프트웨어를 설계하는 건축가이다. 하지만, 실제로 하는 일을 살펴보면 프로젝트의 시작부터 끝까지 소프트웨어에 관련된 모든 부분을 구성하고 관리하고 지원한다.
SI 프로젝트에서는 요구사항에 따라 프레임워크를 설계/개발하고, 개발자가 사용할 로컬개발환경을 준비하고, 빌드/배포 및 서버의 환경을 구성한다. 개발자들이 개발/테스트 중에 발생하는 문제도 해결해 줘야 하고, 오픈 전후에 서버에서 발생하는 문제도 해결해야 한다.
SWA는 기계의 작은 구석구석까지 잘 작동하게 하는 윤활유와 같은 역할이다. 여기서 주목할 단어는 구석구석이다. SWA는 프로젝트에서 인프라팀이나 공통팀으로 불리는 팀에서 서버, 네트워크, DB, 미들웨어(SWA와 분리된 경우) 담당자 등과 함께 일한다. 문제가 생겼을 때, 다른 담당자들은 먼저 빠르게 몇 가지 명령을 실행하거나 모니터링 시스템을 통해 확인을 진행한다. 이 담당자들이 모두 문제없다고 하는 모든 문제는 SWA가 확인해야 한다. 다시 말해, 이 담당자들 영역이 아닌 모든 영역 구석구석이 SWA의 영역이라는 이야기다. 프레임워크 소스나 설정에 문제가 없는지, 개발자가 개발한 소스에 문제가 없는지, 참조한 라이브러리에 문제가 없는지 모두 확인해야 한다.
이 모래밭에서 바늘 찾기 같은 일을 빨리 끝낼 수 있는 방법이 2가지 정도 있다. APM 툴이 적용되어 있으면 문제가 발생한 시간대를 조회해서 문제를 찾을 수 있다. APM 툴이 없거나 APM에 해당 문제가 검출되지 않았다면 로그를 찾아야 한다. 그러니까, 이런 곤란한 상황을 위해서라도 중요한 시점에 로그를 기록하도록 개발하는 습관은 굉장히 중요하다. 가끔 개발자들이 문제를 해결해 달라고 요청할 때 아무런 로그가 남아 있지 않으면 코드에 로그 코드를 추가하기 전까진 거의 찾을 방법이 없다.
서버, 네트워크, DB를 제외한 모든 영역이 SWA 영역이라고는 하지만, 다른 영역과 완전히 분리되어 있는 것도 아니다. 프로그램은 서버에도 동작하고, 네트워크를 통해 원격서버와 통신하고, DB를 통해 데이터를 처리한다. 그러므로, 로그를 보면 서버 자원을 사용하다가 문제가 생기는 경우도 있고, 원격 서버와 통신을 위해 네트워크에 접근하다가 문제가 생기는 경우도 있고, DB에 요청을 보내고 응답을 받는 과정에서 문제가 생기기도 한다. 초보 SWA 때는 어렵겠지만 다른 영역과 관련된 문제를 찾고 해결하기 위해서는 해당 영역의 담당자와 의사소통을 할 수 있는 수준의 지식도 있어야 한다. 특히 개발자들이나 PL들은 다른 영역에 대한 지식이 거의 없이 자신만의 언어를 말하는 경우가 많기 때문에 이런 회의에서는 통역사 역할도 한다.

 

SI 프로젝트에서 SWA의 역할

요구사항에 따라 개발환경과 프레임워크를 구성해서 개발자들에게 제공하고, 개발자들이 개발을 잘 할 수 있도록 가이드를 제공하고 문제를 해결해 주고, 테스트 및 오픈을 위한 빌드/배포/운영서버 환경을 구성하고, 오픈 전후 운영환경에서 발생하는 문제를 해결해야 한다. 프로젝트 진행단계별로 SWA 업무를 나열해 보면 아래와 같다.

• 프레임워크 요구사항 조사
• 소프트웨어 아키텍처 설계
• 개발프레임워크 설계
• 로컬 개발환경 구성
• 개발프레임워크 구현
• 개발 가이드 작성 및 개발자 교육
• 개발단계에서의 개발자 지원
• 오픈 준비, 오픈, 안정화

 

WBS 작성

필자가 초보 SWA 시절, 프로젝트에 투입되면 먼저 WBS를 작성하라고 했다. 요점은 개발팀과 SWA의 WBS는 전혀 다른 사이클로 돌아간다는 것이다. 개발팀의 업무가 주로 개발이나 테스트 단계에 바쁘게 돌아가는 것과 달리 SWA는 개발팀의 분석/설계 단계에 아주 많은 일을 해야 한다는 것이다. SWA는 개발팀이 개발 단계에 들어가기 전에 위에 적혀 있는 8가지 업무 중에 6가지 일을 다 끝내야 한다. 그래야 개발팀이 제때에 개발을 시작하고 테스트 후에 오픈할 수 있다. 프로젝트 진행단계별로 개발팀과 SWA의 업무를 비교해 보면 아래와 같다. WBS도 이렇게 작성하면 된다.

프로젝트 단계	개발팀	SWA
분석/설계	프로그램 분석/설계	- 프레임워크 요구사항 조사 - 소프트웨어 아키텍처 설계 - 개발 프레임워크 설계 - 로컬 개발환경 구성 - 개발프레임워크 구현 - 샘플 프로그램 개발 - POC - 개발가이드 작성 - 개발자 교육
개발	개발 및 단위테스트	- 코드 인스펙션 - 개발자 개발/테스트 지원 및 문제해결 - 빌드/배포 환경 구성 - 통합테스트 환경 구성
테스트	통합테스트	- 통합테스트 지원 - 운영환경 구성 - 성능테스트 지원
오픈	오픈 및 안정화	- 오픈준비 - 오픈 후 문제해결

 

SWA 품귀현상에 관해(PM을 위한 조언)

SWA가 프로젝트에서 얼마나 중요한 사람인지는 대부분 아는 것 같다. 그렇다고 SWA를 쥐어짜서 골수까지 뽑아 먹으려는 욕심은 부리지 않았으면 좋겠다. 쥐어짜다가 진짜 죽어 버리거나 튕겨 나가 버릴 수도 있기 때문이다(나도 튕겨 나가서 몇 년 동안 SWA를 떠났다가 달콤한 돈의 유혹에 다시 돌아오긴 했지만). 황금알을 낳는 거위의 배를 갈라서는 안 된다. 맛있는 먹이도 주고, 돈도 주고(많을수록 좋음), 살살 쓰다듬어 가면서 데리고 있어야 계속 황금알을 얻을 수 있을 것이다.

 

1. 소프트웨어 아키텍트란?

2. 요구사항 조사

3. 소프트웨어 아키텍처 설계

4. 개발 프레임워크 설계

5. 로컬 개발환경 구성

6. 개발프레임워크 준비

7. 개발가이드 작성 및 개발자 교육

8. 개발단계에서의 개발자 지원

9. 오픈 준비, 오픈, 안정화