에이닷에서 파인튜닝을 통해 각 도메인별 특화 데이터를 추가 학습시켜 맞춤형 모델을 만들고 있지만실시간으로 업데이트 되는 동적인 데이터에 대한 대응 그리고 할루시네션 억제, 모델 외부 데이터의 대한 접근을 위해서는 RAG 기능 활용하는게 옳은 선택이라고 합니다.RAG 기능 구현에 있어 VectorDB는 필수 솔루션이며, 여러 VectorDB 중에서 현재 플랫폼에서 스테이징으로 이용하고 있는 Qdrant 구축 내용을 공유하고자 합니다.일반적인 Cloud 솔루션, Kubernetes , Docker 방식이 아닌 정통(?) 방식의 source tarball를 이용한 컴파일 및 Qdrant Cluster 구성방식 입니다.위 링크 내용과 같이 Qdrant 설치에 있어 추천하는 Production 방식은 Qdrant Cloud, Kubernetes Helm, Qdrant Kubernetes Operator, Docker and Docker Compose 입니다.플랫폼에서는 대부분 On-premise 환경을 이용하기 때문에 Kubernetes와 Docker 방식이 적합한걸로 판단되었습니다.현재 내부 정책상 Redis, MongoDB, MySQL, Kafka 등 플랫폼에서 사용하는 주요 stateful 솔루션은 독립된 서버 호스트를 이용 Cluster로 구성하여 이용하고 있습니다.단일 솔루션의 장애가 다른 솔루션으로 전파되는걸 방지하는 목적이며, 그렇기 때문에 Kubernetes 방식은 차선택으로 우선순위가 밀리게 되었습니다.Docker 방식으로 구성을 검토하면서, Qdrant github의 Dockerfile 내부에서 소스파일 컴파일을 진행하는걸 확인했습니다.위 내용을 보면서 추가적인 Docker 레이어 없이 프로세스를 직접 컨트롤 할 수 있는 바이너리 형태로 서비스 운영이 가능하다고 판단하여 source tarball를 이용한 소스컴파일로 서비스 구성을 결정하였습니다.소스 컴파일은 Qdrant에서 추천하는 방식은 아닙니다. 그렇기 때문인지 컴파일을 위한 설명이 매우 미비합니다.Qdratn Github의 Dockerfile을 참고하여 컴파일 과정을 이해 하였고 아래 내용부터는 해당 과정을 정리하였습니다.• None Node : Cluster 구성을 위해 Baremetal 노드 3대 (VM구성시 최소 메모리는 6GB 이상 필요)• None 서비스 운영 환경에 따라 스펙이 변경되어야 하므로 상세 스펙은 생략• None 컴파일시 실제 메모리 사용이 6GB이상 발생하는것 확인 되었습니다.• None Network : 각 노드가 Master 역할을 하며, HA 위해 L4 스위치 이용하는걸 추천합니다.라이브러리 및 소스 다운로드로 위해 모든 노드들은 임시로 Outbound Any Open 된 상태가 되어야 합니다.참고로 Qdrant Github releases 에서 x86_64 범용 바이너리를 패키지를 제공하나 RHEL 8.x , RHEL 9.x , CentOS Stream 9 에서는 gcc 및 주요 라이브러리 버전 이슈로 사용이 어렵습니다.Qdrant는 Rus

