napster.x 대한민국에서 공짜 지도 SDK 쓰는 방법sean.me MapKit에 대한 레퍼런스가 많이 없어 사용을 주저한 적이 있었는데요, 글을 읽어보니 간단한 사용에는 전혀 문제없고 오히려 더 편하게 사용할 수 있겠다는 생각이 들었어요.안녕하세요, 카카오페이 앱의 얼굴! 홈탭과 결제탭 개발을 담당하는 클라이언트서비스팀 iOS 개발자 스위리입니다. 2024년에 지도로 시각화된 사용자 위치 기반 서비스 두 개를 릴리즈했습니다. 상반기에는 실시간 위치 정보를 활용하는 미션형 혜택 서비스인 ‘포춘레이더’를, 하반기에는 카카오페이로 결제 시 혜택을 제공하는 주변 매장을 보여주는 ‘내 주변 혜택’ 카드 작업을 진행했습니다.도메인 관점에서 각각 혜택 그리고 결제로 두 서비스의 소속은 다릅니다. 그러나 개발 관점에서 두 서비스 모두 MapKit 프레임워크를 활용한 점은 공통점입니다. MapKit 프레임워크는 카카오페이에서 처음 도입해 보는 프레임워크이기도 하고, 특히 참고할만한 국내 서비스가 적어 개발 과정이 매끄럽지 않았습니다. 따라서 오늘 이 글에서는 MapKit 프레임워크를 사용하면서 겪은 시행착오를 공유함으로써 유사한 문제로 개발에 난항을 겪고 계신 분들에게 도움이 되고 싶습니다.iOS 네이티브 앱 개발 시 지도를 사용하고 싶다면 다양한 선택지가 있습니다. 기획에 적합해 보이는 SDK를 검토한 결과, 최종적으로 네이버 지도 SDK, 카카오 지도 SDK, MapBox, OSM, MapKit 다섯 가지 선택지가 남았습니다. 이들의 장단점을 살펴본 후 개발 환경과 조건에 가장 적합한 MapKit을 선택했습니다. 특히 비용과 한글 지원 두 가지 측면에서 검토를 진행했습니다.• 비용 지도 SDK의 경우 기업에서 제공하는 것과 오픈소스로 나눠 볼 수 있습니다. 특히 사기업에서 제공하는 SDK는 API 호출 제한 조건이 존재합니다. 특정 조건 달성 시 호출이 막히거나 초과 사용에 대한 비용을 지불해야 합니다. 네이버 지도의 경우 월 600만 건의 API 호출을 무료로 사용할 수 있고, 카카오 지도는 그보다 조금 더 많은 수준인 일 30만 건의 호출을 지원합니다. MapBox는 해외에서 잘 알려진 SDK로(BMW 내장 내비게이션, CNN의 지리 자료 제작 등에 사용) 앞선 두 회사와 달리 일 방문자 수 25,000명까지 호출을 무료로 지원합니다. 당시 기획에서 산정한 예상 방문자 수와 현재 DAU(Daily Active Users)를 종합적으로 고려해 봤을 때 과금 발생 가능성이 높았습니다. SDK에 사용할 수 있는 비용이 제한적이었기 때문에 네이버 지도, 카카오 지도 그리고 MapBox 모두 선택지에서 배제했습니다. 이제 OSM과 MapKit, 2개의 선택지가 남았습니다.• 한글 지원 카카오페이를 사용하는 대부분의 사용자는 한국인이기 때문에 한글 지원이 중요합니다. 언어를 지원하는 것뿐만 아니라 한글로 서비스를 제공했을 때 이질감이 없어야 합니다. 이 측면에서만 보면 네이버와 카카오 지도만 한 것도 없습니다. 남은 두 개의 선택지 중 OSM은 한글을

