five weeks

네이버 부스트캠프 10기 웹 모바일 베이직 후기

five weeks — Fri, 11 Jul 2025 13:24:52 +0900

지원 배경

회사의 경영이 악화되어 퇴사를 결정하게 되었고, 이후 진로를 다시 설계하면서 여러 가능성을 열어두고 있었습니다. 그중 하나가 평소 관심 있었던 부트캠프를 통해 실력을 더 키우는 것이었습니다.

사실 2023년에 삼성청년SW아카데미(SSAFY) 모바일반을 이수한 경험이 있었는데, 그 과정에 매우 만족했기 때문에, 다른 부트캠프에도 도전해 보고 싶다는 생각을 가지고 있었습니다.

마침 퇴사를 준비하던 시기에 네이버 부스트캠프 모집 공고를 보게 되었고, 자연스럽게 지원하게 되었습니다.

지원서 작성

지원서를 작성할 때 가장 중요하게 생각한 것은 진정성이었습니다.
기업에 제출하는 자기소개서처럼 포장하거나 꾸미기보다는, 왜 이 부트캠프에 지원하게 되었는지, 어떤 마음으로 임하려 하는지를 솔직하게 적었습니다.

저 같은 경우에는 원래 안드로이드 개발을 주로 공부했었는데 웹 풀스택에 대한 흥미가 생겨서 해당 부분을 공부하고 싶은 마음을 그대로 적었습니다.

문제 해결력 테스트 준비

저는 Java와 Kotlin을 주로 사용해 왔기 때문에 JavaScript는 다소 낯선 언어였습니다. 하지만 베이직 과정은 웹 풀스택 개발에 필요한 기초 개념과 실습을 차근차근 익힐 수 있도록 잘 구성되어 있어서, 진행하면서 문제 해결력 테스트에 필요한 수준까지 자연스럽게 학습할 수 있었습니다. 따라서 전공자라면 JavaScript를 처음 접하더라도 웹 풀스택 과정에 큰 부담 없이 지원하셔도 괜찮을 것 같다는 생각이 들었습니다.

또한 저는 퇴사 직후라 조금 지친 상태였고, 다른 분들처럼 미리 JavaScript를 공부하거나 문제해결력 테스트를 준비하진 못했습니다. 그럼에도 불구하고 베이직 과정의 과제들을 꾸준히 따라가다 보니 필요한 지식을 충분히 쌓을 수 있었고, 그 덕분에 문제 해결력 테스트도 무사히 통과할 수 있었습니다.

베이직(2주)의 학습 과정

베이직 캠프는 약 2주간 진행되며, 매일 주어지는 미션을 수행하고, 그 결과로 코드와 Readme를 제출하는 방식으로 운영됩니다.
이 과정은 기초 개념을 처음부터 알려주는 형태가 아니라, 목표가 주어지면 스스로 학습하고 해결해 나가는 구조로 진행됩니다.
공부의 양이나 깊이도 정해진 기준이 있는 것이 아니라, 각자가 스스로 계획하고 실천하는 자율적인 방식입니다.

저는 이전에 SSAFY 모바일 과정을 수료한 경험이 있었는데, 그 과정은 강사님이 계시고 커리큘럼이 체계적으로 구성되어 있어서, 대학에서 배운 전공 지식을 빠르게 복습하는 데 큰 도움이 되었습니다.
그에 비해 베이직은 스스로 목표를 설정하고 주도적으로 학습하는 스타일이었고, 두 과정은 학습 방식이 매우 다르면서도 각자의 장점이 뚜렷해 서로 보완되는 경험이었습니다.

또한, 리뷰를 위해 다른 수강생들의 결과물을 꼭 확인해야 하는 구조입니다.
처음에는 뛰어난 분들이 많아 자연스럽게 비교하게 되지만, 리뷰 과정 자체가 하나의 학습 과정이라고 생각합니다.
많은 input 없이 좋은 output을 만들어낼 수는 없다고 생각하기 때문에, 저는 좋은 코드나 구현 방식이 보이면 따로 메모해 두었다가 제 과제에 적용해 보았습니다.

특히 저는 JavaScript에 익숙하지 않았던 터라, 이 과정을 통해 JS 문법과 활용에 대해 실질적으로 많이 익힐 수 있었고, 짧은 시간 안에 언어에 대한 감을 익힐 수 있었습니다.

학습 방법 팁

아래는 제가 베이직 과정을 진행하며 느낀 학습 팁들입니다.

모두 완벽히 지킨 것은 아니지만, 지킨다면 확실히 도움이 될 만한 방법이라 생각되어 정리해 봅니다.

1. 그날 과제는 그날 하기

과제를 미루기 시작하면, 나중에는 시간에 쫓겨 제대로 학습하기 어려워집니다.

매일 주어진 과제를 그날그날 수행하면, 하나의 주제에 더 깊이 몰입할 수 있고, 지속적인 리듬을 유지할 수 있습니다.

2. 다른 사람 코드 많이 보기

다른 사람의 코드를 읽는 만큼 성장할 수 있다는 걸 절실히 느꼈습니다.

내 코드만 보지 말고, 다양한 방식의 접근과 구현을 보며 아이디어를 얻고, 그중 좋은 부분은 내 방식으로 소화해보는 연습이 중요합니다.

베이직 과정에서 배운 점

무언가를 처음 시작할 때는 못하는 게 당연하다고 생각합니다. 예를 들어 Kotlin으로는 어느 정도 익숙하게 구현할 수 있지만, JavaScript는 처음이라 어렵게 느껴졌습니다. 이처럼 익숙하지 않은 언어나 환경에서 어려움을 겪는 건 자연스러운 일이고, 못한다는 사실을 받아들이고, 그 상태를 견디는 과정이 결국 잘하게 되는 길이라고 믿습니다. 중요한 것은 포기하지 않고 요구사항을 끝까지 구현하려는 자세, 그리고 그 과정을 통해 배우고 익히려는 태도라는 사실을 다시 알 수 있었습니다.

베이직에서 어떤점을 배우는지 잘 모르고 시작하게 되어 베이직 학습 목표를 적는 칸에 웹 풀스택에 대한 학습이라고 적어뒀었습니다. 하지만 해당 관련 과제는 아니었습니다. 베이직은 CS 관련 과제가 나오고 해당 부분을 구현하면서 학습하는 내용이었습니다.

회사를 다니면서 지쳐서 중간에 포기할 줄 알았는데 열심히 하는 분들이 많아서 저도 영향을 받아 덩달아 열심히 한 것 같습니다. 챌린지 과정도 성실하게 할 수 있도록 노력하겠습니다.

데이터베이스(Database) 개념 정리

five weeks — Wed, 28 May 2025 14:48:10 +0900

1. 데이터베이스란?

여러 사람들이 다양한 방식으로 데이터를 저장, 검색, 수정할 수 있도록 구조화된 데이터의 집합
앱 또는 시스템에서 데이터를 구조화하고 효율적으로 다루기 위한 도구

사용 예시

사용자 로그인 정보 저장 (이메일/비밀번호)

최근 사용 내역 조회

오프라인 상태에서도 앱 작동 (ex. 메모 앱, 캘린더)

2. DBMS (Database Management System)

데이터베이스를 쉽게 사용할 수 있도록 해주는 소프트웨어

주요 역할

데이터를 파일이 아닌 논리적으로 관리 (인덱스, 트랜잭션, 동시성 제어 등)

SQL을 통해 데이터 처리

대표 DBMS

분류	예시
관계형 (RDB)	MySQL, PostgreSQL, Oracle
비관계형 (NoSQL)	MongoDB, Firebase, Redis
로컬 DB	SQLite, Room

3. SQL (Structured Query Language)

데이터베이스에 명령을 내리는 표준 언어

SELECT * FROM users WHERE age > 20;
INSERT INTO users (name, age) VALUES ('Anna', 25);
UPDATE users SET age = 26 WHERE name = 'Anna';
DELETE FROM users WHERE age < 18;

연산 종류

연산	주의할 점
SELECT (조회)	인덱스가 없으면 느려짐 → WHERE 조건에 인덱싱 필요
INSERT (삽입)	UNIQUE 제약조건 충돌 주의. 대량 삽입 시 배치 처리 고려
UPDATE (수정)	WHERE 누락 시 전체 수정됨 → 항상 조건문 확인
DELETE (삭제)	트랜잭션 사용 필수. 외래키 제약이 있다면 제약 해제 순서 확인