오피지지는 매년 임직원과 이해관계자를 위한 맞춤형 선물 세트를 디자인을 해왔습니다. 선물을 보내는 이유는 우리의 감사와 존경을 전할 수 있는 중요한 기회이자 단순한 선물이 아닌 진심을 담은 메시지를 전달할 수 있는 기회이기때문입니다. 오피지지는 전달하고자 하는 메시지나 주요 테마에 맞춰 컨셉을 선정하고, 패키징부터 각 개별 아이템까지 세심하게 디자인하죠.오피지지가 지난 2년 간 디자인한 선물 세트를 소개해드리겠습니다.2023년은 60간지 주기의 40번째 해인 검은 토끼의 해였습니다. 2023년도에는 이를 기념하기 위해 검은색 테마로 제작하였습니다. 2023년은 특히 코로나 팬데믹에서 벗어나는 해이기도 했기에, 갇혀 있던 좋은 에너지가 다시 순환하기를 바라는 마음으로 원형의 모티프를 사용했습니다.• 구성원을 위한 특별한 2023 설 선물 : 바로가기OP.GG와 함께 게임을 시작하세요!오피지지는 언제나 새로운 방식으로 게임을 즐길 수 있는 방법을 제공하며, 서드파티 게임 산업에 신선한 에너지를 불어넣고 있습니다. 우리의 궁극적인 목표는 게임이라는 문화를 더 풍부하고 재미있게 만드는 것입니다.선물에서는 순수하게 게임을 즐기던 어린 시절의 향수를 불러일으키고, 그 시절의 기쁨과 행복한 추억을 다시 떠올릴 수 있기를 바랐습니다.• 게임을 담은 오피지지의 추석선물 엿보기! : 바로가기2024년도 첫 선물은 겨울의 추위를 지나 따뜻한 봄을 맞이하는 전환점을 의미하는 선물로 골라봤습니다. 오피지지에게도 새로운 계절을 맞이하기 전에 몸과 마음을 재충전할 무언가가 필요한 시기였죠.2024년 새해 선물의 컨셉은 평온함를 찾고 봄의 태동을 느끼는 아이디어에서 영감을 받았으며, 꽃과 차를 통해 재생의 느낌을 담아내고자 했습니다.• 오감으로 즐기는 오피지지 2024 설 선물 : 바로가기음식은 그 자체로도 훌륭하지만, 올바른 양념이나 향신료를 더하면 요리를 완벽하게 만들 수 있습니다.2024년 긴 연휴 선물의 테마는 ‘마법의 레시피’로, 연휴 동안 가족과 함께 더 맛있는 음식을 즐길 수 있기를 바라며 다양한 향신료를 담은 세트를 제작했습니다. 오피지지 역시 게임업계에서 게임을 더 풍요롭게 하는 향신료와 같은 역할을 하고 있기에 이번 연휴에 잘 어울리는 선물세트라 생각합니다. 이번 ‘마법의 레시피’ 선물 세트를 통해 오피지지가 게임을 풍요롭게 하는 것처럼, 여러분의 연휴도 더욱 풍성하셨기를 바랍니다.지난 2년 동안 오피지지의 아이덴티티를 담아 내외부 구성원분들께 감사의 마음을 전할 수 있어 기뻤습니다. 앞으로도 이러한 감사의 기회를 더 많이 만들어 나가겠습니다. 오피지지가 앞으로도 어떻게 오피지지다움을 보여줄지 지켜봐 주시면 감사하겠습니다.

