작년에 이어 올해에도 정말 많은 LLM 모델이 나왔고, 유료와 무료 모델을 두루 사용해본 결과확실히 유료모델이 성능이나 속도측면에서 가성비가 좋았고, 당연하게도 비싼 모델일수록 결과가 매우 좋았습니다.특히, 글 이해 분야에서는 이제 LLM의 성능이 사람을 능가하고 특히 속도측면에서 더욱 강점을 가지는 것으로 보입니다.그럼에도 사람이 모든 세상의 지식을 알고 있지 못하듯이, LLM도 비슷한 한계가 있고, 이로 인해 RAG라는 방식이 대안으로 등장하였는데,올해는 거의 대부분의 작업이 RAG를 기반으로 이루어질 만큼 성능과 활용도가 뛰어나고 앞으로도 현업에서는 필연적으로 사용할 수밖에 없는 방식이라고 봅니다.저는 개인적으로 다양한 툴 중에서 Qdrant 백터 디비와 llamaindex 패키지를 활용하여 python을 통한 작업을 진행하였는데, 너무 만족스러웠습니다.Qdrant 디비의 경우에는 docker나 k8s에 helm 차트로 쉽게 배포가 가능하며, 이를 통해 다양한 config값의 변경이 쉬웠으며 대시보드 UI도 제공되며 특히 llamaindex와의 결합이 좋았습니다.llamaindex의 경우에는 자체적으로 다양한 임베딩 방식을 내재하며, huggingface 모델의 적용이 쉽고, 기본 세팅으로는 단 3줄로도 RAG를 구성할 수 있다는 극강의 효율을 보여줍니다.이를 통해 코딩의 시간을 줄이고, 실무에서 다양한 임베딩 모델을 테스트해보고, 모델을 최적화하는데 초점을 맞출 수 있다는 점이 좋았고, 개발 속도가 매우 빨랐습니다.다만, 이게 또 단점이 될 수 있는게, 그냥 잘 된다고 믿으면 편하지만, 뒷단의 작동방식을 파고 들면 들수록 복잡한 코드를 모두 다 찾아봐야되는...당연하면서도 지난한 작업이 필요하고, 커스터마이징을 하려면 결국 이 지난한 과정이 필요하다는 점이였습니다.나름 커스터마이징을 위한 튜토리얼도 제공되긴 하지만, 구체적으로 어느 단계에서 수정이 이루어져야 원하는 커스터마이징이 될지는 코드를 다 까봐야 알 수 있습니다...더불어 최신의 기술들이 바로바로 반영이 되지는 않아서 직접 만들어야하는 부분이 있고, 이때는 기존 프레임워크의 이점을 크게 가져갈 수 없다는 단점이 있었습니다.RAG의 성능은 Vector 디비에서 연관된 문서 추출과 이를 이용한 prompt 설계 그리고 최종 사용할 llm 모델 이 세 파트에서 결정된다고 보는데,그 중에서도 연관된 문서 추출이 가장 중요하다고 봅니다.실제로 다양한 개선된 모델들은 이 부분에서 최적의 문서 추출을 위한 다양한 기법들이 나와있고, 이는 문서의 수가 늘어날수록 더욱 중요해진다고 봅니다.그리고 임베딩 모델의 선택도 중요한데, 임베딩 모델별로 특화된 언어가 있고, cross lingual에 성능이 천차만별이라 어느 한 모델이 가장 좋다고 하기 어렵습니다.상황에 맞게 최적의 임베딩 모델을 사용해야합니다.그리고 문서에 일부러 중복이 되도록 chunk를 나누는 기법이 있는데, 문서가 방대해질수록 이렇게 설계해서 디비에 저장하는것이 성능 향상에 큰 도움이 되는 것으로 보입니다.개인적으로는 디비에