4. 관계형 데이터베이스 (RDB: Relational Database)

핵심 개념

데이터를 테이블 단위로 저장 (엑셀처럼 행과 열)

테이블 간 관계 설정 가능 (Join)

JOIN이 많아질수록 성능 이슈 발생 가능 → 인덱스 튜닝 필수

엄격한 스키마 구조 → 데이터 간 관계가 명확한 경우 추천

트랜잭션 처리로 데이터 정합성을 보장할 수 있어 업무 로직에 신뢰성 요구될 때 적합

주요 용어

용어	설명
테이블	데이터 저장 단위
행(Row)	레코드, 데이터 한 건
열(Column)	속성 (이름, 나이 등)
기본키(PK)	각 행을 유일하게 식별
외래키(FK)	다른 테이블과의 관계를 나타냄
스키마	테이블 구조 정의

5. 키(Key)의 종류

키 종류	설명
슈퍼 키(Super Key)	유일성만 만족
후보 키(Candidate Key)	슈퍼 키 중 최소성도 만족
기본 키(Primary Key)	후보 키 중 하나 선택 (NOT NULL + UNIQUE)
대체 키(Alternate Key)	후보 키 중 기본 키 제외한 나머지
외래 키(Foreign Key)	다른 테이블의 기본 키를 참조

6. 정규화(Normalization)

중복 제거 및 데이터 무결성을 위해 테이블을 구조적으로 나누는 과정

정규화는 중복 제거와 무결성 확보에 효과적

하지만 과도한 정규화 → JOIN 남발 → 성능 저하

실무에서는 3NF 또는 BCNF까지만 적용하고, 필요한 경우 비정규화로 속도 최적화

정규형	설명
제1정규형 (1NF)	컬럼이 원자값(단일값)만 가지도록 분리 (중첩/반복되는 컬럼 제거)
제2정규형 (2NF)	제1정규형 만족 + 기본키의 일부에만 종속된 컬럼 제거 (부분 종속 제거)
제3정규형 (3NF)	제2정규형 만족 + 이행적 종속 제거 (비기본키 → 다른 비기본키 종속 제거)
BCNF (보이스-코드 정규형)	제3정규형 만족 + 모든 결정자가 후보키일 것 (후보키 아닌 컬럼이 결정자면 분해)
제4정규형 (4NF)	BCNF 만족 + 다치 종속 제거 (하나의 키가 여러 독립적인 다중값을 가질 때 분리)
제5정규형 (5NF)	제4정규형 만족 + 조인 종속 제거 (조인 후에도 정보 손실 없이 복원 가능하게 분해)

용어 정리

부분 종속: 기본키의 일부에만 종속됨

이행적 종속: A → B, B → C이면 A → C가 되는 관계

결정자: 다른 값을 결정하는 컬럼 (예: 학번 → 이름)

다치 종속: 하나의 속성이 여러 개의 독립된 값을 가짐

조인 종속: 테이블을 조인했을 때만 의미가 있는 종속 관계

7. 트랜잭션과 ACID

트랜잭션: 데이터베이스 작업의 논리적 단위

ACID 4원칙

항목	설명
원자성(Atomicity)	전부 실행되거나 전부 취소됨
일관성(Consistency)	무결한 상태 유지
고립성(Isolation)	동시에 실행돼도 서로 영향 없음
지속성(Durability)	커밋된 내용은 영구 저장됨

8. 인덱스(Index)

데이터를 빠르게 찾기 위한 자료 구조 (책의 목차 역할)

항목	실무 팁
WHERE 조건	자주 사용하는 컬럼에 인덱스 생성
정렬(SORT)	ORDER BY 대상에도 인덱스 고려
JOIN	조인 대상 컬럼 인덱스 필수
INSERT/UPDATE	인덱스 많을수록 느려짐 → 쓰기 빈번한 테이블은 인덱스 최소화

장점

검색 속도 향상

정렬 빠름

유니크 제약 조건으로 데이터 무결성 강화

단점

인덱스 생성/유지 비용

INSERT/UPDATE 성능 저하

9. 이상 현상(Anomaly)

테이블 구조가 비정상적일 때 생기는 문제

유형	설명
삽입 이상	일부 정보 없으면 삽입 안 됨
삭제 이상	하나 지우면 관련 정보도 삭제됨
갱신 이상	일부만 수정돼 정보 모순 발생

10. ERD (Entity Relationship Diagram)

시스템에서 사용하는 개체(엔티티)와 그 관계를 도식화한 데이터베이스 설계도

주요 개념

엔티티(Entity): 테이블에 대응 (예: User)

속성(Attribute): 테이블의 열

관계(Relationship): 엔티티 간의 연결

관계 유형

기준	관계
외래 키 위치	식별자 관계 vs 비식별자 관계
발생 횟수	1:1, 1:N, N:N

11. NoSQL (Not Only SQL, 비관계형 데이터베이스)

유연한 구조, 대규모 확장을 위해 등장한 비관계형 데이터베이스

등장 배경

스키마 변경 어려움, JOIN 많은 관계형 DB의 한계

트래픽 많고 유연성 필요한 서비스 (SNS, IoT 등)

사용 조건

사용 조건	설명
스키마 자주 변경됨	문서 기반(JSON)은 구조 자유로움
수평 확장 필요	서버 수 늘리기 쉬움 (샤딩 지원)
고속 읽기/쓰기	단순 key-value 조회 성능 우수
관계 표현이 불필요	조인이 거의 필요 없는 데이터

주요 유형

유형	설명	예시
Document	JSON 문서 기반	MongoDB, Firebase
Key-Value	키-값 쌍	Redis, DynamoDB
Column	열 단위 저장	Cassandra
Graph	노드-엣지 기반	Neo4j

12. MongoDB 특징 (Document DB)

JSON 형태로 저장 (유연한 스키마)

Collection 단위로 관리 (테이블 개념)

샤딩(Sharding), 복제(Replication), 트랜잭션 지원

{
  "name": "Anna",
  "age": 25,
  "tags": ["developer", "blogger"]
}

13. RDB vs NoSQL 선택 기준 요약

항목	RDB	NoSQL
구조	테이블, 고정된 스키마	JSON, 유연한 스키마
트랜잭션	ACID 강력 지원	약함 또는 제한적
JOIN	가능	불가 또는 복잡
확장성	수직 확장	수평 확장 유리
사용 예	금융, ERP	SNS, 로그, IoT

14. 로컬 데이터베이스

로컬 데이터베이스란 네트워크 없이도 디바이스 내부에 데이터를 저장하고 조회할 수 있는 데이터베이스를 의미합니다. 서버와 통신하지 않아도 사용할 수 있어 오프라인 환경에서도 작동 가능합니다.

사용 조건

상황	설명
오프라인 데이터 저장	일정, 메모, 투두리스트, 기사 등
서버와 주기적 동기화	서버 연동 전 임시 저장
빠른 UI 표시용 캐시	검색 결과, 최근 본 항목 등

특징

디바이스 내 저장: 스마트폰, 태블릿, PC 등의 내부 저장소에 위치

빠른 접근 속도: 네트워크 지연 없이 즉시 데이터에 접근 가능

오프라인 지원: 인터넷 연결 없이도 데이터 조회/수정 가능

보안 이슈: 디바이스 분실 시 보안 문제 발생 가능 (암호화 필요)

플랫폼	로컬 데이터베이스 예시	설명
Android	SQLite, Room (SQLite 기반 ORM)	안드로이드 기본 DB, Room은 SQLite를 추상화해 사용 편리
iOS	Core Data, SQLite	애플의 객체 기반 저장소(Core Data), 또는 SQLite
Web	IndexedDB, LocalStorage	브라우저에서 클라이언트 데이터 저장 시 사용
Cross-platform	Realm, ObjectBox, Hive	플랫폼 독립적이며 사용이 쉬움 (특히 Flutter 등에서 인기)

1편: 블루투스란 무엇인가

five weeks — Mon, 26 May 2025 14:10:22 +0900

문제 상황