안녕하세요. Security R&D 팀의 한주홍입니다. 저희 팀은 LY 그룹 서비스의 전반적인 보안을 강화하기 위해 다양한 보안 기술을 연구하고 개발 및 컨설팅하는 업무를 담당하고 있습니다.현재 우리가 사용하고 있는 많은 IT 서비스에서는 안전한 서비스를 제공하기 위해 다양한 암호 기술을 사용하고 있습니다. LY 그룹 역시 종단 간 암호화 기술인 Letter Sealing부터 간편한 사용자 인증을 위한 FIDO(Fast Identity Online), 안전한 백업 시스템 구축 등 사용자가 안심하고 서비스를 이용할 수 있도록 다양한 곳에서 암호 기술을 사용하고 있습니다.그런데 최근 양자 컴퓨터에 관한 연구가 활발해지고 양자 컴퓨터의 개발이 점점 가시화되면서 현재 우리가 안전하다고 믿고 사용하고 있는 암호 기술들의 안전성에 문제가 발생할 수 있게 되었습니다. 이에 대비하기 위해 많은 전문가들이 PQC(Post-Quantum Cryptography)라는 분야를 연구하고 있는데요. 이번 글에서는 양자 컴퓨터의 개발이 현재의 암호 시스템에 어떤 영향을 미치는지, 그리고 양자 컴퓨터의 시대에서는 어떻게 우리의 데이터를 지킬 수 있는지 이야기해 보겠습니다.양자 컴퓨터의 위협에 현대 암호 알고리즘은 안전할까?양자 컴퓨팅은 기존 컴퓨터와는 완전히 다른 방식으로 데이터를 처리하는 컴퓨팅 기술입니다. 현재 우리가 사용하는 컴퓨터는 비트(bit)를 사용해 데이터를 0과 1로 표현하지만, 양자 컴퓨터는 큐비트(qubit)를 사용해 0과 1의 상태를 동시에 가질 수 있습니다. 이러한 특성 덕분에 양자 컴퓨터는 기존 컴퓨터보다 특정 계산을 훨씬 빠르게 처리할 수 있습니다.양자 컴퓨팅의 핵심 개념은 중첩(superposition)과 얽힘(entanglement)입니다. 중첩 상태의 큐비트는 0과 1의 상태를 동시에 가질 수 있어서 병렬 연산을 수행하는 것과 유사한 효과를 낼 수 있습니다. 또한 얽힌 큐비트들은 서로의 상태에 강하게 의존하는데 이때 한 큐비트의 상태가 결정되면 다른 큐비트의 상태도 즉시 결정됩니다. 양자 컴퓨팅의 이와 같은 특성은 양자 컴퓨터가 소인수 분해와 같은 특정 문제들을 매우 빠르게 해결할 수 있게 만듭니다.2023년에 evolutionQ의 Michele Mosca와 Marco Piani 박사가 Global Risk Institute 라이선스로 발행한 QUANTUM THREAT TIMELINE REPORT 2023 보고서에 따르면, '키의 크기가 2048비트인 RSA 암호를 한 시간 안에 깰 수 있는 양자 컴퓨터'가 나올 가능성을 전문가들의 약 27%가 10년 이내 50% 이상으로 예측했고, 기간을 30년으로 늘리면 약 78%의 전문가가 70% 이상으로 예측했다고 합니다.이처럼 양자 컴퓨터의 발전이 아직 초기 단계이긴 하지만 많은 전문가들은 수백 개 또는 수천 개의 큐비트를 다룰 수 있는 양자 컴퓨터의 개발이 멀지 않았다고 보고 있습니다. 이는 현재 양자 컴퓨터의 개발을 주도하고 있는 IBM의 양자 컴퓨터 개발 로드맵을 통해서도 예측해 볼 수

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를

