열정은 차갑고 잔잔하게

컬리 태그 클라우드(키워드 리뷰) 서비스 도입기

API_Dev — Sat, 4 Jan 2025 18:52:38 +0900

현재 재직중인 회사에서 사내 서비스를 개선하는 아이디어를 만들어 볼 수 있는 좋은 기회를 얻게 되었습니다. 컬리의 리뷰 서비스를 좀 더 고도화 해보았고 돈 걱정 없이 AI 기술을 적극 활용해 볼 수 있는 아주 좋은 기회였습니다.

컬리의 리뷰는 아주 많은 데이터가 있지만 원하는 리뷰를 찾기에는 아직 어렵다고 느껴졌습니다. 타 서비스에서는 리뷰를 작성할때마다 어떤 부분이 좋았는지 강제로 선택하게 하여 요약된 결과를 제공하거나, 이미 있는 리뷰의 키워드들을 카운팅해서 노출해주어 어떤 리뷰가 주로 작성되어있는지 다 읽어보지 않고도 파악할 수 있게 해줍니다.

타 서비스

컬리

그래서 리뷰에서 어떤 키워드가 많이 나오는지 주요키워드로 보여주고, 언급된 키워드만으로 조회해 쉽게 접근할 수 있게 하여 '사용자가 원하는 리뷰에 빠르게 도달시키자' 라는 목표를 세웠습니다.

서비스 기획화면

태그 클라우드(키워드 리뷰) 서비스 아키텍처

다음 그림은 해커톤 기간 총 2.5일간 구현한 서비스 아키텍처 입니다.

실제 컬리 프론트 화면을 구현하지 않고도, 실제 컬리 프론트 위에서 구동하는 것처럼 보이기 위해 클라이언트를 크롬 익스텐션을 이용해 구현하였습니다.

1. 워드 클라우드 데이터 구축

사용자가 제품의 리뷰를 한 눈에, 더 쉽게 파악하기 위해서 다음 UI를 구성하는 것을 목표로 잡았습니다.

키워드 개수를 카운팅 하기 위해서 리뷰에 등장한 키워드들을 추출하고 개수를 세어야 합니다.

이를 구현하기 위해서 워드클라우드를 구축하기로 결정하였습니다.

워드클라우드란?

LLM (GPT api) 을 통한 각 리뷰 키워드 추출

리뷰를 키워드로 바꾸어 워드클라우드로 구축해야합니다. 실제 리뷰 내용에는 해당 상품을 특정하는 정보와 관련없는 내용(ex. 합니다, 써보다, 좋아요, 이용하다, 구입하다 등) 이 많이 포함되어있습니다. 이 내용들을 모두 포함하여 워드클라우드로 구축하면 실제 상품의 사용기를 특정하는 내용보다는 쓸모없는 내용들로 워드클라우드 데이터가 채워지게 됩니다. 양질의 워드클라우드를 구축하기 위해선 각 리뷰에서 사용자가 느끼는 감정이나 특징, 혹은 제품의 특징이 담긴 키워드를 추출해내야 합니다. 수십만 건의 리뷰데이터에서 사람이 하나씩 추출해낼 순 없으므로 LLM을 이용합니다.

리뷰 기반 키워드 추출

리뷰 추출에 이용한 프롬프트

프롬프트의 효율과 정확성을 올리기 위하여 다음 4단계를 적용하였습니다.

1. 역할을 부여하고,

2. 지침을 정확히 지시하며

3. 키워드 추출에 대한 기준을 명시하고

4. 응답형식과 예시를 알려줍니다. (Few Shot 적용)

system_msg = """너는 리뷰를 읽고 키워드를 추출해주는 에이전트야.

# 지침
1. 입력으로 여러 개의 리뷰가 주어질 거야. 각 리뷰는 번호가 매겨져 있어.
2. 각 리뷰마다 키워드를 추출해줘.
3. 키워드는 한 단어로만 표현돼.

# 키워드 추출 기준
- 포함해야할 키워드:
  * 리뷰에 직접 언급된 내용 (예: 촉촉함, 발색력, 광택감)
  * 사용자가 느끼는 감정이나 특징 (예: 만족도, 가성비)
  * 제품에 대한 특징 (예: 지속력, 향기)
- 포함하지 말아야할 키워드:
  * 고유 명사 (예: 브랜드명, 제품명)
  * 제품 구성 (예: 세트, 패키지)
  * 단순히 '좋다', '별로' 같은 추상적인 키워드

# 응답 형식
- 반드시 다음과 같은 JSON 형식으로 반환해야 함:
{
  "1": "키워드1,키워드2,키워드3",
  "2": "키워드1,키워드2,키워드3"
}
- 각 키워드는 쉼표(,)로 구분
- 키워드가 없는 경우 빈 문자열("") 반환
- 코드 블록(```)이나 다른 마크다운 형식을 사용하지 말 것

# 예시
입력:
1. 색상이 너무 예쁘고 발색도 좋아요
2. 배송이 빨라서 좋네요
3. 가격이 비싸서 망설였는데 품질이 좋네요

출력:
{
  "1": "예쁨,발색력",
  "2": "빠른배송",
  "3": "고가,품질"
}"""

Few shot

LLM 의 응답 성능을 더 높이기 위해 Few Shot을 적용합니다.

출처: https://www.promptingguide.ai/kr/techniques/fewshot

적용된 부분

"""
... (생략)

# 예시
입력:
1. 색상이 너무 예쁘고 발색도 좋아요
2. 배송이 빨라서 좋네요
3. 가격이 비싸서 망설였는데 품질이 좋네요

출력:
{
  "1": "예쁨,발색력",
  "2": "빠른배송",
  "3": "고가,품질"
}"""

Batch Request

서비스 개발시 사용한 Azure OpenAI API 에는 분당 API 요청 개수가 정해져 있었습니다. 키워드를 추출해야하는 리뷰의 수가 수십만 건이라면 제한되어있는 요청의 수로 키워드를 추출하기 위해 많은 시간이 소요되어야하는 상황입니다. 그래서 API 요청 한번에 1개의 리뷰를 처리하는 것이 아닌, 50개의 리뷰씩 리스트 형식으로 응답을 받도록 구현하였습니다.

"""
... (생략)

# 응답 형식
- 반드시 다음과 같은 JSON 형식으로 반환해야 함:
{
  "1": "키워드1,키워드2,키워드3",
  "2": "키워드1,키워드2,키워드3"
}

...

# 예시
입력:
1. 색상이 너무 예쁘고 발색도 좋아요
2. 배송이 빨라서 좋네요
3. 가격이 비싸서 망설였는데 품질이 좋네요

출력:
{
  "1": "예쁨,발색력",
  "2": "빠른배송",
  "3": "고가,품질"
}"""

비동기 동시 요청

분당 요청 개수가 정해져있기 때문에 최대한으로 이용하기 위하여 비동기로 동시요청을 하였습니다.

워크클라우드 생성 및 LLM 을 이용한 보정

리뷰의 키워드가 다 추출되고나서, 이제 상품별로 모든 키워드를 모아 워드클라우드를 구축하였습니다. 하지만 리뷰 추출 단계에서 LLM 추출한 키워드에서도 약간의 보정이 필요하였습니다. '가격이 싼, 가성비, 저렴' 같은 키워드는 사실 사용자가 보기엔 같은 의미이기때문에 같은 키워드로 카운팅 되어합니다. 이런 비슷한 의미가 키워드가 여러개로 분산되어있으면, 상위 5개의 키워드만 보여준다고 했을때 사용자가 볼 수 있는 키워드 종류가 적어집니다.

ex. 상위 3개의 키워드가 (가격이싼, 가성비, 저렴) 인 것 보다는, (가성비, 촉촉한, 향기로운) 같이 좀 더 다양한 키워드가 있다면 사용자 입장에서 제품을 파악하기가 쉽습니다.

프롬프트

system_prompt = """
    당신은 word_cloud 데이터를 읽고 비슷한 의미를 가진 word 끼리 합치는 전문가 입니다.
    
    요청 예시) 유사한 의미를 가진 단어들을 하나로 합치고, count를 합산한 뒤 percentage를 다시 계산해주세요.
    
    입력 JSON 예시:
    {
        "words": [
            {
                "word": "가격이 싼",
                "count": 3,
                "percentage": 0.2
            },
            {
                "word": "저렴",
                "count": 3,
                "percentage": 0.2
            }
        ]
    }
    
    응답은 반드시 다음 JSON 형식으로 작성해주세요:
    {
        "merged_words": [
            {
                "word": "가성비",
                "count": 6,
                "percentage": 0.4
            }
        ]
    }
    
    비슷한 의미를 가진 단어들을 하나로 합치고, count는 합산하고, percentage도 다시 계산해주세요.
    """

워드 클라우드 구축 결과

워드 클라우드가 구축되었습니다.

그런데 사실은 사용자에게 제공될 정보는 워드클라우드 이미지가 아닌, 이미지를 만들기 위해 생성된 '데이터' 입니다.

여기서 한번 더 LLM 보정 과정을 거치면,

system_prompt = """
당신은 단어를 적절한 형용사로 변환하는 전문가입니다.
주어진 단어들을 해당 상품의 특성을 잘 나타내는 긍정적인 형용사로 변환해주세요.
형용사로 변환하기 어려운 경우 '변환불가'를 반환하세요. 각 단어에 대해 '원본단어:변환결과' 형식으로 응답해주세요.

'광택' 이라면 '광택이 있는' 같이 해당 단어를 포함하여 형용사로 변환해주면 됩니다.
예시 단어들: 
{
    "광택": "광택이 있는",
    "발색": "발색력이 뛰어난",
    "가격": "가격이 착한"
}


JSON 응답 예시:
{
    "원본단어1": "변환결과1",
    "원본단어2": "변환결과2",
    "원본단어3": "변환결과3"
}
"""

주요 키워드 데이터를 제공할 수 있게 됩니다.

2. RAG 구축 - Search AI

이제 해시 태그로 표시된 키워드를 클릭하면 관련된 리뷰만 보이도록 구현하기 위해 Search AI를 구축해야합니다.

Azure AI Search

https://learn.microsoft.com/ko-kr/azure/search/search-what-is-azure-search

Azure AI 검색 소개 - Azure AI Search

Azure AI 검색은 AI 기반 정보 검색 플랫폼으로, 개발자가 대규모 언어 모델을 엔터프라이즈 데이터와 결합하는 생성형 AI 앱과 풍부한 검색 환경을 빌드하는 데 도움이 됩니다.

learn.microsoft.com

AI Search 는 한마디로 '자연어로' '질의'가 가능한 검색 서비스 입니다.

일단 LLM(gpt) 에게 자연어로 컬리의 리뷰 데이터를 물어본다면, 정확히 답할 수 없습니다. GPT는 컬리의 리뷰 데이터를 가지고 있지 않기 때문입니다. 반대로, 컬리의 리뷰데이터는 '자연어로' 질의할 수 없습니다. DB의 데이터를 검색하기 위해선 SQL문을 작성해야합니다. AI Search 는 이 두 가지 방법을 합쳐서 '자연어로' 우리 데이터에 '질의'할 수 있게 해주는 기술 입니다.

자연어로 질의할 수 있게 된다면, 많은 가능성이 열립니다. 예를들어 "가성비와 관련된 리뷰를 정성스러운 순으로 5개 뽑아줘." 같은 자연어로 질의가 가능해 집니다. 이 질문을 SQL로는 구현해낼 수 없습니다. SQL로 '정성스러운' 이라는 추상적인 기준을 정할 수 없고 '~와 관련된' 같은 의미를 담을 수 없습니다. 하지만 LLM 모델은 이런 추상적인 의미를 이해할 수 있기 때문에 가능합니다.

텍스트 임베딩 및 벡터화

우리의 목적은 AI Search 에게 자연어로 묻고(keyword: "가성비가 있는" 와 관련된 내용을 찾아줘.) 원하는 상품으로 데이터의 개수를 지정해 질의하는 것입니다. 자연어로 질의하기 위해선 먼저, 데이터를 임베딩하여 '벡터화'를 해야합니다.

텍스트 임베딩이란,

임베딩은 고차원 공간 상의 특정 표현(Representation)을 의미합니다.
텍스트, 이미지, 오디오 등 비정형 데이터를 고정 길이(예: 768, 1024 차원 등) 벡터로 변환합니다.
임베딩은 의미나 맥락이 비슷한 데이터가 벡터 공간 상에서도 유사한 위치에 놓이도록 학습됩니다.

출처: https://medium.com/@minji.sql/%EC%9E%84%EB%B2%A0%EB%94%A9-%EA%B9%8A%EC%9D%B4-%ED%8C%8C%ED%97%A4%EC%B9%98%EA%B8%B0-rag%EC%9D%98-%ED%95%B5%EC%8B%AC-%EA%B8%B0%EC%88%A0-6f077b8344e7

컬리의 리뷰 데이터 (Raw Data)를 전처리 과정을 거치고, 텍스트 임베딩 모델을 통해 데이터의 '특징'을 추출합니다. 딥러닝 임베딩 모델이 리뷰 데이터가 담고있는 중요한 의미나 패턴, 구조를 벡터 공간에 압축하여 표현합니다. '벡터화된 숫자값'으로 표현하면 이를 활용해 의미 기반의 검색이 가능해집니다.

               ┌───────────────────────────┐
               │       1) Raw Data         │
               │  (텍스트, 이미지, 오디오)   │
               └───────────────────────────┘
                           │
                           │ (전처리: 토큰화, 정규화 등)
                           ▼
               ┌───────────────────────────┐
               │     2) Preprocessing      │
               │ (필요 없는 기호 제거,      │
               │  텍스트 정규화 등)         │
               └───────────────────────────┘
                           │
                           │ (임베딩 모델에 입력)
                           ▼
               ┌───────────────────────────┐
               │    3) Embedding Model     │
               │ (text-embedding-ada-003)  │
               └───────────────────────────┘
                           │
                           │ (임베딩 모델을 통해 특징 추출)
                           ▼
               ┌───────────────────────────┐
               │   4) N-Dimensional Vector │
               │  (3072 차원에 표현)        │
               └───────────────────────────┘

벡터 공간에 텍스트를 표현하게 되면 컴퓨터는 서로 다른 텍스트들에서 임베딩 간의 거리를 계산하여 이들간의 관계를 이해합니다.

출처: https://medium.com/@minji.sql/%EC%9E%84%EB%B2%A0%EB%94%A9-%EA%B9%8A%EC%9D%B4-%ED%8C%8C%ED%97%A4%EC%B9%98%EA%B8%B0-rag%EC%9D%98-%ED%95%B5%EC%8B%AC-%EA%B8%B0%EC%88%A0-6f077b8344e7

벡터화된 공간에선 단순히 키워드 일치가 아니라 '의미 기반'으로 검색할 수 있게 됩니다. (king - queen)간의 관계가 벡터 공간 안에서 표현되는 방식은 (man - woman) 같이 서로 반대되는 의미가 벡터 공간에 표현 되는 방식은 서로 비슷합니다.

컬리의 리뷰데이터를 GPT의 text-embedding3 모델을 이용하여 텍스트 임베딩을 하였습니다. 다음의 절차를 거쳐 리뷰데이터를 임베딩하면, 각 row마다 n-tokens 값과 vector 값이 생성됩니다. 이렇게 구축된 벡터값은 추후에 의미 기반으로 리뷰를 검색할 때 사용됩니다.

각 리뷰 데이터에 대한 벡터값 생성

Azure에서 AI Search를 구축하려면 다음의 순서를 거칩니다.

Data Source (임베딩된 데이터) 를 업로드하고,
인덱서에게 데이터소스의 어떤 필드를 어떻게 인덱스로 구성할지 설정하여 인덱스 문서를 만듭니다.

 ┌───────────────────────────┐
 │       Data Sources        │
 │ (Blob, Cosmos DB, SQL DB) │
 └─────────────┬─────────────┘
               │ (인덱서가 주기적으로 데이터를 가져옴)
               ▼
      ┌───────────────────────┐
      │       Indexer         │
      │  ┌─────────────────┐  │
      │  │   Skillset(AI)  │  │
      │  │ (OCR, NLP 등)   │  │
      │  └─────────────────┘  │
      └─────────────┬─────────┘
                    │ (전처리 & AI로 분석된 결과를 인덱스에 저장)
                    ▼
      ┌───────────────────────┐
      │         Index         │
      │ (문서, 필드, 메타정보)│
      └─────────────┬─────────┘
                    │ (사용자가 검색 쿼리를 보냄)
                    ▼
      ┌───────────────────────┐
      │        Query          │
      │ (검색, 필터, 정렬 등) │
      └───────────────────────┘

참고: https://www.youtube.com/watch?v=MOOHK1b4Syk

이제 다음과 같이 코드를 구성하면 자연어로 구축된 AI Search 에게 질의가 가능해집니다.

vector_query: AI Search에게 자연어로 질의하기 위해 question(질의 내용) -> embedding 해서 -> 벡터화된 쿼리로 만듭니다.
filter: 검색할 상품 기준 (실제 sql 처럼 정확히 특정 상품 안에서만으로도 질의가 가능해집니다.)
select: 원하는 데이터 select
top: 유사도 순으로 개수 지정

client = AzureOpenAI(
    azure_endpoint = azure_endpoint,
    api_key        = api_key,
    api_version    = api_version
)


def search(productNumber: str = "111111", badgeKeyword: str = "촉촉함"):
    search_client = SearchClient(endpoint=endpoint, index_name=index_name, credential=credential, api_version=api_version)

    question = "keyword: " + badgeKeyword + " 와 관련된 내용을 찾아줘. 키워드와 관련된 내용이 꼭 포함되어 있어야 하고 정성스러워야해."
    embedding = client.embeddings.create(input = question, model=embedding_model_name).data[0].embedding
    vector_query = VectorizedQuery(vector=embedding, k_nearest_neighbors=15, fields="content_vector", exhaustive=True)

    results = search_client.search(  
        search_text=f"contents: '{badgeKeyword}'",  
        filter=f"productNumber eq {productNumber}",  
        vector_queries=[vector_query],
        select=["sno", "productNumber", "contents"],
        top=15  
    )
    
    # 결과를 리스트로 변환
    results_list = []
    for result in results:
        results_list.append({
            "sno": result["sno"],
            "productNumber": result["productNumber"],
            "contents": result["contents"]
        })

    return {"results": results_list}

현재 response

