온도 변환 공식: 섭씨, 화씨, 켈빈 온라인 가이드

월요일에 날씨 대시보드를 출시했습니다. 수요일에 토론토에 있는 사용자가 앱이 외부 기온을 284로 표시한다고 보고합니다. OpenWeatherMap 엔드포인트가 켈빈(기본값)을 반환했고 UI는 섭씨를 기대했는데, 그 사이의 어떤 코드도 이를 점검하지 않았습니다. 빠뜨린 뺄셈 한 번이 트위터에 박제되는 스크린샷이 됩니다.

두 공식만 빠르게 확인하고 넘어가시려면 다음과 같습니다.

• 섭씨에서 화씨 변환 공식: °F = °C × 9/5 + 32
• 화씨에서 섭씨 변환 공식: °C = (°F − 32) × 5/9
• 섭씨에서 켈빈 변환: K = °C + 273.15

이 세 가지가 개발자가 실제로 필요로 하는 것의 약 90%를 처리합니다. 나머지 10%, 즉 9/5가 어디에서 오는지, 켈빈이 왜 음수가 되지 않는지, 타입 시스템이 컴파일 시점에 celsiusToFahrenheit(kelvinValue)를 거부하게 만드는 방법, 토론토 버그를 출시하지 않는 방법을 아래에서 다룹니다. 숫자만 필요하면 온도 변환기를 쓰고 본문은 건너뛰어도 됩니다. 온도 외 단위는 단위 변환 완벽 가이드를 참고하세요.

온도가 다른 단위 변환과 다른 이유

대부분의 단위 변환은 0을 통과하는 단순 비례 관계입니다. 1미터는 3.28084피트, 그것으로 끝. 미터 값을 두 배로 하면 피트 값도 두 배, 0미터는 0피트입니다. 단위 쌍마다 곱셈 상수 하나만 두면 변환 라이브러리가 완성됩니다.

온도는 이 모델을 깨뜨립니다. 척도들이 영점을 공유하지 않기 때문입니다. 섭씨는 물의 어는점에 0을 두고, 화씨는 1724년경의 소금물 혼합물에 0을 두며, 켈빈은 열역학적 하한에 0을 둡니다. 두 척도 사이를 오가려면 비례 인자와 오프셋이 모두 필요합니다. 온도는 선형이 아니라 아핀(affine) 변환입니다.

여기서 위험한 결과가 따라옵니다. 온도 값은 길이나 질량처럼 더할 수 없습니다. 20°C + 20°C는 어떤 물리적 의미로도 40°C가 아닙니다. 두 방을 “더해서” 더 따뜻한 방을 만들 수는 없습니다. 온도 차이는 더할 수 있는데, 차이는 선형이기 때문입니다. 2006년 영국 메데바(Medeva) 백신 사건이 바로 이 구분에서 어긋났습니다. 의약품 콜드체인 로거가 절댓값과 변화량을 혼동하면서 수천 회분이 규격 외로 표시됐습니다. 온도 같은 강도성(intensive) 양에는 이런 가드레일이 필요합니다.

네 가지 온도 척도

일상 코드에서 중요한 척도는 두 가지(섭씨, 화씨)이고, 과학 분야에서 세 번째(켈빈)가 추가됩니다. 네 번째는 한 곳에서만 등장합니다. 미국 열역학 교과서와 거기에 의존하는 HVAC 코드베이스입니다.

섭씨 (°C)

안데르스 셀시우스(Anders Celsius)는 1742년에 자신의 척도를 발표했는데, 원래는 0°가 끓는점, 100°가 어는점으로 지금과 정반대였습니다. 0°C가 표준 1기압에서 물의 어는점, 100°C가 끓는점이 되는 현재 방향은 그가 사망한 직후에 정착됐습니다. 오늘날 섭씨는 일상 온도용 SI 유도 단위이며, 미국, 바하마, 벨리즈, 케이맨 제도, 라이베리아를 제외한 모든 국가에서 기본 척도입니다.

2019년 SI 재정의는 섭씨를 켈빈에 엄밀하게 묶었습니다. 0°C는 이제 정확히 273.15 K로 정의됩니다. 한때 정의 기준이던 물의 어는점은 이제 측정 결과입니다(0°C에 백만분의 몇 단위로 가깝지만 더 이상 기준점은 아닙니다).

화씨 (°F)

다니엘 가브리엘 파렌하이트(Daniel Gabriel Fahrenheit)는 1724년에 자신의 척도를 제안했습니다. 그는 단치히의 겨울에 안정적으로 재현할 수 있던 가장 낮은 온도, 즉 특정 소금물 혼합물의 어는점을 0°F로 잡았고, 체온을 96°F로 잡았습니다. 이후 순수한 물의 어는점과 끓는점에 맞춰 재보정하면서 체온은 98.6°F로, 어는점은 32°F, 끓는점은 212°F로 자리 잡았고, 그 사이는 180도가 되었습니다.

