티스토리 뷰


코드는 어떻게 소프트웨어가 되는가

코드는 일반적으로 엔지니어가 작성하자마자 실제로 실행되는 소프트웨어가 되는 것이 아니다. 코드가 의도한 대로 작동하고 기존의 기능이 여전히 잘 작동한다고 확신하기 위한 다양한 과정과 점검이 이루어진다. 이러화 과정을 소프트웨어 개발 및 배포 프로세스라고 부른다.


  • 코드베이스(Codebase): 소프트웨어를 빌드할 수 있는 코드가 저장된 저장소다. 이것은 일반적으로 깃, 서브버전, 퍼포스 등과 같은 형상관리 시스템에 의해 관리된다.

  • 코드 제출(submitting code): 코드 커밋 혹은 풀 요청 병합이라고도 불린다. 개발자는 일반적으로 코드베이스를 자신의 로컬 컴퓨터에 복사하고 여기서 코드를 변경한다. 코드 변경이 끝나면 변경된 사항을 메인 코드베이스에 제출한다.

  • 코드 검토(code review): 여러 회사나 조직에서 코드를 코드베이스에 제출하기 전에 다른 엔지니어가 변경된 내용을 검토하도록 하고 있다.

  • 제출 전 검사(pre-submit check): 때로는 병합 전 훅, 병합 전 점검, 커밋 전 점검이라고도 하며, 테스트가 실패하거나 코드가 컴파일되지 않을 경우 변경 사항이 코드베이스에 병합되지 않도록 차단한다.

  • 배포(release): 소프트웨어는 코드베이스의 스냅샷을 기반으로 빌드된다. 다양한 품질 보증 검사 후에 실제 실행 환경에 배포된다.

  • 프로덕션(production): 테스트 환경과 같이 내부적으로 사용하는 것이 아닌 실제 서비스되는 환경을 가리킨다. 소프트웨어가 출시되고 비지니스 관련 작업을 수행하면 프로덕션 환경에서 실행된다고 말한다.


코드 품질의 목표

더 나은 코드 품질을 위해 아래와 같은 네 가지 상위 수준의 목표를 달성하고자 노력하자.

  1. 코드는 작동해야 한다.
  2. 코드는 작동이 멈추면 안 된다.
  3. 코드는 변경된 요구 사항에 작동할 수 있어야 한다.
  4. 코드는 이미 존재하는 기능을 중복 구현해서는 안 된다.

코드 품질의 핵심 요소

위의 네 가지 목표는 우리가 근복적으로 성취하고자 하는 것에 초점을 맞추는 데는 도움이 되지만, 일상적 업무로 하는 코딩 작업과 관련해서는 특별한 조언을 제공하지는 않는다. 이러한 목표에 부합하는 코드를 작성하는 데 도움이 될 보다 구체적인 전략을 파악하는 것이 유용하다. 코드 품질의 여섯 가지 핵심요소는 아래와 같다.

  1. 코드는 읽기 쉬워야 한다.
  2. 코드는 예측 가능해야 한다.
  3. 코드를 오용하기 어렵게 만들어라.
  4. 코드를 모듈화하라.
  5. 코드를 재사용 가능하고 일반화할 수 있게 작성하라.
  6. 테스트가 용이한 코드를 작성하고, 제대로 테스트하라.

코드는 읽기 쉬어야 한다.

만약 코드의 가독성이 떨어진다면, 다른 개발자가 그 코드를 이애하는 데 많은 시간을 들여야 한다. 또한, 코드의 기능에 대해 잘못 이해하거나, 몇 가지 중요한 세부 사항을 놓칠 가능성 역시 크다. 이런 일이 일어난다면 새로운 기능을 추가하기 위해 다른 개발자가 코드를 수정할 때 새로운 버그가 도입될 가능성이 생긴다. 소프트웨어가 수행하는 모든 일은 그것을 가능하게 하는 어떤 코드에 의해 일어난다. 그 코드가 무엇을 하는지 개발자가 이해하지 못하면, 소프트웨어 전체가 제대로 작동하는 것은 거의 불가능에 가깝다. 코드는 레시피와 마찬가지로 읽을 수 있어야 한다.

코드는 예측 가능해야 한다.

아무리 좋은 의도를 가지고 작성한 코드라 할지라도 예상을 벗어난 동작을 수행하는 위험이 있을 수 있다. 코드가 예상을 벗어난 일을 한다면, 명백하게 이상한 일이 발견되기 전까지 시스템은 계속 비정상적으로 작동할 것이다. 이런 코드는 사소한 오류를 일으킬 수도 있지만, 어떤 경우에는 중요한 데이터가 손상되는 이슈가 발생할 수도 있다. 항상 코드가 예상을 벗어나는 일을 수행하지 않는지 주의 깊게 살펴야 하고, 할 수 있다면 그런 코드를 작성하지 않도록 노력해야 한다.

코드를 오용하기 어렵게 만들어라.