{
	results: [
    	{
            "sno": "1111",
            "productNumber": "11111",
            "contents": "좋아요 촉촉하니 이거쓰고 건조함을 잘못느끼네요"
        },
        ...
}

이제 특정 키워드와 관련된 리뷰까지는 조회가 가능합니다. 이제 형광펜으로 리뷰의 어떤 내용이 키워드의 내용을 포함해주고 있는지를 같이 응답해주어야 클라이언트에서 형광펜으로 하이라이팅을 해줄 수 있습니다. 이를 LLM 을 이용하면 쉽게 구현이 가능합니다.

system_msg = """
        # 당신은 전문 뷰티 리뷰 분석가 입니다.
        보내주는 리뷰를 읽고 같이 보내주는 키워드와 가장 유사한 부분의 하이라이트 텍스트를 반환해 주세요.
        하이라이트 텍스트는 보내주는 리뷰에 꼭 포함되어있어야 하는 텍스트입니다.
        하이라이트 텍스트는 2~3단어 미만으로 구성해주세요.
        유사한 부분이 없다면 빈 문자열로 보내주세요.

        # 예시 요청
        {
            "texts": [
                {
                    "id": 0,
                    "keyword": "향기",
                    "text": "진작부터 써보고 싶었던 제품이에요. 1+1으로 구매해 기분이 좋아요. 제형은 세럼과 토너의 중간쯤인 거 같아요. 향이 좋아서 하루에도 여러 차례 뿌리게 되네요. 처음엔 조금 진한듯 하지만, 시간이 지날수록 은은하게 남은 잔향이  더욱 좋아요."
                },
                ... 20개
            ]
        }

        # 예시 JSON 응답
        {
            "highlighted_texts": [
                {
                    "id": 0,
                    "keyword": "향기",
                    "highlighted_text": "향이 좋아서"
                },
                ... 20개
            ]
        }
    """

이제 어떤 부분을 하이라이팅할지까지 클라이언트에게 응답하면, '리뷰키워드로 검색후 하이라이팅' 구현이 완료됩니다.

마무리

사실 네이버 쇼핑에서는 이미 키워드 리뷰 검색 기능을 제공하고 있습니다. 이를 태그 구름 서비스라고 부릅니다. 네이버 쇼핑에서 잘 쓰고 있는 기능이 컬리에도 도입되었으면 하는 바람에 해커톤 아이디어로 구현해보았습니다. 특히 화장품을 판매하고 있는 뷰티컬리에서는 사용자들이 필수적으로 사용후기를 확인하고 있었지만, 오히려 후기가 너무 많아 제대로 활용되지 못하는 부분을 개선해보고 싶었습니다.

네이버의 키워드 리뷰 검색

서비스 컨셉 기획과 구현, 발표자료 모두 2일안에 만드느라 고생을 많이 했습니다. 결국 구현을 완료했다는 것에 성취함이 엄청 느껴졌고 팀원에게 너무 고마웠습니다. 수상은 하지 못했지만 나에게는 많은 것이 남은 해커톤이었습니다. GPT api만 사용할줄 알던 내가 RAG 까지 구축을 하는 경험을 했다는 것 자체가 너무 귀하고 감사하다는 생각입니다.

조금 더 생각해볼 부분들

안좋은 후기는 어떻게 처리할 것인가?

내용이 안좋은 후기에 대해서는 일부러 보여주지 않을 필요는 없다고 생각했습니다. 안좋은 내용을 확인하고 싶은 사용자도 당연히 있을 것이고, 리뷰 시스템에서 안좋은 내용의 후기를 일부러 노출하지 않을 책임은 없다고 생각합니다. 상품에 대해 평이 안좋은 것은 리뷰시스템에서 해결할 부분이 아니고 상품 품질을 관리하는 부분이 신경써야한다고 생각했습니다. 하지만 단순 부정후기가 아닌 '악성' 후기에 대해선 리뷰 시스템에서 막을 책임은 있을 것 같습니다.

리뷰 개수가 적은 서비스에서는 제공하지 못하는 기능 아닌가?

아이디어의 시작 자체는 '리뷰 데이터가 너무 많아 원하는 리뷰를 찾아보기 힘들다' 에서 출발하였습니다. 리뷰 개수가 적다면 사용자는 오히려 리뷰를 파악하기쉬워 이 기능까지는 필요없지 않을까 생각합니다.

LLM api 를 사용하는 부분에 대한 성능과 비용이슈는?

리뷰 -> 키워드 추출
텍스트 임베딩
키워드 -> 형용사로 변환
AI Search 질의
AI Search 결과 -> 하이라이팅할 텍스트 찾기

리뷰 키워드 추출 최적화가 가능하다.

신기능에 대해선 AI 비용이 당연히 드는 것이 사실입니다. 하지만 좀 더 효율적으로 사용하는 방법에 대해선 고민이 필요합니다. 리뷰 데이터에서 키워드로 추출하는 부분에 대해서는 각 row 하나마다 키워드를 추출하는 방식에서 같은 상품의 리뷰를 몇개 합쳐서 최대 토큰수(8196)개에 근접하게 만들면 리뷰 데이터 row수가 많이 줄어들 수 있습니다. 키워드가 필요한 부분은 사실 '각 리뷰'가 아닌 '상품별' 이기 때문입니다. 실제로 리뷰 데이터들 중에서 짧아서 내용이 별로 없는 리뷰는 제거하고, 남은 리뷰를 몇개씩 합친뒤 키워드 추출을 해보았습니다. row 수가 많이 줄어 임베딩하는 속도와 효율이 많이 증가했고, 주요 키워드의 워드클라우드 데이터는 거의 비슷하게 구축이 되었습니다.

AI Search 결과에서 하이라이팅할 텍스트 찾기

실시간으로 조회된 리뷰에서 하이라이팅할 텍스트를 찾기 때문에 API call이 5초가량 소요됩니다. 조회하는 리뷰의 양이 많을 수록 API 응답속도가 길어집니다. 해커톤 당시에는 사용자가 어떤 키워드로 검색할 지 모르기 때문에 하이라이팅 텍스트를 미리 저장하지 못하는 것 아닌가? 라고 생각했습니다. 끝나고 다시 생각해보니 주요 키워드가 이미 추출된 상태라면 각 리뷰에서도 주요 키워드에 따라 어떤 부분을 하이라이팅 할지 미리 설정하는 것은 불가능하진 않아보였습니다.

LLM api를 사용하는 곳이 많다.

실시간응답을 빠르게 하기 위해 미리미리 LLM을 이용해 데이터를 만들어 놓는다고 하더라도, 리뷰 하나에 api가 여러번 사용됩니다. 실제 리뷰 수는 수백만 건이기 때문에 이 수백만 건마다 api 호출이 여러번이라면 비용이 많이 들 수 있습니다. 이 부분은 아직은 잘 모르겠습니다. 얼마를 투자하고 전환률을 얼마나 올리는데에 드는 비용을 잘 모르기 때문에 판단하기가 어려웠습니다. 그래도 LLM 적극적으로 이용한다면 기존에 없던 기능이 만들어지고 경쟁력을 확보하는데에 좋지 않을까 라는 생각을 하며... (이런 쪽으로 투자 많이 했으면 좋겠는 개인적인 바람)

소감

개인적인 도전으로는 요즘 푹 빠져있는 Windsurf를 이용해서 '한번도 써보지 않는 기술스택으로도 Windsurf와 함께라면 개발이 가능할까?' 라는 도전을 이번에 해봤습니다. 정말 신기하게도 성공했고, 파이썬 언어는 다룰줄 알지만 API를 구축해본적은 없던 상황에서 Windsurf로 Fast API로 서버를 구축하였습니다. 이로써 알게된 것은 어느정도 다룰줄 아는 언어라면 간단하게 서비스를 구현해내는 것은 정말 쉬워졌다는 것입니다.

여러 개발 언어를 테스트해보고 있는데 느낀 점은 아래 표와 같습니다.

언어 수준	개발 효율 증가 (with. Windsurf)	느낀점
주로 사용함, 잘 알고 있음 (Java, Spring)	Low	귀찮은 작업을 대신 해줌
주로 사용하진 않지만 알고 있음 (Python)	High	'주로 사용함' 레벨과 근접하게 사용하게 해줌
잘 모름 (Typescript, Next.js)	Medium	어느정도 구현은 가능하지만 Windsurf가 잘못된 방향으로 가는 순간 망함

일단 전체적으로 사용하지 않는 것 보다는 '훨씬' 좋습니다. GPT에 매번 내 코드 컨텍스트를 학습시키는 비용이 들지 않고 그냥 '내 코드베이스 전체를 파악해서 답변해줘' 라는 말만 맨 앞에 넣으면 되기 떄문입니다.

앞으로는 이렇게 얻은 AI 관련 기술들을 사이드 프로젝트에서 적극적으로 활용해볼 계획입니다. 특히 Function Calling 기능도 가능성이 무궁무진해 보였습니다. 길고 두서없는 어려운 글 읽어주셔서 감사합니다. 나중에 내가 보더라도 이해할 수 있게 작성하려고 노력했으니 미래의 내가 판단해줄 것이라고 생각합니다.

[Github Actions] 모두가 몰랐던 Github PR 워크플로우의 비밀

API_Dev — Thu, 15 Aug 2024 16:44:55 +0900

PR 을 open하면 돌아가는 워크플로우는 PR 브랜치 기준이 아니다 !

보통 많은 분들이 PR을 열어놓고 커밋이 추가될때마다 자동으로 테스트를 돌리거나 Sonar 를 돌리는 경우가 많습니다.

그리고 무의식중으로 아직 머지를 안했으니 내가 방금 업데이트한 브랜치 기준으로 워크플로우가 돌겠구나 생각하게 됩니다.

그런데 혹시 깃헙액션이 돌아갈때, PR을 날리는 브랜치 기준이 아니라 merge 된 브랜치를 가정하고 돌아가는 것을 알고 계셨나요?

이렇게 PR을 날리고 있다고 가정하면 main + feature branch 를 머지했다고 가정한 상태로 액션이 돌아갑니다.

다음과 같이 Checkout 액션을 돌리고,

# <https://github.com/actions/checkout>
- name: Checkout
  uses: actions/checkout@v4
  with:
		...

깃헙 액션이 돌아가는 스크립트를 살펴보면, Checkout 단계에서 /merge 가 붙은 브랜치로 switching 하는 것을 볼 수 있습니다.

(git switch vs git checkout 에 대한 설명은 아래 글 참고)

https://graphite.dev/guides/git-checkout-vs-switch

깃헙 문서의 워크플로우 트리거 이벤트 부분도 확인해 보면, pull_request 이벤트에서는 github_sha, github_ref 를 기본적으로 둘다 merge된 기준으로 제공하고 있습니다.

https://docs.github.com/ko/enterprise-cloud@latest/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request

actions 의 checkout 레포의 Readme 문서를 확인해보겠습니다.

체크아웃할 분기, 태그 또는 SHA입니다.
저장소를 확인할 때 워크플로를 트리거한 경우 기본값은 해당 이벤트에 대한 refence 또는 SHA입니다.
그렇지 않으면 기본 분기를 사용합니다.

해당 이벤트에 대한 refence(ref) 또는 sha 를 사용한다고 되어있습니다.

결론적으로 pull_request 이벤트 트리거를 사용했고, pull_request 트리거는 기본적으로 병합상태의 sha 혹은 ref를 제공하므로 병합상태를 기준으로 워크플로우가 동작하는 것을 확인하였습니다.

난 PR을 생성한 브랜치 기준으로 워크플로우를 실행하고 싶은데?

헤드 브랜치에 대한 커밋을 얻으려면 github.event.pull_request.head.sha 를 사용하라고 가이드합니다.

이 이벤트의 GITHUB_SHA는 풀 요청 병합 분기의 마지막 병합 커밋입니다. 풀 요청의 헤드 브랜치에 대한 마지막 커밋의 커밋 ID를 얻으려면 대신 github.event.pull_request.head.sha를 사용하세요.

https://github.com/actions/checkout

그런데 꼭 PR 브랜치 기준으로 워크플로우를 실행할 이유가 있을까?

이미 누군가가 깃헙에 이슈를 달았다.

싫어요가 2개나.. ㅠ

Github 개발자의 답변

https://github.com/actions/checkout/issues/504

번역)

질문: 이제 풀 요청 브랜치 헤드를 확인하는 것보다 이것이 기본값이라는 이점이 무엇인지 궁금합니다. 그렇게 바꾸면 되지 않을까요?

답변: 생성된 테스트 병합 커밋을 사용하면 기본 분기(마스터/메인)에 병합되는 컨텍스트에서 PR 변경 사항을 테스트하고 실제 병합 전에 해당 문제를 미리 포착할 수 있습니다.(기본 분기에 더 이상 업데이트가 없다고 가정).

납득.. PR을 날린다는건 병합할 예정이라는 뜻이고 병합 후의 발생할 이슈사항을 체크하는게 우선이 맞다고 생각이 든다.

만약 충돌이 있는 브랜치라면?

워크플로우가 돌아가지 않는다.

공식문서에서 병합충돌을 먼저 해결해야 워크플로우가 실행된다고 설명합니다.

번역) 풀 요청에 병합 충돌이 있는 경우 워크플로는 pull_request 활동에서 실행되지 않습니다. 병합 충돌을 먼저 해결해야 합니다.

이와 관련해 최근까지도 엄청 활발하게 토론중인 이슈 링크를 첨부합니다.. ㄷㄷ

‘오류이므로 개선해야한다’ VS ‘이게맞다’ 로 의견이 갈리네요

https://github.com/orgs/community/discussions/26304

번외로.. 해당 이슈를 만난 이유

팀 동료분이 로컬에서 테스트가 성공했지만, PR에서 돌아가는 CI는 자꾸 통과하지 않는다.. 라고 하셔서 같이 살펴봤습니다.

보통 KST, UTC 문제거나 gradle test가 달라서 실패하는 경우가 대부분인데 이번에는 둘다 아니었습니다.

혹시나 해서 로컬에서 머지후에 테스트를 돌렸더니 머지하면서 import 문이 하나 빠지고, 의존성이 없어 컴파일 자체가 실패하고 있었습니다.

원래 jacoco 테스트 실패 리포트가 만들어져야하는데 자꾸 안나오는 이유도 ‘컴파일 자체가 안되어서’ 였습니다.

이럴땐 컴파일 자체를 안된걸 의심해볼 필요가 있다는 걸 또 한번 깨달았습니다.

어쨌든, 머지 후에 테스트가 동일하게 실패하고 혹시 PR이 머지 기준으로 돌아가는것 아닐까? 하고 로그를 살펴보며 발견하게된 이슈였습니다.

지난 2개월간의 인생 리뷰 - 사이드프로젝트 DND

API_Dev — Mon, 6 Mar 2023 13:56:08 +0900

살면서 가장 주도적으로 살았던 기간이었다.

2개월동안, 마음속에만 품어왔던 도전들을 하나씩 꺼내보았다.

그리고 그 도전들을 하나씩 리뷰해보려고 한다.

첫번째 이야기 - 멘토링

사이드프로젝트 - DND

8주동안 DND 에서 [쉽고 빠른 약속시간 정하기 - 모두의시간]을 만들었다.

https://www.dnd.ac/

DND

프로젝트에 즐거움을, 모두에게 기회를

www.dnd.ac

프로젝트 백엔드 레포지토리

시작

프로젝트 아이디어를 정하는 과정에서 여러가지 좋은 의견들이 나왔다. 우리는 8주라는 기간동안 완성할 수 있는지 여부가 가장 중요하다고 판단했고, 개인적으로는 실제로 사용되는 서비스를 만들고 싶었다. 시간 약속을 잡는 불편함은 당장 하고 있던 회의시간을 잡는 중에도 느꼈던 불편함이었고, 살아가면서도 시간약속을 잡아야 할 일도 많았다. 모두가 불편함에 공감하고 있었고 아이디어 채택은 수월하게 진행됐다.

사람들의 아이디어를 다 들어보고 아이디어마다 서로 디벨롭을 할 수 있는 부분을 같이 찾아가는 시간을 가졌다. 이 때는 최대한 자신의 의견이 존중받는다는 것을 느껴야 더 좋은 아이디어를 낼 수 있다는 것을 알고있기에, 팀원들의 의견을 존중하며 디벨롭을 같이 생각해보는 방향으로 최대한 생각했었다.

아침 7시 회의는 실화입니다. - 채민

리서치 및 기획

리서치기간에서는 앞으로 진행할 프로젝트의 기획을 구체화 하기 위해 필요한 리서치들을 했다. 기존에 해왔던 프로젝트는 개발자들끼리만 기획하고 구현했었다. 이 서비스가 사용되기 위한 고민을 개발의 관점에서만 고민했었다. 이번에는 디자이너분들과 함께 제대로된 사용자 모델링을 위해 시장조사, 사용자 설문조사 그리고 이 리서치 정보를 토대로 우리 서비스가 어떤 핵심가치를 지녀야할지 뽑아냈다.

인터뷰 응답을 중심으로 인사이트 뽑기

핵심 인사이트를 뽑아내고 이를 통해 서비스의 핵심가치 정하기

이 과정이 정말 오래걸리고 회의도 많이했다. 하지만 정말 사용될 서비스를 위해선 꼭 필요한 과정이라고 생각헀다. 기존에 우테코에서 프로젝트를 했을때는 개발자들끼리 이루어진 팀이었기 때문에 기획적인 부분이 부족할 수 밖에 없었다. 그런데 이번에 DND에서 디자이너분들과 함께할 수 있어서 기획적인 부분과 디자인을 체계적으로 진행할 수 있었다.

개발

우테코에서 진행한 프로젝트 코드는 우테코 내내 객체지향과 클린코드를 학습한 내용이 잘 적용되지 못했다. 그리고 우테코가 끝나고 추가로 학습한 도메인 중심적인 설계를 적용할 프로젝트가 필요했다. 누구와 개발을 같이 하게될지는 몰랐지만 잘 설득해서 내가 알고있는 지식들을 팀원과 함께 잘 녹여내보기로 생각했다.

도메인 용어 통일하기

지원플랫폼에서 근무하면서 배웠던 것들 중에서는 도메인 용어를 통일하는 것이 있었다. 디자이너, 개발자들끼리 도메인 용어를 통일하는 것은 도메인주도개발에 국한된이 아니라 그냥 일을 잘하는 방법중에 하나이다. 그래서 와이어프레임 설계단계에서부터 같은 화면이나 기능인데 서로 다르게 말하고 있는 것들을 잡아서 계속 바로잡으려고 했다.

이게 생각보다 쉽지는 않았다. 회의를 하는중에 "이거는 이거라고 부르는게 정확하지 않을까요?" 라던가, "이렇게 부르는 것은 정확한 명칭이 아닌것 같아요" 라고 말하는 것은 정말 어려웠다. 게다가 이렇게 태클을 걸었으면 정확한 워딩을 내가 짚어주지는 못하고 같이 고민하자고 하고 있으니 회의 시간이 지체되기도 했었다. 같은 화면, 같은 기능을 모두가 동의하는 합리적인 단어로 말하는 것이 이상적이지만 순조롭게 되지는 못했다. 마감기한이 있으니 급한 것들만 짚기는 했지만 그럼에도 남아있는 잘못된 단어들이 있었다. 지나고나서 보면 도메인 용어는 마감기간때문에 미뤄야할 요소가 아닌 것 같다. 지속되는 서비스를 위해서는 꼭 필요한 작업이라고 생각이 든다. 도메인 용어 하나가 잘못되면 개발코드의 변수명도 이상해지고, 사용자가 보는 단어도 달라지는 경우가 있었다. 처음에 잘못되면 이것들은 바꾸기 어려워진다. 그리고 소통의 문제도 생기게 된다. 다시 프로젝트가 재개될때는 도메인 용어 통일에 대해서는 타협하지 않고 같이 정립해 나가야된다고 팀원들을 설득해야겠다고 생각했다.