화씨는 미국에서 날씨, 요리, 의료용으로 살아남았습니다. 어는점에서 끓는점까지 180도 폭(섭씨 100도 대비)은 “주변 기온에 더 세밀한 해상도를 제공한다”는 명분으로 옹호되곤 합니다. 빈약한 주장이지만, 미국 온도 조절기가 1°F 단위로 표시되고 유럽은 0.5°C 단위를 쓰는 이유를 설명해 줍니다.

켈빈 (K)

윌리엄 톰슨, 켈빈 경(Lord Kelvin)이 1848년에 절대 척도를 제안했습니다. 오늘날 켈빈은 SI 온도 기본 단위입니다. 2019년 SI 재정의는 켈빈을 볼츠만 상수 k_B = 1.380649 × 10⁻²³ J/K에 정확히 묶어 측정량이 아니라 정의된 양으로 만들었습니다.

개발자가 알아 두면 좋은 켈빈의 특이점이 세 가지 있습니다.

1. 도(°) 기호 없음. 300 K로 쓰고, 300°K로 쓰지 마세요. 1967년 이후 SI 표준 표기입니다.
2. 절대영도에서 시작. 0 K = −273.15°C. 유효한 데이터에서 음수 켈빈 값은 절대 보여서는 안 되며, 보인다면 입력 오류로 처리하세요.
3. 섭씨와 같은 도 크기. 1 K의 변화는 1°C의 변화와 같습니다. 온도 차이는 두 단위 사이에서 호환 가능하며, 절댓값만 273.15만큼 차이 납니다.

온도를 곱하거나 나누는 모든 상황(열복사 T⁴, 이상기체 법칙, 흑체 물리)에서는 켈빈이 옳은 선택입니다. 음수나 0에 가까운 섭씨 값으로 나누면 유한하게 유지해야 할 물리량이 발산합니다.

랭킨 (°R)

윌리엄 랭킨(William Rankine)은 1859년에 켈빈에 대응하는 화씨 버전 척도를 제안했습니다. 절대 척도이고, 영점이 절대영도에 있지만, 도 크기는 화씨와 같습니다. 0°R = −459.67°F, 491.67°R = 0°C입니다.

랭킨은 미국 열역학 공학(HVAC 계산, 석유 정제, 로켓 엔진 연소 분석) 외에서는 거의 마주치지 않습니다. 이 분야는 절대 척도가 필요한 계산을 다루지만 입력 데이터가 화씨로 들어옵니다. 변환은 기계적입니다. °R = °F + 459.67, 또는 °R = K × 9/5. 선택의 여지가 있다면 내부에서 켈빈을 유지하다가 표시할 때만 변환하는 쪽을 권장합니다.

온도 변환 공식 (여섯 방향 전체)

여섯 방향, 네 척도, 여섯 공식. 실무에서는 섭씨를 중심으로 한 공식을 외우고 나머지는 조합해서 쓰면 됩니다.

섭씨와 화씨 사이

°F = °C × 9/5 + 32
°C = (°F − 32) × 5/9

9/5 인자는 동일한 두 물리적 기준점 사이에서 두 척도의 폭의 비입니다. 어는점에서 끓는점까지 화씨는 180도(32에서 212까지), 섭씨는 100도(0에서 100까지)를 덮습니다. 180 / 100 = 9/5 = 1.8입니다. + 32는 어는점의 영점을 맞추기 위한 오프셋입니다. 화씨의 영점이 섭씨의 영점보다 32°F 아래에 있기 때문입니다.

계산 예시: °F = 25 × 9/5 + 32 = 45 + 32 = 77°F.

섭씨와 켈빈 사이

K = °C + 273.15
°C = K − 273.15

비례 인자 없이 오프셋만 있습니다. 273.15는 섭씨의 영점(물의 어는점)에서 절대영도까지의 수치적 거리를, 섭씨 도 단위로 측정한 값입니다. 켈빈과 섭씨가 도 크기를 공유하므로 곱셈 인자는 없습니다.

화씨와 켈빈 사이

K = (°F − 32) × 5/9 + 273.15
°F = (K − 273.15) × 9/5 + 32

더 짧은 형태는 없습니다. 비례와 오프셋 변경이 모두 필요하기 때문입니다. 코드에서는 섭씨를 거치는 편이 깔끔합니다. k = cToK(fToC(f)). 코드가 짧아지고 신뢰가 커지며, 컴파일러가 합성을 최적화해 줍니다.

랭킨 변환

°R = °F + 459.67
°F = °R − 459.67
°R = K × 9/5
K  = °R × 5/9
°R = °C × 9/5 + 491.67

