기술 블로그 모음

최고의 자동완성 플러그인 타입스크립트를 사용하여 개발자를 속이고 코드를 최적화한 경험을 공유합니다.

지난 몇 년간 디지털 혁신이 많은 주목을 받았지만, 실제로는 실질적인 변화를 가져오지 못했습니다. 이에 많은 CEO들이 AI에 대해 양가감정을 느끼고 있습니다. 이 글은 기업들이 AI를 어떤 관점에서 견지해야 하는지 깊은 통찰을 제공합니다.

 ## 들어가며 ### 무더운 여름날, 전기가 갑자기 끊긴 경험이 있으신...

모바일 헬스케어는 스마트폰, 웨어러블 기기, 사물인터넷 등 디지털 기술의 발전과 함께 급격히 성장했으며, 최근에는 인공지능, 빅데이터, 클라우드 컴퓨팅 등을 활용하여 개인 맞춤형 건강 관리가 가능해졌습니다. 이 아티클에서는 모바일 헬스케어에 관한 동향과 전망에 대해 살펴 보겠습니다.

들어가며 안녕하세요. Auth & Account Dev 팀의 김은찬, 김종민, 권기범, 정의엽, 허원영입니다. Auth & Account Dev 팀은 LY Corporation 그...

목차 시작하며 규모가 커지면서 생기는 문제점들 2.1 계속해서 생겨나는 중복 코드들 2.2 멀티레포 환경에서의 공통 라이브러리 업데이트 일관성을 위한 모노레포 도입과 고민 프로젝트 세팅 비용 단축하기 4.1 기존 멀티레포 환경에서의 프로젝트 세팅 4.2 모노레포 환경 구성 세팅하기 4.3 Code Generator를 활용한 프로젝트 세팅 4.4 결론 ...

데브시스터즈의 데이터독 사용 노하우를 공유하였던 행사를 소개합니다.

안녕하세요. Cloud DBS 팀에서 사내 클라우드인 Verda의 데이터베이스와 OpenSearch 서비스 개발을 맡고 있는 강인배, 문현균입니다. 이번 글에서는 저희 팀에서 쿠버...

WATCHA에서 서로 다른 클라우드 저장소 간의 데이터 마이그레이션 시스템을 구축한 경험을 소개합니다. #Kubernetes #ArgoWorkflows안녕하세요, WATCHA Server Platform 팀에서 플랫폼 엔지니어로 일하고 있는 루카입니다.WATCHA에서 모은 데이터를 효율적으로 분석하고 활용하기 위해 기존 데이터 마이그레이션 프로세스를 ...

AI는 스마트폰의 인터페이스를 새롭게 정의하며, 온디바이스 AI를 활용한 혁신적인 인터페이스를 만들어내고 있어, 앞으로의 스마트폰은 더욱 강력해진 성능과 편리한 인터페이스를 통해 우리의 삶을 더욱 편리하게 만들어줄 것으로 전망합니다.

들어가며 안녕하세요. LINE Plus에서 Global E-Commerce Platform 개발을 맡고 있는 장효택입니다. LINE Brand Catalog와 통합 커머스 검색 ...

…

“이걸 진짜 만든다고요? 🤯 ” 샐러드게임 탄생 배경 202…

안녕하세요, 뉴넥스 AI 검색팀의 신누리입니다. 현재 팀 내 유일한 검색 담당으로서, 뉴넥스의 패션 커머스 플랫폼들 -브랜디, 하이버, 서울스토어, 셀피- 전체 검색 프로덕트를 책임지고 있습니다. 구체적으로는 검색 데이터 파이프라인 구축 및 유지보수, 검색엔진 관리, 검색 API 개발, 검색 사전 관리 등 검색과 관련된 모든 부분을 매니징하고 있습니다...