처음부터 끝까지 TDD

모두의 시간 프로젝트는 처음부터 끝까지 TDD로 진행했다. TDD를 한번도 해보지 못한 백엔드 팀원과 TDD를 진행하는 것이 어려울 것이라고 생각했지만, 페어프로그래밍으로 처음부터 같이 진행하다보니까 생각보다 괜찮았다. 멘토링으로 TDD 강의도 진행한 경험도 있었지만, 팀원분이 배우려는 자세가 너무 잘되어있었고 학습속도도 스펀지처럼 빨랐기 때문인 것 같다. 프로젝트 중반에는 팀원분이 한번 테스트 코드 없이 프로덕션부터 짜보려고 시도했다가 내가 지금 뭘 해야하지 뇌정지가 와서 '아 이래서 TDD 하시는거군요' 하고 스스로 깨달은 뒤 혼자서 TDD를 진행하시는 것을 보면서 역시 야생형 학습법이 나쁘지 않구나라는 것을 느꼈다.

요즘 우테코를 수료하고 실제 회사에 들어간 크루들을 보면 회사에서 TDD를 안하고 있다는 크루들을 많이 보았다. 우테코 내내 'TDD는 신이다' 라고 외치던 사람도 회사에 들어가선 'TDD는 사기다' 라고 외친다고도 한다. 그런데 나는 TDD를 몇년간 직접 해보면서 장점과 단점을 확실하게 알아가고 있다. 나는 해보지 않고 사용을 안하는 사람과 다르기 때문에, 장점이 빛날때 하면 되고 단점이 두드러질땐 하지 않으면 된다고 생각한다.

JPA 매핑과 DB연결은 최대한 나중에, 우린 객체설계에 집중하자

팀원분께 처음부터 우리는 ERD 설계부터 하는 것이 아닌 도메인 설계부터 하자고 요청했다. 이 부분도 다행히 팀원분이 거부감없이 새로운 것을 받아들일 준비가 되어있어서 수월하게 진행할 수 있었다. 나 조차도 이렇게 진행하는 것이 처음이었고 객체지향설계와 JPA의 장점과 단점을 직접 경험해보자는 생각으로 이렇게 진행했다.

일단 테이블설계를 염두에 두지 않고 진행하다보니까 객체설계 자체에만 집중할 수 있었다. 통합테스트 부분은 메모리를 이용한 레포지토리를 임시로 만들어서 진행했다. 나중에 JPA Repository로 사용할 인터페이스의 이름과 스펙을 똑같이 맞춰놓으면 JPA를 추가할때 코드 변경을 최소화할 수 있겠다고 생각했다. 실제로 이 방법은 나중에 JPA 연결할때 예상대로 되는 모습을 보면서 둘 다 신기해했었다.

느낀 장점도 있지만, 단점도 느껴졌다. 단점이라기 보다는 어쩔 수 없는 문제를 해결해야 했다. 역시 객체와 테이블간의 패러다임 불일치 문제가 있었다. 객체를 먼저 설계하다보면 List를 쓸 일이 굉장히 많았다. 그런데 테이블은 리스트라는 개념이 없기 때문에 연관관계를 맺기 위해선 Many에 해당하는 쪽에 One의 FK를 걸어주어야 한다. 우리가 사용하고있는 객체를 엔티티로 사용하기 위해서는 List로 되어있는 객체를 신경써주어야 했다. 그리고 이 List를 엔티티에 매핑하려면 3가지 경우의 수를 따져야 했다. 1) OneToMany 단방향, 2) ManyToOne 단방향, 3) ManyToOne 양방향 이 세가지를 각 어떤 상황에 걸어야할지 고민했다.

OneToMany 단방향은 영한님의 강의에선 안티패턴이라고 설명해주셨지만, 같은 애그리거트에서 필수로 같이 조회되고 Many쪽의 데이터가 수정될 일이 없다면 충분히 사용해도 된다고 생각했다. 이미 지원플랫폼에서 사용했던 경험도 있다. OneToMany 단방향에서 추가로 신경써주어야 할 것은 불필요한 update 쿼리가 나가는 부분이다. Many부분의 엔티티가 저장되고 FK를 update하기위해 update쿼리가 추가로 나가는 문제가 있다. 하지만 이 쿼리도 없앨 수 있는 방법이 있다. 사실 이 방법이 있기 때문에 OneToMany 단방향을 고려한 것이다. JoinColumn에 nullable=false, updatable=false 을 걸어주면 Hibernate에서 Many가 save될때 FK를 같이 넣어줘서 update쿼리가 추가로 나가지 않는다.

ManyToOne 단방향은 지금 코드를 다시 보니까 사용을 하나도 안했다. 아마 애그리거트를 나누다보니까 ManyToOne 단방향을 걸어야할 상황이 나오지 않은 것 같다. 객체를 List로 가지고있지 않다면 사실 연관관계가 필요하지 않는 경우가 있다. 그리고 굳이 FK로 가지는 것 보다는 그냥 id를 필드로 가지고 있어도 될 수 있다. 우리 코드에서는 ManyToOne 단방향보다는 양방향이 걸려있다.

ManyToOne 양방향도 안티패턴이라고는 하지만, 우리 코드에서는 쓰였다. 객체를 List로 갖고있는 상태에서 Many 쪽의 데이터를 수정해야할 일이 있고, One을 조회할때 항상 Many까지 같이 필요한 경우에 쓰인다. 이때는 연관관계 편의메서드를 신경써주어야한다. 우리 코드는 일반적인 Team, Member 예제코드 처럼 되어있진 않고 우리만의 비즈니스 코드였기 때문에 편의메서드를 다른 방식으로 구현해야했다.

코드가 어느정도 완성되고나서 JPA를 붙이는 것이 생각보다 어렵지 않았지만 List 매핑하는 부분은 신경을 많이 써주어야했다. 적용할 당시에는 최선의 방법이었지만 나중에 볼때는 제거하기 어려운 레거시가 되어있을 수 있겠다 라는 느낌이 들었다. 대신에 지금의 경험과 고민으로 다음에는 시간을 아낄 수 있게 되었다. N+1 문제 등 해결해야할 여러가지 문제들이 남았지만 차근차근 해결해보려고 한다.

도메인 중심 설계와 도메인 이벤트 (feat. 단방향 의존성 관리)

우테코가 끝나고 추가로 도메인 중심적으로 사고하는 방법과 의존성을 단방향으로 관리하는 공부를 했었다. 이번 프로젝트에서도 처음부터 의존성 방향을 잘 관리하여 추후에 도메인 단위로 패키지를 구분할 생각으로 진행했다. 객체설계를 하는 단계에서부터 팀원분이랑 같이 고민하면서 설계했다. 요구사항과 도메인이 계속 추가되면서 구조와 설계도 변경이 자주 되었다. 그러면서도 어느정도 묶이는 개념들이 보였다. 이 부분들을 차근차근 애그리거트로 묶어가며 단방향 의존성을 관리했다.

계속해서 추가되는 도메인구조를 팀원분과 항상 같이 설계했다.

참여자가 본인의 일정을 수정하면, 그에 따라 좌)일정 등록 현황과 우)실시간 조율 현황이 바뀌어야 하는 요구사항이 있었다.

좌) 일정 등록 현황 우) 조율 현황

이때는 일정 수정에 따라 진행하는 추가적인 로직들을 수행하려면 양방향을 의존해야 하는 상황이었다. 그래서 일정이 수정되면, 일정이 수정되었다는 도메인 이벤트를 발행하고 일정을 알고있는 다른 도메인들이 이벤트를 리슨해 자신의 로직을 수행하도록 만들었다. 이렇게 의존성을 단방향으로 관리했다. 이렇게만 사용한다면 문제가 없었을텐데 굳이 이벤트를 사용하지 않아야할 때도 이벤트를 사용한 부분이 있었다. 이미 의존을 하고 있어서 굳이 이벤트를 사용하지 않아도 되었는데도 이벤트를 사용해서 여러가지 문제가 발생했다.

이벤트를 사용함으로써 발생하는 추가적인 코드 (RegisterEvent, Listner코드, 이벤트 테스트 등)
이벤트 객체를 이벤트를 발생한 도메인에 두지 못하고 Listner 쪽에 두어야 하는 점
코드를 추적하기 어려움

굳이 이벤트를 사용하지 않아도 된다면, 이벤트를 사용하지 않고 해당 코드를 차례로 호출만 해도 위의 문제가 발생하지 않을 뿐만 아니라 더 쉽고 간결하게 코드를 짤 수 있었다.

인터페이스를 이용해 의존성 역전하기

단방향 의존성을 위해서는 이벤트 뿐만아니라 인터페이스를 이용한 의존성 역전을 할 필요가 있었다. 현재 의존성 방향이 Room(방) -> TimeBlock으로 되어있다. 이 말의 뜻은 Room은 TimeBlock을 알고있어도 되지만, TimeBlock은 Room을 알 수 없다는 뜻이다.

Room(방) -> TimeBlock 의존성 흐름

하지만 TimeBlock이 수정될때 (참여자가 자신이 등록한 시간을 수정할 때) 방의 정보를 확인해 검증을 해야할 필요가 있었다. 방을 생성할때 지정한 마감기한이 지나지 않았는지, 방이 가지고 있는 날짜들과 시간들 안에 포함되는 시간인지 등을 검증해야했다. TimeBlock에서 Room을 직접 불러 호출하게되면 Room <-> TimeBlock의 양방향 의존성이 생기게 되었다. 이를 해결하기 위해서 인터페이스를 통한 의존성 역전을 이용했다. 또, TimeBlock이 Room을 구분하기 위한 RoomUuid를 불변값으로 가지고있게 만들었다.

좌) Room, 우) TimeBlock

@Component
@RequiredArgsConstructor
public class RoomTimeValidator implements TimeReplaceValidator {

    private final RoomRepository roomRepository;
    private final TimeProvider timeProvider;

    @Override
    public void validate(String roomUuid, List<AvailableDateTime> availableDateTimes) {
        Room room = getRoomByRoomUuid(roomUuid);
        validateDeadLine(room.getDeadLineOrNull());
        validateContainsAllDates(room, availableDateTimes);
        validateStartAndEndTime(room, availableDateTimes);
    }
    ...
}

TimeBlock에서는 interface에만 의존하게 한 후, Room에 구현체를 두어서 의존성 역전을 통해 단방향 의존성으로 만들었다.

좌) 양방향 의존, 우) 단방향 의존

이번 프로젝트에서는 단방향 의존성에 집착하며 개발했다. 물론 현업에서 DDD를 경험해본 것도 아니고, MSA를 경험해본 것도 아니었지만 이번 프로젝트에서 열심히 집착해보았다. 아직은 단방향 의존성 관리의 장점을 그렇게 크게 느끼지는 못했지만, 어느 도메인을 수정했을때 어느 도메인까지 변경이 전파될 수 있는지는 한 눈에 알 수 있었다. 그래서 추후에 백엔드 팀원과 작업을 나눌때도 최대한 컨플릭트가 나지 않고 변경이 적은 방향으로 업무를 나누기도 편할거라고 생각되었다.

시간 관련 코드 가독성

지난 번 면담시간 예약서비스를 개발했을때 가장 개선하고 싶었던 것이 시간관련된 코드의 가독성이다. 현재 테스트를 돌리고있는 현재시간이 계속 바뀌는 상황이었고, 원하는 시간으로 테스트하고 싶을때도 자유롭게 할 수 없었다. 어느 시간을 기준으로 테스트를 실행하고 있는지 테스트 코드만으로도 파악할 수 있게 만들고 싶었다. 그래서 이번 프로젝트에서는 시간관련 테스트를 최대한 가독성있게 짜서 시간테스트를 읽는 비용을 최소화하기 위해 노력했다.

일단은 먼저, 테스트들에서 사용되는 시간의 범위를 미리 정해놓았다. 2월 8~10일, 시간은 11~14시 안에서 테스트를 돌리기로 결정하고 사용되는 시간들의 픽스처를 하나하나 만들면서 진행했다.

변수안에 시간과 날짜를 같이 넣어놔서 해당 픽스처를 사용하는 테스트에서는 변수명만 봐도 어느 시간과 날짜로 테스트를 돌리는지 한 눈에 알 수 있게 만들었다.

11~13시, 9일 10일을 가지고 있는 방

어떤 날짜와 시간을 등록하는지 알 수 있음

어떤 테스트에서 읽어도 어떤 날짜와 시간으로 데이터를 만들고 있는지 한 눈에 알 수 있게 되었다.

Fake객체를 통한 테스트 시간 변경

인터페이스를 통해 원하는 시간으로 테스트하도록 만들었다. 프로덕션에서는 실제 LocalDateTime.now(), 테스트에서는 우리가 원하는 시간을 반환하도록 만들고 싶었다. 지난 번 프로젝트에서 여러가지 방법을 한번 시도해본 적이 있었다. 1) mockStatic을 이용한 방법, 2) Clock을 mocking 하는 방법, 3) Fake객체를 만드는 방법 이렇게 세가지를 시도했었다. mockStatic은 동시성테스트를 위해 멀티쓰레딩 테스트 환경을 만들때 문제가 생기기도 하고 기본적으로도 static은 mocking하는 것이 안티패턴으로 여겨지기도 했다. 2번과 3번의 방법 두가지를 고민했는데, 사실 어느 것을 선택해도 방식은 비슷했다. 그래서 멘토링때 강의했던 fake 객체 주입방식을 선택해서 진행했다.

TimeConfiguration 클래스를 통해 해당 Configuration을 Import한 테스트에서는 Fake 시간이 주입되도록 만들었다.

NoUniqueBeanDefinitionException 트러블 슈팅

TimeConfiguration을 만들때 겪었던 트러블슈팅이 하나 있었는데, 구현체를 반환하는 메서드명(@Bean이 붙어있는)을 실제 Bean의 이름과 똑같이 설정해주어야 한다는 것이다. 그렇지 않으면 NoUniqueBeanDefinitionException 예외가 발생한다.

Bean이 유니크 하지 않다는 예외

실제로 빈이 주입될때는 이름이 같은 것이 우선으로 주입된다. 프로덕션에서는 인터페이스에만 의존하기 때문에 TimeProvider를 의존하는데, 이때 스프링은 timeProvider라는 빈을 찾아 주입하려 한다. 처음엔 TimeConfiguration에서 메서드명을 timeProvider가 아닌 fakeTimeProvider로 했었는데, 이때 Bean의 이름이 @Bean 이 달린 메서드명으로 등록된다.

timeProvider의 구현체들 중 현재 프로덕션에서는 realTimeProvider가 컴포넌트 스캔에 의해 Bean으로 등록되었고, fakeTimeProvider 또한 Bean으로 등록되었다. 스프링은 timeProvider 라는 이름으로 관리되는 Bean을 우선적으로 주입하려 했지만 해당 이름이 없었고 다른 이름으로 2개의 빈이 띄워져있었다. 그래서 스프링 입장에서는 어떤 빈을 주입할지 모르는 상태였고 그대로 NoUniqueBeanDefinitionException 예외가 발생하게 되는 것이었다.

이를 해결하기 위해서는 FakeTimeProvider를 반환하는 메서드 이름을 fakeTimeProvider가 아닌 timeProvider로 바꿔야 했다. 그러면 FakeTimeProvider 구현체는 timeProvider 라는 이름의 빈으로 등록될 것이고 스프링은 이를 우선적으로 주입하게 되는 것이다. 프로덕션 코드에서는 프로덕션에 있는 하나의 Component만 빈으로 등록되기 때문에 신경쓰지 않아도 된다.

timeProvider가 없어 어떤 것을 주입할 지 모름

timeProvider를 우선적으로 주입함

아직 한참 남은 작업들

코드를 깔끔하게 유지하려 했지만 결국 마지막 주에는 테스트 코드 없이 배포된 코드도 있었고, 쿼리가 말도안되게 많이 나가는 요청도 있었다. 다시 프로젝트가 재개될때는 실배포를 위한 남은 기능을 완성하고, 테스트코드 없이 주석으로만 표시한 코드의 테스트 보충, 쓸데없이 많이 나가는 쿼리개선, 쿼리성능개선을 차례로 수행해야겠다.

너무 잘만난 페어

이번에 팀운이 너무 좋았다. 디자이너와 프론트분들도 잘 만났지만 백엔드 팀원도 잘 만났다. 백엔드는 2명이서 진행했는데, 스프링으로 실제 프로젝트는 처음하는 분이었지만, 흡수력이 굉장히 빨랐다. 몇주동안 만들고 버릴 프로젝트라면 파트를 나눠서 개발했겠지만, 지속해서 개발하고 싶은 마음이 있었다. 그래서 설계는 무조건 같이 진행하고 개발도 대부분 페어로 진행했다. 나눠서 개발하고 코딩컨벤션을 리뷰로 맞추는 시간보다 그냥 페어로 하나씩 같이 진행하는 것이 훨씬 빠를거라고 생각했다. 최대한 개발 스타일을 맞추고 도메인지식이 최대한 나에게 몰리지 않도록 했다. 언제든지 각자 업무를 맡아서 진행할 수 있도록 도메인 지식이 서로 동기화되는 것에 집중했고 코딩컨벤션도 맞춰나갔다. 만약 파트를 나눠서 개발했다면 한명만 빠져도 해당 프로젝트는 발전이 불가능하게 된다. 하지만 우리는 설계부터 같이 진행했기 때문에 누가 빠져도 추가로 코드를 작성할 수 있는 상태이다. 습득력이 빠른 페어덕분에 우테코에서 배워온 좋은 개발문화를 같이 나눌 수 있었고, 내가 부족한 인프라나 알고리즘부분을 페어로부터 배울 수 있었다. 페어를 하면서 서로의 장점을 배우려는 자세를 배웠다. 누군가를 설득하고 설득당하는 법에 대해서 많이 배웠다.

아쉬운 것

회고를 한번도 진행하지 못했다. 페어와도 못했고, 팀 단위로도 못했다. 다들 바쁜상태로 사이드프로젝트를 참여해서 회고하자고 따로 부르는 것이 미안했다. 그렇다고 회의 끝나고 진행하려해도 다들 너무 피곤해보였다. 그런데 이것도 다 핑계이다. 안바쁘고 안힘든 팀이 어디있을까. 지금 당장은 분위기가 괜찮은것 처럼 보여도 사람이라면 마음 한켠에 말하고 싶은 것들을 그냥 쌓아두고 있는 경우가 많다. 그리고 이런 작은 것들이 쌓여 팀이 위태해진다. 회고는 이런 팀의 지속력을 유지하고 강화시킬 수 있는 도구이다. 그걸 알면서도 안하고 있던 것이 후회된다. 프로젝트가 재개한다면, 최소 일주일에 한번은 회고할 수 있는 시간을 가져보도록 해야할 것 같다.