이전 아래 글에 이어지는 (실습) 편입니다.• None 이제는 Agent 시대! RAG와 함께 Bedrock Agent를 활용해보자 - 1 (이론)지난번에 살펴본 AI Agent에 대해 간단히 정리해보고, Amazon Bedrock Agent 서비스로 이를 구현해 보겠습니다.AI Agent는 특정 목표를 달성하기 위해 자율적으로 행동하고 결정을 내리는 AI 시스템을 말합니다.• None 자율성: Agent는 사람의 직접적인 개입 없이 자체적인 판단으로 작업을 수행할 수 있습니다.• None 목표 지향성: 주어진 목표를 달성하기 위해 데이터를 수집하고 계획을 세우고 실행합니다.• None 환경 인식: 주변 환경을 인식하고 그에 따라 행동을 조절합니다.• None 학습 능력: 경험을 통해 학습하고 성능을 개선합니다.• None 상호작용: 다른 Agent나 시스템과 소통하고 협력할 수 있습니다.참고 문서 : AI 에이전트란 무엇일까요?여기에서 주목할 점은 상호작용 부분입니다. Agent는 API 호출을 통해 LLM 환경의 Sandbox를 벗어나 외부 환경인 실세계에 개입하여 작업을 할 수 있게 됩니다.현실 세계의 IoT 장비의 값을 읽어 올 수도 있고, 서비스 운영 환경을 자동화할 수도 있고, 게임 내의 세계를 조율하는 AI 운영자가 될 수도 있습니다.기존의 단순한 언어 인식 기반의 정형화된 AI Agent에서,LLM이 적용되면서 사용자의 언어를 이해하고 논리적으로 정리하고 실행할 수 있게 됨으로 AI Agent는 놀라운 가능성을 가지게 되었습니다.AWS Bedrock 플랫폼은 지식 검색(RAG)과 API 스키마를 사용해서 이런 LLM 기반의 에이전트의 기능을 확장 지원합니다.Amazon Bedrock Agent의 주요 구성 요소는 아래와 같습니다.• None Agent의 외부 세계 확장을 위한 핵심기능으로, 바로 AWS Lambda 함수를 호출 할 수 있는 기능입니다.• None Action Group 하나는 AWS Lambda 함수 한개와 직접 연결됩니다.• None OpenAPI Schema를 통해서 Agent는 이 Lambda 함수가 무엇을 할 수 있고, input과 output은 어떻게 정의 되는지 알 수 있습니다.• None 지식 기반에는 Agent가 검색해서 사용할 수 있는 데이터가 들어 있습니다. 에이전트가 지식 기반을 쿼리하여 응답을 증가시키거나 작업 그룹을 호출하는 효율성을 개선할 수 있습니다.• None 데이터 소스 : S3, 웹 크롤링을 직접 지원하며, Confluence, Salesforce, Sharepoint를 연결해서 사용할 수 있습니다.• None 청킹 및 구분 분석 : 다양한 청킹 전략과 더불어 Lambda 함수를 통해 청킹 및 문서 메타데이터 처리를 사용자 정의할수 도 있습니다.• None 벡터 데이터베이스 : Amazon OpenSearch Serverless, Amazon Aurora, Pinecone, Redis Enterprise Cloud을 지원합니다.• None 기본적으로 에이전트는 단일 대화 내의

안녕하세요, 모두싸인 제품 그룹에서 백엔드를 개발하고 있는 러리입니다.이번 포스트에서는 작년 이맘때쯤 약 9시간에 걸쳐 배포되었던 워크스페이스 프로젝트에 대해 이야기해보려 합니다. 해당 프로젝트를 통해 정말 많은 점이 개선되었지만, 이번에는 워크스페이스 프로젝트를 통해 개편된 인가 체계를 소개드리겠습니다.💡 이 글은 인가를 이해하고 있는 개발자를 대상으로 하는 글입니다. 따라서 일부 개념에 대한 자세한 설명은 생략되어 있으니 양해 부탁드립니다.시작하기에 앞서, 자주 헷갈리는 개념인 인증과 인가에 대해 차이점만 간단히 짚고 넘어가겠습니다. 인증(Authentication)은 요청자가 ‘누구인지 확인’하는 과정이고, 인가(Authorization)는 인증 과정을 통해 확인된 요청자가 ‘무엇을 할 수 있는지 결정’하는 과정입니다. 다르게 말하면 인가 과정은 요청자가 적절한 권한을 갖고 있는지 확인하는 과정이라고도 볼 수 있습니다.이번 글에서는 모두싸인이 어떻게 이 인가 과정을 더욱 유연하고 확장 가능한 방식으로 구현했는지를 소개해드리려 합니다. 그럼 이제 본격적으로 시작해볼까요?왜 시작했는가?초기 모두싸인은 계정 하나로도 업무를 충분히 진행할 수 있는 규모가 작은 스타트업을 주요 대상으로 하는 기능을 제공했지만, 고객층이 엔터프라이즈로도 확장되면서 여러 사용자가 함께 이용할 수 있는 기능과 권한 제어에 대한 니즈가 늘어났습니다.계정을 하나만 사용할 때는 각 리소스에 접근할 수 있는 주체가 소유자 하나 뿐입니다. 즉, 리소스를 소유하는 유저가 곧 해당 리소스에 대한 모든 권한을 갖고 있는거죠. 하지만 여러 유저가 함께 사용하는 형태에서는 각 유저가 아니라 조직이 리소스를 소유하고, 유저는 조직으로부터 권한을 부여받아 리소스에 접근합니다. 예를 들어 유저 A가 문서 D를 만들면, 문서 D의 소유권은 유저 A가 속한 조직이 갖고 유저 A는 조직으로부터 권한을 부여받아 문서 D에 접근할 수 있게 되는 것이죠.모두싸인 또한 단일 계정에 맞춰져 있는 로직과 데이터들을 다중 계정의 사용 형태에 맞게 여러 방향으로 수정하며 기능을 개발했습니다. 하지만 시스템의 규모가 커질수록 기존 코드를 수정하는 방법만으로는 확장성과 개발 경험 등에서 계속 한계가 느껴지고 있었습니다. 규모는 커졌지만 인가 체계는 아직 작은 시스템에 맞춰져 있었기 때문에, 조금 다른 접근 방법이 필요해졌습니다.당시에 겪었던 문제는 크게 세 가지였습니다.1. 비즈니스 로직과 인가 로직이 함께 있음비즈니스 로직과 인가 로직이 분리되지 않고 같은 곳에 있었습니다. 예를 들면 “템플릿을 생성한다”는 기능에 대한 로직을 작성할 때, 단순히 그 기능에 대한 로직만 존재하는 것이 아니라 템플릿 생성 권한을 확인하는 것까지 함께 코드에 들어가 있던 것입니다.이 때문에 코드를 작성할 때 만들고 있는 기능에 온전히 집중하지 못하고, 권한을 계속 신경 쓰면서 코드를 작성했어야 했습니다.2. 최고 관리자라는 예외 케이스한편 이러한 인가 로직에 구애받지 않고 조직 내 모든 리소스에 접근할 수 있는 “최고 관리자”

