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

개발자에게 교육을 했다고 곧바로 개발자가 개발을 원활히 할 수 있는 것은 아니다. 이번 프로젝트에서 사용하는 기술을 모두 사용해 봤고 능숙하게 다룰 수 있는 개발자라면 빠르게 적응할 수 있지만, 이렇게 준비된 개발자는 일부이거나 많아도 절반 정도일 것이다. 준비된 개발자가 많은 상태에서 개발을 시작하려면 개발자를 뽑을 때 준비된 사람만 뽑던가, 현재 SI판에서 보편적으로 사용하는 기술로 개발 프레임워크를 구성하면 된다. 그래서, 나는 최신기술보다는 비교적 신기술이긴 한데 보편적으로 많이 사용하는 기술을 사용하려고 노력하는 편이다. 그래야 개발자들의 개발환경에 대한 러닝커브가 짧아진다.

코드 인스펙션

결국 최고의 개발속도(개발생산성)를 얻으려면 개발자가 빨리 적응하도록 SWA가 열심히 지원해야 한다. 이를 위해 개발초기에 몇 가지 할 일이 있다. 일단 개발자들과 가까이 있으면서 개발하다가 질문이 있거나 잘 안 되는 부분이 있으면 바로 가서 지원해서 적응시간을 줄여 준다. 이렇게 해서 1주일 정도 개발을 하고 나면 개발한 소스를 모두 형상관리에 commit하도록 한 후에, SWA가 이 코드에 대해 코드인스펙션을 실시한다. 그래서, 개발표준에 잘 맞는지, SWA가 개발 프레임워크를 만들 때 의도한대로 적절한 레이어에 프로그램의 기능을 잘 분리해서 넣었는지 확인하다. 그 후에 코드인스펙션에 대한 결과를 회의실에서 개발자들과 공유하면서 각 개발자가 다른 개발자들의 실수를 보면서 나중에 실수할 가능성을 줄여 주는 것이다. 이후에도 가끔씩 SWA가 개발자들의 소스를 보면서 새로운 실수 패턴이 있다면 회의실에서 공유하거나 개발자 게시판에 올려서 새로운 실수가 반복되지 않도록 해야 한다. 무슨 실수든 처음에 고치는 건 간단하지만, 어느 정도 시간이 지난 후엔 너무나 많은 코드에 실수가 반복되면서 고치기가 점점 어려줘지고 시간도 오래 걸린다. 이러한 과정이 몇 번 반복되면 SWA가 직접 코드에 신경 쓸 일은 거의 없어지고, 각 개발 파트나 팀원끼리 모여서 Peer Review 시간을 가지면서 문제를 해결할 수 있는 분위기가 형성된다.

정적분석

코드 인스펙션을 시작한 후에는 SonarQube 등의 툴로 지속적으로 인스펙션을 수행하는 것이 좋다. 그래야 코드 품질을 유지하면서 위험한 코드를 방지할 수 있다. 여기서 또 능력있는 SWA가 필요하다. 이런 코드 인스펙션 툴들은 코드에서 체크해야 하는 룰을 선택해서 인스펙션을 수행하는데, 현재 프로젝트 환경에서 꼭 필요한 룰을 잘 고르면 그 결과도 신뢰할 수 있고 코드 결과물도 훌륭하다. 하지만, 굳이 필요하지 않은 룰을 많이 포함시켜서 인스펙션을 수행하면 개발자들이 스트레스만 받고 코드 결과물도 그다지 좋지 않을 수 있다. 그러므로, 코드 인스펙션 룰을 고를 때는 하나씩 내용을 충분히 살펴 보고 꼭 필요한 것만 골라야 한다.

공통모듈 개발

개발자들이 개발을 시작한 후에도 SWA가 개발할 것이 있다. 바로 공통모듈이다. 이것은 SWA가 개발할 수도 있고, 공통모듈을 전담하는 개발자가 개발할 수도 있는데, 중요한 것은 개발 프레임워크 못지 않게 공통모듈도 개발실력이 뛰어난 사람이 개발해야 한다는 것이다. 개발 프레임워크만큼은 아니지만 공통모듈도 아주 빈번하게 호출되기 때문에 잘못된 코드가 아주 큰 영향을 미칠 수 있다. 공통모듈은 기능별로 사용가이드 문서를 만들거나, 사용자 게시판에 게시물을 올려 개발자들이 쉽게 가이드를 보면서 사용할 수 있도록 한다.