자신이 작성한 코드(특정 인수가 입력되거나 시스템이 특정 상태에 있을 것을 예상하여 작성한 코드는)는 종종 다른 코드에 의해 호출되는데, 자신의 의도와 전혀 무관하게 호출되면 작게는 코드가 작동하지 않겠지만, 크게는 시스템이 작동을 멈추고, 데이터베이스가 영구적으로 손상되거나, 중요한 데이터가 손실될 수 있다. 코드를 작성할 때 오용하기 어렵거나 불가능하게 하면 코드가 지속적으로 잘 작동할 가능성을 극대화 할 수 있다.

코드를 모듈화하라.

소프트웨어 시스템과 코드베이스는 장난감과 매우 유사하다. 코드를 외부에 의존하지 않고 실행할 수 있는 모듈로 나누는 것이 의로울 때가 많다. 이때 두 개의 인접한 모듈 사이의 상호작용은 한 곳에서 일어나고 잘 정의된 인터페이스를 사용한다. 이렇게 하면 변화하는 요구 사항에 더 쉽게 적응할 수 있는 코드를 작성하는 데 도움이 된다.

코드를 재사용 가능하고 일반화할 수 있게 작성하라.

코드가 재사용할 수 있고 일반화되어 있으면 우리는 그 코드를 코드베이스의 여러 부분에서, 그리고 하나 이상의 상황에서 사용할 수 있고, 여러 가지 문제를 해결할 수 있게 된다. 이런 코드는 시간과 노력을 절약해주고 더 신뢰할 수 있는데, 그 이유는 실제 서비스 환경에서 이미 시도되고 테스트된 논리를 재사용하기 때문이다. 즉, 어떤 버그라 할지라도 이미 발견되고 해결되었을 가능성이 크다는 것을 의미한다.

테스트가 용이한 코드를 작성하고, 제대로 테스트하라.

테스트는 프로세스에서 두 가지 핵심 사항에 대한 주된 방어 수단이 될 때가 많다.

  • 버그나 제대로 동작하지 않는 기능을 갖는 코드가 코드베이스에 병합되지 않도록 방지
  • 버그나 제대로 동작하지 않는 기능을 갖는 코드가 배포되지 않도록 막고 서비스 환경에서 실행되지 않도록 방지

테스트는 수동 또는 자동으로 수행된다. 개발자는 일반적으로 테스트 코드를 통해 실제 코드를 둘러보고, 모든 것이 정상적으로 작동하는지 확인하고, 이것을 자동화하기 위해 노력한다. 여러 가지 수준의 테스트가 존제하지만, 가장 흔히 볼 수 있는 테스트는 아래과 같은 세 가지다.

  • 단위 테스트(unit test): 일반적으로 개별 함수나 클래스와 같은 작은 단위의 코드를 테스트한다.
  • 통합 테스트(integration test): 시스템은 일반적으로 여러 구성 요소, 모듈, 하위 시스템으로 구성된다. 이러한 구성 요소와 하위 시스템을 함께 연결하는 과정을 통합이라고한다. 통합 테스트를 통해 여러 구성 요소들이 제대로 작동하고 멈추지 않고 계속 실행하는지 확인할 수 있다.
  • 종단간(end-to-end, E2E) 테스트: 처음부터 끝까지 전체 소프트우어 시스템에서 작동의 흐름(또는 워크플로우)을 테스트한다. 테스트하는 소프트웨어가 온라인 쇼핑몽이라면 웹 브라우저를 자동으로 구동하고 사용자가 구매를 완료하는 데까지 진행할 수 있는지 테스트하는 것이 E2E 테스트의 예이다.

고품질 코드 작성을 일정을 지연시키는가

단기적으로 보면 고품질 코드를 작성하는 데 시간이 더 걸릴 수 있다. 하지만 한번 사용하고 버릴 시스템이 아닌 좀 더 중요한 소프트웨어를 개발하고 있다면, 일반적으로 고품질 코드를 작성하는 것이 중장기적으로는 개발 시간을 단축해준다.


코드 품질을 고려하지 않고 먼저 떠오르는 대로 코딩하면 처음에는 시간을 절약할 수 있다. 그러나 이런 코드는 머지 않아 취약하고 복잡한 코드베이스로 귀결될 것이며, 점점 더 이해하기 어렵고 추론할 수 없는 코드가 된다. 새로운 기능을 추가하거나 버그를 수정하는 것이 점점 더 어려워지고 시간도 더 많이 걸리는데, 이는 작동하지 않는 코드를 처리하고 재설계해야 하기 때문이다.



요약

  • 좋은 소프트웨어를 만들려면 고품질 코드를 작성해야 한다.
  • 실제 서비스 환경에서 실행되는 소프트웨어가 되기 전에 코드는 일반적으로 여러 단계의 검사와 테스트를 통과해야 한다(때로는 수동, 때로는 자동화를 통해).
  • 버그나 제대로 동작하지 않는 가능이 사용자에게 제공되거나, 비지니스에 중요한 시스템에서 실행되는 것을 이러한 검사를 통해 막을 수 있다.
  • 테스트는 코드를 작성하는 모든 단계에서 고려하는 것이 좋다. 코드를 다 작성하고 난 후에 고려하는 것이 아니다.
  • 고품질 코드를 작성하면 처음에는 시간이 오래 걸리지만, 중장기적으로는 개발 시간이 단축되는 경우가 많다.


Reference

톰 롱. 『좋은 코드, 나쁜 코드』. 제이펍, 2022.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/01   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함