앞으로

이제 시작단계가 끝났다. 우리는 실서비스를 출시해야하고 운좋게 좋은 팀원들을 만난만큼 이 팀을 더욱 더 지속시킬 수 있는 방법을 고민해야한다. 8주동안 정신없이 지나갔고 힘든기간이었지만 팀원들 덕분에 웃으면서 데모데이까지 갈 수 있었다. 솔직히 말하면, 연합동아리에서는 사실 팀원들이 이렇게 좋고 잘하는 사람일거라고 기대는 안했었다. 생각보다 대단하고 멋진 사람들, 열심히하고 잘하고 재밌는 사람들이 이렇게 모일거라고 생각도 못했다. 운이 좋았던 것이라고 생각하고 이 팀을 지속하기 위한 고민을 계속해서 해 나가야겠다.

감사합니다. DND 8기 5조 여러분들 그리고 이세희 코치님도 감사합니다.

지난 2개월간의 인생 리뷰 - 멘토링

API_Dev — Sun, 5 Mar 2023 17:39:48 +0900

살면서 가장 주도적으로 살았던 기간이었다.

2개월동안, 마음속에만 품어왔던 도전들을 하나씩 꺼내보았다.

그리고 그 도전들을 하나씩 리뷰해보려고 한다.

멘토링

미니 우테코를 직접 기획하고 운영했었다.

프리코스처럼 사전과제로 지원자를 받았고, 지원자 모두에게 공통피드백을 드렸다.

멘토링 지원서 링크

4명의 멘티들을 선발했었고 4주동안 2개의 미션으로 강의, 코드리뷰, 멘토링 등을 진행했다.

[ 자동차 미션 PR ]

https://github.com/hongik-dev-mentoring/java-racingcar/pulls?q=is%3Apr+is%3Aclosed

GitHub - hongik-dev-mentoring/java-racingcar: 자동차 경주 게임 미션 저장소

자동차 경주 게임 미션 저장소. Contribute to hongik-dev-mentoring/java-racingcar development by creating an account on GitHub.

github.com

[ 로또 미션 PR]

https://github.com/hongik-dev-mentoring/java-lotto/pulls?q=is%3Apr+is%3Aclosed

GitHub - hongik-dev-mentoring/java-lotto: 로또 미션 진행을 위한 저장소

로또 미션 진행을 위한 저장소. Contribute to hongik-dev-mentoring/java-lotto development by creating an account on GitHub.

github.com

실제 멘티분들이 보셨던 멘토링 노션 페이지

Hongik-Dev-Mentoring

A new tool for teams & individuals that blends everyday work apps into one.

dongho108.notion.site

실제로 진행했던 강의들도 다 영상으로 남겨놓았다.

[ 자동차 경주 피드백 강의 영상 ]

https://www.youtube.com/watch?v=XbNpNzB_j2s

왜 이렇게 까지 했을까

내가 3학년 까지 다닐 당시 우리 학교에는 개발을 제대로 배울 수 있는 커뮤니티가 없었다. 동아리나 학회도 알고리즘 중심이고 개발을 제대로 배울 수 있는 곳이 없었다. 그렇기 때문에 휴학을 결정하고 독학기간, 우테코 기간을 통해 개발 실력을 성장시킬 수 있었다.

우테코를 하는 기간 내내 실시간으로 실력이 늘어가는 과정을 느꼈고 좋은 환경에서는 성장속도를 비약적으로 상승시킬 수 있다는 것을 깨달았다. 혼자 공부했을때는 물어볼 사람도 없었고, 내가 잘 하고있는지 알 수 있는 방법이 없었다. 이 과정을 후배들도 겪게하고 싶지 않았다. 그래서 우테코를 하는 기간동안 교육프로세스를 잘 체화하고 성장해서 학교에서 꼭 내 지식과 경험을 공유하고 싶었다.

무엇을,어떻게?

처음엔 우테코를 직접 했으니까 그대로 돌려주는 것은 쉬울 수 있겠다라고 생각했다. 직접 멘토링을 하려다보니 생각할 것들이 너무 많았다. 정말 내가 혼자서 리뷰를 다 할 수 있을까? 리뷰는 어디까지 해야될까? 어떤 강의를 어디까지 진행해야할까? 참여하는 사람들이 있을까? 제대로 할까? 얼마나 시간을 쏟을까? 등등 수백가지의 고민을 하며 기획했다.

학기중에는 학생분들이 미션을 소화할 시간이 없을 것 같았고, 사전과제를 받기 위해서는 실제 멘토링을 진행하는 기간보다 훨씬 전부터 진행해야 했다. 그렇게 깨달았을때가 1월달 초였고, 3월에 개강한다는 것을 생각해봤을때 완벽한 기획을 하고나서 모집을 하려면 늦을 것 같았다. 그래서 일단 에타에 글부터 올렸다. 급하게 멘토링용 팀 레포지토리를 파고, 우테코 프리코스 과제를 fork하고, 최소한의 사전미션을 진행하기 위한 가이드라인정도만 수정해서 모집을 시작했다. 모집을 시작하는 동시에 제대로된 일정 기획을 시작했다.

내가 이들에게 4주만에 전달할 수 있는 가치는 무엇일까? 우테코는 10개월 동안 진행되었기 때문에 그 안에서 내가 이렇게 성장할 수 있었다. 그런데 고작 4주동안 내가 이들을 성장시킬 수 있을까? 고민끝에 결정한 것은, 4주동안 이들이 배우는 것들을 모두 소화하기 보다는 앞으로 어떤 공부를 어떻게 해 나가야할지 깨달을 수 있는 것에 집중을 해야겠다고 생각했다.

그러면서도 내가 아니면 이들이 얻지 못하는 것을 얻어가면 좋겠다고 생각했다. 그렇게 뽑아낸 키워드들은 TDD, OOP, 클린코드, 페어프로그래밍이다. 단순히 강의를 듣고 프로젝트만 따라친 학생들은 이 4가지 키워드들을 제대로 학습해보지 못했을 것이다. 4주동안 이 것들이 뭔지, 어떻게 공부를 하고 앞으로 어떻게 학습해야 이 것들을 체화할 수 있을 것인지 전달하자고 결정했다.

TDD는 당연히 강의만 듣는다고 잘 하는 것이 아니다. 스스로 왜 필요한지 깨닫고 직접 코드를 작성하면서 체화를 꾸준히 해 나가야하는 것이었다. 그래서 TDD 강의에서는 테스트가 왜 필요한지, TDD를 처음에 어떻게 시작하는지만 알려주었다. 그리고 미션을 요구사항을 TDD로 진행하면서 스스로 깨달을 수 있도록 진행했다.

OOP, 클린코드는 자신이 무엇을 잘못하고 있는지 빠르게 피드백을 받는 것이 중요했다. OOP 가이드라인인 객체지향생활체조 원칙을 제공하고 이 원칙 안에서 코드리뷰를 진행했다. 그리고 리뷰에서는 왜 이렇게 작성해야 객체지향 프로그래밍에 가까워 질 수 있는지 이유를 같이 제공했다. 자신이 작성한 코드 바로 밑에 달린 리뷰를 통해 즉각적으로 어떤 코드가 어떤 코드로 바뀌어야 하는지 생각할 수 있도록 했다. 클린코드도 프로그래밍 요구사항을 제공하여 규칙 안에서 작성하도록 진행했다. 컨벤션 문서를 제공하고 메서드가 15라인을 넘지 말아야한다는 규칙과 인덴트는 1까지만 허용하는 규칙 등을 제공했다. 이 부분도 처음이라면 당연히 아무리 신경써도 요구사항에 벗어나기 쉬웠다. 그래서 리뷰에서도 이 코드 하나하나 리뷰를 남기는 방식으로 빠르게 피드백을 받을 수 있게 만들었다.

페어프로그래밍은 처음에 첫 미션부터 페어로 진행하려고 생각했었다. 실제 우테코 때는 3주동안 프리코스에서 3개의 미션을 통해 어느정도 컨벤션과 프로그래밍 요구사항에 대한 거부감을 해소하기 때문에 페어를 진행해도 수월할 수 있었던 것이고, 내가 진행하는 멘토링에서는 사전과제를 1번만 진행했기 때문에 우테코 합격자들보다 당연히 컨벤션과 프로그래밍 요구사항에 대한 거부감이 많이 있을 수 있겠다고 생각했다. 그래서 첫 미션에서는 코드리뷰를 소화하는 것만 해도 힘들것 같다고 생각해 두번째 미션부터 페어프로그래밍을 도입했다. 첫번째 미션을 통해 컨벤션과 클린코드 작성하는 방법에 대해 어느정도 잡고나서 두번째 미션때 건강한 토론이 일어날 수 있겠다고 생각했다.

실제로 마지막 미션 때는 사전과제의 코드보다 훨씬 더 나아진 퀄리티의 코드를 제출하는 멘티분들을 볼 수 있었고 너무 뿌듯했다.

후기

요즘엔 우테코의 교육방식과 비슷한 방식으로 진행하는 부트캠프나 학원들이 많아졌다. 그럼에도 우테코 수료생들이 다른 분들보다 더 나은 결과를 낼 수 있는 차이는 어떤 크루들이 모여 있는지에 달려있다고 생각한다. 주변에 잘하는 사람들이 널려있고 또 그들이 치열하게 열심히 공부하는 모습을 보는 것으로 동기부여를 받을 수 있다. 모르는 부분이나 토론할 부분이 있다면 언제든지 건강한 토론을 할 수 있는 사람들이 많았다. 멘토링을 진행하며 가장 아쉬웠던 부분은 내가 가장 크게 느꼈던 이런 토론이나 커뮤니티 부분을 경험시키지 못했다는 것이다. 비대면으로 진행하기도 했고, 이들이 알아서 잘 소통하기를 기대하고 방치했었다. 사실 비대면이기때문에 어쩔 수 없는 부분들도 있고, 4주간의 짧은 기간동안 경험하기에는 어려운 부분일 수 있다. 그래도 다음에 또 멘토링을 진행할때 이런 부분들도 제공한다면 정말 학생들에게 소중한 가치를 전달할 수 있을 것 같다.

이러한 노력을 알아주었는지 GSDC에서 후배들한테 동기부여를 줄 수 있는 기회를 받았다.

대학생활을 하면서 세상에 존재하는 여러 불편한 점들을 외면하지 말고, 내가 가진 기술로 스스로 해결하려고 도전하라는 메세지를 전달하고 왔다. 도전을 하다보면 알아서 공부도 할거고, 실패도 할거고, 그 실패들이 경험으로 쌓일거고, 돈도 벌게 될 수 있겠다는 내용을 내 경험을 통해 전달했다.

https://youtu.be/d_WXNuHOq8U

얼굴이 안나와서 아쉽다. 자막 키고 1.5배속으로 들으세요 ㅎㅎ

우테코에서 테코톡, 데모데이, 유스콘 등 여러 기술 발표를 했었다. 기술발표는 어떤 정보를 전달할 것인지가 명확해서 발표를 준비하기까지 수월했던 것 같다. 기술 학습하는 기간이 어려웠을 뿐이지 발표 자체는 틀린 내용만 아니라면 ppt를 통해 정보를 전달하면 되었었다. 하지만 이번 발표는 다르게 준비했다. 내 경험을 전달하기 위해 ppt는 거의 준비하지 않았다. 대신 내가 겪었던 어떤 경험을 어떻게 전달할 것인지에 집중했다. 남들 앞에서 썰을 잘푸는 성격이 아니다보니까 기술발표보다 스트레스를 더 많이 받았다. 경험 자체가 주관적이기도 하고, 사람들은 내 입과 표정, 몸짓, 말투에 더 집중을 하게 되는 발표이기 때문에 연기자가 된 듯이 발표준비를 했다. 그리고 어떤 가치를 전달하기 위해 이 경험을 전달할 건지도 정해야했다.

결과적으로는 연습했던것 만큼 실제로도 했던 것 같다. 초반에 사람들에게 질문도 하는 시간이 있었는데 그때 절어서 진짜 민망했다. 그래도 어차피 내가 티내지만 않으면 듣는 사람 입장에서는 크게 와닿지 않는다는 것을 알고있었기 때문에 티내지 않고 그대로 진행했다. 그리고 또 기억에 남는 아쉬웠던 점은 처음에 컴퓨터공학과에 왜 왔냐고 질문했을때 새내기가 창업하고싶다고 대답을 했었는데, 이때 대단하다는 반응을 더 해줄걸 이라는 아쉬움이다. 말을 절어서 당황하기도 했었는데, 대답을 해줬다는 것 자체도 고마웠지만 창업이라는 대단한 이유가 있었는데 이 분에게 더 특별한 연사로 남기 위해서는 대단하는 반응 정도는 해줬어야했을 것 같다.

내가 누군가에게 가치를 전달한다는 것 자체만으로도 내 인생을 보는 시야가 달라진다는 것을 깨달았다. 취준하는 기간동안 자존감도 많이 깎였고, 내가 할 수 있는 일이 아무것도 없다는 생각이 가득찼었다. 그리고나서 본가에 왔는데, 형이 그렇게 고군분투하고 치열하게 살아가고 본인의 인생을 만들어가는 것을 보면서 다시한번 내 인생에 집중해봐야겠다고 생각했다. 그리고 내가, 나만이 할 수 있는 것을 생각하고 기획했고 도전했고 나름 성공했다. 앞으로는 더 많은 도전을 해낼 수 있을 것 같다.

모두화이팅!

멘토링 도와준 숟갈이도 너무너무 고마워!

서비스 제공자의 시각으로 살아가기

API_Dev — Tue, 25 Oct 2022 22:24:02 +0900

시작

문을 열고 나오면 부쩍 쌀쌀해진 공기가 피부로 느껴진다. 옷이 한 겹씩 늘어날 때마다 올해도 점점 끝이 다가오는 것 같다. 요즘 입을 옷을 꺼내놓으면서 올해 초와 참 닮아있다는 생각이 든다. 그때도 아직은 쌀쌀한 날씨였기에 차마 얇게는 입고 다니지 못했었다. 꿈만 같았던 합격 날의 기쁨도 아직 가시지 않았었다. 나는 그토록 이곳에 왜 오고 싶어 했을까? 다시 떠올려본다.

기술이 필요했다.

창업을 하면서, 내가 고민한 결과물로 다른 사람들에게 편리함을 주는 것에 희열을 느끼고 있다는 것을 깨달았다. 책의 작은 오타가 혹시나 학생의 시험에 영향이 가진 않을지, 배송 중 책이 조금이라도 손상되어 글씨가 잘 안 보이게 되면 학생이 다른 글씨로 오해하진 않을지 학생의 시점에서 항상 고민했다. 그동안 소비자로 세상을 보던 시각이 서비스 제공자의 시각으로 바뀌게 되었다. 더 많은 사람에게 지금보다 더 편한 서비스를 제공하겠다는 꿈이 생겼다. 그리고 그 꿈을 이루기 위해 개발자가 되고 싶었다.

지금도 마음은 변하지 않았다.

언제나 개발할 때 내 모든 판단의 기준은 서비스를 사용할 사용자이다. 우아한형제들 CEO 범준 님의 말씀 중 정말 와 닿았던 말이 있다.

"고객을 위해서 내가 짠 코드를 버릴 수 있어야 한다."

말은 쉽지만 개발자로서 실천하기는 참 어렵다. 물론 고객이 직접 "이 코드 버려!" 라고 이야기하지는 않을 것이다. 범준님 말씀의 진짜 뜻은 우리가 무엇을, 누구를 위해 개발을 하는 가를 계속 생각하라는 의미인 것 같다. 서비스가 만들어진 계기는 분명히 이 서비스가 필요한 고객이 있기 때문일 것이다. 모든 요구사항을 기술적으로만 풀어낼 필요는 없지만, 적어도 "이 요구사항은 코드가 많이 바뀔 것 같아 못할 것 같아요." 라는 말은 나오지 않아야 한다. 고객이 원하는 경험을 위해서 내가 짠 코드, 설계가 많이 바뀌게 된다면 흠칫 정도는 할 수 있겠지. 하지만 그뿐이다. 언제든지 고객을 위해 내 코드를 버릴 준비가 되어있다.

가까운 곳에 있는 사용자

잘 생각해보니 내 주위에 이미 수많은 사용자가 있었다. 내 코드를 읽고 사용하게 될 동료들이 이미 주변에 있었다. "누군가를 편하게 해주고 싶다." 라는 생각을 하고 개발을 하다 보니 자연스럽게 동료들까지 생각하게 되었다. 내 코드를 쉽게 이해할 수 있게하여 더 편하게 소통하고 싶다. 앞으로도 동료들도 내 코드를 읽는 고객이라 생각하며 개발할 것이다.

수많은 고객을 만족시키기

요즘 가장 크게 느끼는 것은 한 명의 고객을 만족시키는 것보다 수많은 고객을 만족시키는 것은 훨씬 더 힘들다는 것이다. 수천만 명의 사용자를 받는 서비스는 근본적인 설계부터 달라진다. 사용자 수가 적을 때는 고려하지 않아도 될 문제들이 사용자가 많아질수록 계속 생겨난다. 결국, 내가 원하는 것은 더 많은 사람들에게 편리함을 제공하는 것이다. 수많은 고객을 만족시키기 위해 해야 할 공부들이 넘쳐난다. 내 서비스의 사용자들 모두 만족시키기 위해 수천만 명의 고객도 서비스할 수 있는 개발자가 될 것이다.

또, 시작

이미 시작했고, 지금은 또 다른 시작이다. 기술을 가지고 싶어 했고, 지금은 어느 정도 기술을 갖추었다. 처음 개발을 시작할 때의 마음가짐 또한 아직 가지고 있다. 그리고 내 블로그에 적힌 글귀처럼 이 열정은 차갑고 잔잔하게 유지하려고 한다.

고객을 만족시키는 것이 내 행복이라면, 무엇이 먼저였을까. 답은 아직 모르겠다. 정말 많은 사람을 편리하게 만들어 주다 보면, 또 그러기 위해 노력하다 보면 알게 되겠지.

[DI 구현하기] 의존성 주입이 필요한 이유와 DI 컨테이너의 탄생

API_Dev — Mon, 3 Oct 2022 22:12:08 +0900

스프링을 사용하는 핵심이유중 하나는 DI (Dependency Injection) 의존성 주입입니다.

우리는 의존성 주입이 왜 필요한 것인지, 또 스프링이 의존성 주입을 어떻게 해주는지 제대로 이해하고 사용하고 있을까요?

간단한 UserService와 UserDao 예제로 의존성 주입이 왜 필요한 것인지 간단히 이해해보고, 나아가서 스프링이 제공하는 DI 컨테이너를 직접 만들어 보겠습니다.

1단계 : 생성자 주입(?)