오랜만에 새로운 포스팅을 시작합니다. 2025년 새해 복 많이 받으세요!이번 글에서는 파인튜닝 최적화를 주제로, 학습에 관련된 파라메터 설정과 최적화 요소에 대한 내용을 다루려고 합니다.사실 학습 파라미터 설정에 관한 문서는 많지만, 설정값에 따라 어떤 결과가 나오는지 구체적으로 다룬 사례는 드문 편입니다.그래서 현업에서는 여러 번의 실험과 시행 착오를 거쳐 최적의 값을 찾아내는 경우가 많죠.LLM 파인튜닝처럼 비용이 많이 드는 작업에서는 이러한 시행착오의 비용이 큰 부담으로 작용할 수 밖에 없습니다.이번 포스팅에서는 다양한 설정이 결과에 미치는 영향을 직접 실험을 통해 살펴보며, 이를 통해 파인튜닝 최적화에 대한 이해를 좀 더 해보고자 합니다.내용이 많아서 두 편으로 나눠 정리했습니다. 첫번째 글에서는 다음과 같은 주제를 다루고 있습니다.• None Epoch, Batch, Step의 차이와 이해• None 이번 포스팅에서 사용된 코드는 아래 GitHub 링크에서 다운로드할 수 있습니다.• None 모델 학습에는 HuggingFace Transformers 라이브러리를 활용했으며, 관련 Training Arguments에 대한 내용을 본문의 각 세션에 표기 했습니다.• None 실험 환경은 별도 언급이 없는 경우, 다음과 같은 환경에서 진행되었습니다.Batch, Step 그리고 Epoch은 LLM 학습 과정에서 데이터 처리를 정의 하는 단위로, 학습 효율성과 성능에 직접적인 영향을 미칩니다.또한 학습 과정을 효과적으로 모니터링하려면 어떤 지표를 중심으로 관찰 할지 명확히 이해 하는 것도 중요합니다.이 섹션에서는 이러한 기본 개념들을 다시 한번 정리해보겠습니다.Batch 크기는 한 번의 학습 단계(Training Step)에서 사용하는 데이터 샘플의 개수를 의미합니다.그림1에서 데이터셋에서 학습에 사용하기 위해 선택된 데이터 묶음이 Batch를 나타냅니다.예를 들어, Batch 크기가 10이라면, 한 번의 Training Step에서 모델은 데이터셋의 10개 샘플을 사용해 모델의 파라미터를 업데이트합니다.Batch 크기는 학습의 속도와 메모리 사용량에 큰 영향을 미칩니다. 특히 크기에 따라 학습 과정의 특성이 달라지는데요,Batch 크기가 학습 성능에 미치는 구체적인 영향은 다음 섹션에서 자세히 알아보겠습니다.흔히 Step이라고 줄여서 부르는 Training Step은 모델의 파라미터가 한 번 업데이트되는 과정을 말합니다.그림1에서 보면 Batch 만큼의 학습 데이터셋을 GPU에 로드해서 학습을 하고 모델의 파라미터를 업데이트하는 과정입니다.• None 예를 들어, 데이터셋의 크기가 10,000개이고 Batch 크기가 10이라면따라서, 데이터셋 전체를 한 번 학습하기 위해 1,000번의 Training Step이 필요합니다.Epoch은 학습 데이터셋의 모든 샘플을 한 번씩 모델에 보여주는 과정을 의미합니다.쉽게 말해, 데이터셋 전체를 한 번 학습한 상태를 1 Epoch 이라 합니다.LLM 학습에서는 일반적으로 Training Step을

