Offcanvas

개발자 / 애플리케이션

블로그 | SW 개발과 관리, '관찰 가능성 도구'를 눈여겨볼 이유

2022.07.29 Matt Asay  |  InfoWorld
혹시 레거시 소프트웨어를 떠올리면 메인프레임 같은 구식 기기에서 쓰이는 구닥다리 코드가 생각나는가? 다시 생각해보라. 몇 달 전에 쓴 코드도 개발자의 발목을 잡는 레거시 코드가 될 수 있다. 결국 코드의 관찰 가능성을 높이고 상세한 설명서를 남겨야 진짜 좋은 코드를 유지할 수 있다. 
 
ⓒDepositphotos

만약 레거시 소프트웨어가 자신과 무관한 다른 세계의 이야기라고 생각한다면, 다시 생각해보라. 아키타 소프트웨어(Akita Software) 창립자 겸 CEO 진 양은 “모든 코드는 쓰이는(ship의 뉘앙스와 크게 달라요) 순간 레거시 코드가 된다. 새로 짜는 모든 코드는 관리해야 하는 짐이 되며, 이는 불가피하다. 나도 지난주에 어떤 코드를 작성했는지 기억 못 한다. 대다수 개발자가 그럴 것이다”라고 말했다. 

보통 어떤 소프트웨어를 레거시라고 부르려면 코볼(COBOL) 정도로 오래된 언어로 작성하거나, 메인프레임에서 구동되는 애플리케이션쯤 돼야 한다고 생각한다. 

하지만 바로 이런 사고방식이 개발자가 코드를 근시안적으로 개발하는 원인이 된다. 나중에 그 코드를 이해해야 할 사람을 고려하지 않는 것이다. 양이 지적한 것처럼 개발자 스스로도 코드를 다시 이해해야 하는 상황이 올 수 있다. 

그럼 어떻게 해야 레거시 코드를 잘 관리할 수 있을까? 

코드가 네트워크를 만나면 
코드의 까다로운 특성 중 하나는 바로 역동성이다. 코드는 절대 불변의 상태로 남지 않는다. 허니콤(Honeycomb) 창립자 겸 CTO 차리티 메이저스(Charity Majors)는 양과의 인터뷰에서 “코드가 네트워크에 들어서는 순간 신비의 세계에(mystery land)에 들어간다. 개발자의 통제권을 벗어나게 되는 것이다”라고 말했다. 

이런 비유를 해볼 수도 있다. 개발자가 처음 개발한 애플리케이션은 마치 원시 상태의 에덴 동산에 있는 것과 같다. 그러나 유용한 애플리케이션 대부분은 대게 인터넷에 연결되는 데, 그 순간 대혼란이 일어난다. 네트워크의 복잡성이 개입하기 때문이다. 

메이저스는 생산 단계로 밀어 넣기 전까지는 소프트웨어가 어떻게 작동할지 전혀 예측할 수 없다고 강변했다. 오직 생산 단계에서만 그 ’레거시’ 코드 내 결함이 드러난다. 그녀는 “작은 코드라도 일단 실행되면 복잡한 시스템”이라면서 “일단 사용자와 트래픽 패턴이 생기고 그 아래에 다양한 인프라가 접목되면서 복잡해진다”고 설명했다. 미지의 것들과 만나면서 점점 더 복잡해진다. 메이저스는 계속해서 “뭔가를 변경할 때 무슨 일이 일어날지 예측할 수 없게 된다. 통제된 환경에서 변경한 후 무슨 일이 일어나는지 관찰해야 한다”고 말했다. 

코드 문제가 아니라 사람 문제
메이저스는 "개별 개발자가 코드를 작성하겠지만 결국 소프트웨어를 제공, 배포, 관리 및 유지하는 주체는 소프트웨어 팀, 즉 사람이다. 즉, 소프트웨어 제공의 최소 단위는 팀이다”라고 말했다. 

모호한 표현인가? 메이어스는 소프트웨어 개발팀이 어떤 문제(버그, 오류 등)를 발견했을 때, 그 원인이 무조건 기술적일 것이라는 착각에 빠질 수도 있다는 점을 강조한 것이라고 양은 설명했다.

양은 자신 또한 메이저스의 견해에 동의한다며, “소프트웨어 개발 및 출시는 언제나 사람 문제였다. 코드보다 사람을 우선시해야 한다. 요즘 소프트웨어 개발 도구의 주요 기능 중 하나가 바로 개발자의 업무 기록을 지원하는 것이다. 개발자가 최근에 한 일과 문제가 발생한 원인비롯해등, 모든 개발 과정을 철저하게 기록하도록 돕는 도구가 많다. 결국 사람이 본질이고, 그들의 역사를 남겨야 한다”라고 말했다.    

이제 다시 레거시와 소프트웨어 관찰 가능성의 주제로 돌아가자.

레거시 받아들이기  
메이저스는 양과의 인터뷰에서 “디버깅 비용은 소프트웨어가 개발된 지 오래될수록 치솟는다”라고 지적했다.  아키타 및 허니콤 등의 관찰 가능성 툴은 신속한 디버깅에 도움이 될 수 있는 이유가 바로 이것이다. 이런 툴을 사용하면 통제된 생산 환경에서 코드를 실행할 수 코드를 작성 한 직후, 코드를 디버깅할 수 있다. 몇 개월, 몇 년, 몇 십년 후 코드를 해독하려 씨름하지 않아도 된다.