저는 블루투스 기술을 매일 쓰고 있지만, 블루투스가 정확히 뭔지, 어떻게 동작하는지 자세히 설명하려고 하면 막연해지는 경우가 많습니다.

1년 넘게 블루투스 디바이스를 활용한 서비스를 개발하면서 늘 "언젠가는 제대로 정리해야지"라는 생각을 가지고 있었습니다.

지금 회사를 다니면서 학습한 블루투스에 대해서 이번 기회에 블루투스의 개념부터 동작 원리, 종류까지 개발자 입장에서 알아야 할 내용을 정리해보려 합니다.

블루투스의 정의

블루투스(Bluetooth)는 짧은 거리에서 데이터를 주고받기 위한 무선 통신 기술입니다.

대표적인 특징은 다음과 같습니다

근거리 전용: 보통 10m 내외의 거리에서만 연결 가능
저전력: 배터리를 적게 소모하는 구조
간편한 연결: 페어링만 되면 자동 연결 지원

그래서 블루투스는 스마트워치, 체중계, 차량, 이어폰 같은 소형 저전력 기기들과의 통신에 최적화돼 있습니다.

블루투스의 역사

블루투스는 꽤 오래된 기술입니다. 기본 개념은 90년대 후반에 등장했습니다.

1998년, 블루투스 기술을 표준화하기 위해 Bluetooth SIG(Special Interest Group)라는 단체가 결성되었습니다. 지금도 이 단체가 표준을 관리합니다.

왜 하필 이름이 '블루투스'일까?이 왕은 서로 다른 부족을 하나로 통합한 통치자였는데, 블루투스 기술도 다양한 기기를 하나로 연결해주는 역할을 하기 때문에 그 상징성에서 이름을 따왔다는 이야기가 있습니다.
이름은 10세기 덴마크의 왕 하랄드 블루투스(Harald Bluetooth)에서 따왔습니다.
버전의 발전 흐름
- Bluetooth 1.0 (1999): 낮은 데이터 전송률 (~721 kbps), 불안정한 연결
- Bluetooth 2.0 + EDR: 전송 속도 증가 (~2.1 Mbps)
- Bluetooth 3.0 + HS: 고속 전송을 위해 Wi-Fi(802.11) 채널을 활용. 블루투스는 연결 제어용으로만 사용되며, 실제 데이터는 Wi-Fi로 전송 (~24 Mbps).
- Bluetooth 4.0 / 4.2: BLE(Bluetooth Low Energy) 등장, 저전력 기기 지원
- Bluetooth 5.0 / 5.2: BLE 범위 확대, 속도 향상, 2Mbps 전송, 멀티 디바이스 브로드캐스트

블루투스 이해를 위한 개념 정리

1. 주파수 대역이란?

블루투스는 2.4GHz ISM 대역(산업·과학·의료용)을 사용합니다.
이 대역은 전 세계적으로 면허 없이 사용할 수 있도록 지정된 비면허 주파수 대역으로, 산업, 과학, 의료 기기뿐만 아니라 소형 무선 기기들에 널리 쓰입니다.
이 주파수는 Wi-Fi, 전자레인지 등도 같이 쓰기 때문에 간섭이 발생하기도 합니다.

2. 2.4GHz이란?

2.4기가헤르츠(Gigahertz)는 전파의 주파수 단위입니다.
1GHz는 10억 헤르츠(1초에 10억 번 진동)이고, 2.4GHz는 1초에 24억 번 전파가 진동한다는 뜻입니다.
쉽게 말해, 무선 신호가 초당 24억 번 진동하는 주파수를 의미합니다.

3. ISM이란?

Industrial, Scientific, and Medical의 약자입니다.
산업용, 과학용, 의료용 등 비통신 목적으로도 사용되는 주파수 대역이에요.
이 대역은 면허 없이 자유롭게 쓸 수 있는 비면허 대역으로 지정돼 있어서, 여러 무선 기기가 자유롭게 공유해서 사용합니다.

4. 면허 주파수 대역(Licensed Frequency Bands)이란?

특정 사용자만 사용할 수 있도록 정부나 관련 기관에서 허가(면허)를 내주는 주파수 대역입니다.
주로 통신사, 방송국, 군사, 항공, 위성 통신 등 중요하고 간섭이 없어야 하는 서비스에 할당됩니다.
면허가 있기 때문에, 해당 주파수를 독점하거나 제한된 환경에서 안정적으로 사용할 수 있습니다.
예를 들어, 한국에서는 과학기술정보통신부에서 면허 주파수를 관리합니다.

5. 비면허 주파수 대역(Unlicensed Frequency Bands)이란?

누구나 허가 없이 자유롭게 사용할 수 있는 주파수 대역을 말합니다.
별도의 면허 없이도 무선 장치가 사용할 수 있기 때문에, 와이파이, 블루투스, 무선 키보드·마우스 등 다양한 기기에 활용됩니다.
여러 기기가 동시에 같은 대역을 사용하기 때문에 간섭이 발생할 수 있고, 통신 품질이 떨어질 위험도 존재합니다.
이런 특성 때문에 보통 저전력, 짧은 거리 통신에 적합합니다.

6. MAC 주소란?

각 블루투스 장비는 고유한 MAC 주소를 갖고 있습니다.

MAC 주소(Media Access Control Address)는 네트워크 장치(블루투스, 와이파이 등)에 부여되는 고유 식별자입니다. 보통 6바이트(48비트) 크기이고, 16진수로 표기됩니다

00:1A:7D:DA:71:13

Mac 주소 사용처
- BLE 스캔을 하면 주변의 블루투스 장비들이 탐지되는데, 이때 MAC 주소(Public Address 또는 Random Address)가 함께 포함되어 제공됩니다.
- 어떤 장치가 어떤 MAC 주소를 가졌는지 알 수 있기 때문에, 특정 장치만 골라서 연결하거나, 원하는 장치만 필터링해서 처리할 수 있어요.
- 또한, 한 번 페어링한 기기와 재연결할 때도 MAC 주소가 사용돼요. (단, BLE는 대부분 비페어링 상태로도 통신 가능하며, 일반적으로는 디바이스 식별용으로 주로 사용됨)
실제 앱 개발의 경우
- Android에서는 OS 버전에 따라 BLE 스캔 시 제공되는 MAC 주소가 제한될 수 있습니다.
  - Android 6.0 (API 23) 이후부터는 위치 권한을 허용하지 않으면 블루투스 기기가 스캔되지 않습니다.
  - Android 10 (API 29) 이후부터는 getAddress()를 통한 MAC 주소 접근이 제한되며, 대신 BluetoothDevice.getAddress()가 “00:00:00:00:00:00”을 반환하는 경우도 있습니다.
- iOS에서는 BLE 스캔 결과에 MAC 주소가 포함되지 않기 때문에, MAC 주소 대신 식별이 필요할 경우 Advertisement Data의 Manufacturer Data나 Custom Service UUID 등을 활용해야 합니다.

7. 프로파일(Profile)이란?

블루투스에서는 “이 기기를 어떤 용도로 사용할 것인가?”를 정리해둔 일종의 표준 통신 형식을 프로파일이라고 합니다.

블루투스 동작 방식

1. 페어링(Pairing)

블루투스를 처음 연결할 때, 두 기기는 암호화 키를 교환합니다.

이 과정을 페어링이라고 하고, 한 번 페어링되면 자동 재연결이 가능합니다. BLE에서는 보안 수준을 선택할 수 있으며, 보통 'Just Works', 'Passkey Entry', 'Numeric Comparison' 같은 방식이 있습니다.

Just Works: 사용자가 입력 없이 자동으로 연결됨. 사용자 편의는 좋지만 보안 수준은 낮음.
Passkey Entry: 한 쪽에 표시된 6자리 숫자를 다른 쪽에 입력. 보안 수준이 높음.
Numeric Comparison: 양쪽 디바이스에 같은 숫자가 표시되며, 사용자 확인을 통해 페어링.

BLE는 기본적인 데이터 송수신에는 페어링이 필요 없지만, 민감한 데이터 전송이나 보안이 필요한 경우에는 페어링을 통해 암호화 키를 교환해야 합니다.

페어링과 기기 연결은 다른 개념으로 “페어링”은 보안 키 교환을 위한 절차, “연결”은 실제 데이터 송수신 가능 상태로 만드는 것입니다.

