효율도 포함되지만 근본적인 이유는 아님.
라이브러리야 Java로 만들어진게 Python에서 작동할 수가 없다 정도로만 설명하고 (그렇다고 그것도 돌려버리면 라이선스 문제가 발생할 수도),
예를 들어 객체 지향인 Java로 짠 코드를 절차지향인 C로 컴파일 하려고 든다면 아마 난리가 날 수 있음. 두 언어의 패러다임 자체가 다르거든. 그 과정에서 최적화도 망가질 수 있지만 중요한건 전체적 구조가 망가질 수 있다는거임.
실제로 돌려보면 대충 알 수 있음. 이게 당최 무슨 소린지... 싶은 코드가 튀어나올꺼임
비슷한 패러다임을 가진 언어 사이에서는 좀 더 나은 결과물이 나올 수는 있음. 근데 이것도 언어 특성에 따라 결과물이 달라짐. 그 언어 입장에서는 단점을 개선해서 훨씬 나은 방법이 있을 수도 있는건데 트랜스컴파일러 입장에서는 그런걸 다 고려하기는 힘드니까 이른바 구식 방법을 쓰게되는 문제점도 생김.
결론은 원래 컴파일해서 쓰라고 만든 언어 사이가(c <-> 어셈블리 <-> 기계어, javascript <-> typescript 등) 아니라면 억지로 우겨넣는 과정에서 코드가 망가진다는 것.
위에서 설명은 많이 한 거 같아서 역사적으로 그나마 유명한 예시를 좀 들자면
1. 최초의 C++ 컴파일러는 사실 C++ 코드를 C 코드로 바꿔준 뒤에 C 컴파일러를 돌리는 식으로 구현이 돼 있었음. 이거도 C++ -> C로 바꾸는 거니까 트랜스컴파일러라 볼 수 있지 않을까
2. 현재 Typescript 컴파일러는 사실 코드를 javascript로 바꿔주는 역할만 함
3. LLVM 백엔드에 의존하는 언어 (clang을 쓰는 C/C++, Rust, Swift 등등)는 프론트엔드가 원본 언어를 LLVM IR (컴파일러 최적화를 위한 중간 언어)로 변환해줌
4. Tensorflow는 TF 언어를 MLIR이라는 중간 언어로 변환해서 최적화를 수행함