프로그래밍에서 하드코드: 정의, 원인 및 회피 방법

프로그래밍에서 하드코드란

하드코드(하드 코딩)는 데이터, 구성 매개변수 또는 설정 값을 프로그램 텍스트에 직접 포함시키는 안티패턴입니다. 외부 소스에서 이러한 값을 읽는 대신, 개발자는 리터럴(문자열, 숫자, 불리언 값)로 함수 본문, 클래스 또는 모듈에 직접 작성합니다. 이 용어는 1980년대 개발자 커뮤니티에서 생겨났는데, 소프트웨어가 다양한 하드웨어 플랫폼으로 확산되기 시작하면서 하드코딩된 매개변수가 이식성을 저해한다는 것이 명백해졌기 때문입니다.

하드코드의 주요 문제는 이러한 값을 변경하려면 소스 코드 편집, 재컴파일 및 애플리케이션 재배포가 필요하다는 것입니다. 이로 인해 업데이트 프로세스가 느려지고 오류가 발생하기 쉬우며 위험해집니다. 개발자는 하드코딩된 매개변수를 편집하는 동안 실수로 코드의 다른 부분을 변경할 수 있습니다. 최신 DevOps 방식에서는 이 접근 방식이 명백히 권장되지 않습니다.

Veracode State of Software Security 2024 연구에 따르면, 상용 애플리케이션의 모든 취약점 중 약 23%가 하드코딩된 자격 증명과 관련이 있습니다. 이는 하드코드와의 싸움을 편의의 문제일 뿐만 아니라 중요한 정보 보안 작업으로 만듭니다.

간단한 용어로 하드코드 정의

하드코딩된 값은 구성에서 로드되는 대신 코드에 직접 작성된 모든 숫자, 문자열 또는 설정입니다. 예를 들어, 개발자가 데이터베이스 연결 클래스 내에 `connectionTimeout = 30`을 작성하는 경우 — 이것이 하드코드입니다. 환경 변수나 구성 파일에서 타임아웃을 읽는다면 — 그것이 올바른 접근 방식입니다.

용어의 기원

하드코드라는 단어는 영어 단어 hard code(“단단한 코드”)에서 유래했습니다. 한국어 환경에서는 “하드코딩”, “고정 값” 등의 변형도 사용됩니다. 유연한 구성과 달리, 하드코드는 말 그대로 실행 파일에 “박혀” 있어 재빌드 없이는 변경할 수 없습니다.

하드코드가 나쁜 관행으로 여겨지는 이유

하드코드는 장기적으로 많은 문제를 만듭니다. 첫 번째이자 가장 명백한 것은 소스 코드를 수정하지 않고는 애플리케이션 동작을 변경할 수 없다는 점입니다. 두 번째는 기밀 정보 유출 위험입니다. 세 번째는 특히 단위 및 통합 테스트의 복잡성입니다.

다양한 환경(개발, 스테이징, 프로덕션)에서 빠른 배포가 필요한 Agile 및 DevOps에서는 하드코드가 극복할 수 없는 장애물이 됩니다. 팀은 배포할 때마다 코드를 편집하거나 수동 패치를 사용해야 하며, 이는 지속적 전달 원칙에 위배됩니다.

케임브리지 대학교의 연구(2023)에 따르면, 하드코드 수준이 높은 프로젝트는 릴리스 시 결함이 47% 더 많고 변경에 2.3배 더 많은 시간이 소요됩니다. 이는 하드코딩된 코드의 유지 관리 비용이 개발 초기 단계의 시간 절약을 크게 초과한다는 것을 확인합니다.

확장성 및 이식성

하드코딩된 매개변수가 있는 애플리케이션은 다양한 플랫폼에 적응시키기 어렵습니다. 예를 들어, 파일 경로 `C:\Users\admin\data.txt`는 Linux 서버에서 작동하지 않습니다. 또한 14pt 글꼴 크기는 픽셀 밀도가 다른 장치에서 다르게 보일 수 있습니다.

코드 유지보수성

하드코드가 프로젝트 전체에 흩어져 있는 경우, 개발자는 grep 또는 IDE 검색을 사용하여 각 값을 수동으로 찾아야 합니다. 이는 개발 속도를 늦추고 필요한 값을 놓칠 가능성을 높이며 버그의 원인이 됩니다. 한편, 새 팀원은 “매직 넘버”와 문자열을 이해하는 데 훨씬 더 많은 시간을 소비합니다.

가장 자주 하드코딩되는 값

