안녕하세요. LINE Plus Tech Content Strategy 팀 하성창입니다. 저희 팀은 테크니컬 라이터로 구성돼 있으며, LINE Plus에서 개발한 다양한 플랫폼의 기술 문서를 작성하는 한편 사내 용어집 사이트인 Words의 콘텐츠와 LY Corporation Tech Blog의 국문 콘텐츠를 담당하고 있습니다. 이 글에서는 LINE Planet이라는 VoIP 플랫폼의 문서에 싱글 소싱(single sourcing)을 적용해 문서 관리 효율성을 개선한 사례를 공유하려고 합니다.싱글 소싱은 하나의 소스에서 여러 가지 결과물을 생성하는 것을 뜻하는 용어입니다. 문서화에서는 아래와 같은 두 가지를 모두 의미합니다.• 단일 소스에서 여러 포맷(HTML, PDF, EPUB 등)으로 문서를 생성하기. 멀티 채널 퍼블리싱(multi-channel publishing)이라고도 합니다.• 단일 소스에서 맥락에 따라 여러 문서를 생성하기. 여기서 맥락은 문서화 요구사항에 따라 정의할 수 있습니다(배포 환경, 구동 플랫폼 등).예전에는 첫 번째 의미로 주로 사용했으나, 최근에는 두 번째 의미도 포함하여 더 넓게 사용하는 용어입니다. 이 글에서 '싱글 소싱'은 두 번째 의미에 해당합니다.싱글 소싱의 주요 목적은 문서 관리의 효율성과 문서의 품질을 개선하는 데 있습니다.• 문서 관리 효율성 측면에서는 '복사 및 붙여넣기' 작업을 최소화하여 유지 보수를 간소화할 수 있습니다. 콘텐츠를 재사용하여 불필요한 반복 작업을 줄이고 시간을 절약할 수 있습니다.• 문서 품질 측면에서는 단일 출처에서 정보를 가져옴으로써 각각의 문서가 따로 작성되었을 때에 비해 내용이나 스타일 면에서 일관성을 높이고 오류를 줄일 수 있습니다.다음과 같은 경우에 싱글 소싱을 적용할 수 있습니다.• 공통된 부분이 많지만 조금씩 차이가 있는 제품군의 문서를 관리해야 할 때• 소프트웨어 배포 환경에 따라 해당하는 내용의 문서를 만들고 싶을 때싱글 소싱의 주요 기법으로는 다음과 같은 것들이 있습니다.일정한 조건에 따라 콘텐츠 포함 여부를 결정하는 필터링 처리를 의미합니다. 다음과 같은 경우에 활용할 수 있습니다.• 특정 개발 환경에만 해당하는 내용이 있을 때• 멀티플랫폼 문서에서 플랫폼별로 조금씩 차이가 나는 부분이 있을 때예를 들어 'staging' 환경 문서에만 포함되어야 하는 내용을 조건부 콘텐츠로 관리하는 것을 의사코드로 나타내면 다음과 같습니다.값이나 용어를 변수화하는 것을 의미합니다. 다음과 같은 경우에 활용할 수 있습니다.• 특정 기능을 사용하는 데 필요한 최소 SDK 버전을 변수로 관리• 연락처, 고객 지원 채널 등의 URL을 변수로 관리예를 들어 SDK 최소 버전을 변수로 처리하는 것을 의사코드로 나타내면 다음과 같습니다.자주 쓰이는 콘텐츠를 재사용하는 것을 의미합니다. 다음과 같은 경우에 활용할 수 있습니다.• 여러 페이지에 동일하게 나타나야 하는 안내 문구를 재사용• 가이드나 튜토리얼에 반복되는 사전 절차(prerequisites)를 재사용예를 들어 오래된 문서에 대한