Picking 공정 시뮬레이션의 구축부터 활용까지• 시뮬레이션을 만들어 보자• 시뮬레이션을 활용해 보자• 재고 리로케이션• 앞으로는?안녕하세요, 컬리 데이터서비스개발팀의 Data Scientist 박수형입니다. 최근 다양한 산업 분야에서 모델링 및 시뮬레이션(M&S) 기반의 디지털 트윈을 활용해 복잡한 비즈니스 문제를 효과적으로 해결하는 사례가 늘고 있습니다. 디지털 트윈의 근간이 되는 시뮬레이션 기술은 실제 시스템을 가상의 환경에 재현해 다양한 시나리오를 실험하고 문제를 사전에 예상하며 최적의 해결책을 모색하는 데 큰 도움이 되는데요. 컬리 또한 M&S 기술을 적극적으로 도입하여 물류센터 내 다양한 현상을 분석하고, 이를 바탕으로 각 공정의 개선 작업을 수행하고 있습니다. 특히 최근에는 Picking(이하 피킹) 공정에 대한 시뮬레이션을 개발하여 의사결정이 더욱 신속하고 효율적으로 이루어지도록 지원하고 있습니다. 이번 글에서는 피킹 시뮬레이션 구축 과정과 활용 사례를 자세히 살펴보겠습니다.피킹은 출고 대상 상품을 각 적치 공간에서 꺼내 오는 공정을 말합니다. 개별 작업자에게 피킹잡(= 여러 피킹 작업의 묶음) 단위의 작업 지시를 내리면, 아래의 사진처럼 작업자가 카트를 끌고 안내되는 위치로 이동하여 물건을 바구니에 담게 됩니다. 작업자는 할당된 지시를 완료하기까지 창고를 돌아다니며 이 작업을 반복합니다.이처럼 대부분의 작업이 사람에 의해 이루어지다 보니, 현장에서는 여러 난관이 있기도 하는데요. 예를 들어, 통로에서 작업자 간 병목이 생기거나 동선이 길어져 시간이 지연되는 경우가 있습니다. 이와 같은 부분들을 개선하기 위해 다양한 아이디어들이 제시되었으나, 어떤 방안이 실무에서 도움이 될지 판단하는 것은 쉽지 않은 일이었습니다.‘물건을 적치하는 위치를 변경하면 어떤 효과가 있을까?’와 같은 질문에 대해, 저희는 주로 두 가지 접근 방식을 통해 답을 도출해 왔습니다. 첫 번째는 과거 데이터를 기반으로 한 분석이며, 두 번째는 실제 환경에서의 실험입니다. 그러나 과거 데이터는 이미 발생한 상황만을 반영하기 때문에, 환경 변화를 시도했을 때의 미래 결과를 예측하는 데는 근본적인 한계가 존재합니다. 또한, 물류 센터에서 개선안을 직접 실험하는 것은 운영과 병행해야 하는 현실적인 제약으로 인해 진행이 어려우며, 설령 실험을 하더라도 관찰자로 인해 의도치 않은 개입과 그로 인한 편향된 결과가 발생할 수 있습니다. 이를 극복하고자, 저희는 시뮬레이션 기법을 도입하여 조건이 변경되었을 때 미래의 환경에 끼칠 영향을 더 정확하게 예측하고 개선안을 객관적으로 평가할 방법을 마련했습니다.시뮬레이션을 만들어 보자시뮬레이션 모델링을 위해서는 먼저 실제 시스템에서 구현할 요소를 명확히 정의해야 합니다. 대상 시스템인 피킹 공정에서는 많은 작업자가 동시에 여러 사건을 발생시키지만, 이상적인 상황에서 각각의 작업자는 독립적으로 작업을 수행하며 작업자들 간의 상호작용은 존재하지 않습니다. 시스템이 복잡해 보일 수 있지만 실제로는 간단하게 이해할 수 있는 구조로 되어