비밀번호와 자격 증명은 가장 위험한 유형의 하드코드입니다. 개발자는 로컬 개발의 편의를 위해 데이터베이스 비밀번호, 타사 API 키, 인증 토큰을 코드에 직접 저장하는 경우가 많지만, 커밋하기 전에 외부화하는 것을 잊어버립니다. 이로 인해 공개 저장소에서 유출이 발생합니다.

외부 서비스의 URL과 엔드포인트도 하드코드의 희생양이 되는 경우가 많습니다. 호스팅이나 API 버전을 변경할 때 개발자는 수십 군데의 URL을 업데이트해야 합니다. 주소가 여러 모듈에서 하드코딩된 경우 일부 링크가 오래된 상태로 남아 애플리케이션이 올바르게 작동하지 않습니다.

매직 넘버 — 설명 없는 숫자 상수. 예를 들어, `price * DISCOUNT_RATE` 대신 `price * 0.85`. 코드를 읽는 사람은 0.85가 무엇을 의미하는지 이해하지 못합니다. 이는 마틴 파울러가 저서 “리팩토링”(1999)에서 설명한 하드코드의 전형적인 예입니다.

매직 문자열

프로그램의 여러 부분에서 반복되는 문자열 리터럴은 또 다른 일반적인 하드코드 유형입니다. 예를 들어, 딕셔너리 키, HTTP 헤더, iOS 애플리케이션의 뷰 이름 등입니다. 문자열이 한 곳에서는 변경되었지만 다른 곳에서는 그대로 남아 있으면 애플리케이션이 중단됩니다. 해결책은 문자열을 상수나 지역화 파일로 외부화하는 것입니다.

환경 구성

애플리케이션 모드(디버그/릴리스), 로깅 설정, SMTP 서버 주소 — 이러한 모든 매개변수는 외부에 있어야 합니다. 하드코딩된 경우 다른 서버로 이동할 때 애플리케이션이 시작되지 않거나 예기치 않게 동작할 수 있습니다.

하드코드 사용의 보안 위험

하드코딩된 비밀번호와 키는 애플리케이션 보안에 직접적인 위협이 됩니다. 공격자가 소스 코드에 접근할 경우(저장소 유출, 내부자 위협 또는 디컴파일을 통해) 보호된 모든 리소스에 즉시 접근할 수 있습니다. 2023년 GitHub는 공개 저장소에서 1,200만 개 이상의 시크릿 유출을 발견했습니다.

OWASP(오픈 웹 애플리케이션 보안 프로젝트) 표준은 하드코딩된 자격 증명을 A04:2021 — 안전하지 않은 설계 범주에 포함합니다. OWASP는 비밀번호, 토큰 또는 키를 소스 코드에 절대 저장하지 말 것을 권장합니다. 대신 HashiCorp Vault, AWS Secrets Manager 또는 Azure Key Vault와 같은 전문 시크릿 관리 서비스를 사용하십시오.

Positive Technologies(2024)가 수행한 보안 감사에 따르면, 테스트된 모바일 애플리케이션의 78%에 하드코딩된 키나 토큰이 하나 이상 포함되어 있습니다. 웹 애플리케이션의 경우 이 수치는 62%입니다. 대부분의 취약점은 데이터를 구성 파일로 외부화하는 것만으로 제거할 수 있습니다.

# hardcoded secrets — unsafe
password = "supersecret123"
api_key = "sk-abc123def456"

# safe approach — read from env vars
import os
password = os.getenv("DB_PASSWORD")
api_key = os.getenv("API_KEY")

버전 관리를 통한 유출

Git은 전체 커밋 기록을 보존합니다. 하드코딩된 비밀번호가 저장소에 포함되면 현재 버전에서 삭제된 후에도 기록에 남아 있습니다. git-secrets 및 truffleHog와 같은 도구는 이러한 유출을 감지하는 데 도움이 되지만, 코드 검토 단계에서 방지하는 것이 가장 좋습니다.

규제 요구 사항

PCI DSS, GDPR, HIPAA와 같은 표준은 소스 코드에 기밀 데이터를 저장하는 것을 직접 금지합니다. 하드코드 사용은 특히 금융 및 의료 분야에서 법적 결과와 벌금을 초래할 수 있습니다.

프로젝트에서 하드코드를 피하는 방법

첫 번째 단계는 팀 수준에서의 인식입니다. 코드 검토에는 하드코딩된 값에 대한 확인이 포함되어야 합니다. 잠재적 하드코드를 강조 표시하는 린터 또는 정적 분석기를 설정하십시오. TypeScript의 경우 no-hardcoded-credentials 규칙이 있는 ESLint가 적합하고, Python의 경우 Bandit이 적합합니다.