Koyeb 플랫폼을 활용해 Docker로 나만의 서비스를 손쉽게 배포하는 방법에 대해서 공부및 정리후 나만의 노하우와 지식을 공유한다.1. Koyeb에 대해서 알아본다.2. Koyeb 및 docker 를 활용해 간단하게 나만의 서비스를 배포하는 방법을 정리해본다.클라우드의 새로운 가능성? Koyeb과 Docker의 조합클라우드 컴퓨팅 시대에 효율적이고 간단한 서비스 배포는 더 이상 선택이 아닌 필수가 되었습니다.이번 블로그에서는 Koyeb 플랫폼을 활용해 Docker로 나만의 서비스를 손쉽게 배포하는 방법을 안내드립니다.Koyeb은 서버리스 클라우드 플랫폼으로, 빠르고 간편하게 애플리케이션을 배포할 수 있는 환경을 제공합니다.다음과 같은 특징으로 정리해볼 수 있는데요.서버리스 아키텍처로 관리할 서버가 없어 배포와 운영에만 집중 가능하게 되고요.자동 스케일링으로 인해서 트래픽 증가에도 유연한 대응할 수 있다고 하네요.통합 환경인 Docker, API, 파일 처리 등 다양한 워크로드 지원하고요.무엇보다도 제가 개인적으로 생각하는 Koyeb의 장점은 Docker 컨테이너 이미지를 직접 활용하여, 개발자가 기존에 작성한 애플리케이션을 간단히 무료로 배포할 수 있다는 점입니다.배포 관련 무료 사양은 아래와 같습니다.아무튼 간단한 어플리케이션 테스트및 배포로 사용하면 좋을것 같해요.우선 배포 하기 전 필요한 것은 아래와 같습니다.Koyeb 계정을 만들어야 하는데요 Koyeb 홈페이지에서 가입하시면 됩니다.계정이 만들어져있으면 docker 이미지로 만들 나만의 서비스가 구현되어야 하겠죠?나만의 서비스를 구현 후 윈도우의 경우 Docker Desktop 을 기동시켜야 합니다.아무튼 그래야 docker 관련 명령어를 사용할 수 있거든요...아래는 제가 요즘에 개인적으로 꾸준하게 구현해 나가고 있는 "오늘을 잘 사는 팁" 서비스입니다.그리고 사전에 저는 아래와 같이 간단하게 Dockerfile 을 작성했습니다.그리고 Docker Hub 또는 harbor 같은 레지스트리가 필요한데요 저는 docker hub 를 이용했습니다.그러면 아래와 같이 dockerhub 에 이미지가 올라간것을 확인할 수 있습니다.저는 Web 서비스를 Docker 를 통해서 배포하기를 원하기 때문에 아래와 같이 선택합니다.그리고 아래와 같이 image 를 기입합니다.그외에 아래와 같이 선택을 하시면 됩니다.그리고 마지막으로 서비스 이름까지 적으시고 Save and deploy 를 누르시면 배포가 됩니다아래 화면으로 진행이 되다가...아래와 같이 배포가 되죠그리고 위의 URI로 접속해보면 아래와 같이 서비스가 잘되고 있음을 확인할 수 있습니다.예를들어 블로그 검색 을 하면 아래와 같이 잘 나옵니다.여기까지가 오늘 내용이였고요..Koyeb 을 직접 사용해보고 제 개인적인 생각을 정리해보자면요Docker와 Koyeb의 조합은 간단하면서도 강력한 클라우드 배포 방법을 제공합니다.이 글을 따라 여러분만의 서비스를 클라우드에 올려보세요.더 이상 복잡한 서버 관리에 시간을 낭비하지 않아도 됩니다!

