Kotlin언어을 개발했고, 개발 환경 IDE로 유명한 Jetbrain사에서 개발한 경량 웹 프레임워크인 Ktor를 이용한 간단한 REST-API서버 개발 소개 글입니다. Ktor는 Pivotal사의 Spring 프레임워크에 비해서 상당히 경량화된 프레임워크(AOP,DI같은 고급(?) 기능들은 지원하지 않습니다.)이고, 코틀린과 코루틴에 대한 기본 지식이 있다면 러닝 커브가 낮습니다. REST API서버를 실행하기 위한 기본적인 프로젝트 셋업 및 상용 배포를 위한 설정(배포 환경에 따른 설정 파일 분리, 데이터독 로그 연동을 위한 설정 등등..)위주로 알아 보겠습니다.Ktor는 다음과 같은 독특한 특징을 가지고 있습니다.• None Ktor는 Kotlin의 코루틴을 활용하여 비동기 처리를 기본적으로 지원합니다. 이는 성능을 향상시키고, 리소스 사용을 최적화하는 데 도움이 됩니다.• None Ktor는 Kotlin의 멀티플랫폼 기능을 활용하여 JVM뿐만 아니라 Kotlin/Native, Kotlin/JS 등 다양한 플랫폼에서 사용할 수 있습니다. 이는 다양한 환경에서의 애플리케이션 개발을 용이하게 합니다.• None Ktor는 설정이 간편하고 경량 서버로 설계되어 빠르게 구동할 수 있습니다. 이는 빠른 배포와 유연한 확장이 필요한 현대적 MSA(Microservices Architecture) 구조에 적합합니다.위와 같이 좋은 특징을 가지고 있지만, 아직 아쉬운 점도 많은 것이 사실 입니다.• None Ktor의 ecosystem가 개발자 커뮤니티는 아직 한참 확장 중입니다. Spring과 같이 오랜 기간 개발된 프레임워크에 커뮤니티의 성숙도나, 지원하는 third-party 패키지들이 아직 부족합니다.• None 출현한지 얼마 되지 않은 프레임워크인 관계로 Best Practice나 몇몇 기능들은 아직 아쉬운 부분들이 있습니다.아쉬운점들도 있지만, 저같은 경우 위의 특징들중 첫번째와 3번째 특징 때문에 관심을 가지게 되었고,팀에서 마침 AI Divergency프로젝트 때문에 MAS 컴포넌트 추가가 필요해서 프로젝트 셋업 작업을 진행 했고, 작업후 내용 정리 및 공유 차원에서 글을 작성 하는 중입니다.Ktor프로젝트 셋업을 위해서는 초기 프로젝트 생성용 싸이트를 이용하는 방법과 IntelliJ IDE를 이용하는 방법이 있습니다ktor에서 공식적으로 제공하는 프로젝트 생성 싸이트 https://start.ktor.io/settings 에 접속 합니다.이 싸이트에 접속해서 해야할 일은 크게 3가지 입니다.첫번째와 세번째에 대한 설명은 생략하도록 하겠습니다.(적절하게 입력해 주세요)두 번째 플러그인들 선택에 대해서 알아 보도록 하겠습니다.이외에도 DefaultHeaders, Forwared Headers, Static Content, CORS, DoubleReceive등등도 나중에 필요한 경우가 있을수 있을꺼 같지만,우선 단순한 REST API서버 개발을 목표로 한다면 위의 목록만으로도 충분 합니다.플러그인 선택까지 마친 후 download를