두 번째 단계는 Configuration as Code 패턴을 도입하는 것입니다. 환경에 따라 다를 수 있는 모든 매개변수는 환경 변수나 구성 파일에 저장해야 합니다. dotenv(Node.js), python-decouple(Python), Spring Cloud Config(Java)와 같은 라이브러리가 이 접근 방식을 표준화합니다.

세 번째 단계는 구성 관리 서비스 사용입니다: Consul, etcd, Zookeeper. 클라우드 프로젝트에는 AWS Parameter Store, Google Cloud Secret Manager 또는 Azure App Configuration이 적합합니다. 마이크로서비스 아키텍처에서는 중앙 집중식 구성 관리가 중요합니다.

• 환경 변수 — 시크릿 및 민감한 데이터용
• .env 파일 — 로컬 개발용
• 구성 클래스 — 외부 소스에서 읽기
• 기능 토글 — 기능 활성화/비활성화용
• 국제화 — 문자열 리소스용

모범 사례

각 구성 매개변수를 문서화하세요: 목적, 허용 값, 기본값. 구성에 스키마 유효성 검사를 사용하면 애플리케이션 시작 시 오류를 포착할 수 있습니다. 실제 값 없이 필요한 모든 변수가 포함된 .env.example 파일을 만드세요.

하드코드 리팩토링 예제

JavaScript의 구체적인 예를 살펴보겠습니다. 리팩토링 전의 코드에는 하드코딩된 URL과 타임아웃이 포함되어 있습니다. 리팩토링 후 모든 매개변수가 구성으로 외부화됩니다. 이렇게 하면 코드를 테스트 가능하고 유연하며 안전하게 만들 수 있습니다.

// before refactoring — hardcoded values
const response = await fetch("https://api.example.com/v1/users", {
  timeout: 5000,
  headers: { "Authorization": "Bearer sk-abc" }
});

// after refactoring — config driven
const config = {
  apiUrl: process.env.API_URL,
  timeout: parseInt(process.env.API_TIMEOUT || "30000"),
  authToken: process.env.AUTH_TOKEN
};

const response = await fetch(config.apiUrl, {
  timeout: config.timeout,
  headers: { "Authorization": "Bearer " + config.authToken }
});

Java에서의 리팩토링

Java에서는 하드코드가 데이터베이스 연결 문자열 형태로 자주 나타납니다. Spring Boot를 application.yml과 함께 사용하면 이 문제가 해결됩니다. 파일에는 다양한 환경에 대한 프로필이 포함되어 있고, 코드는 @Value 어노테이션을 통해 값을 읽습니다.

// hardcoded — Java example
class DatabaseConnection {
    private String url = "jdbc:mysql://localhost:3306/mydb";
    private String user = "admin";
    private String password = "pass123";
}

// proper config via Spring Boot
@Value("${db.url}")
private String url;

다양한 프로그래밍 언어에서의 하드코드

하드코드 대응 방법은 언어와 생태계에 따라 다릅니다. 인터프리터 언어(Python, JavaScript, Ruby)에서는 일반적으로 구성을 환경 변수나 .env 파일에 저장합니다. 컴파일 언어(Java, C#, Go)에서는 YAML, JSON, XML 구성 파일이나 포함된 리소스에 저장합니다.

Python에서는 python-decouple 라이브러리가 인기가 있습니다. .env 파일에서 구성을 읽고 타입화된 게터를 제공합니다. Go에서는 Viper가 사용됩니다 — 다양한 소스의 구성 작업을 위한 강력한 라이브러리입니다. Swift의 iOS 개발에서는 구성을 Info.plist나 별도의 Configuration 파일로 외부화합니다.

SonarQube, ESLint, Pylint와 같은 정적 분석 도구는 하드코딩된 값을 자동으로 감지할 수 있습니다. SonarQube에는 다양한 언어의 코드에서 매직 넘버와 문자열을 찾기 위한 내장 규칙이 있습니다. CI/CD 파이프라인에서 이러한 검사를 설정하는 것은 새로운 하드코드의 출현을 방지하는 가장 좋은 방법입니다.

하드코드 감지 자동화

Pre-commit Git 훅은 하드코딩된 시크릿이 있는지 커밋을 검사하는 스크립트를 실행할 수 있습니다. git-secrets 도구는 비밀번호, 키, 토큰에 대한 정규식과 일치하는 항목을 커밋에서 스캔합니다. TruffleHog와 Gitleaks는 더 나아가 유출 여부를 전체 git 기록에서 확인합니다.