안녕하세요, 응용기술검증팀 이은지입니다.우리 회사에서 진행되는 여러 프로젝트는 날이 갈수록 규모가 커지고 복잡해지고 있습니다. 각 검증 담당자는 동시에 여러 프로젝트를 맡고 있으며, 각 프로젝트의 다양한 마일스톤을 빠르게 소화하고 관리하는 것이 필수적입니다. 하지만, 테스트 케이스는 지속해서 증가하고 있고, 시간은 제한되어 있어 이를 체계적으로 관리하는 것이 점점 더 어려워졌습니다.특히, 기존의 엑셀 기반 관리 방식으로는 복잡한 프로젝트의 전체적인 흐름을 한눈에 파악하는 데 한계가 있었습니다. 테스트 케이스 간의 상호작용을 시각적으로 파악하기 어렵고, 변경 사항이 발생할 때마다 일일이 수정하는 과정에서 누락이나 중복이 발생할 위험이 있었습니다.이러한 배경에서 검증 업무의 효율성을 높일 수 있는 도구를 찾게 되었고, 그 결과 Xmind라는 마인드맵 도구를 활용하게 되었습니다.어렸을 때 한 번쯤 중요한 개념을 연결하거나 아이디어를 정리하기 위해 종이 위에 마인드맵을 그려본 기억이 있을 겁니다. 학교에서 공부할 때 중요한 개념을 연결하거나, 꿈꿨던 아이디어를 정리하기 위해 종이 위에 그림을 그리며 생각을 정리했던 기억이 떠오릅니다.이러한 시각적 사고 방식은 개념을 직관적으로 연결하고, 서로의 관계를 쉽게 이해하는 데 큰 도움이 됩니다.이 마인드맵의 개념을 현대 기술로 발전시킨 도구가 바로 Xmind로, Xmind는 복잡한 정보를 구조화하고 관리하는 데 최적화되어, 아이디어를 손쉽게 시각화하고 공유할 수 있습니다.프로젝트가 처음 시작되면 다양한 정보가 곳곳에 퍼져 있습니다.요구사항 문서, 피그마와 같은 디자인 시안, 그리고 스펙 문서 등이 각각 다른 위치에 분산되어 있어, 이를 확인하고 정리하는 데에 많은 시간이 소요되었고, 중요한 세부 사항을 놓치는 경우도 있었습니다.또한, 전체적인 그림을 그리기 어려워 테스트 계획을 체계적으로 세우는 데 한계가 있었습니다.엑셀로 작성된 테스트 케이스는 표 형식으로 나열되다 보니, 각 테스트 항목 간의 상호작용이나 흐름을 시각적으로 파악하는 것이 어려웠습니다.복잡한 시나리오에서는 테스트 항목들이 어떻게 연결되는지 명확하게 이해하기 힘들었고, 그 결과 빠지거나 중복되는 사례가 발생할 위험이 있었습니다.게다가, 여러 파일이나 시트에 나뉜 테스트 항목은 프로젝트 전체의 흐름을 한눈에 파악하기 어렵게 만들었고, 팀원들이 같은 문서에 접근하더라도 해석 방식이 각기 달라 혼선이 발생할 수 있었습니다.엑셀을 통한 전통적인 테스트 케이스 관리는 여전히 유효하지만, 프로젝트가 복잡해질수록 전체 흐름을 시각적으로 한눈에 파악하는 데는 한계가 있을 수 있습니다.Xmind를 이용해, 테스트 항목들을 크게 분류하고 트리 구조로 시각화함으로써 테스트 케이스 간의 상호작용과 전체 흐름을 한눈에 볼 수 있었습니다.이를 통해 복잡한 테스트 시나리오에서도 각 항목 간의 연결 관계를 명확하게 이해할 수 있어, 빠지는 항목 없이 효율적인 테스트 계획 수립이 가능했습니다.테스트 중간에 요구사항이 변경되거나 새로운 기능이 추가될 때, Xmind의 Drag & Drop 기능을 이용해 간편하게 하위 항목을 추가하거나 재배치할 수 있습니다.이러한 유연성 덕분에 변경 사항을 신속하게 반영할 수 있으며, 특히 애자일 환경에서 빈번한 변경에도 민첩하게 대응할 수 있었습니다.복잡한 프로젝트일수록 테스트 케이스의 구조를 직관적으로 조정할 수 있어, 작업의 일관성을 유지하기 쉬웠습니다.프로젝트 전반의 흐름과 마일스톤 관리엑셀 방식의 테스트 케이스 관리는, 특정 마일스톤의 기획 문서나 스펙 등을 한 번에 살펴보기 어려운 경우가 있습니다.Xmind는 테스트 케이스를 마일스톤과 연계하여 전체적인 프로젝트 흐름을 쉽게 파악할 수 있게 도와주었고, 각 마일스톤에 따른 중요 사항을 체계적으로 관리할 수 있었습니다.또한, 마일스톤 별 우선순위를 명확하게 설정할 수 있어, 제한된 시간 내에 중요한 테스트 항목에 효과적으로 집중할 수 있었습니다.기존에 사용하던 엑셀 기반 테스트 케이스 관리 방법도 여전히 중요한 방식이지만, 이번에는 Xmind를 이용하여 테스트 케이스를 만드는 방법에 대해 작성해 보겠습니다.프로젝트 초기 단계에서 피그마 디자인, 스펙 문서, 기획서 등 다양한 출처로부터 기능 요구사항을 수집합니다.이 요구사항을 Xmind에 입력하고, 트리 구조로 기능별로 분류하여 정리합니다.상위 기능을 중심으로 하위 세부 기능을 확장해 나가며, 복잡한 요구사항을 쉽게 관리할 수 있습니다.정리된 요구사항을 바탕으로 각 기능에 맞는 테스트 케이스를 작성합니다.작성된 테스트 케이스를 구조적으로 구분하고, 테스트 범위, 조건, 예상 결과 등을 세부 항목으로 분리해 시각적으로 명확하게 표현합니다.만약 테스트 중간에 요구사항이 변경되거나 새로운 기능이 추가되면, Drag & Drop으로 손쉽게 구조를 변경할 수 있습니다.시각화된 전체 기능을 토대로 테스트 우선순위를 설정합니다.중요한 기능이나 위험성이 높은 항목에 대해 우선순위를 두고, 색상 등으로 중요도 또는 우선순위를 명확하게 표시합니다.이를 통해, 우선 처리해야 할 항목들을 쉽게 구분할 수 있습니다.4. 팀과의 협업 및 피드백테스트 계획 및 진행 상황을 팀원들과 공유합니다.프로젝트 진행 중 발생하는 이슈나 피드백을 Xmind에 추가해, 수정 사항을 팀원들과 실시간으로 업데이트하고 관리할 수 있습니다.모든 테스트가 완료되면, Xmind를 이용해 테스트 결과를 체계적으로 정리합니다.완료된 테스트와 진행 중인 테스트를 명확하게 구분하여 관리할 수 있고, 이를 기반으로 최종 보고서를 작성합니다.Xmind를 도입한 이후, 프로젝트 관리 및 업무 효율성이 크게 개선되었습니다.테스트 케이스 간의 누락이나 중복 발생이 줄어들고, 피드백 속도가 빨라지게 되었습니다. 이를 통해 프로젝트 진행 속도를 높일 수 있었고, 제한된 시간 내에 중요한 테스트 항목에 더욱 집중할 수 있게 되었습니다.기존에 사용하던 도구가 아니었기 때문에 처음 Xmind를 도입했을 때는 오히려 시간과 노력이 더 들어가는 듯했습니다. 하지만 어느 정도 익숙해진 지금, Xmind는 프로젝트의 전체적인 흐름을 파악하는 데

