[SQL] SELECT와 PRINT

회사에서 프로시저 디버깅 중
같은 파라미터 값을 PRINT와 SELECT로 출력했는데 결과가 달랐던 경험이 있었다.

놀랍게도

• PRINT로 출력한 값은 정상
• SELECT로 출력한 값은 일부가 잘려 다른 값으로 나왔다

결론부터 말하면 원인은 MSSQL의 암묵적 타입 변환(Data Type Precedence) 이다.

---

1. 문제 상황

다음과 같이 하나의 파라미터 값을 출력했다.

DECLARE @score DECIMAL(10,4) = 123.4567

PRINT @score
SELECT @score AS score

처음에는 둘 다 같아 보여서 문제 없어 보였다.

그런데 실제 문제는 문자열과 함께 출력하려고 할 때 발생했다.

---

2. 이상한 현상 발생

DECLARE @score DECIMAL(10,4) = 123.4567

PRINT 'score = ' + CAST(@score AS VARCHAR(20))
SELECT 'score = ' + @score AS score

결과

• PRINT
  → score = 123.4567 ✅ (정상)

• SELECT
  → score = 123 ❌ (소수점 손실)

같은 파라미터인데 결과가 다르다.

---

3. 왜 이런 일이 발생했을까?

핵심 원인: MSSQL 데이터 타입 우선순위

MSSQL은 서로 다른 타입을 연산할 때
우선순위가 높은 타입으로 변환한다.

• DECIMAL > VARCHAR
• 숫자 타입 > 문자열 타입

즉, 아래 코드에서:

SELECT 'score = ' + @score

MSSQL은 내부적으로 이렇게 처리한다.

SELECT CAST('score = ' AS DECIMAL) + @score

결과적으로

• 문자열이 숫자로 변환
• 소수점 정밀도 손실 발생
• 의도하지 않은 결과 출력

---

4. PRINT는 왜 정상일까?

PRINT는 내부적으로
NVARCHAR(4000)으로 암묵적 변환을 수행한다.

즉, 다음과 같은 처리에 가깝다.

PRINT CAST(@score AS NVARCHAR)

그래서:

• 타입 충돌 없음
• 정밀도 유지
• 사람이 보는 로그 기준으로는 정확하게 출력됨

👉 그래서 PRINT는 맞고 SELECT는 틀려 보이는 현상이 발생한 것

---

5. 재현 예제 (정확한 비교)

잘못된 SELECT (문제 발생)

SELECT 'value = ' + @score

올바른 SELECT (명시적 변환)

SELECT 'value = ' + CAST(@score AS VARCHAR(20))

또는

SELECT CONCAT('value = ', @score)

👉 CONCAT은 내부적으로 문자열 변환을 안전하게 처리함

---

6. 실무에서 주의할 점

• PRINT 결과만 믿고 로직을 판단하면 위험
• SELECT에서 문자열 + 파라미터 사용 시
  • 반드시 명시적 CAST
  • 또는 CONCAT() 사용
• 숫자, 날짜, DECIMAL은 특히 주의

---

8. 정리

• PRINT는 로그 친화적
• SELECT는 데이터 타입에 매우 엄격
• MSSQL은 암묵적 변환을 “조용히” 수행한다

PRINT가 맞고
SELECT가 틀릴 수 있다
→ 문제는 SELECT가 아니라 타입 처리

실무에서는
명시적 CAST를 습관화하는 게 가장 안전한 방법이다.