Ktor 2.0이 출시되었다는 기쁜 소식을 전해 드립니다. 약 1년의 작업 끝에 마침내 결실을 맺었군요!  Ktor 2.0에는 많은 새로운 기능이 도입되었지만, 주요 버전인 만큼 획기적인 변경 사항이 적용되었고, 일부 유지 관리 작업과 더불어 기존에 잘못된 결정을 철회하는 기회로도 삼았습니다. 대대적인 변경이 있었지만 이를 최소화하려고 노력했고 자동화된 마이그레이션에 도움이 될 수 있는 일부 지원 도구도 제공되니 염려하지 마세요. 먼저 몇 가지 새로운 기능을 살펴보고 그 밖의 내용은 나중에 자세히 알아보도록 하겠습니다. Ktor 서버 단순화된 확장성 Ktor를 빌드할 때는 항상 확장성을 염두에 둡니다. 처음에는 기능이라고 불렀고 지금은 플러그인으로 이름이 바뀌었지만, Ktor가 제공하는 모든 기능은 플러그인 아키텍처를 사용하여 빌드됩니다(이름이 바뀐 이유가 납득되시죠?). 이때 제기된 문제는 어떤 사람들에게는 그 이면에 있는 아키텍처 모델이 난해하다는 것이었습니다. Ktor 2.0에서는 확장성 API를 대폭 간소화하여 플러그인을 훨씬 쉽게 만들 수 있도록 했습니다.  1.x의 다음 API 코드를 살펴보세요. companion object F

2022년으로 접어든 지도 한 달이 지난 지금, Ktor 팀은 Kotlin 2.0에서 맡은 소임의 마무리 작업에 집중하고, Kotlin 1.6.20이 릴리스되기를 기다리며, 2.0 릴리스를 준비하고 있습니다. 이와 동시에 차기 추진할 작업도 계획하고 있습니다. 아시는 분도 계시겠지만 우리는 2020-2021년 로드맵을 발표했고, 모두 계획대로 되지는 않았지만 그럭저럭 잘 해냈습니다. 그러나 실제로 우리의 능력을 넘어 무리하게 계획한 부분도 있었다는 점을 깨달았습니다.  이러한 경험을 토대로 우리는 기한이 정해진 로드맵에 대한 전체적인 접근방식의 효과를 신중하게 검토해 보았습니다. 로드맵은 확실히 업계 표준이고 JetBrains에서도 많은 사람들이 이를 실행하지만 동시에 자체적인 문제도 가지고 있습니다. 특히, 이 방식은 우리가 상황을 아주 잘 추정할 수 있다는 가정을 기반으로 할 뿐만 아니라 진로 수정을 불가피하게 만드는 외부적 요인이나 방해 요소를 고려하지 않습니다. 로드맵의 목적은 팀이 앞으로의 과제에 집중하고 고객에게 우리가 기울이는 노력에 대해 알려주는 데 있으므로, 특정 연도에 얽매이지 않는 새로운 접근방식을 채택하기로 결정했습니다. 앞으로