[데이터넷] 기업의 다양한 내·외부 환경 요인으로 인해 소프트웨어 개발에 필요한 요건이 점차 중가하고 있다. 그렇기에 지금까지의 정성적인 개발방법이 아닌 정량적이고 체계적이면서 자동화된 개발도구 활용이 요구된다. 최근 생산성 향상을 위한 개발 도구의 핵심에는 오픈소스가 자리 잡고 있는 만큼, 금융IT 분야에서 이들을 어떻게 효과적으로 도입할 수 있을지 알아본다. <편집자>

최근 IT 분야는 지속 통합/배포(CI/CD), 데브옵스(DevOps)가 확대되고, 인프라도 클라우드 환경으로 전환되고 있으므로 선제적 대응이 중요한 시점이다. 이를 위해 고려해야 할 요인은 크게 기술적 요인, 기업 내부 요인 및 외부 요인으로 나눠볼 수 있다.

우선 기술적 요인을 살펴보면 개발 참여 인력의 기술적 사전검증 부족, 조기 품질점검 부재, 점점 복잡해지는 요구 사항으로 인한 수작업 요인 증가, 기술·업무에 대한 고객의 요구 사항 증가 등을 확인할 수 있다.

기업 내부 요인으로는 유지보수 시 사후관리 미흡, 소프트웨어 품질관리 인력 및 솔루션 부재, 소스코드에 대한 상태진단 및 개선사항에 대한 외부 의존도 증가 등을 들 수 있으며, 외부 요인으로는 IT의 급변으로 인한 인력수급 제약, 주 52시간제 도입, 언택트 상황 증가로 소프트웨어 개발에 필요한 요건 증가 등을 꼽을 수 있다.

이처럼 다양한 리스크 요인이 대두되는 상황이기 때문에 지금까지의 정성적인 개발방법이 아닌 정량적이고 체계적인 자동화된 개발도구 적용과 더불어 소프트웨어 개발관리/편의성 증대로 인한 생산성 향상 등이 현재 상황에 필요한 해결책이라 할 수 있다.

최근 금융IT는 물리적인 망분리, 강한 보안규칙 준수, 인터넷 접근금지라는 폐쇄적인 상황에 놓여 있기에 개발생산성을 높이기 위한 도구를 사용하기 어려운 실정이다. 클라우드에 대한 열기가 뜨거움에도 불구하고 금융IT 분야는 SaaS(Software-as-a-Service)로 진행되는 상황에서도 IaaS(Infrastructure-as-a-Service)조차 사용한 인력이 많지 않은 실정이다. 이미 다른 분야에서 사용되는 여러 소프트웨어 개발도구는 금융IT 분야에서 전혀 사용할 수 없는, 마치 ‘그림의 떡’과 같다고 할 수 있다.

특히 소프트웨어 개발과정 전체에 걸쳐서 고객사에 표준화된 개발 환경을 지원받지 못하는 상황이 많이 발생된다. 자체 프로젝트, 중소규모 프로젝트, 비중요 시스템 구축 사업 수주 시 비용 문제로 인한 아키텍트 인력 운용 불가, 외주업체 의존성 상승 및 회사마다 표준화된 지원체계를 갖추지 못했기 때문이다. 또한 프로젝트 진행 시 한정된 자원으로 인해 코드 품질 및 생산성을 위한 자동화 적용이 미흡하기에 단계마다 즉시 사용할 수 있는 표준화되고 자동화된 개발도구의 적용이 품질향상 및 생산성 향상의 중요 포인트라고 할 수 있다.

