하드 코딩

하드 코딩(hard coding) 또는 하드코딩(hardcoding)은 소스 코드에 데이터를 직접 프로그램 또는 기타 실행 가능한 객체에 포함하는 소프트웨어 개발 방식이며, 외부 소스에서 데이터를 얻거나 런타임에 생성하는 방식과 대조된다.

하드 코딩된 데이터는 일반적으로 소스 코드를 편집하고 실행 파일을 재컴파일해야만 수정할 수 있지만, 디버거나 헥사 편집기를 사용하여 휘발성 메모리 또는 디스크에서 변경할 수 있다.

하드 코딩된 데이터는 물리 상수, 버전 번호 및 정적 텍스트 요소와 같이 변하지 않는 정보에 가장 적합하다.

반면 소프트 코딩된 데이터는 사용자 입력, 텍스트 파일, INI 파일, HTTP 서버 응답, 구성 파일, 전처리기 매크로, 외부 상수, 데이터베이스, 명령줄 인수를 통해 임의의 정보를 인코딩하며 런타임에 결정된다.

개요

하드 코딩은 입력 데이터나 원하는 형식이 변경될 때마다 프로그램의 소스 코드를 변경해야 하는데, 이는 최종 사용자가 프로그램 외부에서 어떤 수단으로든 세부 사항을 변경하는 것이 더 편리할 수 있다.^[1]

하드 코딩은 종종 필요하지만, 안티패턴으로 간주될 수도 있다.^[2] 프로그래머는 최종 사용자를 위한 동적인 사용자 인터페이스 솔루션을 찾지 못했더라도 기능을 제공하거나 프로그램을 출시해야 할 수 있다. 이는 일반적으로 임시적이지만 단기적으로 코드를 제공해야 한다는 압박을 해소한다. 나중에 소프트 코딩을 통해 사용자가 매개변수를 전달하여 최종 사용자가 결과나 성과를 수정할 수 있는 방법을 제공한다.

"하드 코딩"이라는 용어는 원래 하드웨어 회로의 하드와이어링에 대한 비유로 사용되었으며, 소프트웨어 설계 및 구현에 사용될 때 발생하는 유연성 부족을 전달하기 위한 것이었다. MUD와 같은 런타임 확장 가능한 협업 개발 환경의 맥락에서, 하드 코딩은 시스템의 핵심 엔진을 개발하는 것을 의미하며, 이 엔진은 낮은 수준의 작업을 처리하고 스크립트를 실행하는 역할을 한다. 반면 소프트 코딩은 런타임에 시스템에 의해 해석되는 높은 수준의 스크립트를 개발하는 것을 의미하며, 이는 텍스트 파일, INI 파일, 전처리기 매크로 (컴퓨터 과학), 외부 상수, 데이터베이스, 명령줄 인수, HTTP 서버 응답, 구성 파일, 사용자 입력과 같은 외부 소스의 값을 사용한다. 이 경우 이 용어는 경멸적인 의미가 아니며, 단순히 출력 데이터를 삽입하는 것이 아니라 일반적인 개발을 의미한다.

하드 코딩과 백도어

자격 증명 하드 코딩은 백도어를 만드는 일반적인 방법이다. 하드 코딩된 자격 증명은 일반적으로 구성 파일이나 계정 열거 명령의 출력에서 보이지 않으며 사용자가 쉽게 변경하거나 우회할 수 없다. 발견될 경우, 사용자는 소스 코드에서 프로그램을 수정하고 재구축하거나 (소스가 공개적으로 사용 가능한 경우), 디컴파일하거나 리버스 엔지니어링 소프트웨어를 통해, 직접 프로그램의 이진 코드를 편집하거나, 무단 접근을 방지하기 위한 무결성 검사(예: 디지털 서명, 위변조 방지 및 치트 방지)를 통해 이러한 백도어를 비활성화할 수 있지만, 이러한 행위는 종종 소프트웨어 사용권 동의에 의해 금지된다.

하드 코딩과 디지털 권리 관리

디지털 권리 관리 조치로, 소프트웨어 개발자는 고유한 일련번호를 프로그램에 직접 하드 코딩할 수 있다. 또는 공개 키를 하드 코딩하여 키젠을 생성하는 것이 불가능한 DRM을 만드는 것이 일반적이다.

반대로, 소프트웨어 크래커는 유효한 일련번호를 프로그램에 하드 코딩하거나 심지어 실행 파일이 사용자에게 이를 요구하지 못하게 할 수 있으며, 이를 통해 무단 복사본이 유효한 번호를 입력할 필요 없이 재배포될 수 있고, 하드 코딩된 경우 모든 복사본이 동일한 키를 공유하게 된다.

고정 설치 경로

