테크 뉴스
테크 뉴스 더 보기
기술 블로그

Kubernetes에서 NFS를 활용한 ReadWriteMany 스토리지 구성하기
Kubernetes 환경에서 여러 파드가 동시에 접근할 수 있는 공유 스토리지가 필요한 경우가 있다.이 글에서는 가장 간단하게 구성할 수 있는 NFS를 활용한 ReadWriteMany 스토리지 구성 방법을 알아본다.Kubernetes에서는 스토리지 접근 방식을 다음과 같이 구분한다:• None ReadWriteOnce (RWO): 단일 노드에서만 읽기/쓰기 가능• None ReadOnlyMany (ROX): 여러 노드에서 읽기만 가능• None ReadWriteMany (RWX): 여러 노드에서 읽기/쓰기 모두 가능• None Kubernetes SIG에서 개발한 Ganesha NFS를 사용하는 것이 가장 추천되는 방법이다. Helm을 통해 쉽게 설치할 수 있으며, 동적 프로비저닝을 지원한다.• None StatefulSet을 사용해 NFS 서버를 직접 구성할 수 있다:NFS 서버가 준비되면 다음과 같이 PV와 PVC를 구성한다:Ganesha NFS를 사용하는 경우 PVC만 생성하면 된다:아래는 앞에서 만든 pvc를 사용하는 3개의 pod를 생성하여 동시에 파일시스템을 활용하는 예시이다.• None NFS 클라이언트 패키지 설치가 필요• None 네트워크 성능이 스토리지 성능에 영향을 미침이렇게 구성된 NFS 스토리지는 여러 파드가 동시에 접근해야 하는 로그 수집, 공유 파일 시스템, 미디어 처리 등의 용도로 활용할 수 있다.
SK텔레콤
·
2일 전