Refine 이관 작업 ( feat. 중고나라 — 셀러지원센터 )📍 이관을 하게 된 배경기존에 셀러지원센터는 Next.js, react-query, shadcn/ui 의 환경에서 개발을 진행했었다. 짧은 시간 안에 빠른 개발, 빌드 시간 단축, 확장 할 수 있는 커스텀 조건이 위 기술의 채택 이유이기도 했다. (참고 아티클)1차,2차 배포까지만 해도 우리가 선택한 기술이 올바르다고 판단했다.3차 오픈을 준비하기 전에, 이전에 빠른 개발로 인해 미뤄두었던 코드 개선작업을 시작한 것이 이관의 시초점이다.1️⃣ 개발자마다 다른 코드 스타일우리의 컨벤션을 정하긴 했지만, 페이지마다 작성한 개발 코드의 스타일이 온전히 일치하지는 않았다.그래서 오류가 발생 했을때 해당 코드를 작성하지 않은 사람이 개선을 진행하려고 하면 개발 비용이 많이 필요했다.2️⃣ 직관적이지 않은 코드 베이스테이블 자체에 대한 공통 컴포넌트는 직접 구현해 두었고, 외부에서 테이블 리스트 데이터를 불러오고 주입하는 방식으로 사용했었다.하지만, API마다 데이터를 변환하는 방식, 페이지 수를 가져오는 방식이 달라 페이지 내부에 단순히 리스트 컴포넌트만 보여주는 것이 아닌 데이터를 클라이언트 환경에 맞게 변환하는 로직들이 섞여 있어 페이지 동작을 직관적으로 파악하기 어려웠다.3️⃣ API마다 다른 스펙에 맞춰 변환하는 과정의 분산화셀러지원센터에서 호출하는 API 도메인은 아래와 같다.seller-api (셀러)partner-api (관리자)order-api (주문/결제 )main-api (중고나라 메인)edge-api (이미지)해당 API를 개발한 팀들이 다르다 보니 데이터를 반환하는 형식이 다르게 설계되어 있었다.그래서 클라이언트 내부적으로 공통 컴포넌트를 만들어놓았지만, 만약 한 페이지에 여러 도메인의 API를 호출했을 경우에는 이를 클라이언트 형식에 맞게 변환하는 과정이 페이지 내부에 여러 유틸이 들어감으로써 가독성이 떨어지는 현상이 발생하였다.더불어 변환하는 과정을 모두 모듈로 관리하지 않았기 때문에,해당 방식 또한 개발자마다 스타일이 달라져 코드의 흐름을 파악하기 어려웠다.하지만, 어드민 시스템의 특성상 테이블을 사용하는 페이지, 정보를 보여주는 페이지는 일관성을 가지도록 구현되는 것이 필요했고뷰의 요소만이 아닌 내부 코드 시스템도 동일하게 관리되어야 추가 기능에 대해 여러 페이지를 한 번에 대응하는 것이 가능해진다고 느껴졌다.이 3가지의 이유로 나는 어떤 특정 규격에 따른 코드 베이스를 가지면서 확장성을 고려한 기술의 도입이 필요하다고 판단했다.🖤 Refine의 간략한 특징그렇게 찾게 된 기술이 바로 Refine이다. 공식 문서에는 아래와 같이 설명되어 있다.React 기반 내부 도구, 관리자 패널, 대시보드 및 엔터프라이즈급 비즈니스 애플리케이션을 구축하도록 설계된 오픈소스 프레임워크이다. CRUD, 상태 관리와 같은 일반적인 기능을 처리하기 위한 자동화 세트를 제공하여 개발 프로세스를 간소화한다.이를 통해 개발자는 반복적인 코딩 작업을 피하고 프로젝트의 더 복잡한 측