생산성 향상 위한 개발도구 핵심 ‘오픈소스’
오픈소스는 누구나 이용할 수 있고, 공개된 코드를 기반으로 변경이 가능하다. 또한 많은 개발자들에게 검증된 소스코드를 기반으로 하기에 폐쇄망에서 사용하는 소스보다 안정성과 신뢰도가 높다고 할 수 있다. 리눅스(Linux) 운영체제가 대표적인 오픈소스 사례다. 폐쇄성이라는 특징을 가진 애플조차 크고 작은 다양한 오픈소스 기술에 관여하고 개발해왔다. 금융IT에서도 비용 절감과 새로운 트렌드를 받아들이기 위해 오픈소스 기반의 시스템에 많은 관심을 가지고 있다.

그러나 오픈소스 도입은 다양한 개발언어와 프런트엔드, 백엔드, 인프라적인 아키텍처 등 많은 지식이 필요하다. 국내에는 참고자료가 부족해 많은 개발자들이 구글링에 의존하고 있는 상황이지만, 이러한 허들을 넘기 위해서는 지속적인 관심과 노력과 더불어 오픈소스 기술에 관여하고 개발에 참여해야 추후 필요한 솔루션에 대해 획기적인 비용 절감과 자유로운 변경이 가능할 것이다.

오픈소스 도입해보기
그동안 오프라인 및 폐쇄망 환경에서도 자유롭게 설치, 실행 가능한 검증된 오픈소스 도입이라는 기본 원칙으로 다양한 시도를 해온 만큼, 다방면의 검증을 통해 필요 오픈소스 솔루션을 하나씩 도입하고 통합하는 과정을 소개한다.

오픈소스의 처음 도입은 정보의 축적 및 체계적인 활용, 효율적인 협업 환경 구축을 위한 문서협업도구 적용부터 시작했다. 문서협업도구인 위키(WIKI)의 오픈소스 중 안정성과 확장성이 뛰어난 엑스위키(XWiki)를, 그중 이슈트래커 기반의 프로젝트 관리도구인 레드마인(Redmine)을 선정해 커스터마이징 작업을 시작했으며 위키시스템과 프로젝트 관리 시스템의 편리성을 위해 통합로그인(SSO) 기능도 추가했다. SSO 솔루션은 키클록(KeyCloak) 오픈소스를 활용해 적용했고, 금융보안심의를 마친 솔루션으로 탈바꿈시켜 현재도 무리 없이 운영하고 있다.

오픈소스 커스터마이징 작업에는 공통적인 허들이 존재한다. 한글화 과정과 기존 오픈소스의 수정이다. 국내에서 활성화되지 않는 오픈소스 솔루션은 한글화 작업을 별도로 해야 한다. 직역이 아닌 의역이 많아 많은 시간투자가 필요하다.

또한 오픈소스 그대로 사용할 수 없는 경우가 종종 발생한다. 사내 보안성 심의로 인한 수정사항 및 규정에 맞춰야 하는 제한사항 등을 고려하지 않을 수 없는 것이다. 전체 소스코드를 파악하고 필요한 부분에 대한 부분수정을 한 후 반복적인 테스트가 수반돼야 하기에 오픈소스의 수정은 많은 수고와 노력이 필요하다.

이처럼 오픈소스 도입은 전체 아키텍처를 파악하고 한글화 작업 진행과 각 부분을 어떻게 수정하는지에 따라 사용이 불편한 오픈소스에서 사용자 친화적인 시스템으로 거듭날 수 있다.

여러 개발도구 검증
다양한 기술에 기반해 구축기간이 짧은 프로젝트로 변화하는 시점이기에 당사에서는 이를 지원하고자 수행 단계마다 필요한 소프트웨어 개발 지원도구를 선별, 검증해 구축하는 작업을 진행했다.

진행 프로세스는 후보군 선정 → 도구에 대한 외부평가 및 소스 업데이트 지속성 → 컨테이너 기반 파일럿(pliot) 환경 구축 → 사용방법에 대한 이해 → 당사에 맞춘 커스터마이징 → 문서화 순으로 작업을 진행했고, 소스코드 품질을 위한 정적분석 도구, 테스트 지원도구, 자동화테스트 도구, 성능테스트 도구, 그 외 다양한 개발도구를 하나씩 검증 프로세스를 진행했다.