2. 페어링 이후의 흐름

Central(앱)이 주변 BLE 기기를 스캔합니다.
Peripheral(디바이스)와 연결 시도합니다.
연결 성공 시 서비스/캐릭터리스틱 탐색합니다.
데이터 주고받기 (Read/Write/Notify)

블루투스의 구조

블루투스는 기본적으로 Master/Slave 구조에서 시작했습니다. 각각 통신을 주도하는 쪽과 수신하는 쪽이라는 의미로, 스마트폰과 이어폰 같은 관계입니다.

요즘 BLE에서는 이 구분이 Central/Peripheral로 바뀌었고, Central이 연결을 주도하고 Peripheral이 데이터를 제공합니다. Master/Slave는 기술적인 용어지만, 사회적 맥락에서는 인종차별적 역사를 연상시킬 수 있어서 블루투스 SIG를 비롯해 여러 기술 커뮤니티(예: Python, GitHub 등)에서 표현을 더 중립적으로 바꾸는 움직임이 있었습니다. 깃허브에서도 주 브랜치 이름이 Master에서 Main으로 바뀌었습니다.

출처

https://www.bluetooth.com/learn-about-bluetooth/tech-overview/

Bluetooth Technology Overview | Bluetooth® Technology Website

Learn About Bluetooth One key reason for the incredible success of Bluetooth® technology is the tremendous flexibility it provides developers. Offering two radio options…

www.bluetooth.com

https://developer.android.com/develop/connectivity/bluetooth?hl=ko

블루투스 개요 | Connectivity | Android Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. 블루투스 개요 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. Android 플랫폼에는 블루투스 네트워크

developer.android.com

HTTP FAILED: java.net.SocketTimeoutException: timeout 문제 해결법

five weeks — Thu, 24 Apr 2025 11:19:30 +0900

문제 상황

회사에서 운영하던 서비스가 데이터가 많이 쌓여서 api return까지 걸리는 시간이 10초를 넘으면서 사용 기록이 많은 사용자들에게 앱에서 연속적으로 timeOut이 발생했습니다. 현재 상황에서 조회에 소요되는 시간은 30초 전후이고, DB 개선이 필요하지만 동시에 timeOut 제한 시간도 수정을 해야할 것 같습니다.

타임 아웃의 종류

설정할 수 있는 값의 범위는부터 0 부터 Integer.MAX_VALUE까지이며, 단위는 밀리초(ms)입니다.

0은 제한 없음(no timeout)을 의미합니다.

타임아웃 종류

SocketTimeOutException이 발생할 수 있는 상황

1. 서버 응답 지연

서버가 내부적으로 오래 걸리는 작업을 처리 중일 수 있습니다 (예: 데이터베이스 작업, 외부 API 호출).
이 경우에는 readTimeout에 걸려서 타임아웃 발생합니다.
저는 이 경우에 해당합니다.

예시: 서버 응답에 28초 소요, readTimeout이 기본 10초 → SocketTimeoutException

2. 네트워크 품질 불량 또는 끊김

사용자의 네트워크 상태가 불안정할 경우입니다.
- 패킷 손실 (packet loss)
- 지연 (latency)
- DNS 지연 또는 실패

예시: 지하철에서 약한 LTE 신호로 요청 보냈을 때 응답이 안 오고 timeout 발생

3. 서버가 다운되었거나 연결 자체가 안 되는 경우

이건 보통 connectTimeout에 해당합니다.
서버가 아예 꺼져 있거나 IP/포트가 잘못되어 연결을 못 하면 타임아웃아 발생합니다.

예시: 잘못된 서버 주소를 넣었거나, 서버가 꺼져 있음 → 연결 자체가 실패

4. 프록시, 방화벽, VPN 등의 중간 장비가 연결을 방해

회사 네트워크나 공공 와이파이에서 종종 발생합니다.
클라이언트와 서버 사이에 중간 네트워크 장비가 연결을 막거나, 요청을 느리게 처리합니다.

예시: 프록시 서버가 서버 응답을 받아도 클라이언트로 전달 안 해주는 경우

타임아웃 제한 수정 방법

okhttpClient에 아래와 같이 적용했습니다.

val okhttpClient = OkHttpClient.Builder()
  .connectTimeout(30, TimeUnit.SECONDS)
  .readTimeout(30, TimeUnit.SECONDS)
  .writeTimeout(30, TimeUnit.SECONDS)
  .callTimeout(60, TimeUnit.SECONDS)
.build()

안드로이드 앱의 기본 빌드 타입을 Release로 변경하는 방법

five weeks — Tue, 22 Apr 2025 14:59:01 +0900

문제 상황

버전 업데이트를 할 때, 실제 상황과 동일하게 테스트를 하고 싶을 때가 있습니다.

하지만 안드로이드 스튜디오에서 앱을 실행하거나 빌드하면, 기본적으로 debug 빌드 타입으로 앱이 빌드됩니다.

실제 서비스와 동일한 환경에서 테스트하거나, 디버깅 로그 없이 앱을 실행하고 싶을 때는 release 빌드로 앱을 실행하고 싶은 경우에는 빌드 세팅을 바꿔야합니다.

안드로이드 스튜디오는 기본적으로 debug를 기본 빌드 타입으로 인식하며, 실행(Run) 버튼을 눌러도 항상 debug 빌드가 실행됩니다.

그래서 다음과 같은 상황이 발생할 수 있습니다

디버그 로그가 포함된 상태로 테스트됨
난독화(ProGuard)가 적용되지 않음
최적화되지 않은 상태로 앱이 동작
릴리즈 빌드에서 발생하는 버그를 사전에 확인할 수 없음

이런 문제를 해결하기 위해, 기본 빌드 타입을 release로 변경하고 앱을 실행하는 방법을 알아보겠습니다.

1. 빌드 타입(Build Type)이란?

Build Type은 안드로이드 앱을 빌드할 때, 빌드 설정을 구분하는 단위입니다. 대표적으로 debug와 release 두 가지가 기본으로 존재합니다.

빌드 타입 설명

debug	개발 중 디버깅에 최적화된 빌드디버그 로그 출력, 프로가드 미적용, 서명 생략
release	사용자에게 배포 가능한 최종 앱 빌드로그 제거, 코드 난독화, 최적화, 서명 필요

각 빌드 타입은 build.gradle의 buildTypes 블록 안에서 설정할 수 있습니다:

buildTypes {
    release {
        isMinifyEnabled = true
        versionNameSuffix = ""
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
        signingConfig = signingConfigs.getByName("release")
    }

    debug {
        isMinifyEnabled = true
        versionNameSuffix = ".debug"
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro",
        )
    }
}

2. 기본 빌드 타입을 Release로 변경하는 방법

안드로이드 스튜디오에서 실행(Run) 시 자동으로 release 빌드가 실행되도록 설정하려면 아래 방법 중 하나를 선택하면 됩니다.

✅ 방법 0. signingkey 발급(signingkey가 있다면 생략 가능)

상단 메뉴에서 Build > Generate Signed Bundle / APK.. 선택
Android App Bundle 옵션 선택 후 Next
Create new .. 선택 후 Key 정보 입력 후 생성

파일 경로와 Alias, Password은 이후 모드 설정에 필요합니다.

✅ 방법 1. Release 모드 설정 생성

상단 메뉴에서 Run > Edit Configurations 클릭
앱 모듈의 설정에서 Signing Configs를 선택
release 가 없다면 +버튼을 눌러서 생성
SigningKey를 생성했을 때, 키 정보를 입력 및 저장
해당 과정을 거치면 build.gradle에 release 빌드를 위한 설정이 적용

build.gradle이 변경되는 과정에서 원래 build.gradle의 일부 코드가 소실될 수 있습니다.

✅ 방법 2. Run/Debug Configuration 설정 변경

Shift를 두번 눌러서 build variants를 검색하거나 오른쪽 하단의 build variants 탭을 눌러서 접근 가능
Build Variants에서 release 모드로 변경

단, release 빌드는 signingConfig 설정이 필요하며 서명이 없으면 실행이 안 될 수 있습니다.

✅ 방법 2-1. build.gradle에서 기본 빌드 Variant 설정 (Gradle Task 용도)