현대차·기아에서 프론트엔드 개발에 다국어를 지원하며 협업하는 법 (feat. i18n)
들어가며안녕하세요, 인포테인먼트CCS개발팀에서 Frontend 업무를 수행하고 있는 이민재 연구원입니다.인포테인먼트CCS개발팀의 Frontend 개발자들는 CCS의 개발 및 운영, 이슈 파악등을 위한 팀 내의 백오피스 및 어드민 페이지들을 다양하게 구축하고 있습니다.커넥티드카 서비스는 글로벌하게 운영중입니다. 내수, 유럽, 북미, 아중동 등등 수 많은 지역에 전개되고 있습니다.커넥티드카 서비스를 글로벌하게 전개하고 운영하기 위해서는 현지의 연구소 분들, 협력사 및 개발자 분들과 개발/운영중인 시스템에 대해서 이슈가 발생할 때는 당팀에서 개발한 어드민을 통해서 소통을 하려고 했습니다만, 커넥티드카 서비스는 "글로벌"하지만, 기존에 Frontend 개발자들이 개발한 어드민들은 전부 한국어로 제작되어 있었습니다.이 부분에서 발생할 수 있는 문제점은현지 분들이 품질 게이트, 혹은 VOC가 들어온 이슈가 발생한 부분에 대해서 한국어만 봐야할 수 있음.개발된 페이지의 한국어에 대해서 다시 영어 혹은 현지 언어로 번역해야 함.등의 문제점들이 있을 수 있었습니다.이 문제를 해결하기 위해서 Frontend 개발자들은 i18n을 도입하여 어드민 및 백오피스를 개발하고 있습니다. 그렇다면 지금부터는 i18n을 당팀에서 어떻게 사용하고, 적용했는지 공유해드리려고 합니다.i18ni18n에 대해서 소개드리겠습니다. i18n은 "국제화"라는 의미입니다. "국제화"라는 단어를 직역하면 internationalization이라는 20개의 알파벳으로 이루어진 단어인데요, 여기서 맨 앞과 뒤의 철자만 빼면 18개가 됩니다. 그래서 이를 축약하여 i18n이라고 부르고 있습니다. 이는 mdn 공식문서에 잘 정리되어 있습니다. (출처: https://developer.mozilla.org/ko/docs/Glossary/Internationalization) 당팀에서 사용하는 i18n 라이브러리는 i18next입니다.i18next 라이브러리란?i18next는 다국어 지원을 위한 i18n 라이브러리이며 텍스트를 여러 언어로 번역하고, 관리할 수 있는 기능들을 제공합니다. i18next의 기능들로는 다국어 번역 관리, 언어 감지, 동적 번역 로딩, key에 대한 복수형 처리 기능, 내부적인 subscription을 통한 부분 번역 변경 등이 있습니다. 또한, 무엇보다도 커스터마이징과 여러 플러그인을 통한 개발이 가능하다는 장점을 가진 라이브러리입니다.설명에 앞서, Frontend에서 Next.js를 사용하는 두 가지 방식이 있습니다. 바로 SSR(Server-Side Rendering)과 CSR(Client-Side Rendering)인데요 저희 팀에서는 CSR을 위주로 사용했기 때문에 CSR에서 사용하는 방식을 설명해드리겠습니다.CSR? SSR?CSR (Client-Side Rendering):클라이언트(브라우저)에서 JavaScript를 사용하여 데이터를 렌더링합니다. 초기 로딩 시 HTML 구조만 다운로드되고, 이후에 JavaScript가 데이터와 함께 호출되어 페이지를 동적으로 생성합니다. 사용자 경험이 매끄럽고 빠르지만, SEO 최적화에 어려움이 있을 수 있습니다. SSR (Server-Side Rendering):서버에서 미리 렌더링된 HTML을 클라이언트에 전송합니다. 초기 로딩 시 완전한 HTML 페이지가 다운로드되므로, SEO에 유리하며 첫 페이지 로딩 속도가 빠릅니다. 그러나 서버에서 렌더링되기 때문에 서버의 부하가 증가할 수 있습니다.i18n을 사용하는 방법Directories1. Installation네 개의 dependency를 install합니다.2. i18n 설정installation 후에 i18n 관련 설정을 진행해주어야 합니다. 아래와 같이 i18n.ts 파일을 만들어 i18n에서 사용할 설정을 해줍니다.3. Provider 설정디렉토리 구조를 보면 아시겠지만, 위에서 생성한 i18n 인스턴스를 Provider에게 넘겨주어야 합니다. Provider 같은 경우에는 app 하위에 있는 layout.tsx에 주입하였습니다.4. locale 설정locale은 크게 아래의 두 가지 방법으로 설정할 수 있습니다.1. namespace로 나누어 namespace안에서 언어 별로 분리하는 법2. 언어별로 분리한 후에 namespace를 나누는 법당팀에서는 언어별로만 우선 분리를 하고, namespace는 따로 나누지 않는 전략을 선택했습니다. Frontend 개발자들끼리 내부적으로 잘 정의한 i18n locale Ground Rule을 정해, 이를 충실히 지킨다면 namespace를 따로 나눌 필요가 없다고 판단했습니다.Locale의 작성법은, 번역하고 싶은 string에 대해서 key를 먼저 선언하고, 번역은 value에 넣어줍니다. 아래의 json의 예시를 보시면 쉽게 이해가 되실겁니다.5. i18n 적용하기i18n은 쉽게 적용할 수 있습니다. 'react-i18next'에서 제공해주는 useTranslation hook을 사용하면 알아서 i18n 인스턴스를 통해 설정된 언어를 불러와서 화면에 render하게 됩니다.하지만 여전히 발생되는 에러이렇게 잘 설정을 한 것 같았지만, 브라우저와 console에서는 아래와 같은 에러가 뜨고 있었습니다.바로, hydration error입니다. 'use client'를 사용했음에도 불구하고, Next.js단에서 html을 미리 만들고 내려주는 text와 browser에서 초기에 render되는 text가 다른, 즉 React 트리가 아직 DOM과 동기화 되지 않은 상태로 Browser에 그려주려고 했기 때문에 발생하는 문제였습니다.이 문제는 간편하게 해결하는 방법은 react-i18next 라이브러리를 사용하지 않고, next-i18next를 사용하는 방법이었습니다.하지만, 저희는 조금 더 CSR스럽게 프로젝트를 진행하고 싶었기 때문에 dynamic을 통해 SSR로 render하는 것을 강제로 꺼버리도록 설정하는 방법을 사용했습니다. 아래의 코드처럼 dynamic을 적용해서 hydration error를 처리했습니다.6. 언어를 변경하는 방법언어를 바
현대자동차그룹
·
2일 전

모두를 위한 LLM 애플리케이션 개발 환경 구축 사례
안녕하세요. Game Platform Dev의 류동훈, Zhang Youlu(Michael), Takenaka, 이형중입니다. 저희 조직은 게임 퍼블리싱에 필요한 다양한 기능을 개발하고 운영하는 역할을 맡고 있습니다.저희는 최근 조직 내 업무 효율을 높이기 위해 다양한 LLM(large language model) 애플리케이션을 개발하고, 이와 연계해 LLMOps 시스템 구축 프로젝트를 진행했습니다. 프로젝트의 주요 목표 중 하나는 진입 장벽이 높은 LLM 애플리케이션 개발을 직군에 상관없이 누구나 쉽게 제작할 수 있는 환경을 구축하는 것이었는데요. 이를 위해 여러 가지를 고민하며 시도하는 과정을 거쳤고, 그 결과 누구나 손쉽게 접근할 수 있는 개발 및 배포 환경을 마련할 수 있었습니다.이번 글에서는 LLM 애플리케이션의 일반적인 개발 방식과 개발 과정에서 마주하는 어려움을 살펴보고, 이런 문제를 해결할 수 있는 환경을 구성하기 위해 저희가 어떤 고민을 하고 노력을 했는지 공유하고자 합니다. 이 글을 통해 LLM 애플리케이션 개발 과정의 병목 지점을 개선하고 고도화해 접근성을 높일 수 있는 인사이트를 얻으시길 바라며 시작하겠습니다.LLM 애플리케이션의 개발 과정최근 OpenAI의 GPT와 Anthropic의 Claude 같은 고성능 LLM을 쉽게 활용할 수 있게 되면서, LLM 애플리케이션 개발의 초점이 이러한 모델을 효과적으로 활용해 서비스를 제공하는 방향으로 전환되고 있습니다. 모델을 직접 학습시키거나 파인튜닝(fine-tuning)하지 않고, 비용 효율을 고려해 상용 모델을 그대로 사용하면서 모델의 입력인 프롬프트를 구조화해 모델이 이를 잘 이해하도록 만드는 데 집중하고 있는 것입니다.프롬프트는 모델이 수행해야 할 작업의 맥락과 방향을 제시하므로 프롬프트를 잘 구조화하면 LLM의 성능을 한층 더 높일 수 있습니다. 또한 프롬프트는 수정하기 쉽기 때문에 비싼 비용을 지불해 모델을 직접 수정하는 것보다 훨씬 저렴하다는 장점도 있습니다. 이런 장점을 이용해 개발자들은 보다 빠르고 경제적으로 모델의 성능을 최적화할 수 있습니다.하지만 LLM 애플리케이션이 새로운 데이터에 대해 적절히 답변하도록 만드는 문제는 프롬프트 최적화만으로는 해결할 수 없습니다. 그럼 이 문제를 모델을 추가 학습하지 않고 어떻게 해결할 수 있을까요?일반적으로 이런 문제는 LLM의 몇 가지 기능을 활용해 해결합니다. LLM은 사전 학습된 데이터 외에 프롬프트에 제시된 추가 정보를 통해 즉석에서 정보를 생성할 수 있습니다. 이런 기능을 인 컨텍스트(in-context) 러닝이라고 합니다. 인 컨텍스트 러닝 중 특히 몇 가지 예시 답변을 통해 모델이 패턴을 익히고 더욱 잘 답변하게 만드는 것을 퓨 샷(few-shot) 러닝이라고 하는데요. 이를 이용해 프롬프트에 정보를 주입하면 LLM이 새로운 데이터에 대해 적절히 답변할 수 있게 만들 수 있습니다.이제 LLM이 새로운 데이터에 대해 답변할 수 있게 됐지만 인 컨텍스트 러닝과 퓨 샷 러닝, 두 가지 기법만으로는 새로운 데이
라인
·
3일 전

오픈채팅 Lite FE 성능 개선의 모든 것
안녕하세요, 오픈채팅 Lite의 stella, roddy, holly입니다.오픈채팅 Lite는 부담 없이 수많은 사람들과 대화할 수 있도록 하는 것을 목표로 개발된 서비스로, 지금 이 순간에도 다양한 주제로 많은 이야기가 만들어지고 있습니다.하나의 주제로 많은 사람이 제한 없이 참여할 수 있다는 서비스 특성상, 유저들의 화력에 따라 짧은 시간 안에 한 화면에 적게는 수십 개, 많게는 수백, 수천 개의 메시지가 몰릴 수 있습니다. 그만큼 오픈채팅 Lite에서는 화면 렌더링 성능에 큰 관심을 기울이고 있습니다. 약간의 개선 혹은 개악으로도 유저들의 체감 성능이 극적으로 바뀔 수 있기 때문이에요.이번 포스트에서는 오픈채팅 Lite FE에서 진행했던 여러 렌더링 성능 개선 시도, 그리고 그 결과를 공유합니다. 간단한 컴포넌트 개선부터 라이브러리 사용 컨벤션, 코어 로직의 변경까지 여러 방면에 걸쳐 개선을 진행하였으니 많은 관심을 가지고 지켜봐 주세요!이 게시글에서 발생하는 여러 가지 문제 상황들은 단숨에 발생한 것이 아니라, 23년 5월 오픈채팅 Lite 런칭 이후 꾸준한 기능 개발 및 구조 개선을 거쳐오며 수정된 것입니다. 전후 비교 영상 혹은 그래프는 개선 양상을 보여드리기 위해 테스트 환경을 구성하여 촬영된 것으로, 오픈채팅 Lite의 현재 성능 및 동작과는 다를 수 있습니다.먼저, 오픈채팅 Lite를 개발하면서 직면했던 여러 가지 성능 문제를 소개하겠습니다.잠깐 텍스트를 보내고 나가는 사용성에서는 크게 문제가 되지 않았지만, 한 주제에서 여러 채팅방을 이동하며 대화하거나, 오랜 시간 채팅방에 머물며 여러 개의 메시지를 받을 경우 유저가 체감할 수 있을 정도로 점점 동작이 느려지는 현상이 발생했습니다.메시지를 주고받는 동안에도 문제가 발생했어요. 누군가 보낸 메시지가 화면에 그려지는 동안, 유저가 누른 버튼이 동작하지 않다가 뒤늦게 동작하는 현상이 발생했습니다. 평소에도 종종 발생하지만, 시즈널 이벤트를 기념하는 채팅방에서는 수많은 사람이 메시지를 작성하기 때문에 이 문제점이 더 극명하게 드러났습니다. 이 현상은 안드로이드보다는 iOS에서 더 잘 재현되었어요.화면이 깜빡이는 현상마지막으로, 유저의 참여율이 높은 주제에서 채팅방에 너무 빠른 속도로 메시지가 쌓일 때 발생하는 문제입니다. 우리가 기대한 동작은 메시지가 빠르게 주르룩 올라가는 그림이었는데, 메시지가 전역 스토어에 쌓이는 속도 대비 메시지가 그려지는 속도가 충분하지 못해서 화면이 하얗게 보이는 현상이었어요. iOS보다는 안드로이드에서 더 잘 발생했습니다.여러 가지 방법으로 두 현상을 개선할 수 있겠지만, 여기서는 컴포넌트를 좀 더 빨리 그리는 방법에 집중해 보겠습니다.먼저 첫 번째, 앱이 점점 느려지는 이유 중 하나는 DOM에 그려진 컴포넌트가 시간이 지날수록 점점 늘어나기 때문입니다. 말풍선 하나를 그릴 때마다 a만큼의 메모리를 사용한다고 하면, n개의 말풍선을 그리기 위해서는 총 a*n만큼의 메모리가 필요하죠. a와 n을 줄일 수 있다면 위의 두 가지 문제를 해결할 수 있을
카카오
·
3일 전

FastAPI에 모듈화된 구조 적용을 통한 빠른 프로토타이핑
오늘은 FastAPI와 SQLite를 사용하여 간단한 사용자 정보 관리 기능을 구축하고, 프로젝트를 모범 사례에 맞게 그리고, Fast라는 말에 걸맞게 신속하게 모듈화하는 과정을 공유해보려 합니다.이 글에서는 FastAPI의 주요 기능들을 활용해 어떻게 프로젝트 구조를 만들 수 있는지에 관한 간단한 예시를 소개합니다.이 프로젝트 구조는 API 엔드포인트(api/)와 데이터베이스 연동(db/, crud/)을 모듈화하여 관리합니다.• None 모델 정의는 models/에,• None 데이터 검증용 스키마는 schemas/에 분리하여 코드의 가독성과 유지 보수성을 높였습니다.• None 최상위 main.py는 FastAPI 애플리케이션을 초기화하고 라우터를 등록하는 역할을 합니다.이제, 각 모듈이 어떤 역할을 하는지 자세히 살펴보겠습니다.SQLite 데이터베이스를 설정하기 위해 파일을 작성했습니다.여기서는 함수를 통해 **의존성 주입(Dependency Injection)**을 사용하여 데이터베이스 세션을 주입합니다.2) 데이터베이스 모델 정의 (models/user.py)사용자 테이블을 정의하기 위해 파일을 작성했습니다.입력과 출력을 검증하기 위해 Pydantic 모델을 사용했습니다.데이터베이스와 상호작용하는 CRUD 함수들을 에 정의했습니다.에서는 사용자 관련 API를 정의했습니다.파일에서 FastAPI 애플리케이션을 생성하고 라우터를 등록합니다.서버 기동에 필요한 패키지를 배포합니다.이제 모든 준비가 끝났습니다! FastAPI 서버를 실행해서 API의 동작을 확인해 볼 수 있습니다.• None 모듈화된 프로젝트 구조의 중요성 🚀• None , , , , 로 기능을 분리하여 코드 가독성과 유지 보수성을 크게 향상할 수 있습니다. 모듈화를 통해 재사용성과 확장성이 극대화되었으며, 추후 기능 추가나 데이터베이스 변경이 용이한 구조를 갖추었습니다.• None• None 의존성 주입(Dependency Injection)을 사용해 데이터베이스 세션을 안전하게 관리하고, Pydantic을 활용해 입력 데이터 검증을 강화할 수 있습니다.• None SQLite와 SQLAlchemy를 통한 빠른 프로토타이핑 💡• None SQLite를 사용해 빠르게 데이터베이스 설정을 완료하고, SQLAlchemy로 ORM 방식을 적용해 데이터베이스 관련 처리를 직관적이고 효율적으로 구성할 수 있습니다.• None API 설계와 예외 처리의 중요성 🛡️• None RESTful API 원칙을 준수하며, FastAPI의 HTTPException을 활용해 에러 처리를 구조화했습니다. 이를 통해 명확한 에러 메시지 제공으로 사용자 경험을 개선할 수 있습니다.• None• None FastAPI의 자동 Swagger 문서 생성을 통해 API 테스트를 효율적으로 진행할 수 있었고, 을 사용해 빠르게 서버를 실행해 개발 속도를 높일 수 있습니다.
SK텔레콤
·
3일 전