491.67은 32 × 9/5 + 459.67, 즉 0°C에 해당하는 랭킨 값입니다. 이 공식들을 직접 조합할 일은 드뭅니다. 랭킨이 필요하면 “화씨의 절대 짝”으로 보고 화씨나 켈빈을 거치세요.

9/5는 어디에서 오는가? 간단한 유도

두 척도는 아핀 함수 °F = a × °C + b로 연결됩니다. a와 b를 풀려면 알려진 보정점 두 개가 필요합니다. 어는점과 끓는점이 관습적으로 쓰는 한 쌍입니다.

• 어는점: 0°C ↔ 32°F
• 끓는점: 100°C ↔ 212°F

두 점을 모두 °F = a × °C + b에 대입합니다.

32  = a × 0   + b   →  b = 32
212 = a × 100 + 32  →  a = (212 − 32) / 100 = 180 / 100 = 9/5

두 개의 일차방정식, 두 개의 미지수, 변환 전체가 떨어집니다. 기하학적 직관을 덧붙이면, 섭씨와 화씨 두 온도계를 나란히 두었을 때 화씨 온도계는 섭씨에 비해 수직으로 늘어나고(기울기 9/5) 위로 이동된(절편 32) 모양입니다. 다른 모든 변환 값이 그 직선 위에 놓입니다.

같은 유도를 (0°C, 273.15 K)와 (100°C, 373.15 K)에 적용하면 섭씨-켈빈 변환이 나옵니다. 기울기 1, 절편 273.15. 두 보정점만 있으면 어떤 아핀 변환도 같은 방식으로 유도할 수 있습니다. 수학적으로 온도에 특별한 점은 없고, 복잡함은 다른 단위 유형에는 없는 두 기준점 설정에서 옵니다.

−40° 교차점: 유용한 암기법

섭씨와 화씨가 같은 값을 가리키는 온도가 있을까요? 변환 공식에서 °C = °F를 두면 됩니다.

°C = °C × 9/5 + 32
°C − °C × 9/5 = 32
°C × (1 − 9/5) = 32
°C × (−4/5) = 32
°C = −40

따라서 −40°C = −40°F. 정확히 한 점에서 교차하며, 옐로나이프, 야쿠츠크, 페어뱅크스의 1월에 실제로 만날 수 있는 온도입니다. 점검 도구로도 유용합니다. C↔F 변환을 어림하다 결과가 −40 부근이면 두 숫자가 서로 가까워야 합니다. 한쪽이 −40°C인데 다른 쪽이 −72°F라면 변환 방향에 버그가 있다는 뜻입니다.

저는 모니터 옆에 다섯 점을 붙여 둡니다. 어는점(0 / 32), 체온(37 / 98.6), 실온(20 / 68), 끓는점(100 / 212), −40(−40 / −40). 필요한 온전성 점검의 대부분을 덮습니다.

코드로 보는 온도 변환

공식 자체는 사소합니다. 실제 코드베이스에서 올바르게 동작하게 만들려면 두 가지가 필요합니다. 호출자가 섭씨 자리에 화씨를 넘기지 못하게 막기, 그리고 경계점(어는점, 절대영도, 오븐 온도)에서 부동소수점 동작을 예측 가능하게 하기. 아래 모든 예제는 그대로 실행 가능한 프로그램입니다.

JavaScript / TypeScript

평범한 자바스크립트로도 함수형 변환을 곧장 만들 수 있습니다.

const cToF = (c) => c * 9 / 5 + 32;
const fToC = (f) => (f - 32) * 5 / 9;
const cToK = (c) => c + 273.15;
const kToC = (k) => k - 273.15;
const fToK = (f) => cToK(fToC(f));
const kToF = (k) => cToF(kToC(k));
const cToR = (c) => (c + 273.15) * 9 / 5;
const rToC = (r) => r * 5 / 9 - 273.15;

console.log(cToF(100));   // 212
console.log(fToC(98.6));  // 37
console.log(kToC(300));   // 26.85

타입스크립트에서는 number 타입에 브랜드를 붙여 단위 혼동을 컴파일 오류로 만들 수 있습니다.

type Scale = 'C' | 'F' | 'K' | 'R';
type Temp<S extends Scale> = number & { readonly __scale: S };

const t = <S extends Scale>(value: number, _scale: S): Temp<S> =>
  value as Temp<S>;

const cToF = (c: Temp<'C'>): Temp<'F'> => t(c * 9 / 5 + 32, 'F');
const fToC = (f: Temp<'F'>): Temp<'C'> => t((f - 32) * 5 / 9, 'C');

const indoor = t(22, 'C');
const outdoor = cToF(indoor);   // OK: Temp<'F'>
// const broken = cToF(outdoor); // Compile error: Temp<'F'> is not Temp<'C'>

