C#은 기업 환경과 현장 도구 개발에서 생각보다 폭이 넓다

어디에서 기본값인가

C#을 고를지 말지는 언어의 문법을 비교해서 정해지는 일이 드뭅니다. 대개 이미 정해져 있습니다. 사내 인증이 Windows 도메인에 묶여 있거나, 기존 업무 시스템이 .NET으로 굴러가고 있거나, Office 문서와 사내 데이터베이스를 오가는 도구를 만들어야 하는 상황이라면 다른 선택지가 오히려 번거롭습니다. 게임 쪽에서 Unity를 쓰는 팀도 사실상 C#으로 일하게 됩니다.

반대로 말하면 이 조건 밖에서는 C#이 자동으로 유리하지 않습니다. .NET 런타임은 여러 운영체제에서 돌아가고 서버 애플리케이션을 리눅스 컨테이너에 올리는 일도 평범해졌지만, 데스크톱 UI 스택 일부는 여전히 Windows에 묶여 있습니다. “.NET은 이제 크로스 플랫폼”이라는 말과 “내가 만들려는 것이 크로스 플랫폼”이라는 말은 다릅니다. 만들 대상이 무엇인지부터 확인하는 편이 빠릅니다.

또 하나 현실적인 부분은 주변 생태계의 무게입니다. 데이터 접근은 대개 EF Core 같은 ORM을 통해 이뤄지고, 웹은 ASP.NET Core의 관례를 따릅니다. C#을 배운다는 것은 실무에서는 이 두 축을 배운다는 뜻에 가깝습니다.

LINQ가 바꾸는 코드 읽기

다른 언어에서 온 사람이 C# 코드를 읽을 때 가장 먼저 걸리는 지점이 LINQ입니다. 컬렉션을 다루는 문법이 SQL과 닮아 있어서 처음에는 반갑지만, 동작 방식이 예상과 다릅니다. 질의를 만든 시점에는 아무 일도 일어나지 않습니다. 결과를 실제로 훑는 순간에야 계산이 진행됩니다.

이 지연 실행 때문에 생기는 사고가 몇 가지 있습니다. 질의를 만들어 두고 원본 컬렉션을 바꾼 뒤 결과를 꺼내면 예상과 다른 값이 나옵니다. 같은 질의를 두 번 훑으면 계산도 두 번 돌아갑니다. 데이터베이스를 대상으로 하는 질의라면 어디까지가 SQL로 번역되고 어디부터 메모리에서 처리되는지가 성능을 가릅니다. 이 경계를 모르는 채로 쓰면 목록 화면 하나가 조용히 전체 테이블을 끌어옵니다. 결과가 확정되어야 하는 자리에서는 리스트나 배열로 한 번 굳혀 두는 습관이 안전합니다. 함수형 스타일 가이드와 언어별 리스트 처리 비교가 도움이 됩니다.

async/await의 원조가 남긴 함정

지금은 여러 언어에서 익숙해진 async/await 문법은 C#에서 널리 퍼진 형태입니다. 오래 쓰인 만큼 함정도 잘 알려져 있습니다.

첫째, 비동기 메서드를 동기적으로 기다리는 코드는 상황에 따라 교착으로 이어질 수 있습니다. UI나 일부 호스팅 환경에서는 완료 후 돌아갈 실행 맥락이 정해져 있는데, 그 맥락이 이미 대기 중이면 서로를 기다리게 됩니다. 라이브러리 코드에서 맥락 복원이 필요 없다고 명시해 두는 관례가 생긴 이유입니다.

둘째, 반환값을 기다리지 않고 흘려보낸 비동기 호출은 예외가 조용히 사라집니다. 이벤트 처리기를 제외하면 결과를 받아 두는 편이 맞습니다. 셋째, 비동기는 동시성을 만들어 주지만 병렬 처리와는 다릅니다. CPU를 오래 쓰는 계산을 await로 감싼다고 빨라지지 않습니다.

값 타입과 참조 타입의 구분도 다른 언어에서 온 사람이 자주 놓치는 부분입니다. 구조체는 대입할 때 복사되고, 클래스는 참조가 복사됩니다. 큰 구조체를 무심코 주고받으면 복사 비용이 쌓입니다. 반대로 할당을 줄여야 하는 코드에서는 연속된 메모리를 그대로 바라보는 Span<T> 계열 타입이 쓰입니다. 널 가능 참조 타입 기능도 이름과 달리 실행 시점의 보장이 아니라 컴파일러의 경고 체계입니다. 경고를 끄면 그대로 통과합니다.

dotnet 한 줄로 도는 작업 흐름

위 예제에서 record를 쓴 이유는 이 값이 한 번 만들어진 뒤 바뀌지 않는 측정치이기 때문입니다. 교대조 지표처럼 여러 화면과 알림 규칙이 함께 읽는 데이터는 도중에 값이 바뀌지 않는다는 보장이 있을 때 추적이 쉬워집니다. 위치 기반 생성자로 필드가 한눈에 드러나므로 화면이 무엇을 표시하는지도 타입 선언만 보고 파악됩니다.

도구 쪽은 명령 하나로 대부분이 해결되는 편입니다. 프로젝트를 만들고, 패키지를 추가하고, 빌드하고, 테스트를 돌리고, 배포용 결과물을 만드는 일이 전부 같은 CLI 아래 있습니다. 실무에서 반복되는 순서는 대체로 이렇습니다.

1. 프로젝트를 만들고 패키지를 추가합니다. 의존성은 NuGet에서 오고, 버전 고정 방식을 팀 규칙으로 정해 둡니다.
2. 테스트 프로젝트를 처음부터 붙입니다. xUnit이나 NUnit 중 하나면 충분하고, 데이터 접근이 얽히면 실제 데이터베이스를 띄운 통합 테스트를 별도 범주로 나눕니다.
3. 분석기와 경고 수준을 먼저 정합니다. 널 가능 참조 타입 경고를 오류로 승격할지 여부가 이후 코드의 성격을 크게 바꿉니다.
4. 데이터베이스 변경은 마이그레이션 파일로 남기고, 생성된 SQL을 사람이 한 번 읽는 절차를 둡니다.
5. 배포 결과물은 런타임을 포함할지 여부를 정해 만듭니다. 대상 서버 환경을 통제할 수 없다면 포함하는 쪽이 편합니다.

주제별로는 비동기 처리, 컬렉션, 테스트 순서가 무난하고, 예제로 익히려면 C# 학습 라이브러리에서 시작하시면 됩니다.

선택을 미뤄야 할 때

• 목표하는 조직이나 제품이 이미 .NET 위에 있습니까. 이 경우 학습 대비 회수가 가장 확실합니다.
• Unity로 게임이나 인터랙티브 콘텐츠를 만들 계획이 있습니까. 엔진이 언어를 정해 줍니다.
• 업무 자동화나 사내 도구를 만드는 자리에 있습니까. 데스크톱과 서버, 데이터베이스 연동을 한 언어로 묶기 좋습니다.
• 웹 프런트엔드나 데이터 분석이 목표라면 그 영역의 주력 언어가 먼저입니다. 지금은 아닙니다.
• 이미 Java로 서버를 다루고 있고 특별히 .NET 환경에 들어갈 계획이 없다면, 두 언어의 사고방식이 비슷해 얻는 것이 적습니다. 지금은 아닙니다. 차이가 궁금하다면 언어 비교를 훑는 정도로 충분합니다.