Neoself의 기술 블로그

이번 포스트에서는 이미지 캐싱 라이브러리의 캐시 히트율을 높이기 위한 프로젝트의 첫 단계로, Kingfisher 라이브러리의 핵심 구조를 분석하고 필수 모듈을 추출한 과정을 공유하려 합니다.프로젝트 배경 및 목표최근 모바일 애플리케이션에서 이미지 로딩은 사용자 경험에 직접적인 영향을 미치는 중요한 요소입니다. 이에 저는 다음과 같은 가설을 세웠습니다:이미지에 대한 카테고리 정보를 이미지 데이터와 함께 제공받을 수 있다면, 사용자의 이미지 사용 패턴을 학습하여 캐시 히트율을 향상시킬 수 있다. 이 가설을 검증하기 위해 우선 기본적인 이미지 캐싱 라이브러리를 구축할 필요가 있었고, 널리 사용되는 오픈소스 라이브러리인 Kingfisher를 참고하여 핵심 기능만을 추출하는 작업을 진행했습니다.0. Kingfis..

1. 3차 리펙토링2차 리펙토링 이후, 구조에 대해 아래와 같은 문제점을 파악하게 되었습니다. 1. 서비스 레이어의 분산으로 인한 응집도 저하BookSearchService는 BookMatchAPI 모듈 내부에 위치한 반면, ImageProcessService와 TextExtractionService는 BookOCRKit에 위치했으며, BookValidationService는 BookRecommendationKit 내부에 위치했습니다.때문에 같은 비즈니스 로직을 담당하는 서비스 레이어 컴포넌트끼리의 응집도가 저하되는 문제가 있었습니다. 2. 의존성 관리의 복잡성2개의 최상위 모듈이 3개의 서비스 레이어 컴포넌트들 중 일부를 직접 import하여 사용하고 있기에 Service 레이어와 Integration..

1. 2차 리펙토링이후 아래와 같은 이유들로 인해 2차 리펙토링의 필요성을 느끼게 되었습니다.- DeepSeek api처럼 로직 목표를 공유하는 다른 외부 API를 추가하거나 대체하고자 할때, 많은 개발 리소스가 소요됨.- BookMatchModule 내부 기능상 다른 역할을 하는 메서드 2개가 공존하고 있기에, 유지보수 용이성이 저하됨.- BookMatchModule 내부 세부로직들에 대한 책임이 명확히 분리되어있지 않음. 따라서 크게 4가지 변경점을 가져가고자 했습니다.1. API 계층 개선2. BookMatchModule 책임 분리3. 계층적 디렉토리 구조 도입4. 서비스 계층 도입 2. API 계층 개선 API 클라이언트 분리기존에는 DefaultAPIClient라는 단일 클래스에서 모든 API..

이번 포스트에서는 도서 추천 및 매칭 시스템인 BookMatchKit의 아키텍처 설계 과정에 대해 살펴보겠습니다.1. 1차 리펙토링1차 리펙토링에는 단일 책임원칙 준수를 최우선 순위로 고려해 다음과 같은 주요 모듈들로 구성하게 되었습니다.BookMatchKit/├── Sources/│ ├── BookMatchAPI/ # 외부 API 통신 계층│ ├── BookMatchCore/ # 핵심 도메인 계층│ ├── BookMatchKit/ # 비즈니스 로직 계층│ └── BookMatchStrategy/ # 알고리즘 구현 계층1.1 BookMatchCoreBookMatchCore는 프로젝트의 핵심 도메인 로직을 담고 있는 모듈로써 설계했습니다.BookItem: 도..

