Offcanvas

How To / 개발자 / 애플리케이션

'리팩터링, 린트, 프로필...' 완료된 코드를 추가 개선하는 16가지 팁

2020.03.05 Peter Wayner   |  InfoWorld
작성한 코드가 모든 테스트에서 정상으로 나왔다. 지속적 통합 파이프라인도 끝까지 실행됐다. 기능 목록의 모든 체크박스를 확인했고, 벽에 붙여 둔 포스트잇 메모는 모두 완료 구역으로 이동됐다. 휴...
 
이쯤 되면 코드가 완성되었음을 선언하고 휴가를 떠나고 싶은 마음이 굴뚝같다. 그럴 만한 자격이 있다. 한동안 코드가 작업을 수행하도록 두면 된다. 애초에 그렇게 하려고 만들지 않았던가? 벽 너머로 던져 거기서 실행되도록 하면 그걸로 우리 일은 끝이다.
 
그러나 현실에 만족하는 시대는 끝났다. 요즘은 끝난다는 개념이 없다. 버그를 없앤, 기능하는 프로그램을 전달했다고 해서 쉬어도 된다는 뜻은 아니다. 그 시점에도 코드를 개선하기 위해 할 수 있는 일이 십여 가지는 있기 때문이다. 다음 팀을 위해 코드를 잘 정비하는 모범적 개발자로서 해야 할 일도 있고, 새로운 여정의 시작이라 할 만한 것도 있다.
 
잠깐의 휴식과 재충전 후에 돌아와서 해야 할 16가지 일을 살펴보자.
 

린트

린트(lint) 또는 린터(linter)라고 하는 이 툴은 일종의 코드 리뷰 로봇으로, 수백, 수천 가지의 의미 체계 규칙을 적용한다. 공백 문자의 수를 하나하나 세고 공백을 너무 많이 또는 너무 적게 사용한 개발자를 질책하는 강박적 잔소리꾼이 만든 규칙도 있고, 나중에 보안 결함으로 이어질 수 있는 모호한 의미 체계 패턴을 지적하는 깐깐한 사람들이 만든 규칙도 있다. 프로그래밍 팀이라면 이미 선택해둔 린터 모음이 있을 테니, 이제 그 린터를 실행할 시간이다.
 

프로필

돈 커누스는 전에 “너무 이른 최적화는 만악의 근원”이라고 말한 적이 있다. 코드에서 가끔씩만 실행될 부분을 개선하느라 시간을 허비하는 것은 어리석은 일이기 때문이다. 이제 코딩을 끝냈으니, 프로파일러를 실행해서 포화가 집중되는 지점을 찾을 시간이다. 많은 경우 코드의 10%가 90%의 시간 동안 실행된다. 때로는 조밀한 내부 루프가 사이클의 99%를 흡수하는 경우도 있다. 지금 그러한 부분을 찾을 수 있다면 약간의 조정만으로 큰 효과를 볼 수 있다.
 

디버깅 툴 제거

만일을 위해 프로덕션 코드에 세부적인 로깅 옵션을 내장해 두고 싶은 생각이 들겠지만 일단 코드가 실행되면 이러한 로깅 툴을 정리하고 디버깅 옵션도 끄는 것이 좋다. 가외의 데이터가 컴퓨터를 어지럽히고 디스크 공간을 점유해 성능에 부정적인 영향을 미칠 수도 있기 때문이다. 프로덕션 서버에서는 디버깅을 빼라.
 

AI를 사용한 분석

과거의 프로그래머들은 기본적인 정규식과 문을 사용해서 문제를 찾았다. 현대의 프로그래머에게는 인공 지능 툴도 있다. 예를 들어 아마존의 코드구루(CodeGuru)는 “머신 러닝 모델을 활용”해서 불량 코드를 찾아준다고 한다. 프로파일링 및 정밀 분석을 기반으로 하는 완전한 자동 프로세스다.
 

데이터의 가치 산정

애플리케이션을 빌드할 때는 데이터베이스와 로그 파일을 당연하게 생각하기 쉽다. 이제 앱 작업은 끝났으니, 속도와 안정성을 위해 데이터베이스 최적화를 시작할 시간이다. 적절한 열에 인덱스를 추가해 조회 속도를 높인다. 정전이나 디스크 장애 발생 시의 안정성을 개선하기 위해 미러링과 적시 백업을 추가한다.
 
이제 스토리지 비용과 데이터 손실 비용을 놓고 저울질할 차례다. 로그 파일이 얼만큼의 가치를 지니는가? 로그 파일을 유지하려면 얼만큼의 비용이 드는가? 데이터 센터에 재해가 발생할 가능성에 견주어 지리적으로 분산된 백업 계획에 드는 비용이 적절한가? 쉽게 답할 수 없는 질문들이지만 일단 백업의 비용을 파악해야 얼만큼 도박을 할지를 결정할 수 있다. 카지노와 같지만, 본인의 경력과 주변 사람들의 일자리를 걸고 주사위를 굴린다는 차이가 있을 뿐이다.
 