프로세스 단계에서 가장 중요한 단계는 커스터마이징 단계로 오픈라인 상태의 폐쇄망에서 동작 검증, 프론트엔드-백엔드 소스 수정 등이 가장 넘기 힘든 허들이었고 또 가장 많은 시간이 소요된 작업이었다. 주요 적용 사례는 다음과 같다.

• 정적분석 도구

프로젝트 품질점검(QA) 활동은 대다수 산출물(Document) 위주로 이뤄지고 있으므로, 개발/테스트 단계 품질점검이 미흡하다. 또한 협력업체 개발인력 비중이 높아짐에 따라 소프트웨어 코드 품질 중요성이 높아지고 있고, 소프트웨어 코드 품질 리뷰 활동이 적절히 수행되지 않아 테스트 단계에서의 결함률이 높으며, 유지보수에 어려움을 겪고 있다.

이러한 문제의 해결책으로 정적분석 도구를 도입해 소프트웨어 품질점검 자동화, 정량적 품질관리, 개발인력별 소프트웨어 품질을 추적해 품질 높은 소프트웨어를 고객사에 제공하려 했다.

소스 품질의 기준이 되는 정적분석은 기준이 되는 규칙(Rule)을 정하는 것이 중요하고, 사용가능한 개발도구로 구축했다 하더라고 다양한 프로젝트에 적용해서 주기적으로 정적분석결과를 분석하는 것이 중요하다. 주기적으로 분석된 결과 데이터를 축적해 프로젝트 소스코드 품질의 변화 및 도구적용 전/후에 대한 결과 피트백이 가능하므로 고객과의 신뢰구축에 중요한 도구라고 할 수 있다.

• 테스트 지원도구

개발자의 판단에 근거한 단위 테스트 진행 시 많은 문제점을 만들어낸다. 이런 문제를 제거하기 위해 여러 가지 기법들이 그 가치를 인정받았는데, 그중 하나가 테스트를 개발의 전면에 내세운 테스트 주도 개발(TDD: Test Driven Development)이다. ‘프로그램을 작성하기 전에 테스트를 먼저 작성하는 것’이라고 정의할 수 있다. 코드를 검증하는 테스트 코드를 먼저 만든 다음에 실제 작성해야 하는 프로그램 코드 작성에 들어가라는 뜻이다.

우리가 TDD 방식을 통해 얻고자 하는 최종 목적은 ‘잘 동작하는 깔끔한 코드’다. 다만 TDD에서는 정상적으로 동작하는 코드만을 개발의 목표로 삼지 않고, 작성된 코드도 명확한 의미를 전달할 수 있어야 한다. 즉 ‘제대로 동작(works)’할뿐만 아니라 ‘깔끔함(clean)’까지도 동등한 수준의 개발 목표로 삼는다는 점이 일반적인 개발 방식과 다르다. 2019 프로그래머스 리포트(Programmers Report)를 참고해 보면 아직 국내에서는 확산되지 않은 것을 알 수 있다.

TDD 확산이 부족한 주요 원인은 높은 진입장벽, 시간과 비용의 증가가 원인이다. 현재 필요한 것은 TDD로의 전환을 위한 브릿지로 제이유닛(JUnit), 모키토(Mockito) 등을 사용해보지 않은 개발자도 즉시 테스트 가능한 테스트케이스 소스를 제공하는 개발도구를 선적용해 테스트 주도개발을 위한 경험을 해주는 것이 개발문화의 변화를 이끌어 낼 수 있는 마중물이 될 것이다.