빌드 자동화 목적으로 사용할 경우, Gradle 명령어를 통해 release 빌드를 직접 실행할 수도 있습니다.

./gradlew assembleRelease

혹은 APK 설치까지 진행하고 싶다면 다음의 방식을 사용할 수 있습니다.

./gradlew installRelease

⚠️ 주의 사항

위의 문제가 발생한다면 하단과 같이 release 안에 signingConfig 설정 코드를 넣어줘야합니다.
release 빌드는 반드시 서명 설정이 필요합니다 (signingConfigs 설정 누락 시 빌드 실패)
디버깅이 제한되므로, 디버깅이 필요한 경우에는 debuggable true 설정을 임시로 추가할 수 있습니다 (단 보안상 권장되지 않음)

buildTypes {
    release {
    	...
        signingConfig = signingConfigs.getByName("release")
    }
}

baseUrl 설정 과정에서 일부 경로가 호출 URL에 반영되지 않는 문제

five weeks — Fri, 18 Apr 2025 17:13:09 +0900

문제 상황

이번에 서버 이전을 하면서 레거시 코드를 고치게 되었는데, 도메인 및 기타 하위 경로가 변경되었습니다. baseUrl을 변경한 후, 일부 경로가 호출 URL에 반영되지 않는 문제가 있어서, 정리해봤습니다.

원래 baseUrl에는 도메인 주소까지만 작성되어있었습니다. 하지만 한 앱에서 하위 경로도 모두 동일하게 사용하는 부분이 있어서 해당 부분까지 포함해서 BaseUrl에 넣어뒀습니다.

예를 들면 https://like.while.android/api/v1/ 와 같은 형식으로 입력했습니다.

baseUrl을 https://like.while.android/api/v1/로 설정했는데도, 실제 API 호출 시 /api/v1/가 생략되었습니다.

이유는 interface의 endpoint path 설정에서 @GET, @POST 등에 슬래시(/)로 시작되는 절대 경로를 사용했기 때문이었습니다.

interface ApiService {
    @GET("/users") // ← 슬래시로 시작 → baseUrl 무시하고 절대 경로
    suspend fun getUsers(): Response<List<User>>
}

이 경우, https://like.while.android/users 로 호출되었습니다.

즉, baseUrl에 포함했던 /api/v1/ 경로가 무시된 채 API가 호출되었습니다.

해결 방법

@GET이나 @POST 등에서 절대 경로가 아닌 상대 경로로 설정해야합니다.

interface ApiService {
    @GET("users") // ← 슬래시 없음 → baseUrl 뒤에 붙음
    suspend fun getUsers(): Response<List<User>>
}

그러면 최종 URL은 이 경우, https://app.nueyne.dev/api/v1/users 로 호출되었습니다.

✅ 절대 경로 (Absolute Path)

기준(baseUrl)을 무시하고 지정한 경로 그대로 요청하는 방식
경로 앞에 슬래시(/)가 붙어 있음
baseUrl의 경로 부분(/api/v1/ 등)이 무시됨.

@GET("/users")

baseUrl이 https://like.while.android/api/v1/라고 해도, @GET("/users") 처럼 절대 경로를 사용하면 최종 호출 URL은 다음과 같이 됩니다

https://like.while.android/api/v1/

https://like.while.android/users

✅ 상대 경로 (Relative Path)

기준(baseUrl) 에 경로가 이어붙는 방식
슬래시(/) 없이 시작하는 게 특징
baseUrl을 기준으로 경로가 연결됨

@GET("users")

baseUrl이라면 최종 호출 URL은 이렇게 됩니다.

https://like.while.android/api/v1/

https://like.while.android/api/v1/users

정리

@GET("/something") → baseUrl의 path는 무시됨
@GET("something") → baseUrl 뒤에 붙음 (원하는 동작)

절대 경로와 상대 경로의 개념이었습니다. 대학교 때 파일 처리라는 과목을 수강하면서 배웠던 개념이 여기에 적용되어있었던 것입니다.

해당 프로젝트의 baseUrl은 https://1.123.4.567:1234 와 같은 형식으로 입력되어있고, 그 뒤에 @GET("/users") 로 주소를 붙여서 사용하는 방식으로 동작하고 있던 것이 제 변경 후 호출 URL이 이상해진 근본적인 이유였습니다.

그러나 제가 아는 바에 따르면 baseUrl은 /로 끝나지 않으면 오류가 발생하는 것으로 알고 있었습니다.

하지만 이 프로젝트는 baseUrl을 https://1.123.4.567:1234와 같은 형식으로 사용했고, 문제가 발생하지 않았습니다. 이유는 다음과 같습니다.

✅URL의 기본 구조

https://like.while.android:443/api/v1/users?sort=asc#section2

프로토콜 (scheme)	통신 방식	http, https
호스트 (host)	접속할 도메인 이름 또는 IP 주소	like.while.android, 1.123.4.567
포트 (port)	서버와 통신할 때 사용하는 포트 (생략 가능, https는 443)	:443, :8000
패스 (path)	서버 내부에서 요청 자원을 찾기 위한 경로	/api/v1/example
쿼리스트링 (query)	파라미터 전달용	?sort=asc, ?page=1&limit=20
프래그먼트 (fragment)	페이지 내부 특정 위치로 이동 (서버에는 전송되지 않음)	#section2

✅ 핵심 용어 정리

1. 도메인 (Domain)

사람 친화적인 서버 주소입니다.
IP 대신 사용하며, DNS가 이를 IP로 변환해줍니다.
예: google.com, naver.com,like.while.android

2. 호스트 (Host)

네트워크 상의 서버 주소를 의미하며, 도메인이나 IP가 될 수 있어요.
like.while.android → 하위 도메인을 포함한 전체 호스트 이름
http://1.123.4.567:443 에서도 1.123.4.567이 host
Retrofit에서 baseUrl의 호스트는 프로토콜 + 호스트 + 포트까지입니다.

3. 패스 (Path)

서버 안에서 특정 리소스에 접근하기 위한 경로예요.
/api/v1/users 같은 것
파일 시스템처럼 계층적 구조를 가짐
예: /api/v1/ 는 API 버전 구분을 위한 경로

✅ Retrofit에서 baseUrl의 규칙

Retrofit은 내부적으로 HttpUrl (OkHttp의 클래스)을 사용해 URL을 조립합니다. 이때 다음과 같은 규칙이 적용돼요.