기존 서비스 국제화(i18n) 작업 쉽게 덜어내기: t 함수 자동 래핑 스크립트 만들기
안녕하세요. 인프랩의 랠릿 셀 프론트엔드 개발자 고슈, 도니, 루시입니다.2024년 초, 연간 플래닝에서 CTO인 향로에게서 예상치 못한 발표를 듣게 됩니다.이렇게 랠릿을 포함한 인프랩 개발파트는 레거시 코드 정리부터 국제화 작업까지, 인프런의 글로벌 서비스 출시를 위한 새로운 도전을 시작하게 되었습니다.i18n을 서비스에 적용하는 전체 과정보다는, 기존 서비스를 다국어 서비스로 전환하는 과정에서 i18n 을 효율적으로 적용하는 방법에 대해 공유하고자 합니다. 이후 적용 과정에 대한 상세한 내용은 후속 글에서 다루도록 하겠습니다.들어가기 앞서, Next.js 기반의 프로젝트에서 다국어 지원을 위해 일반적으로 사용되는 라이브러리에 대해 먼저 살펴보겠습니다.간단한 사용 예시를 보면 다음과 같습니다.이제 이 라이브러리를 활용하여 어떻게 효율적으로 기존 서비스에 국제화를 적용했는지 살펴보도록 하겠습니다.기존 인프런 담당 셀에서 레거시 코드의 React 마이그레이션이 진행을 진행중에 있어서 랠릿 셀은 이미 React로 전환된 코드들에 대한 i18n 적용을 가장 먼저 담당하게 되었습니다. 따라서 다른 셀과 함께 작업 하면서 사용할 효율적인 컨벤션을 먼저 결정할 필요가 있었습니다. 이 과정에서 가장 중요한 초기 결정 사항 중 하나는 다음과 같았습니다.이 문제에 대한 해답을 찾기 위해 다양한 개발자들과의 네트워킹을 하며 인사이트를 얻었습니다. 그 중 기억에 남는 의견이 있었습니다.이 의견에 많은 개발자들이 동의했고, 그 이유를 물어보니 다음과 같은 공통된 피드백을 얻을 수 있었습니다.• 영문 키를 사용할 경우 대응되는 번역 키를 찾는 과정이 번거로움이러한 인사이트를 바탕으로, 랠릿셀은 함께 언어 자원의 키 정의에 대한 세 가지 컨벤션을 수립하고, 각각의 장단점을 분석하여 PM과 PD에게 제안하게 되었습니다.서비스의 국제화를 위한 언어 자원 키 정의 방식을 세 가지로 분류하여 분석했습니다.한국어 텍스트를 그대로 키로 사용하는 방식입니다.• 키 정의 과정 생략 가능• 원본 텍스트 변경 시 키도 함께 수정 필요• 비개발 직군의 낮은 직관성 (URL 구조 이해 필요)최종적으로 을 채택했습니다. 주요 결정 요인은 다음과 같습니다.• 프로젝트의 시간 제약 상황 고려이러한 결정은 빠른 구현과 팀 전체의 효율성을 우선시한 결과였습니다.배경과 아이디어i18next-parser나 i18next-scanner는 i18n이 적용된 코드에서 번역 키를 추출하여 JSON 파일을 생성해주는 기능을 제공합니다.컨벤션도 정해졌으니, 이제 기존에 있던 한글들을 모두 t로 감싸주면 됩니다.이 한숨 앞에서 괜찮은 생각이 스쳐 지나갔습니다.결국 우리는 반복 작업을 줄이려고 개발을 시작한 사람들이니까요.그렇다면… 기나긴 전체 서비스 소스에서 번역 대상이 될 한글 텍스트를 어떻게 찾아내고, 수정할 수 있을까요?백엔드 개발자인 우드가 던진 이 한마디가 스크립트의 출발점이 되었습니다.저희는 Babel에서 제공하는 라이브러리를 이용해 AST 기반으로 소스 코드를 파싱하고, 탐색하고, 수정하기로 했
인프런
·
3일 전
기술 블로그 더 보기
테크 뉴스
테크 뉴스 더 보기
코드너리에서 이용할 수 있는
새로운 기능
새로운 기능
지금 확인해 보세요!

이달의 컨퍼런스
컨퍼런스 일정 더 보기