데이터 흐름 최적화

많은 애플리케이션은 빠른 캐시의 혜택을 누릴 수 있다. 서버에서의 캐시도 되고, 콘텐츠 전송 네트워크로 인터넷 전반에 분산된 형태도 된다. 분산 메모리 캐시를 추가하거나 CDN을 통합하는 것은 사용자의 체감 성능을 높이는 가장 간단한 방법 중 하나다.
 

데이터 최적화

데이터 중에는 필요 이상으로 큰 경우가 있다. 많은 타협 없이 크기를 줄일 수 있는 가장 간편한 대상 중 하나는 이미지다. 정교한 백그라운드와 같은 양식상의 디테일은 극히 작은 디스크 공간과 대역폭을 사용하는 그라디언트 채우기를 위한 CSS 명령어로 대체가 가능하다. 사진가와 예술가는 필요한 경우를 대비해 최대한 많은 정보와 세부 사항을 유지하고자 이미지를 RAW 형식으로 저장하곤 한다. 이미지옵팀(ImageOptim)과 같은 툴은 사용자가 인지할 수 있는 범위를 벗어나는 불필요한 세부 사항을 없애고 카메라 렌즈와 같이 본질과 무관한 정보를 추적하는 EXIF 값도 제거한다. 결과적으로 다운로드 속도가 빨라지고 대역폭 사용량이 줄어든다.
 

API 추가

많은 설계자가 프런트엔드 디스플레이 코드를 그 아래의 비즈니스 로직과 분리하기 위해 잘 만들어진 API를 시작점으로 삼지만, 또 다른 문이나 창문을 추가해서 코드 베이스의 사용을 확장할 수 있는 경우도 존재한다. 스웨거(Swagger)와 같은 API 툴킷은 파싱, 라우팅, 문서화를 통해 이 과정을 비교적 쉽게 해준다. 현재 코드 블록으로 들어가는 깔끔한 진입점인 함수가 있다면 새 API에 이러한 함수를 연결해서 새로운 자동화와 통합 옵션을 실현할 수 있다.
 

라이브러리로 묶기

코드는 종종 다른 프로젝트에 포함되는 라이브러리로서 두 번째, 세 번째, 많으면 네 번째 삶을 얻는다. 뛰어난 설계자는 사전에 이와 같은 옵션을 예상하고 처음부터 코드를 라이브러리로 나누지만, 뒤늦게 영감이 떠오르는 경우도 있다. 코드를 라이브러리로 리팩터링하는 것은 작업물에 새로운 생명을 불어넣기 위한 좋은 방법이다.
 

문서

예전보다 그 중요함이 낮아졌다 해도 적절한 문서화는 여전히 유용하다. 알아보기 쉬운 변수 이름과 간소한 구조를 사용해 적절히 구조화된 코드를 쓴다면 많은 로컬 주석이 필요 없을 것이다. 그러나 각 섹션의 역할을 대략적으로 기술하고 코드에서 데이터가 어떻게 흐르는지 명시해 두면 여전히 도움이 된다. 또한 코드의 잠재적인 문제를 설명하고 코드가 예외로부터 어떻게 복구되는지(복구가 된다면) 기술하는 것도 도움이 된다.
 

마이크로서비스로 쪼개기

점점 더 많은 아키텍트가 자신의 원대한 비전을 가져다 조각조각 분쇄하고 있다. 때로는 커다란 애플리케이션 하나보다는 여러 개의 작은 애플리케이션을 유지하는 것이 더 쉽다는 사실을 아는 것이다. 개발자는 동시에 서로 다른 부분을 작업할 수 있고, 최종 통합 테스트 전에는 코딩과 테스트를 독립적으로 진행할 수 있다. 프로젝트는 시간이 지나면서 규모가 커지기 쉬운데, 특히 추가 기능이라도 있으면 더욱 심해진다. 때로는 최종 마감이 다가올수록 작업을 더 작은 조각으로 나누는 이점이 더 분명해지기도 한다.
 

컨테이너화