브랜드 타입은 런타임 비용이 0이고 보일러플레이트는 10줄 정도입니다. 그 대가로 첫 단락의 토론토 버그가 에디터에서 빨간 물결선이 됩니다.

Python

평범한 함수도 괜찮지만 Enum과 dataclass 조합은 온도를 로깅하는 순간 본전을 뽑습니다.

from dataclasses import dataclass
from enum import Enum

class Scale(Enum):
    C = "°C"
    F = "°F"
    K = "K"
    R = "°R"

@dataclass(frozen=True)
class Temperature:
    value: float
    scale: Scale

    def to(self, target: Scale) -> "Temperature":
        c = _to_celsius(self)
        return _from_celsius(c, target)

    def __str__(self) -> str:
        return f"{self.value:.2f}{self.scale.value}"

def _to_celsius(t: Temperature) -> float:
    if t.scale is Scale.C: return t.value
    if t.scale is Scale.F: return (t.value - 32) * 5 / 9
    if t.scale is Scale.K: return t.value - 273.15
    if t.scale is Scale.R: return (t.value - 491.67) * 5 / 9
    raise ValueError(f"Unknown scale: {t.scale}")

def _from_celsius(c: float, scale: Scale) -> Temperature:
    if scale is Scale.C: return Temperature(c, scale)
    if scale is Scale.F: return Temperature(c * 9 / 5 + 32, scale)
    if scale is Scale.K: return Temperature(c + 273.15, scale)
    if scale is Scale.R: return Temperature(c * 9 / 5 + 491.67, scale)
    raise ValueError(f"Unknown scale: {scale}")

body = Temperature(37, Scale.C)
print(body.to(Scale.F))   # 98.60°F
print(body.to(Scale.K))   # 310.15K

0.1 + 0.2 != 0.3이 감사 이슈가 되는 과학 데이터 처리라면 float을 decimal.Decimal로 바꾸세요. 단점은 속도(Decimal은 약 50배 느림)와 5/9도 정확한 십진 표현이 없다는 점입니다. 제어된 컨텍스트에서 Decimal(5) / Decimal(9) 형태가 필요합니다. 대부분의 센서 파이프라인은 float과 표시 경계의 round(value, 2)로도 충분합니다.

Go

Go의 타입 시스템은 타입스크립트보다 한 걸음 더 갑니다. 명명된 float64 타입은 같은 런타임 표현을 공유하더라도 다른 명명된 float64 타입과 조용히 섞일 수 없습니다.

package main

import "fmt"

type Celsius float64
type Fahrenheit float64
type Kelvin float64
type Rankine float64

func (c Celsius) ToFahrenheit() Fahrenheit { return Fahrenheit(c*9/5 + 32) }
func (c Celsius) ToKelvin() Kelvin         { return Kelvin(c + 273.15) }
func (f Fahrenheit) ToCelsius() Celsius    { return Celsius((f - 32) * 5 / 9) }
func (k Kelvin) ToCelsius() Celsius        { return Celsius(k - 273.15) }
func (f Fahrenheit) ToKelvin() Kelvin      { return f.ToCelsius().ToKelvin() }

func main() {
    room := Celsius(22)
    fmt.Printf("%.2f °F\n", room.ToFahrenheit()) // 71.60 °F
    fmt.Printf("%.2f K\n", room.ToKelvin())      // 295.15 K

    // var bug Fahrenheit = room          // compile error
    // fmt.Println(room.ToKelvin() + 1)   // compile error: Kelvin + untyped int needs Kelvin(1)
}

비용은 척도당 한 줄 정도입니다. 대신 ToFahrenheit가 켈빈 값을 실수로 받지 않고, Celsius를 받는 함수가 호출 지점에서 원시 float64를 거부합니다.

Rust

Rust의 newtype 패턴은 Go와 같은 보장을 주면서, 값싼 From/Into 변환까지 함께 지원합니다.