안녕하세요. LINE Plus ABC Studio에서 앱 개발을 하고 있는 김종식, 최정연, 박유진입니다. 저희 팀은 Flutter를 활용해 일본에서 운영하는 배달 서비스인 '데마에칸(Demaecan, 出前館)'의 다양한 제품 개발에 참여하고 있는데요. 작년에 YouTube 채널 라인개발실록에 올라간 일본 1위 배달앱, Flutter로 만듭니다 콘텐츠를 작업하면서 협업한 것을 계기로 Future 행사 준비 팀으로부터 컨퍼런스 초대 및 발표 요청을 받았습니다. 이 초청을 계기로 LINE Plus에서 이번 행사를 후원하기도 했는데요. 이 번 글에서는 Future 2024에 참석한 후기를 공유하려고 합니다.Flutter 2024는 Flutter Seoul & Incheon 커뮤니티에서 Flutter 개발자 여러분들을 위해 국내 최대 규모로 준비한 행사로, 2024년 9월 28일 인천 송도에서 10개 세션이 300명 이상의 참가자분들과 함께 진행됐습니다. FFI(foreign function interface)와 WebRTC(web real time clock), Code Push(over the air update, 사용자의 기기에 직접 배포하는 기술), UI 렌더링, 멀티 플랫폼 환경 개발 등 다양한 Flutter 이론과 실제 활용 사례를 오프라인에서 공유하고 공유 받을 수 있었던 귀한 행사였습니다.행사 시작 전 조금 일찍 도착해 행사장 주변과 세미나 실을 한 번 둘러봤는데요. 강연장 규모가 생각보다 커서 조금 부담이 느껴지기도 했습니다. 첫 세션이 시작되기 전에 대부분의 참가자들이 입장을 완료해 주실 만큼 참석률이 높았습니다.입장할 때 받았던 굿즈는 특히 맘에 들어 몇 개 더 받고 싶다는 생각도 들었습니다.매 세션마다 참가자분들의 발표 몰입도는 엄청났고, 발표 후 Q&A도 활발히 진행됐습니다. 최근 Flutter에 대한 관심이 커지고 있다고 느꼈는데요. 강연장에서 그 관심도를 생생하게 체감할 수 있었습니다. 특별히 기억에 남는 것은 발표자 대기실 공간인데요. 다과나 음료가 잘 준비돼 있었고, 행사장에서 진행되는 발표를 별도로 모니터링도 할 수 있도록 준비돼 있어서 준비를 많이 한 행사라고 느꼈습니다.저희 팀에서 준비한 발표 세션을 간략히 소개하겠습니다.저는 현재 머천트 앱 개발에 참여하면서 지속적으로 앱의 사용성을 개선해 나가고 있습니다. 이번 행사에서는 머천트 앱 리뉴얼 중 실제 담당했던 UI 커스터마이징과 스켈레톤 로딩, CustomScrollView 내부에 드롭다운 팝업 표시 등의 UI 요구 사항과 구현 과정을 소개했습니다. 각 요구 사항을 어떻게 해결해 나갔는지 그 과정을 상세히 소개하면서 이미 제공되는 패키지들과 비교하기도 했습니다.또한 내가 이해한 것을 정확하게 표현하기 위해 시각 자료를 그려서 첨부해 명확하게 의사소통을 하는 노하우와, 기획자 및 디자이너와 인식을 정확 히 맞추기 위해 노력하면서 동료에게 신뢰받는 개발자로 성장한 이야기도 공유했습니다.제 발표 전체 내용이 궁금하시다면 아래 링크를 참고하세요.저는 개인적으로 모바

Riverpod을 사용하여 간단하고 효과적인 캐싱 시스템 구축하기Flutter 개발자라면 데이터 관리는 앱의 성능과 사용자 경험에 직접적인 영향을 미친다는 것을 잘 알고 있을 것입니다.특히, 외부 API(OpenAPI)를 통해 데이터를 가져오는 경우 네트워크 지연이나 서버 상태에 따라 앱의 반응 속도가 달라질 수 있습니다.이러한 상황에서 백엔드에게 기본적인 캐싱 기능을 부탁할 수 없는 경우, 앱 내부에서 간단한 캐싱 시스템을 구현하여 성능을 향상시키는 것이 중요합니다.이번 글에서는 Riverpod을 사용하여 로컬 스토리지(Hive 등)를 사용하지 않고도 효과적인 캐싱 시스템을 구현하는 방법을 단계별로 알아보겠습니다.🍄 캐싱의 필요성a. API 호출의 문제점외부 API(OpenAPI)를 사용하여 데이터를 가져오는 경우, 다음과 같은 문제점이 발생할 수 있습니다.네트워크 지연 : 사용자의 네트워크 상태에 따라 API 호출 시간이 달라집니다.서버 응답 지연 : 백엔드 서버의 상태나 부하에 따라 응답 시간이 변동될 수 있습니다.비용 문제 : 빈번한 API 호출은 비용을 증가시킬 수 있습니다.데이터 일관성 : 실시간 데이터가 필요하지 않은 경우에도 불필요한 데이터 요청이 발생할 수 있습니다.b. 내부 캐싱의 장점이러한 문제점을 해결하기 위해 앱 내부에서 간단한 캐싱 시스템을 구현하는 것이 유용합니다. 내부 캐싱의 주요 장점은 다음과 같습니다.성능 향상 : 캐시된 데이터를 즉시 제공하여 앱의 반응 속도를 높입니다.네트워크 비용 절감 : 동일한 데이터에 대한 반복적인 API 호출을 줄여 네트워크 비용을 절감합니다.오프라인 지원 : 네트워크 연결이 불안정하거나 없는 상황에서도 캐시된 데이터를 제공할 수 있습니다.데이터 최신성 유지 : 캐싱 만료 시간을 설정하여 데이터의 최신성을 유지할 수 있습니다.c. 로컬 스토리지 없이 캐싱하기로컬 스토리지(Hive, SharedPreferences 등)를 사용하지 않고도 Riverpod만으로 캐싱 시스템을 구현할 수 있습니다. 이는 다음과 같은 장점을 제공합니다.간결성 : 추가적인 패키지 설치나 설정 없이 Riverpod만으로 캐싱을 관리할 수 있습니다.유연성 : 메모리 내에서 캐시를 관리하므로, 다양한 형태의 데이터를 손쉽게 캐싱할 수 있습니다.성능 : 메모리 기반 캐싱은 디스크 기반 캐싱보다 빠르게 데이터를 접근할 수 있습니다.🧙‍♂️캐시 매니저 구현효과적인 캐싱 시스템을 구축하기 위해서는 먼저 캐시 매니저(CacheManager) 를 구현해야 합니다. 이 매니저는 다양한 타입의 데이터를 키를 기반으로 저장하고, 캐시의 만료 시간을 관리합니다.a. CacheItem 클래스CacheItem 클래스는 캐시된 데이터를 나타내며, 데이터 자체와 함께 데이터를 저장한 시점을 기록합니다.// cache_item.dartclass CacheItem { final T data; final DateTime timestamp; CacheItem(this.data, this.timestamp);}b. CacheManager