점점 더 많은 코드가 컨테이너 이미지로 생을 마감한다. 컨테이너 이미지는 새로운 소스 파일을 특정하고 어떤 라이브러리와 기타 서비스가 필요한지를 알려주는 역할을 한다. 이런 환경 구성 파일을 만드는 것은 어떨 때는 매우 단순하지만, 좀 더 영리하게 처리할 수 있는 기회는 무궁무진하다. 어떤 팀은 코드를 여러 개의 컨테이너로 나누기를 좋아하는데, 필요에 따라 각각 사용할 수도 있기 때문이다. 일반적으로 각 마이크로서비스는 자체 컨테이너 내에 살지만, 공유해야 할 이유도 있기 마련이다. 어떤 개발자는 각각의 문서조차도 별도의 컨테이너로 만드는 좀 더 극단적인 접근법을 주창하기도 한다. 아직 논쟁의 여지가 많은 부분이다.
 

서버리스 배치

서버리스 컴퓨팅 옵션이 한창 일반화되고 있지만, 코드에서 핵심 기능을 뽑아 AWS 람다나 애저 펑션즈 같은 서버리스 플랫폼에 배치하는 것은 '스마트'한 방식이다. 사용 요금도 호출 회수로 계산되기 때문에 들어오는 트래픽이 없는 휴지기에는 비용을 낼 필요도 없다. 만약 기존 코드가 잘 만들어진 데다 상태를 유지하고 있어야 할 필요도 없다면, 애플리케이션에서 비즈니스 로직만 추출해 서버리스 시스템에서 사용하는 단순 기능 호출로 재포장하는 것은 손쉬운 일이다.
 

모바일로 배포하기

현재 훌륭한 웹 앱 대다수는 모바일 디스플레이용으로도 설계된다. 또 모바일 디스플레이에 맞게 설계된 웹 앱이 보통 스마트폰에서도 잘 작동하기 때문에 독자적인 앱을 따로 개발하라는 요구는 점점 줄어드는 형태다. 또한, 웹 앱은 앱 스토어나 구글 플레이 스토어에 등록되기 위해 수많은 난관과 리뷰를 거쳐야 할 필요도 없다. 하지만 가끔 웹 기반 앱을 네이티브 아이폰, 안드로이드 앱으로 바꿔야 할 이유도 생겨나며, 브라우저 임베디드 버전과 웹 서버 마무리 작업을 통해 플랫폼 이전을 쉽게 도와주는 도구도 있다.

근본주의자들은 임베디드 웹페이지에서 자바스크립트를 실행하는 것은 진정한 네이티브가 아니라고 주장한다. 그리고 게임 같은 몰입도 높은 일부 앱에서는 지연을 유발할 수 있다는 그들의 주장도 맞는 말이다. 그러나 대부분의 경우에는 자바 스크립트가 앱 스토어에 진입할 수 있는 가장 단순한 방법이기도 하며, 장점도 많다. 네이티브 앱은 로컬의 대규모 웹 사이트를 캐시화해서 데이터 전송을 더욱 섬세하게 제어할 수 있다. 따라서 개발자와 모바일 사용자 모두의 데이터 대역폭을 절약하고, 상호작용이 더 빨라지며, 데이터 사용량도 줄일 수 있다.
 

웹으로 이동하기

대부분의 경우 앱을 다른 방향으로 옮기고, 웹 사이트로 다시 묶는 작업이 훨씬 더 번거롭다. 웹 코딩에 맞게 설계된 툴키트를 사용하지 않는다면, 자바, 스위프트, 오브젝티브 C 언어로 쓰인 네이티브 코드를 대규모로 다시 써야 할 것이다. 그래도 웹 브라우저용으로 설계하면 앱 스토어 리뷰의  통제에서 벗어날 수 있고, 같은 코드로 데스크톱 PC용 제품을 만들 수 있다는 장점이 있다.
 

계속 진행하기

몇몇 똑똑한 프로그래머는 코드를 다시 쓴다는 개념을 재창조해냈다. 코드 다시 쓰기(rewriting)라는 표현은 애초에 실수를 했기 때문에 다시 쓴다는 느낌을 주기 때문이다. 새로운 단어는 ‘리팩터링(refactoring)’이다. 리팩터링은 기존 실수의 존재 유무와는 상관없고, 따라서 다루는 사람의 자존심도 멀쩡하다. 코드 개선 과정은 종종 단계를 건너뛰기도 하므로 코드를 ‘완료’한 후 바로 다시 시작하는 것도 좋은 생각이다. 자잘한 개선과 수정 사항을 빠르게 코드에 추가할 수 있다.

많은 부서에서 지속적인 리팩터링, 쉬핑, 새 버전 배포 등을 매일, 또는 시간마다 진행한다. 이러한 자잘한 변경은 눈에 띄지 않겠지만 몇 주일, 몇 달을 걸쳐 쌓이면서 점진적이지만 확연한 변화를 이끌게 된다. 이러한 반복이 너무 자주 이루어지면 코드 완성과 재시작의 구분이 흐려진다. 개선과 배포라는 하나의 사이클은 계속 이어진다. editor@itworld.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.