2023.09–2023.12 , 중고나라 웹 개발팀에서의 4개월 이라는시간 동안 인턴십을 수행하고 나서, 정규직 전환이 이루어져 2024.02.01에 신입 웹 개발자로 입사를 하게 되었다. 2024년도 중고나라의 핵심 프로젝트인 셀러지원센터를 웹 개발팀 리딩의 자리에서 이끌어가면서 느꼈던 부분들을 회고로 기록하고자 이 글을 작성하였다.셀러 지원센터의 시작한 달의 공백기 이후 입사하게 되었지만, 인턴의 경험이 있었기 때문에 그간의 중고나라 웹 개발팀의 작업 내용들을 수월하게 따라올 수 있었다. 올해의 중고나라 핵심 프로젝트는 셀러 지원센터와 J쿠폰 이었다. 물론 두 가지 프로젝트에 관심이 있었지만, 웹 개발팀 전체가 비슷한 수요를 가지고 있었기에 우리는 공정하게 사다리 타기를 진행해서 어떤 프로젝트를 맡게 될지 선정하게 되었다. 그렇게 나와 다른 매니저님들과 함께 셀러 지원센터에 합류하게 되었고, 그때부터 해당 서비스에 대한 설계와 프로젝트 방향성을 잡는 과정이 시작되었다. 우리 팀은 해당 서비스를 온전히 이해하기 위해 PM 팀 과의 회의에 선택적으로 참여하곤 했다.개발자인데 굳이 참여해야 하나..?라는 생각이 들 수도 있겠지만, 서비스를 온전히 이해하고 장기적인 개선 방향을 도출해내는데 기여하기 위해서는 이 과정이 필요하다고 생각했다.신입 개발자의 프로젝트 리딩사내에서 진행하는 프로젝트에 참여하는 것도 처음이어서 설레는 마음이면서도 중요한 프로젝트에서 웹 개발팀의 리딩의 자리를 맡게 되어서 책임감을 느끼고 있기도 했다.우선, 셀러 지원센터가 어떤 특성을 가진 서비스이며, 우리는 어떤 기술을 선정해야 하고, 개발 일정과 방식은 어떻게 진행할 예정인지 수립하는 과정이 필요했다.Tech Stack 논의셀러 지원센터의 기술적인 특징은 아래와 같다.유저는 셀러 / 관리자로 나누어지므로 2개의 페이지가 필요로그인 이후 접속해야 하는 페이지들이기에 SEO 대응이 중요하지 않음다만, 추후 커뮤니티성이 도입된다면 미리 고려는 해야 하는 부분빠른 작업 속도를 위해 빌드 시간 단축 필요디자인 투입 리소스가 없으므로 웹 개발팀 내부적으로 쉽게 만들 수 있는 컴포넌트와 페이지 제작 필요위 특징들을 토대로 우리는 또 다른 질문들을 아래와 같이 도출했다.어떤 패키지 매니저를 선택할 것인가..?Headless UI로 shadcn/ui 가 있는데, react-admin 보다 용이할까?SEO가 중요하지는 않지만, Next.js 를 사용해야 할까?페이지를 나눠야 한다면, repository를 2개를 생성해야 할까?총 4가지 안건에 대해 레퍼런스를 찾고 회의를 진행했다.✅ 어떤 패키지 매니저를 선택할 것인가?npm, yarn, yarn-berry, pnpm 중에서 패키지 매니저를 선정하기로 했다.우선, npm은 기본적인 패키지 관리가 모두 가능하며 package.json안에서 관리할 수 있다는 장점이 있었지만,일관적이지 않은 패키지 버전을 사용하고 있고, 순차적인 설치로 인한 긴 소요 시간을 가진다는 단점이 있었다.그래서 yarn을 살펴보았고, 해당 패키지 매니

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2024(10월)에서 발표되었던 세션을 공개합니다.스노우 AI 서비스의 운영 개선을 위해 기존 GPU 서버 인프라를 Kubernetes 클러스터로 이전하는 과정에서 맞닥뜨린 기술적 문제들과 해결 방법을 공유합니다.AI 서비스 운영을 위해 GPU 서버 기반의 Kubernetes 클러스터 도입을 고려하는 엔지니어• GPU 인프라 이전을 위한 고려 사항NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2024(10월)의 일부 세션을 공개합니다.