안녕하세요. 커뮤니케이션 앱 LINE의 모바 일 클라이언트를 개발하고 있는 Ishikawa입니다.저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '나쁜 열거가 좋은 계층을 몰아낸다'입니다.나쁜 열거가 좋은 계층을 몰아낸다어떤 서비스의 '사용자 계정 유형'으로 다음과 같은 열거형이 정의돼 있다고 가정해 보겠습니다.로컬 저장소나 데이터베이스, 네트워크를 통한 API를 사용해 해당 값을 읽고 쓰는 경우 '컨버터'나 '매퍼'라는 메커니즘을 사용해 언어별 객체 및 인터페이스 정의 언어 또는 프로토콜에 정의된 바이트 열로 상호 변환할 수 있습니다. 예를 들어 Android 애플리케이션 개발에서는 Room이라는 지속성 라이브러리를 이용할 수 있으며, 라는 메커니즘을 사용해 컨버터를 쉽게 구현할 수 있습니다.하지만 다음 사용 예시에는 문제가 있습니다. 어떤 점이 문제일까요?해당 코드의 문제점은 과 이라는 열거형 속성을 사용했기 때문에 컨버터가 부패 방지층 역할을 하지 못한다는 것입니다. 이 때문에 외부(인터페이스 정의 언어나 프로토콜)의 변경 사항이 열거형을 사용하는 코드에 영향을 미치며, 그 반대로 영향이 전파되기도 합니다.만약 데이터베이스나 원격 API에서 사용하는 값(이하, 외부에서 사용하는 값)이 변경되면 열거형 정의도 변경돼 열거형을 사용하는 코드에도 영향을 미칩니다. 반대로 열거형을 사용하는 측 사정으로 열거형에 다른 이름을 부여하거나 정의 순서를 바꾸고 싶어질 수도 있지만, 이름이나 순서를 변경하는 것은 외부에서 사용하는 값에 직접 영향을 미치기 때문에 마음대로 변경할 수 없습니다.을 사용하면 발생하는 구체적인 문제를 예로 들어보겠습니다. 라는 새로운 을 추가하려고 한다고 가정해 봅시다. 가격 설정이나 기능 면에서 볼 때 는 과 의 중간으로 정의하는 것이 타당하다고 하겠습니다.그런데 위와 같이 변경하면 의 값도 변경됩니다. 따라서 외부에서 사용하는 값도 업데이트해야 합니다.을 사용할 때도 비슷한 문제가 발생합니다. 예를 들어 리브랜딩을 위해 , , 라는 열거형 이름을 , , 로 변경하고 싶다고 가정해 봅시다. 만약 해당 변경을 그대로 진행한다면 이전에 외부에서 사용 중인 값이 깨져버립니다.이와 같이 과 을 사용할 때의 무서운 점은 열거형을 사용하는 측에서 편의를 위해 간단한 리팩토링만 진행해도 의도치 않게 버그가 발생한다는 것입니다. 열거형을 사용하는 입장에서는 언뜻 봐서는 해당 변경 사항이 외부에서 사용하는 값에 영향