안녕하세요. 일본 최대 규모의 음식 배달 서비스 Demaecan(出前館, 이하 데마에칸) 프로덕트를 담당하는 김영재라고 합니다. 어느덧 프로덕트를 쇄신한 지 2년 반이 되어가고 있습니다. 이번 글은 레거시를 해소하면서 서비스를 혁신해 나가는 데마에칸의 여정 중 기록을 남기는 의미로 작성했습니다.레거시의 정의는 다양합니다. 단순히 오래된 코드를 의미하는 경우도 있고, 새로운 서비스 구현에 제약이 되는 기존 구조를 말하기도 합니다. 하지만 사전에 실려 있는 '유산'이라는 긍정적인 의미처럼, 레거시는 지금까지 서 비스가 생존할 수 있게 해준 기반이기도 합니다.레거시에 관한 재미있는 표현도 많습니다.• 어제 내가 작성한 코드는 레거시이다.• 사용자가 한 명이라도 있는 시스템은 레거시이다. 그 한 명이 바로 당신이다.• 레거시를 고칠 바엔 다시 만드는 게 더 빠르다.위와 같은 표현이 셀 수 없이 많을 정도로 엔지니어는 레거시 때문에 웃고 울곤 합니다.데마에칸도 여느 회사처럼 레거시가 있습니다. 아니, 많습니다. 데마에칸은 업력이 20년이 넘은 회사입니다. 다시 말해 20여 년의 레거시가 쌓여 있습니다. 레거시는 코드나 시스템만 의미하지는 않습니다. 스펙이나 업무 프로세스에도 레거시가 있습니다. 예를 들어 점포의 속성 중에 '2-in-1'이라는 것이 있는데요. 이것을 정의하고 구현한 모습은 세 가지가 있었습니다. 회사 안에서도 '2-in-1 점포'라고 말할 때 부서마다 다르게 이해하고 있는 것이죠. 이 또한 레거시라고 말할 수 있습니다.현재 데마에칸은 앱부터 백엔드까지, 백엔드부터 운영 프로세스까지 하나씩 재작성하면서 레거시를 쇄신하는 장기 프로젝트를 진행하고 있습니다. 쇄신하는 방법은 여러 가지가 있는데요. 이번 글에서는 일반적인 방법 외에 조금 색다른 세 가지 방법을 말씀드리고자 합니다.레거시를 해소하는 대표적인 방법으로는 Strangler Fig 패턴이 있습니다. 아래 그림과 같이 새로운 시스템을 마련한 후 조건에 따라 옛 시스템에서 새로운 시스템으로 이행하다가 새로운 시스템이 잘 작동한다는 확신이 들면 옛 시스템으로 가는 경로를 없애고 폐쇄하는 방법입니다. 직접 본 적은 없지만 Strangler Fig라는 나무가 이와 같은 방식으로 생장한다고 합니다.데마에칸에서도 이 방법으로 백엔드의 여러 컴포넌트를 활발히 개선하고 있습니다. 가장 안전하면서도 결과와 일정을 예측하기 쉬운 방법이기에 운영 중인 서비스라면 어디든 적용할 수 있습니다. 데마에칸에서는 결제, 주문, 회원 정보 등 이커머스로서 가장 핵심적인 도메인에 이 방법을 사용하고 있습니다.이 방법의 단점으로는 차근히 개선해 나가는 방식이므로 꽤 오랜 시간이 걸린다는 점과, 안정성을 중시하는 만큼 레거시의 가장 핵심적인 부분은 교체하지 못하는 경우가 많다는 점을 꼽을 수 있습니다. 그래서 보다 극단적인 방법들도 쓰이는데요. 어떤 방법이 있는지 하나씩 사례와 함께 소개하겠습니다.보다 과격하게 레거시를 해소하는 세 가지 방법어떤 방법을 사용하든 레거시를 해소하는 것은 어느 지점에서 레거시를 단절하