요즘은 LLM(Large Language Model)의 시대입니다. 2022년에 ChatGPT가 처음 서비스된 이후로, 하루가 다르게 더 빠르고, 더 정확하고, 심지어 이미지나 비디오, 음성 등을 이해하고 생성하는 모델들이 등장하고 있습니다. 아래 그림처럼, 2024년 들어서 상용 LLM과 오픈소스 LLM이 경쟁적으로 등장하며, 시장을 빠르게 변화시키고 있습니다.토스증권 역시 이런 흐름에 발맞춰, LLM을 활용한 서비스 혁신에 적극 나서고 있습니다. 투자 데이터를 이해하고 고객들에게 보다 나은 금융 서비스를 제공하기 위해, 우리는 자체적으로 LLM 모델을 학습시키고 이를 서비스에 적용하려는 데 집중하고 있습니다.구슬이 서말이라도 꿰어야 보배라는 말처럼, 좋은 LLM을 학습시키는 것도 중요하지만 이걸 서비스에 적용하지 못하면 큰 의미가 없습니다. 하지만 일정 수준의 이상의 성능을 지원하는 LLM을 서비스에 적용할 때 크게 두 가지의 어려움이 있습니다.첫 번째는 속도의 문제입니다. 중간 사이즈의 LLM인 Llama3 8B 모델을 일반적인 Transformers 패키지를 사용해서 추론하면, 단순한 질문에도 수십 초씩 기다려야 합니다. 따라서, 서비스에 적용할 만큼의 성능을 확보하기 위해서 추론 속도를 빠르게 만들 필요가 있습니다.두 번째는 사용성의 문제입니다. 어떤 모델이 우리 서비스에 더 적합한지 판단하려면, 다양한 모델을 서비스에 적용하면서 각기 다른 상황에 맞게 테스트해야 합니다. 하지만 학습된 모델을 서빙하기 위해서 개발자는 많은 정보를 알아야 됩니다. 예를 들어, 모델 코드를 컨테이너화하기 위해 필요한 Docker 이미지 빌드 방법이나, 서버를 Kubernetes에 배포하기 위해 필요한 manifest 작성법 등이 있습니다. 이런 허들 때문에 여러 모델을 서빙해서 A/B 테스트로 비교하기 어렵습니다.이번 아티클에서는 토스증권이 어떻게 LLM의 추론 속도, 모델 서빙 방법을 더 효율적으로 개선했는지 알려드리겠습니다.문제 1. LLM을 우리 인프라에서 그냥 돌리면 너무 느려요ChatGPT, Claude, Gemini 등 다양한 LLM 서비스를 사용해보셨나요? 이런 서비스는 속도가 상당히 빠릅니다. 특히 최신 모델들은 그 성능도 대단하지만, 2~3 문단으로 구성된 긴 글을 쓰는데 수 초 정도면 충분합니다. 하지만, 그에 준하는 성능을 보인다고 알려진 Llama3 70B, Mixtral 8x22B 등의 모델들을 써보면, GPU를 사용하더라도 비슷한 양의 토큰을 생성하는 데 수 분, 길게는 수십 분이 걸리는 경우도 있습니다.이런 모델들이 느린 이유는 autoregressive 모델의 특성 때문입니다. Autoregressive 모델이란, 이전 모델의 결과물을 입력으로 이용해서 다음 모델 결과를 생성하는 모델을 의미합니다. 즉, 각각의 토큰을 순차적으로 생성해야 하기 때문에 속도가 느립니다. 예를 들어, 안녕하세요. 토스 테크 블로그입니다 . 라는 문장은, 안녕하세요. -> 토스 -> 테크 -> 블로그입니다. 라는 순서대로 생성합니다.이런 본질

