docs: write (how Kotlin JDSL is different from jOOq and QueryDSL) FAQ document

docs/en/faq/how-can-i-see-the-generated-query.md

@@ -4,7 +4,7 @@ Kotlin JDSL prints queries and parameters generated by DSL to the debug log. So
 
 Because the parameters contained in the log are printed through the `toString` function, it can be difficult to identify the values unless `toString` function is overridden.
 
-```
+```kotlin
 select(
     path(Book::isbn),
 ).from(

docs/en/faq/how-kotlin-jdsl-is-different-from-jooq-and-querydsl.md

@@ -0,0 +1,35 @@
+# How is Kotlin JDSL different from jOOQ and QueryDSL?
+
+Unlike jOOq and QueryDSL, Kotlin JDSL does not generate a `Metadata Model (code generation) for writing queries.
+
+If you use code generation, you'll have to do the following:
+
+```
+Modify tables and entities →
+Entity modification causes compile errors →
+Run Manven or Gradle task to regenerate the metadate →
+Write query based on modified entity
+```
+
+Then you might think about trying JPQL yourself, but that might not be a good idea.
+
+JPQL uses a string-based way of writing queries, which makes it impossible to detect errors at compile time.
+
+However, the Kotlin JDSL uses code generation and pure code-based query construction rather than string-based construction.
+
+This means that as soon as you modify an entity or field name, it is reflected in the query code, and the above inconvenience does not exist.
+
+It also adopts an ORM-based object-oriented query like JPQL, which supports specifications such as polymorphism and fetch joins.
+
+Therefore, the way we write queries also relies on object names and fields to query, rather than querying the table/column itself.
+
+Below is a table comparing the differences between Kotlin JDSL, QueryDSL, and jOOQ.
+
+
+
+|                      | Kotlin JDSL | QueryDSL                                       | jOOQ                                           |
+|----------------------|-------------|------------------------------------------------|------------------------------------------------|
+| Code Generation      | ❌           | ✅                                              | ✅                                              | ✅ |
+| How to write queries | JPQL        | SQL, SQL, JPQL                                 | SQL                                            |
+| Language support     | Kotlin      | All JVM languages including Java, Kotlin, etc. | All JVM languages including Java, Kotlin, etc. |
+| Type Stability       | ✅           | ✅                                              | ✅                                              | ✅ |

docs/ko/faq/how-can-i-see-the-generated-query.md

@@ -4,7 +4,7 @@ Kotlin JDSL은 DSL를 통해 생성된 쿼리 및 파라미터를 debug 로그
 
 로그에 포함된 파라미터의 경우 `toString` 함수로 출력되기 때문에 만약 `toString` 함수가 오버라이드 되지 않았다면 식별에 어려움이 있을 수 있습니다.
 
-```
+```kotlin
 select(
     path(Book::isbn),
 ).from(

docs/ko/faq/how-kotlin-jdsl-is-different-from-jooq-and-querydsl.md

@@ -0,0 +1,33 @@
+# Kotlin JDSL은 jOOQ, QueryDSL와 무엇이 다른가요?
+
+jOOq와 QueryDSL과 다르게 Kotlin JDSL의 경우 쿼리 작성을 위해 `Metadata Model(코드 제너레이션)`을 생성하지 않습니다.
+
+코드 제너레이션 방식을 사용하면 다음과 같은 수고로움이 있습니다:
+
+```
+테이블과 엔티티 수정 →
+엔티티 수정으로 컴파일 오류 발생 →
+메타데이터를 다시 생성하기 위해 Manven 또는 Gradle 작업 실행 →
+수정된 엔티티를 기반으로 쿼리 작성
+```
+
+그러면 아마도 우리는 JPQL을 생각해볼 수도 있지만 이는 좋은 생각이 아닐 수 있습니다.
+
+JPQL은 문자열 기반의 쿼리 작성 방식을 사용하기 때문에, 컴파일 시점에 오류를 감지할 수 없습니다.
+
+하지만 Kotlin JDSL은 코드 제너레이션 방식과 문자열 기반 작성이 아닌 순수한 코드 기반으로 쿼리를 작성합니다.
+
+즉, 엔티티나 필드 이름을 수정하는 즉시 쿼리 코드에 반영이 되어 위와 같은 불편함이 존재하지 않습니다.
+
+또 JPQL과 같이 ORM 기반의 객체지향 쿼리를 채택하고 있어서 다형성, Fetch 조인 등의 스펙을 지원합니다.
+
+따라서 쿼리를 작성하는 방식 또한 테이블/컬럼 자체에 쿼리를 하는 것이 아닌 객체명과 필드에 의존하여 쿼리를 합니다.
+
+아래는 Kotlin JDSL과 QueryDSL, jOOQ의 차이점을 비교한 표입니다.
+
+|          | Kotlin JDSL | QueryDSL                 | jOOQ                     |
+|----------|-------------|--------------------------|--------------------------|
+| 코드 제너레이션 | ❌           | ✅                        | ✅                        |
+| 쿼리 작성 방식 | JPQL        | SQL, JPQL                | SQL                      |
+| 언어 지원    | Kotlin      | Java, Kotlin 등 모든 JVM 언어 | Java, Kotlin 등 모든 JVM 언어 |
+| 타입 안정성   | ✅           | ✅                        | ✅                        |