"완벽한 화룡점정" 깜박 잊어버리기 쉬운 코드 작업 10가지

작성한 코드에 대한 모든 테스트를 수행했고 결과도 문제없었다. 지속적인 통합 파이프라인도 프로세스도 모두 거쳤다. 기능 목록의 확인란은 모두 체크되어 있다. 모든 포스트잇 노트는 작업 완료됐음을 알리는 칸으로 옮겨졌다. 휴, 이제 한숨 좀 놓을 수 있겠다.

이제 코드가 완성됐다며 휴가를 떠나고 싶은 유혹을 느낀다. 팀 전체가 그럴 자격이 있다. 잠시 동안은 코드가 제 일을 하도록 내버려두자. 그게 바로 열심히 코드를 작성한 이유가 아니던가? 버려두면 코드가 흥얼거리며 스스로 할 일을 하도록?

아, 현실에 안주하고 가만히 앉아있던 시대는 끝났다. 요즘엔 아무것도 완료될 수 없다. 숨어있던 버그를 힘들게 찾아내고 제대로 작동하는 프로그램을 완성했다고 해서 쉬어도 된다는 뜻은 아니다. 아직 코드를 개선하게 위해 할 일이 수십 가지다. 일부는 다음 팀을 위해 정리를 하는 선량한 시민의 역할이고, 일부는 성장과 새로운 시장을 포착할 수 있는 기회를 만드는 것이다. 일부는 새로운 여행의 시작이 될 것이다. 

코드 개발 과정에서 약간의 휴식과 충전을 취하고 돌아와 시작할 16가지 작업을 소개한다.
 

린트

린트(lint) 또는 린터(linter)라고 하는 툴은 코드 검토 로봇처럼 수백 개의 의미 규칙을 시행한다. 아마도 수천 개에 이를 것이다. 일부는 프로그래밍 부서에서 공백 문자의 수를 세고 너무 많거나 적게 사용한 개발자를 강박적으로 지적해서 작성됐고, 일부는 추후 보안 결함으로 이어질 수 있는 모호한 의미 패턴을 찾아내 표시하는 진지한 개발자가 작성하기도 했다. 아마 프로그래밍 팀이 선택한 린터 모음이 있을거고, 이젠 실행할 때다. 
 

프로필

컴퓨터 과학자 돈 크누스는 “미숙한 최적화는 모든 악의 근원”이라고 말했다. 가끔씩만 실행되는 코드의 일부를 개선하느라 시간을 소모하는 것은 어리석기 때문이다. 이제 코딩이 끝났으니 이제 프로파일러를 시작해 문제가 집중된 부분을 찾아야 한다. 코드의 10%가 90%의 시간을 소비하는 경우가 종종 있다. 때로는 여유 없이 빡빡한 내부 루프가 주기의 99%를 차지하기도 한다. 지금 이러한 문제들을 찾아낼 수 있다면, 약간의 조정만으로도 성과를 낼 수 있다. 
 

디버깅 도구 제거

만일의 경우를 대비해 프로덕션 코드에 자세하다 못해 장황한 로깅 옵션을 남겨두고 싶겠지만, 일단 코드가 실행되면 이런 도구를 정리하고 디버깅 옵션을 끄는 것이 좋다. 부가적인 데이터는 컴퓨터를 어지럽히고 디스크 드라이브를 점유해 성능을 위협할 수 있다. 프로덕션 서버에서는 디버깅을 수행하지 않기를 권장한다. 
 

AI로 분석

과거의 프로그래머는 기본적인 정규 표현식과 문장을 사용해 문제를 찾았다. 현대 프로그래머는 인공 지능 도구도 사용한다. 예를 들어 아마존의 코드구루(CodeGuru)는 “머신 러닝 모델을 활용해” 잘못된 코드를 찾는다고 한다. 프로파일링과 철저한 분석을 기반으로 한 완전히 자동화된 프로세스다. 
 

큐레이트 데이터

애플리케이션을 구축할 때, 데이터베이스과 로그 파일을 당연하게 여기기 쉽다. 이제 앱을 완성했으니 속도와 안정성을 위해 데이터베이스를 촤적화할 시간이다. 조회 속도를 높이려면 적절한 열에 인덱스를 추가한다. 미러링과 적시 백업을 추가해 정전이나 디스크 장애 발생 시 안정성을 높인다. 