안녕하세요, 현대자동차그룹의 R&D전략팀에서 오픈이노베이션 및 기술이전/사업화, 투자를 담당하고 있으며 Full Stage Venture Capitalist로 성장하고 있는 윤상원 책임연구원 입니다.지난 글에서는 오픈이노베이션(Open Innovation, 이하 OI로 기재함)의 정의와 진화, 급변하는 시장에서의 현대자동차그룹의 응전에 대해 이야기 해 보았습니다.이번 글에서는 당사의 OI 플랫폼 중 스타트업과 협업하는 프로그램인 '제로원 엑셀러레이터 프로그램, ZER01NE Accelerator Program'의 협업 지원서가 정부지원사업의 사업계획서와 어떻게 다른지를 설명하면서 이 글을 보시는 미래 또는 잠재적 스타트업 대표님들과 이야기 해 보도록 하겠습니다.1. 제로원 엑셀러레이터 프로그램, ZER01NE Accelerator Program | https://zer01ne.zone/zer01ne-accelerator/당사의 OI 플랫폼 중 스타트업(Start-Up)과 협업하는 프로그램인 '제로원 엑셀러레이터 프로그램, ZER01NE Accelerator Program에 대해 다시 한 번 설명드리겠습니다.잘 아시는 것처럼 새로운 시장과 새로운 비즈니스 모델(Business Model)을 만드는 것은 스타트업이 훨씬 유리합니다. 이는 대기업의 경우 스타트업의 속도와 민첩함을 따라갈 수 없고, 시장에서의 테스트(고객 반응)가 필요할 경우, 기존 브랜드 훼손의 이슈도 있기 때문에 쉽게 접근하지 못하기 때문입니다. 이에, 현대자동차그룹은 본 프로그램을 통해 그룹 내부의 문제를 해결하고자 하는 사항을 외부 스타트업과의 협업을 통해 시도하고 필요할 경우 전략적 투자(S.I., )도 진행하고 있습니다.<참고> 전략적 투자와 재무적 투자(F.I., ) 전략적 투자(S.I., Strategy Investment)     미래에 특정 기술을 포함하는 제품을 납품 받기 위한 투자로 주로 제조업 분야에서 많이 진행함 재무적 투자(F.I., Financial Investment)     재무제표상 '영업외수익'을 통한 원활한 기업 운전 자금의 확보를 위한 투자로 센싱 기능 포함함 이하 내용은 개인의 생각으로 현대자동차의 공식적인 입장은 아님을 미리 고지합니다.2. 대기업의 협업 지원서 파헤치기다양한 OI 플랫폼에서 과제를 사전 공유하며 다음과 같은 목차로 구성된 협업 지원서를 많이 요청하고 있습니다*[1, 2]*.       1) 과제를 해결하기 위한 제품 및 솔루션       2) 과제 진행 계획 및 지원 자금 집행 계획       3) 스타트업이 보유하고 있는 기술의 특징 및 증빙       4) (행정서류) 사업자등록증, 법인등기부등본, 재무제표 등"과제를 사전에 공유한다"는 문구에서 눈치가 빠르신 분들은 추측이 가능하신 것처럼 대기업 내부에 관련한 조직이 존재합니다. 여기서 '내부의 조직이 있는데 왜 공모를 진행하죠?' 라고 질문하신다면 그 답을 OI에서 찾으실 수 있습니다.<참고> OI, Open Innovation 정의 [3]"2003년 미국 버클리대학의 헨리 체스브로(Henry Chesbrough)가 그의 저서, Open Innovation에서 제시한 개념으로 외부에 존재하는 기술, 지식, 아이디어를 활용하여 연구개발(R&D)비용을 줄이고, 성공 가능성을 높여 그 효율성을 극대화하는 방식을 지칭함"알고 계신 것처럼 1개의 기능을 구현하기 위한 필요 기술들은 복수 개의 조합이고 이에 대한 그 세부(하부)기술들도 아주 많습니다. 이를 내부의 1개 팀에서 모두 시도해보고 이를 비교해서 최적의 솔루션을 찾는 것은 정말 많은 시간이 소요될 것이기 때문에 공모(전)를 활용해 그 시간과 그에 따른 비용을 절약하고 있습니다(개발자 10명의 1개팀의 연봉을 생각하시면 보다 쉽게 이해되실 것 입니다).그럼, 다시 협업 지원서로 돌아가서 함께 지원자(스타트업 대표님) 입장에서 접근해 보겠습니다. 보다 구체적으로 2024년 하반기 당사의 공모 1개를 확인해 보면 다음과 같습니다.제목 : 음성인식 기반 인캐빈 모니터링 솔루션개요 : AI 음성인식 분석 기반 인캐빈 모니터링 솔루션 개발개발 목적 : 탑승자 이상 상태 파악 및 경고 기능 구현검증 내용 : 차량 탑승자 상태 모니터링 분석 결과 정확도 검증적용 계획 : 차량 옵션 상품화 적용 검토필요 역량 : (스타트업) AI 음성인식을 활용한 탑승자 모니터링 분석 및 피트백 제공 서비스 역량(제가 생각하는) 위의 솔루션을 구성하는 기술과 그에 대한 세부기술의 조합은 다음과 같습니다.음성 인식 기술 - 문장 활용 기술 / 말하기 속도 측정 기술 / 어조 측정 기술영상 인식 기술 (인캐빈 카메라를 활용함) - 몸의 움직임 측정 기술 / 얼굴(표정) 측정 기술 / 눈동자 측정 기술운전자 상황 판별 기술 - 음성(소리)만을 활용하는 기술 / 영상(카메라)만을 활용하는 기술 / 핸들 조작 감지 기술 / 복합 감지 기술운전자 알림 기술 - 실내등 활용 기술 / HUD 활용 기술 / 핸들 연동 기술 / 시트 연동 기술만약, 우리 스타트업(이하 '연구핑[4]'으로 지칭함)이 스마트 팩토리에서 활용되는 머신 비전 시스템*으로 매출을 발생시키고 있고, 사업 영역의 확대를 위해 음성 인식 및 처리 알고리즘을 코딩할 수 있는 개발자를 채용한 상태에서 본 공고를 확인했다면 어떻게 접근하면 가장 좋을까요?<그림> 머신 비전 시스템 / <출처> 비전시스템[5] / 기술정보('22.10/16) 기사 사전 조사를 통해 'AI 음성인식 분석 기반 인캐빈 모니터링 솔루션'의 요소 기술들과 확장 시 필요 기술들을 정리해보니 음성 인식 기술, 영상 인식 기술, 운전자 상황 판별 기술, 운전자 알림 기술 등이 필요한 것으로 확인되었습니다.이에 "연구핑"이 다음과 같은 제안서(협업 지원서)를 작성한다면 '제로원 엑셀러레이터 프로그램'에 선발될 수 있을까요?연구핑의 협업 지원서A. 과제를 해결하기 위한 제품 및 솔루션 : 복합(음성 및 영상) 인식 기반의 인캐빈 모니터링 시스템<그림> 복합 인식 기반의 인캐빈 모니터링 시스템의 요소 기술 / <출처> Napkin.ai / https://app.na