baseUrl은 반드시 프로토콜(https://)과 도메인, 그리고 /로 끝나는 path로 설정되어야 합니다.

만약 path가 있다면, 그것도 마지막에 /가 붙어야 합니다.

예를 들어, 다음은 정상적인 baseUrl입니다.

https://like.while.android/         
https://like.while.android/api/
https://like.while.android/api/v1/

반면 다음은 오류 발생합니다 (Retrofit 초기화 시 IllegalArgumentException)

https://like.while.android/api

Retrofit은 baseUrl과 @GET 등에서 정의한 endpoint를 단순 문자열로 이어붙이지 않고, OkHttp의 HttpUrl.Builder를 통해 합성합니다. 이때 baseUrl이 /로 끝나지 않으면 마지막 path segment가 "덮어쓰기" 되기 때문에 의도한 경로와 달라질 수 있다고 합니다.

✅그런데 왜 https://1.123.4.567:1234 는 괜찮았을까?

https://1.123.4.567:1234 는 path가 없는 URL입니다. 즉, 도메인만 있고 경로(path)가 없기 때문에, Retrofit이 내부적으로 자동으로 /를 붙여서 처리합니다.

https://1.123.4.567:1234

위의 url은 실제로는 다음과 동일하게 해석됩니다

http://1.123.4.567:1234

이건 Retrofit 내부에서 OkHttp가 자동으로 처리해주는 부분입니다.

정리2

baseUrl은 경로(path)가 있다면 반드시 /로 끝나야 함
경로가 없는 경우 (host:port만 있는 경우), Retrofit이 자동으로 슬래시를 붙여줌
그래서 https://1.123.4.567:1234는 괜찮았던 것입니다.

결론

자주 사용하는 라이브러리에서 또 새로운 점을 알게 되어서 재밌었습니다.

소프트웨어 정적 분석(Static Analysis)이란?

five weeks — Sun, 8 Sep 2024 10:53:45 +0900

문제 상황

이번에 회사 프로젝트가 출시 준비에 들어가면서 개발 중인 코드를 다른 회사에 정적 분석을 맡기게 되었습니다. 그래서 이번 기회에 정적 분석이 무엇인지, 왜 해야하는지 조사하였습니다.

정적 분석 정의

정적 분석은 소프트웨어 개발 과정에서 소스 코드, 바이너리 코드 또는 애플리케이션을 실행하지 않고 검사하는 기술입니다. 이 분석을 통해 코드에서 안티 패턴, 코딩 오류, 보안 취약점, 스타일 문제 등을 발견할 수 있습니다. 정적 분석 도구는 코드를 논리적으로 분석하고 복잡한 알고리즘을 사용하여 잠재적인 문제점을 식별합니다.

정적 분석 필요성

품질 향상: 개발 초기 단계에서 코드의 버그와 취약점을 식별하여 수정함으로써 소프트웨어의 전반적인 품질을 향상 시킬 수 있습니다. 이는 추후 발생할 수 있는 오류를 미연에 방지하고, 유지 보수 비용을 줄이는 데 도움을 줍니다.
보안 강화: 보안 취약점을 조기에 발견하고 해결함으로써 소프트웨어의 보안 수준을 강화할 수 있습니다. 이는 특히 금융, 의료, 국방 등 보안이 중요한 분야에서 더욱 중요합니다.
표준 준수: 코딩 표준과 컨벤션을 준수함으로써 개발자 간의 코드 이해도를 높이고 협업을 촉진할 수 있습니다. 또한, 특정 산업 표준이나 규제 요구사항을 충족시키기 위해 정적 분석이 필요할 수 있습니다.
개발 효율성 증가: 초기에 문제를 발견하고 수정함으로써 개발 과정에서의 지연을 줄이고, 제품 출시 시간을 단축할 수 있습니다.

사용중인 정적 분석 도구 : ktlint

저희는 현재 ktlint를 사용하고 있습니다. ktlint 도 Kotlin 프로그래밍 언어를 위한 정적 코드 분석 도구입니다. 이 툴은 Kotlin 코드의 스타일과 포맷팅을 체크하여, 코드의 일관성과 가독성을 향상시키는 데 도움을 줍니다. ktlint는 Kotlin 공식 코딩 스타일 가이드를 기반으로 작동하지만, 사용자 정의 규칙을 추가하여 특정 프로젝트나 팀의 요구사항에 맞춰 조정할 수도 있습니다.

주요 특징

스타일 체크: Kotlin의 공식 코딩 스타일을 따르도록 코드를 분석하고, 일관되지 않은 스타일 사용을 지적합니다.
자동 수정: ktlint -F 명령어를 사용하면, 대부분의 스타일 이슈를 자동으로 수정할 수 있습니다. 이는 개발자가 수동으로 코드 스타일 문제를 수정하는 시간을 절약할 수 있게 해줍니다.
플러그인 지원: IntelliJ IDEA와 같은 IDE나, Gradle, Maven과 같은 빌드 도구에 플러그인 형태로 통합할 수 있어, 개발 과정에서 실시간으로 코드 스타일을 검토하고 수정할 수 있습니다.
사용자 정의 규칙: 기본 제공되는 규칙 외에도, 팀의 특정 코딩 규칙을 정의하여 적용할 수 있습니다. 이를 통해 팀 내 코드 스타일의 일관성을 유지할 수 있습니다.

이번에 맞긴 정적 분석 : 스패로우

이번에 스패로우에 코드를 보내서 받은 정적 분석 리포트가 387 페이지였습니다. 초기 정적 분석은 단순히 단어와 문법만 확인했기 때문에 지금보다 오탐지의 확률이 높았다고 한다. 현재는 개선된 버전이라고 하는데, 이번에 정적 분석 리포트에서 hilt에 대한 코드들이 다 매우 위험으로 감지되었다. 해당 라이브러리는 Android Developers에서 추천하는 것이라서 당황스러웠다. 해당 부분이 1000개 정도 감지된 위험 요소의 80% 정도를 차지하고 있었는데, 실제로 보안 위험이 있는지는 좀 더 조사해봐야할 것 같다. 하지만 종종 오탐지가 보인다. 따라서 무조건 신뢰하기 보다는 참고 용도로 사용하는 것이 좋을 것 같다.

참고 링크

https://sparrow.im/kr/product/sast/

Sparrow SAST | 소스코드 취약점 분석 | 시큐어코딩 | 정적 분석

소스코드 취약점을 분석해 해결 방안을 제공하는 정적 분석 도구로 Sparrow SAST를 활용해 소프트웨어 보안약점 진단가이드, 전자금융감독규정 등을 준수하세요.

sparrow.im

https://developer.android.com/training/dependency-injection/hilt-android?hl=ko

Hilt를 사용한 종속 항목 삽입 | Android Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. Hilt를 사용한 종속 항목 삽입 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. Hilt는 프로젝트에서 종속

developer.android.com

Firebase Cloud Messageing 수신 기능 구현(Compose)

five weeks — Wed, 28 Aug 2024 15:45:37 +0900

문제 상황

사용자가 프로모션 알림을 앱을 사용하지 않을 때도 이러한 알림을 받을 수 있어야 합니다.

구현 순서

firebase 프로젝트 생성 및 google-service.json 파일 다운로드
필요한 종속성을 build.gradle에 선언
AndroidManifest에 service 추가
FirebaseMessagingService을 상속 받아서 구현

구현 방법

Firebase Cloud Messaging을 활용하여 앱에서 프로모션 알림을 수신하고 처리하는 구현 방법을 다음 단계별로 설명합니다

1. 프로젝트 설정

google-services.json 파일을 프로젝트에 추가합니다.

필요한 종속성을 build.gradle에 선언합니다.

// app
plugins {
    id("com.google.gms.google-services")
}

dependencies {
    implementation("com.google.firebase:firebase-messaging-ktx")		
}

// project
plugins {
    id("com.google.gms.google-services") version "4.4.0" apply false
}

AndroidManifest.xml에 service를 추가합니다.

<service
    android:name=".data.remote.FcmService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

2. FirebaseMessaging Service

FirebaseMessagingService를 상속 받아서 사용합니다.

onNewToken 메서드가 불리는 경우

앱 설치 시: 사용자가 앱을 처음 설치하고 실행할 때, 새로운 FCM 등록 토큰이 생성되며, 이 때 onNewToken이 호출됩니다.
앱 데이터 삭제 후 재설치 시: 사용자가 앱 데이터를 삭제하거나 앱을 제거했다가 다시 설치하는 경우, 기존의 토큰이 삭제되고 새 토큰이 발급될 때 이 메서드가 실행됩니다.
토큰이 갱신되는 경우: FCM 토큰은 주기적으로 갱신될 수 있습니다. 이는 보안을 유지하기 위해 필요한 절차로, 갱신 주기는 Firebase 서비스에 의해 관리됩니다.
앱의 보안 관련 설정 변경 시: 예를 들어, 사용자가 앱의 인스턴스 ID를 초기화하거나 FCM 관련 정보를 재설정하는 경우, 새로운 토큰이 필요하게 됩니다.
기기 설정 변경 시: 사용자가 Google 계정을 추가하거나 변경하는 등의 기기 설정을 수정할 때, FCM 시스템이 토큰을 새로 발급할 수 있습니다.

@AndroidEntryPoint
class FcmService : FirebaseMessagingService() {
    @Inject
    lateinit var appPreferences: AppPreferences

    override fun onNewToken(token: String) {
        super.onNewToken(token)
        LogUtils.d("new token : $token")
        appPreferences.saveFcmToken(token)
    }
}

3. 알림 메시지 처리

onMessageReceived 메서드를 오버라이드하여 수신된 메시지를 처리합니다.
메세지의 종류는 알림 메세지와 데이터 메세지로 총 두 가지입니다.
알림 메시지가 도착하면 시스템이 자동으로 알림을 생성하여 사용자에게 보여줍니다.
데이터 메시지의 경우, 메시지에 포함된 데이터를 앱에서 직접 처리하고 필요한 작업을 수행합니다.

@AndroidEntryPoint
class FcmService : FirebaseMessagingService() {

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        super.onMessageReceived(remoteMessage)
        LogUtils.d("From: ${remoteMessage.from}")

        // 알림 메시지인 경우
        if (remoteMessage.notification != null) {
            LogUtils.d("Message Notification Body: ${remoteMessage.notification?.body}")
            showNotification(remoteMessage.notification?.title, remoteMessage.notification?.body)
        }
    }

    private fun showNotification(title: String?, body: String?) {
        val notificationManager =
            getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

        val channel = NotificationChannel(
            FCM_NOTIFICATION_NAME,
            "Notification",
            NotificationManager.IMPORTANCE_HIGH
        )
        notificationManager.createNotificationChannel(channel)

        val notificationBuilder = NotificationCompat.Builder(this, FCM_NOTIFICATION_NAME)
            .setContentTitle(title ?: "Promotion Title")
            .setContentText(body ?: "Promotion Message")
            .setSmallIcon(android.R.drawable.ic_dialog_email)
            .setAutoCancel(true)

        notificationManager.notify(FCM_NOTIFICATION_ID, notificationBuilder.build())
    }
}