인터페이스 모듈 개발

기본적인 공통모듈 외에도 각종 시스템과의 인터페이스 모듈 개발도 SWA가 담당한다. 솔루션의 호출이라면 대개 솔루션에서 제공하는 API를 이용해서 호출하지만, 이 또한 SWA가 호출방식이나 문제발생 가능성에 대비해 적당한 방법으로 개발프레임워크에 포함시키거나 공통모듈을 만들어야 한다. 이를 이용해 실제로 테스트를 해 보고 문제가 없는지 확인한 후에 개발자에게 사용가이드를 배포한다. 테스트에 간단한 성능테스트도 포함해야 하고, 시스템 오픈하기 전에 실시하는 성능테스트에 포함시키는 것이 좋다.
솔루션 외에 표준방식(웹서비스 등)으로 통신하는 외부 시스템과의 인터페이스에 대해서도 모듈을 만들고 테스트를 한 후에 배포해야 한다. 새로운 인터페이스에 대한 개발을 할 경우, 가끔씩 이클립스 등의 개발툴의 다른 기능을 이용할 수도 있고, 새로운 플러그인을 설치해서 이용해야 할 수도 있다. 이런 경우에는 다른 기능을 이용하거나 플러그인을 설치해서 그 기능을 이용하는 과정을 한 화면씩 캡쳐해서 어떤 것을 누르고 이 과정이 무엇인지 간단하게 설명하는 문서를 함께 만들어서 배포한다. 과정이 복잡해서 직접 설명이 필요한 경우도 있겠지만, 웬만한 난이도까지는 잘 만들어진 가이드 문서만으로 충분히 따라할 수 있다. 가이드 문서만으로 설명이 된다면 새로운 개발자가 들어오더라도 매번 설명할 필요가 없어서 좋다.

업무 협의

개발을 진행하다 보면 기본적인 개발패턴 외에 다양한 이슈가 발생한다. 위에서 다룬 각종 인터페이스도 있지만, XA를 비롯한 다양한 트랜잭션 처리, 메모리 관리 문제, SSO 등이 있다. 이런 일들 또한 전문적인 지식이 필요하기 때문에 SWA가 해야 하는 일이긴 한데, 단순히 기술만 알고 혼자 해결하는 일들만 있는 것은 아니다. 때로는 다른 시스템의 담당자들과 협의를 해야 할 수도 있고, 누가 해야 하는 일인지 업무분담에 대해 논의해야 할 수도 있다.

개발서버 빌드/배포 구성

어느 정도 개발을 진행하면 소스를 빌드하고 배포한 후에 개발서버에서 테스트를 수행해야 한다. 이때에 필요한 것이 CI(Continuous Integration)툴이다. 보통은 Jenkins를 사용한다. 가장 큰 빌드 단위는 운영 시 하나의 인스턴스에 하나의 웹애플리케이션으로 수행되는 단위로 할 수 있다. 그런데, 이 단위가 너무 크면 여기에 올라가는 하나의 소스에서만 컴파일 에러가 발생해도 그 소스를 포함하는 빌드 단위가 모두 서버에 배포될 수 없는 상황이 발생할 수 있다. 이런 경우를 대비해서 되도록 더 작은 단위로 소스를 빌드해서 그 빌드마다 별도의 인스턴스를 할당해 준다. 그러면, 그 작은 단위에서 빌드에러가 발생할 경우 빨리 개발자를 찾아서 고친 후에 다시 빌드를 수행하고 테스트를 할 수 있다. 여기서 개발빌드/배포 소스범위나 주기는 개발팀의 의견을 반영해서 정하면 된다. 하루에 3번 시간을 정해서 자동으로 배포할 수도 있고, 각 개발팀의 빌드 담당자가 팀별로 정한 시간에 자율적으로 빌드/배포하고 테스트를 수행해도 된다.

 

 

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

2. 요구사항 조사

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

4. 개발 프레임워크 설계

5. 로컬 개발환경 구성

6. 개발프레임워크 준비

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

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

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