글. 김지영(Terna) / Platform Design Team Lead부제. 효율적인 디자인 시스템 구축을 위한 프로세스 개선지난 글에서는 디자인 시스템 운영 과정에서 겪은 비효율과 그로 인해 생긴 고민들을 공유드렸는데요. 혹시 공감되거나 비슷한 경험이 떠오르셨나요? 이번 글에서는 그 문제들을 어떻게 해결했는지, 더 나은 시스템을 구축하기 위해 어떤 시도와 개선을 이뤄냈는지 자세히 소개해드릴게요.1. 버전 추적의 어려움을 어떻게 해결했을까?① 명확한 업데이트 규칙과 버전 관리많은 컴포넌트를 앱에 반영하는 것도 중요했지만, 그보다 더 중요한 건 확실하게 검증된 컴포넌트를 만드는 거였어요. 그래야 디자인 라이브러리를 넘어, YDS 컴포넌트는 기능적으로도, 심미적으로도 믿을 수 있다는 신뢰를 쌓을 수 있다고 생각했죠.그래서 먼저 버전 업데이트의 규칙을 새롭게 정의했어요. 체인지로그는 코드 레벨에서 변경점이 있는지를 기준으로 상태값을 명확히 정의해서 작성했구요. 이 체인지로그와 함께 해당 버전의 스펙을 확인할 수 있는 피그마 브랜치 링크를 앱 개발팀에 전달했어요. 프로젝트와 분리된 지라 티켓으로 요청해 시스템 개발이 버전 단위로 진행되도록 했죠.배포 일정이 정해지면 UX Owner분들께 공지해서, 작업 중인 피그마 파일에서 라이브러리 업데이트를 받을 시점을 조율할 수 있도록 했어요. 이렇게 프로세스를 정리하면서 업데이트 흐름을 명확하게 알 수 있게 했고, 개발과 시스템 디자인 간의 연결을 더 견고하게 만들게 되었어요.② YDS 컴포넌트 검수용 샘플앱앱에 아직 적용되지 않은 컴포넌트를 포함해 기존 컴포넌트의 검수가 절실했는데요, 이 부분은 앱개발팀이 먼저 적극적으로 방법을 제안해 주셔서 검수 전용 샘플앱(YDS Stage)을 구축하게 되었어요. 피그마 라이브러리 버전이 업데이트되면, 개발이 진행되는 동안 샘플앱 가이드를 작업하고, 이후 샘플앱 업데이트를 요청드리는 방식으로 검수를 이어가고 있어요. 상용 앱에서는 확인하기 어려운 상태값까지 포함해 Variants 단위로 꼼꼼히 검수가 가능해졌죠.검수가 가능하다는 건 시스템 디자이너 입장에서 정말 큰 의미가 있었어요. 내가 검증한 컴포넌트를 개발자와 UX Owner가 실제로 활용할 거라는 확신이 생기니, 작업에 대한 불안감도 크게 줄어들었거든요. 더불어 샘플앱은 시간이 지날수록 그 중요성이 커질 거라고 생각해요. 앱 내 적용되는 컴포넌트 비율이 늘어날수록, 컴포넌트 변경이 앱 전반에 미치는 영향도 커지기 때문에 검수 과정은 더욱 민감한 사안이 될 거예요. 결국 샘플앱이 시스템의 신뢰를 유지하고, 변경의 리스크를 줄이는 데 필수적인 도구로 자리 잡을 거라고 생각해요.2. A/B 테스트와 실험 UI 관리의 문제은 어떻게 해결했을까?사후 대응과 위닝 패턴 수집업데이트와 버전 관리 규칙이 생긴 덕분에 덕분에 디자인 시스템이 프로젝트 일정에 휘둘리던 문제는 어느 정도 해결됐어요. 시스템 자체를 고도화할 프로세스도 정립되었고요. 그런데 여전히 전체 컴포넌트가 개발되지 않았고, 앱에 충분히 반영되지 않은 상태

모닥불 10화 특집: 캠프파이어 에피소드 🔥 이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요."폴더 구조를 설계할 때 꼭 지켜야 할 원칙은?" "컴포넌트 추상화, 어디까지 해야 더 효율적일까요? "함수형 프로그래밍은 언제, 왜 사용하는 게 좋을까요?"사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지! 토스 개발자들이 실무 경험에서 얻은 노하우와 인사이트를 아낌없이 공유합니다! 지금 바로 확인해보세요!• None 01:20 첫 번째 사연: 폴더 구조는 어떻게 정리해야 협업이 쉬울까요?• None 06:39 두 번째 질문: 컴포넌트를 어떻게 분리하고, 추상화는 어디까지 해야 할까요?• None 11:20 변경 사항을 예측해 추상화 하는데 어려움을 겪고 있다면• None 15:24 세 번째 질문: 유효성 검사는 에러로 보는 것이 맞을까요?• None 19:57 네 번째 질문: 함수형 프로그래밍이 꼭 필요한가요?다른 모닥불 회차 보러가기 EP.7 개발자 리더로서 성장당한 썰 EP.8 Next.js 그만 쓰세요! 면접관이 진짜 원하는 것!? EP.9 프론트엔드 서비스 최적화? 토스에서는 '이렇게' 합니다!