#[derive(Clone, Copy, Debug, PartialEq)]
struct Celsius(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Fahrenheit(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Kelvin(f64);

impl From<Celsius> for Fahrenheit {
    fn from(c: Celsius) -> Self { Fahrenheit(c.0 * 9.0 / 5.0 + 32.0) }
}

impl From<Fahrenheit> for Celsius {
    fn from(f: Fahrenheit) -> Self { Celsius((f.0 - 32.0) * 5.0 / 9.0) }
}

impl From<Celsius> for Kelvin {
    fn from(c: Celsius) -> Self { Kelvin(c.0 + 273.15) }
}

impl From<Kelvin> for Celsius {
    fn from(k: Kelvin) -> Self { Celsius(k.0 - 273.15) }
}

fn main() {
    let body = Celsius(37.0);
    let body_f: Fahrenheit = body.into();
    let body_k: Kelvin = body.into();
    println!("{:.2} {:?} {:?}", body.0, body_f, body_k);
    // 37.00 Fahrenheit(98.6) Kelvin(310.15)
}

그 위에 검증을 한 층 얹을 수도 있습니다. 음수 값을 거부하는 TryFrom<f64> for Kelvin은 Result<Kelvin, TemperatureError>를 반환하고 점검을 생성 시점으로 끌어올립니다. 잘못된 상태가 비즈니스 로직까지 닿지 않습니다.

SQL (PostgreSQL)

CHECK 제약과 함께 온도를 저장하고 다른 단위는 생성 컬럼으로 유도하세요. 그러면 음수 켈빈 값은 삽입 시점의 제약 위반이지, 세 쿼리 뒤에서 드러나는 데이터 버그가 아닙니다.

CREATE OR REPLACE FUNCTION c_to_f(c numeric) RETURNS numeric AS $$
    SELECT c * 9.0 / 5.0 + 32.0;
$$ LANGUAGE SQL IMMUTABLE;

CREATE OR REPLACE FUNCTION c_to_k(c numeric) RETURNS numeric AS $$
    SELECT c + 273.15;
$$ LANGUAGE SQL IMMUTABLE;

CREATE TABLE sensor_readings (
    id          bigserial PRIMARY KEY,
    recorded_at timestamptz NOT NULL DEFAULT now(),
    celsius     numeric(6, 2) NOT NULL,
    fahrenheit  numeric(6, 2) GENERATED ALWAYS AS (c_to_f(celsius)) STORED,
    kelvin      numeric(6, 2) GENERATED ALWAYS AS (c_to_k(celsius)) STORED,
    CONSTRAINT  kelvin_non_negative CHECK (celsius >= -273.15)
);

INSERT INTO sensor_readings (celsius) VALUES (22.5), (0), (100);
SELECT celsius, fahrenheit, kelvin FROM sensor_readings;
-- 22.50 | 72.50  | 295.65
--  0.00 | 32.00  | 273.15
-- 100.00| 212.00 | 373.15

-- Rejected at insert time:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED는 디스크를 조금 내주는 대신 쿼리 시점 속도를 얻습니다. 값을 읽을 뿐 다시 계산하지 않기 때문입니다. 대용량 IoT 테이블에서 디스크 압박이 읽기 지연보다 크다면 STORED를 뷰로 바꾸세요.

날씨 및 IoT API 다루기

운영 환경에서 가장 자주 발생하는 온도 버그는 공식 오류가 아니라 API 반환 단위와 UI 표시 단위의 불일치입니다. 대부분의 개발자가 마주치는 제공 업체를 정리하면 다음과 같습니다.

OpenWeatherMap은 기본값으로 켈빈을 반환합니다. 섭씨를 받으려면 units=metric, 화씨를 받으려면 units=imperial을 전달하세요. 쿼리 매개변수를 빠뜨리면 켈빈이 옵니다. temp라는 필드에 284.15 같은 숫자가 도착해서 충분히 많은 엔지니어를 속였기 때문에, 통합 테스트로 확인할 만한 가치가 있습니다.

Open-Meteo는 기본값으로 섭씨를 반환하며 temperature_unit=fahrenheit를 받습니다. 켈빈 옵션은 없습니다. 과학용 API가 아니기 때문입니다.

Tomorrow.io와 WeatherAPI는 미터법을 기본으로 하지만, 같은 응답에서 서로 다른 키 아래 두 척도를 모두 반환합니다. 이웃한 키가 아니라 코드가 실제로 참조하는 키를 읽으세요.

날씨나 센서 수집에 제가 쓰는 패턴은 다음과 같습니다.

type Reading = {
  value: number;
  scale: 'C' | 'F' | 'K';
  source: string;
};

function normalise(raw: Reading): number /* celsius */ {
  switch (raw.scale) {
    case 'C': return raw.value;
    case 'F': return (raw.value - 32) * 5 / 9;
    case 'K': return raw.value - 273.15;
  }
}

// At ingestion, every reading carries its scale explicitly.
// The UI layer never guesses — it consumes celsius and formats per user preference.

여기에서 두 가지 규칙이 따라옵니다.

1. 모든 수집 경계는 원본 척도를 기록합니다. 모듈 경계를 넘는 무단위 숫자는 없습니다.
2. 변환은 표시 계층 한 곳에서만 사용자 선호 단위로 일어납니다.

이중 변환, 즉 두 계층이 각각 숫자를 “정규화”하는 경우도 자주 나오는 버그입니다. 백엔드 팀이 쓰기 시점에 켈빈을 섭씨로 변환합니다. 그 사실을 모르는 프런트엔드 팀이 읽기 시점에 같은 - 273.15를 적용합니다. 사용자는 −251°C 부근의 온도를 봅니다. 해법은 더 많은 테스트가 아니라 정규화의 단일 책임자를 두는 것입니다.

IoT에서 원시 센서 데이터는 보통 ADC 카운트로 도착하며, 보정 곡선을 통해 온도로 변환됩니다(10kΩ NTC 서미스터라면 슈타인하트–하르트 방정식이 그 역할). 온도 척도 변환은 그 이후 보정된 값에 적용됩니다. 두 단계를 섞으면 온도 모양은 갖췄지만 30%쯤 어긋난 숫자가 나옵니다.

자주 발생하는 함정과 회피법

다음 여섯 가지는 실제 운영 코드베이스에서 등장합니다. 여러분의 코드도 한 번 점검해 보세요.

변환 방향을 거꾸로 적용

흔한 증상: 아기의 37°C 발열을 위중하다고 표시하는 앱입니다. 실제로는 API가 37°F를 반환했는데 컬럼 이름 때문에 누군가 celsius로 라벨을 붙였고, 의료 임계값 로직이 섭씨 척도와 비교한 결과입니다. 변수 이름이 아니라 타입이 단위를 지니게 하세요.

온도를 외연적(extensive) 양으로 다루기

averageTemperature는 의미가 있지만 sumTemperatures는 없습니다. 집계 SQL에 SUM(temperature_c)가 있다면 뭔가 잘못된 것입니다. 보통 AVG를 원했거나, 드물게 적분된 도일(degree-day) 지표를 원했을 겁니다. 온도는 강도성 양이어서 더하면 의미가 사라집니다.

부동소수점 반올림

자바스크립트에서 (37 * 9 / 5) + 32는 98.6이 아니라 98.60000000000001입니다. IEEE 754 더블을 쓰는 모든 언어에서 동일합니다. 선택지는 다음과 같습니다.

• .toFixed(2)(또는 해당 언어 등가물)로 표시하고 거기서 끝냅니다.
• 감사 수준의 정밀도가 필요하다면 십진 라이브러리(decimal.js, Python Decimal, BigDecimal)를 사용합니다.
• 데시도(deci-degree) 단위 정수로 저장합니다(37.0 대신 370). 표시할 때만 나눕니다.

UI 표시에는 toFixed(2)로 충분합니다. 반올림 오차가 누적되는 청구나 규제 시스템에는 십진을 쓰세요.

음수 켈빈에 대한 입력 유효성 검사

켈빈은 물리 법칙상 음수가 될 수 없습니다. { "tempK": -10 } 요청 본문은 잘못된 입력입니다. 비즈니스 로직 깊은 곳이 아니라 경계(JSON 스키마, Pydantic, Zod, CHECK 제약)에서 차단하세요. “음의 절대온도”를 갖는 양자계는 여러분이 통합할 만한 어떤 API에도 등장하지 않으며, 등장한다면 이미 알고 있을 것입니다.

UI와 로그의 단위 라벨 누락

sensor 42: 37이라고 적힌 로그 한 줄은 6개월 뒤엔 쓸모가 없습니다. 섭씨인가요, 화씨인가요, 원시 ADC 카운트인가요? 항상 sensor 42: 37°C로 쓰거나 { "sensor": 42, "value": 37, "unit": "celsius" } 형태로 구조화하세요. 디스크 공간은 싸지만 새벽 3시의 운영 사고 대응은 그렇지 않습니다.

시간대 혼동을 온도에 적용

여행 앱에서 종종 출시되는 버그입니다. 사용자가 시간대를 넘어가면 코드가 친절하게도 온도 측정값을 포함한 모든 타임스탬프 필드를 이동시킵니다. 온도는 시간대를 신경 쓰지 않습니다. 측정 타임스탬프에는 시간대 로직이 필요하지만 측정값 자체에는 필요하지 않습니다. 두 값을 별도 필드에 두고 별도 파이프라인을 통과시키세요.

암산 단축법

변환기를 열어 둘 수 없는 상황을 위해 정리합니다.

섭씨 → 화씨(어림): 두 배에 30을 더합니다. 20°C → 70°F(실제 68). 30°C → 90°F(실제 86). 040°C 범위에서 23°F 이내로 정확하며, 가마 바깥에서 겪는 모든 온도를 덮습니다.

화씨 → 섭씨(어림): 30을 빼고 반으로 나눕니다. 80°F → 25°C(실제 26.7). 60°F → 15°C(실제 15.6). 같은 정확도 범위입니다.

섭씨 → 켈빈: 273을 더하고 반올림합니다. 0.15 K를 잃지만 물리학 실험실 외에서는 온도계 정밀도보다 작은 값입니다.

기억해 둘 만한 두 기준점: 20°C = 68°F ≈ 293 K, 그리고 100°C = 212°F = 373.15 K. 이 두 점에서 선형 보간하면 어떤 어림 추정도 충분히 가까워집니다.

빠른 암산은 여행, 요리의 대략적 온도, 일기 예보에 쓰세요. 코드나 규제 신고에 들어갈 값에는 정확한 공식을 쓰고, 아니면 무료 온도 변환 도구에서 정밀한 값을 복사하세요.

참고표

일상 온도

상황	섭씨	화씨	켈빈
가정용 냉동고	−18°C	0°F	255.15 K
어는점	0°C	32°F	273.15 K
냉장고	4°C	39°F	277.15 K
실온	20°C	68°F	293.15 K
체온	37°C	98.6°F	310.15 K
발열 임계값	38°C	100.4°F	311.15 K
한여름 무더위	35°C	95°F	308.15 K
물 끓는점	100°C	212°F	373.15 K

요리 및 오븐 변환

오븐 프리셋	섭씨	화씨
저온 / 슬로우 쿡	125°C	257°F
약한 베이킹	150°C	302°F
중간 베이킹	175°C	347°F
표준 베이킹(케이크)	180°C	356°F
로스팅	190°C	374°F
강한 로스팅	200°C	392°F
더 강한 로스팅	220°C	428°F
피자 / 빵 크러스트	250°C	482°F

미국 레시피에서 350°F는 요리책에 따라 175°C 또는 180°C로 반올림합니다. 정확한 값은 176.67°C. 어느 쪽을 골라도 무방합니다. 가정용 오븐은 어차피 ±5°C보다 정밀하게 온도를 유지하는 경우가 드뭅니다.

과학적 극값

현상	켈빈	섭씨
절대영도(이론적 하한)	0 K	−273.15°C
우주 마이크로파 배경 복사	2.725 K	−270.425°C
액체 헬륨(끓는점, 1 atm)	4.2 K	−268.95°C
초전도체 전이(YBCO)	93 K	−180.15°C
액체 질소(끓는점)	77 K	−196.15°C
심우주 그늘	~40 K	~−233°C
드라이아이스(승화)	194.65 K	−78.5°C
태양 표면	5,778 K	5,504.85°C
태양 중심	1.57×10⁷ K	1.57×10⁷ °C*
토카막 플라스마(ITER 목표)	1.5×10⁸ K	~1.5×10⁸ °C*

*이 정도 크기에서는 273.15 K 오프셋이 반올림 오차 수준입니다. 섭씨와 켈빈이 사실상 동일한 값을 가리킵니다.

FAQ

섭씨를 화씨로 변환하는 공식은 무엇인가요?

섭씨에 9/5(또는 1.8)를 곱한 뒤 32를 더합니다. °F = °C × 9/5 + 32. 예: 25°C × 1.8 + 32 = 77°F. 곱하는 인자는 두 척도의 어는점~끓는점 폭이 180:100인 비율을 반영하고, 더하는 32는 서로 다른 영점을 맞춥니다.

화씨를 섭씨로 변환하는 공식은 무엇인가요?

화씨 값에서 32를 뺀 뒤 5/9를 곱합니다. °C = (°F − 32) × 5/9. 72°F라면 (72 − 32) × 5/9 = 40 × 5/9 ≈ 22.22°C입니다. 먼저 빼고, 그다음 곱하세요. 순서를 뒤집으면 틀린 값이 나옵니다.

섭씨와 화씨가 같아지는 온도는 몇 도인가요?

정확히 −40도입니다. 변환 공식에서 °C = °F로 두면 °C = °C × 9/5 + 32가 되고 풀면 °C = −40이 나옵니다. 두 척도가 같은 숫자를 가리키는 유일한 온도이며, 실제 한파나 변환 방향 버그를 잡는 점검 기준점이 됩니다.

베이킹용 350°F는 섭씨로 얼마인가요?

350°F는 약 176.67°C입니다. 유럽 레시피는 보통 이를 180°C로 반올림하고, 미국식-미터법 변환표 상당수는 175°C를 씁니다. 가정용 오븐에서는 어느 쪽이든 무방합니다. 그 범위에서의 온도 안정성은 반올림 오차보다 더 떨어집니다. 정밀도가 중요한 경우 온도 변환기 도구에서 정확한 값을 확인하세요.

100°F는 섭씨로 얼마인가요?

100°F ≈ 37.78°C입니다. 정상 체온(37°C / 98.6°F)보다 약간 높으며, 종종 미열의 시작으로 표시됩니다. 의학 가이드라인에서는 38°C / 100.4°F를 진정한 발열 임계값으로 사용하므로, 100°F는 경계선이지만 임상적으로는 아직 유의미하지 않습니다.

절대영도는 왜 그냥 −273이 아니라 −273.15°C인가요?

2019년 SI 재정의가 볼츠만 상수를 정확히 고정했기 때문입니다. 결과적으로 −273.15°C는 반올림 근삿값이 아니라 절대영도의 정확한 계산 값입니다. 2019년 이전에는 섭씨 영점이 물의 삼중점에 묶여 있었고 0.15는 측정값이었습니다. 지금은 정의에 의해 정확합니다.

코드에서 섭씨 대신 켈빈을 써야 할 때는 언제인가요?

온도를 곱하거나 나누거나 거듭제곱할 때. 흑체 복사(T⁴), 이상기체 계산, 반응 속도 등이 그렇습니다. 켈빈은 음수가 되지 않으므로 나눗셈이 안정적입니다. 온도 차이에서는 섭씨와 켈빈이 호환됩니다(5도 변화는 두 단위에서 동일).

2026년에도 랭킨이 사용되나요?

네, 다만 좁은 영역에서입니다. 미국의 기계·HVAC·항공우주 공학에서는 다른 입력이 모두 화씨인 열역학 사이클 분석에 여전히 랭킨을 씁니다. 이 분야 외, 미국 외에서는 사실상 사라진 척도입니다. 범용 소프트웨어를 작성한다면 랭킨 지원은 값싼 보험이지 핵심 부담은 아닙니다.

SQL 쿼리에서 온도를 어떻게 변환하나요?

공식을 인라인으로 쓰거나 GENERATED ALWAYS AS 컬럼을 씁니다. 예: SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. 대부분의 방언에서 9와 5가 아닌 9.0과 5.0을 써야 부동소수점 산술이 강제됩니다. 정수 나눗셈은 조용히 잘려 나갑니다. CHECK (celsius >= -273.15)를 더해 삽입 시점에 말이 안 되는 값을 거부하세요.

머릿속에서 섭씨를 화씨로 변환하는 가장 쉬운 방법은 무엇인가요?

섭씨를 두 배 하고 30을 더합니다. 22°C × 2 + 30 = 74°F(실제 71.6°F). 0~30°C 범위에서 약 2°F 이내로 정확하며, 대부분의 날씨와 실내 측정값을 덮습니다. 반대 방향은 화씨에서 30을 빼고 반으로 나눕니다.

37°C를 변환했더니 왜 98.599999가 나오나요?

9/5 = 1.8을 이진 부동소수점에서 정확히 표현할 수 없기 때문입니다. 그래서 37 × 9 / 5 + 32는 98.6이 아닌 98.60000000000001입니다. IEEE 754 동작이지 버그가 아닙니다. 표시에는 toFixed(2)를 쓰고, 끝자리 정밀도가 도메인에서 중요하다면 십진 라이브러리로 바꾸세요.

부동소수점 문제를 피하기 위해 온도를 정수로 저장해도 되나요?

네, 가능합니다. 데시섭씨(섭씨에 10을 곱한 값)로 저장하세요. 37.0°C는 370, 22.5°C는 225. 정수 연산은 정확하고 표시 경계에서만 10으로 나눕니다. 디스크와 CPU가 중요한 임베디드 시스템과 대용량 시계열 데이터베이스에서 흔히 쓰입니다.

API 응답에서 단위가 없는 숫자는 어떻게 처리하나요?

처리하지 마세요. 모든 온도 필드는 명시적인 단위와 함께 와야 합니다. 필드 이름(temp_celsius, temp_k)이나 형제 unit 필드에 담으세요. 소비자 입장에서 API가 단위를 제공하지 않는다면, 코드에 가정을 크게 문서화하고 API 기본값이 바뀌면 깨지는 계약 테스트를 작성하세요.

네 척도 전부에서 물의 끓는점은 얼마인가요?

표준 대기압(1기압, 101.325 kPa)에서 100°C = 212°F = 373.15 K = 671.67°R입니다. 압력이 영향을 줍니다. 덴버의 고도에서는 물이 약 95°C에서, 에베레스트 정상에서는 71°C에 가깝게 끓습니다. 끓는점은 보편 상수가 아니라 압력 의존량입니다.

온도 값이 다른 숫자와 부동소수점 계산에서 다르게 동작하나요?

아닙니다. 온도 값은 다른 부동소수점 숫자와 동일하게 동작합니다. 실무에서 걸리는 부분은 변환 공식의 5/9와 9/5 인자가 매 변환 단계마다 반올림 오차를 들인다는 점입니다. 200~400 범위의 켈빈 값에서는 정밀도가 충분하고 영하 섭씨 값에서도 유지됩니다. 진짜 함정은 연쇄 변환에서 작은 오차가 쌓이는 것입니다. 한 번만 변환해 정규형으로 저장하세요.