이제 스토리지 비용 대비 데이터 손실 비용을 비교해야 할 때다. 로그 파일의 가치는 어느정도 인가? 유지비용은 얼마일까? 데이터 센터의 재해로 인한 피해 가능성 대비 지리적으로 분산된 백업 계획 비용은 어느정도 인가? 대답하기 쉬운 질문은 아니지만, 일단 백업 비용을 이해하면 도박에 걸 비용을 결정할 수 있다. 마치 이미 비용이 지불된 라스베가스로의 여행과 같다. 단, 본인의 경력과 주위 모두의 일자리를 걸고 주사위를 던지는 도박이다. 
 

데이터 흐름 최적화

많은 애플리케이션은 서버에서 또는 콘텐츠 전송 네트워크를 통해 인터넷에서 확산되는 빠른 캐시의 이점을 누릴 수 있다. 분산 메모리 캐시를 추가하거나 CDN을 통합하는 것은 사용자가 경험하는 성능을 향상시키는 가장 간단한 방법 중 하나다. 
 

데이터 최적화

모든 데이터가 지금처럼 클 필요는 없다. 너무 많은 손해 없이 크기를 줄이는 가장 간단한 방법은 이미지다. 정교한 배경과 같은 서식 세부사항은 디스크 공간과 대역폭을 매우 적게 차지하는 그래디언트 채우기를 위한 CSS 명령어로 대체할 수 있다. 사진가와 예술가는 종종 이미지를 RAW 형식으로 저장해, 필요한 경우를 대비해 세부 정보를 가능한 많이 유지하는 경향이 있다. 이미지옵팀(ImageOptim)과 같은 도구는 사용자가 인지할 수 있는 수준에 못 미치는 불필요한 세부사항을 제거하고, 카메라 렌즈와 같이 관련 없는 정보를 추적하는 EXIF 값도 제거한다. 결과적으로 다운로드 속도가 빨라지고 대역폭 사용비는 줄어든다. 
 

API 추가

많은 설계자가 프론트엔드 디스플레이 코드를 하위의 비즈니스 로직과 분리하기 위해 정형화된 AIP로 시작하지만, 때로는 다른 문이나 창문을 추가해 코드 기반의 사용을 확장할 수 있는 좋은 기회도 있다. 스웨거(Swagger)와 같은 API 툴킷은 파싱(Parsing), 라우팅, 심지어 문서화를 제공해 비교적 쉽게 수행할 수 있다. 현재의 코드 블록에 대한 깔끔한 진입점 함수가 있다면, 새로운 API에 접목해 자동화와 통합을 위한 새로운 옵션을 사용할 수 있다. 
 

문서화

문서화는 예전보다 중요도는 낮아졌지만, 적절한 분량은 여전히 도움이 된다. 이해하기 쉬운 변수 이름과 단순한 구조로 잘 구성된 코드를 작성한다면, 코드에 많은 로컬 주석이 필요 없다. 그래도 각 섹션의 기본 역할과, 데이터가 코드를 통해 흐르는 방식을 간단히 설명해 두면 도움이 된다. 코드의 잠재적인 문제 중 일부를 적시하고, 코드가 예외에서 복구가 된다면, 어떻게 복구되는지에 대한 설명도 도움이 된다. 
 

계속 진행

일부 영리한 프로그래머는 코드를 다시 쓴다는 개념을 재정의했다. “재작성”이라는 단어가 처음에 실수를 한 것처럼 들리기 때문이다. 새로운 “리팩토링(Refactoring)” 단어의 어감이 더 낫다. 리펙토링은 이전의 실수를 인정하는 의미도 아니고 자존심을 다치게 하지도 않는다. 코드를 개선하는 과정은, 종종 작은 개선이긴 하지만, ‘완료’ 이후에 바로 시작하는 것이 좋다. 작은 개선과 수정은 코드에 즉시 적용될 수 있다. 

많은 개발팀이 새로운 버전을 매일 또는 매시간 지속적으로 리팩토링, 출하(shipping), 배포하고 있다. 그 자체로는 이런 작은 변화가 미미해 보이지만 몇 주, 몇 개월에 걸쳐 현저한 개선이 된다. 반복이 너무 빨라서 코드 완료와 재시작의 경계가 모호해진다. 단 하나의 지속적인 개선과 배포 주기의 반복일 뿐이다. editor@itworld.co.kr