국내 IT 기업들의 기술 블로그 글을 한 곳에서 모아보세요
안녕하세요. 올리브영의 배포 문지기를 맡고 있는 QA 엔지니어 황소입니다. 이번 글에서는 Datadog을 올리브영 QA는 어떻게 활용하고 있는지에 대해서 공유합니다. 목차 QA가 Datadog을 활용하게 된 이유 올리브영 QA는 Datadog…
메타 세상에서 팬덤을 창조하기 위해서는 기업에서도 MZ세대의 인문학, 예술, 대중문화에 대한 학습을 확대해야 합니다.
알리익스프레스와 CJ제일제당의 협력은 한국 시장에서 주목할만한 이벤트로, 한국 시장에서의 알리 입지를 더욱 강화하는 계기가 되었습니다. 알리의 한국 시장 확대는 단순한 진출을 넘어서, 글로벌 이커머스 산업의 경계를 재정립하고, 중국 기반 이커머스 플랫폼들이 전 세계적으로 어떻게 영향력을 확대해 나가고 있는지 잘 보여주고 있는 사례입니다.
안녕하세요. FE개발팀 조성창 입니다. 사람인에선 서비스의 레거시 영역을 점진적으로 개선해 나가고 있습니다. 그동안 FE개발팀은 긱이나 멘토링 같은 버티컬 서비스의 FE개발을 진행해왔는데, 작년부터 주요서비스의 FE분리를 시작하면서 FE 영역의 아키텍쳐에 대한 고민을 했었습니다. 그 결과 Monorepo를 적용하기로 하였고 첫번째 서비스가 배포를 앞두...
인공지능(AI)과 로보틱 프로세스 자동화(RPA)의 융합은 비즈니스 프로세스를 혁신하고, 업무 효율성을 극대화하는 새로운 가능성을 열어주고 있습니다. 이러한 기술의 융합은 단순한 작업 자동화를 넘어서, 기업이 대면하는 복잡한 문제들을 해결하고, 더 스마트하고 유연한 방식으로 작업을 수행할 수 있도록 만들어줍니다.
안녕하세요. 인벤토리 스쿼드 백엔드 개발자 펭귄대장입니다! 인벤토리 스쿼드에서 재고 변경 이력을 관리하기 위해 OpenSearch + EFK 를 구축하게 되어 소개 드립니다. 이전 포스팅에서 자주 언급되었듯이, 올리브영은 Datadog…
안녕하세요. 모바일앱개발팀 윌, 의지수입니다🙇♂️ 이번 글에서는 올리브영 앱의 바코드 스캔 성능을 개선한 경험을 공유하고자 합니다. 2024 APP뿐페스티벌 올리브영은 매년 옴니채널 활성화를 위해 APP뿐페스티벌을 진행합니다. 올해 APP…
…
Fixture를 활용한 테스트 코드 작성해보겠습니다. 그런데 이제 🙉 를 곁들인... 안녕하세요. 😀 올리브영에서 백엔드 개발을 하고 있는 윤노트입니다. 테스트 코드를 작성할때 사용하는 Fixture…
생성형 AI는 비교적 새로운 기술임에도 불구하고 잠재적 비즈니스 가치를 고려할 때 이제 이 기술이 없는 세상을 상상하기가 어렵습니다. 많은 기업이 향후 12개월 동안 5% 이상의 생산성 향상이 가능할 것으로 예상하고 있습니다.
Photo by Jo Barnard on UnsplashHEIC/HEIF 란?HEIC(High Efficiency Image Container) 파일 포맷은 Apple이 모바일 디바이스에서 전통적으로 사용하던 HEIF(Efficiency Image Format)의 업데이트 버전입니다.출처: HEIC 파일의 역사 / 장,단점HEIC 형식은 우리 주변에서...
2014년부터 시작되어 매년 미국 라스베이거스에서 열리는 AWS 공식 개발자 행사인 re:Invent! 개발자들의 축제 현장에 다녀온 올디브의 이야기 지금부터 시작합니다. 2023년 AWS re:Invent (이하 : AWS)는 11월 2…
AI 기술이 급속도로 발전하며 다양한 비즈니스 기회를 제공하고 있는 한편, AI 시스템이 평등권, 프라이버시 등 기본권을 침해할 수 있는 만큼 리스크를 안고 있습니다. EU, OECD 등 국제사회가 발표하는 AI 관련 규범과 법규 및 권고를 바탕으로 사전에 안전하고, 신뢰할 수 있으며 지속 가능한 AI 시스템을 개발할 수 있도록 대응해야 합니다.
안녕하세요, 네이버 페이에서 프론트엔드를 개발하고 있는 이창재입니다.네이버 파이낸셜에서는 GitHub를 통해 코드를 관리하고 있고, 자연스레 GitHub Actions를 활용하여 효율성을 더하고 있습니다.이번 글에서는 실제 사용중인 GitHub Actions 중 간단한 예시와 함께 해당 개념에 대해 소개하고자 합니다. 시작에 앞서 기본 개념을 짚고 넘어가겠습니다.👀 GitHub Actions?GitHub Actions란 GitHub 저장소를 기반으로 워크플로우를 자동화 할 수 있는 도구, GitHub가 제공하는 완전관리형 CI/CD 툴입니다.✒️ CI/CD?참고 자료 : RedHat 문서 — CI/CD란?📄 CI(Continuous Integration) — 지속적인 통합* PR이나 push된 코드를 빌드 및테스트하는 프로세스를 자동화하고, 이러한 프로세스를 거친 후 코드를 merge해 주는 자동화 프로세스입니다.* 이 과정에서 충돌이나 Lint, 정상 동작 등 자동화된 테스트를 실행하여 변경 사항을 검증합니다.📄 CD(Continuous Delivery, Deployment) — 지속적인 제공 및 배포* Delivery(지속적 제공) : CI를 거친 후 레포에 업로드되는 것을 의미합니다.* Deployment(지속적 배포) : 배포과정을 자동으로 처리해주는 것을 의미합니다.📄 CI/CD의 목적반복적인 일(빌드, 테스트, 배포 작업 등)을 처리하고 그 과정에서 이슈 발생 시 경고해주는 등, 자동화된 파이프라인을 통해 코드 변경과 배포 단계를 원활하게 진행할 수 있도록 해 줍니다.이 과정에서 시간 절약 및 사람이 직접적으로 처리할 때 발생하는 실수, 즉 휴먼에러를 방지할 수 있습니다.🎯GitHub Actions 특징* 컨테이너(도커) 기반으로 동작합니다.* 개발자는 워크플로우를 작성하여 다양한 이벤트 기반으로 실행시킬 수 있습니다.* 워크플로우는 Runners라 불리는 인스턴스에서 리눅스, 맥, 윈도우 환경에서 실행됩니다. (동시 테스트도 가능!)* GitHub 마켓 플레이스에서 필요한 Workflow를 찾아 사용할 수 있고, 직접 만들어 마켓 플레이스에 공유할 수도 있습니다.😄GitHub Actions의 장점* 다른 CI/CD툴(ex. 젠킨스)처럼 별도 서버 설치와 같은 복잡한 절차 없이 사용이 가능합니다.* 즉 GitHub에서 제공하는 완전 관리형 서비스이므로 설정이 매우 간편하고 GitHub API에도 쉽게 접근할 수 있습니다.* 비동기적 병렬 실행이 가능한 CI/CD입니다.* GitHub 마켓플레이스를 통해 필요한 워크플로우를 내려 받거나 공유할 수 있습니다.🤔GitHub Actions의 단점* 서버에 장애가 일어나거나 리소스를 초과할 경우 개발자가 직접 문제를 해결해야 합니다.⚙️GitHub Actions 핵심 개념참고자료 : GitHub Docs — GitHub Actions 이해Workflows* GitHub Actions의 기본 구성 단위로써 가장 최상위 개념입니다.* 자동화된 프로세스가 정의되어 있는 파일로 YAML 파일에 정의됩니다.* 하나 이상의 작업을 포함할 수 있으며 해당 파일을 실행할 규칙, 동작 등이 작성되어 있습니다.Events* 워크플로우를 시작하는 트리거(push, PR 등)로써, 워크플로우 파일 내에 정의됩니다.Jobs* 워크플로우 내에서 실행되는 개별 작업입니다.* 이벤트로 워크플로우가 실행되면 Job에 작성된 명령들이 Runner에서 실행됩니다.* 기본적으로 Job들은 병렬로 실행되지만, 서로 의존관계를 가질 수도 있고 직렬로 실행할 수도 있습니다.* Job은 자신의 환경 설정과 Steps를 가지고 있습니다.Steps* Job내 작업의 가장 작은 단위입니다.* 각 step들은 스크립트나 명령어 또는 액션을 실행할 수 있습니다.Actions* 작업 흐름에서 공유 및 결합할 수 있는 재사용 가능한 코드 단위입니다. 컴포넌트라고 볼 수 있습니다.* 마켓에 등록되어 있는 Action을 가져오거나, 별도 레포에 작성하여 해당 레포의 이름으로 워크플로우의 파일에서 참조할 수 있습니다.Runners* 워크플로우가 실행되는 가상 머신 또는 자체 호스팅 환경입니다.* 기본적으로 GitHub에서 워크플로우를 구동할 리눅스, 윈도우, 맥OS 운영체제의 Runner를 제공하며, 필요시 self-hosted-runner를 등록할 수도 있습니다.GitHub Actions에는 도커(Docker) 컨테이너 액션, 복합(Composite) 액션, 그리고 자바스크립트를 활용한 액션, 이렇게 3가지 종류의 액션이 존재합니다. 그 중 이번 글에서는 자바스크립트를 활용한 액션 예시를 준비했습니다.아래는 해당 예시를 위한 특정 상황입니다.정기배포 이후 릴리즈 브랜치를 alpha나 beta와 같은 기존 작업 브랜치에 머징해야 할 필요성이 있습니다.하지만 해당 PR 생성 후 Lint나 Unit Test와 같은 테스트 워크플로우들이 모두 실행 완료될때까지 기다리기엔 너무나도 귀찮습니다. 가끔 일에 치여 머징하는걸 깜빡하고 한참 후에 최근 릴리즈 브랜치가 반영되지 않았다는 것을 깨닫기도 합니다.따라서 특정 워크플로우 체킹이 완료된 후 source branch가 `release/`로 시작하면 머징을 진행하는 자동화된 워크플로우가 있으면 좋겠다는 생각을 하게 됩니다.해당 예시의 전체적인 레포 구조는 위와 같습니다.📑action.yaml가장 먼저 action에 대해 작성할 필요가 있습니다.기본적으로 해당 action의 설명과 필요한 파라미터를 기술하는 부분으로 크게 name, description, inputs, runs, branding 5가지 섹션으로 나누어져 있습니다.이 중 name, description, runs는 필수로 작성해주어야 합니다.name: Auto merge when head branch starts with 'release/'description: 'Prevent merging if a specific label is attached to a PR'inputs: token: description: 'Github token' required: true workflow: required: true description: 'File name of the workflow you wanna wait for' interval: description: 'The interval between workflow checks (default is 3s)'runs: using: 'node16' main: 'dist/index.js'📄inputsinputs.<input_id> — token, workflow, interval필요한 input 파라미터의 변수명을 지어줍니다. 이 변수명은 나중에 js 코드상으로 불러올때 필요하기에 의미에 맞게 작성할 필요성이 있습니다.inputs.<input_id>.descriptioninput 파라미터에 대한 설명을 적어줍니다.inputs.<input_id>.required필수 파라미터 여부를 표시해줍니다.inputs.<input_id>.default필요 시 디폴트 값을 설정해 줍니다. 이때 무조건 string 값만 사용할 수 있습니다.📄runsruns.using코드를 실행시킬 환경을 설정합니다. (필수)runs.main실행할 필수 작업 코드가 포함된 파일의 main path를 지정합니다. (필수)runs.env필요한 환경변수를 지정합니다📄branding마켓플레이스 배포 시 표시될 아이콘을 설정해 줍니다.📑src/index.ts본격적인 action 작업코드를 작성하는 파일입니다.해당 자바스크립트 코드 작성 도와주는 다양한 툴킷이 존재합니다.여기서는 @actions/core와 @actions/github을 사용하여 개발을 진행하였습니다.* @actions/core: workflow에 대한 inputs, outputs, logging 등의 함수를 제공합니다.* @actions/github : 인증된 Octokit client를 제공해줍니다.import * as core from '@actions/core'import * as github from '@actions/github'async function run(): Promise<void> { const workflows: string[] = core .getInput('workflow', { required: true, }) .split('|') .map((item) => item.trim()) const interval: number = +core.getInput('interval') * 1000 || 3000 const token: string = core.getInput('token', { required: true, }) const memes = [ '잘했어요 밈1', '잘했어요 밈2', '잘했어요 밈3', '잘했어요 밈4', '잘했어요 밈5', '잘했어요 밈6', ] const octokit = github.getOctokit(token) const {pull_request} = github.context.payload const {owner, repo} = github.context.issue const pr_number = pull_request?.number const head_ref = pull_request?.head?.ref || '' try { for (const workflow of workflows) { core.info(`Waiting until workflow ${workflow} ends`) let workflowIsRunning do { await new Promise((resolve) => setTimeout(resolve, interval)) workflowIsRunning = await checkIfWorkflowIsRunning(workflow) } while (workflowIsRunning) } if (pr_number && head_ref.startsWith('release/')) { await octokit.rest.pulls.createReview({ owner, repo, pull_number: pr_number, body: memes[Math.floor(Math.random() * memes.length)], event: 'APPROVE', }) await octokit.rest.pulls.merge({ owner, repo, pull_number: pr_number, merge_method: 'merge', }) core.info('LGTM & Merge') } else { core.info(`Check exist PR number : ${pr_number} or source branch(${head_ref}) starts with release/`) } } catch (error) { if (error instanceof Error) { core.setFailed(error.message) } }}run()async function checkIfWorkflowIsRunning(workflow: string): Promise<boolean> { const token: string = core.getInput('token', { required: true, }) const octokit = github.getOctokit(token) const {owner, repo} = github.context.issue const { data: {workflow_runs}, } = await octokit.rest.actions.listWorkflowRuns({ owner, repo, workflow_id: workflow, per_page: 5, }) return workflow_runs.some( (workflow_run) => workflow_run.status === 'queued' || workflow_run.status === 'in_progress', )}📄input값 가져오기위 action.yaml에서 지정한 input값의 경우 core.getInput({input_변수명})으로 불러올 수 있습니다.input값을 가져오는 방법만 안다면 나머지 로직의 경우 개발자가 원하는 대로 작성할 수 있습니다.위 예시에서처럼 github의 기능(pull request 작성, apporve, merge 및 owner, repo등 값 추출 등)을 사용하고 싶다면 octokit document를 참고하여 작성해 주면 됩니다. 😎🚀만든 액션 사용해보기위와 같이 작성된 액션은 사용하고자 하는 레포의 ./github/workflows 폴더 내에 워크플로우를 작성하여 사용할 수 있습니다.# 워크플로우의 이름입니다.name: test-workflow# 워크플로우를 동작하게 하는 트리거입니다.# 해당 트리거의 종류는 아래 GitHub Docs에서 확인할 수 있습니다.# https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_requeston: # 여기서는 alpha, beta 브랜치를 대상으로 pull reqeust가 발생할 때 트리거링되도록 작성되었습니다. pull_request: branches: - alpha - beta# 위에서 서술한 jobs의 핵심 개념과 동일한 개념입니다.jobs: # 여기서는 call-workflow라는 하나의 job을 작성하였습니다. call-workflow: # 구동 환경입니다. 여기서는 리눅스 환경에서 실행합니다. runs-on: ubuntu-latest # 위에서 서술한 steps의 핵심 개념과 동일한 개념입니다. # 상세 내용은 아래 GitHub Docs에서 확인할 수 있습니다. # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps steps: - name: check PR # 사용할 액션 위치입니다. 소유자/저장소@브랜치 형태로 가리켜주면 됩니다. uses: common/auto-release-merge-action@main # with 키워드를 통해 action에 값을 전달할 수 있습니다. # 이전 작성한 액션에서 token, workflow 파라미터를 필수 필요로 했으므로 해당 값을 전달해 줍니다. with: token: ${{ secrets.ACTION_TOKEN }} workflow: 'ci.yaml | lint.yaml'여기서 token의 secrets 값의 경우 레포 세팅 탭에서 설정할 수 있습니다.Settings > Secrets and Variables > Actions 에서 환경변수를 생성하여 secrets.환경변수명 으로 호출할 수 있습니다.GitHub Actions를 사용할 때 민감한 정보의 경우는 여기서 관리하면 좋습니다.네이버 파이낸셜에서 사용중인 GitHub Actions 중 간단한 예시를 개념과 함께 살펴보았습니다.GitHub Actions은 이 글에서 설명된 작업 말고도 훨씬 다양한 상황에서 사용될 수 있습니다. 여러분들의 레포에서 단순 반복되는 작업이 존재한다면 이번 기회에 GitHub에게 맡겨보는 건 어떨까요? 😊이 포스트가 여러분들께 조금이나마 도움이 되었으면 합니다. 읽어주셔서 감사합니다 🙇♂️🔖참고 자료* RedHat 문서 — CI/CD란?* Github Actions or Jenkins? Making the Right Choice for You* GitHub Docs — GitHub Actions* Octokit DocumentGitHub Actions 활용하기 was originally published in NAVER Pay Dev Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
AI 팀 구성은 계속 발전하는 과정의 문제여야 합니다. 조직이 AI로 하고자 하는 것을 파악하는 것이 매우 중요하고, 혁신에 대한 열망과 헌신, 그리고 전략이 있어야 합니다. 그리고 목적과 목표를 파악한 후에 맞는 팀을 구성해야 합니다.
안녕하세요. 사람인 개발팀 노혜민입니다. 이번 포스팅은 Vue3, Composition API와 Pinia를 이용한 상태관리 (1) 글의 후편입니다. 이전 포스팅에서 Composition API, Pinia에 대한 이론적인 설명을 다루었다면 이번 포스팅에서는 실제로 Pinia를 어떤 방식으로 적용했고 어떤 작업 결과를 냈는지 다루려합니다. 글의 목차는...
고객 경험은 생성형 AI의 강력한 영향력 아래에 있습니다. 생성형 AI는 방대한 데이터를 기반으로 고객과 소통하고 문제를 더 빠르게 해결하는 과정에 사용되고 있습니다. 고객센터에 생성형 AI를 결합하려는 기업이 점점 늘고 있습니다.
생성형 AI 기술의 발전에 따라 많은 기업에서 자사 서비스에 생성형 AI 기술을 적용하려는 움직임이 활발하게 일어나고 있습니다. 삼성SDS 역시 AI 기술이 적용된 신규 서비스 발굴과 기존 서비스와의 통합을 위해 다양한 시도를 하고 있습니다. 그 중 삼성SDS Gen AI 해커톤에서 소개된 고객 기술지원 업무에서 활용할 수 있는 AI 기반 서비스와 기...
기업이 ESG 목표를 달성하기 위해서는 다양한 기술을 적극적으로 활용할 수 있어야 하는데, 이때 클라우드, 데이터, AI는 핵심 기술로서 중요한 역할을 합니다. 클라우드와 빅데이터 기술을 통합함으로써 에너지 사용 최적화와 지속 가능한 자원 관리가 가능해지고, AI와 머신러닝은 신재생 에너지의 효율적 관리와 배분에 활용할 수 있습니다.
안녕하세요. 사람인 FE개발팀 지성봉입니다. 사람인 FE 개발팀에서는 기존의 사람인 서비스를 점진적으로 FE 분리 전환을 진행 중에 있는데요, 최근 사람인 서비스 중 신입·인턴 채용달력 모바일 서비스(이하 채용달력)를 React + TypeScript(이하 TS)로 전환하게 되었습니다. React + TS로의 전환은 제 개인적으로도 제법 작지 않은 도...
안녕하세요! 상품스쿼드 백엔드 개발자 빽곰입니다. 상품스쿼드에서 상품데이터 Pipeline을 위해 도입한 Debezium CDC…
목차 들어가며 1.1 데이터프로덕트그룹 소개 1.2 Data Product 시리즈 소개 1.3 왜 AI 세차가 데이터프로덕트인가? AI(데이터)기반 세차 오퍼레이션 소개 2.1 세차 오퍼레이션 배경 및 AI모델 소개 2.2 세차 요청 로직 개선 2.3 세차 오퍼레이션 아키텍쳐 문제 정의 및 해결 과정 3.1 1차 분석 시도 3.2 ground trut...
랭체인은 언어 모델 기반의 애플리케이션을 개발하는 프레임워크입니다. 랭체인을 사용해 챗봇 또는 개인 비서를 만들고, 문서 또는 구조화된 데이터에 대한 Q&A를 요약, 분석, 생성하고, 코드를 쓰거나 이해하고, API와 상호작용하고, 생성형 AI를 활용하는 여러 애플리케이션을 만들 수 있습니다.
소개 안녕하세요. 다나와에서 검색 서비스를 개발하고 있는 곽명환입니다. 오늘은 주기적으로 들어오는 요청의 자동화에 대해서 소개해보도록 하겠습니다. 문제점 검색 서비스 담당팀은 정기적으로 변화하는 처리 키워드와 비 처리 키워드를 업데이트하며, 이를 검색 팀에 처리 요청합니다. 처음에는 관련 위키를 참조하며 대응했으나, 몇 가지 문제점을 파악했습니다. 첫...
안녕하세요, 네이버페이 내자산&회원FE에서 프론트엔드 개발하는 이선아입니다.저희 팀이 담당하는 일은 원용님의 아래 글에 잘 정리되어 있습니다.내자산: 마이데이터 자산 조회 by wonyong01.kim이 글에서는 코드 관리의 관점에서, 모노레포에 대해 간략히 알아보고 기존에 있던 두 레포를 하나로 통합하는 과정과 진행하면서 생겼던 고민거리와 느낀 점을 공유하려 합니다.개편 이전의 코드 관리저희 팀에서는 내자산 서비스뿐만 아니라, 신용점수, 송금, 간편결제 등의 서비스도 담당하고 있는데, 각 서비스에서 다뤄야 할 기능이 많다 보니 서비스 별로 레포를 분리해서 코드를 관리하고 있습니다.그리고 공통으로 사용해야 하는 부분을 패키지로 뽑아 패키지용 레포를 따로 두고 있었습니다. 패키지에는 범용적으로 사용되는 코드를 모아둔 utils 패키지나 원용님께서 설명해 주신 Session IO를 사용하기 위한 패키지 등이 있습니다.저희 팀에서 관리하는 레포가 늘어나다 보니, 패키지만 따로 뽑아둔 레포는 개발 스택 업데이트에서 누락되는 등 관리가 안 되는 문제가 발생했습니다. 서비스 코드 작업이 더 급하다 보니 패키지 코드 개선은 후순위로 밀리는 경우가 많았습니다.또한 패키지는 카나리 배포를 해야 코드 동작을 확인할 수 있다보니, 작업을 위한 컨텍스트 스위칭에 피로도가 높아졌습니다.결정적으로 배포 프로세스가 변경되었는데 패키지 레포에서도 이를 새로 적용해야 했고, 이전의 불편사항을 개선하기 위해 패키지 레포와 서비스 레포를 합쳐 모노레포로 관리하기로 결정했습니다.모노레포란?잠깐 모노레포에 대해 설명하자면, 여러 프로젝트의 코드를 하나의 레포에서 저장, 관리하는 소프트웨어 개발 전략을 뜻합니다.기존에도 패키지들을 하나의 레포에서 관리하고 있었으니 해당 레포는 모노레포 전략을 취하고 있었다고 볼 수 있습니다. 이전에 패키지들만 모아서 관리하던 레포에서 패키지들을 옮겨와 하나의 레포에서 코드를 관리할 수 있도록 변경했습니다.Repo before & afterturbo repo란?모노레포를 구성하기 위해서 저희는 turbo repo를 사용했습니다.turbo repo는 자바스크립트 또는 타입스크립트로 된 프로젝트를 대상으로 하는 고성능의 빌드 시스템입니다.turborepo모노레포를 구성하는 많은 방법 중에서 선택할 때에 저희의 기준은 두 가지였는데요, 적용 및 사용하기 어렵지 않을 것과 빌드 속도가 크게 저하되지 않을 것이었고, 결론적으로 저희 팀은 만족하며 사용하고 있습니다.turbo repo 알아보기turbo repo 사용법을 간략하게만 설명하려 합니다. turbo에서는 `turbo.json` 파일에서 설정을 명시하여 사용합니다.{ "$schema": "https://turbo.build/schema.json", "pipeline": { "build": { "cache": false, "dependsOn": ["^build"] }, "deploy": { "cache": false, "dependsOn": ["^build"] }, "start": { "dependsOn": ["^build"] }, "lint": {} }}pipeline은 turbo로 실행할 스크립트의 이름을 키로 가지는 객체입니다. `turbo run`으로 실행할 수 있으며 각 package.json에서 일치하는 스크립트가 있으면 실행시켜줍니다. 예를 들어 `turbo run build`를 실행하면 레포 내의 모든 패키지와 서비스를 빌드 할 수 있습니다.pipeline 별로 설정을 다르게 할 수 있습니다. turbo에서는 빠른 실행을 위해 캐싱을 지원하고 있는데, 스크립트를 실행한 결과를 저장해두어 다시 실행했을 때에 캐시 되어있던 결과가 있다면 그대로 사용합니다. 프로젝트를 빌드 할 때에는 캐싱 된 결과를 사용하지 않도록 cache로 설정을 제어할 수 있습니다. 스크립트 간에 의존성이 있을 경우에는 dependsOn으로 설정합니다.패키지 이관하기패키지 레포에 있는 코드들을 이관하고 turbo로 실행할 수 있도록 스크립트를 정리해 주었습니다.그리고 패키지 매니저인 pnpm에서 제공하는 기능으로, 서비스 코드에서 배포된 버전이 아닌 같은 레포에 있는 코드를 바라볼 수 있도록 package.json을 수정해 주었습니다.{ // ... "dependencies": { "@mydata/packageA": "workspace:*", "@mydata/packageB": "workspace:*" }}배포 프로세스 정리하기코드 이관 후에는 github actions를 이용하여 패키지 버전관리와 배포 프로세스를 정리했습니다. 우선 패키지의 버전 관리와 changelog 작성을 쉽게 하도록 도와주는 Changesets를 도입했습니다.ChangesetsChangesets를 활용한 버전 관리 과정을 짧게 설명하면, PR 생성 시에 패키지에 변경사항이 있는지를 감지하여 코멘트를 달아줍니다.코멘트에서 major, minor, patch 중 어떤 버전을 bump할 것인지 선택하고 changelog를 작성하면 임시 파일을 추가해 줍니다. 해당 PR이 특정 브랜치인 develop에 머지 되면 이를 감지해서 임시파일의 내용으로 버전 업데이트와 changelog를 추가하여 새로운 PR를 생성해주며, 패키지 작업이 모두 완료되었을 때에 작업자가 머지합니다.여기에 나아가서 develop에서 패키지 버전에 변경이 있었을 때에 자동으로 publish를 실행하도록 했습니다. 배포가 정상적으로 완료되면 메신저로 알람을 보내 배포 결과를 공유합니다. 작성한 publish actions 코드를 발췌한 내용입니다.name: Release Publishon: push: branches: - developjobs: publish: runs-on: air-fe steps: - name: Checkout Repo uses: actions/checkout@v2 - name: install dependencies run: pnpm install --frozen-lockfile - name: Create Release Pull Request id: changesets uses: common-fe/changeset-actions@main with: title: "🚀 version changed packages" publish: pnpm run publish - name: Publishing success! if: steps.changesets.outputs.published == 'true' uses: actions/github-script@v6 with: script: # 배포 성공한 경우 사내 메신저인 works 발송마지막으로, 작업 중 카나리 배포를 쉽게 할 수 있도록 PR 코멘트에서 canary-publish를 인식하여 카나리 배포를 자동화했습니다.자동화 작업할 때에는 한주님이 작성해 주신 FinFE Bot을 많이 활용했습니다. 처음 소개해 주신 글보다 지금은 더 많은 기능을 고도화하여 제공하고 있지만, 읽어보시면 자동화에 대한 인사이트를 얻을 수 있습니다!반복적이고 귀찮은 일은 Bot에게! by 이한주불편한 점 개선하기배포 프로세스까지 정리하고 나니 “해야 하는 일”은 다 끝난 상태였고, 약간의 불편한 부분이 남은 상태였습니다.첫 번째로 CI/CD에 걸리는 시간이 길어진 것이었습니다. PR 생성 시에 작성한 코드에 이상이 없는지 확인하는 CI가 걸려있는데, 코드를 모두 빌드 하는 단계가 포함되어 있었습니다. 패키지에 비해 서비스 빌드 시간이 더 길었는데, 패키지 코드를 조금만 고쳐도 긴 서비스 빌드 시간을 기다려야 했습니다.이런 문제를 해결하기 위해서 빌드 스크립트를 분리하고 패키지 변경 시에는 서비스 코드에 대한 테스트를 건너뛸 수 있도록 github actions를 보완했습니다.두 번째로는 브랜치 관리가 이슈가 되었습니다. 패키지 코드 작업과 서비스 코드 작업에 의존 관계가 있어서 문제 되는 부분이 있었습니다.처음에는 패키지 수정 시에 패키지 쪽만 수정해서 PR을 작성하여 changelog에서 쉽게 확인할 수 있도록 하려 했는데, 서비스 코드에서 이를 참조하고 있어서 에러가 발생할 수 있습니다. 브랜치가 잘못 관리 되면 다른 브랜치로 에러가 전파될 수 있어서 브랜치 관리 전략을 새로 논의해야 했습니다.장단점 분석해보기모노레포로 전환하고 몇 달간 사용해 보면서 느낀 장단점을 분석해 봤습니다.장점은- 한 레포에서 관리하다 보니, 패키지 작업이 수월해졌습니다.- 개발 스택 업데이트할 때에 누락되는 경우가 적어졌습니다.- 코드 검색과 관리가 쉬워졌습니다.단점은- 브랜치 관리 방법이 더 복잡해졌습니다.- 팀원 모두 빌드 시스템에 대한 공부가 더 필요했습니다.전체적으로 봤을 때에 코드 작업 측면에서는 모노레포를 사용하는 것이 유리하지만, 환경 설정이나 브랜치 관리가 복잡하여 피로해진 부분도 있었습니다.마치면서작업 착수 전에는 코드 이동만 하면 되려나 했는데, 실제로 작업하면서는 빌드 시스템부터 github actions까지 다양하게 공부해 볼 수 있었습니다.제 경험기가 모노레포 전환을 고려하시는 분들께 조금이나마 도움이 되었으면 좋겠습니다.이번 모노레포 전환 작업을 진행하면서 시행착오도 많이 하고 고민도 많이 하면서 한 뼘 더 성장할 수 있었습니다. 작업 중 막힐 때마다 함께 고민해 주신 팀원분들 덕분에 무사히 마무리할 수 있었습니다.저희 네이버페이 내자산&회원FE에서는 팀원들의 지속적인 성장을 독려하고 있습니다. 저희와 함께하실 열정적인 분들을 언제나 기다리고 있습니다!채용: https://recruit.naverfincorp.com/코드, 어떻게 관리하세요? was originally published in NAVER Pay Dev Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
쏘카플랜 개편기 대부분의 개발자들은 논리적 사고와 정교한 설계를 통해 체계적으로 멋진 제품을 만드는 것을 목표로 합니다. 하지만 현실에서는 마감일에 쫓겨 우선순위를 정하고, 기능만 동작하도록 급히 코드를 작성해야 하는 상황에 처할 때가 많습니다. 다음과 같은 분들이 읽으면 좋습니다. 모든 프론트엔드 개발자 코드 품질과 마감일 사이에서 고민 중인 개발자...
생성형 기업이란 AI, 머신러닝, 딥러닝 등 생성형 기술을 활용하여 새로운 콘텐츠, 제품, 서비스를 창출하고, 비즈니스 모델을 혁신하는 기업을 의미합니다. 생성형 기술을 성공적으로 적용하기 위한 전략, 핵심 구성 요소, 그리고 생성형 기업으로 진화하기 위한 전략적 접근 방법을 제시합니다. 마지막으로, 생성형 기술의 미래 전망 및 도전 과제를 논의하며,...
안녕하세요. 왓챠 ML팀에서 머신러닝 엔지니어로 일하고 있는 찰스입니다.이전 글에서는 기존 왓챠 ML 파이프라인 및 실험 환경이 가진 문제점에 대해서 살펴보고, 문제를 해결하기 위해 컨테이너 환경의 도입, On-premise GPU 서버와 클라우드 서비스와의 연동, ML 파이프라인과 실험 환경을 제공하기 위해 여러 서비스를 활용한 사례에 대해 살펴보았...
생성형 AI는 소프트웨어 개발의 전통적인 방식을 혁신하며 새로운 도구와 개발 패러다임을 소개하고 있습니다. 이 기술은 코드 생성에서 검증, 통합, 배포에 이르기까지 소프트웨어 개발 생애주기(SDLC)의 모든 단계에 영향을 미치며, 개발자의 역할을 재정의하고 생산성을 비약적으로 향상시킬 전망입니다. 전문가들은 생성형 AI가 개발 팀의 효율성을 극대화하고...
안녕하세요, Tech Data AI검색 소속 데이터 분석가 최정현입니다. 지난해 말부터 커머스 유저 데이터를 분석 및 지표를 기획하고 대시보드로 자동화 하는 업무를 진행하였습니다. 이를 통해 추가적인 수익을 얻게 되었고 데이터를 통한 최적화 방향을 잡을 수 있었습니다. Databricks와 AWS 서비스를 활용한 데이터 파이프라인 설계 및 고도화 부분...