이러한 단계를 통해, 사용자가 앱을 사용하고 있지 않을 때도 프로모션 알림을 효과적으로 수신하고, 적절히 반응할 수 있도록 하는 시스템을 구축할 수 있습니다.

참고 링크

https://firebase.blog/posts/2023/08/adding-fcm-to-jetpack-compose-app/

The Firebase Blog

News, tutorials, and updates from the Firebase team.

firebase.blog

https://firebase.google.com/docs/cloud-messaging/android/client?hl=ko

Android에서 Firebase 클라우드 메시징 클라이언트 앱 설정

Google I/O 2023에서 Firebase의 주요 소식을 확인하세요. 자세히 알아보기 의견 보내기 Android에서 Firebase 클라우드 메시징 클라이언트 앱 설정 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐

firebase.google.com

안드로이드 앱 난독화 알아보기

five weeks — Sun, 14 Jul 2024 09:46:05 +0900

문제 상황

팀 개발자분이 회사 안드로이드 앱이 난독화가 필요할 것 같다고 하셔서, 준비를 하게 되었습니다. 이전에 했던 개인 프로젝트들을 스토어에 올릴 때, abb 파일을 올리면 Progard 혹은 R8을 사용해서 난독화된 코드를 사용하라는 경고 메세지를 본 적이 있습니다. 이번 기회에 앱 난독화는 왜 해야하는지, 어떻게 하는 것인지 정리하려고 합니다.

난독화

R8 적용 시 장점

축소
- 사용되지 않는 코드를 제거하여 애플리케이션의 크기를 줄입니다. 이는 불필요한 클래스, 메서드, 필드 등을 제거함으로써 가능합니다.
최적화
- 바이트코드를 최적화하여 애플리케이션의 성능을 개선합니다. 불필요한 명령어를 제거하고, 코드의 실행 경로를 최적화합니다.
난독화
- 클래스명, 메서드명, 변수명을 의미 없는 문자열로 변경하여 소스 코드를 읽기 어렵게 만듭니다. 이는 역공학을 어렵게 만들어 코드의 보안을 강화합니다.
사후 검증
- 애플리케이션을 실행하기 전에 바이트코드를 검증하여 런타임 오류를 방지합니다.

R8 적용 시 단점

디버깅의 어려움
- ProGuard가 코드를 난독화하면 메소드 이름과 변수가 변경됩니다. 이로 인해 크래시 로그가 읽기 어려워지고, 문제를 진단하거나 디버깅하는 것이 더 복잡해집니다. 이는 특히 외부 라이브러리나 프레임워크에서 발생하는 문제를 해결할 때 더욱 도전적일 수 있습니다.
설정의 복잡성
- ProGuard를 효과적으로 사용하려면 세심한 설정이 필요합니다. 잘못된 설정은 앱의 정상적인 기능을 방해할 수 있으며, 중요한 클래스나 메소드가 난독화 과정에서 제외되지 않아야 하는 경우 이를 정확히 지정해야 합니다. 설정을 잘못하면 런타임 오류가 발생할 수 있습니다.
빌드 시간 증가
- ProGuard를 프로젝트에 적용하면, 난독화, 최적화, 그리고 축소 과정이 추가되어 앱의 빌드 시간이 길어질 수 있습니다. 이는 개발 과정에서 시간이 더 많이 소요될 수 있음을 의미합니다.

R8 사용법

R8 활성화
- R8은 안드로이드 build.gradle 버전 3.4.0 이상에서 기본적으로 활성화되어 있습니다. 별도로 활성화할 필요는 없으며, build.gradle 파일에 필요한 설정을 추가하면 됩니다.
ProGuard 설정 파일 구성
- ProGuard 설정 파일 (proguard-rules.pro)을 사용하여 R8의 동작을 제어합니다.
- 이 파일에서 난독화, 축소, 최적화와 관련된 규칙을 정의합니다. 예를 들어:
- -keep class com.example.myapp.** { *; } -dontwarn com.example.myapp.**
빌드 파일 설정
- build.gradle 파일에서 릴리즈 빌드 구성에 R8을 사용하도록 설정합니다. R8은 기본적으로 활성화되어 있으므로, ProGuard 파일을 지정하기만 하면 됩니다:
- buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } }
빌드 및 배포
- R8 설정이 완료되면 애플리케이션을 빌드할 때 자동으로 R8이 실행되어 코드가 축소, 최적화 및 난독화됩니다.
- 릴리즈 빌드를 실행하려면 다음 명령어를 사용할 수 있습니다:
- ./gradlew assembleRelease

프로가드 파일 문법

1. 클래스, 메서드 및 필드 유지

특정 클래스, 메서드 또는 필드를 난독화 및 제거하지 않도록 유지할 수 있습니다. 이는 주로 반사(reflection)를 사용하는 경우, 또는 특정 API를 외부에서 호출하는 경우에 필요합니다.

# 모든 공용 클래스와 메서드를 유지합니다.
-keep public class * {
    public *;
}

# 특정 패키지의 모든 클래스와 메서드를 유지합니다.
-keep class com.example.myapp.** { *; }

# 특정 클래스의 이름을 유지합니다.
-keepnames class com.example.myapp.MyClass

2. 경고 무시

ProGuard는 코드 축소 및 최적화 중 경고를 발생시킬 수 있습니다. 이러한 경고를 무시하도록 설정할 수 있습니다.

# 특정 패키지의 경고를 무시합니다.
-dontwarn com.example.myapp.**

3. 코드 축소 방지

특정 클래스나 메서드를 제거하지 않도록 설정할 수 있습니다. 이는 주로 외부 라이브러리와의 호환성을 유지하기 위해 사용됩니다.

# 모든 애노테이션을 유지합니다.
-keep @interface **

# 특정 클래스의 모든 메서드를 유지합니다.
-keepclassmembers class com.example.myapp.MyClass {
    *;
}

4. 라이브러리 모드 설정

ProGuard를 라이브러리 모드로 설정하여, 프로젝트가 아닌 라이브러리의 코드를 난독화할 때 사용할 수 있습니다.

# 라이브러리 모드 활성화합니다.
-libraryjars /path/to/retrofit.jar
-libraryjars /path/to/okhttp.jar

*라이브러리 모드(Library Mode)

ProGuard가 라이브러리 코드를 처리할 때 사용하는 특별한 설정입니다. 이 모드는 라이브러리의 코드가 다른 애플리케이션에 의해 사용될 수 있음을 가정하고, 이를 고려하여 코드 축소 및 난독화를 수행합니다. 즉, 라이브러리 모드는 ProGuard가 "이 코드는 다른 앱에서도 사용될 거야, 중요한 부분은 손대지 말고 잘 보호해줘"라고 인식하게 만드는 설정입니다.

5. 인라인 및 코드 제거 제어

ProGuard가 인라인 및 코드 제거를 수행하는 방식을 제어할 수 있습니다.

# 인라인을 비활성화합니다.
-dontoptimize

*인라인 최적화 (Inlining Optimization)

인라인 최적화는 컴파일러가 성능 향상을 위해 메서드 호출을 메서드의 실제 코드로 대체하는 최적화 기법입니다. 즉, 작은 메서드의 호출을 제거하고 그 메서드의 본문을 호출 지점에 직접 삽입하는 과정입니다. 이를 통해 함수 호출의 오버헤드를 줄이고 실행 속도를 높일 수 있습니다.