안녕하세요. 저는 당근 LocalMaps UGC 팀에서 서버 개발을 하고 있는 조앤(Joanne)이라고 해요. 저희 팀은 얼마 전까지 지역사업실 UGC(User Generated Contents) TF로서 MVP 스펙 개발에 몰입해 있었는데요. 이 글에서는 저희가 TF일 당시 어떻게 빠르고 효과적으로 기능을 구현할 수 있었는지 그 방법을 소개해보려고 해요. 단기간에 새로운 기능을 도입하기 위해 어떤 협업 방식을 갖춰야 할지 궁금하신 분들에게 도움이 되었으면 해요.UGC TF의 배경과 목표먼저 UGC(User Generated Contents)는 후기와 같이 사용자가 자발적으로 생산하는 콘텐츠를 의미해요. 저희는 사용자들이 더 많은 UGC를 생산하도록 동기부여하는 데에 집중하기 위해 UGC TF를 결성했어요. 즉, 사용자에게 UGC를 생산해야 하는 이유를 만들어 줌으로써 UGC 생산을 효과적으로 늘리려고 했죠.개발자의 경우 클라이언트 2명, 서버 4명으로 구성된 저희 TF는 최근 MVP 개발을 완료했어요. 최소 비용으로 사용자 반응을 빠르게 확인하여 가설을 검증하려 했기에 일정을 타이트하게 가져갔죠. 저희 팀은 약 한 달간의 일정 내로 여러 기능을 구현해야 했는데요. 그 중 대표적인 것은 피드백 루프였어요.다시 말해, 생산해 낸 콘텐츠에 피드백을 제공함으로써 사용자에게 자기 효능감을 주는 것을 중심으로 MVP 스펙을 구성했죠. 대표적인 요구사항으로는 내가 참여한 장소와 기여 내역을 확인할 수 있는 프로필 페이지, 내가 생성한 콘텐츠의 조회수가 일정 수준 도달 시 이를 전달해 주는 성과 알림 등이 있어요.단기간에 여러 기능을 구현해야 하는 요구사항이 주어졌을 때, 어떻게 일하는 것이 가장 좋은 방법이라고 생각하시나요? 혼자서 하나를 담당해 빠르게 구현하는 것이 가장 좋은 방법일까요?혼자 하면 빨리 가고, 함께 하면 멀리 간다.잘 알려져 있는 유명한 문구죠. 저도 이 문구를 오랫동안 믿어 왔어요. 하지만 이번 UGC TF에서 협업하는 과정에서 이 문장이 틀렸다는 걸 깨달았죠. 함께 하는 것은 멀리 갈 뿐만 아니라 사실 결국 더 빨리 갈 수 있는 방법이었어요. 멀리 가면서도 빠르게 갈 수 있었던, 저희 TF의 협업 방식을 본격적으로 이야기해 볼게요.1. Tech Spec을 작성하고 함께 리뷰해요.기능 구현을 위해 바로 코드부터 짜시나요? 그 이전에 테크 스펙을 작성하고 팀원들과 공유하는 과정이 필요해요. 테크 스펙은 기술적인 세부 사항을 기록한 문서예요. 테크 스펙은 요약 및 배경, 목표와 목표가 아닌 것, 계획, 임팩트 측정, 고려사항 및 마일스톤, 질의응답 등의 주요 요소로 구성돼 있어요.이해를 돕고자 UGC TF의 요구사항 중 하나인 성과 알림을 예시로 들어볼게요. UGC TF는 유저에게 긍정적인 피드백 루프를 제공하기 위해 성과 알림을 발송하기로 했어요. 아래는 성과 알림 구현을 위한 요구사항 중 일부예요.특정 유저가 작성한 후기의 조회수가 N회에 도달하면 알림을 발송해요.같은 횟수로 이미 발송된 적이 있다면 중복으로 발송하지 않아요.유효한 후기가 아닐 경우 발송하지 않아요.이를 바탕으로 Tech Spec의 핵심이 되는 부분인 목표와 계획 파트를 작성한다면, 다음과 같이 작성할 수 있어요.목표와 목표가 아닌 것목표:사용자가 작성한 후기의 조회수가 특정 기준(N회)에 도달했을 때 성과 알림을 발송해요.중복 알림 발송을 방지하여 사용자 경험을 해치지 않도록 해요.유효한 후기에 대해서만 알림을 발송하여 알림의 품질을 유지해요.목표가 아닌 것:모든 종류의 사용자 활동에 대한 알림을 구현하는 것은 이번 프로젝트의 목표가 아니에요.사용자가 알림 기준(N회)을 직접 설정하는 기능은 이번 단계에서 구현하지 않아요.계획후기 조회수 집계 시스템 구축:기존 후기 조회 로직에 카운터 증가 기능을 추가해요.분산 환경에서의 동시성 문제를 고려하여 원자적 연산을 사용해요.알림 발송 조건 확인 로직 구현:조회수가 N회에 도달했는지 확인하는 로직을 구현해요.중복 발송 방지를 위해 이전 알림 발송 이력을 확인해요.후기의 유효성을 검증하는 로직을 추가해요.알림 발송 시스템 구축:자체 알림 발송 시스템을 활용해 알림을 발송해요.알림 템플릿을 제작하고, 동적으로 내용을 변경할 수 있도록 구현해요.테스트 및 모니터링 시스템 구축:단위 테스트와 통합 테스트를 작성하여 시스템의 안정성을 확보해요.알림 발송 현황을 모니터링할 수 있는 대시보드를 구축해요.Trade-Off:FCM vs 자체 알림 시스템: 주어진 기간 내에 FCM을 구현하기에는 러닝커브가 높기 때문에, 모니터링 및 구현이 간단한 자체 알림 시스템을 선택해요.배치 처리 vs 실시간 처리: 사용자 경험을 위해 실시간 처리 방식도 고려했지만, 시스템 부하를 줄이기 위해 조회수 집계와 알림 발송을 배치 처리하는 방안을 선택해요목표와 계획은 프로젝트의 방향을 명확히 하고, 구체적인 실행 단계를 제시해 줘요. 또한 Trade-Off 부분에서는 의사 결정 과정과 그 이유를 명시하여 팀원들과의 논의 기반을 마련했어요. 이 과정에서 MVP 대비 오버 엔지니어링이 되는 경우는 없는지, 주어진 상황에서 더 적은 리소스를 쓸 수 있는 방법은 없을지 고민할 수 있어요.테크 스펙을 혼자서만 작성하고 끝나는 것이 아니라 서버 엔지니어가 모두 모여 리뷰하는 시간을 가져요. 리뷰 시간에는 주로 선택지에 대한 트레이드 오프나 발생 가능한 문제 위주로 피드백하죠. 또한 작성자가 생각하는 것과는 다른 개선책이 떠오른다면 함께 제안하고 의견을 적극적으로 나눠요.테크 스펙을 작성하고 함께 리뷰하는 과정에서 경험한 장점들을 아래와 같이 정리할 수 있어요.문서를 작성하며 전체적인 설계를 정리하고 다듬을 수 있어 오히려 구현하는 데에 시간이 덜 들었어요. 직관적이고 빠르게 개발할 수 있어요.고민되는 부분에 대해 나의 생각뿐만 아니라 동료의 의견을 들을 수 있어요. 이러한 리뷰를 통해 더 나은 방향으로 갈 수 있도록 유연함을 가져요.문서를 Source Of Truth로 바라보고 개발 직군이 아닌 직군과도 일관되게 소통할 수 있어요. 문서는 주기적으로 업데이트하고 문서의 업데이트를 통해 다시 한번 전체적인 구현에 대해 점검할 수 있어요.예상치 못한 문제들을 미리 방지하고, 함께하는 구성원들과 프로젝트의 상태 및 방향성에 대해 얼라인할 수 있어요.2️. 맥락을 긴밀히 공유해요.앞서 예시로 든 성과알림 외에도 프로필 페이지, 내가 참여한 내역 등 여러 가지 요구사항이 동시에 존재했어요. 담당하는 요구사항에만 집중하다 보면 큰 맥락을 놓치기 쉽고, 전체적인 유저 경험을 고려하기 어려울 수 있어요. 저희 TF는 이런 한계를 보완하고자 페어를 구성했어요. 페어는 맥락 공유를 위해 더욱 긴밀하게 협업하는 관계예요.저(Joanne)는 제니(Jenny)와 페어였는데요, 페어로서 더 잘 일할 수 있는 방법을 함께 많이 고민했어요. 저희는 맥락 공유가 가장 중요하다고 결론 내렸는데요. 이를 위해 가장 처음 한 것은 둘을 한꺼번에 멘션할 수 있도록 Slack에서 JJ라는 유닛을 결성했어요. 멘션 시에도 함께 멘션되도록 해서 사소한 맥락도 공유할 수 있도록 했죠.맥락 공유가 가져다주는 긍정적인 효과로는 다음과 같은 것들을 경험할 수 있었어요.PR 리뷰 과정에서 둘 다 전체 맥락을 이해하고 있어 효과적인 피드백을 주고받을 수 있었고 리뷰에 소요되는 시간이 줄었어요.특정 작업자에 대한 의존도가 줄어들어 프로젝트의 유연성이 향상됐어요.상황에 따라 유동적으로 업무를 나누고 조정할 수 있었어요. 이는 작업 효율성을 높이고 예상치 못한 상황에도 신속히 대응할 수 있었어요.결과적으로 페어를 통한 맥락 공유는 단순히 정보를 나누는 것을 넘어 팀의 생산성과 코드 품질, 그리고 프로젝트의 전반적인 건강성을 향상시키는 핵심 요소로 작용했어요.3. 함께 고민하여 변경에 유연하게 대응해요.프로젝트를 진행하면서 변경에 유연하게 대응하고 팀원들과 함께 고민하는 문화를 만들어갔어요. 이를 위해 여러 가지 방법과 도구를 활용했어요.Schema-First 접근 방식을 활용해요.OpenAPI Spec을 사용함으로써 클라이언트와 서버 개발팀이 API 인터페이스에 대해 함께 논의하고 하나의 소스를 바라보며 병렬 작업을 할 수 있었어요. API 응답에 변경이 필요할 때도 서버에서 일방적으로 수정하는 것이 아니라, OpenAPI Spec을 수정하여 더욱 유연하게 대응할 수 있었어요.OpenAPI의 사용과 관련해서 더 자세한 내용이 궁금하다면, 커뮤니티실의 하이디가 작성해 주신 아래 글을 참고해 보시면 좋을 것 같아요.🔗 커뮤니티실 API Design-First 접근방식 정착기테크 스펙을 기반으로 요구사항 변경에 유연하게 대응해요.요구사항이 변경될 때는 앞서 작성한 테크 스펙을 기반으로 기존에 설계했던 것과 수정되어야 할 것을 명확히 비교할 수 있어요. 수정된 부분을 엔지니어들과 함께 재검토하면서 직관적이고 유연한 수정이 가능해졌죠.위에서 이야기했던 성과 알림을 계속 예시로 들어볼게요. 중복 발송 로직이 고도화되기로 수정되었다고 가정해 봅시다. 기존에 작성한 테크 스펙을 기반으로 ASIS와 TOBE를 작성하여 변경된 부분을 명확히 하거나 변경된 부분에 대해서만 리뷰를 받는 등 유연한 변경이 가능해져요.회고와 개선프로젝트가 끝날 때엔 회고 시간을 가져 개발 과정에서 놓쳤던 부분들을 다시 짚어보고, 더 나은 방향으로 나아갈 수 있도록 수정하는 cool-down 시간을 가졌어요. 이를 통해 지속적인 개선과 성장이 가능했죠.회고 시 주의해야 할 점이 하나 있어요. 그건 바로 프로젝트를 모두 마친 후 회고를 진행하면 작업 중에 고민했던 부분을 놓치기 쉽다는 점이에요. 저희 TF에서는 그런 상황을 방지하기 위해 미리 회고 티켓을 따로 만들어뒀어요. 추후에 함께 고민해 볼 만한 것들을 미리 등록해두고, 회고 때 함께 논의했죠.회고 티켓은 다음과 같은 내용을 담을 수 있어요. ‘패키지 구조를 어떻게 나누어야 할 것인가’에 대한 고민을 예로 들어 볼게요. A라는 Service를 a라는 패키지를 만든 뒤 그 하위에 위치시킬지, 혹은 service라는 상위 패키지 하위에 모두 몰아넣을지 고민해 봤다고 가정해봐요. 그럼 그 당시 고민했던 여러 대안들과 최종적인 선택을 내린 이유 등을 티켓에 함께 작성해두는 거죠.이러한 방식으로 팀원들과 함께 변화에 대응하고 고민하며, 프로젝트의 품질을 높이고 팀워크를 강화할 수 있었어요.우리는 왜 협업할까?혼자 하면 빨리 가고, 함께 하면 멀리 간다.이 문구를 다시 한번 생각해 봐요.만약 모든 일을 혼자 했다면, 모든 맥락을 혼자만 알고 있었을 거예요. 이는 특정 사람에 대한 의존도를 높이고 문제를 빠르게 개선하기 어려운 상황을 만들어요. 저희는 먼저 문서를 작성하고, 이에 대해 피드백을 받고, 함께 고민하고, 유연하게 대응할 수 있는 방법들을 사용했어요. 이는 복잡도가 높은 상황에서 더욱 안정적이고 빠르게 갈 수 있도록 큰 도움을 주었어요.우리가 협업하는 이유는 단순히 일을 나눠서 하기 위함이 아니에요. 지속 가능한 방식으로 팀을 전진시키기 위해 협업하죠. 혼자 일할 때의 장점도 분명히 있지만, 협업을 통해 우리는 서로의 지식과 경험을 공유하고 다양한 관점에서 문제를 바라볼 수 있어요. 이는 개인의 성장뿐만 아니라 팀 전체의 성장으로도 이어지죠. 팀이 더 큰 도전을 성취해 내고 더 큰 목표를 향해 나아갈 수 있도록 해요.여러분은 어떻게 협업하시나요? 더 멋진 방법이 있다면 함께 공유해 주세요.이만 글 줄일게요. 읽어주셔서 감사해요.#programming #workingMVP를 빠르고 효과적으로 개발하기: 우리는 협업해요 was originally published in 당근 테크 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