네이버 검색 FE 시스템 구축 과정에서 저희는 다음과 같은 문제에 직면했습니다.첫째, 유사하지만 영역이 다른 경우 비슷한 작업을 반복하는 경우가 있었습니다.검색의 각 영역은 마이크로서비스 아키텍처(MSA)로 이루어져 있으며 클라이언트 코드 역시 영역별로 관리되고 있었습니다. 이로 인해 영역 간 동일한 유형의 작업을 반복해야 했고, 경험이 축적되기보다는 업무의 성장이 저해되는 결과를 초래했습니다.둘째, 유사한 UI를 매번 새로 개발해야 하는 비효율성이 존재했습니다.코드의 재활용이 어려워서 유사한 패턴의 UI를 구현할 때마다 새로운 코드를 작성해야 했고, 이는 자원의 낭비로 이어졌습니다.셋째, 데이터가 부족해 개선 작업이 어려웠습니다.개선이 이루어져도 이를 측정할 수 있는 데이터가 부족해서 실제 효과를 파악하기 어려웠습니다. 그 결과, 어디부터 개선해야 할지, 문제는 없을지 등을 판단하기가 어려워 개선 작업의 방향성을 설정하기 어려웠습니다.넷째, 피드백 주기가 지나치게 길다는 문제가 있었습니다.디자인이 실제 코드로 구현되어 동작하기까지의 시간이 너무 오래 걸렸고, 이 과정 중에 디자인이 수정되면 재작업이 많아지는 비효율적인 상황이 발생했습니다.이 글에서는 이 문제들을 해결하기 위한 저희의 해결 방안과 현재 고민하고 있는 문제를 공유하겠습니다.해결 방향이러한 문제를 해결하기 위해 저희가 생각한 해결 방향은 다음과 같습니다.첫째, 서버 주도 UI(Server Driven UI) 방식을 도입했습니다.비슷한 작업이 반복되는 문제를 해결하기 위해 UI를 한곳에 모으고 이를 재활용할 필요가 있었습니다. 서버에서는 비즈니스 로직만 구현하고 UI를 생성하는 서버를 별도로 두는 것이 적합하다고 판단하여 서버 주도 UI 방식을 채택했습니다. 이를 통해 클라이언트 측에서 UI를 반복해 개발할 필요 없이 서버에서 다양한 상황에 맞춰 유연하게 UI를 전달할 수 있게 되었습니다. 이는 비슷한 개발 작업을 줄이고 유지 보수의 효율성을 크게 향상시켰습니다.둘째, 디자인 시스템(Design System)을 통한 해결책을 마련했습니다.기존에는 UI가 유사해도 개발자가 달라서 별도로 개발하여 중복이 발생했다면, 이제는 자주 사용되는 UI 요소를 일관된 디자인 시스템으로 구축하여 재사용이 가능하도록 만들었습니다. 이는 개발자와 디자이너 모두에게 큰 도움이 되었으며, UI 개발 시간을 단축시키고 중복된 노력을 최소화할 수 있었습니다.셋째, 데이터 기반의 접근 방식을 도입했습니다.현재 데이터가 부족해 개선 작업이 어렵다는 문제를 해결하기 위해, 더 많은 데이터를 수집하고 이를 바탕으로 피드백 루프를 강화하는 계획을 수립했습니다. 특히 현재 사용되고 있는 UI를 분석하고 그 데이터를 수집하여, 이후 개발 및 운영 과정에 적극적으로 활용하고자 했습니다. 이를 통해 서비스에 많이 사용되는 컴포넌트와 모듈을 수집하고 사용자의 패턴을 파악하며 어떤 UI가 효과적인지에 대한 통찰을 얻어 UI와 UX를 최적화할 수 있게 되었습니다. 더 나아가, 데이터 분석 결과는 새로운 기능 개발뿐만 아니라

디자이너로서 커리어를 시작할 때, 특히 경력이 부족하다면 고민이 많을 수밖에 없죠. “내가 과연 준비가 됐을까?”, “경험도 없는데 이런 회사에 도전해도 될까?” 같은 걱정이 앞서기 마련인데요. 그런 고민 속에서 도전했던 두 디자이너 세린님과 수빈님의 이야기를 들어봤어요.두 분이 경험한 토스 인턴십은 단순히 보조 업무나 과제 중심의 경험이 아니라, 1인 디자이너로서 제품을 주도적으로 맡을 수 있었던 기회였다고 해요. 4개월이라는 시간 동안 압축적으로 성장하며 과거의 자신을 뛰어넘을 수 있었던 그 이야기, 지금 시작할게요.Q. 토스 인턴십에는 어떤 분들이 지원하시는지 궁금해요. 두 분은 지원 당시 어떤 상황이셨나요?세린 : UX 디자인에 흥미를 느껴 공부하던 학생이었어요. 하지만 제 실력으로는 디자이너로 시작하기에 부족하다고 느껴서 고민이 많았죠. 그러다 토스 PD 인턴십 공고를 보고 ‘이건 꼭 도전해야 한다’는 생각이 들었어요. 토스는 제가 꼭 경험해보고 싶었던 회사였거든요. 아직 졸업 전이었지만, 지금 아니면 안 될 것 같다는 마음으로 지원했어요.수빈 : 저는 원래 산업디자인을 전공했어요. 코로나 이후 제 적성을 고민하다 UX 디자인으로 눈을 돌리게 됐죠. 다른 회사에서 프로덕트 디자이너로 인턴을 하긴 했지만, 주도적으로 문제를 해결하는 경험이 부족하다는 아쉬움이 남았어요. 그래서 더 적극적으로 일할 수 있는 환경을 찾아보다 토스에 지원하게 됐어요.Q. 경력이 많지 않았던 만큼 걱정도 많으셨을 것 같아요. 어떤 점이 가장 고민이었나요?세린 : 걱정이 많았죠. UX 실무 경험은 없었고 PM 인턴 경험만 있었거든요. 하지만 입사 전형을 겪으며 토스가 “경력보다 잠재력을 본다”는 걸 느꼈어요. 얼마나 많은 디자인을 해봤는지가 아니라, 문제를 해결하려는 태도와 제품을 바라보는 관점이 훨씬 중요했어요. “경력이 없다면 우리가 만들어 줄게!”라는 느낌이 강했달까요.수빈 : 저도 비슷했어요. 포트폴리오도 완벽하지 않았고, UI 디자인 경험도 부족했거든요. ‘내가 이 정도로 가능할까?’라는 생각이 들었지만, 면접 과정에서 제게 필요한 질문들을 많이 받으면서 생각이 바뀌었어요. ‘왜 이런 디자인을 선택했는지’, ‘이 문제를 어떻게 풀려고 했는지’를 묻는 질문들 덕분에 제 사고 과정을 돌아볼 수 있었고, 자신감도 얻었어요.또 저의 경험과 태도를 보여주는 것에 집중했어요. 예를 들어, 제가 사이드 프로젝트를 할 때 발로 뛰며 사용자 인터뷰를 했던 경험이나, 꽃 사진 촬영을 위해 꽃을 직접 사고 팝업으로 판매까지 했던 이야기들을 담았어요.결국, 토스가 원하는 건 현재 스킬보다도 그런 적극적인 태도와 문제를 해결하려는 자세가 아니었을까 싶어요.Q. 실제로 토스에서 인턴십을 하며 어떤 경험을 하셨나요?세린 : 대부분의 인턴십은 보조 업무 위주로 진행된다는 인식이 있잖아요. 그런데 토스는 달랐어요. 사일로에 소속된 1인 디자이너로서 제품의 모든 과정을 주도적으로 맡을 수 있었어요. 제가 제안한 디자인이 실제로 제품에 반영되고, 유저 반응을 확인하는 경험은 정말

