결정사항
- KeywordID 주입 문제 해결을 위해, 키워드 전체 리스트를 앱 시작시 받아오기. 저장은 간단하게 그냥 변수에 담아두기. 어짜피 시작할 때마다 매번 받아오기 때문에, 영구 저장소까지 갈 필요가 없을 듯!
- Data module에 Factory
- Class가 반드시 필요한 경우가 아니라면 Struct
- TUIST EDIT의 모듈 의존성 생성 함수 케이스별로 다 만들지 말고 함수 하나로 - @Naknakk
- OSLogger 도입 - @Guryss
- BaseData 도입 - @onesunny2
- Networking 모듈에 Token 주입&Token Refresh 기능 추가 - @Naknakk
회의록
로거 및 에러 처리 아키텍처 기술 논의 요약
일시: 2026-03-27 16:55 KST
전체 요약
이번 대화에서는 프로젝트의 로깅 및 에러 처리 구조를 어떻게 정리할지에 대한 논의가 중심이었습니다.
주요하게는 로거를 프로토콜 기반으로 추상화할지, 데이터 모듈과 네트워크 모듈의 에러를 어떻게 구분하고 처리할지, 그리고 모듈 간 의존성과 중복 코드를 어떻게 줄일지에 대한 의견이 오갔습니다. 전반적으로 유지보수성과 가독성을 높이는 방향으로 구조를 다듬으려는 논의였습니다.
핵심 논의 사항
1. 문서화 및 프로젝트 소개 방식
• 회의록이나 프로젝트 소개 문서를 노션 외에 GitHub 같은 외부에서도 볼 수 있게 정리하면 좋겠다는 의견이 나왔습니다.
• 프로젝트의 기술적 이유만이 아니라, 왜 이 프로젝트가 필요한지와 어떤 비즈니스적 목적이 있는지도 함께 드러내려는 방향이 논의되었습니다.
2. 로거(Logger) 구조 설계
• 콘솔 로거와 OS 로거를 어떻게 통합하거나 추상화할지 논의했습니다.
• 특정 구현체에 직접 의존하기보다, 프로토콜을 통해 추상적인 인터페이스를 정의하고 필요에 따라 구현체를 갈아끼울 수 있는 구조가 제안되었습니다.
• 다만 OSLog를 완전히 현재 프로토콜 구조에 맞추는 것이 적절한지에 대해서는 약간의 유보적인 의견도 있었습니다.
3. 에러 처리 방식
• 네트워크 에러, 매핑 에러, 데이터 계층 에러를 어디서 어떻게 나눠서 처리할지에 대한 고민이 있었습니다.
• 현재는 catch가 여러 번 중첩되거나 비슷한 구조가 반복되는 부분이 있어, 이를 줄이고 더 읽기 쉬운 형태로 개선하고 싶어 했습니다.
• 하지만 에러 종류별로 의미가 다르기 때문에, 무조건 하나로 합치기보다는 명확한 기준이 필요하다는 의견도 있었습니다.
4. 모듈 구조와 의존성 정리
• 공통으로 쓰이는 데이터/로깅 구조를 하나의 베이스 형태로 정의하고, 각 모듈에서는 extension이나 프로토콜 채택을 통해 필요한 부분만 확장하는 방향이 제안되었습니다.
• 프로젝트 타겟이나 의존성 선언이 반복되는 부분을 함수화해서 줄이자는 아이디어도 나왔습니다.
• 새 프로젝트 생성 시 폴더와 파일을 반복해서 만드는 과정이 번거로우니, 이를 자동화하는 명령어나 스크립트가 있으면 좋겠다는 의견도 있었습니다.
5. struct와 class 사용 기준
• 특별히 참조 타입이 꼭 필요한 경우가 아니라면, class보다 struct를 사용하는 쪽이 더 단순하고 관리하기 좋다는 의견이 나왔습니다.
• 값 타입과 참조 타입의 차이에 대한 설명도 함께 오갔습니다.
액션 아이템
• 로거를 프로토콜 기반으로 정리해, 내부 구현을 바꾸지 않고도 콘솔 로거/OS 로거 등을 교체할 수 있는 구조를 시도해보기
• 에러 처리 구조를 정리해서 중복된 catch와 로깅 패턴을 줄이기
• 프로젝트 생성 시 폴더/파일 세팅을 자동화하는 방법 검토하기
• 기존 로깅 방식들을 비교해 보고, 하나로 정리할 수 있는지 검토하기
아직 남은 질문
• OSLog까지 고려했을 때, 현재의 로거 프로토콜 추상화 수준이 적절한가?
• 에러별 catch를 분리하는 것이 더 나은지, 가능한 범위에서 통합하는 것이 더 나은지?
• 공통 모듈을 어디까지 일반화해야 중복은 줄이면서도 복잡도는 높아지지 않을까?
결정사항
회의록
로거 및 에러 처리 아키텍처 기술 논의 요약
일시: 2026-03-27 16:55 KST
전체 요약
이번 대화에서는 프로젝트의 로깅 및 에러 처리 구조를 어떻게 정리할지에 대한 논의가 중심이었습니다.
주요하게는 로거를 프로토콜 기반으로 추상화할지, 데이터 모듈과 네트워크 모듈의 에러를 어떻게 구분하고 처리할지, 그리고 모듈 간 의존성과 중복 코드를 어떻게 줄일지에 대한 의견이 오갔습니다. 전반적으로 유지보수성과 가독성을 높이는 방향으로 구조를 다듬으려는 논의였습니다.
핵심 논의 사항
1. 문서화 및 프로젝트 소개 방식
• 회의록이나 프로젝트 소개 문서를 노션 외에 GitHub 같은 외부에서도 볼 수 있게 정리하면 좋겠다는 의견이 나왔습니다.
• 프로젝트의 기술적 이유만이 아니라, 왜 이 프로젝트가 필요한지와 어떤 비즈니스적 목적이 있는지도 함께 드러내려는 방향이 논의되었습니다.
2. 로거(Logger) 구조 설계
• 콘솔 로거와 OS 로거를 어떻게 통합하거나 추상화할지 논의했습니다.
• 특정 구현체에 직접 의존하기보다, 프로토콜을 통해 추상적인 인터페이스를 정의하고 필요에 따라 구현체를 갈아끼울 수 있는 구조가 제안되었습니다.
• 다만 OSLog를 완전히 현재 프로토콜 구조에 맞추는 것이 적절한지에 대해서는 약간의 유보적인 의견도 있었습니다.
3. 에러 처리 방식
• 네트워크 에러, 매핑 에러, 데이터 계층 에러를 어디서 어떻게 나눠서 처리할지에 대한 고민이 있었습니다.
• 현재는 catch가 여러 번 중첩되거나 비슷한 구조가 반복되는 부분이 있어, 이를 줄이고 더 읽기 쉬운 형태로 개선하고 싶어 했습니다.
• 하지만 에러 종류별로 의미가 다르기 때문에, 무조건 하나로 합치기보다는 명확한 기준이 필요하다는 의견도 있었습니다.
4. 모듈 구조와 의존성 정리
• 공통으로 쓰이는 데이터/로깅 구조를 하나의 베이스 형태로 정의하고, 각 모듈에서는 extension이나 프로토콜 채택을 통해 필요한 부분만 확장하는 방향이 제안되었습니다.
• 프로젝트 타겟이나 의존성 선언이 반복되는 부분을 함수화해서 줄이자는 아이디어도 나왔습니다.
• 새 프로젝트 생성 시 폴더와 파일을 반복해서 만드는 과정이 번거로우니, 이를 자동화하는 명령어나 스크립트가 있으면 좋겠다는 의견도 있었습니다.
5. struct와 class 사용 기준
• 특별히 참조 타입이 꼭 필요한 경우가 아니라면, class보다 struct를 사용하는 쪽이 더 단순하고 관리하기 좋다는 의견이 나왔습니다.
• 값 타입과 참조 타입의 차이에 대한 설명도 함께 오갔습니다.
액션 아이템
• 로거를 프로토콜 기반으로 정리해, 내부 구현을 바꾸지 않고도 콘솔 로거/OS 로거 등을 교체할 수 있는 구조를 시도해보기
• 에러 처리 구조를 정리해서 중복된 catch와 로깅 패턴을 줄이기
• 프로젝트 생성 시 폴더/파일 세팅을 자동화하는 방법 검토하기
• 기존 로깅 방식들을 비교해 보고, 하나로 정리할 수 있는지 검토하기
아직 남은 질문
• OSLog까지 고려했을 때, 현재의 로거 프로토콜 추상화 수준이 적절한가?
• 에러별 catch를 분리하는 것이 더 나은지, 가능한 범위에서 통합하는 것이 더 나은지?
• 공통 모듈을 어디까지 일반화해야 중복은 줄이면서도 복잡도는 높아지지 않을까?