안녕하세요, 여기어때컴퍼니 iOS개발팀 드락입니다.iOS개발팀은 개발 플랫폼에 적용된 기술 스택이 업계 메인스트림에서 뒤쳐지지 않도록 항상 노력 중인데요, 여기어때 기술블로그라는 공간을 통해 최근에 진행한 여기어때 앱의 Network/Adapter 모듈 구조 개선에 대해 한 번 이야기해볼까 합니다.이번 구조 개선은 기술적 개선&기능적 개선 두 가지 전부 이루어졌는데요, 개선사항은 다음과 같습니다.1. Network, Adapter 모듈과 인터페이스에서 RxSwift, RxCocoa의존성 제거2. UI 레벨에서 네트워크 로딩 상태를 자유롭게 핸들링 가능한 구조로 전환우선, 첫 번째로 언급한Network, Adapter 모듈, 인터페이스에서 RxSwift, RxCocoa의존성 제거부터 살펴보겠습니다.바로 제거하기 전에 어쩌다 RxSwift에 의존하게 되었는지, 이제와서 굳이 왜 제거하려 하는지를 우선 살짝 짚고 넘어가자면..대략 2018년도 즈음.. 앱개발 씬이 ReactiveX Hype 상태일 시절, 세상이 iOS개발자에게 RxSwift & RxCocoa 스킬을 필수 소양으로 요구했었고, 저 역시 RxSwift와 RxCocoa를 익히며 앱의 코어부터 UI레벨에 거쳐 사방팔방에 Rx를 적용했습니다.그런데…이제 상황이 약간 변했습니다?우선, First-Party인 애플에서 Built-in으로 Rx대안 솔루션인 Combine을 발표했고, 지속적으로 지원해주고 있습니다. 거기에, 기존의 callback 방식을 대체하는 형태로 사용되던 RxSwift를 대체하는(..) 차세대 비동기 처리 솔루션인 Async/Await도 발표되었죠.1st-party 솔루션을 사용하는 것은 많은 부분에서 이점을 가져다줍니다.우선 신뢰도가 높고요, 플랫폼 전반에 걸친 호환성을 보장합니다.Swift 컴파일러는 당연하게도 1st-party 타입을 가장 잘 이해하고 있기 때문에, 최적화된 코드를 생성할 수 있고, IDE 에서도 가장 매끈한 개발 지원이 이루어집니다.1st-party에서 제공하는 타입들은 통상적으로 플랫폼에 최적화된 성능을 제공하며 지속적인 업데이트와 개선이 이루어집니다.Swift 개발자들 사이에서 공통된 이해를 기반으로 하기 때문에, 누구나 빠르게 코드에 접근하고 수정할 수 있습니다.요약: 1st-Party 솔루션은 3rd-party 솔루션에 비해 안정성, 성능, 유지보수, 보편성, 프로젝트 러닝커브등 여러가지를 고려했을 때 많은 이점이 있습니다.1부터 10,000까지의 값들에 2를 곱하는 작업을 RxSwift와 Combine을 활용해서 각각 100회씩 수행해 보았습니다.좌측 상단부터 시계 방향으로 - 할당된 후 해제되지 않고 계속 유지되고 있는 메모리 블록, 할당된 총 메모리의 양, 발생한 메모리 할당 횟수, 작업 완료까지 걸린 시간아무래도 근본 태생이 다른 만큼 성능 면에서도 상당한 차이가 나고 있구요..그렇다면…….우리 프로젝트도 RxSwift에 대한 의존도를 조금이라도 줄이는 방향으로 리팩토링하는 쪽이 유리하다는 판단 아래, View와 ViewModel