저에게는 게임 개발에 QA라는 직군이 있는 줄도 몰랐던 시절이 있었습니다. 사실 게임은 그냥 코드를 뚝딱하고 짜면 짠! 하고 만들어지는 것이라고 생각을 했다는 것이 더 정확할 겁니다. ‘개발자 = 똑쟁이’ 라서 저절로 양질의 제품이 만들어지겠지... 하는 바보 같은 생각이었죠. 우연한 기회로 QA를 업으로 삼고 나니, 테스트라는 것이 정말 소프트웨어 개발에 있어 상당히 중요하구나라는 것을 소름 돋을 정도로 느끼게 되었습니다. 생각보다 게임에는 고쳐야 할 것들이 엄청나게 많거든요.우선 QA 활동이 게임 개발에 왜 필요한지는 아래 문장으로 간단하게 요약할 수 있을 것 같습니다.위 문장이 전반적인 QA활동에 대해 적절히 잘 표현한 것 같습니다. 그렇지만 이렇게 정리하면 너무 식상합니다. 마치 면접장에서 많이 들을 수 있는 대답 같아 보이지 않나요?그렇다면 좀 더 깊게 생각해봅시다. 만약 “그래서 너의 업무가 프로젝트 안에서 어떤 가치를 창출하는데?”라는 공격적인 질문을 갑자기 받게 되었다면, 빠르고 정확하게 저희의 가치를 상대방의 뇌리에 각인 시킬 수 있으신가요? 몇 년 전의 저였다면, 아마 흔들리는 동공과 떨고 있는 꽉 쥔 주먹만 보여주었을 것 같습니다.게임 QA로 오랫동안 일하다 보니 가끔 시간이 날 때 마다 ‘나는 프로젝트에서 어떤 가치를 가질까?’하는 질문을 떠올립니다. 그래서 이번 포스팅은 그것에 대한 나름의 답을 같이 이야기하고자 합니다. 테크니컬한 부분은 없습니다만, 특별히 게임 QA를 직업으로 삼고 애정을 가진 많은 분들이 자부심을 가질 수 있도록 조금이나마 도움이 되었으면 합니다.1. 게임에서의 품질 기준QA가 Quality Assurance 인 것은 모두 잘 알고 계실겁니다. 직역하면 역시나 ‘품질 보증’이구요. 어쨌든 단어풀이는 이해가 되는데, 그에 비해 예전부터 명확치 않았던 것이 있었습니다. 우리의 테스트 활동이 어떻게 품질을 ‘보증’하는 것일까요? 농축산품처럼 품질등급을 도장으로 쾅 찍는 것도 아니고, 공산품처럼 6시그마(σ) 품질관리를 활용해 불량률을 정확하게 평가할 수 있는 것도 아닌데 말이죠. 소프트웨어 제품이라는 두루뭉술한 대상에 대해서 우리는 어떻게 품질을 평가하고 있는걸까요?이에 대한 정의는 사람에 따라 조금씩 다르겠지만, Software Testing Help 사이트에서 설명한 내용이 오늘 포스팅의 주제에 부합할 것 같습니다.여기서 말하는 QA는 “정의된 표준을 준수하였는가?”에 초점을 맞추고 있습니다. 그렇다면 우리는 먼저 게임 서비스에서 ‘정의된 표준’이 무엇인지 정리해야 할 것 같습니다.ISTQB Foundation을 공부하셨다면 ‘요구사항’에 대한 내용을 기억 하실 겁니다. 이는 사용자가 제품에 원하는 여러가지 기능/비기능적 사양을 뜻합니다. 이 요구사항이 제대로 충족되었는지 인수 테스트를 거친 다음 비로소 제품이 사용자에게 전달되게 됩니다. 즉, 사용자 요구사항이 명확히 정의되면서 표준(Standards)이 되고, 이 기준선을 통과한 상태를 우린 품질이 보증된 상태라고 볼 수 있을 것 같습니다.그