geuru.geon DevSecOps에서 Sonarqube가 어떤 역할을 하는지 쉽게 파악할 수 있는 글입니다! 평소 Sonarqube 도입에 대해 고민하고 계셨다면, 이번 기회에 안전한 코드로 서비스를 운영해 보시는 건 어떨까요? 😀owen.kh DevSecOps 환경 구성을 위해 카카오페이는 어떤 방향성를 가지고 있는지 알기 좋은 글입니다. 관련해 비슷한 고민을 하는 많은 담당자 분들께 도움이 되었으면 좋겠습니다~안녕하세요, 카카오페이 SRE팀 RE파트 데이빗입니다. 오늘은 DevSecOps와 Sonarqube에 대해 깊이 있게 알아보려고 해요. 어렵게 들리시나요? 걱정 마세요. 차근차근 설명해 드릴게요.DevSecOps가 뭔가요?DevSecOps는 Development(개발), Security(보안), Operations(운영)을 하나로 뭉친 말인데요. 쉽게 말해 “우리 처음부터 끝까지 보안에 신경 쓰면서 개발하자!”라는 뜻이에요. 예전에는 개발을 다 하고 나서 “자, 이제 보안 점검 좀 해볼까?” 하는 식이었어요. 마치 집을 다 짓고 나서 “앗, 도둑이 들어올 수 있겠네. 자물쇠를 달아야겠다!”라고 하는 것과 비슷하죠. DevSecOps는 집을 설계할 때부터 보안을 고려하는 거예요. “이 창문은 좀 위험해 보이니 특수 유리를 쓰자”, “현관문은 이중잠금장치로 하자” 이런 식으로요. 개발할 때도 코드 한 줄 쓸 때마다 “이 로직은 안전한가? 보안에 문제없나?” 생각하면서 만드는 거죠.DevOps와의 차이“그럼 DevOps랑 뭐가 다른데요?”라고 물으실 수 있어요. DevOps가 개발과 운영을 하나로 묶었다면, DevSecOps는 여기에 보안을 더한 거예요. DevOps를 맛있는 케이크를 만드는 과정이라고 생각해 볼까요? 개발팀이 케이크를 구워서 운영팀에게 건네주는 거죠. DevSecOps는 여기에 “케이크에 유해 성분은 없는지, 알러지 유발 물질은 없는지” 확인하는 과정을 추가한 거예요. 더 안전하고 믿을 수 있는 케이크를 만드는 거죠!• 보안을 핵심 요소로 강조• 보안 팀과의 긴밀한 협업전통적인 개발 방식과의 차이전통적인 개발은 마치 릴레이 경주 같았어요. 개발팀이 달리고, 그다음 보안팀이 달리고, 마지막으로 운영팀이 달리는 식이었죠. DevSecOps는 달라요. 세 팀이 손을 잡고 같이 달리는 거예요. 시작부터 끝까지 함께 가는 거죠. 이러면 중간에 실수가 생겨도 빨리 발견할 수 있고, 서로 도와가며 더 빠르고 안전하게 목표에 도달할 수 있어요.DevSecOps를 실제로 구현하려면 어떻게 해야 할까요? 세 가지 핵심 요소가 있어요.자동화와 보안 통합은 DevSecOps의 핵심 요소예요! 자동화는 수동으로 수행하던 많은 보안 관련 작업들을 자동화함으로써 효율성을 높이고 인적 오류를 줄일 수 있어요. 예를 들어 볼까요? 여러분이 매일 아침 100개 이상의 보안점검을 한다고 생각해 보세요. 끔찍하죠? 하지만 보안점검을 진행하고 리포트해 주는 서비스가 있다면 어떨까요? 버튼 하나만 누르면 카테고리와 점검 요약 정보들로 알려주니 훨씬 편

yun.cheese 코틀린 매력에 푹 빠진 개발자의 생생한 경험을 통해, 실제 서비스 개발에 바로 적용할 수 있는 코틀린 활용 꿀팁들을 얻어가세요!noah.you 복잡한 보험의 요구사항들을 해결하기 위한 이유 있는 코틀린 사용 사례! 좋은 사례들 많으니 많이 보고 가세요!ari.a 카카오페이에서는 왜 서비스의 백엔드를 개발할 때 코틀린을 사용하는 걸까요? 궁금하신 분들에게 카펀의 코틀린 사용 사례를 추천드립니다!안녕하세요. 카카오페이 보험마켓파티에서 보험 비교 추천, 내 차 관리 서비스 등을 개발하고 운영하는 카펀입니다.여러분은 어떤 언어를 사용하여 개발을 하고 계신가요? 카카오페이에서는 저희 보험 서비스를 비롯한 다양한 서비스의 백엔드 서비스 개발에 코틀린을 사용하고 있습니다.카카오페이에 합류하기 전에는 코틀린을 경험해 본 적이 없었지만, 실제로 사용하면서 코틀린의 다양한 장점과 편리함에 매료되었습니다. 예를 들면 다음과 같은 코틀린의 매력이 있습니다.• 코틀린을 사용함으로써 서비스를 보다 견고하고 안정적이며, 효율적으로 운영하고 있습니다.• 특정 도메인에 대한 내용을 쉽게 모아서 관리하거나, 저희 서비스만을 위한 라이브러리를 간편하게 만들었습니다.• 목적과 대상이 명확한 테스트 코드 작성 역시 코틀린을 통해 손쉽게 작성하였습니다.카카오페이에 합류해 코틀린으로 여러 서비스를 개발하고 운영하면서 직접 경험한 코틀린의 매력을 소개해 보고자 합니다. 여러 매력 포인트 중 코틀린의 4가지 매력 포인트를 정리했습니다. 저와 마찬가지로 안정적인 웹 서비스 개발에 관심 있는 백엔드 개발자 분들이 읽어 보시면 좋습니다.생성 시 값이 검증되는 객체 만들기어떤 값을 나타내는 VO1를 만들 때, 이따금 입력 값을 변환하거나 검증이 필요한 경우가 있습니다. 검증 로직을 별도 클래스로 분리할 수도 있지만, 매번 별도로 검증 로직을 호출해야 한다면 실수로 검증을 누락할 가능성이 있습니다. 코틀린의 다양한 기능을 활용하여 간결하면서도, 검증을 통과하였음이 보장되도록 작성하는 예시를 소개합니다.자동차 번호를 나타내는 VO가 있습니다. 코틀린의 Value Class를 사용합니다.Value Class는 코틀린에서 값을 나타내기 위한 wrapper 클래스입니다. 단 하나의 불변 필드만을 가질 수 있고, JVM 환경에서 컴파일 시 class를 벗겨 내고 내부의 값으로 대체합니다. 덕분에 primitive 타입의 값을 객체와 같이 다룰 수 있으며, 동시에 wrapper 클래스 사용 시의 오버헤드 문제를 해결할 수 있습니다. 자세한 내용은 Reference의 Project Valhalla 내용을 확인해 주세요.자동차 번호에는 아래와 같은 규칙이 있다고 가정하겠습니다.• 자동차 번호 형식은 아래 중 하나여야 함인스턴스 생성 시, 아래 과정을 거치고 싶습니다.• 지역명은 주어진 목록 내에서만 사용 가능(서울, 경기, 대전 등등), 아닐 경우 예외 발생• 지역명이 없는 경우 앞 숫자는 2~3자리, 뒤 숫자는 4자리• 지역명이 있는 경우 앞 숫자는 1~2자리, 뒤 숫자는 4자리이를