이번 포스트에서는 CoreML과 OCR을 활용한 도서 표지 인식 결과를 기반으로, 실제 도서를 매칭하는 시스템의 후처리 구현 과정을 공유하고자 합니다. 특히, 초기 기획과는 다르게 변경된 설계 과정과 그 과정에서 마주친 문제들을 어떻게 해결했는지 자세히 다루어보겠습니다.1. 초기 설계와 변경된 요구사항1.1. 초기 설계처음에는 다음과 같은 플로우를 계획했습니다:전처리: OCR 및 CoreML로 도서 표지에서 추출된 텍스트 제목/저자로 라벨링하여 전달후처리: 기존 구현된 searchOverallBooks 메서드로 도서 검색 후, 제목&저자 간 텍스트 유사도가 가장 높은 도서 반환public func searchOverallBooks(from sourceBook: RawBook) -> Single { ..

1. 기존 시스템의 한계점 및 기존 시스템 플로우 개선초기 도서 매칭 시스템은 GPT가 제공하는 도서 정보의 정확성을 전제로 설계되었습니다. 시스템은 단순히 제목, 저자, 출판사 간의 텍스트 유사도 비교에만 중점을 두었습니다. 하지만 테스트 과정에서 GPT가 실제로 존재하지 않는 도서를 추천하는 케이스가 상당수 발견되었습니다. 따라서, 기존 로직 흐름에 재시도 로직을 추가해, 존재하지 않는 책에 대한 매칭이 이뤄지는 것을 최소화하고자 했습니다.개선된 시스템 플로우 계획1. 책 추천에 대한 질문에 대해 GPT가 1~3개의 책 데이터 반환2. 각 책 데이터에 대해 재시도 횟수 3회로 두고 존재하는 책이 나올때까지 아래 내용반복수행         1. 제목과 저자를 네이버 책 검색 api query에 전달 후..

저번 게시글에서는 도서 매칭 시스템에 대한 테스트 환경 구축을 비롯해 설계를 진행하였으며, 해당 게시글에서는 본격적인 구현 과정을 다루고 있습니다.1. 도서 매칭 시스템 개요2. 검색 결과 반환 로직 구현    - 메서드 구현    - 테스트 환경 구축    - 트러블 슈팅3. 엣지케이스 처리를 통한 검색 결과 반환 확률 개선    - 빈 스트링 값 처리    - 부제가 잘못된 케이스 처리    - 영문 책 한글 제목 검색 문제 해결    - 코드 캡슐화4. GPT 연동 및 유사도 측정 구현    - ChatGPT API 연동    - 검색 결과 유사도 연산    - 최종 매칭 로직 구현5. 테스트와 성능 개선    - ExactMatchStrategy와 ContainsStrategy 구현    - 레벤..

ChatGPT api를 활용해 사용자가 제시한 질문에 적합한 책을 추천하는 로직을 개발하면서 발생한 기술 도전과제의 해결과정을 정리한 글입니다.ChatGPT 반환값의 후가공 과정에 대한 이해도를 높히고자 하는 개발자분들께 도움이 되었으면 좋겠습니다. 0. 배경구현이 필요한 핵심로직은 아래 2개로 정리할 수 있습니다.책 추천: AI를 활용해 사용자의 질문에 답이 될 수 있는 책을 추천하고, 앱 내 서재 탭에 추가할 수 있도록 하기책 추가: 사용자가 책표지를 촬영할 경우, OCR촬영된 책 앱 내 서재 탭에 추가하기위 기능을 구현하기 위해선 결국 아래와 같은 기술적 고민으로 이어졌습니다.1. 사진촬영을 통해 책을 인식하는 로직2. ChatGPT로 책을 추천받는 로직1번과 2번 로직의 경우, ChatGPT만을 ..

이 글에서는 제가 클린 아키텍처를 공부하고, 이를 실제 프로젝트에 적용하면서 겪은 경험을 공유하고자 합니다. 클린 아키텍처 자체에 대한 이해도를 높히고 싶으신 개발자 분들께 도움이 되었으면 합니다. 배경Todo 앱을 개발하면서 가장 신경 쓴 부분은 오프라인 상태에서도 앱이 정상적으로 동작하는 것이었습니다. 사용자가 지하철에서 Todo를 추가하거나 수정하더라도, 네트워크가 복구되면 자연스럽게 서버와 동기화되어야 했죠. 이를 위해 CoreDataSyncService라는 동기화 전담 서비스를 구현했습니다. 하지만 시간이 지날수록 이 서비스는 점점 더 많은 책임을 떠안게 되었습니다. CRUD 작업마다 로컬 저장소 처리, 네트워크 요청, 위젯 업데이트까지... 모든 로직이 긴밀하게 얽혀있었죠.func update..

RxSwift는 ReactiveX 프로그래밍 패러다임을 Swift로 구현한 라이브러리입니다. 이 글에서는 RxSwift의 핵심 컴포넌트들이 어떻게 상호작용하며 동작하는지 실제 소스 코드를 통해 살펴보겠습니다. 아래 사진은 RxSwift 라이브러리의 내부 구현파일들의 의존성을 표현한 그래프입니다. 해당글을 통해 다루게 되는 파일들은 검정색 및 빨간색 줄처리하였습니다. RxSwift의 기본이 되는 타입 계층 구조는 다음과 같습니다:1. 핵심 타입 계층 구조1.1. ObservableConvertibleType모든 Observable 타입의 기본이 되는 프로토콜입니다.public protocol ObservableConvertibleType { associatedtype Element func as..