sunny.ryu 카카오페이는 OOO에 진심이다! 정답은? 이프카카오입니다~! 기술전략팀 DR(Developer Reltaions) 로라가 들려주는 생생한 if(kakaoAI)2024 준비 과정, 함께 보러 가시죠!dan.dy (더 이상 잘할 수 있는 게 거의 없을 거 같은데도) 이프카카오 발표 준비 과정 역시 “고도화”가 계속되는 것 같네요 ^^. 저희가 발표자 분들께 페이스 메이커가 되어 드리고자 했는데요, 고난한 과정을 묵묵히 완주해 주신 발표자 여러분께 진심으로 감사드립니다.안녕하세요, 카카오페이 Developer Relations(이하 DevRel) 담당자 로라입니다.지난 10월, 무려 5년 만에 오프라인으로 카카오 개발자 컨퍼런스 if(kakao)를 진행했습니다. 페이에 입사하고 처음으로 경험한 if(kakao)2022는 온라인으로 진행해 새롭게 배운 점도 있었지만 아쉬운 부분도 있었습니다. 올해는 특별한 장소에서 오프라인으로 진행한다는 소식에 기대가 남달랐는데요. 그래서 더욱 철저하게 준비하려고 했던 것 같습니다.이번 글에서는 카카오페이의 if(kakao) 개발자 컨퍼런스 준비 과정을 회고 중심으로 작성하려고 합니다. 평소 ‘다른 곳에서는 개발자 컨퍼런스를 어떻게 준비할까?’ 궁금했던 분들에게 도움 되는 글이길 바랍니다.올해 컨퍼런스 준비는 6월 중순부터 시작했습니다. 6월 중순 페이공동체(카카오페이, 카카오페이증권, 카카오페이손해보험 3사를 칭함.) 대상 발표자 모집이 긴 여정의 시작이었는데요. 본격적으로 여정을 시작하기 전, 지난 과정을 되돌아보는 시간이 꼭 필요하다고 생각했습니다. 그렇게 컨퍼런스 담당자인 저, 댄 그리고 써니 3명은 2022년 if(kakao) 회고를 위해 모였습니다.회고 미팅에서는 2022년 컨퍼런스를 마치고 팀 위키 페이지와 기술 블로그에 정리한 내용을 바탕으로, 아래 2가지 사항에 대해 정리하려고 했습니다.• 긍정 포인트를 찾고 이 부분은 고도화하기• 아쉬운 포인트를 살펴보고 올해는 되풀이하지 않도록 새로운 방안 마련하기회고를 진행하며 느낀 점은 회고와 기록의 중요성이었습니다. 회고 과정이 없었다면, 백지 상태에서 시작해 다소 막막했을 텐데 덕분에 쉽게 준비를 시작했던 것 같습니다. 그리고 인간의 기억은 생각보다 빠르게 휘발되기 때문에, 어딘가에 기록해 두지 않으면 제대로 회고하지 못했겠다 싶었기 때문입니다.그래서 올해도 컨퍼런스 준비로 아무리 바빠도 중간중간 준비 과정을 기록하자고 얘기를 나눴습니다. 어쩌면 이 글도 내년 if(kakao)2025 준비 단계에서 큰 도움이 될 것 같네요. 짧든 길든, 형식적이든 아니든, 어떤 형태로든 준비 과정 기록을 남겨두시는 걸 추천드려요.그렇다면 저희는 어떤 포인트들을 정리하고 올해 컨퍼런스를 준비했을까요?👀 함께 보면 좋은 글 카카오페이 if(kakao)2022 발표 준비 과정 엿보기지난 컨퍼런스를 준비하며 ‘이거는 참 잘했다!’ 하는 긍정 포인트를 먼저 정리했습니다. 긍정 포인트는 더욱 돋보일 수 있도록 다듬어 바로 적용하자고 했죠.지난번과 마찬가지로 올

저는 AI Comm Client 팀에서 에이닷 통화녹음과 에이닷 전화 iOS 개발을 하고 있는 이준영입니다.올해로 2년차 주니어 개발자가 되었는데요, 그간 한 일 중에서 가장 기억 남는 과제는 에이닷 watchOS 앱 개발입니다.Apple Watch는 올해로 출시한 지 10년이 되었습니다.하지만 부족한 하드웨어 스펙 등으로 인해 iPhone에 비해 제공할 수 있는 기능들이 부족해, 앱 개수도 적고 참고할 만한 개발 자료도 다소 적습니다.그렇다보니 개발하면서 여러 어려움을 겪었는데요, 이번 게시글에서는 Notification 관련 기능을 개발하며 겪었던 일들에 대해서 다뤄 보겠습니다.이번 게시글에서는, Apple에서 제공하는 Creating a watchOS app 샘플 프로젝트를 사용합니다.직접 빌드해서 확인해 보고 싶은 분들은, Apple Developer 사이트에서 해당 프로젝트를 다운로드 받으시면 됩니다.그리고 본 게시글은 아래 환경을 기준으로 작성된 내용이므로, 향후 Apple의 OS 업데이트에 따라 동작이 달라질 수 있습니다.마지막으로, 본 게시글을 이해하기 위해서는 SwiftUI에 대한 기본적인 이해가 필요합니다.만약 SwiftUI에 대해 잘 모르신다면, Apple의 Introducing SwiftUI를 먼저 보시는 것을 추천드립니다.Apple 공식 문서에서는, Notification이 iPhone과 Apple Watch 중 어디에 등장하는지에 대해 아래와 같이 설명하고 있습니다.위 설명에서 2번 항목을 보면, Apple Watch가 사용자의 손목에 착용되어 있고 잠금 해제된 경우에 Apple Watch로 알림이 전송된다고 나와 있습니다.시스템은 Apple Watch가 손목에 착용되어 있는 것은 어떻게 알 수 있을까요?iPhone의 Watch 앱을 보면, 손목 인식이라는 설정이 있습니다.설명만 읽어보면 암호 설정이 되어 있을 때 Apple Watch를 잠그는 것과 관련 있는 내용으로 보입니다.하지만 설명과는 다르게, 암호를 사용하지 않더라도 손목 인식 옵션은 켜고 끄는 것이 가능합니다.즉 이 옵션은 시스템이 실시간으로 Apple Watch 착용 여부를 판단하게 해 주는 것입니다.앞서 'Apple Watch가 사용자의 손목에 착용되어 있고 잠금 해제된 경우에 Apple Watch로 알림이 전송된다'고 말씀 드렸습니다.손목 인식이 꺼져 있으면 어떻게 될까요? 정답은 'iPhone과 Apple Watch에 모두 전송된다'입니다.Apple에서 위와 같이 동작하는 지에 대한 설명이 따로 없어, 제가 추론한 내용을 정리했습니다(공식적인 설명이 아니므로, 참고 부탁드립니다).Apple에서 말하는 iPhone의 잠금 상태, 그리고 Apple Watch의 잠금상태/손목 착용 여부는 곧 사용자가 현재 어떤 기기를 사용하고 있는지를 판단하기 위한 기준입니다.Apple Watch는 iPhone과 달리, 화면이 항상 켜져 있는 경우는 잘 없습니다.사용자들은 대부분 Apple Watch를 일반 시계처럼 착용하고 일부 필요한 경우에만 화면을 터치하기 때