안녕하세요, 전자문서 서비스의 서버를 개발하고 있는 Alan입니다.스프링(Spring)으로 서버를 개발하다 보면 데이터베이스를 사용하는 경우가 곧잘 있습니다. 이때 트랜잭션 처리를 직접 구현하기보다는 스프링의 지원을 받아 구현하는 것이 일반적인 과정입니다. 특히, 트랜잭션의 처리 방식을 정확하게 알지 못하더라도 프레임워크가 모든 과정을 대신 처리해 주기 때문에 러닝 커브가 낮다는 것이 큰 장점인데요. 그러다 보니 지나치게 프레임워크에 의존하여 안전하지 않은 코드를 무심코 작성하게 되는 경우가 종종 있는 것 같습니다.이번 글에서는 독자분들께 통상 효과적인 처리 방식이라 생각하는 스프링 프레임워크를 통한 트랜잭션 처리가 잠재적으로 가져올 수 있는 위험성을 소개하고 살펴보겠습니다. 또한, 이 문제를 해결하기 위한 방법으로 최근 스프링과 조합되어 사용되는 비중이 점차 증가하고 있는 코틀린(Kotlin)을 활용하여 잠재된 위험성을 줄이는 방식 또한 알아보도록 하겠습니다.프로그램의 효과현대의 프로그램은 격리된 환경에서 단독으로 실행되는 것이 아니라 사용자의 다양한 요구사항에 맞추어 데이터베이스에서 정보를 읽거나, 다른 프로그램과 HTTP 프로토콜을 사용한 통신으로 데이터를 주고받습니다. 이렇게 프로그램이 외부 세계와 상호 작용하는 것을 통칭 ‘효과’라고 부릅니다.아래 코드 예시와 같이, 전통적인 프로그램은 외부 세계와 상호 작용을 처리하는 컨텍스트(Context)를 함수에 직접 전달해야 했습니다.이러한 방식은 함수가 어떤 효과를 수행할 것인지 명시적으로 표현할 수 있지만, 개발자가 모든 과정을 하나하나 처리해야 한다는 단점이 있습니다. 예를 들어 데이터베이스에 데이터를 저장하려면 트랜잭션을 시작하고, 데이터를 저장하고, 트랜잭션을 커밋하는 과정을 모두 직접 처리해야 합니다. 게다가 코드의 실행 과정에서 예외가 발생할 수도 있으므로 이를 대비한 방어 로직 또한 작성해야 합니다.최근에는 개발자가 이러한 과정을 직접 구현하기보다는 프레임워크에게 처리를 일임하는 것이 각광받고 있습니다. 특히 백엔드 개발에서 주로 사용하는 스프링은 이 효과를 손쉽게 처리할 수 있도록 DI와 AOP를 지원합니다.아래 예시와 같이, 스프링 프레임워크에선 함수에 @Transactional 어노테이션을 추가하기만 하면 트랜잭션의 모든 과정을 스프링이 대신 처리하도록 구현이 가능합니다. AOP를 통한 효과를 처리하는 방법은 굉장히 유용하기는 하지만, 아쉬운 부분도 있습니다. 바로 모든 클래스와 함수에 어노테이션을 아무런 제약이 없이 설정할 수 있다는 점입니다. 이러한 유연성은 엉뚱한 곳에 효과를 부여하거나 반대로 반드시 필요한 곳에는 효과를 부여하지 못하는 부작용(Side effect)을 가져올 수 있습니다.그렇다면 효과를 안전하게 처리하려면 어떻게 해야 할까요? 전통적인 방식에서는 효과 처리에 지나친 자율성이 부여되었기 때문에 작성된 코드의 동작을 예측하기 어렵게 만들었습니다. 따라서, 이러한 생각을 스프링 프레임워크에서도 도입하여 자율성을 제약한다면, 코드의 동작을 보다 예측 가능하도록 변경할 수 있을 것입니다.지금부터는 코틀린을 활용하여 안전하게 효과를 처리하는 방법을 알아보도록 하겠습니다.코틀린에서 제약 조건을 설정하는 방법은 바로 확장 함수(Extension function)를 정의하는 것입니다.확장 함수는 함수의 이름 앞에 수신 객체 타입을 지정하여 정의할 수 있습니다. 확장 함수는 이름처럼 수신 객체 타입에 기능을 추가하는 용도로도 쓰이지만, 반대로 생각하면 확장 함수를 해당 수신 객체가 있을 때만 사용할 수 있도록 제약하는 방식으로도 사용할 수도 있습니다.save 함수에 DatabaseContext라는 수신 객체 타입을 설정하면 컨텍스트 없이는 단독으로는 save 함수를 호출할 수 없습니다.이제 코틀린의 확장 함수를 사용해서 스프링 예제 코드를 개선해 보도록 하겠습니다. 코드의 요구사항은 아래와 같습니다.• 상품을 삭제하는 프로그램을 개발한다.• 상품을 삭제하는 함수는 반드시 트랜잭션 범위 안에서만 호출해야 한다.스프링에서는 함수를 트랜잭션 범위 안에서만 호출할 수 있도록 만들고 싶다면 아래와 같이 @Transactional 어노테이션을 추가하고 MANDATORY 옵션을 설정하기만 하면 됩니다.그런데 만약 @Transactional 어노테이션이 누락된 채로 코드가 작성되었다면 어떤 위험이 있을까요? AOP 방식의 트랜잭션은 컴파일 타임에는 호출 관계에 대한 문법 에러를 감지할 방법이 없습니다. 따라서 런타임에 함수를 호출하게 되면 서버에서 에러가 발생하게 됩니다.그렇다면 이 문제를 해결할 수 있는 근본적인 해결책은 무엇일까요? 가장 좋은 방법은 요구 사항 그대로 트랜잭션이 없는 경우, 컴파일 타임에 에러가 감지되도록 하여 개발자의 실수를 방지하는 것입니다. 이때, 아래 예시와 같이 코틀린을 사용한다면 delete 함수에 트랜잭션을 처리해 줄 특별한 컨텍스트를 지정하여 이 목표를 쉽게 달성할 수 있습니다.개선된 코드에서는 delete 함수에 @Transactional을 지정하는 대신에 DatabaseContext를 수신 객체 타입으로 지정하였습니다. 지금부터는 확장 함수의 특성으로 인해 DatabaseContext와 ProductComponent가 모두 주입된 영역에서만 delete 함수를 호출할 수 있습니다. 즉, 잘못된 코드를 억지로 사용하고 싶어도 컴파일 과정에서 문법 에러가 감지되어 컴파일이 실패하게 됩니다. 이는 기존에는 런타임 시점에서야 감지할 수 있었던 에러가 원천적으로 차단될 수 있다는 것을 시사하며, 효과를 안전하게 처리하는 방식에 한 발짝 가까워졌음을 의미합니다.고차 함수로 효과 함수 전달코틀린은 함수를 인자로 받거나 리턴할 수 있는 고차 함수를 지원합니다. 코틀린의 고차 함수를 적용한 예시는 아래와 같습니다.기존에 살펴보았던 delete 함수는 이제 상품을 직접 삭제하는 것이 아니라, 상품을 삭제하는 함수를 리턴하는 고차 함수로 작성되었습니다. 물론 리턴되는 함수에도 DatabaseContext가 수신 객체 타입으로 지정할 수 있기 때문에 제약 사항도 잘 지켜지고 있습니다.효과 함