현재, 사용할 UserDao 인스턴스를 생성자를 통해 외부에서 전달받는 UserService가 존재합니다.

UserService

class UserService {

    private final UserDao userDao;

    public UserService(UserDao userDao) {
        this.userDao = userDao;
    }

    public User join(User user) {
        userDao.insert(user);
        return userDao.findById(user.getId());
    }
}

UserDao

class UserDao {

    private static final Map<Long, User> users = new HashMap<>();

    private final JdbcDataSource dataSource;

    public UserDao() {
        final var jdbcDataSource = new JdbcDataSource();
        jdbcDataSource.setUrl("jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;");
        jdbcDataSource.setUser("");
        jdbcDataSource.setPassword("");

        this.dataSource = jdbcDataSource;
    }

    public void insert(User user) {
        try (final var connection = dataSource.getConnection()) {
            users.put(user.getId(), user);
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    public User findById(long id) {
        try (final var connection = dataSource.getConnection()) {
            return users.get(id);
        } catch (SQLException e) {
            return null;
        }
    }
}

위와 같은 코드의 문제점은 무엇일까요?

개발자가 위의 코드를 이용해 UserServiceTest를 작성하려고 합니다.

그런데, DB 없이 돌아가는 테스트를 작성하기 위해서 어떻게 해야할까요?

UserDao가 Jdbc에 직접 의존하고 있기 때문에 현재 구조에서는 방법이 없습니다.

DB에 연결하지 않고 테스트를 짤 수 없습니다.

떠오르는 하나의 방법은,

Jdbc에 의존하지 않는 DAO를 새로 생성해 UserService 코드상 에서 교체해준뒤, 외부에서도 새로운 DAO를 전달해주는 방법이 있을 수 있습니다.

그런데 이 방법은 문제점이 존재합니다.

UserDao의 변경을 위해 UserService의 코드를 변경해주어야 합니다.

UserDao를 사용하는 클래스가 수백개 있다고 가정하면 UserDao를 교체하기 위해 수백개의 클래스를 직접 다 수정해주어야 합니다.

위와 같은 문제점을 해결하기 위해서는 객체지향의 5가지 원칙중 하나인 DIP (구현 클래스에 의존하지 않고 인터페이스에 의존해라)를 만족하게 하면 됩니다.

UserService가 UserDao 인터페이스에 의존하도록 바꿔보겠습니다.

2단계 : 인터페이스에 의존하기

구현체들이 사용할 메서드 명세만 작성해놓은 UserDao interface를 만듭니다.

UserDao interface

interface UserDao {

    void insert(User user);

    User findById(long id);
}

UserService는 UserDao 인터페이스에만 의존하도록 구현합니다.

또한, 외부에서 사용할 UserDao의 구현체를 주입받습니다.

UserService

class UserService {

    private final UserDao userDao;

    public UserService(UserDao userDao) {
        this.userDao = userDao;
    }

    public User join(User user) {
        userDao.insert(user);
        return userDao.findById(user.getId());
    }
}

1단계와 똑같이 위의 코드로 DB 없이 돌아가는 UserServiceTest를 작성하려고 합니다.

이제 UserService가 UserDao 인터페이스에만 의존하고 있기 때문에 외부에서 DB없이 돌아가는 구현체를 주입해주면 됩니다.

UserServiceTest

InMemoryUserDao() 라는 메모리 상에서 돌아가는 DB를 구현한뒤 UserService에 주입해줍니다.

    @Test
    void joinTest() {
        final var user = new User(1L, "ash");

        final UserDao userDao = new InMemoryUserDao();
        final var userService = new UserService(userDao);

        final var actual = userService.join(user);

        assertThat(actual.getAccount()).isEqualTo("ash");
    }

인터페이스에만 의존하도록 수정했더니 UserDao의 변경이 UserService에게 영향을 미치지 않게 되었습니다.

그런데 아직도 문제가 존재합니다.

UserDao 구현체를 변경하기 위해서는 UserService를 사용하는 어딘가에서 구현체를 결정하고 주입해주어야 한다는 것입니다.

UserController

UserController에서 UserDao의 구현체를 결정해주고 있습니다.

@Controller
public class UserController {
    private UserService userService;

    @PostMapping("/api/user")
    public String join(final Long id, final String name) {
        final var user = new User(1L, "gugu");
        
        userService = new UserService(new InMemoryUserDao());
        userService.join(user);
        return "index.html";
    }
}

분명히 인터페이스에 의존하게 변경했는데도 어딘가에서는 UserDao의 변경에 영향이 가는 곳이 존재합니다.

왜 이런 문제가 발생한 것일까요?

관계설정 책임

UserService를 사용하는 곳에서는 자신과는 상관없는 UserDao 구현체를 결정해준다는 책임이 숨어있습니다.

UserController

UserController에서 UserDao의 구현체를 결정해주고 있습니다.

@Controller
public class UserController {
    private UserService userService;

    @PostMapping("/api/user")
    public String join(final Long id, final String name) {
        final var user = new User(1L, "ash");
        
        userService = new UserService(new InMemoryUserDao());
        userService.join(user);
        return "index.html";
    }
}

UserController에게 UserDao 구현체를 결정해줘야된다는 책임이 필요할까요?

이 관계설정의 관심사를 분리하지 않으면 결국에는 UserDao가 확장 가능한 클래스라고 볼 수는 없습니다.

3단계 : DI Container

관계 설정의 관심사(책임)을 분리하기 위해서는 어떻게 해야 할까요?

전혀 다른 외부에서 책임을 가지도록 구현하면 됩니다. (제어의 역전. IoC)

관계설정만 하는 책임을 가지는 클래스로 분리를 하면 됩니다.

그리고 이런 객체를 생성하고 연결해주는 역할을 하는 클래스를 DI Container 라고 합니다.

객체가 사용할 구현체를 능동적으로 결정하는 것이 아니라 외부의 다른 객체에게 제어권한을 넘깁니다.

DI Container가 객체를 생성하고 관계를 설정하고,

UserService가 DI Container에게 모든 제어 권한을 위임하도록 구현해보겠습니다.

UserService는 DIContainer로 부터 사용할 인스턴스를 제공받습니다.

이 인스턴스 안에는 사용할 UserDao 구현체도 결정되어있죠.

    @Test
    void stage3() {
        final var user = new User(1L, "ash");

        final var diContainer = createDIContainer();

        final var userService = diContainer.getBean(UserService.class);

        final var actual = userService.join(user);

        assertThat(actual.getAccount()).isEqualTo("gugu");
    }

    /**
     * DIContainer가 관리하는 객체는 빈(bean) 객체라고 부른다.
     */
    private static DIContainer createDIContainer() {
        var classes = new HashSet<Class<?>>();
        classes.add(InMemoryUserDao.class);
        classes.add(UserService.class);
        return new DIContainer(classes);
    }

DI Container

제가 구현한 DI Container의 원리는 간단하게 아래와 같습니다.

생성자를 통해 컨테이너가 관리할 빈을 등록합니다.
컨테이너는 빈을 전달받을 클래스를 인스턴스화해서 가지고 있습니다.
그리고 한번 인스턴스화 된 빈을 계속 사용합니다.
빈으로 등록될 객체가 들고있는 필드가 빈으로 등록되어있으면 걔네들도 주입합니다.

/**
 * 스프링의 BeanFactory, ApplicationContext에 해당되는 클래스
 */
class DIContainer {

    private final Set<Object> beans = new HashSet<>();

    // TODO: 같은 클래스로 여러 빈 등록 불가하게 수정해야한다.
    public DIContainer(final Set<Class<?>> classes) {
        // 클래스를 인스턴스화 해서 Set에 저장
        initBean(classes);
        // 빈의 필드에 빈으로 등록할 수 있는 필드 등록
        beans.forEach(this::setFields);
    }

    private void initBean(final Set<Class<?>> classes) {
        try {
            for (Class<?> aClass : classes) {
                addBeans(aClass);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    private void setFields(final Object bean) {
        // 필드가 빈으로 등록되어있으면 주입한다.
        final List<Field> fields = List.of(bean.getClass().getDeclaredFields());
        fields.forEach(field -> setField(bean, field));
    }

    private void setField(final Object obj, final Field field) {
        field.setAccessible(true);
        beans.forEach(bean -> setFieldValue(obj, field, bean));
    }

    private void setFieldValue(final Object obj, final Field field, final Object bean) {
        final Class<?> fieldType = field.getType();
        if (fieldType.isInstance(bean)) {
            try {
                field.set(obj, bean);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }

    private void addBeans(final Class<?> aClass)
            throws NoSuchMethodException, InstantiationException, IllegalAccessException, InvocationTargetException {
        final Constructor<?> constructor = aClass.getDeclaredConstructor();
        constructor.setAccessible(true);
        final Object instance = constructor.newInstance();
        beans.add(instance);
    }

    @SuppressWarnings("unchecked")
    public <T> T getBean(final Class<T> aClass) {
        return (T) beans.stream()
                .filter(aClass::isInstance)
                .findFirst()
                .orElseThrow(() -> new NoSuchElementException("등록된 빈이 아닙니다."));
    }
}

기본생성자로 리플렉션을 이용해 인스턴스를 생성하는 부분,

필드들을 읽어서 해당필드의 타입이 빈으로 등록된 인스턴스중 같은 타입이면 필드에도 주입해주는 부분

들이 이해하기 어려울 수 있지만 여러번 읽어보면 또 쉽게 이해할 수 있습니다.

4단계 : 어노테이션 기반 DI 컨테이너

지금도 DI 컨테이너는 자신의 책임에 맞게 잘 동작하고 있습니다.

하지만 개발자는 매번 빈을 직접 등록해주는 일도 번거롭습니다.

그리고 어떤 클래스가 빈으로 등록되는 클래스인지 알기 위해서는 DI컨테이너까지 가봐야 알 수 있습니다.

저희는 스프링을 사용할 때 어노테이션 기반으로 빈들을 등록하고 있습니다.

클래스 위에 어노테이션으로 이 클래스는 빈으로 등록된다는 것을 명시합니다.

그리고 이것은 InterviewService의 @Service에 해당하는 부분입니다.

Service 어노테이션 클래스 안에는 @Component 가 있습니다.

사실 @Component 가 빈으로 등록된다는 것을 명시하는 어노테이션 입니다.

이처럼 어노테이션 기반의 DI컨테이너를 만들면 개발자는 어떤 설정파일에 직접 빈을 등록할 필요 없이 클래스 위에 어노테이션을 붙이는 것 만으로도 객체를 빈으로 등록해 관리할 수 있습니다.

어노테이션 기반의 DI 컨테이너를 직접 구현해보겠습니다.

저희는 간단하게 @Service, @Repository 어노테이션이 붙은 클래스, 더해서 @Inject 어노테이션이 붙은 필드의 의존성을 자동으로 주입해보겠습니다.

(@Inject 는 @Autowired에 해당하는 어노테이션 이라고 봐도 무방합니다.)

DIContainer

createContainerForPakage 에서는 전달받은 rootPakageName을 루트로 가지는 모든 클래스들 가져오고
이 클래스들 중 @Service, @Repository 어노테이션이 붙은 클래스를 추출하고,
추출된 클래스들을 빈으로 등록합니다.

    ...
    public static DIContainer createContainerForPackage(final String rootPackageName) {
        // @Service 가 붙은 클래스들의 인스턴스를 bean으로 등록하자.
        final Set<Class<?>> allClasses = ClassPathScanner.getAllClassesInPackage(rootPackageName);
        final Set<Class<?>> injectClasses = allClasses.stream()
                .filter(DIContainer::isComponent)
                .collect(Collectors.toSet());
        return new DIContainer(injectClasses);
    }

    private static boolean isComponent(final Class<?> aClass) {
        return aClass.isAnnotationPresent(Service.class)
                || aClass.isAnnotationPresent(Repository.class);
    }
    ...

setField 에서는 모든 필드의 의존성을 주입하는 것이 아닌, @Inject 가 붙어있는 필드에만 의존성을 주입합니다.

...
// @Inject 붙은 필드의 의존성을 주입해준다.
    private void setFields(final Object bean) {
        final List<Field> fields = List.of(bean.getClass().getDeclaredFields());
        final List<Field> injectFields = fields.stream()
                .filter(field -> field.isAnnotationPresent(Inject.class))
                .collect(Collectors.toList());
        injectFields.forEach(field -> setField(bean, field));
    }
    ...

UserService

UserDao 인터페이스를 필드로 가지고 있지만 구현체를 할당하는 코드가 존재하지 않습니다.

하지만 DI 컨테이너에서 @Inject 가 붙은 필드에 의존성을 주입해주기 때문에 런타임에는 구현체를 가지고 있습니다.

@Service
class UserService {

    @Inject
    private UserDao userDao;

    public User join(final User user) {
        userDao.insert(user);
        return userDao.findById(user.getId());
    }

    private UserService() {}
}

마무리

토비의 스프링 1권 p.378~379

그래서 적절하게 책임과 관심이 다른 코드를 분리하고, 서로 영향을 주지 않도록 다양한 추상화 기법을 도입하고, 애플리케이션 로직과 기술/환경을 분리하는 등의 작업은 갈수록 복잡해지는 엔터프라이즈 애플리케이션에는 반드시 필요하다. 이를 위한 핵심적인 도구가 바로 스프링이 제공하는 DI다. 스프링의 DI가 없었다면 인터페이스를 도입해서 나름 추상화를 했더라도 적지 않은 코드 사이의 결합이 남아있게 된다.

스프링의 의존관계 주입 기술인 DI는 모든 스프링 기술의 기반이 되는 핵심 엔진이자 원리이며, 스프링이 지지하고 지원하는, 좋은 설계와 코드를 만드는 모든 과정에서 사용되는 가장 중요한 도구다. 스프링을 DI 프레임워크라고 부르는 이유는 외부 설정정보를 통한 런타임 오브젝트 DI라는 단순한 기능을 제공하기 때문이 아니다. 오히려 스프링이 DI에 담긴 원칙과 이를 응용하는 프로그래밍 모델을 자바 엔터프라이즈 기술의 많은 문제를 해결하는 데 적극적으로 활용하고 있기 때문이다. 또, 스프링과 마찬가지로 스프링을 사용하는 개발자가 만드는 애플리케이션 코드 또한 이런 DI를 활용해서 깔끔하고 유연한 코드와 설계를 만들어낼 수 있도록 지원하고 지지해주기 때문이다.

스프링 프레임워크의 핵심 기술인 어노테이션 기반의 DI 컨테이너를 직접 구현하면서 스프링 DI에 대한 이해도를 높여보았습니다.

저희가 스프링을 사용하지 않았다면 결국엔 직접 구현체를 넣어주거나 DI 컨테이너를 따로 구현해주어야 했을 것입니다.

스프링이 DI를 해주는 덕분에 저희는 애플리케이션 코드에만 집중할 수 있고 더 깔끔하고 유연한 설계를 할 수 있었습니다.

고마워 최고스프링아

[Servlet 구현하기] Controller Scanner와 JSON View

API_Dev — Thu, 29 Sep 2022 22:23:04 +0900

지난 시간에 어노테이션 기반의 MVC 프레임워크를 만들어 보았습니다.

아직은 개선할 점이 있었습니다.

컨트롤러 어노테이션 스캔 역할 분리
JSON view 지원

프레임워크에서 기본으로 어노테이션 핸들러 지원하기

위의 개선점들을 해결하기 전에, 생각해봐야할 점이 있었습니다.

MVC 프레임워크 패키지가 아닌 APP (어플리케이션) 패키지에서 지원하는 핸들러와 어댑터를 추가해주고 있었습니다.

저희가 스프링 MVC를 사용할때 어노테이션 매핑을 따로 추가해주지 않아도 기본으로 지원하는 것 처럼, 개발자는 어노테이션 매핑에 대한 추가설정 없이 기본적으로 제공받도록 구현하고 싶었습니다.

그래서 MVC 프레임워크 패키지에 DefaultApplicationInitializer를 만들어주었습니다.

package nextstep.mvc.config;

import jakarta.servlet.ServletContext;
import jakarta.servlet.ServletException;
import nextstep.mvc.AnnotationHandlerAdapter;
import nextstep.mvc.DispatcherServlet;
import nextstep.mvc.controller.tobe.AnnotationHandlerMapping;
import nextstep.web.WebApplicationInitializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class DefaultAppWebApplicationInitializer implements WebApplicationInitializer {

    private static final Logger log = LoggerFactory.getLogger(DefaultAppWebApplicationInitializer.class);

    @Override
    public void onStartup(final ServletContext servletContext) throws ServletException {
        final var dispatcherServlet = DispatcherServlet.getInstance();
        dispatcherServlet.addHandlerMapping(new AnnotationHandlerMapping());
        dispatcherServlet.addHandlerAdapter(new AnnotationHandlerAdapter());

        final var dispatcher = servletContext.addServlet("dispatcher", dispatcherServlet);
        dispatcher.setLoadOnStartup(1);
        dispatcher.addMapping("/");

        log.info("Start DefaultAppWebApplication Initializer");
    }
}

개발자 영역에서는 기본으로 제공되는 어노테이션 뿐만 아니라 추가로 사용하고 싶은 핸들러와 어댑터를 DispatcherServlet에 넣어주면 됩니다.

package com.techcourse.config;

import jakarta.servlet.ServletContext;
import nextstep.mvc.DispatcherServlet;
import nextstep.web.WebApplicationInitializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class AppWebApplicationInitializer implements WebApplicationInitializer {

    private static final Logger log = LoggerFactory.getLogger(AppWebApplicationInitializer.class);

    @Override
    public void onStartup(final ServletContext servletContext) {
        final var dispatcherServlet = DispatcherServlet.getInstance();
        dispatcherServlet.addHandlerMapping(new ManualHandlerMapping());
        dispatcherServlet.addHandlerAdapter(new ManualHandlerAdapter());
        log.info("Start AppWebApplication Initializer");
    }
}

여기서 바뀐점이 있는데요.

DispatcherServlet을 싱글톤으로 받고있는 부분입니다.

App 패키지에서 추가하는 핸들러와 어댑터들도 같은 DispatcherServlet 에 등록이 되도록 싱글톤으로 구현했습니다.

public class DispatcherServlet extends HttpServlet {

    private static final long serialVersionUID = 1L;
    private static final Logger log = LoggerFactory.getLogger(DispatcherServlet.class);

    private final List<HandlerMapping> handlerMappings;
    private final List<HandlerAdapter> handlerAdapters;

    private DispatcherServlet() {
        this.handlerMappings = new ArrayList<>();
        this.handlerAdapters = new ArrayList<>();
    }

    public static class DispatcherServletGenerator {
        private static final DispatcherServlet INSTANCE = new DispatcherServlet();
    }
    public static DispatcherServlet getInstance() {
        return DispatcherServletGenerator.INSTANCE;
    }
    ...
}

하지만 여기서주의해야 할 점은 실제로 서블릿 컨테이너가 서블릿에 대해 싱글톤을 보장하지는 않는다는 점입니다.

실제 기본 서블릿의 경우 서블릿 컨테이너가 서블릿 선언당 인스턴스를 1개만 사용하기는 하지만, SingleThreadModel 인터페이스를 구현하는 서블릿의 경우 많은 요청을 처리하기 위해 여러 인스턴스를 만들어 사용합니다.

정리하면, 기본적으로 동일한 웹 앱에서 서블릿 선언당 인스턴스를 1개만 사용하기는 하지만, 여러 개의 인스턴스화를 막고있진 않기 때문에 서블릿은 싱글톤이 아닙니다.

저는 구현 편의상 싱글톤으로 구현했습니다.

Controller Scanner

아래와 같이 리플렉션으로 컨트롤러를 읽어오는 코드가 AnnotationHandlerMapping에 존재하고

이 과정에서 적지 않은 코드가 발생하는 것을 볼 수 있습니다.

public class AnnotationHandlerMapping implements HandlerMapping {

    private static final Logger log = LoggerFactory.getLogger(AnnotationHandlerMapping.class);
    private static final Class<RequestMapping> REQUEST_MAPPING_ANNOTATION_CLASS = RequestMapping.class;
    private static final Class<Controller> CONTROLLER_ANNOTATION_CLASS = Controller.class;

    private final Object[] basePackage;
    private final Map<HandlerKey, HandlerExecution> handlerExecutions;

    public AnnotationHandlerMapping(final Object... basePackage) {
        this.basePackage = basePackage;
        this.handlerExecutions = new HashMap<>();
    }

    public void initialize() {
        final Reflections reflections = new Reflections(basePackage);
        final Set<Class<?>> classes = reflections.getTypesAnnotatedWith(CONTROLLER_ANNOTATION_CLASS);

        for (Class<?> clazz : classes) {
            Object instance = getInstance(clazz);
            final List<Method> methods = getRequestMappingMethods(clazz);
            methods.forEach(method -> putHandlerExecutionByRequestMapping(instance, method));
        }
        log.info("Initialized AnnotationHandlerMapping!");
    }

    private Object getInstance(final Class<?> clazz) {
        try {
            final Constructor<?> constructor = clazz.getConstructor();
            return constructor.newInstance();
        } catch (NoSuchMethodException exception) {
            log.error(exception.getMessage());
            throw new IllegalArgumentException("생성자를 가져올 수 없습니다. " + clazz.getName());
        } catch (InstantiationException
                | IllegalAccessException
                | InvocationTargetException exception){
            log.error(exception.getMessage());
            throw new IllegalArgumentException("인스턴스화할 수 없습니다. " + clazz.getName());
        }
    }
    ...
}

ControllerScanner에게

리플렉션으로 컨트롤러가 붙은 클래스를 읽고
인스턴스화해서 Map으로 반환하는

역할을 부여하였습니다.

package nextstep.mvc.controller.annotation;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
import nextstep.web.annotation.Controller;
import org.reflections.Reflections;

public class ControllerScanner {

    private static final Class<Controller> CONTROLLER_ANNOTATION_CLASS = Controller.class;

    private final Reflections reflections;

    public ControllerScanner(final Object[] basePackage) {
        this.reflections = new Reflections(basePackage);
    }

    public Map<Class<?>, Object> getControllers() {
        final Set<Class<?>> classes = reflections.getTypesAnnotatedWith(CONTROLLER_ANNOTATION_CLASS);
        return instantiateControllers(classes);
    }

    private Map<Class<?>, Object> instantiateControllers(final Set<Class<?>> classes) {
        final Map<Class<?>, Object> controllers = new HashMap<>();
        for (Class<?> controller : classes) {
            controllers.put(controller, getInstance(controller));
        }
        return controllers;
    }

    private Object getInstance(final Class<?> clazz) {
        try {
            final Constructor<?> constructor = clazz.getConstructor();
            return constructor.newInstance();
        } catch (NoSuchMethodException exception) {
            throw new IllegalArgumentException("생성자를 가져올 수 없습니다. " + clazz.getName());
        } catch (InstantiationException
                | IllegalAccessException
                | InvocationTargetException exception){
            throw new IllegalArgumentException("인스턴스화할 수 없습니다. " + clazz.getName());
        }
    }
}

AnnotationHandlerMapping은 ControllerScanner로 부터 컨트롤러 인스턴스를 받고 각 인스턴스로부터 메서드를 추출해 HandlerExecutions에 추가해줍니다.

public class AnnotationHandlerMapping implements HandlerMapping {

    private static final Logger log = LoggerFactory.getLogger(AnnotationHandlerMapping.class);
    private static final Class<RequestMapping> REQUEST_MAPPING_ANNOTATION_CLASS = RequestMapping.class;

    private final Object[] basePackage;
    private final Map<HandlerKey, HandlerExecution> handlerExecutions;

    public AnnotationHandlerMapping(final Object... basePackage) {
        this.basePackage = basePackage;
        this.handlerExecutions = new HashMap<>();
    }

    public void initialize() {
        final ControllerScanner controllerScanner = new ControllerScanner(basePackage);
        final Map<Class<?>, Object> controllers = controllerScanner.getControllers();
        for (Class<?> aClass : controllers.keySet()) {
            final List<Method> methods = getRequestMappingMethods(aClass);
            methods.forEach(method -> putHandlerExecutionByRequestMapping(controllers.get(aClass), method));
        }
        log.info("Initialized AnnotationHandlerMapping!");
    }

    private List<Method> getRequestMappingMethods(final Class<?> clazz) {
        return Arrays.stream(clazz.getDeclaredMethods())
                .filter(method -> method.isAnnotationPresent(REQUEST_MAPPING_ANNOTATION_CLASS))
                .collect(Collectors.toList());
    }
    ...
}

JSON View

Jsp view만 지원하는 것이 아닌 Json view로도 반환하고 싶었습니다.

View 인터페이스를 구현하여 render에서 response body에 model 데이터를 json 형식으로 변환해 넣어주도록 구현했습니다.

public class JsonView implements View {

    @Override
    public void render(final Map<String, ?> model, final HttpServletRequest request, HttpServletResponse response)
            throws Exception {

        final ObjectMapper objectMapper = new ObjectMapper();
        final String body = objectMapper.writeValueAsString(model);

        response.setContentType(APPLICATION_JSON_UTF8_VALUE);
        response.getWriter().write(body);
    }
}

사용할 때는

ModelAndView를 생성할때 어떤 view를 사용할 것인지 넣어주고
ModelAndView의 Object에 user 데이터를 넣어주면
DispatcherServlet이 render를 호출합니다.

@Controller
public class UserController {

    private static final Logger log = LoggerFactory.getLogger(UserController.class);

    @RequestMapping(value = "/api/user", method = GET)
    public ModelAndView show(final HttpServletRequest request, final HttpServletResponse response) {
        log.info("test controller api");
        final String account = request.getParameter("account");
        log.debug("user id : {}", account);

        final ModelAndView modelAndView = new ModelAndView(new JsonView());
        final User user = InMemoryUserRepository.findByAccount(account)
                .orElseThrow();

        modelAndView.addObject("user", user);
        return modelAndView;
    }
}

DispatcherServlet

   ...
   @Override
    protected void service(final HttpServletRequest request, final HttpServletResponse response) throws ServletException {
        log.debug("Method : {}, Request URI : {}", request.getMethod(), request.getRequestURI());

        try {
            final var handler = handlerMappingRegistry.getHandler(request);
            final HandlerAdapter handlerAdapter = handlerAdapterRegistry.getHandlerAdapter(handler);
            final ModelAndView modelAndView = handlerAdapter.handle(request, response, handler);
            render(modelAndView, request, response);
        } catch (Throwable e) {
            log.error("Exception : {}", e.getMessage(), e);
            throw new ServletException(e.getMessage());
        }
    }

    private void render(final ModelAndView modelAndView, final HttpServletRequest request, final HttpServletResponse response)
            throws Exception {
        modelAndView.render(request, response);
    }
    ...

요청 처리 확인

URL : /api/user

Method : GET

정리

자바의 서블릿을 구현해보았고, 실제로 스프링 MVC에서는 자바의 서블릿을 DispatcherServlet으로 사용하고 있었습니다.

지금까지 어노테이션 기반의 MVC 프레임워크를 만들어 컨트롤러를 스캔해보고 jsp가 아닌 다른형식의 view도 지원하도록 만들어 보았습니다.

MVC

Model, View, Controller 를 나누는 이유에 대해서 더 명확하게 이해를 할 수 있었습니다.

그리고 이들이 해주는 행위에 대해서도 직접 구현해보면서 확실히 알게되었습니다.

다음목표는..

스프링의 핵심원리 중 하나인 DI(Dependency Injection)를 직접 구현해보도록 하겠습니다.

참고자료

dispatcher servlet : https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-servlet
Is Servlet the singleton? : https://stackoverflow.com/questions/11820840/is-servlet-the-singleton
https://jcp.org/en/jsr/detail?id=315

[Servlet 구현하기] 어노테이션 기반 MVC 프레임워크 구현

API_Dev — Mon, 19 Sep 2022 11:57:26 +0900

톰캣 코드 저장소 : https://github.com/dongho108/jwp-dashboard-http/tree/step234
어노테이션기반 MVC 프레임워크 코드 저장소 : https://github.com/dongho108/jwp-dashboard-mvc/tree/step1

지난 시간에는 서블릿 컨테이너인 톰캣을 구현해보았습니다.

구현했던 톰캣 기능

요청당 쓰레드 생성 (쓰레드관리)
커넥션관리
서버소켓 생성
HttpRequest, HttpResponse 변환
컨트롤러 찾기
컨트롤러 실행

그래서 4~6번은 아래와 같은 구조가 만들어졌습니다.

위와 같은 구조에는 문제점이 있었습니다.

Request에 맞는 Controller를 찾아주는 메서드와 클래스가 전혀 다른 곳에 있는 패키지를 의존하고 있습니다.

사실 비즈니스 로직에 컨트롤러가 추가된다고 스프링 코드가 변화하지는 않죠.

프레임워크는 비즈니스 로직과 완전 분리되어야 한다는 뜻입니다.

그렇다면 어떻게 스프링은 계속 변화하는 비즈니스 코드를 알고 Controller를 매핑시켜주는 것일까요?

어노테이션 기반 MVC 프레임워크

아래와 같은 코드의 컨트롤러를 비즈니스로직에서 작성하고, HandlerMapping에서 자동으로 읽어올 수 있게 만들어 보겠습니다.

@Controller
public class TestController {

    private static final Logger log = LoggerFactory.getLogger(TestController.class);

    @RequestMapping(value = "/get-test", method = RequestMethod.GET)
    public ModelAndView findUserId(final HttpServletRequest request, final HttpServletResponse response) {
        log.info("test controller get method");
        final var modelAndView = new ModelAndView(new JspView(""));
        modelAndView.addObject("id", request.getAttribute("id"));
        return modelAndView;
    }

    @RequestMapping(value = "/post-test", method = RequestMethod.POST)
    public ModelAndView save(final HttpServletRequest request, final HttpServletResponse response) {
        log.info("test controller post method");
        final var modelAndView = new ModelAndView(new JspView(""));
        modelAndView.addObject("id", request.getAttribute("id"));
        return modelAndView;
    }
}

interface HandlerMapping

public interface HandlerMapping {

    void initialize();

    Object getHandler(HttpServletRequest request);
}

class AnnotationHandlerMapping

initialize()에서는 리플렉션으로 @Controller 어노테이션이 붙어있는 클래스들을 가져옵니다.

클래스의 각 메서드들을 HandlerExcecution 클래스로 만들어 Map에 넣어줍니다.

getHandler()에서는 request에서 url, method를 key로 작업을 수행할 HandlerExcecution을 가져올 수 있습니다.

public class AnnotationHandlerMapping implements HandlerMapping {

    private static final Logger log = LoggerFactory.getLogger(AnnotationHandlerMapping.class);
    private static final Class<RequestMapping> REQUEST_MAPPING_ANNOTATION_CLASS = RequestMapping.class;
    private static final Class<Controller> CONTROLLER_ANNOTATION_CLASS = Controller.class;

    private final Object[] basePackage;
    private final Map<HandlerKey, HandlerExecution> handlerExecutions;

    public AnnotationHandlerMapping(final Object... basePackage) {
        this.basePackage = basePackage;
        this.handlerExecutions = new HashMap<>();
    }

    public void initialize() {
        final Reflections reflections = new Reflections(basePackage);
        final Set<Class<?>> classes = reflections.getTypesAnnotatedWith(CONTROLLER_ANNOTATION_CLASS);

        for (Class<?> clazz : classes) {
            Object instance = getInstance(clazz);
            final List<Method> methods = getRequestMappingMethods(clazz);
            methods.forEach(method -> putHandlerExecutionByRequestMapping(instance, method));
        }
        log.info("Initialized AnnotationHandlerMapping!");
    }
    
    public Object getHandler(final HttpServletRequest request) {
        final String requestURI = request.getRequestURI();
        final String method = request.getMethod();
        final RequestMethod requestMethod = RequestMethod.valueOf(method);
        final HandlerKey handlerKey = new HandlerKey(requestURI, requestMethod);

        if (handlerExecutions.containsKey(handlerKey)) {
            return handlerExecutions.get(handlerKey);
        }

        throw new NotFoundHandlerException(requestURI, method);
    }
    ...
}

HandlerKey

HandlerExecution을 가져오기위해 url, method를 묶은 VO입니다.

public class HandlerKey {

    private final String url;
    private final RequestMethod requestMethod;

    public HandlerKey(final String url, final RequestMethod requestMethod) {
        this.url = url;
        this.requestMethod = requestMethod;
    }

    @Override
    public String toString() {
        return "HandlerKey{" +
                "url='" + url + '\'' +
                ", requestMethod=" + requestMethod +
                '}';
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof HandlerKey)) return false;
        HandlerKey that = (HandlerKey) o;
        return Objects.equals(url, that.url) && requestMethod == that.requestMethod;
    }

    @Override
    public int hashCode() {
        return Objects.hash(url, requestMethod);
    }
}

HandlerExecution

컨트롤러의 메서드를 대신 실행시켜주는 녀석입니다.

현재 제가 만들고 있는 어노테이션 기반의 컨트롤러는 HandlerExecution을 이용해야만 실행시킬 수 있습니다.

(이 말을 잘 기억해주세요.)

public class HandlerExecution {

    private final Object object;
    private final Method method;

    public HandlerExecution(final Object object, final Method method) {
        this.object = object;
        this.method = method;
    }

    public ModelAndView handle(final HttpServletRequest request, final HttpServletResponse response) throws Exception {
        return (ModelAndView) method.invoke(object, request, response);
    }
}

Test

제가 만든 어노테이션기반의 핸들러매핑이 잘 동작하는지 확인해보겠습니다.

위에서 정의한 TestController

@Controller
public class TestController {

    private static final Logger log = LoggerFactory.getLogger(TestController.class);

    @RequestMapping(value = "/get-test", method = RequestMethod.GET)
    public ModelAndView findUserId(final HttpServletRequest request, final HttpServletResponse response) {
        log.info("test controller get method");
        final var modelAndView = new ModelAndView(new JspView(""));
        modelAndView.addObject("id", request.getAttribute("id"));
        return modelAndView;
    }

    @RequestMapping(value = "/post-test", method = RequestMethod.POST)
    public ModelAndView save(final HttpServletRequest request, final HttpServletResponse response) {
        log.info("test controller post method");
        final var modelAndView = new ModelAndView(new JspView(""));
        modelAndView.addObject("id", request.getAttribute("id"));
        return modelAndView;
    }
}

TestController가 속한 pakage 이름을 AnnotationHandlerMapping 생성자의 매개변수로 넣어줍니다.

그리고 초기화를 시켜줍니다.

class AnnotationHandlerMappingTest {

    private AnnotationHandlerMapping handlerMapping;

    @BeforeEach
    void setUp() {
        handlerMapping = new AnnotationHandlerMapping("samples");
        handlerMapping.initialize();
    }

    @Test
    void get() throws Exception {
        final var request = mock(HttpServletRequest.class);
        final var response = mock(HttpServletResponse.class);

        when(request.getAttribute("id")).thenReturn("gugu");
        when(request.getRequestURI()).thenReturn("/get-test");
        when(request.getMethod()).thenReturn("GET");

        final var handlerExecution = (HandlerExecution) handlerMapping.getHandler(request);
        final var modelAndView = handlerExecution.handle(request, response);

        assertThat(modelAndView.getObject("id")).isEqualTo("gugu");
    }

    @Test
    void post() throws Exception {
        final var request = mock(HttpServletRequest.class);
        final var response = mock(HttpServletResponse.class);

        when(request.getAttribute("id")).thenReturn("gugu");
        when(request.getRequestURI()).thenReturn("/post-test");
        when(request.getMethod()).thenReturn("POST");

        final var handlerExecution = (HandlerExecution) handlerMapping.getHandler(request);
        final var modelAndView = handlerExecution.handle(request, response);

        assertThat(modelAndView.getObject("id")).isEqualTo("gugu");
    }
}

이제 @Controller 어노테이션과 @RequestMapping 어노테이션을 달아주는 것 만으로도 프레임워크의 코드를 수정하지 않고 컨트롤러를 추가할 수 있게 되었습니다.

그런데 한가지 문제점이 더 발생했습니다.

기존의 상속기반 컨트롤러는 어떻게 되는 것일까요?

기존 컨트롤러 ForwardController (톰캣 구현하기의 컨트롤러와 조금 달라졌습니다.)

기존 컨트롤러는 메서드명도 execute입니다.

public class ForwardController implements Controller {

    private final String path;

    public ForwardController(final String path) {
        this.path = Objects.requireNonNull(path);
    }

    @Override
    public String execute(final HttpServletRequest request, final HttpServletResponse response) {
        return path;
    }
}

기존 핸들러 매핑 방식도 다릅니다.

public class ManualHandlerMapping implements HandlerMapping {

    private static final Logger log = LoggerFactory.getLogger(ManualHandlerMapping.class);

    private static final Map<String, Controller> controllers = new HashMap<>();

    @Override
    public void initialize() {
        controllers.put("/", new ForwardController("/index.jsp"));
        controllers.put("/login", new LoginController());
        controllers.put("/login/view", new LoginViewController());
        controllers.put("/logout", new LogoutController());
        controllers.put("/register/view", new RegisterViewController());
        controllers.put("/register", new RegisterController());

        log.info("Initialized Handler Mapping!");
        controllers.keySet()
                .forEach(path -> log.info("Path : {}, Controller : {}", path, controllers.get(path).getClass()));
    }

    @Override
    public Controller getHandler(HttpServletRequest request) {
        final String requestURI = request.getRequestURI();
        log.debug("Request Mapping Uri : {}", requestURI);
        return controllers.get(requestURI);
    }
}

기존 컨트롤러와 어노테이션 기반 컨트롤러의 실행방법에는 차이가 존재합니다.

기존의 컨트롤러는 상속한 클래스의 excecute를 실행하는 방식이고
어노테이션 기반의 컨트롤러는 HandlerExecution의 handle을 실행시키는 방식입니다.

Handler Adapter (핸들러 어댑터)

기존의 컨트롤러를 새로운 어노테이션 기반의 컨트롤러로 코드를 수정하는 방법도 있습니다만,

만약 기존의 컨트롤러가 수백개 수천개라면 어떻게 될까요?

기존 컨트롤러를 어노테이션 기반으로 변경할때까지 서비스를 중단해야할까요?

가장 좋은 방법은 기존 컨트롤러와 어노테이션 기반의 컨트롤러를 둘 다 지원하게 만드는 방법입니다.

차근차근 전환을 하면 되죠.

만약 실제 프레임워크를 만든다고 생각해도 갑자기 기존 코드를 지원중단할 수도 없겠죠.

그래서 필요한 것이 핸들러 어댑터입니다.

실제 Spring MVC 에서 핸들러 어댑터를 사용해 여러가지 방식의 컨트롤러를 지원하도록 합니다.

지금부터 핸들러 어댑터를 자세히 알아보고 기존의 컨트롤러와 새로운 어노테이션 기반의 컨트롤러를 둘 다 지원하도록 구현해보겠습니다.

Dispatch Servlet

여기서 잠시,

그림에 갑자기 등장한 DispatcherServlet에 대해 잠깐 언급하고 넘어가겠습니다.

현재 구조는 아래와 같습니다.

톰캣이 서블릿을 직접 생성해서 넘겨주는 상황입니다.

하지만 저희는 서블릿에게 HttpRequest를 넘겨주어도 서블릿에서는 이 요청이 어떤 컨트롤러에 의해 처리되어야 하는지 찾아야합니다.

(핸들러매핑)

또한, 이 핸들러가 어떻게 구현했는지에 상관없이 실행시켜야 하기 때문에 컨트롤러에 맞는 핸들러어댑터도 찾아야 합니다.

(핸들러어댑터 조회)

그리고 작업이 수행되고나서 ModelAndView를 렌더링해야 합니다.

정리하면 요청마다 아래의 과정이 반복됩니다.

핸들러매핑
핸들러어댑터조회
핸들러실행
렌더링

사실 개발자가 짜야하는 비즈니스 로직은 핸들러 실행 부분입니다.

1, 2, 4 부분은 항상 같은 로직이 반복됩니다.

그래서 등장한 것이 DispatchServlet (front controller 패턴) 입니다.

비즈니스로직마다 달라지는 코드 빼고 중복되는 처리는 front controller 인 DispatcherServlet에서 담당합니다.

그래서 Spring MVC에서는 아래와 같은 그림이 나오게되는 것이죠.

interface HandlerAdapter

핸들러 어댑터는 아래와 같은 인터페이스를 구현합니다.

supports() 는 자신이 핸들링 할 수 있는 핸들러인지 판단하는 메서드입니다. 외부에서 supports를 이용해 핸들러 어댑터를 찾을 수 있게하는 메서드입니다.

handle() 은 매개변수로 받는 Object handler를 자신이 핸들링할 수 있는 객체로 캐스팅해 메서드를 실행합니다.

public interface HandlerAdapter {
    boolean supports(Object handler);

    ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
}

AnnotationHandlerAdapter

supports() 에서는 매개변수로 들어온 handler가 HandlerExecution의 인스턴스인지 확인합니다.

handle() 에서는 handlerExcecution의 handle을 실행합니다.

public class AnnotationHandlerAdapter implements HandlerAdapter {
    @Override
    public boolean supports(final Object handler) {
        return handler instanceof HandlerExecution;
    }

    @Override
    public ModelAndView handle(final HttpServletRequest request,
                               final HttpServletResponse response,
                               final Object handler) throws Exception {
        final HandlerExecution handlerExecution = (HandlerExecution) handler;
        return handlerExecution.handle(request, response);
    }
}

ManualHandlerAdapter

support()에서는 매개변수로 들어온 handler가 Controller를 상속받는 클래스의 인스턴스인지 확인합니다.

handle()은 해당 controller의 메서드를 실행시킵니다.

하지만 controller는 String viewName을 반환하기 때문에 인터페이스의 반환타입을 맞춰주려면 ModelAndView로 변환해야합니다.

여기서는 일단 View 템플릿은 JSP만 있다고 가정하겠습니다.

public class ManualHandlerAdapter implements HandlerAdapter {

    @Override
    public boolean supports(final Object handler) {
        return handler instanceof Controller;
    }

    @Override
    public ModelAndView handle(final HttpServletRequest request,
                               final HttpServletResponse response,
                               final Object handler) throws Exception {
        final Controller controller = (Controller) handler;
        final String viewName = controller.execute(request, response);
        return new ModelAndView(new JspView(viewName));
    }
}

HandlerAdapter 덕분에 과거에 지원하던 핸들러도 실행시킬 수 있게 되었습니다.

    @Override
    protected void service(final HttpServletRequest request, final HttpServletResponse response) throws ServletException {
        log.debug("Method : {}, Request URI : {}", request.getMethod(), request.getRequestURI());

        try {
            final var handler = getHandler(request); // 핸들러 매핑
            final HandlerAdapter handlerAdapter = getHandlerAdapter(handler); // 핸들러어댑터 조회
            final ModelAndView modelAndView = handlerAdapter.handle(request, response, handler); // handle
            modelAndView.render(request, response); // 렌더링
        } catch (Throwable e) {
            log.error("Exception : {}", e.getMessage(), e);
            throw new ServletException(e.getMessage());
        }
    }

    private Object getHandler(final HttpServletRequest request) {
        return handlerMappings.stream()
                .map(handlerMapping -> handlerMapping.getHandler(request))
                .filter(Objects::nonNull)
                .findFirst()
                .orElseThrow(() -> new NoSuchElementException("핸들러를 찾을 수 없습니다."));
    }

    private HandlerAdapter getHandlerAdapter(final Object handler) {
        return handlerAdapters.stream()
                .filter(it -> it.supports(handler))
                .findFirst()
                .orElseThrow(() -> new NotFoundHandlerAdapterException("핸들러 어댑터를 찾을 수 없습니다."));
    }

실제로 스프링에는 SimpleControllerHandlerAdapter 가 존재합니다.

Controller 인터페이스를 구현하는 방식의 컨트롤러를 지원하기 위한 것이죠.

지금까지 간단한 DispatcherServlet과 핸들러매핑, 핸들러 어댑터를 구현해보았습니다.

조금 더 개선할 점이 보이는데요.

컨트롤러 어노테이션 스캔 역할 분리
JSON view 지원

다음시간에서 차근차근 개선해봅시다!

코드저장소 : https://github.com/dongho108/jwp-dashboard-mvc/tree/step1

[Tomcat 구현하기] 2. HttpRequest, HttpResponse, RequestMapper, Controller

API_Dev — Thu, 15 Sep 2022 01:32:23 +0900

이번에는 지난번에 구현한 톰캣을 이용해 요구사항을 구현해보겠습니다.

다음과 같이 기능 요구사항이 주어졌습니다.

기능요구사항

GET /login 요청에 로그인 페이지를 보여준다.
GET /register 요청에 회원가입 페이지를 보여준다.
POST /register , body를 포함한 요청에 회원가입을 시키고 login 페이지로 redirect 시킨다.
POST /login 요청에 로그인 처리를 한다.
- 서버에서 세션을 생성해 로그인 정보를 저장한다.
- 쿠키에 JSESSION 아이디를 담아서 로그인을 유지시킨다.
로그인 처리가 된 사용자에게는 index.html 페이지를 보여준다.

HttpRequest 구현

socket 에 쓰여진 inputStream을 사용하기 편하도록 HttpRequest로 변환해야 합니다.

HttpReqeust

HttpRequest가 가지는 요소들을 포함한 클래스를 만들어 줍니다.

HttpStartLine : Method, Path, Version
HttpHeaders

HttpReqeust

현재 socket에서 BufferReader로 읽어들이기 때문에 정적팩터리메서드로 BufferReader를 통해 HttpRequest를 생성합니다.

package org.apache.coyote.http11.http.request;

import static org.apache.catalina.webutils.IOUtils.readData;
import static org.apache.coyote.http11.header.HttpHeaderType.CONTENT_LENGTH;

import java.io.BufferedReader;
import java.io.IOException;
import org.apache.coyote.http11.header.HttpHeader;
import org.apache.coyote.http11.http.HttpHeaders;

public class HttpRequest {

    private final HttpRequestStartLine startLine;
    private final HttpHeaders headers;
    private final String body;

    private HttpRequest(final HttpRequestStartLine startLine, final HttpHeaders headers, final String body) {
        this.startLine = startLine;
        this.headers = headers;
        this.body = body;
    }

    public static HttpRequest from(final BufferedReader bufferedReader) throws IOException {
        final String startLine = bufferedReader.readLine();
        if (startLine == null) {
            throw new IllegalArgumentException("request가 비어있습니다.");
        }

        final HttpRequestStartLine httpRequestStartLine = HttpRequestStartLine.from(startLine);
        final HttpHeaders headers = HttpHeaders.from(bufferedReader);
        final String body = readBody(bufferedReader, headers);

        return new HttpRequest(httpRequestStartLine, headers, body);
    }

    private static String readBody(final BufferedReader bufferedReader,
                                   final HttpHeaders headers) throws IOException {

        if (!headers.contains(CONTENT_LENGTH.getValue())) {
            return "";
        }

        final int contentLength = convertIntFromContentLength(headers.get(CONTENT_LENGTH.getValue()));
        return readData(bufferedReader, contentLength);
    }

    private static int convertIntFromContentLength(final HttpHeader contentLength) {
        return Integer.parseInt(String.join("", contentLength.getValues()));
    }

    public HttpRequestStartLine getStartLine() {
        return startLine;
    }

    public HttpHeaders getHeaders() {
        return headers;
    }

    public String getBody() {
        return body;
    }

    public String getUrl() {
        return startLine.getPath();
    }

    public boolean isGetMethod() {
        return startLine.getHttpMethod().isGet();
    }
}

HttpStartLine

HttpMethod, path, HttpVersion을 포함하는 라인을 표현하는 클래스입니다.

package org.apache.coyote.http11.http.request;

import java.util.List;
import org.apache.coyote.http11.http.HttpVersion;

public class HttpRequestStartLine {

    private static final int START_LINE_MIN_LENGTH = 3;
    private static final String BLANK_LETTER = " ";

    private final HttpMethod httpMethod;
    private final String path;
    private final HttpVersion httpVersion;

    private HttpRequestStartLine(final HttpMethod httpMethod, final String path, final HttpVersion httpVersion) {
        this.httpMethod = httpMethod;
        this.path = path;
        this.httpVersion = httpVersion;
    }

    public static HttpRequestStartLine from(final String startLine) {
        return parseStartLine(startLine);
    }

    private static HttpRequestStartLine parseStartLine(final String startLine) {
        final List<String> startLineInfos = parseStartLineInfos(startLine);
        final HttpMethod method = HttpMethod.from(startLineInfos.get(0));
        final String path = startLineInfos.get(1);
        final HttpVersion version = HttpVersion.from(startLineInfos.get(2));

        return new HttpRequestStartLine(method, path, version);
    }

    private static List<String> parseStartLineInfos(final String startLine) {
        final List<String> startLineInfos = List.of(startLine.split(BLANK_LETTER));
        validateStartLineLength(startLineInfos);
        return startLineInfos;
    }

    private static void validateStartLineLength(final List<String> startLineInfos) {
        if (startLineInfos.size() < START_LINE_MIN_LENGTH) {
            throw new IllegalArgumentException("요청 정보가 잘못되었습니다.");
        }
    }

    public HttpVersion getHttpVersion() {
        return httpVersion;
    }

    public HttpMethod getHttpMethod() {
        return httpMethod;
    }

    public String getPath() {
        return path;
    }
}

HttpHeaders

Map (key: String, value: HtepHeader) 을 가지는 HttpHeaders.

package org.apache.coyote.http11.http;

import static org.apache.catalina.webutils.Parser.removeBlank;

import java.io.BufferedReader;
import java.io.IOException;
import java.util.Arrays;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.stream.Collectors;
import org.apache.coyote.http11.header.HttpHeader;
import org.apache.coyote.http11.header.HttpHeaderType;

public class HttpHeaders {
    private Map<String, HttpHeader> headers = new LinkedHashMap<>();

    private static final String COLON_LETTER = ":";

    public HttpHeaders() {
    }

    private HttpHeaders(final Map<String, HttpHeader> headers) {
        this.headers = headers;
    }

    public static HttpHeaders from(final BufferedReader bufferedReader) throws IOException {
        return new HttpHeaders(readAllHeaders(bufferedReader));
    }

    public static HttpHeaders of(final HttpHeader... httpHeaders) {
        final Map<String, HttpHeader> headers = Arrays.stream(httpHeaders)
                .collect(Collectors.toMap(HttpHeader::getHttpHeaderType,
                        httpHeader -> httpHeader,
                        (key, value) -> value,
                        LinkedHashMap::new));
        return new HttpHeaders(headers);
    }

    private static Map<String, HttpHeader> readAllHeaders(final BufferedReader bufferedReader) throws IOException {
        final Map<String, HttpHeader> headers = new LinkedHashMap<>();

        while (true) {
            final String line = bufferedReader.readLine();
            if (line.equals("")) {
                break;
            }
            final List<String> header = parseHeader(line);
            final String headerType = removeBlank(header.get(0));
            final String headerValue = removeBlank(header.get(1));
            final String httpHeaderType = HttpHeaderType.of(headerType);
            headers.put(httpHeaderType, HttpHeader.of(httpHeaderType, headerValue));
        }

        return headers;
    }

    private static List<String> parseHeader(final String line) {
        final List<String> header = List.of(line.split(COLON_LETTER));
        validateHeader(header);
        return header;
    }

    private static void validateHeader(final List<String> header) {
        if (header.size() < 2) {
            throw new IllegalArgumentException("요청 정보가 잘못되었습니다.");
        }
    }

    public boolean contains(final String httpHeaderType) {
        return headers.containsKey(httpHeaderType);
    }

    public HttpHeader get(final String httpHeaderType) {
        return headers.get(httpHeaderType);
    }

    public Set<String> keySet() {
        return headers.keySet();
    }

    public void put(final String httpHeaderType, final HttpHeader httpHeader) {
        headers.put(httpHeaderType, httpHeader);
    }

    public void add(final HttpHeader httpHeader) {
        headers.put(httpHeader.getHttpHeaderType(), httpHeader);
    }
}

HttpRequest 구현은 끝났습니다.

BufferReader를 통해 HttpRequst를 생성하면 됩니다.

    @Override
    public void process(final Socket connection) {
        try (final var inputStream = connection.getInputStream();
             final var outputStream = connection.getOutputStream()) {

            final InputStreamReader inputStreamReader = new InputStreamReader(inputStream, UTF_8);
            final BufferedReader bufferedReader = new BufferedReader(inputStreamReader);

            final HttpRequest httpRequest = HttpRequest.from(bufferedReader);
            ...

            outputStream.write(response.getBytes());
            outputStream.flush();
        } catch (IOException | UncheckedServletException e) {
            log.error(e.getMessage(), e);
        }
    }

HttpResponse

package org.apache.coyote.response;

import static org.apache.coyote.header.HttpHeaderType.CONTENT_LENGTH;
import static org.apache.coyote.response.HttpStatus.OK;

import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.List;
import org.apache.coyote.HttpVersion;
import org.apache.coyote.header.HttpHeader;
import org.apache.coyote.header.HttpHeaders;

public class HttpResponse {

    private static final String NEW_LINE_LETTER = "\r\n";
    private static final String EMPTY_LETTER = "";
    private static final String BLANK_LETTER = " ";
    private static final String COLON_LETTER = ":";
    private static final String SEMI_COLON_LETTER = ";";
    private static final HttpVersion DEFAULT_HTTP_VERSION = HttpVersion.HTTP11;

    private HttpVersion httpVersion = DEFAULT_HTTP_VERSION;
    private HttpStatus httpStatus = OK;
    private HttpHeaders headers = new HttpHeaders();
    private String body = "";

    public String getBody() {
        return body;
    }

    public void setHttpStatus(final HttpStatus httpStatus) {
        this.httpStatus = httpStatus;
    }

    public void addHeader(final String name, final String value) {
        headers.add(HttpHeader.of(name, value));
    }

    public void setBody(final String body) {
        final int length = body.getBytes(StandardCharsets.UTF_8).length;
        addHeader(CONTENT_LENGTH.getValue(), String.valueOf(length));
        this.body = body;
    }

    public String generateResponse() {
        final String statusLine = generateStatusLine();
        final String headerLine = generateHeaderLine();
        return String.join(NEW_LINE_LETTER, statusLine, headerLine, EMPTY_LETTER, body);
    }

    private String generateStatusLine() {
        return String.join(BLANK_LETTER,
                httpVersion.getVersion(),
                String.valueOf(httpStatus.getCode()),
                httpStatus.getMessage(),
                EMPTY_LETTER);
    }

    private String generateHeaderLine() {
        final List<String> headers = new ArrayList<>();
        for (String httpHeaderType : this.headers.keySet()) {
            final String header = String.join(COLON_LETTER + BLANK_LETTER, httpHeaderType,
                    String.join(SEMI_COLON_LETTER, this.headers.get(httpHeaderType).getValues()));
            headers.add(header + BLANK_LETTER);
        }
        return String.join(NEW_LINE_LETTER, headers);
    }
}

각 method, url 요청에 컨트롤러 매핑을 해주겠습니다.

각 요청은 아래와 같이 처리됩니다.

socket에 들어오는 inputStream을 사용하게 편하게 HttpRequest로 변환하기
RequestMapper에 GET /login 요청을 매핑해 컨트롤러 반환하기
Controller에 HttpReqeust, HttpResponse를 같이 넣어주며 service 실행하기
HttpResponse를 socket의 outputStream에 담기

그리고 요청에 따라 다른 처리의 분기는 2, 3번만 코드를 추가해주면 됩니다.

Http11Processor

package org.apache.coyote.http11;

import static java.nio.charset.StandardCharsets.UTF_8;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.Socket;
import nextstep.jwp.exception.UncheckedServletException;
import org.apache.coyote.Processor;
import org.apache.coyote.http11.http.RequestMapper;
import org.apache.coyote.http11.http.request.HttpRequest;
import org.apache.coyote.http11.http.response.HttpResponse;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Http11Processor implements Runnable, Processor {

    private static final Logger log = LoggerFactory.getLogger(Http11Processor.class);

    private final Socket connection;

    public Http11Processor(final Socket connection) {
        this.connection = connection;
    }

    @Override
    public void run() {
        try {
            log.info("connect host: {}, port: {}", connection.getInetAddress(), connection.getPort());
            process(connection);
        } catch (Exception e) {
            log.error(e.getMessage(), e);
            e.printStackTrace();
        }
    }

    @Override
    public void process(final Socket connection) {
        try (final var inputStream = connection.getInputStream();
             final var outputStream = connection.getOutputStream()) {

            final InputStreamReader inputStreamReader = new InputStreamReader(inputStream, UTF_8);
            final BufferedReader bufferedReader = new BufferedReader(inputStreamReader);

            final HttpRequest httpRequest = HttpRequest.from(bufferedReader);
            final Controller controller = RequestMapper.getControllerFrom(httpRequest);
            final HttpResponse httpResponse = new HttpResponse();
            controller.service(httpRequest, httpResponse);
            final String response = httpResponse.generateResponse();

            outputStream.write(response.getBytes());
            outputStream.flush();
        } catch (IOException | UncheckedServletException e) {
            log.error(e.getMessage(), e);
        }
    }
}

RequestMapper

저는 일단 RequestMapper를 enum으로 관리하고 있습니다.

클래스가 로딩되는 시점에 인스턴스가 생성되기 때문에 Controller를 싱글톤처럼 사용할 수 있습니다.

RequestMapper로부터 반환되는 Controller들은 Controller 인터페이스와 AbstractController 추상클래스를 상속하고 있기 때문에 각 Controller의 service 메서드를 호출하는 것으로 전략패턴을 구현할 수 있습니다.

package org.apache.coyote.http11.http;

import java.util.Arrays;
import java.util.NoSuchElementException;
import java.util.regex.Pattern;
import org.apache.coyote.http11.Controller;
import nextstep.jwp.controller.HomeController;
import nextstep.jwp.controller.LoginController;
import nextstep.jwp.controller.IndexController;
import nextstep.jwp.controller.RegisterController;
import nextstep.jwp.controller.ResourceController;
import org.apache.coyote.http11.http.request.HttpRequest;

public enum RequestMapper {

    HOME(Constants.HOME_URL_REGEX, new HomeController()),
    INDEX(Constants.INDEX_PAGE_REGEX, new IndexController()),
    LOGIN(Constants.LOGIN_REGEX, new LoginController()),
    REGISTER(Constants.REGISTER_REGEX, new RegisterController()),
    RESOURCE(Constants.RESOURCE_URL_REGEX, new ResourceController());

    private final Pattern urlRegex;
    private final Controller controller;

    RequestMapper(final Pattern urlRegex, final Controller controller) {
        this.urlRegex = urlRegex;
        this.controller = controller;
    }

    public static Controller getControllerFrom(final HttpRequest httpRequest) {
        final String url = httpRequest.getUrl();
        return Arrays.stream(RequestMapper.values())
                .filter(it -> matchUrl(url, it))
                .findFirst()
                .orElseThrow(() -> new NoSuchElementException("해당하는 handler가 없습니다. " + url))
                .controller;
    }

    private static class Constants {
        private static final Pattern HOME_URL_REGEX = Pattern.compile("^/$");
        private static final Pattern RESOURCE_URL_REGEX = Pattern.compile("^(/[a-z|A-Z|가-힣|ㄱ-ㅎ|_|0-9|\\-]*)+(\\.[a-z]*)$");
        private static final Pattern LOGIN_REGEX = Pattern.compile("^(/login)(\\?([^#\\s]*))?");
        private static final Pattern REGISTER_REGEX = Pattern.compile("^(/register)(\\?([^#\\s]*))?");
        private static final Pattern INDEX_PAGE_REGEX = Pattern.compile("^(/index\\.html)");
    }

    private static boolean matchUrl(final String url, final RequestMapper requestMapper) {
        return requestMapper.urlRegex.matcher(url).find();
    }
}

로그인기능

LoginController

SessionAuthorizeService 와 UserService를 싱글톤 객체로 받고있습니다.

GET 요청에는

로그인됨 -> index.html redirect
로그인안됨 -> login.html 반환

POST 요청에는

UserService를 이용해 로그인 처리

package nextstep.jwp.controller;

import static nextstep.jwp.controller.ResourceUrls.INDEX_HTML;
import static nextstep.jwp.controller.ResourceUrls.LOGIN_HTML;
import static nextstep.jwp.controller.ResourceUrls.UNAUTHORIZED_HTML;

import java.util.Map;
import java.util.NoSuchElementException;
import nextstep.jwp.application.SessionAuthorizeService;
import nextstep.jwp.application.UserService;
import nextstep.jwp.dto.UserLoginRequest;
import org.apache.catalina.session.SessionManager;
import org.apache.catalina.webutils.Parser;
import org.apache.coyote.header.HttpCookie;
import org.apache.coyote.request.HttpRequest;
import org.apache.coyote.response.HttpResponse;

public class LoginController extends ResourceController {

    private final SessionAuthorizeService sessionAuthorizeService = SessionAuthorizeService.getInstance();
    private final UserService userService = UserService.getInstance();

    @Override
    public void doGet(final HttpRequest httpRequest, final HttpResponse httpResponse) {
        if (sessionAuthorizeService.isAuthorized(httpRequest)) {
            setRedirectHeader(httpResponse, INDEX_HTML);
            return;
        }
        setResource(LOGIN_HTML.getValue(), httpResponse);
    }

    @Override
    public void doPost(final HttpRequest httpRequest, final HttpResponse httpResponse) {
        final String body = httpRequest.getBody();
        login(body, httpResponse);
    }

    private void login(final String body, final HttpResponse httpResponse) {
        final Map<String, String> queryParams = Parser.parseQueryParams(body);
        try {
            final UserLoginRequest userLoginRequest = getUserLoginRequest(queryParams);
            userService.login(userLoginRequest);
            final HttpCookie cookie = SessionManager.createCookie();
            setRedirectHeader(httpResponse, INDEX_HTML);
            httpResponse.addHeader("Set-Cookie", cookie.toHeaderValue());
        } catch (IllegalArgumentException exception) {
            setRedirectHeader(httpResponse, UNAUTHORIZED_HTML);
        } catch (NoSuchElementException exception) {
            setRedirectHeader(httpResponse, LOGIN_HTML);
        }
    }

    private UserLoginRequest getUserLoginRequest(final Map<String, String> queryParams) {
        validateLoginParams(queryParams);
        return new UserLoginRequest(queryParams.get("account"),
                queryParams.get("password"));
    }

    private void validateLoginParams(final Map<String, String> queryParams) {
        if (!queryParams.containsKey("account") || !queryParams.containsKey("password")) {
            throw new IllegalArgumentException("account와 password 정보가 입력되지 않았습니다.");
        }
    }
}

Catalina vs Coyote

tomcat에는 catalina와 coyote라는 패키지가 있습니다.

각 패키지의 의미가 무엇이고 어떤 파일들을 가지고 있을까요?

Catalina

tomcat의 서블릿 컨테이너입니다.

tomcat은 실제로 tomcat JSP 엔진과 다양한 커넥터를 비롯한 여러 구성요소로 구성되어 있지만 핵심 구성 요소는 Catalina라고 합니다.

Catalina는 tomcat의 실제 서블릿 specification의 구현을 제공합니다. tomcat서버를 시작할 때 실제로는 Catalina를 시작하는 것입니다.

connector, manager, mapper, servlets, session 등이 있네요.

저도 비슷하게 패키지를 구성했습니다.

my apche catalina

Coyote

HTTP1.1, 2 프로토콜을 웹 서버로 지원하는 tomcat용 커넥터 구성요소 입니다.

이를 통해 Java 서블릿 또는 Catalina가 로컬 파일을 HTTP 문서로 제공하는 일반 웹 서버로도 작동할 수 있습니다.

Coyote는 특정 TCP 포트에서 서버로 들어오는 연결을 수신하고 Tomcat 엔진에 요청을 전달하여 요청을 처리하고 클라이언트에게 응답을 보냅니다.

http11, http2, Processor, Request, Response 등이 있습니다.

저도 비슷하게 패키지를 구성했습니다.

Header는 사실 RequestHeader, ResponseHeader로 나뉠 수 있는데 저는 공통으로 구성해서 밖으로 뺐습니다.

my apache coyote

이렇게 웹 어플리케이션이 어떻게 클라이언트로부터 데이터를 받고 가공하고 보내주는지를 한번 구현해보았습니다.

Tomcat은 Servlet Container의 역할을 하는데요.

Connector를 생성하고, Socket을 통해 클라이언트로부터 데이터를 받고 Controller를 매핑해 데이터를 가공해주고 있었습니다.

각 부분들을 직접 구현해보며 어떤 역할을 하는지도 더 이해할 수 있었습니다.

다음에는?

그런데 지금의 구조는 약간의 문제가 존재합니다.

Controller가 추가될 때마다 RequestMapper에도 url을 추가해주어야 합니다.

사실 우리는 Spring을 사용할때 Controller가 추가된다고 Spring의 클래스파일을 수정하지는 않고있죠.

다음에는 Spring MVC가 어떻게 이런 불편함들을 해결해주는지 직접 Spring MVC를 구현하며 알아보겠습니다.

참고자료

tecoble https://tecoble.techcourse.co.kr/post/2021-05-24-apache-tomcat/

코드 저장소

https://github.com/dongho108/jwp-dashboard-http/tree/step234

[Tomcat 구현하기] 1. Tomcat, Connector, Socket

API_Dev — Wed, 14 Sep 2022 11:58:22 +0900

SpringBoot를 사용해 클라이언트-서버 통신을 하게되면 내장 된 톰캣을 사용합니다.

Tomcat에 대한 이해가 없더라도 우리는 어렵지 않게 외부와 통신을 할 수 있습니다.

그런데 정말 Tomcat을 모르고 웹 어플리케이션 서버를 만들어도 되는 걸까요?

우리는 서버에 요청이 많아져 부하가 생긴다면 Tomcat 설정을 바꿔야할 수도 있습니다.

미리 Tomcat에 대한 이해가 있다면 어느부분에서 문제가 생겼는지, 파악이 가능하고 튜닝까지 가능할 것입니다.

이번 시간에는 Tomcat을 직접 구현해보며 Tomcat을 알아가보겠습니다.

더 나아가 서블릿을 직접 구현하며 웹서버 통신의 흐름을 다뤄봅니다.

다음과 같이 기능 요구사항이 주어졌습니다.

기능요구사항

GET /login 요청에 로그인 페이지를 보여준다.
GET /register 요청에 회원가입 페이지를 보여준다.
POST /register , body를 포함한 요청에 회원가입을 시키고 login 페이지로 redirect 시킨다.
POST /login 요청에 로그인 처리를 한다.
- 서버에서 세션을 생성해 로그인 정보를 저장한다.
- 쿠키에 JSESSION 아이디를 담아서 로그인을 유지시킨다.
로그인 처리가 된 사용자에게는 index.html 페이지를 보여준다.

Tomcat을 직접 구현하며 해결해보겠습니다.

0. 클라이언트와 서버가 통신하기 위해 Connection을 연결하고 Socket을 통해 데이터를 읽고 쓴다.

먼저 클라이언트로부터 요청을 받아야겠죠.

웹서버에게 요청이 들어오는 방식은 아래와 같습니다.

코드로 구현할 내용들

Application이 실행되고 Tomcat이 생성되고 실행됩니다.
Tomcat이 실행되면 Connector가 생성되고 실행됩니다.
Connector가 생성될때 ThreadPool과 ServerSocket을 생성합니다.
제일 앞단에서 Socket이 클라이언트의 요청을 기다리다가 요청이 들어오고 수락되면, ServerSocket에 요청데이터를 넘깁니다.
Connector는 요청 1개당 ThreadPool에서 Thread 1개를 사용해 요청을 처리합니다.
클라이언트의 요청을 읽을때는 ServerSocket의 inputStream을 읽습니다.
(이와같이 Socket에 데이터를 읽고쓰며 클라이언트와 데이터를 주고받을 수 있습니다.)
요청이 처리되면 다시 ServerSocket을 통해 outputStream을 쓰고 클라이언트에게 데이터를 전달합니다.

Socket (oracle docs 번역)

일반적으로 서버는 특정 포트가 바인딩된 소켓을 가지고 특정 컴퓨터 위에서 돌아갑니다.

해당 서버는 클라이언트의 연결 요청을 소켓을 통해 리스닝 하면서 기다립니다.

클라이언트는 서버가 떠 있는 머신의 호스트네임과 서버가 리스닝하고 있는 포트 번호를 통해 연결을 시도합니다.

서버가 연결을 수락하면 서버는 동일한 로컬 포트에 바인딩된 새로운 소켓을 생성하며 클라이언트의 주소와 포트로 세팅된 엔드포인트를 가지게 됩니다.

클라이언트와 서버는 이제 소켓에 데이터를 쓰거나 읽음으로써 통신할 수가 있게됩니다.

Connector (tomcat docs 번역)

서버로 들어오는 각 요청에는 요청 기간 동안 쓰레드가 필요합니다.

현재 사용 가능한 요청 처리 쓰레드에서 처리할 수 있는 것보다 많은 동시 요청이 수신되면 구성된 최대값(max-Threads)값까지 추가 쓰레드가 생성됩니다.

더 많은 동시 요청이 수신되면 Connector에 의해 생성된 ServerSocket 내부에 구성된 최대값 (accepCount)값까지 누적됩니다.

더 이상의 추가 동시 요청은 리소스를 처리할 수 있을 때까지 "connection refused" 오류를 수신합니다.

그럼 이제 구현 해보겠습니다.

Application

import org.apache.catalina.startup.Tomcat;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Application {

    private static final Logger log = LoggerFactory.getLogger(Application.class);

    public static void main(String[] args) {
        log.info("web server start.");
        final var tomcat = new Tomcat();
        tomcat.start();
    }
}

Tomcat

원래는 max-connections 에 따라 connection 수를 늘릴 수 있지만 현재 구현에선 Connection을 1개로 고정하겠습니다.

package org.apache.catalina.startup;

import org.apache.catalina.connector.Connector;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.IOException;

public class Tomcat {

    private static final Logger log = LoggerFactory.getLogger(Tomcat.class);

    public void start() {
        final Connector connector = new Connector(1, 10);
        connector.start();

        try {
            // make the application wait until we press any key.
            System.in.read();
        } catch (IOException e) {
            log.error(e.getMessage(), e);
        } finally {
            log.info("web server stop.");
            connector.stop();
        }
    }
}

Connector

maxThread에 따라 newFixedThreadPool 를 생성합니다.

acceptCount에 따라 ServerSocket을 생성합니다.

Connector가 생성될때 ServerSocket을 생성합니다.

요청 1개당 1개의 쓰레드에 요청을 처리합니다.

package org.apache.catalina.connector;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import org.apache.coyote.http11.Http11Processor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.IOException;
import java.io.UncheckedIOException;
import java.net.ServerSocket;
import java.net.Socket;

public class Connector implements Runnable {

    private static final Logger log = LoggerFactory.getLogger(Connector.class);

    private static final int DEFAULT_PORT = 8080;
    private static final int DEFAULT_ACCEPT_COUNT = 100;

    private final ExecutorService executorService;
    private final ServerSocket serverSocket;
    private boolean stopped;

    public Connector(final int port, final int acceptCount, final ExecutorService executorService) {
        this.executorService = executorService;
        this.serverSocket = createServerSocket(port, acceptCount);
        this.stopped = false;
    }

    public Connector(final int acceptCount, final int maxThreads) {
        this(DEFAULT_PORT, acceptCount, Executors.newFixedThreadPool(maxThreads));
    }

    public Connector() {
        this(DEFAULT_PORT, DEFAULT_ACCEPT_COUNT, Executors.newCachedThreadPool());
    }

    private ServerSocket createServerSocket(final int port, final int acceptCount) {
        try {
            final int checkedPort = checkPort(port);
            final int checkedAcceptCount = checkAcceptCount(acceptCount);
            return new ServerSocket(checkedPort, checkedAcceptCount);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }

    public void start() {
        var thread = new Thread(this);
        thread.setDaemon(true);
        thread.start();
        stopped = false;
    }

    @Override
    public void run() {
        while (!stopped) {
            connect();
        }
    }

    private void connect() {
        try {
            process(serverSocket.accept());
        } catch (IOException e) {
            log.error(e.getMessage(), e);
        }
    }

    private void process(final Socket connection) {
        if (connection == null) {
            return;
        }
        log.info("connect host: {}, port: {}", connection.getInetAddress(), connection.getPort());
        var processor = new Http11Processor(connection);
        executorService.execute(processor);
    }

    public void stop() {
        stopped = true;
        try {
            serverSocket.close();
        } catch (IOException e) {
            log.error(e.getMessage(), e);
        }
    }

    private int checkPort(final int port) {
        final var MIN_PORT = 1;
        final var MAX_PORT = 65535;

        if (port < MIN_PORT || MAX_PORT < port) {
            return DEFAULT_PORT;
        }
        return port;
    }

    private int checkAcceptCount(final int acceptCount) {
        return Math.max(acceptCount, DEFAULT_ACCEPT_COUNT);
    }
}

Http11Processor

Connector로부터 받은 Socket의 InputStream을 읽고 데이터를 처리한 후 OutputStream에 데이터를 담아 클라이언트에게 전달합니다.

package org.apache.coyote.http11;

import static java.nio.charset.StandardCharsets.UTF_8;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.Socket;
import nextstep.jwp.exception.UncheckedServletException;
import org.apache.coyote.Processor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Http11Processor implements Runnable, Processor {

    private static final Logger log = LoggerFactory.getLogger(Http11Processor.class);

    private final Socket connection;

    public Http11Processor(final Socket connection) {
        this.connection = connection;
    }

    @Override
    public void run() {
        try {
            log.info("connect host: {}, port: {}", connection.getInetAddress(), connection.getPort());
            process(connection);
        } catch (Exception e) {
            log.error(e.getMessage(), e);
            e.printStackTrace();
        }
    }

    @Override
    public void process(final Socket connection) {
        try (final var inputStream = connection.getInputStream();
             final var outputStream = connection.getOutputStream()) {

            final InputStreamReader inputStreamReader = new InputStreamReader(inputStream, UTF_8);
            final BufferedReader bufferedReader = new BufferedReader(inputStreamReader);

			...

            outputStream.write(response.getBytes());
            outputStream.flush();
        } catch (IOException | UncheckedServletException e) {
            log.error(e.getMessage(), e);
        }
    }
}

1. GET /login 요청에 로그인 페이지를 보여준다.

는 다음 시간에..

2022.09.15 - [Web/Spring] - [Tomcat 구현하기] 2. HttpRequest, HttpResponse, RequestMapper, Controller

참고자료

What is Socket? https://docs.oracle.com/javase/tutorial/networking/sockets/readingWriting.html
mulesoft https://www.mulesoft.com/tcat/tomcat-catalina
wikipedia https://en.wikipedia.org/wiki/Apache_Tomcat#Catalina
tomcat-docs-excutor https://tomcat.apache.org/tomcat-8.5-doc/config/executor.html
tomcat-docs-http https://tomcat.apache.org/tomcat-8.0-doc/config/http.html