윈도우 프로그램이 항상 C:\Program Files\Appname에 설치된다고 가정하도록 프로그래밍되어 있는데, 사용자가 공간이나 조직상의 이유로 다른 드라이브에 설치하려고 하면 설치에 실패하거나 설치 후 실행되지 않을 수 있다. 이 문제는 테스트 과정에서 식별되지 않을 수 있는데, 일반 사용자는 기본 드라이브와 디렉토리에 설치하며 테스트에는 설치 디렉토리 변경 옵션이 포함되지 않을 수 있기 때문이다. 그러나 프로그래머와 개발자는 프로그램의 설치 경로를 고정하지 않는 것이 좋다. 기본 설치 경로는 운영 체제, OS 버전, 시스템 관리자 결정에 따라 달라지기 때문이다. 예를 들어, 많은 마이크로소프트 윈도우 설치는 기본 하드 디스크로 드라이브 C:를 사용하지만, 이는 보장되지 않는다.

초기 컴퓨터의 마이크로프로세서에서도 유사한 문제가 있었는데, 이들은 메모리의 고정된 주소 공간에서 실행을 시작했다.

시작 디스크

일부 "복사 방지" 프로그램은 무단 복사본이 아님을 확인하기 위해 시작 시 플로피 디스크나 플래시 드라이브에서 특정 파일을 찾는다. 컴퓨터가 플로피 드라이브가 없는 최신 기기로 교체되면, 플로피 디스크를 삽입할 수 없으므로 플로피 디스크가 필요한 프로그램은 더 이상 실행될 수 없다.

이 마지막 예는 하드 코딩이 당시에는 완전히 작동할 것처럼 보일지라도 왜 비실용적일 수 있는지를 보여준다. 1980년대와 1990년대에는 대다수의 PC에 최소 하나의 플로피 드라이브가 장착되어 있었지만, 플로피 드라이브는 나중에 사용되지 않게 되었다. 15년 전에 그런 방식으로 하드 코딩된 프로그램은 업데이트되지 않으면 문제가 발생할 수 있다.

특수 폴더

일부 윈도우 운영 체제에는 하드 디스크에 파일을 논리적으로 구성하는 소위 특수 폴더가 있다. 하드 코딩과 관련된 문제가 발생할 수 있다.

프로필 경로

일부 윈도우 프로그램은 프로필 경로를 C:\Documents and Settings\Username과 같이 개발자가 정의한 위치로 하드 코딩한다. 이것은 윈도우 2000 이상 버전의 대다수에 해당하는 경로이지만, 프로필이 네트워크에 저장되거나 다른 곳으로 재배치된 경우 오류가 발생할 수 있다. 올바른 방법은 GetUserProfileDirectory 함수를 호출하거나 %userprofile% 환경 변수를 해결하는 것이다. 개발자들이 흔히 하는 또 다른 가정은 프로필이 로컬 하드 디스크에 있다고 가정하는 것이다.

내 문서 폴더 경로

일부 윈도우 프로그램은 내 문서의 경로를 ProfilePath\My Documents로 하드 코딩한다. 이러한 프로그램은 영어 버전의 컴퓨터에서는 작동하지만, 지역화된 윈도우 버전에서는 이 폴더의 이름이 일반적으로 다르다. 예를 들어, 이탈리아어 버전에서는 My Documents 폴더의 이름이 Documenti이다. My Documents는 윈도우 2000 이상 버전의 그룹 정책에서 폴더 리디렉션을 사용하여 재배치되었을 수도 있다. 올바른 방법은 SHGetFolderPath 함수를 호출하는 것이다.

해결책

"FileName"이라는 프로그램 내 변수와 같은 간접 참조는 "파일 찾아보기" 대화 상자를 통해 확장될 수 있으며, 파일이 이동해도 프로그램 코드를 변경할 필요가 없다.

하드 코딩은 다른 언어로 소프트웨어를 번역할 때 특히 문제가 된다.

많은 경우, 배열 크기와 같이 하드 코딩된 단일 값은 프로그램의 소스 코드 내에서 여러 번 나타날 수 있다. 이것은 매직 넘버가 될 수 있다. 이는 값의 일부만 수정하고 모두 수정하지 않으면 프로그램 버그를 유발할 수 있다. 이러한 버그는 찾기 어렵고 프로그램에 오랫동안 남아 있을 수 있다. 동일한 하드 코딩된 값이 둘 이상의 매개변수 값(예: 6개의 요소가 있는 배열과 최소 입력 문자열 길이 6)에 사용되는 경우 유사한 문제가 발생할 수 있다. 프로그래머는 각 인스턴스가 어떻게 사용되는지 코드를 확인하지 않고 값의 모든 인스턴스를 (종종 편집기의 검색 및 바꾸기 기능을 사용하여) 실수로 변경할 수 있다. 두 상황 모두 상수를 정의하여 이름과 값을 연결하고 코드 내에서 각 나타남에 상수의 이름을 사용하여 방지한다.

