앱에서 API 요청부터 응답까지의 통신 과정 정리

앱에서 버튼을 누르면 데이터가 저장되거나 목록이 갱신된다.
겉으로 보기에는 단순한 동작이지만, 내부에서는 클라이언트와 서버가 HTTP로 통신하고, 서버는 요청을 처리한 뒤 JSON 응답을 다시 돌려준다.
이번 글에서는 노트 앱 구조를 기준으로, 안드로이드 앱에서 서버에 요청을 보내고 응답을 받아 화면에 반영하기까지의 과정을 정리해본다.

---

전체 흐름

전체 흐름은 다음과 같다.

사용자 입력
-> Android UI
-> Repository
-> Retrofit / OkHttp
-> HTTP 요청 전송
-> 서버 엔드포인트 처리
-> 인증 / 검증
-> DB 저장 또는 조회
-> JSON 응답 반환
-> Room 반영
-> UI 갱신

노트 생성처럼 AI 후처리가 필요한 경우에는 다음 흐름이 추가될 수 있다.

노트 생성 요청
-> DB에 기본 데이터 저장
-> 생성 성공 응답 반환
-> 백그라운드에서 AI 요약 / 감성 분석
-> DB 업데이트
-> 이후 목록 조회 시 반영

---

1. 안드로이드에서 서버에 요청 보내기

안드로이드에서는 보통 Retrofit과 OkHttp를 사용해 서버와 통신한다.

• Retrofit : API를 인터페이스 형태로 선언
• OkHttp : 실제 HTTP 요청과 응답 처리
• GsonConverterFactory : JSON과 Kotlin 객체 변환

예를 들어 API 인터페이스는 다음처럼 작성할 수 있다.

interface NoteApi {
    @GET("notes")
    suspend fun listNotes(
        @Query("limit") limit: Int = 10,
        @Query("cursor") cursor: String? = null,
        @Query("order") order: String = "desc"
    ): PagedNotesDto

    @GET("notes/{id}")
    suspend fun get(@Path("id") id: Int): NoteDto

    @POST("notes")
    suspend fun create(@Body body: NoteRequest): NoteDto

    @PUT("notes/{id}")
    suspend fun update(@Path("id") id: Int, @Body body: NoteRequest): NoteDto

    @DELETE("notes/{id}")
    suspend fun delete(@Path("id") id: Int): Response<Unit>
}

---

2. 엔드포인트와 URL 뒤에 붙는 값

API를 볼 때는 경로(Path) 와 파라미터(Parameter) 를 구분해서 보는 것이 중요하다.

Path Parameter

특정 데이터를 식별할 때 사용한다.

GET /notes/3
PUT /notes/3
DELETE /notes/3

여기서 3은 특정 노트의 id이다.
Path Parameter는 어떤 자원을 대상으로 하는지를 나타낸다.

---

Query Parameter

조회 조건이나 정렬 조건을 전달할 때 사용한다.

GET /notes?limit=10&cursor=abc123&order=desc

예를 들면:

• limit : 한 번에 가져올 개수
• cursor : 다음 페이지 기준값
• order : 정렬 방식

즉, Query Parameter는 데이터를 어떤 조건으로 가져올지를 나타낸다.
정리하면 다음과 같다.

• Path Parameter → 무엇을 요청하는지
• Query Parameter → 어떻게 가져올지

---

3. 요청 Body는 JSON으로 전달된다

생성이나 수정 요청은 URL만으로는 부족하고, 실제 데이터를 함께 보내야 한다.
이때 보통 JSON 형식을 사용한다.
예를 들어 노트 생성 요청은 다음과 같은 형태가 된다.

{
  "title": "제목",
  "content": "내용"
}

안드로이드에서는 이를 data class로 표현할 수 있다.

data class NoteRequest(
    val title: String = "",
    val content: String = ""
)

Retrofit은 이 객체를 자동으로 JSON으로 변환해서 서버에 전달한다.

---

4. HTTP 요청은 어떤 형태로 전달될까

예를 들어 새 노트를 생성하면 개념적으로는 다음과 같은 요청이 서버로 전송된다.

POST /notes HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{
  "title": "오늘 공부한 내용",
  "content": "Retrofit과 서버 통신 정리"
}

