[보안뉴스 문정후 기자] 양질의 결과물을 내고 싶은 건 분야를 막론하고 모든 사람의 열망이다. 코딩을 업으로 삼고 있는 사람들도 마찬가지다. 다만 ‘품질’이라는 것의 정의를 모두가 다르게 내린다는 게 문제다. 알고 지내는 코더 아무나 잡고 “품질이 뛰어난 코드란 무엇입니까?” 질문을 받는 사람마다 다른 답을 내릴 것이다.
[이미지 = utoimage]
데이터 전문 회사인 슈퍼컨덕티브(Superconductive)의 엔지니어링 부문 부회장인 로렌스 브러뮬러(Lawrence Bruhmuller)는 “양질의 코딩에는 세 가지 특성이 있다”고 운을 뗀다. “개인적인 견해이긴 하지만, 가독성, 일관성, 모듈성을 갖춘 코드가 좋은 코드라고 생각합니다. 누가 코드를 봐도 독해가 가능해야 하고, 들쭉날쭉한 퍼포먼스를 보여서도 안 되고, 여러 조각으로 나뉘고 유연하게 조합될 수 있어야 한다는 겁니다.”
또한 브러뮬러는 “모든 관계자들이 코드에 쉽게 이해할 수 있어야 한다”고 덧붙이기도 한다. “무슨 말이냐면 변수나 메소드에 명확하고 직관적인 이름을 붙이고, 여백을 제대로 활용해야 한다는 겁니다. 또한 주석도 적절한 곳에 달아 코더의 의도와 생각의 흐름을 파악할 수 있어야 하되, 또 주석이 너무 많아서는 안 됩니다. 어떤 부분에서는 외부 라이브러리와 오픈소스를 겹겹이 사용하고, 어떤 부분에서는 손수 짠 코드만 사용하는 등 일관성 없는 코딩 행위도 그리 추천할 만하지 않습니다. 어떤 부분을 읽던 같은 사람이 짰다는 느낌을 주는 코드가 좋은 코드라고 생각합니다.”
품질 평가의 여러 가지 방법들
코딩에 대해 잘 모르는 프로젝트 관리자가 코드의 품질을 평가하는 데 사용하는 기술들이 있다. 가장 쉬운 방법 중 하나는 코드 스캔을 통해 쓸데 없이 복잡하게 구성된 부분을 찾아내는 것이다. 함수 하나에 너무 많은 IF 구문이 들어가 있다든가 하는 부분을 브러뮬러는 예로 든다. “또한 테스팅 단계에서나 베타 사용자들에 의해 발견된 버그의 수량을 보고도 코드의 품질을 가늠할 수 있습니다. 하지만 사내 개발자들의 평가도 대단히 중요합니다. 개발자만큼 코드의 품질을 꿰뚫어 볼 수 있는 사람은 없죠.”
컨설팅 회사 캡제미니(Capgemini)의 데브옵스 책임자인 쿨비르 라이나(Kulbir Raina)는 “좋은 코드와 나쁜 코드의 차이는 유지 관리의 난이도에서 나타난다”고 말한다. “그렇기 때문에 운영 비용만큼 정확한 척도가 없습니다. 운영 비용이 낮으면 낮을수록 그 코드는 품질이 좋았다는 뜻이 됩니다. 그 외에 확장성, 가독성, 재활용성, 신장성, 리팩토리성, 간결성도 좋은 코드의 중요한 특징입니다.”
계속해서 라이나는 “기술 부채가 얼마나 되는지 측정하고(즉, 꼭 필요한 비기능적 요소가 얼마나 되는지), 결함이 얼마나 되는지(즉, 코드가 원래 발휘해야 하는 기능성과 실제 기능성 간 격차가 얼마나 되는지) 파악함으로써 좋은 코드와 나쁜 코드를 구분하는 것도 가능하다”고 강조한다. “다행히 소프트웨어 설명서 작성과 지속적 검사를 통해서 코드의 품질을 개선할 수 있습니다.”
속도 vs. 품질
코드의 품질을 가장 저해하는 요소는 뭐니 뭐니 해도 속도에 대한 압박감이다. 빠른 코더가 유능한 코더냐, 양질의 코딩을 해야 유능한 코더냐 - 컴퓨터의 역사만큼이나 오래된 논제다. 자매품으로는 ‘기한을 더 주면 양질의 코딩을 할 수 있는가, 품질 욕심을 줄이면 속도를 빠르게 낼 수 있는가?’가 있다. 브러뮬러는 “속도가 빠르거나 품질이 좋은 건 다 강력한 특장점”이라고 말하며 “어떤 소프트웨어를 만들고 있느냐에 따라 발휘되어야 할 능력이 다르다”고 정리한다.
“그렇다고 하나를 얻기 위해 다른 하나를 포기해야만 하는 것도 아닙니다. 둘 다 추구하는 게 가장 생산적이겠죠. 저희 회사의 경우, 개발 속도 자체는 강조하는 편입니다. 다만 실험과 모니터링에 더 힘을 줍니다. 속도 때문에 모자랄 수 있는 품질을 개발 후 실험 및 모니터링으로 보충하는 것이죠. 즉 속도와 품질 사이에서 균형 맞추는 법을 저희 나름대로 찾은 것입니다. 사실 살면서 가장 중요한 건 균형을 맞추는 거잖아요. 모 아니면 도의 답이 항상 정답인 건 아니라고 생각합니다. 빠르게 출시하고, 빠르게 피드백을 받아 빠르게 고쳐줌으로써 완벽한 품질에 가까워질 수 있습니다.”
라이나 역시 속도와 품질의 문제에서 하나를 포기할 필요가 없다는 의견이다. “아니, 오히려 진짜 프로 코더라면, 그리고 개발을 주력으로 하는 회사라면, 둘을 다 가져갈 생각을 해야 합니다. 둘 중 하나밖에 택하지 못한다고 여기는 순간 아마추어가 되는 겁니다. 속도, 품질, 그리고 보안까지, 한꺼번에 고려하고 전부 양보 없이 잡는 게 맞습니다. 이 셋은 적어도 현재의 개발 환경과 시장 상황에서는 양보가 불가능한 가치관이라고 봅니다.”
품질 확실히 다지기
라이나의 말마따나 그 어떤 것도 양보할 수 없는 가운데, 품질을 계속해서 일정하게 유지하려면 어떻게 해야 할까? 브러뮬러는 “사용자들을 기쁘게 하는 소프트웨어를 만드는 게 최고의 방법”이라고 말한다. “수많은 사용자들이 기꺼이 소프트웨어를 평가해 주다 보면 부족한 부분들이 발굴되고, 이걸 고쳐서 만족시키는 것이 결국 코드의 품질을 높이는 것과 마찬가지라는 겁니다. 또한 개발 팀에 다양한 인력들이 있을수록 좋습니다. 다양한 시각으로 코드와 소프트웨어를 바라볼 수 있게 되거든요. 그럴수록 더 많은 사용자들에게 만족감을 주기 쉽겠죠.”
딜로이트(Deloitte)의 데브섹옵스 팀 리스크 및 금융 상담 총괄인 아론 오(Aaron Oh)는 “품질이 좋은 코드가 곧 모든 면에서 완벽하고 보안이 튼튼한 코드라고 여기는 건 잘못된 것”이라고 강조한다. “소프트웨어 및 코드 설명서도 잘 문서화 되어 있고, 버그도 나오지 않고, 최적화도 잘 되어 있지만 여전히 보안의 측면에서는 구멍이 있을 수 있습니다. 그렇다고 해서 이 코드의 품질이 곧바로 하락하는 건 아닙니다. 그저 보안의 측면에서 향상시킬 부분이 더 남아 있다는 뜻일 뿐입니다.”
하지만 반대로 보안이 완전히 결여된 코드 품질 평가도 바람직하지 않다고 그는 경고한다. “결국 언젠가는 보안 점검이라는 것이 개발 초기 단계에서부터 들어가야 하는 요소로서 자리를 잡을 것입니다. 데브섹옵스라는 개념이 조금씩 확대되고 있고, 개발자들 사이에서 보안에 관한 개념들이 서서히 연구되고 있기도 합니다. 시큐어 코딩이라는 개념에 대하여 현대 개발자 치고 모르는 사람은 없고, 코딩 교육에서도 점차 보안이 비중 있게 다뤄지고 있고요. 완벽해지고 싶은 코더라면 보안을 지금부터 공부해 두어야 할 것입니다.”
글 : 존 에드워즈(John Edwards), IT 칼럼니스트
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>