하드 코딩의 중요한 한 가지 경우는 문자열이 파일에 직접 배치되어 번역자가 프로그램을 번역하기 위해 소스 코드를 편집해야 하는 경우이다. (문자열을 파일에 남겨두면서도 번역자가 소스 코드를 변경하지 않고 번역할 수 있도록 하는 Gettext라는 도구가 있다. 이는 문자열을 효과적으로 하드 코딩 해제한다.)

경쟁에서의 하드 코딩

국제 정보 올림피아드와 같은 컴퓨팅 대회에서 참가자들은 문제의 요구 사항에 따라 특정 입출력 패턴을 가진 프로그램을 작성해야 한다.

가능한 입력 수가 충분히 작은 드문 경우에 참가자는 모든 가능한 입력을 올바른 출력에 매핑하는 접근 방식을 고려할 수 있다. 이 프로그램은 알고리즘 방식과 대조적으로 하드 코딩된 솔루션으로 간주될 것이다(하드 코딩된 프로그램이 알고리즘 프로그램의 출력일지라도).

소프트 코딩

소프트 코딩은 텍스트 파일, INI 파일, 전처리기 매크로 (컴퓨터 과학), 외부 상수, 구성 파일, 명령줄 인수, 데이터베이스, 사용자 입력, HTTP 서버 응답과 같은 외부 리소스에서 값이나 함수를 얻는 것을 의미하는 컴퓨터 코딩 용어이다. 이는 소스 코드에 값과 함수를 코딩하는 것을 의미하는 하드 코딩의 반대이다.

프로그래밍 관행

자주 변경되는 값을 하드 코딩하는 것을 피하는 것은 좋은 프로그래밍 관행이다. 소프트웨어 사용자는 합리적인 범위 내에서 프로그램의 소스 코드를 편집할 필요 없이 자신의 필요에 맞게 소프트웨어를 사용자 정의할 수 있어야 한다. 마찬가지로, 신중한 프로그래머는 코드의 가독성을 높이고 유지 관리를 돕기 위해 코드에서 매직 넘버를 피한다. 이러한 관행은 일반적으로 소프트 코딩이라고 불리지 않는다.

이 용어는 일반적으로 소프트 코딩이 안티패턴이 되는 경우에 사용된다. 너무 많은 값과 기능을 추상화하면 필요할 때 코드를 변경하는 것보다 더 많은 복잡성과 유지 관리 문제를 야기할 수 있다. 이러한 의미에서 소프트 코딩은 더 데일리 WTF의 기사에 실렸다.^[3]

잠재적 문제

극단적으로, 소프트 코딩된 프로그램은 자체적으로 잘 설계되지 않고 구현되지 않은 스크립트 언어와 고급 프로그래밍 기술을 필요로 하는 구성 파일을 개발한다. 이는 원래 프로그램을 구성하는 데 도움이 되는 유틸리티를 생산하게 할 수 있으며, 이러한 유틸리티는 종종 그 자체로 소프트 코딩된다.

적절한 구성 가능성과 문제성 있는 소프트 코딩 사이의 경계는 프로그램의 스타일과 특성에 따라 달라진다. 클로즈드 소스 소프트웨어는 최종 사용자가 변경할 수 있는 소스에 접근할 수 없으므로 매우 구성 가능해야 한다. 사내 소프트웨어 및 제한된 배포를 가진 소프트웨어는 변경된 복사본을 배포하는 것이 더 간단하므로 덜 구성 가능할 수 있다. 맞춤형 웹 애플리케이션은 스크립트를 변경하는 것이 구성 파일을 변경하는 것보다 거의 어렵지 않으므로 제한된 구성 가능성이 가장 좋다.

소프트 코딩을 피하려면, 제공하는 추가적인 유연성이 최종 사용자에게 어떤 가치를 제공하는지 고려하고, 추가된 구성 가능성이 수반하는 복잡성 증가 및 관련 지속적인 유지 보수 비용과 비교하라.

유연성 확보

소프트 코딩이 제공하려는 유연성을 달성하기 위한 여러 합법적인 디자인 패턴이 존재한다. 구성 파일에 적합하지 않은 더 많은 유연성을 요구하는 애플리케이션은 스크립트 언어를 통합함으로써 이점을 얻을 수 있다. 많은 경우, 적절한 디자인은 기존 스크립트 언어에 통합된 도메인 특화 언어이다. 또 다른 접근 방식은 애플리케이션 기능의 대부분을 라이브러리로 이동하여 관련 애플리케이션을 신속하게 작성하기 위한 API를 제공하는 것이다.

같이 보기

• 클로즈드 소스 소프트웨어
• 펌웨어
• 내부 플랫폼 효과
• 최소 권한 원칙
• 자체 수정 코드