C# 정적 변수와 메서드는 문제인가? Derek Comartin이 설명합니다 (비디오 분석)

정적 메서드가 문제가 되는 이유는 무엇일까요?

영상 초반에 데릭은 Is18YearsOrOlder라는 정적 메서드를 자세히 살펴봅니다. 이 메서드는 DateTime 형식의 생년월일을 입력받아 해당 사용자가 18세 이상인지 확인합니다. 현재 날짜와 DateTime.UtcNow를 사용하여 비교합니다. 간단하죠?

하지만 데릭이 지적했듯이, 이 방법은 비결정적입니다. 0:50에서 그는 DateTime.UtcNow를 사용하면 메서드가 실행 시점에 따라 다른 결과를 반환한다는 점을 강조합니다. 이는 유닛 테스트에서 심각한 문제이며 코드에서 예상치 못한 동작을 유발합니다.

이 경우, 해당 메서드는 순수 함수처럼 보이지만 실제로는 순수 함수가 아닙니다. 데릭은 순수 메서드는 동일한 매개변수로 호출될 때마다 항상 동일한 값을 반환해야 한다고 설명합니다. 하지만 여기서는 현재 날짜가 계속 바뀌기 때문에 반환 값도 바뀝니다.

이는 공개 정적 메서드가 편리하긴 하지만, 실시간 데이터나 애플리케이션 도메인 상태에 의존하는 경우 부작용을 초래할 수 있음을 보여줍니다.

정적 메서드를 테스트 가능하고 예측 가능하게 만들기

데릭의 다음 지적은 매우 중요합니다. DateTime.UtcNow에 대한 의존성을 제거하면 비결정성을 해결할 수 있습니다. 대신, 데릭은 정적 클래스 또는 인터페이스 구현을 사용하여 시간 제공자를 주입하는 방법을 보여줍니다. 이렇게 하면 함수가 결정론적이 됩니다. 즉, 동일한 입력을 전달할 때마다 동일한 출력을 얻게 됩니다.

그는 PlaceOrder 클래스에서 금요일에 처리된 주문에 50% 할인이 적용되는지 테스트하기 위해 가짜 날짜 제공자를 도입합니다. 이렇게 하면 시스템 시간에 얽매인 로직을 하드코딩하는 것을 방지하여 메서드의 신뢰성과 테스트 용이성을 높일 수 있습니다.

데릭은 동작을 분리하고 비즈니스 로직 내에서 정적 메서드를 직접 참조하는 것을 피함으로써 테스트 용이성을 유지하면서도 깔끔한 코드를 작성하는 방법을 보여줍니다.

긴밀 결합 및 정적 방법

데릭은 이 시점에서 정적 메서드에 의존하는 것은 종종 강한 결합을 초래한다고 경고합니다. DateTime.UtcNow를 직접 사용하면 해당 구현체에 종속되며, 재정의하거나 모킹할 수 없습니다.

이는 문제가 되는데, 이와 같은 정적 멤버는 애플리케이션 전체에서 전역적으로 사용되기 때문입니다. 코드베이스에서 정적 필드나 정적 속성을 많이 사용하는 경우, 동작을 변경하거나 의존성을 주입하기가 어려워져 객체 지향 프로그래밍의 핵심 원칙을 위반하게 됩니다.

또한 인스턴스 변수나 주입된 서비스처럼 정적 필드를 다른 구현으로 대체할 수 없기 때문에 유연성이 떨어집니다.

정적 변수를 사용하는 전역 상태 문제

이제 데릭은 정적 변수에 초점을 맞추고, 이때부터 대화는 진지해집니다.

그는 Global 클래스에서 정적 캐시를 사용하는 예시를 제시합니다. 그는 정적 변수의 가장 큰 문제는 상태를 알 수 없다는 점이라고 설명합니다. 실행 시점에는 정적 필드가 초기화되었는지 확신할 수 없습니다. 이러한 예측 불가능성은 특히 변경 가능한 정적 정수 또는 문자열 이름이 관련된 경우 위험합니다.

개발자들이 해당 변수의 복사본이 스레드 간에 하나만 공유된다고 가정하고 스레드 안전성을 고려하지 않으면 이러한 상황은 더욱 악화됩니다.

멀티스레드 코드에서의 스레드 안전성 및 정적 필드

데릭은 또 다른 우려 사항을 제기합니다. 바로 멀티스레드 환경에서 정적 변수를 사용하는 것입니다. 그는 정적 리스트의 예를 제시합니다.Parallel.For와 동시에 사용됩니다. 정적 필드가 스레드로부터 안전하지 않기 때문에 코드가 충돌합니다.