본 글은 SK플래닛에서 OPA(Open Policy Agent)를 이용하여 사내 JIRA의 권한을 구현한 사례를 공유하며, 아래와 같이 크게 세 가지 작업을 정리하고자 합니다.• 첫번째는 개발 중인 ITSM 시스템에서 권한 부분을 OPA를 이용해 구현합니다.• 정책은 Rego로 작성합니다.• 두번째는 작성된 정책을, data API를 이용해 권한 체크를 구현합니다.• 세번째는 애플리케이션과 OPA 서버를 하나의 파드로 묶어 사이드카 형태로 쿠버네티스 개발 환경에 배포합니다.• ITSM 시스템의 백엔드를 Java Spring 및 JPA를 사용하여 개발하였고, 현재 사용 중인 JIRA를 대체할 예정입니다.• JIRA의 데이터를 이전할 계획이라, JIRA의 데이터 구조를 그대로 사용하고자 합니다.• JIRA의 권한 관련 데이터 및 권한 정책을 확인하였습니다.• JIRA의 프로젝트 관리 권한을 가진 사용자라면 아래와 같은 페이지에서 프로젝트의 롤과 퍼미션의 수정이 가능합니다.• Users and Roles 에서 ADMINISTRATORS/DEVELOPERS/USERS 롤에 그룹 및 사용자를 할당할 수 있습니다.• Project Permissions 에서 각 퍼미션에 사용자, 그룹 및 위에서 할당한 롤을 추가할 수 있습니다.• 이렇게 화면에서 설정한 값은 JSON으로 아래와 같이 표현합니다(JIRA API를 통해 확인).• 파일 크기가 꽤 되므로 일부 내용만 캡쳐하며, permissionKey(퍼미션 내용)과 grants(권한부여) 을 포함한 동일한 형태의 퍼미션을 배열로 정의하고 있습니다.• 해당 JSON을 OPA에서 권한 체크 시, 데이터로 사용합니다.• 이러한 구조를 염두해 두고 권한 처리를 생각해 보면, 사용자 및 사용자의 그룹이 속한 롤을 확인하고,• 사용자 아이디, 그룹명, 롤명으로 permissions의 grants를 뒤져서 해당 사용자가 해당 퍼미션에 권한이 있는지 여부를 확인할 수 있습니다.• 복잡해 보이지만 의외로 간단합니다. Rego를 작성해 봅니다.• 작성한 정책(rego)과 데이터을 이용하여 권한을 체크합니다. OPA 플레이그라운드에서 테스트할 수 있습니다.• 백엔드 서버에서 OPA data API를 이용하여 권한 체크를 하는 로직을 개발해 봅니다.• Spring security의 PreAuthorize 태그를 이용합니다.• Spring controller에 권한 체크를 위해 PreAuthorize 태그를 추가합니다.• PreAuhorize에서 opaclient.allow를 호출합니다.• opaClient.allow는 아래와 같이 구현하였습니다.• input으로 사용자 아이디와 그룹, 권한을 체크하고자 하는 프로젝트와 퍼미션를 입력합니다.• 개발한 백엔드 서버와 OPA 서버을 쿠버네티스(이하 k8s) 환경에 개발 서버로 배포해 봅니다.• 아래 k8s deployment yaml를 이용하여, 백단서버(pitsm-backend)와 OPA서버를 한 pod 내에 container로 배포합니다.• OPA 서버를 사이드카 형태로 실행