사업개발, 영업으로 커리어를 시작해서 풀스택, 프론트엔드, 서버 개발까지 다 해보신 지민님의 이야기를 들려드립니다. 끝 없는 도전과 변화, 지민님은 매 순간 어떤 태도로 커리어를 대했을까요? 토스 피플 글을 통해 알아보세요.토스에서 하고 계신 일을 간략히 소개해주세요.토스증권 마진 트레이딩 사일로에서 서버 개발자로 일하고 있어요. 저희 사일로는 외상 거래(미수 거래) 와 같은 레버리지를 사용하는 서비스들을 만들고 있어요. 돈이 없어도 레버리지를 사용해서 주식 투자를 할 수 있는 거죠. 주식에서 얻은 수익으로 빌린 돈을 갚고요. 최근에는 주식 담보 대출이라는 새로운 기능도 준비하고 있어요.어떻게 처음 커리어를 시작했나요?학부에서 경제학과 심리학을 전공했었는데요. 처음에는 대학원을 가려고 진로를 정해두고, 공군 학사 장교로 군복무를 시작했어요. 근데 가보니까 제가 큰 조직이랑 안 맞는 사람이라는 걸 깨달았어요. 저는 계속 더 나은 방식으로 일을 하고, 무언가를 발전시키고 싶었는데 큰 조직에서는 안전하고 해오던 방식을 선택하는 게 미덕이더라고요.그러다 하고 싶은 걸 생각해봤을 때 쥐뿔도 없이 시작할 수 있는 IT 창업을 꿈꿨어요(웃음). 일단 개발은 모르니까 친구랑 창업자 쫓아다니고, 해외 밋업도 가보고, 아이템도 선정해보고… 많은 일을 했죠. 근데 그렇다고할 제품은 결국 하나도 안 나오고 엎어졌어요. 결국 “스타트업에 가서 IT 창업에 대해서 배우자”라는 선택을 했어요.어떤 스타트업에 들어갔나요?IoT 가 뜨고 있을 때라 관련된 스타트업에 들어가서 “뭐든지 해봐야겠다” 싶어서 사업개발을 담당했어요. 거기서 열심히 개발자랑 디자이너랑 친해져서 사이드 프로젝트도 다양하게 해봤어요. ‘오모’라는 알림 서비스도 만들었고요. 이 회사에서 많이 배웠지만, IoT 라는 기술에 대한 한계가 보였고, 새로운 환경에서 더 많은 성장을 하고 싶어서 이직을 했어요.결혼 준비 플랫폼에 영업 직군으로 이직했는데요. 강남을 돌아다니면서 셀프 웨딩 촬영 스튜디오, 드레스샵, 웨딩홀 같은 곳을 영업했죠. 새로운 도메인을 알게 되, 매출이 없던 곳에서 매출을 만들어내는 게 재미있었어요. 저도 이 회사를 다니면서 결혼 준비를 했고요.근데 곰곰히 생각해보니 회사가 어려워지면 제가 제일 먼저 잘릴 거 같았어요(웃음). 전문성이 쌓이고 있다는 생각이 들지 않았고, 제가 커리어를 발전시키고 있다는 생각도 안 들었어요. 반면 옆에서 지켜본 개발자들은 어떤 기술을 써본 것만으로도 커리어가 쌓이고 성장에 후퇴가 없다는 느낌이 들어서 부러웠어요.그래서 개발을 배우기로 결심했나요?네. 신혼여행 가서 고민하다가 개발을 해봐야겠다는 마음을 먹었어요. 제가 레스토랑을 열고 싶으면 요리를 기본적으로 알아야 되듯이, 나중에 창업을 하고 싶으면 개발을 알아야 된다는 생각도 들었고요. 그래서 국비 개발 학원을 6개월 동안 열심히 다녔죠. 이때 제가 서른이었어요. 늦었다는 생각도 들었지만 개발자가 되면 커리어를 차근차근 쌓아갈 수 있다는 것도 알고 있었고, 성장이 돈으로 보상된다는 것도 알고 있어서 으쌰