이번시간에는 Custom ItemReader와 ItemWriter에 대해서 알아볼 것이다.스프링 배치는 사전에 구현된 내장 ItemReader와 ItemWriter를 가지고 있어서 일반적인 케이스는 모두 수용이 가능하다.그러나 특이 케이스나, 비즈니스 로직에 딱 맞는 배치를 수행하기 위해서 Customize가 필요하다.- 우선 QueryDsl을 이용하여 Paging하여 데이터베이스의 값을 읽어 들이는 QuerydslPagingItemReader를 구현해 볼 것이다.- 그리고 CustomItemWriter를 구현하여 타 서비스를 호출하는 샘플을 만들어 보자.• None Querydsl은 SpringBatch의 공식 ItemReader이 아니다.• None 우리는 AbstractPagingItemReader를 이용하여 Querydsl 을 활용할 수 있도록 ItemReader를 만들 것이다.• None Querydsl 기능 활용: Querydsl의 강력하고 유연한 쿼리 기능을 사용하여 데이터를 효율적으로 읽을 수 있다.• None JPA 엔티티 추상화: JPA 엔티티에 직접 의존하지 않고 추상화된 쿼리를 작성하여 코드 유지 관리성을 높일 수 있다.• None 동적 쿼리 지원: 런타임 시 조건에 따라 동적으로 쿼리를 생성할 수 있다.• None• None 위 선언은 AbstractPagingItemReader 를 상속받았다.• None AbstractPagingItemReader은 어댑터 패턴으로, 상속받는 쪽은 doReadPage만 구현하면 된다.• None• None 위 내용과 같이 우리에게 필요한 부분은 name, entityManagerFactory, querySupplier, chunkSize 이다.• None name: ItemReader를 구분하기 위한 이름이다.• None entityManagerFactory: JPA를 이용하기 위해서 entityManagerFactory 를 전달한다.• None Function: 이는 JPAQuery를 생성하기 위한 Functional Interface 이다.• None 입력 파라미터로 JPAQueryFactory 를 입력으로 전달 받는다.• None 반환값은 JPAQuery 형태의 queryDSL 쿼리가 된다.• None chunkSize: 한번에 페이징 처리할 페이지 크기이다.• None alwaysReadFromZero: 항상 0부터 페이징을 읽을지 여부를 지정한다. 만약 paging 처리된 데이터 자체를 수정하는경우 배치처리 누락이 발생할 수 있으므로 이를 해결하기 위한 방안으로 사용된다.• None• None doClose는 기본적으로 AbstractPagingItemReader를 자체 구현되어 있지만 EntityManager자원을 해제하기 위해서 em.close() 를 수행한다.• None• None 실제로 우리가 구현해야할 추상 메소드이다.• None JPAQueryFactory를 통해서 함수형 인터페이스로 지정된 queryDSL에 적용할 QueryFactory이다.• None 만약