여기서 볼 수 있는 핵심 요소는 다음과 같다.

• POST : 생성 요청
• /notes : 요청 대상 엔드포인트
• Authorization : 인증 정보
• Content-Type: application/json : 본문 데이터 형식
• Body : 실제 전달할 데이터

안드로이드에서의 API 호출은 결국 HTTP 메서드 + URL + 헤더 + JSON Body 조합으로 이루어진다.

---

5. 서버는 엔드포인트에 맞는 함수를 실행한다

서버에서는 URL과 HTTP 메서드에 따라 실행할 함수를 연결한다.
Flask에서는 다음처럼 매핑할 수 있다.

@app.post("/notes")
def create_note():

즉, 클라이언트가 POST /notes 요청을 보내면 서버에서는 create_note() 함수가 실행된다.
비슷하게 조회, 수정, 삭제도 각각 다른 엔드포인트에 연결된다.

• GET /notes → 목록 조회
• GET /notes/<id> → 단일 조회
• POST /notes → 생성
• PUT /notes/<id> → 수정
• DELETE /notes/<id> → 삭제

이처럼 엔드포인트는 단순 주소가 아니라, 서버에서 어떤 로직을 실행할지 결정하는 기준이다.

---

6. 서버는 먼저 인증과 요청 데이터를 확인한다

생성, 수정, 삭제 같은 요청은 보통 인증이 필요하다.
이때 요청 헤더의 Authorization: Bearer <token> 값을 확인한다.
서버는 보통 다음 순서로 요청을 검사한다.

1. 인증 토큰이 있는지 확인
2. 유효한 사용자 요청인지 확인
3. 요청 데이터 형식이 올바른지 확인
4. 필요한 값이 누락되지 않았는지 확인

즉, 서버는 클라이언트가 보낸 데이터를 바로 신뢰하지 않고,
검증을 통과한 요청만 처리한다.

---

7. 서버는 DB에 저장하거나 조회한다

검증이 끝나면 서버는 실제 비즈니스 로직을 수행한다.

생성 요청이라면

• 요청 Body에서 title, content 추출
• 작성자 정보와 함께 DB 저장

조회 요청이라면

• DB에서 노트 목록 또는 단일 노트 조회
• 응답용 데이터 형태로 변환

즉, 서버의 핵심 역할은 다음과 같다.

• 요청 받기
• 인증 / 검증
• DB 저장 또는 조회
• 응답 생성

---

8. 서버는 JSON 응답과 상태코드를 반환한다

서버는 처리 결과를 JSON으로 반환하고, 동시에 HTTP 상태코드도 함께 보낸다.
예를 들어 응답 데이터는 다음과 같을 수 있다.

{
  "id": 1,
  "userId": "abc",
  "userName": "user",
  "title": "제목",
  "content": "내용",
  "summarize": "요약 결과",
  "sentiment": 0.82,
  "createdAt": "2026-03-12T10:00:00Z"
}

자주 사용하는 상태코드는 다음과 같다.

• 200 OK : 조회 / 수정 / 삭제 성공
• 201 Created : 생성 성공
• 401 Unauthorized : 인증 실패
• 404 Not Found : 요청한 데이터 없음
• 500 Internal Server Error : 서버 내부 오류

즉, JSON은 결과 데이터, 상태코드는 처리 결과 상태를 나타낸다.

---

9. 안드로이드는 응답을 받아 로컬 DB에 반영한다

서버 응답을 받은 뒤에는 이를 DTO로 파싱하고, 필요하면 Room에 저장한다.
흐름은 다음과 같다.

서버 응답 수신
-> JSON 파싱
-> DTO 변환
-> Room 저장
-> UI 갱신

이 구조를 사용하면 UI는 서버 응답을 직접 다루지 않고,
Room 데이터를 기준으로 화면을 그릴 수 있다.
즉, 네트워크 계층과 화면 계층이 어느 정도 분리되는 장점이 있다.

---

한 줄 요약

안드로이드 앱의 API 통신은 클라이언트가 HTTP 요청을 보내고, 서버가 이를 처리한 뒤 JSON 응답을 반환하고, 앱이 그 결과를 로컬 데이터와 UI에 반영하는 과정이라고 정리할 수 있다.

---