이 문제를 해결하기 위해 그는 ConcurrentBag으로 전환합니다..NET 에서 사용할 수 있는 스레드 안전 컬렉션입니다. 이를 통해 여러 스레드에서 정적 데이터에 안전하게 접근할 수 있습니다.

그의 요점은 분명합니다. 스레드 간에 정적 변수를 사용하는 경우 스레드 안전성을 확보해야 한다는 것입니다. 그렇지 않으면 프로그램이 예측할 수 없는 동작을 하거나 심지어 충돌할 수도 있습니다.

정적 방법의 안전한 사용

이어서 데릭은 정적 메서드의 안전하고 효과적인 사용법, 즉 간단한 유틸리티 메서드인 MilesToKilometers를 소개합니다. 이 함수는 정수형 마일을 입력받아 변환 후 실수형 값을 반환합니다. 이 방법은 결정론적입니다. 즉, 동일한 정수 값을 입력하면 항상 동일한 결과가 나옵니다.

이러한 방식은 비정적 필드에 의존하지 않고, 공유 데이터를 변경하지 않으며, 알려지지 않은 상태를 포함하지 않습니다. 이는 C#에서 static 키워드를 올바르게 사용하는 방법을 보여주는 훌륭한 예입니다.

.NET 환경에서 정적(Static)의 의미 이해하기

C#에서 static 키워드는 클래스, 필드, 메서드, 생성자 및 속성에 적용할 수 있습니다. 데릭은 간접적으로 다음과 같은 개념을 언급합니다:

• 정적 클래스: 인스턴스를 생성할 수 없으며 정적 멤버만 포함할 수 있는 클래스입니다.

• 정적 필드: static 키워드로 선언됨 - 애플리케이션 도메인당 하나의 복사본만 존재합니다.

• 정적 생성자: 클래스에 처음 접근할 때 한 번만 실행됩니다.

• 정적 void Main: 대부분의 C# 애플리케이션의 진입점으로, 정적 메서드가 얼마나 중요한지 보여주는 예입니다.

• 정적 정수, 정적 문자열: 클래스의 모든 인스턴스에 공통된 데이터를 저장하거나, 실제로 인스턴스가 전혀 필요하지 않은 정적 필드의 예입니다.

객체를 생성할 때마다 실행되는 인스턴스 생성자와 달리 정적 생성자는 클래스 수준 리소스를 한 번만 초기화합니다.

이러한 구분은 개발자가 인스턴스 변수와 정적 변수를 언제 사용해야 하는지, 또는 공유 멤버 변수를 캡슐화하기 위해 속성 접근자를 언제 사용해야 하는지를 결정하는 데 도움이 됩니다.

데릭의 최종 요약

데릭은 개발자들이 정적 멤버 사용에 주의를 기울여야 하는 주요 이유를 다음과 같이 요약합니다.

• 강한 결합 — 해당 정적 메서드 또는 필드의 동작 방식에 고정됩니다.

• 비결정적 동작 — 테스트하기 어렵고, 오류 발생 가능성이 높습니다.

• 전역적으로 변경 가능한 상태 — 값이 무엇인지, 누가 변경했는지 알 수 없습니다.

• 동시성 문제 — 멀티스레드 코드에서 공유 데이터에 대한 안전하지 않은 접근.

하지만 데릭이 말했듯이, 잡음 자체가 나쁜 것은 아닙니다. 올바르게 사용하면 매우 강력한 효과를 발휘합니다. 특히 유틸리티 함수, 공유 상수 또는 전역 설정에서 유용합니다. 상태를 신중하게 관리하고 변경 가능한 동작이나 시스템별 동작에 의존하지 않도록 하면 됩니다.

결론

C#에서 정적 변수와 메서드는 양날의 검과 같습니다. 데릭 코마틴이 명확하게 설명했듯이, 그것들이 본질적으로 나쁜 것은 아니지만, 신중한 사용이 필요합니다. 객체의 상태에 의존하지 않는 공유 데이터나 기능이 필요할 때는 정적 필드와 정적 클래스를 사용하십시오. 하지만 시간, 시스템 상태에 따라 달라지거나 유연성이 요구되는 경우에는 사용을 피하십시오.

따라서 객체를 생성하거나 정적 필드에 접근하기 전에 범위, 테스트 용이성, 스레드 안전성, 그리고 코드가 단일 복사본을 필요로 하는지 아니면 여러 인스턴스를 필요로 하는지를 고려해야 합니다.

데릭 마틴의 전체 영상은 그의 CodeOpinion 유튜브 채널 에서 시청하실 수 있습니다. 클린 아키텍처, 소프트웨어 설계 및 실제 C# 애플리케이션에 대한 더 많은 정보를 찾을 수 있습니다.