이 글은 AI가 기존 창작물을 무단으로 복제하는 문제를 다루며, AI 표절의 정의와 탐지 기술, 그리고 이를 방지하기 위한 솔루션들을 소개합니다.

‘무신사테크’ 유튜브 채널은 무신사/29CM 서비스를 만드는 이야기를 영상으로 전하고있습니다. 영상을 통해 더 생생하고 재밌게 기술의 이야기를 들을 수 있어요.https://medium.com/media/a387f62a5c11e9fa0bc26c8a65480218/href영상 소개29CM 서비스를 이용하시는 고객들이 만들어 내는 실시간 데이터 양이 시간...

생성형 AI의 등장으로 인해 전통적인 코딩 방식이 점점 구식이 되어 가고 있으며, 이제 로우코드와 같은 도구를 사용하여 효율성과 생산성이 크게 향상된 '코딩하지 않는' 개발자의 세상이 열리고 있습니다.

이 글에서는 AI 시대의 변화와 함께 LangChain이 어떻게 언어 모델의 한계를 극복하고 실질적인 애플리케이션 개발을 가능하게 하는지 살펴보겠습니다.

안녕하세요. 쿠버네티스에서 파드를 분산 처리할 때 사용할 수 있는 토폴로지 분배 제약 조건(topology spread constraints) 활용 사례를 공유할 ContentsS...