hyeoni.c 평소 잘 사용하던 라이브러리의 정책과 내부 구현을 살펴보며 문제를 해결해 가는 과정을 재밌게 풀어내었습니다. 유사한 경험을 가지신, 앞으로 마주할 수 있는 모든 분들에게 추천합니다!daisy.dani URI 정보가 왜 갑자기 사라졌을까요? 이 글에서 원인을 파헤치고, 어떻게 해결할 수 있는지 알아봅시다!Spring 프레임워크가 제공하는 UriComponentsBuilder 클래스를 아시나요? UriComponentsBuilder 클래스는 URL을 쉽게 다루기 위한 유틸 클래스입니다. 이번에 URL을 수정하기 위해 UriComponentsBuilder 클래스를 사용하던 중 서비스 장애가 발생했는데요. 원인을 분석해 보니 java.net.URI 클래스와 UriComponentsBuilder 클래스 사이에서 꽤나 흥미로운 일이 이뤄지고 있습니다. 무슨 일인지 궁금하지 않으신가요? 지금부터 함께 당시의 상황 속으로 들어가 보겠습니다.안녕하세요. 채널서버유닛의 레인입니다. 채널서버유닛은 여러분이 카카오페이의 다양한 서비스와 혜택을 마주하고 탐색할 수 있도록 홈 탭, 혜택 탭, 결제 탭 등 다양한 전면 서비스를 개발하고 있습니다. 이러한 서비스에는 이 글의 배경이 되는 알림피드도 존재하는데요. 카카오페이 앱을 사용하신다면 아래 사진 속 공간, 알림피드가 익숙하실 겁니다.알림피드는 여러분이 언제나 편하게 알림을 탐색하고 원하는 서비스를 방문할 수 있도록 노력하고 있습니다. 클릭하면 메시지가 사라지는 OS 알림 센터와 달리 메시지를 다시 볼 수 있도록 30일 동안 보관하고 있고요. 알림을 식별하기 편하도록 메시지에 서비스를 표시하거나, 원하는 종류의 알림을 탐색하기 편하도록 필터 등의 기능을 제공하고 있습니다.기: 무슨 일이 발생했는가알림피드를 구성하는 데이터는 앱푸시로 발송하는 메시지에 기반하고 있습니다. 그래서 알림피드는 OS 알림 센터 환경에 맞춰진 데이터들을 목적에 맞게 가공해서 사용하고 있습니다. 이 과정에서 알림피드는 반복되는 키워드를 제거하는 등 문구를 가공하고 있는데요. 어느 날 메시지의 랜딩 URL도 가공해야 하는 순간이 찾아왔습니다.카카오페이 앱 정책이 변경되면서 OS 알림 센터와 알림피드에서 메시지의 랜딩 동작이 서로 달라야 했습니다. OS 알림 센터에서 앱푸시 메시지를 클릭한 경우는 카카오페이 앱이 열리고 특정 흐름을 거친 후 서비스로 랜딩 합니다. 하지만 알림피드에서 메시지를 클릭한 경우는 카카오페이 앱 내부에서의 동작이기 때문에 특정 흐름을 거치지 않아야 합니다.정책을 반영하기 위해서는 메시지의 랜딩 URL에서 특정 파라미터를 제거하면 됩니다. 아래와 같이 OS 알림 센터에 맞춰진 메시지 랜딩 URL에서 base 파라미터를 제거하면 되는데요. 알림피드에 랜딩 URL을 가공하는 로직을 추가한 그날 문제가 발생했습니다.• OS 알림 센터에서의 메시지 랜딩 URL:• 알림피드에서의 메시지 랜딩 URL:알림피드에 URL 재처리 기능을 배포하고 몇 시간 후, 내부 크루 채널을 통해 알림피드가 이상하다는 제보를 받았습니다