철저히 기록하라 
이는 철저한 기록이 매우 중요한 이유이기도 하다. 개발자가 자신이 만든 코드에 대한 배경과 접근 방식을 설명서를 남기면, 이 코드를 이용할 다른 개발자에게 큰 도움이 되리라는 점은 어찌 보면 당연하다.  

또한, 철저한 기록은 개발자 자신에게도 유용하다. 데이터셋(Datasette) 창립자 사이몬 윌리슨은 본인을 위해 코드 설명서를 작성한다고 언젠가 필자에게 말했다. 그렇게 하지 않으면 왜 코드를 특정 방식으로 작성했는지 곧잘 잊어버리기 때문이다. 그는 “상세하게 설명서를 작성해주면, 두 달이 지나 프로젝트로 복귀하더라도 모든 코드가 어떻게 작동하고 어디에 왜 있는지 금방 파악할 수 있다”라고 설명했다. 상세한 기록 덕분에 코드의 맥락에 적응할 수 있어서다. 

철저한 기록, 꼼꼼한 유닛 테스트(unit test), 그리고 높은 관찰 가능성 3가지가 레거시 코드를 효과적으로 관리하는 데 매우 중요하다고 메이저스는 거듭 강조했다. 그는 “개발 따로 운영 따로가 아니다. 운영 자체가 개발 작업의 일환이다”라며 “즉, 코드가 다양한 시스템과 제약 조건에서 어떻게 행동하는지 끝없이 검증하는 작업을 빠뜨릴 수 없다. IDE에만 틀어박혀 있으면 본인의 소프트웨어를 절대로 이해하지 못할 것”이라고 주장했다. “반드시 여러 환경에서 실행해보고 그에 따른 결과를 관찰해야 한다”라고 그는 덧붙였다. 

수년, 혹은 수십 년에 작성된 코드를 활용하려 애쓰는 개발자는 어떻게 해야 할까? 본인과는 무관한 상황이라고 생각한다면, 개발자 아비샤이 이시-샬롬이 최근 주장한 내용을 살펴볼 가치가 있다. 그는 리눅스(Linux), 마이SQL(MySQL), 포스트그레SQL(PostgreSQL)과 같은 현대적 인프라가 등장한지도 이미 수십 년이 되었고, 심지어 최신 기술로 여겨지는 클라우드도 이제 청소년기에 접어들었다고 말했다. 이어 그는 “이러한 인프라가 기대 이상으로 유연하고 안정적이라는 점이 입증됐지만, 요즘 들어 노화의 징조가 서서히 나타나고 있다. 해가 갈수록 유지보수와 개발이 더욱 어려워지고 있다”라고 지적했다.

레거시 SW, Old & New 
어쨌든, 살롬이 말하는 새로운 레거시이든, 정말 오래된 레거시이든, 우리가 레거시 소프트웨어의 세계에 살고 있다는 점은 분명하다. 
 
ⓒDepositphotos

기술 분야는 하드웨어 및 소프트웨어 한계에 부딪히거나, 새롭게 혁신의 기회를 포착할 때마다 대전환을 추진한다. 모놀리틱에서 마이크로서비스 구조로, 디스크에서 RAM 메모리로의 전환 같은 사례가 있다. 

하지만 새로운 기술에는 항상 레거시 기술이 그림자처럼 따라다닌다. 특히 수 년 내지 수십 년 된 시스템을 다루는 기술 종사자의 상황은 매우 나빠진다.  양은 톨스토이의 소설 ‘안나 카레리나’에 나오는 첫 문장(모든 행복한 가정은 서로 닮았고, 불행한 가정은 제각각 나름으로 불행하다)을 차용했다. “최신 시스템은 서로 비슷한 기술을 기반으로 한다. 그러나 구식 시스템은 구식인 이유는 제각각이다”라며, “즉, 모든 레거시 시스템이 구식이 되는 이유는 천차만별이이다”라고 그는 덧붙였다. 

SW 관찰 도구
이런 이유로 몇몇 기업은 아키타 같은 서비스를 검색 툴로 활용해 서비스 매핑을 하고 있다. 기존 시스템의 작동 방식을 총체적으로 파악하기 위함이다. 허니콤으로 같은 툴은 사용하면 더욱 깊게 파고들 수도 있다. 

메이저스의 표현에 따르면 이런 관찰 가능성 툴은 ’복잡함을 단순화’하는 것을 목적으로 한다. 그래서 최대한 많은 팀원이 소프트웨어를 이해하고 제공하도록 돕는다. 

물론,.이런 툴로 인해 레거시가 좀 더 늘어날 수도 있다. 그러나 괜찮다. 관찰 가능성 툴을 이용해 레거시의 존재를 이해하고 잘 관리해내기만 한다면 말이다.

레거시는 불가피할 수는 있다. 하지만 이제 이를 감내해야 할 이유는 없다.

*Matt Asay는 몽고DB의 파트너 마케팅을 담당하고 있다. ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.