삼성SDS의 R&D Cloud for AI는 GPU 클러스터링으로 AI 연구를 가속화합니다. AI 연구자들이 복잡한 연산 작업을 빠르고 효율적으로 처리할 수 있도록, 최적화된 환경과 리소스 관리 기능을 제공합니다.

이 아티클에서는 소프트웨어 개발 생산성 향상을 위해 AI 코딩 도구를 도입할 때 고려해야 사항들이 무엇인지 살펴봅니다.

‘무신사테크’ 유튜브 채널은 무신사/29CM 서비스를 만드는 이야기를 영상으로 전하고있습니다. 영상을 통해 더 생생하고 재밌게 기술의 이야기를 들을 수 있어요.https://medium.com/media/86a03ebb2caf37766b5534f385892a5b/href영상 소개검색 개발자로 합류 후 방향성을 잡고 업무 효율성을 위해 검색 시스템의 핵...

올리브영은 뷰티 상품을 중심으로 각기 다른 특징을 가진 상품을 고객에게 전달하고 있습니다. 최근엔 W CARE…

AI SaaS 도입으로 검색 경험을 개선한 사례 소개

안녕하세요. 올리브영 플랫폼엔지니어링팀 리더 무스타파🌙입니다. DASH 2024 Datadog에서는 매년 새롭게 런칭되는 서비스와 다양한 성공 사례와 경험을 공유하기 위해서 뉴욕에서 DASH라는 컨퍼런스를 개최합니다. 이번 DASH 202…

이 글에서는 대규모 언어 모델(LLM) 대신 소규모 언어 모델(SLM)을 선택하는 이유, IT 리더들의 지속 가능성 고려, 에너지 효율성, 데이터 통제 문제 등을 분석합니다.

프로덕션 환경에서 ZIO 애플리케이션을 최대한 빠르게 만드는 방법.

안녕하세요! 올리브영에서 라이브관과 매거진관을 담당하고 있는 몌으니입니다🦦💙 올리브영의 백오피스(BackOffice)시스템(이하 BO)에 Storybook…

이 아티클에서는 클라우드 전환 단계별로 적절한 보안 전략을 수립하고, 보다 안전하고 효율적인 클라우드 환경을 구축할 수 있도록 가이드를 제공합니다.