PHP를 Java로 바꾸려는 시도를 멈춰라: AI 시대에 Loose Typing이 최고의 자산인 이유
Source: Dev.to
🧠 declare(strict_types=1); 딜레마: 전문성인가 함정인가?
잠시 솔직해집니다. 꼭 필요해서가 아니라 “베스트 프랙티스” 혹은 전문성을 보여주기 위해 declare(strict_types=1); 를 PHP 스크립트에 추가한 적이 얼마나 되나요?
수년간 PHP 커뮤니티는 Symfony 같은 프레임워크와 PSR 표준의 영향을 크게 받아 언어의 전문성을 끌어올리려 노력해 왔습니다. 우리는 PHP가 Java나 C# 만큼 견고해지길 바랐고, 반환 타입, 타입이 지정된 프로퍼티, 엄격한 예외 처리 등을 열렬히 도입했습니다. “타입 재지정”(type juggling) — 예를 들어 문자열 "10"을 정수 5와 더하는 자동 타입 변환 — 은 근본적으로 잘못됐으며, 잡기 어려운 버그의 온상이라고 배웠습니다.
하지만 새로운 패러다임이 펼쳐지고 있습니다. 생성형 AI와 대형 언어 모델(LLM)의 폭발적 성장으로, 완벽한 코드 계약이라는 결정론적 세계가 확률적 현실에 자리를 내어주고 있습니다.
그렇다면 여러분이 억제하도록 배운 PHP의 “유연성”이 바로 AI 환각이라는 예측 불가능한 현상으로부터 PrestaShop 스토어 같은 애플리케이션을 보호하는 핵심이 될 수도 있지 않을까요?
⚡ 웹 현실 vs. 코드 순수성: 끊임없는 줄다리기
인터넷은 본질적으로 혼돈입니다. 우리는 이를 자주 간과합니다.
- 기본적인 HTTP 프로토콜은 주로 텍스트로 통신합니다.
- HTML 폼은 사용자 입력을 문자열로 전송합니다.
- MySQL 같은 데이터베이스는 숫자를 나타내는 경우에도 값을 문자열로 반환하는 경우가 많습니다.
PHP는 이러한 디지털 혼돈을 위한 궁극적인 “접착제”로 탄생했습니다. 그 핵심 철학은 언제나 수용적이었습니다: “입력이 완벽하게 포맷되지 않더라도 당신의 의도를 최선을 다해 이해하겠다.”
절대적 제어의 환상
현대 “클린 코드” 철학은 종종 타협 없는 경직성을 옹호합니다. 코드가 int 를 기대하는데 문자열 "42" 가 들어오면, 일반적인 지혜는 TypeError 예외를 통해 즉시 충돌하도록 합니다. 이러한 엄격함은 내부 비즈니스 계산(예: 부가세 계산)에는 귀중하지만, 애플리케이션의 주변부—입출력 경계—에서는 오히려 부채가 됩니다.
왜일까요? 소프트웨어가 현실 세계(타사 API, 공급업체 CSV 파일, 직접 사용자 입력)와 맞닿을 때, 그 현실은 여러분이 정교하게 정의한 타입을 거의 따르지 않기 때문입니다.
그리고 이 “현실 세계” 데이터 교환에서 가장 예측 불가능한 참여자는 바로 인공지능입니다.
🚀 AI가 규칙을 깨뜨릴 때: 예측 불가능함을 받아들인다
AI 모델(예: GPT‑5)을 PrestaShop 모듈 같은 시스템에 통합하는 것은 뛰어나지만 가끔은 괴짜인 파트너와 협업하는 것과 같습니다.
예를 들어 OpenAI API에 제품 설명을 위한 JSON을 생성하도록 요청하면서 명시적으로 “weight 필드는 정수이며, 단위는 그램이다.” 라고 지정할 수 있습니다.
- 열 번 중 아홉 번은 AI가
{"weight": 500}을 반환합니다. - 열 번째에는 환각이나 미세한 오해 때문에
{"weight": "500g"}혹은{"weight": "approximately 500"}와 같이 반환할 수 있습니다.
엄격한 아키텍처의 취약성
엄격한 타입을 강제하는 언어(Java, Go, 혹은 strict mode의 PHP)에서는 다음과 같은 예측 가능한 결과가 발생합니다:
- DTO가
int를 기대한다. - API가
string을 반환한다. Fatal Error혹은Uncaught TypeError가 발생한다.- 전체 프로세스가 중단되고, 제품이 생성되지 않는다.
그 후 오류 핸들러를 구현하고, 실패를 로그에 남기며, 필요시 요청을 재시도해야 합니다—시간과 자원을 소모하게 됩니다.
숨은 영웅: PHP의 타입 강제 변환
이에 반해 PHP는 숙련된 통역가처럼 동작합니다. 타입 강제 변환(type coercion) 을 활용해, 기대되는 슬롯에 맞게 데이터를 즉석에서 변환해 버립니다.
weight = $weight;
}
}
// Imagine AI response:
$data = ['weight' => '1.5 kg'];
try {
$feature = new ProductFeature();
// Application CRASHES HERE:
// Argument 1 passed to setWeight() must be of type int, string given
$feature->setWeight($data['weight']);
} catch (\TypeError $e) {
// Data is lost; error must be manually addressed...
Logger::log("AI supplied malformed data again");
}적응형 접근법 (PHP의 장점)
weight = $weight;
$product->save();
}
}왜 이 방법이 AI 통합에 뛰어난가
- 중단 없는 워크플로 – 사소한 타입 불일치가 더 이상 가져오기 과정을 멈추게 하지 않는다.
- 간편한 정제 – PHP의 캐스팅이 자동으로 숫자 부분을 추출해 보일러플레이트 코드를 줄여준다.
- 빠른 개발 – AI가 만들어낼 수 있는 모든 가능한 포맷에 대해 맞춤형 변환 함수를 만들 필요가 없다.
이 철학은 PrestaShop 같은 견고한 플랫폼에 깊이 스며들어 있습니다. 예를 들어 Tools::getValue('param') 은 파라미터가 없거나 예상치 못한 타입이라도 절대 실패하지 않으며, 서비스 회복력을 자연스럽게 구축합니다.
🌍 내일의 개발자: “혼돈 관리자”
수십 년 동안 우리는 건축 순수주의자처럼 훈련받아, 각 코드 블록을 완벽히 맞추어야 한다고 배워왔습니다. 어느 하나라도 벗어나면 전체 구조를 거부하는 것이 당연했습니다.
AI 시대에는 혼돈 관리자(Chaos Manager) 로 진화해야 합니다.
AI는 창의적이고 강력하지만 대부분 비구조적인 데이터의 홍수를 만들어냅니다. 우리의 목표는 경직된 장벽(엄격한 타입)으로 이 흐름을 막는 것이 아니라, 유연한 관(느슨한 타입)을 통해 데이터를 우리 데이터베이스에 행동 가능한 깨끗한 형태로 전달하는 것입니다.
AI 통합에서 가장 성공적인 개발자는 순수주의자가 아니라, 데이터의 불완전성을 받아들이고 가장 관대한 도구를 활용해 이를 처리하는 사람일 것입니다.