즉, 이유가 없다면 그대로 활성화 시켜두면 될 것 같습니다.

만들어본 내 프로가드 설정 파일

# 서버 통신 관련 클래스와 인터페이스를 유지합니다.
-keep class com.example.app.data.model.** { *; }
-keep interface com.example.app.data.remote.ApiService.** { *; }

# 라이브러리와 관련된 클래스와 메서드를 유지합니다.
# Keep Compose runtime Composable functions
-keepclassmembers class * {
    @androidx.compose.runtime.Composable *;
}

-keepclasseswithmembers class * {
    @androidx.compose.runtime.Composable *;
}

# Keep Dagger Hilt classes and annotations
-keep class dagger.hilt.** { *; }

-keepclassmembers class * {
    @dagger.hilt.android.qualifiers.ApplicationContext *;
    @dagger.hilt.android.lifecycle.HiltViewModel *;
}

# Keep Retrofit classes and annotations
-keep class retrofit2.** { *; }

# Keep attributes for Retrofit
-keepattributes Signature, Exceptions, RuntimeVisibleAnnotations, RuntimeVisibleParameterAnnotations

-keepclasseswithmembers class * {
    @retrofit2.http.* <methods>;
}

# Keep Firebase and Google Play Services classes
-keep class com.google.firebase.** { *; }
-keep class com.google.android.gms.** { *; }

# Keep OkHttp Callback interface
-keep class okhttp3.Callback { *; }

# Keep AndroidX Lifecycle classes
-keep class androidx.lifecycle.ViewModel { *; }
-keep class androidx.lifecycle.LiveData { *; }

# Keep all classes extending Fragment
-keep class * extends androidx.fragment.app.Fragment { *; }

# Keep Gson classes and annotations
-keep class com.google.gson.** { *; }

-keep class * implements com.google.gson.TypeAdapterFactory
-keep class * implements com.google.gson.TypeAdapter
-keep class * implements com.google.gson.JsonSerializer
-keep class * implements com.google.gson.JsonDeserializer

-keepclassmembers,allowobfuscation class * {
    @com.google.gson.annotations.SerializedName <fields>;
}

# Keep Kotlin coroutines methods
-keepclassmembers class kotlinx.coroutines.** {
    public <methods>;
}

발생할 수 있는 오류 리스트

1. Missing classes detected while running R8.

에러 메시지에서 제공한 경로(C:\\...\\build\\outputs\\mapping\\debug\\missing_rules.txt)를 확인하여 어떤 클래스나 메소드가 누락되었는지 파악합니다. 추가적으로 필요한 keep 규칙이 있을 수 있습니다. 하지만 OkHttp 4.11.0 버전 이전이라면, 라이브러리 오류일 수 있습니다.

https://github.com/square/okhttp/issues/6258

Proguard Rules (OkHttp 4.7.2) · Issue #6258 · square/okhttp

Hi, I am getting a few warnings when building with DexGuard. Gradle: 5.6.4 Android Gradle Plugin: 3.6.3 OkHttp: 4.7.2 compile_sdk = 30 build_tools = "30.0.2" Current Proguard rules for OkHttp: # ==...

github.com

2. 빌드는 되는데, 서버 통신이 안되는 경우

요청까지는 잘 하는지 리턴으로 200이 돌아오는데 제가 만든 데이터 클래스를 사용하는 부분에서 못찾는 문제가 있었습니다. 데이터 클래스 또는 모델이 제대로 보존되지 않은 경우, Gson을 사용하여 JSON을 파싱할 때 필드 이름이 변경되어 올바르게 매핑되지 않을 수 있는 것 같습니다.

-keep class com.example.app.data.model.** { *; }
-keep interface com.example.app.data.remote.ApiService.** { *; }

3. e$default: java.lang.ClassCastException이 발생하는 경우

ClassCastException은 타입 캐스팅 문제이므로, 관련 클래스의 타입 정보가 제대로 보존되도록 ProGuard 규칙을 조정해야 합니다. Gson은 내부적으로 리플렉션을 사용하여 객체를 생성하고 데이터를 할당합니다. 리플렉션을 사용하는 경우, 클래스의 생성자, 메소드, 필드가 난독화 과정에서 이름이 변경되거나 제거되지 않도록 보존해야 합니다.

-keepclassmembers class * {
    <init>(...);
    private <fields>;
    private <methods>;
}

4. AGP가 8.0보다 높은 경우

8.0부터는 R8이 프로가드와 호환모드가 아닌 풀모드로 동작하기 때문에 규칙을 더 자세히 작성해야합니다.

https://developer.android.com/build/releases/gradle-plugin#default-changes

Android Gradle 플러그인 8.5 출시 노트 | Android Studio | Android Developers

Android 스튜디오 빌드 시스템은 Gradle을 기반으로 하며 Android Gradle 플러그인에는 Android 앱을 빌드하는 데 사용하는 몇 가지 추가 기능이 있습니다.

developer.android.com

참고 사이트

앱 축소, 난독화 및 최적화 | Android Studio | Android Developers

사용하지 않는 코드와 리소스를 삭제하기 위해 출시 빌드에서 코드를 축소하는 방법을 알아보세요.

developer.android.com

Kotlin 버전에 필요한 D8 및 R8 컴파일러 버전 | Android Studio | Android Developers

각 Kotlin 버전의 최소 D8/R8 버전을 찾습니다.

developer.android.com

[Dagger/MissingBinding] UserData cannot be provided without an @Provides-annotated method.

five weeks — Sat, 13 Jul 2024 08:06:18 +0900

문제 상황

Dagger에서 발생하는 MissingBinding 오류는 종속성 주입 과정에서 필요한 객체를 제공할 방법이 없을 때 나타납니다. 이 경우 UserData 객체에 대한 의존성을 해결하기 위해 적절한 제공 메커니즘을 설정해야 합니다. UserData가 객체로 정의되어 있기 때문에, 이 객체의 인스턴스를 주입할 수 있도록 Dagger 설정을 추가해야 합니다.

UserData 제공 설정

UserData는 이미 object로 선언되어 있으므로, Dagger 모듈에서 이를 직접 제공하는 방법으로 접근할 수 있습니다.UserData를 Dagger 컨테이너에 등록하여 다른 컴포넌트에서 UserData를 주입받을 수 있도록 설정합니다. 이를 위해 @Provides와 @Singleton 어노테이션을 사용하여 UserData 객체를 제공하는 메서드를 만들어야 합니다.

@Provides의 의미

@Provides 어노테이션은 Dagger에게 특정 객체를 생성하거나 제공하는 방법을 명시하는 데 사용됩니다. 즉, Dagger가 종속성 그래프에서 필요한 객체를 어떻게 생성하고 제공해야 하는지 알려주는 역할을 합니다. 이 어노테이션은 모듈 클래스의 메서드에 사용되며, 해당 메서드가 반환하는 객체를 Dagger가 관리하게 됩니다.

예를 들어, 다음과 같이 @Provides 어노테이션이 사용된 메서드를 정의하면, Dagger는 이 메서드를 호출하여 UserData 객체를 제공할 수 있습니다

@Provides
fun provideUserData(): UserData {
    return UserData
}

수정된 AppModule

UserData 제공 설정: UserData 객체를 Dagger 모듈에서 제공하도록 설정합니다. UserData는 object로 선언되어 있으므로 싱글턴 인스턴스를 제공하기 위해 @Singleton과 @Provides 어노테이션을 사용합니다.
TokenAuthenticator 제공 설정: TokenAuthenticator 클래스는 ApiService와 UserData를 필요로 합니다. 이를 Dagger 모듈에서 @Provides 메서드를 통해 제공하며, UserData 인스턴스를 주입받도록 설정합니다.

@Module
@InstallIn(SingletonComponent::class)
object AppModule {
    @Singleton
    @Provides
    fun provideUserData(): UserData {
        return UserData
    }
    
    @Provides
    fun provideTokenAuthenticator(apiServiceProvider: Provider<ApiService>, userData: UserData): TokenAuthenticator {
        return TokenAuthenticator(apiServiceProvider, userData)
    }
}