테스트케이스의 반복적인 사용 및 개발 소스에 대해 테스트 커버리지는 개발 단계에 가장 중요한 부분으로, 최소 테스트 커버리지는 70% 이상의 기준으로 점검하는 것이 보통이다. 실제 운영에서 문제가 되는 것은 테스트 케이스 중 검증이 안 된 로직에서 많은 오류를 발생시키기 때문이다. 테스트 케이스 지원도구는 정적분석 도구와 연동해 소스에 테스트 커버리지를 확인할 수 있게 해주고, 주기적인 검증으로 테스트 단계 즉 통합테스트 시 시간과 비용을 획기적으로 줄일 수 있다.

지속 업그레이드 필요
여러 개발도구를 적용하면서 문제가 된 점은 사용자가 사용하기 어렵다는 것이다. 또한 익숙한 기존 틀을 깨기 쉽지 않고, 개발도구별 프론트엔드-백엔드 기술과 사용 방법이 달라 진입장벽이 존재한다.

그래서 도구 사용의 통합화에 대해 고민하기 시작했다. 기존 내부 프로젝트에서 사용 시 발견된 문제점을 기준으로 사용자는 간편하게 사용하는 방법으로 프론트엔드에 자바FX(javaFx) 기반 개발도구 통합 실행화면을 제공해 사용성을 대폭 개선했고, 개발자를 위해 통합개발환경(IDE)인 이클립스 플러그인으로도 캔버스(Canvas)와 동일한 기능을 제공하게 됐다.

백엔드의 경우는 커스터마이징된 오픈소스 기반 개발도구를 도커 빌드(docker build)해 이미지로 관리, 적용을 원하는 프로젝트에 즉시 적용할 수 있게 변경했다.

이렇게 오픈소스 적용 기본 원칙을 기준으로 필요한 소프트웨어 개발도구를 한 개씩 적용해 실제 프로젝트에 적용하고, 적용 후 피드백을 받아 개발도구의 통합화 작업을 진행하게 됐다.

이것으로 끝이 아니다. 꾸준한 작업과 적용한 사례를 기반으로 추후 결과를 만들어 내는 방식으로 계속 진행될 것이다. 앞으로도 결승점 골인이 아닌 결승점을 향해 달려가는 마음으로 지속적인 업그레이드를 진행할 생각이다.

변화하는 환경에 발 빠르게 대비
신한DS는 프로젝트 수행 시 즉시 적용 가능하고 필수적인 소프트웨어 개발도구를 적용한 올인원(All-in-One) 형태의 개발통합지원도구(Shinhan Development ToolKit)를 제공해 ▲정량적이고 투명한 지속적인 품질관리 ▲코드품질 자동화 ▲테스트 커버리지 ▲프로젝트 관리 ▲자동 배포 ▲빠른 문제해결 및 체계적인 검증을 가능하게 했다. 이를 그룹사 내부 프로젝트에서 적용해 그룹사 담당자 및 투입인원들에게 많은 호응을 얻었으며, 더 나아가 외부 고객사의 차세대 시스템에도 적용하고 있다.

앞으로도 CI/CD, 데브옵스, 클라우드 환경이 가속화되는 상황에서 신한DS는 자체 개발방법론과 조화를 이루고 프로젝트를 성공적인 방향으로 이끌고자 검증된 오픈소스 기반의 다양한 소프트웨어 개발도구를 적극적으로 수집·검증해 도입하고 지속적으로 적용·구축할 예정이다. 또한 커스터마이징된 오픈소스들을 컨테이너로 관리하는 것뿐만 아니라 안정적인 사용을 위해 오픈소스 기반의 오케스트레이션 서비스를 적용, 프라이빗/퍼블릭 클라우드 환경에서도 안정적인 운영이 가능할 수 있도록 변화하는 환경에 발 빠른 대비를 하려 한다.

이처럼 오픈소스 기반의 다양한 개발도구를 활용해 적량적인 소프트웨어 개발, 상호소통 및 협업, 품질 좋은 소프트웨어, 고객과의 협력, 변화의 대응에 큰 가치를 두고 소프트웨어 생산성을 높이는데 주력할 예정이다.