style: proofread the difference docs

docs/en/SUMMARY.md

@@ -17,3 +17,4 @@
 ## FAQ
 
 * [How can I see the generated query?](faq/how-can-i-see-the-generated-query.md)
+* [What is the difference between Kotlin JDSL and jOOQ and QueryDSL?](faq/what-is-the-difference-between-kotlin-jdsl-and-jooq-and-querydsl.md)

docs/en/faq/what-is-the-difference-between-kotlin-jdsl-and-jooq-and-querydsl.md

@@ -0,0 +1,25 @@
+# What is the difference between Kotlin JDSL and jOOQ and QueryDSL?
+
+Unlike jOOQ and QueryDSL, Kotlin JDSL does not need a `Metadata Model` for building queries.
+
+Creating a metadata model typically involves code generation, which comes with several disadvantages:
+
+- It increases the complexity of the initial project setup.
+- It adds an extra step of metadata generation to the regular build process.
+
+Although the first disadvantage can be solved through various plugins and references, the second one cannot. Using a code generator requires additional steps between entity modification and query building, which can interrupt a developer's working:
+
+```
+1. Modify tables and entities.
+2. The modifications causes compile errors.
+3. Run Maven or Gradle task to regenerate the metadata model.
+4. Build queries based on the modified entities.
+```
+
+Despite these disadvantages, jOOQ and QueryDSL are still popular because they provide type safety, which allows the developer to catch errors in the query at compile time. Kotlin JDSL provides this type safety without the need for a metadata model.
+
+Kotlin JDSL supports the building of type-based queries using Kotlin's KProperty. There is no need to worry about performance impact due to reflection because Kotlin JDSL uses only the names of KProperties, and when Kotlin compiles to Java, it registers these names as constants.
+
+In addition, KProperty allows automatic detection of field changes by the IDE, ensuring that any changes to class field names are reflected immediately.
+
+In summary, Kotlin JDSL overcomes the disadvantages of the metadata model used by jOOQ and QueryDSL, while retaining the benefits of type safety, and without any performance impact, enabling efficient and reliable query building.

docs/ko/SUMMARY.md

@@ -17,3 +17,4 @@
 ## FAQ
 
 * [How can I see the generated query?](faq/how-can-i-see-the-generated-query.md)
+* [What is the difference between Kotlin JDSL and jOOQ and QueryDSL?](faq/what-is-the-difference-between-kotlin-jdsl-and-jooq-and-querydsl.md)

docs/ko/faq/what-is-the-difference-between-kotlin-jdsl-and-jooq-and-querydsl.md

@@ -0,0 +1,24 @@
+# Kotlin JDSL과 jOOQ, QueryDSL의 차이점은 무엇인가요?
+
+Kotlin JDSL은 jOOQ와 QueryDSL과 달리 메타 모델(Metadata Model)을 요구하지 않습니다.
+
+메타 모델을 생성하기 위해 일반적으로 코드 생성(code generation)을 활용하는데, 이 방식은 몇 가지 단점이 있습니다.
+
+- 프로젝트 초기 설정의 복잡성이 증가합니다.
+- 일반적인 빌드 프로세스에 메타데이터 생성 단계가 추가됩니다.
+
+첫 번째 단점은 여러 플러그인과 레퍼런스를 통해 해결할 수 있지만, 두 번째 단점은 그렇지 않습니다. 코드 생성 방식을 사용하면, 엔티티 수정과 쿼리 작성 사이에 다음과 같은 추가 작업이 요구되며, 이는 개발자의 작업 흐름을 방해할 수 있습니다.
+
+```
+1. 테이블과 엔티티 수정
+2. 엔티티 수정으로 인한 컴파일 오류 발생
+3. 메타데이터를 재생성하기 위해 Maven 또는 Gradle 작업 실행
+4. 수정된 엔티티를 기반으로 쿼리 작성
+```
+이러한 단점에도 불구하고 jOOQ와 QueryDSL이 인기 있는 이유는 타입 안전성을 제공하여 컴파일 시점에 쿼리 오류를 발견할 수 있게 해주기 때문입니다. Kotlin JDSL은 메타 모델을 요구하지 않으면서도 이러한 타입 안전성을 제공합니다.
+
+Kotlin JDSL은 Kotlin의 KProperty를 활용하여 타입 기반의 쿼리를 작성할 수 있도록 지원합니다. KProperty를 사용함에도 리플렉션으로 인한 성능 저하를 걱정할 필요가 없는데, 이는 Kotlin JDSL이 KProperty의 이름만을 사용하며, Kotlin이 Java로 컴파일할 때 이 이름을 상수로 등록하기 때문입니다.
+
+또한, KProperty는 IDE를 통해 필드 변경을 자동으로 감지할 수 있어, 객체의 필드명이 변경되더라도 즉시 반영됩니다.
+
+Kotlin JDSL은 jOOQ와 QueryDSL이 가진 메타 모델의 단점을 해소하면서도, 성능 저하 없이 그들이 제공하는 타입 안전성의 장점을 유지하며 쿼리를 작성할 수 있게 해주는 라이브러리입니다.