조금 늦었을 뿐이고, 잠시 우선순위를 조정했을 뿐이다.

2026년 상반기는 개발자로서의 첫 적응기였다.

새로운 환경에서 업무를 배우고, 내가 할 수 있는 것과 할 수 없는 것을 인정하는 방법을 배웠다. 계획했던 것들을 모두 이루지는 못했지만 그 과정에서 우선순위를 정하는 법과 꾸준함의 중요성을 다시 한 번 느낄 수 있었다.

잊어버리기 전에 2026년 상반기를 기록해두려고 한다.

개발자로 이직 후 실무 적응

자격증 공부와 실무 적응을 동시에 해내고 싶었다.

하지만 생각보다 업무가 빨리 끝나지 않았고, 야근이 잦아질수록 공부할 시간을 빼앗긴다는 생각에 답답하기도 했다.

결국 자격증은 잠시 내려놓고 일에 집중했다. 그 선택이 아쉽지 않도록 지금의 경험이 좋은 자산으로 남기를 바란다.

여러 번의 면접 끝에 연봉을 올려 새로운 회사에 왔다. 지금은 이 환경에 감사하며 배우는 데 집중해보려 한다.

개발자로서의 첫 4개월

상반기 가장 큰 변화는 개발자가 된 것이었다.

입사 후 통신사 빌링 시스템 개발 업무를 맡으며 처음으로 실무 개발 환경을 경험했다. 학교에서 학생들을 가르치던 시절과는 완전히 다른 환경이었다.

처음에는 개발자가 되면 코드를 잘 짜는 것이 가장 중요하다고 생각했다. 그런데 막상 일을 해보니 코드보다 먼저 이해해야 할 것들이 많았다.

상품과 요금 구조를 이해해야 했고, 상품 변경 시 어떤 데이터가 어떻게 변경되는지 확인해야 했다. 하나의 기능을 수정하더라도 기존 기능에 영향은 없는지, 예외 상황에서는 어떻게 동작하는지 확인해야 했다.

특히 최근 진행했던 개발 과제에서는 상품 변경과 관련된 여러 케이스를 검토하고 테스트하는 업무를 경험했다. 비슷해 보이는 요구사항도 실제로는 처리 기준이 달랐고, 어떤 데이터를 기준으로 판단해야 하는지 이해하는 데 시간이 많이 걸렸다. 이 과정에서 단순히 개발만 하는 것이 아니라 도메인을 이해하는 것이 중요하다는 것을 배웠다.

또 여러 부서와 협업하며 업무를 진행하는 과정도 쉽지 않았다. 같은 요구사항이라도 보는 관점이 달랐고, 내가 이해한 내용이 맞는지 계속 확인해야 했다. 기술적인 문제보다 일정 조율이나 커뮤니케이션이 더 어렵다고 느낀 순간도 많았다.

최근 개발 기간에는 "퇴사할게요."라는 말이 목끝까지 차오르기도 했다. 업무 강도도 높았고 개인 시간이 사라진다는 생각에 힘들었다. 그런데 신기하게도 적응하는 시기라고 받아들이고 나니 조금씩 일이 재미있어지기 시작했다.

아직은 모르는 것이 훨씬 많다. 그래도 처음 입사했을 때와 비교하면 업무 흐름도 조금씩 보이기 시작했고, 내가 맡은 개발 건을 스스로 처리하는 범위도 넓어지고 있다. 실무 개발자로서 조금씩 성장하고 있다는 점에서 의미 있는 시간이었다.

러닝과 체력 관리

상반기에는 스트레스 관리가 생각보다 쉽지 않았다.

퇴근 후 아무것도 하기 싫은 날도 많았고 운동을 미루는 날도 있었다. 예전 같았으면 그냥 쉬었을 텐데 어떻게든 러닝화를 신고 밖으로 나가려고 했다.

그래도 결국 내 균형을 잡아준 것은 러닝이었다. 땀을 흘리고 나면 하루 종일 머릿속을 괴롭히던 생각들이 조금 정리되는 느낌이었다.

매일 뛰지는 못했지만 끝까지 놓지 않았다는 것만으로도 다행이라고 생각한다.

공부와 자격증

결론은 빅데이터분석기사 실기시험을 또 미루고 말았다.

작년 하반기에는 SKCT를 준비한다는 이유로 미뤘는데, 또 미루게 될 줄은 몰랐다. 처음에는 스스로에게 실망하기도 했다.

하지만 지금 돌아보면 때가 아님을 인정하고 잠시 미뤄두는 것이 오히려 정신 건강에는 더 좋았다.

책도 많이 읽지 못했다. 대출 공부도 하겠다고 해놓고 많이 미뤘다. 눈앞의 일이 급급했다.

그럼에도 매일 출근길에 경제 기사와 부동산 관련 글을 읽었고, 월가 모닝브리핑도 꾸준히 들었다. 지금은 티가 나지 않더라도 이런 작은 습관들이 결국 자양분이 될 것이라고 믿는다.

인간관계

원래 사람을 많이 만나는 편은 아니다. 운동하고 일하고 공부하고 나면 에너지가 거의 남지 않는다.

그런데 사람들을 조금 더 자주 만났던 시기가 있었다. 그때 느낀 건 좋은 사람들과 삶의 이야기를 나누는 것이 생각보다 큰 힘이 된다는 것이었다.

(그리고 내가 퇴사를 여러 번 외치며 불만을 쏟아낼 때 묵묵히 들어준 친구에게 정말 고맙고 미안하다. 사실 더 좋은 이야기를 나누었으면 좋았을 것 같다. 불만을 말한다고해서 해결되는 문제는 아니었다.)

반면 나를 지치게 만드는 관계도 있었다. 미련을 버리고 나니 오히려 후련했고 다시 내 루틴을 찾을 수 있었다.

좋은 관계는 에너지를 채워주고, 좋지 않은 관계는 생각보다 많은 에너지를 가져간다는 것을 배웠다.

상반기에 포기한 것

모든 사람에게 잘 보이려는 마음

입사 초반에는 대리님들에게도, 사원분들에게도 정말 많은 질문을 했다.

내가 들어간 개발팀에서는 직급보다는 소위말하는 “짬“이 더 중요했다. 질문을 너무 많이해서 이해도가 낮다는 이야기를 들은 적도 있다.

그동안 어디를 가도 1인분은 한다는 이야기를 듣고 살았는데, 그런 말을 들으니 내가 너무 바보 같기도 했다.

그래도 괜찮다.

지금은 바보 대리를 하겠다.

대신 1년 후에는 바보 대리가 되지 않기 위한 과정이라고 생각하겠다.

완벽하게 하려는 강박

개발과제를 완벽하게 해내고 싶었다. 그러다 보니 주말에도 계속 일 생각을 했고, 잘하고 싶다는 마음이 오히려 부담으로 다가왔다.

개발자의 타이틀을 가진 지 4개월밖에 되지 않았는데 뭐가 그렇게 급했을까.

나에 대한 기대가 컸던 만큼 실망도 컸다.

조급한 비교

"저 사람은 사원인데 나보다 더 빨리 배우는 것 같다."

"나는 1년 차가 되어도 저 정도는 못할 것 같다."

아직 오지도 않은 미래의 나를 스스로 낮게 평가하고 있었다.

나조차 나를 낮게 평가한다면 누가 나를 좋게 보겠는가.

상반기에 배운 것

• 꾸준함이 재능보다 강하다.
• 체력이 곧 멘탈이다.
• 내 속도대로 가도 괜찮다.
• 방향성을 잃지 않는 것이 중요하다.

나는 처음 배우는 과정에서 학습 속도가 빠른 사람은 아니다. 이해하고 내 것으로 만드는 데 시간이 오래 걸리는 편이다.

교관 시절에도 그랬다. 너무나도 당연하지만.. 교사 출신 선배님들은 수업 준비를 한두 시간 하면 되는 내용을 나는 몇 배의 시간을 들여 공부했다.

처음 가르쳤던 과목인 컴퓨터구조 교과서가 학생들 교과서보다 더 너덜너덜해지도록 봤던 기억이 있다.

대신 한 번 이해하고 나면 자신 있게 설명할 수 있을 때까지 반복했다.

지금도 크게 다르지 않은 것 같다.

회사는 내가 빨리 1인분이 되기를 바라겠지만 내가 더 조급해질수록 그 시기는 오히려 늦어질 수 있다.

내 속도를 유지하자. 그리고 방향성을 잃지 말자.

지금 회사에서 열심히 일하는 것도 중요하지만, 내가 어떤 개발자가 되고싶은지 끊임없이 고민하는 것도 중요하다.

마무리하며

2026년 상반기는 생각보다 훨씬 힘들었다. 개발자로서의 첫 적응기였고, 수없이 퇴사를 고민했다. 계획했던 것들을 여러 번 미루기도 했다.

그래도 포기하지는 않았다. 지금 생각해보면 실패한 상반기라기보다 우선순위를 다시 정했던 상반기에 가까운 것 같다.

모든 것을 다 가져가려고 했지만 현실은 그렇지 않았다.

무엇을 먼저 해야 하는지, 무엇을 잠시 내려놓아야 하는지 배웠다. 하반기에는 더 빨리 가기보다 꾸준히 가고 싶다.

그리고 2026년 12월의 내가 이 글을 다시 읽었을 때

"그래도 잘 버텼네."

라고 웃으면서 말할 수 있었으면 좋겠다.

이번 포스팅에서는 이 구조를 실제 코드로 구현해보며 RAG 파이프라인 안에서 검색, 채팅, 메모리, 비동기 실행까지 직접 확인해보겠습니다.

실습 목표

이번 실습의 목표는 LCEL의 다양한 실행 방식과 블록들을 직접 체험하는 것입니다.

구체적으로는 다음을 확인해볼 것입니다.

1. 검색 모드: 벡터DB에서 관련 문서 찾기 2. 채팅 모드(Streaming): 답변을 토큰 단위로 스트리밍 출력 3. 메모리 적용: RunnableWithMessageHistory를 활용하여 대화 맥락 유지 4. 배치 처리: 여러 질문을 한 번에 처리하는 batch/abatch 실행 5. 비동기 실행: ainvoke/astream으로 동시에 요청 처리

정리하면 "검색 → 답변 → 맥락 유지 → 병렬/비동기 처리라는 흐름을 하나의 파이프라인에서 확인하는 것"이 핵심 목표입니다.

코드 구조 요약

이번 실습 코드는 기능별로 모듈을 나누어 구성했습니다.

lcel_pipeline/ ├── config.py # 설정 및 상수 ├── models.py # 데이터 모델(KeywordSection 등) ├── document_processor.py # 문서 로드 & 섹션/청크 분리 ├── vector_store_manager.py # 벡터스토어 구축 및 로드 ├── rag_chain_builder.py # LCEL 기반 RAG 체인 ├── chat_history_manager.py # 대화 히스토리 관리 (RunnableWithMessageHistory) ├── main.py # RAGApplication (검색/채팅/비동기/배치 실행) │ ├── run.py # 기본 실행 스크립트 ├── interactive_chat.py # CLI 대화형 실행 │ ├── finance-keywords.txt # 금융 키워드 데이터 ├── nlp-keywords.txt # NLP 키워드 데이터 └── faiss_keywords/ # 실행 시 생성되는 벡터스토어 디렉토리

1. 핵심 모듈

• config.py: 모델명, 경로, 검색 파라미터 등 공통 설정
• models.py: 데이터 모델 정의 (KeywordSection 등)
• document_processor.py: 문서 로드 및 섹션/청크 분리
• vector_store_manager.py: 임베딩 생성 & 벡터스토어(FAISS) 관리
• rag_chain_builder.py: LCEL 기반 RAG 체인 (Branch, Memory, Stream 포함)
• chat_history_manager.py: 대화 히스토리 관리 (RunnableWithMessageHistory)
• main.py: RAGApplication 클래스 → 검색, 채팅, 비동기, 배치 실행 총괄

2. 실행 스크립트

• run.py: 기본 실행 스크립트
• interactive_chat.py: CLI 기반 대화형 실행 (검색/채팅 모드 선택)

3. 데이터 파일

• finance-keywords.txt: 금융 키워드 데이터
• nlp-keywords.txt: NLP 키워드 데이터
• faiss_keywords/: 실행 시 자동 생성되는 벡터스토어 디렉토리
• index.faiss / index.pkl

데이터 플로우

파이프라인 구축

앱 초기화

아래 함수 하나로 문서 로드 → 청크 분할 → 벡터스토어 구축(FAISS) → retriever 생성 → RAG체인 연결 → 메모리까지 한 번에 준비됩니다.

즉, 질문을 던지면 바로 검색과 답변이 가능하도록 RAG 파이프라인 전체를 세팅하는 단계입니다.

def initialize(self) -> None:
    print("문서를 로드하는 중...")
    docs = DocumentProcessor.load_documents(FILES)
    if not docs:
        raise ValueError("문서를 찾지 못했거나 섹션이 비어 있습니다.")

    print("문서를 청크로 분할하는 중...")
    split_docs = DocumentProcessor.split_long_docs(docs)

    print("벡터 스토어를 구축하는 중...")
    vs = VectorStoreManager.build_and_save_vectorstore(split_docs)
    self.retriever = vs.as_retriever(search_kwargs={"k": DEFAULT_RETRIEVER_K})

    print("RAG 체인을 구축하는 중...")
    rag_chain = RAGChainBuilder.make_rag_chain(self.retriever)

    self.chain_with_history = RunnableWithMessageHistory(
        rag_chain,
        self.history_manager.get_session_history,
        input_messages_key="query",
        history_messages_key="history",
    )
    print("초기화 완료!")

코드 상세 설명

1. 문서 로드

def initialize(self) -> None:
    print("문서를 로드하는 중...")
    docs = DocumentProcessor.load_documents(FILES)
    if not docs:
        raise ValueError("문서를 찾지 못했거나 섹션이 비어 있습니다.")

텍스트 파일(finance-keywords.txt, nlp-keywords.txt)을 읽어 Document객체로 변환합니다. 만약 파일이 비어있다면 에러를 발생시켜 초기화가 멈추게합니다.

2. 청크 분할

    print("문서를 청크로 분할하는 중...")
    split_docs = DocumentProcessor.split_long_docs(docs)

이 단계에서는 문서를 그대로 쓰지 않고 길이가 너무 긴 섹션은 자동으로 잘라냅니다. 실제로는 DocumentProcessor.split_long_docs() 안에서 RecursiveCharacterTextSplitter라는 유틸을 써서, 일정한 크기(chunk_size=800) 단위로 청크를 나누고, 겹치는 부분(chunk_overlap=120)도 남겨둡니다. 이렇게 해야 LLM이 문맥을 놓치지 않고 검색 정확도가 올라갑니다.

아래는 split_long_docs 함수를 정의한 부분입니다.

# document_processor.py
    @staticmethod
    def split_long_docs(docs: List[Document], chunk_size: int = DEFAULT_CHUNK_SIZE, 
                       chunk_overlap: int = DEFAULT_CHUNK_OVERLAP) -> List[Document]:
        """긴 문서들을 청크로 분할합니다.

        Args:
            docs: 분할할 Document 객체들의 리스트
            chunk_size: 청크 크기
            chunk_overlap: 청크 간 겹치는 부분의 크기

        Returns:
            분할된 Document 객체들의 리스트
        """
        splitter = RecursiveCharacterTextSplitter(
            chunk_size=chunk_size,
            chunk_overlap=chunk_overlap,
            separators=TEXT_SPLITTER_SEPARATORS,
        )
        return splitter.split_documents(docs)

3. 벡터스토어 구축

    print("벡터 스토어를 구축하는 중...")
    vs = VectorStoreManager.build_and_save_vectorstore(split_docs)
    self.retriever = vs.as_retriever(search_kwargs={"k": DEFAULT_RETRIEVER_K})

이 단계에서는 잘라낸 문서 청크들을 벡터(숫자 표현)로 변환한 후, 이를 FAISS라는 벡터 데이터베이스에 저장합니다. 이 과정을 거쳐야 나중에 질문이 들어왔을 때, 관련성이 높은 문서들을 빠르게 찾아올 수 있습니다.

실제로는 VectorStoreManager.build_and_save_vectorstore()함수 안에서 다음 과정을 수행합니다.

# vector_store_manager.py
@staticmethod
def build_and_save_vectorstore(docs: List[Document], save_dir: Path = Path("./faiss_keywords")) -> FAISS:
    embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
    vectorstore = FAISS.from_documents(documents=docs, embedding=embeddings)
    save_dir.mkdir(parents=True, exist_ok=True)
    vectorstore.save_local(str(save_dir))
    return vectorstore

• 임베딩: OpenAI의 "text-embedding-3-small"모델을 사용해 각 문서를 벡터로 변환합니다.
• FAISS 저장: 변환된 벡터들을 FAISS에 저장하고, 로컬 디렉토리(faiss_keywords/)에도 파일(index.faiss, indel.pkl)로 남깁니다.
• retriever 변환: 마지막으로 vs.as_retriever(k=DEFAULT_RETRIEVER_K)를 통해 검색 인터페이스로 바꿉니다. 이제 사용자가 질문을 던지면, retriever가 FAISS에서 관련 문서 k개를 뽑아 RAG 체인에 넘깁니다.

4. RAG 체인 구축

    print("RAG 체인을 구축하는 중...")
    rag_chain = RAGChainBuilder.make_rag_chain(self.retriever)

이 단계에서는 검색기(retriever)를 받아서 RAG 파이프라인을 구성합니다. RAGChainBuilder.make_rag_chain()내부에서는 프롬프트 템플릿을 정의하고, LLM(ChatOpenAI)을 연결한 뒤, 검색 결과(retriever)에서 가져온 문서를 프롬프트에 포함시킵니다. 이렇게하면 "질문 → 관련 문서 검색 → 문맥을 붙여서 답변 생성"의 RAG 흐름이 완성됩니다.

5. 메모리 적용

    self.chain_with_history = RunnableWithMessageHistory(
        rag_chain,
        self.history_manager.get_session_history,
        input_messages_key="query",
        history_messages_key="history",
    )

마지막 단계에서는 체인에 대화 히스토리(메모리)를 붙입니다.

• RunnableWithMessageHistory로 감싸면, 동일한 세션(session_id) 안에서는 이전 대화 내용이 자동으로 프롬프트에 포함됩니다.
• input_messages_key="query" : 사용자가 입력한 질문
• history_messages_key="history" : 저장된 대화 히스토리

검색 모드

LLM을 붙이기 전에, 검색이 제대로 되는지 먼저 확인하는 모드입니다. 이 단계에서는 키워드를 입력하면, 관련 문서 섹션의 출처(source)와 제목(section_title)만 출력됩니다.

RAG를 튜닝할 때 첫번째 체크포인트입니다. 검색이 잘 안될 경우 답변 품질이 떨어지기 때문에 반드시 확인해야합니다.

def run_search(self, query: str) -> None:
    items = self.retriever.invoke(query)
    print("\n[Search Results]")
    for d in items:
        print("-", d.metadata.get("source"), d.metadata.get("section_title"))

채팅 모드(동기 스트리밍)

채팅모드에서는 stream()을 사용해 답변이 토큰 단위로 출력됩니다. 기다리지 않고 첫 토큰부터 바로 보여주기때문에 실시간 채팅 환경을 제공합니다.

def run_chat(self, query: str, session_id: str = DEFAULT_SESSION_ID) -> None:
    print("\n[Answer Streaming]")
    print("=" * 50)
    response_chunks = []
    for chunk in self.chain_with_history.stream(
        {"query": query},
        config={"configurable": {"session_id": session_id}}
    ):
        print(chunk, end="", flush=True)
        response_chunks.append(chunk)
    print("\n" + "=" * 50)
    if not response_chunks:
        print("❌ 응답을 생성할 수 없습니다.")
    else:
        print(f"✅ 응답 완료! (총 {len(''.join(response_chunks))} 문자)")

예를 들어, "딥러닝이 뭐야?"라고 물으면 한 글자씩 쌓이면서 답변이 완성됩니다.

코드 추가 설명

1. 함수 진입

def run_chat(self, query: str, session_id: str = DEFAULT_SESSION_ID) -> None:

인자로 query(사용자 질문)와 session_id(대화 세션 ID)를 받습니다. 세션 ID는 RunnableWithMessageHistory와 연결되어 있어서, 같은 세션 안에서는 대화 히스토리가 이어집니다. (여기서 히스토리 관리는 chat_history_manager.py의 get_session_history()함수가 담당합니다.)

2. 스트리밍 출력 준비

response_chunks = []
for chunk in self.chain_with_history.stream(
    {"query": query},
    config={"configurable": {"session_id": session_id}}
):

핵심은 self.chain_with_history.stream(...)입니다. self.chain_with_history는 initialize() 단계에서 만들어지는데, 사실은 이렇게 구성돼 있어요.

self.chain_with_history = RunnableWithMessageHistory(
    rag_chain,  # ← rag_chain은 rag_chain_builder.py에서 생성
    self.history_manager.get_session_history,
    input_messages_key="query",
    history_messages_key="history",
)

즉 self.chain_with_history = RAG 체인 + 메모리입니다.

• RAG 체인은 rag_chain_builder.py의 make_rag_chain()에서 생성
• 메모리는 chat_history_manager.py의 get_session_history()로 관리
• stream() 메서드는 답변을 한 번에 기다리지 않고, 토큰 단위로 잘라서 실시간으로 전달해줍니다.

3. 출력 처리

print(chunk, end="", flush=True)
response_chunks.append(chunk)

각 토큰(chunk)을 바로 출력(print)하면서, 동시에 리스트에 저장합니다. flush=True옵션 덕분에 터미널에 바로 찍히고, 버퍼에 쌓이지 않습니다. 이렇게 모아둔 response_chunks는 마지막에 답변 전체를 합칠 때 사용됩니다.

4. 최종 결과 출력

if not response_chunks:
    print("❌ 응답을 생성할 수 없습니다.")
else:
    print(f"✅ 응답 완료! (총 {len(''.join(response_chunks))} 문자)")

만약 스트리밍 도중 아무 토큰도 못 받으면 에러 메시지를 출력합니다. 정상적으로 답변이 생성되면 토큰을 전부 합쳐서 길이(문자 수)를 계산해 보여줍니다.

메모리 적용

(별도 함수는 없고, 위 run_chat/run_chatasync에서 session_id로 동작합니다.)

for chunk in self.chain_with_history.stream(
    {"query": query},
    config={"configurable": {"session_id": session_id}}
):
    ...

같은 세션(session_id)에서는 이전 대화를 기억합니다. 예를 들어, 먼저 "딥러닝이 뭐야?"라고 물은 뒤에 "예시를 들어줘"라고 하면 모델이 앞 대화의 맥락을 기억하고 이어서 대답합니다. 이것은 RunnableWithMessageHistory덕분에 가능한 기능입니다.

session_id는 사실상 “방 번호” 같은 역할을 합니다. 같은 방에서는 이전 대화가 그대로 이어지고, 새로운 session_id로 실행하면 완전히 새로운 대화 세션이 시작됩니다.

배치 처리

def run_batch(self, queries, session_id: str = DEFAULT_SESSION_ID):
    print("\n[Batch Processing]")
    results = self.chain_with_history.batch(
        [{"query": q} for q in queries],
        config={"configurable": {"session_id": session_id}}
    )
    for idx, (q, res) in enumerate(zip(queries, results)):
        print(f"\n[Query {idx+1}] {q}\n[Answer]")
        print(res)

batch()를 사용하면 여러 질문을 한 번에 처리할 수 있습니다. 예를 들어, ["시장 변동성 정의", "NLP 토큰화", "딥러닝이 뭐야?"]를 입력하면 각각의 답변이 순서대로 출력됩니다. 그리고 내부적으로 LCEL은 병렬 최적화를 지원하기 때문에, 순차 실행보다 빠르게 결과를 얻을 수 있습니다. 출력도 [Query 1], [Query 2]처럼 깔끔하게 정리돼 나오기 때문에 부하 테스트나 대량 요청 시 매우 유용합니다.

실행 방법

# ====== 1. 프로젝트 디렉토리 진입 ======
cd lcel_pipeline
python

# ====== 2. 파이썬 REPL에서 실행 ======
import asyncio
from main import RAGApplication

app = RAGApplication()
app.initialize()

# 비동기 실행
asyncio.run(app.run_chat_async("딥러닝이 뭐야?"))

비동기 스트리밍

async def run_chat_async(self, query: str, session_id: str = DEFAULT_SESSION_ID) -> str:
    print(f"\n[Async Answer Streaming] 질문: {query}")
    print("=" * 50)
    response = ""
    async for chunk in self.chain_with_history.astream(
        {"query": query},
        config={"configurable": {"session_id": session_id}}
    ):
        print(chunk, end="", flush=True)
        response += chunk
    print("\n" + "=" * 50)
    return response

astream()은 stream()의 비동기 버전입니다. 차이점은 “여러 요청을 동시에 처리할 수 있느냐”에 있습니다.

예를 들어, 동기 stream()은 한 사용자의 요청을 처리하는 동안 다른 요청은 대기해야 하지만, astream()은 동시에 여러 사용자의 질문을 받아 각각 독립적으로 스트리밍 답변을 보낼 수 있습니다.

서버 환경에서 동시 접속자가 많은 경우, 이 비동기 방식이 필수적입니다.

실행 방법

# ====== 1. 프로젝트 디렉토리 진입 ======
cd lcel_pipeline
python

# ====== 2. 파이썬 REPL에서 실행 ======
from main import RAGApplication

app = RAGApplication()
app.initialize()

queries = ["시장 변동성 정의", "NLP 토큰화", "딥러닝이 뭐야?"]
app.run_batch(queries)

마무리

이번 실습에서는 LCEL의 다양한 실행 방식(stream, astream, batch, branch, memory)을 실제 코드에 적용해보면서 RAG 파이프라인을 확장해보았습니다.

검색만 검증할 수 있는 검증 모드, 토큰 단위로 답변을 보여주는 스트리밍, 맥락을 이어가는 메모리, 여러 질문을 동시에 처리하는 배치, 서버 환경에서 유용한 비동기 처리까지 동시에 확인할 수 있었습니다.

처음에는 복잡해보였지만, 결국 LCEL은 각 단계를 Runnable블록으로 나누고 파이프(|)로 연결한다라는 단순한 원리에 기반하는 것을 깨달았습니다.

참고자료

LangChain Expression Language(LCEL) 원리 이해와 파이프라인 구축 가이드

여러분 혹시 한강라면 좋아하시나요? 저는 며칠 전에 한강에 갔다가 라면을 먹었는데, 대기 줄이 정말 길더라구요.

LCEL에 대해 공부하다가 이게 한강라면기계와 같은 것이 아닌가하는 생각이 들었습니다.(저도 왜 이런 생각을 했는지 모르겠네요😂 아마 배고파서 그런것 같아요.) 집에서 라면을 끓일 땐 물 계량, 불 세기, 면 넣는 타이밍까지 전부 직접 챙겨야 합니다. 그런데 한강 라면 기계는 그 과정을 다 자동화해주잖아요?

LCEL도 마치 그 한강 라면 기계와 비슷합니다.

우리가 "무엇을 할지(What)"만 선언하면 "어떻게 할지(How)"는 LangChain이 알아서 처리해줍니다. 덕분에 우리는 복잡한 세부 구현에 매달리지 않고, 큰 흐름만 설계하면 되는거죠.

이번 글에서는 위 특징을 가능하게해주는 핵심개념인 LCEL에 대해 정리해보겠습니다.

LCEL(LangChain Expression Language)이란?

공식문서에는 LCEL에 대해 다음과같이 소개하고 있습니다.

The LangChain Expression Language (LCEL) takes a declarative approach to building new Runnables from existing Runnables. This means that you describe what should happen, rather than how it should happen, allowing LangChain to optimize the run-time execution of the chains.

즉, LCEL은 기존 Runnable들을 조합해 새로운 체인을 선언적으로 표현하는 언어입니다. 중요한 점은 “무엇을 할지”를 기술하는 데 집중할 수 있고, 실행 과정의 최적화는 LangChain이 자동으로 처리한다는 겁니다.

LCEL의 주요 특징

• 모듈화(Modularity): 모든 구성 요소가 Runnable 단위로 통일되어 있어 조합이 쉽습니다.
• 일관된 실행 모델: 동기/비동기, 단일 입력/배치 입력, 스트리밍까지 모두 동일한 인터페이스로 실행 가능합니다.
• 확장성(Extensibility): 조건 분기, 사용자 정의 함수, 메모리 등 다양한 기능을 유연하게 추가할 수 있습니다.

이 중에서 가장 핵심이 되는 키워드가 바로 *"Runnable"*입니다. LCEL은 모든 요소를 Runnable단위로 추상화하기 때문에, Runnable을 이해하는 것이 곧 LCEL을 이해하는 출발점이라고 할 수 있습니다.

Runnable

개념

Runnable은 한마디로 입력을 받아 → 어떤 작업을 하고 → 출력을 내는 실행 단위입니다. LCEL에서는 모든 구성 요소(프롬프트, LLM, 검색기, 변환기 등)가 Runnable로 표현됩니다.

특징

1. 입력 → 출력 구조

• "무언가를 넣으면 결과가 나온다"라는 점에서 함수와 유사합니다.

• ex) "runnable"를 넣으면 "RUNNABLE" 출력

2. 공통 실행 방식 제공 모든 Runnable은 동일한 메서드를 가집니다.

• .invoke(input): 단일 입력 처리

• .batch([inputs]): 여러 입력 처리
  • .stream(input): 토큰 단위 스트리밍
  • .ainvoke, .abatch, .astream: 비동기 버전

3. 조합 가능

• Runnable들을 |(파이프)로 연결해서 체인(Chain)을 만듭니다.

• ex) 검색기 | 프롬프트 | LLM → RAG 체인

LCEL의 특징 중 하나인 조합 기능을 보면 이런 의문이 들 수 있습니다.

*"LCEL로 조립했을 때 뭐가 좋은거지?"* 🤔

LCEL을 사용했을 때의 가장 큰 장점은 "복잡한 기능을 단순하고 일관된 방법으로 제공한다"라는 점입니다. 병렬처리, 비동기, 스트리밍, 디버깅, 배포까지 모두 LCEL의 공통 인터페이스 안에서 쉽게 다룰 수 있다는 것이 장점입니다.

주요 Runnable 정리

이번에는 LCEL에서 자주 쓰이는 Runnable들을 정리해보겠습니다. 처음에는 "이게 뭐야?"싶었는데, 알고보면 되게 단순한 블록들입니다.

RunnablePassthrough

가장 간단한 Runnable입니다. 입력을 그대로 통과시켜줍니다. 아무 일도 안 하지만, 디버깅이나 중간 데이터를 확인할 때 은근 유용합니다.

from langchain_core.runnables import RunnablePassthrough

passthrough = RunnablePassthrough()
print(passthrough.invoke("Hello"))  
# 출력: "Hello"

RunnableLambda

python함수를 그대로 Runnable로 감싸는 기능입니다. 이를 통해 개발자는 자신만의 함수를 정의하고, 해당 함수를 RunnableLambda를 사용하여 실행할 수 있습니다.

from langchain_core.runnables import RunnableLambda

to_upper = RunnableLambda(lambda x: x.upper())
print(to_upper.invoke("hello"))  
# 출력: "HELLO"

예를 들어, 데이터 전처리, 계산, 또는 외부 API와의 상호작용과 같은 작업을 수행하는 함수를 정의하고 실행할 수 있습니다.

RunnableBranch

조건에 따라 실행 경로를 분기하는 Runnable입니다. 예를 들어, 질문에 "finance"라는 단어가 있으면 금융 체인으로, "nlp"가 들어가 있으면 NLP 체인으로 보내는 식입니다.

from langchain_core.runnables import RunnableBranch, RunnableLambda

branch = RunnableBranch(
    (lambda x: "finance" in x, RunnableLambda(lambda x: "금융 체인 실행")),
    (lambda x: "nlp" in x, RunnableLambda(lambda x: "NLP 체인 실행")),
    RunnableLambda(lambda x: "기본 체인 실행")  # fallback
)

print(branch.invoke("finance keyword"))  

RunnableWithMessageHistory

마지막은 대화형 시스템에서 정말 중요한 블록입니다. 이 Runnable을 사용하면 이전 대화 내용을 히스토리(history)로 저장해두고, 그 맥락을 이어받아 다음 대화를 할 수 있습니다.

예를 들어,

사용자: "노트북 추천 해줘." 모델: "게임용이 필요한가요, 아니면 코딩을 하기 위해 필요한가요?" 사용자: "코딩용" 모델: "그럼 가볍고 키보드 타건감이 좋은 모델을 추천해드릴게요"

이렇게 앞에서 했던 대화를 기억하고 이어서 답변할 수 있는 것이 바로 RunnableWithMessageHistory덕분입니다.

실행 방식

Runnable은 기본적으로 입력 → 처리 → 출력 구조인데, 실행하는 방법이 다양합니다. 상황에 따라 적절히 골라 쓰면 됩니다.

1. invoke 가장 기본적인 실행 방식입니다. 입력 하나를 동기적으로 처리합니다.

result = chain.invoke("딥러닝이 뭐야?")
print(result)

2. ainvoke invoke의 비동기 버전입니다. asyncio같은 환경에서 동시에 여러 요청을 처리할 때 유용합니다.

import asyncio

result = await chain.ainvoke("딥러닝이 뭐야?")
print(result)

3. batch 여러 입력을 한꺼번에 넣고 병렬 처리합니다. 리스트를 넣으면 리스트 결과가 나옵니다.

queries = ["딥러닝이 뭐야?", "NLP가 뭐야?", "금융 리스크란?"]
results = chain.batch(queries)
print(results)

4. abatch batch의 비동기 버전입니다. 비동기 서버 환경에서 동시에 수십 개 요청을 처리할 때 사용합니다.

queries = ["딥러닝이 뭐야?", "NLP가 뭐야?", "금융 리스크란?"]
results = await chain.abatch(queries)
print(results)

5. stream 체인 실행 결과를 토큰 단위로 스트리밍 출력합니다. 즉, 답변이 다 생성될 때까지 기다리지 않고, 하나씩 실시간으로 볼 수 있어요.

for chunk in chain.stream("딥러닝이 뭐야?"):
    print(chunk, end="")

6. astream stream의 비동기 버전입니다. 채팅 애플리케이션에서 토큰 단위로 실시간 출력할 때 자주 씁니다.

async for chunk in chain.astream("딥러닝이 뭐야?"):
    print(chunk, end="")

• invoke: 단일 입력 동기 실행 • ainvoke: 단일 입력 비동기 실행 • batch: 여러 입력 동기 실행 • abatch: 여러 입력 비동기 실행 • stream: 스트리밍 동기 실행 • astream: 스트리밍 비동기 실행 👉 결국 상황에 따라 "단일/여러 개" + "동기/비동기/스트리밍" 조합으로 고르면 됩니다.

마무리

오늘은 LCEL을 한강 라면 기계 비유로 풀어보고, Runnable의 개념부터 실행 방식, 그리고 주요 블록들까지 정리해봤습니다.

요약하자면..

• Runnable은 LCEL의 가장 작은 실행 단위(입력->처리->출력)
• LCEL은 이 Runnable들을 레고 블록처럼 조합해서 체인을 만드는 언어
• 병렬 처리, 비동기, 스트리밍, 메모리 같은 기능을 쉽게 적용할 수 있다는 점이 강점

👉 결국 LCEL을 쓰면 복잡한 구현을 단순한 흐름 설계로 바꿀 수 있다는 것이 핵심입니다.

다음 글에서는 실제로 LCEL을 활용해서 RAG 파이프라인을 직접 구축하는 실습을 다뤄볼 예정입니다. 실제 코드와 실행 결과를 보면서, 오늘 배운 내용이 어떻게 쓰이는지 확인해보는 시간을 가져봅시다.

참고자료

• LangChain 공식문서
• LangChain Expression Language(LCEL) 원리 이해와 파이프라인 구축 가이드

JPA에서 엔티티를 조회할 때 연관된 엔티티를 언제 불러올지는 중요한 주제입니다. 이를 결정하는 방식이 바로 지연 로딩과 즉시 로딩입니다. 이번 포스팅에서는 두 로딩 방식의 동작 차이를 코드 예제와 함께 살펴보고, 여기서 자주 발생하는 N+1문제까지 연결해서 정리해보겠습니다.

1. 지연 로딩 LAZY를 사용하여 프록시로 조회

먼저 이번 예제에서 사용할 연관관계 구조를 그림으로 정리하면 다음과 같습니다.

이 구조를 코드로 매핑한 Member 엔티티는 다음과 같습니다.

Member엔티티 코드

import jakarta.persistence.*;
import lombok.Getter;
import lombok.Setter;

@Entity
@Getter
@Setter
public class Member extends BaseEntity {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "MEMBER_ID")
    private Long id;

    @Column(name = "USERNAME")
    private String username;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn
    private Team team;
}

위 코드는 fetch = FetchType.Lazy로 설정한 경우입니다.

실행 코드(Main)

package hellojpa;

import jakarta.persistence.*;
import org.hibernate.Hibernate;

import java.util.List;

public class JpaMain {

    public static void main(String[] args) {

        System.out.println("MARKER >>>>>>>>>>>>>>>>>>");

        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
        EntityManager em = emf.createEntityManager();

        EntityTransaction tx = em.getTransaction();
        tx.begin(); //트랜잭션 시작

        try {
            Team team = new Team();
            team.setName("teamA");
            em.persist(team);

            Member member1 = new Member();
            member1.setUsername("member1");
            member1.setTeam(team);

            em.persist(member1);

            em.flush();
            em.clear();

            Member m = em.find(Member.class, member1.getId());

            System.out.println("m = " + m.getTeam().getClass());

            tx.commit();
        } catch (Exception e) {
            tx.rollback();
            e.printStackTrace();
        } finally {
            em.close();
        }
        emf.close();
    }

}

Member만 먼저 조회되고(select * from MEMBER …), Team은 실제 속성 접근 시 쿼리가 나가며 초기화됩니다. 즉, “Member 조회 시 Member만 조회 / Team은 프록시로 보관 → 사용하는 순간 DB 조회”가 지연 로딩의 핵심 동작입니다.

그럼 Team은 언제 실제로 불러올까요? 🤔

아래처럼 실행 코드를 조금 바꿔서 getName()을 호출해보면, 이 시점에 프록시가 초기화되며 쿼리가 실행되는 것을 확인할 수 있습니다.

try {
            ...

            System.out.println("m = " + m.getTeam().getClass());

            System.out.println("====================");
            m.getTeam().getName(); //초기화 시점
            System.out.println("====================");

            tx.commit();
        }

team의 어떤 속성을 사용하는(실제 team을 사용하는 시점. team을 가져오는 시점이 아닙니다.) 시점에 프록시 객체가 초기화되면서 db에서 Team을 가져옵니다.

2. 즉시 로딩(EAGER)을 사용해서 함께 조회

Member와 Team을 자주 함께 사용하는 경우에는 즉시로딩(EAGER)를 사용해서 함께 조회할 수 있습니다.

    @ManyToOne(fetch = FetchType.EAGER) //지연로딩(LAZY: team을 proxy로 조회)
    @JoinColumn
    private Team team; //연관관계 주인

즉시 로딩을 사용하는 경우, em.find()를 호출하면 Member와 Team을 한 번에 직접 조회합니다.

따라서 연관 엔티티가 프록시가 아닌 실제 엔티티로 로딩됩니다.

m.getTeam().getClass()를 확인해보면 class hellojpa.Team이 출력되며, m.getTeam().getName()을 호출하면 지연 없이 바로 teamA가 출력됩니다.

즉, member1을 조회하면 곧바로 team1 엔티티까지 함께 가져옵니다.

즉시 로딩을 사용하는 경우 JPA 구현체는 다음과 같이 동작할 수 있습니다.

• 조인을 사용하여 SQL 한 번에 함께 조회합니다.
• 또는 두 테이블을 각각 조회하여 데이터를 채울 수 있습니다.

대부분의 경우 JPA 구현체는 가능하다면 조인을 사용해서 SQL 한 번에 조회하려고 합니다.

3. 프록시와 즉시로딩 주의

1) 실무에서는 가급적 지연 로딩만 사용해야 합니다.

즉시 로딩을 적용하면 예상하지 못한 SQL이 발생할 수 있습니다.

예를 들어, 연관된 테이블이 10개라면, 단순히 find() 한 번으로도 10개의 테이블이 전부 조인되어 성능이 급격히 떨어질 수 있습니다.

2) 즉시 로딩은 JPQL에서 N+1 문제를 일으킵니다.

즉,

• 1번: select * from Member
• N번: 각 Member의 Team을 가져오기 위한 select * from Team where TEAM_ID = ?

결과적으로 총 1 + N번의 쿼리가 발생하는 것이 바로 N+1 문제입니다.

예제 코드 (Member 1명, Team 1개 / EAGER 가정)

public class JpaMain {

        ...
        try {
            Team team = new Team();
            team.setName("teamA");
            em.persist(team);

            Member member1 = new Member();
            member1.setUsername("member1");
            member1.setTeam(team);

            em.persist(member1);

            em.flush();
            em.clear();

            // JPQL: 루트 엔티티(Member)목록 조회
            List<Member> members = em.createQuery("select m from Member m", Member.class).getResultList();

            tx.commit();
        } 
        ...
    }

}

로그 해석

1. 쿼리 1실행 (Member 조회)

   select * from Member;

JPQL select m from Member m 가 그대로 Member 테이블 조회로 변환됩니다.

2. 쿼리 2실행 (Team 조회)

   select * from Team where TEAM_ID = xxx; //xxx에는 각 Member가 가진 TEAM_ID값이 바인딩

   Member 엔티티의 team 필드가 EAGER로 지정되어 있기 때문에, 조회된 Member의 연관 Team을 즉시 초기화하기 위해 추가 SQL이 실행됩니다.

즉, Member 1번 + Team 1번 = 총 2번의 쿼리가 실행됩니다. (여기서 Team이 프록시가 아닌 실제 엔티티로 채워집니다.)

요약

• Member 엔티티 목록을 조회하는 JPQL 한 줄이 실제로는 Member 쿼리 1번 + Team 쿼리 N번을 발생시킵니다.

• 이 때문에 총 1 + N번의 쿼리(N+1 문제)가 실행됩니다.
• 즉, em.createQuery 결과 리스트를 만들 때 이미 Member와 Team이 모두 채워져 있어야 하므로 JPA가 자동으로 Team까지 가져오는 쿼리를 날리는 것입니다.

LAZY로 지정했을 경우

같은 JPQL을 실행하더라도 연관관계가 LAZY이면 처음에는 select * from Member 한 번만 실행됩니다. Team은 실제로 getTeam().getName() 같이 Team의 속성을 사용하는 순간에 별도 쿼리가 나가며 초기화됩니다.

즉, 실제로 접근하기 전까지는 쿼리가 나가지 않는다는 점이 핵심입니다.

3) N+1문제 해결 방법

• 모든 연관관계 기본은 지연 로딩(LAZY)로 설정 (@ManyToOne, @OneToOne은 기본이 EAGER → 꼭 fetch = FetchType.LAZY로 변경)
• 필요할 때만 fetch join으로 가져오기 : Member는 LAZY지만, JPQL에서 join fetch를 사용했으므로 Member와 Team을 한 번에 조인해서 가져옵니다.

  # JpaMain.java
  List<Member> members = em.createQuery(
    "select m from Member m join fetch m.team", Member.class)
    .getResultList();

  • 엔티티 그래프(EntityGraph) : 애노테이션이나 동적 API를 통해 특정 시점에 연관 엔티티까지 함께 조회하도록 설정 가능
  • 배치사이즈 방법 : 여러 개의 연관 엔티티를 한 번의 IN 쿼리로 묶어서 가져오도록 최적화

실무 권장 사항

• 모든 연관관계는 기본적으로 LAZY로 설정하는 것을 추천합니다.
• 실제로 함께 조회가 꼭 필요한 상황에서는 fetch join 또는 엔티티 그래프를 활용하는 것이 좋습니다.
• 즉시 로딩(EAGER)은 사용하지 말 것 → 의도하지 않은 조인이나 N+1 문제가 발생할 수 있습니다.

처음에는 "뭔가 계층 간 데이터를 전달하는 용도인가보다~" 하고 지나쳤지만, 실제로 회원가입 기능을 만들면서 DTO가 왜 필요한지, 어떻게 써야 하는지 체감하게 되었습니다.

이 글에서는 직접 회원가입 기능을 구현하면서

• DTO를 왜 따로 만드는것이 좋은지

• 유효성 검증 과정에서 어떤 문제가 발생했는지
• 그리고 어떻게 해결했는지

제가 겪은 과정을 기반으로 정리해보려고 합니다.

DTO란?

DTO (Data Transfer Object)는 계층 간 데이터 전달을 위해 사용하는 순수 데이터 전송 객체입니다. 웹 애플리케이션에서는 사용자의 입력값을 안전하게 받기 위한 전용 폼 객체로 자주 사용됩니다.

🤔 왜 굳이 DTO를 써야 할까?

처음엔 이렇게 생각했습니다.

"User 엔티티를 그냥 써도 되지 않나? 굳이 SignupFormDto 같은 걸 왜 만들어야 하지?"

회원가입 기능을 만들며 겪은 실제 흐름

처음엔 이렇게 User 엔티티를 그냥 컨트롤러에 받아서 처리했습니다.

@PostMapping("/signup")
public String signup(User user) {
    userRepository.save(user);
    return "redirect:/login";
}

간단해 보이지만 몇 가지 문제가 있었습니다.

❌ User 엔티티를 바로 받으면 생기는 문제

그래서 등장한 DTO

회원가입에 필요한 필드만 딱 담은 전용 객체 SignupFormDto를 만들었습니다.

@Data
public class SignupFormDto {

    @NotBlank(message = "아이디는 필수입니다.")
    private String userId;

    @NotBlank(message = "비밀번호는 필수입니다.")
    private String password;

    @NotBlank(message = "이름은 필수입니다.")
    private String username;

    @Email(message = "이메일 형식이 올바르지 않습니다.")
    @NotBlank(message = "이메일 입력은 필수입니다.")
    private String email;

    @NotBlank(message = "소속 선택은 필수입니다.")
    private String affiliation; //학생대, 교육대

    @NotBlank(message = "중대 선택은 필수입니다.")
    private String unit; //1~3중대
}

오직 회원가입 시 사용자가 입력한 정보만 받도록 설계했습니다.

그런데 검증이 안된다?

@NotBlank, @Email을 다 붙였는데 값 안넣고 제출해도 그대로 통과되는 문제가 발생했습니다.

그 이유는 바로 @Valid와 BindingResult의 위치와 사용 여부 때문이었습니다.

유효성 검증이 동작하려면

컨트롤러는 다음처럼 구성되어야 합니다.

@PostMapping("/signup")
    public String processSignup(@Valid @ModelAttribute("signupForm") SignupFormDto form, BindingResult bindingResult, Model model) {

        if (bindingResult.hasErrors()) {
            return "signup"; // 유효성 에러 처리
        }

        try {
            signupService.registerUser(form);
            return "redirect:/login?signupSuccess"; //회원가입 성공 시 로그인 페이지로
        } catch (IllegalArgumentException e) {
            model.addAttribute("error", e.getMessage());
            return "signup";
        }
    }

❗️ 순서 주의: 반드시 @Valid → BindingResult 순서로 선언

처음엔 try-catch문이 있는데 왜 유효성 에러처리가 안되지? 라고 생각했는데 @Valid 유효성 검사는 컨트롤러 메서드 호출 전에 실행되기 때문이었습니다.

BindingResult가 없으면? : 검증 실패 시 Spring이 MethodArgumentNotValidException을 던지고 예외로 끝냅니다 → try-catch 안으로 못 들어옵니다.

폼 페이지 (Thymeleaf)

<form th:action="@{/signup}" th:object="${signupForm}" method="post">
  <input type="text" th:field="*{userId}" />
  <small th:if="${#fields.hasErrors('userId')}" th:errors="*{userId}"></small>

  <input type="text" th:field="*{email}" />
  <small th:if="${#fields.hasErrors('email')}" th:errors="*{email}"></small>

  <select th:field="*{affiliation}">
    <option value="">📌 선택하세요</option>
    <option value="학생대">학생대</option>
    <option value="교육대">교육대</option>
  </select>
  <small th:if="${#fields.hasErrors('affiliation')}" th:errors="*{affiliation}"></small>
</form>

자 그럼 이렇게 DTO를 쓸 경우 어떤 점이 좋아질까요?

DTO 사용 시 장점

정리

• 회원가입 같은 폼에서는 User 엔티티를 직접 사용하지 않는 것이 좋습니다.
• User엔티티는 DB 저장용 객체이고, 사용자의 입력값은 DTO로 분리하는 것이 좋습니다.
• 유효성 검증은 DTO에 어노테이션으로 붙이고 컨트롤러에서는 @Valid, BindingResult로 처리해야 합니다.
• Thymeleaf에서는 th:field, th:errors를 제대로 써야 오류 메시지 표시가 가능합니다.

결론

DTO는 단순한 데이터 전달용 객체가 아닙니다. 사용자 입력을 안전하게 받고, 검증하고, 분리해서 처리하기 위한 아키텍처적 보호막이자, 유지보수성과 보안성을 높이는 필수 도구입니다.

📌 이 글은 WingITs의 기술 구조 정리입니다. 이 프로젝트가 어떻게 시작되었는지 궁금하시다면 👉 개발일지 WingITs #1~#6

프로젝트 개요

제가 개발한 노트북 관리 시스템 WingITs는 Spring Boot 기반의 MVC 아키텍처로 설계되었습니다.

• Controller가 사용자 요청을 받고,
• Service에서 비즈니스 로직을 처리하며,
• Repository (JPA 기반)를 통해 MySQL과 연동됩니다.

프론트엔드는 Thymeleaf를 사용하여 렌더링되며, 사용자 역할에 따라 학생과 관리자 기능을 명확하게 분리하였습니다.

인증과 보안은 Spring Security를 기반으로 구현했고, Google/Kakao OAuth2 로그인도 지원합니다. 특히 관리자 계정은 승인 절차를 거쳐야 로그인할 수 있도록 설정하여 보안을 강화했습니다.

운영 환경은 Docker 기반으로 구성되어 있으며, 개발 초기에는 H2 DB를 사용하다가 배포 단계에서 MySQL로 전환하였습니다. 또한 초기 데이터 세팅을 위해 Excel 업로드 기능도 구현했습니다 (Apache POI).

프레임워크 및 라이브러리별 역할 정리

각 기술을 선택한 이유

Spring Boot

• spring-boot-starter-web 하나만 추가해도 필요한 웹 기능이 자동 설정됨
• 복잡한 설정 없이 빠르게 개발 시작 가능
• 내장 톰캣 서버 덕분에 별도 WAS 설정 없이 실행 가능 → 개발 생산성 ↑

Thymeleaf

• Spring MVC와의 자연스러운 통합 덕분에 별도 설정 없이 사용 가능
• 컨트롤러에서 전달한 데이터를 템플릿에서 직관적으로 활용 가능
• 서버사이드 렌더링에 적합한 직관적 문법

Spring Security

• Spring 생태계에 최적화된 보안 프레임워크
• 인증/인가 설정 및 커스터마이징이 유연함
• 별도 연동 없이도 강력한 보안을 쉽게 구현 가능

OAuth2

• Google, Kakao 등 외부 서비스와 손쉽게 연동 가능
• 사용자 비밀번호를 직접 다루지 않아 보안상 유리
• 정립된 인증 플로우 덕분에 구현이 간편하고 유지보수도 쉬움

BCrypt

• 솔트 자동 추가, 키 스트레칭 등 보안성이 뛰어난 해시 알고리즘
• Spring Security와의 연동이 자연스러워 쉽게 적용 가능
• 널리 사용되는 방식으로 신뢰성과 적용 편의성이 높음

Spring Data JPA + Hibernate

• 객체지향적으로 DB를 다룰 수 있어 코드가 직관적이고 재사용성 높음
• SQL을 직접 작성하지 않아도 되므로 반복적인 CRUD 로직이 줄어듦
• Repository 인터페이스만으로 기본 CRUD 자동 처리 가능

객체지향적으로 DB를 다룰 수 있다? : 데이터베이스의 테이블을 자바 객체로 매핑해서, 마치 자바 객체를 다루듯 데이터를 조작할 수 있다는 의미. 즉, 개발자는 SQL쿼리를 직접 작성하는 수고를 덜고, 자바의 클래스를 통해 데이터베이스 레코드를 다룰 수 있음. 👉 코드가 직관적, 재사용성 증가

반복적인 CRUD 로직을 줄일 수 있다? : 기본적인 데이터 조작 작업들(ex. 저장, 조회, 수정, 삭제 등)이 메서드 호출만으로 가능해지기 때문에 반복적인 코드를 줄이고 생산성을 높일 수 있음.

MySQL & H2

• 개발 초기에는 H2로 빠르게 작업
• 운영 환경에서는 안정적인 MySQL을 사용해 데이터 영속성과 확장성을 확보

Apache POI

• .xlsx 엑셀 데이터를 Java에서 쉽게 처리 가능
• 초기 사용자/노트북 등록 등 관리자 기능 구현에 활용

Docker

• MySQL을 Docker로 컨테이너화해 개발/운영 환경을 통일
• 환경 차이로 인한 문제 최소화
• 배포 자동화 및 협업에도 유리

마무리하며

이처럼 WingITs 프로젝트는 Spring Boot를 중심으로 보안, 인증, 데이터 연동, 배포 등 실제 서비스를 운영하기 위한 필수 요소들을 직접 설계하고 구현한 경험이 집약된 시스템입니다.

이후 포스트에서는 아래 주제들을 다룰 예정입니다:

• Spring Security + OAuth2 로그인 처리 흐름
• ControllerAdvice를 활용한 사용자 정보 처리
• JPA 연관관계 매핑 설계 및 이슈
• Docker-Compose로 구성한 로컬 개발 환경

아키텍처를 설계할 때 이 글이 도움이 되었으면 좋겠습니다. 🙌

2025년 3월 말, 군복무 중 직접 겪은 불편함을 해결하고자 시작한 노트북 수리 요청 시스템 WingITs는 기획부터 구현, 디자인, 배포 직전 단계까지 약 3개월 간의 개발 여정을 거쳐 완성되었습니다. 사실 전역 준비와 이사 준비로 예상했던 것보다 더 오래 걸렸던 것 같네요.

🛠 아직 배포하지 않은 이유

현재까지의 개발 결과물은 완성도 측면에서 핵심 기능이 대부분 구현되어 실사용이 가능한 수준이지만, 아직 외부 배포는 진행하지 않았습니다.

그 이유는...

• 군부대 특성상 실제 학생/교직원 정보를 외부 서버에 올릴 수 없음
• 이 시스템은 실제 부대 내에서 사용될 목적으로 직접 개발한 것이기 때문에,
  → 정보보호 및 보안에 대한 내부 검토가 반드시 필요
• 아직 보안 기능이 충분히 안전한지 검토가 완료되지 않음
• 현재는 임의의 테스트 데이터를 활용해 기능을 검증하고 있으며, 실제 학생 및 교직원 정보를 포함한 운영 환경 적용은 군 부대의 보안 검토 절차를 모두 마친 후, 공식적인 허가가 떨어지는 경우에 한해 외부 배포를 진행할 예정

☁️ 배포 방식에 대한 고민

원래는 Render를 통해 간편하게 배포하고, 테스트 사용자 피드백을 빠르게 받을 계획이었습니다.

하지만 이후 고려한 몇 가지 요소로 인해 EC2 + Docker 기반 클라우드 배포 방식으로 방향을 바꾸게 되었습니다:

• 보안 설정 및 서버 제어권 확보가 필요
• 단순 호스팅보다 직접 인프라 구성 경험을 쌓고 싶었음
• Docker, EC2, Nginx, HTTPS 인증서 등 기술적 역량 향상 목적

따라서 현재는 배포를 보류하고 있지만, 보안 검토 및 허가 절차가 완료되면 EC2 기반으로 정식 배포를 진행할 계획입니다.

🔭 향후 추가 예정 기능 및 개선 사항

💭 이 프로젝트가 나에게 남긴 것

• 실제 문제 해결의 전 과정을 경험하며 개발자로서의 자신감 얻음
• Spring Security, OAuth2, Docker 등 다양한 기술 스택을 실전에 적용
• 기획 → 개발 → 테스트까지의 경험

📌 다음 글부터는?

이번 시리즈에서는 마무리 단계 이후, 보안 검토를 통과하거나 실제 운영에 필요한 기능이 추가되는 경우를 중심으로 기능 개선 및 후속 개발기를 다룰 예정입니다.

• 관리자 전용 통계 기능 고도화
• 수리 요청 소유권 변경 로직 완성
• 실사용자 기반 피드백 반영 등

※ 개발 중 겪었던 다양한 시행착오와 기술적 문제들은 별도의 시리즈, "개발 이슈 로그"에서 보다 상세히 다루고 있습니다. 🔧

기존에는 학생 대상 공지를 대부분 카카오톡 단체방을 통해 전달했지만..

• 모든 선생님이 공지를 올리다 보니 중요한 정보가 금방 묻혀버리고
• 나중에 다시 확인하려 해도 검색이 어려운 문제가 자주 발생했습니다.

이를 해결하기 위해, 공지사항 · 게시판 · FAQ를 웹 시스템 내에 별도로 구현하고 역할별 접근 권한, 검색 기능, 댓글 기능 등을 통해 효율적인 커뮤니케이션 구조를 만들고자 했습니다.

📢 공지사항 기능

공지사항은 관리자만 등록할 수 있으며, 페이징 / 검색 / 파일 첨부 기능을 지원합니다.

• 목록에서 제목 클릭 시 상세 보기
• 첨부 파일이 있는 경우 다운로드 가능
• 최근 공지사항 5개는 메인 페이지에 미리보기로 표시됨
• 학생은 열람만 가능, 관리자는 작성 가능

💬 게시판 & 댓글 기능

게시판은 학생들이 자유롭게 글을 작성하고 소통할 수 있는 공간입니다.
각 게시글에는 댓글 기능이 포함되어 있어 간단한 피드백이나 공감 표현이 가능합니다.

• 학생: 게시글 작성, 수정, 삭제 가능
• 관리자: 게시글 작성은 불가, 학생 글 삭제 가능
• 댓글은 역할 상관없이 누구나 작성 가능
• 본인 댓글은 본인만 수정/삭제 가능, 관리자는 모든 댓글 삭제 가능
• 조회수 증가 기능
• 최근 게시글 5개는 메인 화면에 미리보기로 표시됨

❓ 자주 묻는 질문 (FAQ)

자주 묻는 질문은 Bootstrap 기반 아코디언 UI로 구현해 가독성을 높였습니다.

• 관리자가 등록
• 질문 클릭 시 답변이 펼쳐지는 구조
• 나중에 카테고리 필터 기능 추가 예정

🔐 역할 기반 접근 제한

⏭ 다음 글에서는...

개발 마무리와 회고, 그리고 앞으로 추가할 기능들에 대한 계획을 공유하며 이 프로젝트의 여정을 정리할 예정입니다. 특히 배포를 아직 하지 않은 이유, 그리고 향후 도입 예정인 보안 기능과 개선 계획에 대해서도 함께 다룰 예정입니다.

학생이 노트북 수리 요청을 보내고, 관리자가 그 요청을 검토하여 상태를 업데이트하는 과정은 곧 이 시스템이 해결하고자 했던 가장 중요한 ‘불편함’이었습니다.

🧑‍🎓 학생 → 수리 요청

학생은 로그인 후 마이페이지에서 본인의 노트북 정보를 확인할 수 있습니다. 이 페이지에서 직접 수리 요청을 작성할 수 있도록 구성했습니다.

📋 요청 내역 확인

요청한 내역은 요청 일자, 상태, 문제 요약으로 리스트업되며, 학생은 이를 통해 현재 수리 진행 상황을 실시간으로 확인할 수 있습니다.

🛠 관리자 → 수리 요청 관리

관리자는 모든 학생의 요청을 목록 형태로 한눈에 볼 수 있으며, 검색, 필터링, 정렬이 가능합니다.

각 요청을 클릭하면 상세 정보가 나오고, 여기서 관리자는 수리 상태를 다음중 하나로 변경할 수 있습니다.

• 수리 요청됨, 수리 중, 수리 완료, 반려

반려의 경우 관리자가 사유를 입력하여 학생이 반려 사유를 인지할 수 있도록합니다.

(중간 관리자의 경우 총괄 관리자와 다르게 승인과 반려 둘 중에 하나만 선택할 수 있습니다.)

🧭 상태 변경 로직 (예정)

향후에는 수리 요청 상태에 따라 노트북 소유자가 자동으로 전환되는 로직을 도입할 예정입니다.

예를 들어,

• 수리 요청됨 / 수리 중 상태일 때 → 소유자를 관리자로
• 수리 완료 시점 → 다시 학생에게 소유권 복구

이러한 흐름을 통해 실제 현장에서 자주 들었던

“누가 노트북을 가지고 있는지 모르겠어요…”

라는 문제를 기술적으로 해결하는 것을 목표로 하고 있습니다.

⚙️ 현재는 해당 로직을 구현하기 위한 엔티티/서비스 구조를 고민 중이며, 추후 기능 안정화 이후 단계적으로 도입할 계획입니다.

✅ 관리자 마이페이지에서 확인 가능

추가적으로, 관리자는 마이페이지에서 수리 요청 현황을 한눈에 파악할 수 있도록 구성된 통계 카드들을 통해 확인할 수 있습니다.

요청 수, 처리 상태, 이번 주 접수 건수 등을 시각적으로 보여주어 업무 효율을 높였습니다.

⚙️ 현재는 전체 수리 요청 기준의 통계만 제공되며, 추후에는 로그인한 관리자의 개인 처리 현황까지 구분하여 보여주는 기능도 추가할 예정입니다.

📌 요약

⏭ 다음 글에서는...

공지사항, 게시판, 그리고 FAQ까지 학생과 관리자 모두가 정보를 쉽게 주고받을 수 있도록 만든 커뮤니케이션 기능들에 대해 소개합니다. 특히 댓글 기능, 검색/페이징 처리, 역할 기반 접근제한 등의 구현 과정을 다룰 예정입니다!

이 프로젝트를 설계하면서 가장 고민이 많았던 부분 중 하나는 바로
“학생과 관리자가 동일한 로그인 페이지를 통해 접근하되, 서로 다른 권한을 갖게 하자”는 요구사항이었습니다.

처음에는 간단하게 생각했습니다.
“그냥 Role만 구분하면 되겠지?”

하지만 구현 단계에서는 여러 갈래의 고민이 이어졌습니다.

• 학생은 OAuth2만 허용하고, 관리자는 로컬 로그인만?
• 관리자도 OAuth2를 쓸 수 있게 하려면 추가 정보 입력을 어떻게 처리하지?
• 로그인 후 역할에 따라 라우팅을 나눌까, 통합할까?
• 로그인 폼을 아예 나눌까, 하나로 통합할까?

결국 제가 내린 결론은 이랬습니다:

👩‍🎓 학생

• 로그인 방식: 군번(ID) + 군번+생년월일 6자리 (초기 비밀번호)
• 사전 등록된 DB 정보 기반으로만 로그인 가능
• 최초 로그인 시 비밀번호 즉시 변경 필수
• 자동으로 ROLE_STUDENT 부여
• 학생 전용 기능만 접근 가능

👩‍💼 관리자

✅ 로컬 로그인

1. 회원가입 시 이름, 군번, 이메일 등 기본 정보 입력
2. ROLE_PENDING_ADMIN 상태로 DB 저장 (로그인 불가)
3. 총괄 관리자(ROLE_TOP_ADMIN)의 승인 후
4. ROLE_MID_ADMIN 권한 부여 → 로그인 가능

✅ OAuth2 로그인 (Google / Kakao)

1. OAuth2 로그인 성공 시 ROLE_TEMP으로 임시 등록
2. 즉시 추가 정보 입력 페이지로 리디렉션
3. 입력 완료 시 ROLE_PENDING_ADMIN으로 상태 전환
4. 총괄 관리자 승인 후 ROLE_MID_ADMIN 으로 변경 → 로그인 가능

🗝️ 관리자 권한 접근 정책

✅ ROLE_TEMP, ROLE_PENDING_ADMIN

• 로그인 가능
• 하지만 /admin/** 경로는 모두 접근 차단
• 단, 예외적으로 아래 경로는 접근 허용:
  • /admin/profile (추가 정보 입력용 페이지)

🔒 관리 기능은 사용 불가

✅ ROLE_MID_ADMIN, ROLE_TOP_ADMIN

• /admin/** 경로 포함한 모든 관리자 기능 접근 가능
• 권한 설명:
  • ROLE_MID_ADMIN: 일반 관리자
  • ROLE_TOP_ADMIN: 총괄 관리자 (다른 관리자 승인 가능)

🧑‍✈️ 총괄 관리자 (ROLE_TOP_ADMIN)

• ROLE_TOP_ADMIN은 시스템 초기 등록 시 1명만 존재
• 승인 대기 관리자 조회/승인 기능 (/admin/pending-admins)은 TOP_ADMIN만 접근 가능
• 추후 인수인계를 위한 TOP_ADMIN 권한 이관 기능 별도 개발 예정

⚙️ 설계 흐름

로그인 요청
├── 학생 로그인 (로컬)
│   └── DB에 저장된 사전 등록 정보 확인 → ROLE_STUDENT 부여
│
└── 관리자 로그인
    ├── 로컬 회원가입 → ROLE_TEMP
    │   └── ROLE_TOP_ADMIN 승인 → ROLE_MID_ADMIN
    │
    └── OAuth2 로그인 → ROLE_TEMP
        └── 추가 정보 입력 → ROLE_PENDING_ADMIN
            └── ROLE_TOP_ADMIN 승인 → ROLE_MID_ADMIN

🔁 로그인 폼, 하나로 통합할 것인가?

이 프로젝트에서 고민했던 포인트 중 하나는
"로그인 폼을 기술적으로 통합하면서도, 사용자 경험을 구분할 수 있을까?"였습니다.

처음에는 /login 하나로 통합된 폼만 제공했지만, 학생과 교직원이 혼동하지 않도록 UI 상에서만 탭으로 구분하는 방식으로 개선했습니다.

• 기술적으로는 여전히 하나의 엔드포인트(/login)
• 입력받은 userId(군번)을 기반으로 이메일을 조회
• Spring Security 내부에서 이메일 기반 인증 수행

덕분에 로그인 플로우는 단순하게 유지하면서도, 학생 / 관리자의 구분은 Role 기반으로 유연하게 처리할 수 있었습니다.

✅ 다음 글에서는...

다음 글에서는 가장 핵심 기능인 학생과 관리자가 주고받는 수리 요청 프로세스를 어떻게 시스템으로 구현했는지 소개할 예정입니다.
특히 수리 이력 관리, 상태 변경 흐름, 권한에 따른 요청 처리 방식까지 실제 현장 문제를 어떻게 해결했는지 상세히 풀어보려고합니다!

“그래서… 이걸 뭐부터 만들어야 하지?”

📌 기능 목록은 어디서 나왔을까?

시작은 아주 단순했습니다.
실제 업무 중 겪은 수리 요청 절차의 불편함을 ‘어떻게 하면 시스템화할 수 있을까’에서 출발했기 때문이죠.

그래서 처음엔 그냥 내가 자주 들었던 말들을 적어봤습니다.

• "선생님, 제 노트북 수리 요청하고 싶은데요."
• "담당자분 누구셨어요?"
• "수리 맡긴지 오래됐는데 지금 어디 있는지 모르겠어요."
• "어떤 학생 노트북이 고장나서 다른 노트북으로 교환했는데 지금 누가 사용하고있는지 모르겠네요."

이런 대화 속에서 필요한 기능들이 자연스럽게 떠올랐습니다.

🎯 최소 기능 목록

• 학생
  • 수리 요청 등록
  • 내가 맡긴 수리 내역 확인
• 관리자
  • 수리 요청 목록 보기
  • 요청 상태 변경 (접수됨 / 수리 중 / 완료 등)
  • 수리 이력 관리

우선은 이 정도만 있어도 “입력 → 처리 → 이력 확인”의 흐름이 가능하다고 생각했습니다.

🔁 기능을 정하면서 고민했던 점들

처음엔 기능이 아주 단순할 거라고 생각했지만, 실제로 만들다 보니 하나하나에서 고민할 게 정말 많았습니다.

1. 수리 요청은 누구나 할 수 있을까?

→ 아니다. 로그인한 학생만 가능해야 했고, 중복 요청은 방지해야 했습니다.
→ 그래서 상태가 '처리 중'인 요청이 있을 땐, 새 요청을 막는 로직을 넣었습니다.

2. 관리자 권한은 어떻게 나눌까?

→ 그냥 다 admin이면 될 줄 알았는데, 관리자도 중간 관리자 / 최고 관리자로 나눠야 했습니다. (관리자 인원이 증가할수록 수동으로 사용자를 변경하는 기능을 모든 관리자가 할 수 있다면 잘못 설정하는 일이 발생할 수 있다고 생각이 들었습니다.)

3. 수리 요청 상태는 어떻게 설계할까?

→ '요청됨 → 수리 중 → 수리 완료'처럼 간단해보이지만, 학생들이 요청서를 잘못 적는 경우도 있기 때문에 실제로는 '반려됨'같은 예외 상태도 필요했습니다.

→ 그래서 enum으로 RepairStatus를 설계하고, 뷰에서도 한눈에 상태별 UI를 바꿔줄 수 있도록 처리했습니다.

🧠 흐름도와 ERD의 시작

처음에는 아주 단순한 흐름만 그렸습니다.

• 수리 요청 흐름: 학생 → 요청 등록 → 관리자 확인 → 처리
• 화면 구성: 로그인 → 메인 → 내역 확인 (학생) / 전체 요청 관리 (관리자)

ERD도 초안은 금방 그렸지만, 개발을 진행하면서 기능이 늘어나고 흐름이 바뀌며 구조도 계속 수정됐습니다.

그래서 이 글에서는 구체적인 ERD보다는, 어떤 기능을 어떤 흐름으로 구현했는지에 초점을 맞춰 정리해보려 합니다.

🤔 정리하며

‘기획’이라고 해서 거창한 게 필요한 건 아니었습니다. 오히려 내가 겪은 불편함을 적어보는 것부터 시작하니 그 안에서 자연스럽게 기능들이 나왔습니다.

무조건 많이 만들기보다는, 실제로 필요한 흐름을 작동시킬 수 있는 최소한의 기능에서 부터 출발하는 게 정말 중요하다고 느꼈습니다.

다음 글에서는...

✅ 개발 중 가장 복잡했던 "학생과 관리자, 로그인은 같지만 권한은 다르게"
인증 방식과 권한 분리, 그리고 로그인 흐름 설계에 대해 자세히 풀어보려 합니다.

🙋‍♀️ 왜 시작했을까?

장교로 군 복무 중, 항공과학고에서 전산 교관으로 근무하면서 저는 학교 내 노트북의 소프트웨어 관리를 담당하고 있었습니다.

이 시기, 학생들의 수리 요청은 대부분 고장 난 노트북을 직접 들고 와서 구두로 설명하거나, 종이에 간단히 적어 전달하는 방식이었습니다.

요청이 많아질수록 내용을 체계적으로 기록하거나 수리 이력을 관리하기엔 너무나 비효율적인 구조였습니다.
(심지어 하드웨어 담당자와의 공간적 분리로 인해 수리 중 노트북이 분실되는 일도 있었습니다.)

“선생님, 제 노트북이 갑자기 꺼져요. 그래서 수리를 맡겼는데 노트북을 받지 못했어요.”
“그때 담당자는 누구셨죠?”
“음… 잘 모르겠는데요…?”

문제가 생겨도 이력을 추적할 수 없었고, 수리 상태를 공유하거나 누가 어떤 노트북을 갖고 있는지도 알기 어려웠습니다. 모든 것이 너무 아날로그적이었습니다.

그래서 생각했습니다.

“이걸 시스템으로 만들 수 있지 않을까?”

💡 처음엔 아주 단순했다

처음엔 그저 ‘수리 요청서 작성 기능’ 하나만 만들 생각이었습니다. 그런데 막상 시작하고 보니 생각보다 고려할 게 많았습니다.

• 누가 노트북을 보유 중인지 어떻게 판단할까?
• 수리 중일 땐 소유권이 누구에게 있을까?
• 관리자와 학생의 권한을 어떻게 분리할까?
• OAuth2 로그인도 붙일 수 있을까?
• 어차피 하는 김에 공지사항, 댓글, 마이페이지도?

하나씩 기능이 붙어가며, 단순한 요청서 시스템에서 자산 및 수리 이력 관리 시스템으로 확장됐습니다. 기획부터 개발까지 모든 걸 직접 하면서 첫 웹 서비스를 완성했습니다.

🧱 기술보다 사용자 경험

이번 프로젝트에선 멋진 기술보다 “실제로 쓰기 편한가?”에 더 집중했습니다.

• 학생은 간단히 수리 요청을 등록할 수 있어야 했고
• 관리자는 전체 요청 내역과 현재 수리 상태를 한눈에 볼 수 있어야 했다
• 관리자 승인 흐름, 역할 구분, 로그인 방식까지 고려해야 했다
• 군 환경에 맞춘 OAuth2 로그인과 관리자 승인 로직도 직접 설계했다

그 과정에서 Spring Security, Docker, MySQL, Excel 데이터 마이그레이션까지
정말 다 해봤고… 그만큼 삽질도 많이 했습니다 😇

🏁 문제를 발견하고, 직접 만든 첫 개발 프로젝트

아직도 고칠 점은 많습니다. 하지만 이 프로젝트는 문제를 스스로 발견하고 → 기획하고 → 설계하고 → 개발한 나만의 첫 번째 서비스입니다.

그리고 무엇보다, 진짜 재밌었습니다.

💬 마무리

제가 만들고 싶은 건 “대단한 기술”이 아니라 “실용적이고 사용자에게 필요한 서비스”입니다.

WingITs는 그 첫걸음이었고, 앞으로 더 나은 개발자가 되기 위한 여정은 계속될 것입니다.

로컬 개발 환경에서 H2 인메모리 DB를 사용하다가 MySQL로 전환하면서 발생했던 문제들과 그 해결 과정을 정리합니다. Docker와 TablePlus를 활용했으며, data.sql 자동 실행 및 application-test.yml 오작동 등 다양한 이슈들을 직접 해결했습니다.

❗️문제 정의

H2에서 MySQL로 데이터베이스를 전환한 후 회원가입을 하게 되면 정상적으로 데이터가 저장되지만, 서버를 재시작하면 저장된 데이터가 사라지는 문제가 발생했습니다.

문제 재현 절차

1. IntelliJ에서 서버 실행

2. 브라우저에서 회원가입 진행

3. TablePlus에서 users 테이블 확인
   ▲ 회원가입 직후 TablePlus에 저장된 사용자 정보 확인 화면

4. IntelliJ에서 서버 종료 (DemoApplication 수동 종료)

5. Docker 컨테이너 종료

   docker stop wingits-mysql

6. Docker 컨테이너 다시 시작

   docker start wingits-mysql

7. IntelliJ에서 서버 재실행

8. 다시 TablePlus에서 users 테이블 확인
   ▲ 서버 재실행 후 회원 정보가 사라진 상태

🔍 사실 수집

• spring.jpa.hibernate.ddl-auto: update로 설정되어 있음
• 회원가입은 성공했고, TablePlus에서도 데이터 확인됨
• docker volume도 정상적으로 연결되어 있었음
• CommandLineRunner 안에서 userRepository.deleteAll() 사용
• data.sql 파일이 존재함
• application-test.yml에서 mysql을 사용하도록 되어 있었다는 사실을 발견함

💡 원인 추론

1. data.sql 자동 실행 → Spring Boot는 서버 시작 시 data.sql이 존재하면 이를 실행함. 이로 인해 MySQL DB의 기존 데이터가 매번 초기화됨.

▲ MySQL로 전환한 뒤에도 data.sql 파일이 남아 있는 상태

2. CommandLineRunner에서 deleteAll() 호출 → 개발 중 테스트용 코드가 실서버에서도 동작하며 회원 데이터를 모두 삭제해 문제를 악화시킴.

3. application-test.yml 설정이 제대로 분리되지 않음 → 테스트 환경에서도 실제 MySQL을 참조하게 되어 의도치 않게 실DB에 영향을 줄 수 있는 구조였음.

해결 방법 결정

1. 운영 환경에서 유저 데이터가 삭제되지 않도록 • CommandLineRunner 내 userRepository.deleteAll() 코드 제거

2. Spring Boot의 자동 SQL 실행 방지 • data.sql, schema.sql 파일 완전 삭제

3. 테스트 환경과 운영 환경의 설정 명확히 분리 • 운영은 MySQL, 테스트는 H2를 사용 • application.yml과 application-test.yml을 분리하고, 테스트에서는 아래와 같은 H2 설정만 유지

spring:
  datasource:
    url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1
    driver-class-name: org.h2.Driver
    username: sa
    password:
  jpa:
    hibernate:
      ddl-auto: create-drop
    show-sql: true
  h2:
    console:
      enabled: true

4. 도커 볼륨 확인 및 MySQL 영속성 확보 • Docker Volume이 /var/lib/mysql에 제대로 마운트되어 있는지 확인 (docker inspect 명령 사용) • 컨테이너 재시작 시 데이터가 유지되는지 테스트 완료

결론 요약

실수를 줄이기 위한 팁

• data.sql파일은 운영 환경에서 사용하지 않으면 삭제해두는 것이 좋습니다. (실수로 DB가 초기화될 수 있습니다.)
• CommandLineRunner에서 초기화 코드(deleteAll() 등)는 테스트 전용 조건 분기 또는 @Profile("test") 설정으로 운영 환경과 분리하는 것이 좋습니다.
• application.yml, application-test.yml의 설정을 명확히 구분하고, 테스트 환경에서는 반드시 H2 같은 인메모리 DB를 사용합시다.
• docker inspect 명령어로 볼륨 마운트 상태를 꼭 확인해두면, 데이터 손실 여부를 빠르게 파악할 수 있습니다.
• 중요한 설정(ddl-auto, datasource url 등)은 코드 리뷰 전 꼭 double-check!

현재 학교 내 노트북 수리 요청 및 사용자 관리 시스템을 개발 중입니다. Spring Boot와 Spring Security를 이용해 로컬 로그인과 카카오/구글 OAuth 로그인을 모두 지원합니다.

사용자 역할(Role)에 따라

• 일반 학생(STUDENT)은 게시글 작성 및 수리 요청 가능
• 관리자(MID_ADMIN, TOP_ADMIN)는 사용자/노트북 관리 권한을 갖습니다.

문제 상황

상단 메뉴바에 현재 로그인 중인 사용자 정보를 표시합니다. 이때 관리자 계정으로 로그인이 되어있기 때문에 TOP_ADMIN으로 표시되어야하나, 역할이 ANONYMOUS(손님)으로 잘못 표시되는 문제가 발생했습니다.

👉 문제는 게시글 상세 페이지(/posts/{id})에서만 발생했어요. 다른 페이지에서는 정상적으로 TOP_ADMIN | 관리자로 표시되었죠.

🔍 원인 분석

원인을 파악하기 위해 게시글 상세 페이지(/posts/{postId})와 관련된 컨트롤러에서 viewPost()메서드를 분석했습니다.

// 게시글 상세
    @GetMapping("/{postId}")
    public String viewPost(@PathVariable String postId,
                           Model model,
                           HttpServletRequest request) {

        postService.incrementViewCount(postId);
        Post post = postService.getPost(postId);
        model.addAttribute("post", post);
        model.addAttribute("comments", commentService.getCommentsByPostId(postId));

        // 현재 로그인한 사용자 정보를 가져오기 위한 인증 객체 획득
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

        // 인증된 사용자의 경우
        if (authentication != null && authentication.isAuthenticated()) {
            Object principal = authentication.getPrincipal();

            if (principal instanceof CustomOAuth2User user) {
                model.addAttribute("currentUserEmail", user.getEmail());
                model.addAttribute("userRole", user.getRole().name());
            } else if (principal instanceof org.springframework.security.core.userdetails.User user) {
                // 로컬 유저의 경우 DB에서 이메일/역할 가져오기 (‼️문제 발생 의심 지점‼️)
                System.out.println("✅ 로컬사용자"); //출력 ❌
                String email = user.getUsername(); // email이 username에 담김
                String role = postService.findRoleByEmail(email); // PostService에서 사용자 role 조회하는 메서드 만들기

                model.addAttribute("currentUserEmail", email);
                model.addAttribute("userRole", role);
            } else if (principal instanceof org.springframework.security.core.userdetails.User user) {
                String email = user.getUsername();
                String role = postService.findRoleByEmail(email);
                model.addAttribute("currentUserEmail", email);
                model.addAttribute("userRole", role);

            } else if (principal instanceof String email) {
                model.addAttribute("currentUserEmail", email);
                model.addAttribute("userRole", "USER");

            } else {
                model.addAttribute("currentUserEmail", null);
                model.addAttribute("userRole", "ANONYMOUS");
            }
        } else {
            model.addAttribute("currentUserEmail", null);
            model.addAttribute("userRole", "ANONYMOUS");
        }

        // CSRF
        CsrfToken csrfToken = (CsrfToken) request.getAttribute("_csrf");
        model.addAttribute("_csrf", csrfToken);

        return "post/view";
    }

콘솔 출력 결과 authentication != null && authentication.isAuthenticated()조건은 통과하지만 ✅ 로컬 사용자가 출력되지 않았습니다. principal instanceof org.springframework.security.core.userdetails.User user조건이 false가 되는 것이 원인이었죠.

SecurityContextHolder.getContext().getAuthentication().getPrincipal()을 통해 로그인 정보를 가져오는데, principal 객체 타입이 잘못되어 발생한 문제였습니다.

👉 그런데 저는 컨트롤러에서 CustomOAuth2User만 체크하고, CustomUserDetails는 체크하지 않아 userRole = ANONYMOUS로 떨어졌던 겁니다.

✅ 해결 방법

viewPost() 메서드에서 principal의 타입을 명확히 분기했습니다.

if (principal instanceof CustomOAuth2User user) {
    // OAuth 사용자 처리
    ...
} else if (principal instanceof CustomUserDetails userDetails) {
    // 로컬 로그인 사용자 처리
    ...
}

이로써 로컬 로그인 사용자도 userRole, username이 정확하게 나왔답니다!!👏👏👏

배운 점

• Spring Security의 Authentication.getPrincipal()은 로그인 방식에 따라 타입이 다르다.
• 로그인 방식을 혼합해서 사용할 땐, @ControllerAdvice나 개별 컨트롤러에서 instanceof 분기 처리를 꼭 하자!

WHERE과 HAVING의 차이를 비교하기 전에 우선 SQL쿼리의 실행 순서를 알아야합니다.

SELECT ename
FROM emp
WHERE empno=10
GROUP BY ename
HAVING count(*)>=1
ORDER BY ename;

위 쿼리에서 SELECT문의 실행 순서는 FROM > WHERE > GROUP BY > HAVING > SELECT > ORDER BY입니다.

WHERE과 HAVING

WHERE

SELECT * FROM 테이블 WHERE 조건절;

•    역할: 데이터를 그룹화(GROUP BY) 이전에, 개별 행(row) 수준에서 조건을 필터링.
•    적용 대상: 테이블의 개별 행.
•    사용 위치: FROM 절 바로 다음에 실행.
•    집계 함수(예: SUM, AVG)는 사용할 수 없음.

WHERE은 기본적인 조건절로 항상 FROM 뒤에 위치하며 다양한 비교 연산자로 구체적인 조건을 줄 수 있습니다.

HAVING

SELECT * FROM 테이블 GROUP BY 필드 HAVING 조건절;

•    역할: 데이터를 그룹화(GROUP BY) 이후에, 그룹 전체를 대상으로 조건을 필터링.
•    적용 대상: 그룹화된 데이터(aggregate data).
•    사용 위치: GROUP BY 절 뒤에 실행.
•    집계 함수(예: SUM, AVG)를 사용할 수 있음.

항상 GROUP BY 뒤에 위치하며 WHERE과 마찬가지로 다양한 비교 연산자로 조건을 줄 수 있습니다.

공통점과 차이점

둘 다 필드에 조건을 줄 수 있다는 것은 동일하지만, WHERE은 기본적으로 모든 필드에 조건을 줄 수 있지만 HAVING은 GROUP BY로 그룹화 된 필드에 조건을 줄 수 있습니다. 또한, HAVING에서 조건을 줄 필드는 SELECT에 반드시 명시되어 있어야 합니다.

적용 예제

우선 직업별 급여 합계 중에 급여 합계가 1000이상인 직업을 조회하는 상황을 가정해봅시다.

1. WHERE 사용( 오류 발생)

SELECT job, SUM(salary) AS total_salary
FROM employees
WHERE SUM(salary) >= 1000 -- 오류 발생
GROUP BY job;

SUM(salary)는 그룹화 이후에 계산되므로, WHERE(그룹화 이전에 적용됨)에서 사용할 수 없습니다.

2. HAVING 사용(올바른 사용)

SELECT job, SUM(salary) AS total_salary
FROM employees
GROUP BY job
HAVING SUM(salary) >= 1000;

쿼리 실행 흐름: • 1단계: FROM employees → 직원 테이블 로드. • 2단계: GROUP BY job → 직업별로 데이터를 그룹화. • 3단계: SUM(salary) → 각 그룹의 급여 합계 계산. • 4단계: HAVING SUM(salary) >= 1000 → 급여 합계가 1000 이상인 그룹만 필터링.

GROUP BY는 데이터를 그룹 단위로 묶는 작업을 합니다. 각 그룹에 대해 집계함수(SUM, AVG, COUNT, MAX, MIN 등)가 적용되며, 이 작업은 그룹화 후에 수행됩니다.

HAVING절은 GROUP BY 이후에 실행됩니다. 따라서, 이미 그룹화가 끝난 상태에서 SUM(salary) 값을 조건으로 사용할 수 있습니다.

HAVING은 그룹화된 결과에서 집계 결과를 필터링하므로 올바르게 작동합니다.

요약

• SUM(salary)는 그룹화된 결과를 기반으로 계산되기 때문에, 그룹화 이전의 WHERE절에서는 사용할 수 없습니다.
• 그룹화가 끝난 후 조건을 적용하려면, 반드시 HAVING절을 사용해야 합니다.
• WHERE는 개별 행을 대상으로 작동하지만, HAVING은 그룹 전체를 대상으로 작동합니다.
  • WHERE: 개별 행 수준의 필터링. 집계 함수 사용 불가.
  • HAVING: 그룹화된 데이터의 필터링. 집계 함수 사용 가능.

참고자료

• https://amaranth1ne.tistory.com/52
• https://velog.io/@rocknzero/having-where%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%A1%B0%EA%B1%B4%EC%A0%88-%EB%B9%84%EA%B5%90

👉 문제바로가기

n: 전체 사람의 수(1 ≤ n ≤ 100) a, b: 촌수를 계산해야하는 서로 다른 두 사람의 번호 m: 부모 자식들간의 관계의 개수 m x, y: 부모 자식간의 관계를 나타내는 두 번호(x는 y의 부모)

부모 자식들 간의 관계가 주어졌을 때, 이를 그래프로 구축하고 두 사람의 촌수(간선의 개수)를 구하는 문제입니다. 두 사람의 친척 관계가 전혀 없어 촌수를 계산할 수 없는 경우 -1을 출력해야합니다.

주어진 예제를 예시로 들어보겠습니다.

• 총 9명이 있습니다.

• 우리가 구해야하는 것은 7번과 3번의 촌수입니다.
• 부모 자식들 간의 관계의 개수는 7개입니다.
• 1번은 2번의 부모입니다.
• 1번은 3번의 부모입니다.
• 2번은 7번의 부모입니다.
• 2번은 8번의 부모입니다.
• 2번은 9번의 부모입니다.
• 4번은 5번의 부모입니다.
• 4번은 6번의 부모입니다.

위 정보를 그림으로 표현하면 아래와 같습니다.

주어진 부모 자식 관계를 통해 그래프를 구축하고, 3에서 시작하여 7까지 가는 간선의 수를 구하면 되는 문제입니다!

1️⃣ 입력 및 변수 정의

n = int(sys.stdin.readline())
a, b = map(int, sys.stdin.readline().split())
m = int(sys.stdin.readline())

2️⃣ 노드정보 저장 및 그래프 기록

graph = [[] for _ in range(n+1)]  #그래프 리스트 초기화
visited = [False] * (n+1)    #방문 여부

for _ in range(m):
    x, y = map(int, sys.stdin.readline().split())   #부모 자식 관계정보
    graph[x].append(y)
    graph[y].append(x)

3️⃣ DFS함수 정의

우리가 구해야하는 것은 한 정점에서 다른 노드까지의 간선 개수입니다. 따라서 dfs의 매개변수인 v에는 인자를 a로하여 호출하면 됩니다.

def dfs(v):
    global count
    visited[v] = True
    if v == b:
        print(count)
        exit()
    for i in graph[v]:
        if not visited[i]:
            count += 1 
            dfs(i)
            count -= 1 #재귀 호출이 끝나면 깊이 감소

dfs(s)
print(-1)    

dfs()에서 v == b인 경우 exit()를 만나 코드가 종료된다는 것은 우리가 찾고자하는 b를 만나면 자동으로 종료된다는 의미입니다. dfs()에서 코드가 종료되지 못하면.. 즉, for문을 모두 반복해도 원하는 값을 만나지 못하면 print(-1)이 실행됩니다.

📌 알고리즘 선택

한 점을 정점으로 선택하고 해당 점과 연결된 노드들을 모두 탐색하면서 원하는 값을 찾아야하기 때문에 DFS를 활용할 수 있겠네요.

시간복잡도

dfs함수가 한 번 호출되면, 현재 노드에서 가능한 모든 인접한 노드를 재귀적으로 탐색합니다. 모든 노드와 간선을 한 번씩 방문하므로 시간복잡도는 O(n+m)입니다. n의 최대값은 1000이고, 노드가 n개인 경우 부모-자식의 관계(간선의 수)는 n-1이므로 최대 999개가 됩니다. 따라서 최악의 경우 연산은 약 1999회가 수행되므로 이는 수행 시간 내에 충분히 연산이 가능합니다.

📌 코드 설계하기

1. 전체 사람의 수(n), 촌수를 계산해야하는 서로 다른 두 사람의 번호, 부모 자식들간의 관계의 개수(m)을 Input받습니다.
2. 부모 자식간의 관계를 나타내는 두 번호(x, y)를 입력받으면서 그래프를 구축합니다.
3. DFS를 수행하면서 간선의 개수를 카운트합니다.
4. 원하는 값을 가진 노드를 찾으면 count를 출력하고, DFS를 모두 수행했음에도 원하는 값을 찾지 못하면 -1을 출력합니다.

📌 정답 코드

import sys

count = 0

def dfs(v):
    global count
    visited[v] = True
    if v == b:
        print(count)
        exit()
    for i in graph[v]:
        if not visited[i]:
            count += 1 
            dfs(i)
            count -= 1 #재귀 호출이 끝나면 깊이 감소

n = int(sys.stdin.readline())
a, b = map(int, sys.stdin.readline().split())
m = int(sys.stdin.readline())

graph = [[] for _ in range(n+1)]  #그래프 리스트 초기화
visited = [False] * (n+1)

for _ in range(m):
    x, y = map(int, sys.stdin.readline().split())
    graph[x].append(y)
    graph[y].append(x)

dfs(a)
print(-1)

👉 문제바로가기

• N: 정점의 개수(1 ≤ N ≤ 1,000)

• M: 간선의 개수(0 ≤ M ≤ N×(N-1)/2)
• u, v: 간선의 양 끝점(1 ≤ u, v ≤ N, u ≠ v)

노드와 노드의 쌍이 주어진 경우 연결 요소의 개수를 구하는 문제입니다.

주어진 예제를 예시로 들어보겠습니다.

• 노드는 6개이며, 간선은 5개입니다.

• 1과 2가 연결되어 있습니다.
• 2와 5가 연결되어 있습니다.
• 5와 1이 연결되어 있습니다.
• 3과 4가 연결되어 있습니다.
• 4와 5가 연결되어 있습니다.

위 정보를 그림으로 그려보면 아래와 같습니다.

그림에서 볼 수 있듯이 1-2-5가 연결되어 하나의 요소를 이루고, 6-4-3이 연결되어 하나의 요소를 이룹니다.

이 문제를 보자마자 몇일 전 풀어보았던 순열 사이클 문제가 생각났습니다. (상당히 유사한 방법으로 풀 수 있겠네요ㅎㅎ)

요소의 개수를 구한다는 것은 한 점을 정점으로 선택하고 해당 점과 연결된 모든 노드들을 탐색해나가는 과정에서, 선택된 정점의 개수를 count한다는 의미로 해석하면 되겠네요.

결국 우리가 구해야 할 것은 정점의 개수입니다!!

1️⃣ 입력 및 변수 정의

먼저 정점의 개수(N)과 간선의 개수(M)를 공백을 사이에 두고 입력받습니다. 그래프 구축 전 그래프 리스트를 초기화하고 방문 여부를 담을 리스트도 정의합니다.

N, M = map(int, sys.stdin.readline().split())
graph = [[] for _ in range(N+1)]  #그래프 리스트 초기화
visited = [False] * (N+1)
count = 0

2️⃣ 노드정보 저장 및 그래프 기록

노드-노드 쌍을 공백을 사이에 두고 입력받은 후 인접리스트 방법으로 그래프에 저장합니다.

for _ in range(M):
    a, b = map(int, sys.stdin.readline().split())
    graph[a].append(b)
    graph[b].append(a)

3️⃣ DFS함수 정의

def dfs(v):
    visited[v] = True
    for i in graph[v]:
        if not visited[i]:
            dfs(i)

4️⃣ 연결 요소의 개수 구하기

1부터 시작해서 정점으로 잡고 연결된 모든 노드를 방문하며 dfs()를 수행합니다. 연결된 노드가 더이상 없을 경우 다른 정점을 찾아 dfs()를 다시 수행합니다. 정점을 하나 찾을 때 마다 count를 1씩 증가시킵니다.

for i in range(1, N+1):
    if not visited[i]:
        dfs(i)
        count += 1

📌 알고리즘 선택

한 점을 정점으로 선택하고 해당 점과 연결된 모든 노드들을 모두 탐색하면 되기 때문에 DFS를 활용할 수 있겠네요.

시간복잡도

• 그래프 구축: O(M)

• dfs탐색: O(N+M)

최악의 경우 DFS는 모든 노드와 간선을 정확히 한 번 방문합니다. 따라서 전체 시간복잡도는 O(N+M)입니다. N의 최댓값은 1000이고, M의 최댓값은 (1,000*999)/2이므로 약 500,000입니다. 따라서 연산은 최대 약 501,000번 수행되므로 주어진 시간 내에 충분히 가능한 연산입니다.

📌 코드 설계하기

1. N, M값과 노드-노드 쌍을 입력받습니다.
2. 노드 연결정보를 통해 그래프 리스트를 구축합니다.
3. DFS를 수행합니다.

📌 정답 코드

import sys

sys.setrecursionlimit(10000)

def dfs(v):
    visited[v] = True
    for i in graph[v]:
        if not visited[i]:
            dfs(i)

N, M = map(int, sys.stdin.readline().split())
graph = [[] for _ in range(N+1)]  #그래프 리스트 초기화
visited = [False] * (N+1)
count = 0

for _ in range(M):
    a, b = map(int, sys.stdin.readline().split())
    graph[a].append(b)
    graph[b].append(a)

for i in range(1, N+1):
    if not visited[i]:
        dfs(i)
        count += 1

print(count)

👉 문제바로가기

N: 게임에 참여하는 사람의 수(3 ≤ N ≤ 150) K: 보성이의 번호(1 ≤ K ≤ N - 1) ai: i번 사람이 지목하는 사람의 번호(0 ≤ i ≤ N - 1, 0 ≤ ai ≤ N - 1)

지목하는 사람의 번호를 입력받아 차례대로 다음 노드로 이동하여 보성이의 번호(K)를 찾는 문제입니다. 어떤 방법으로도 K를 찾지 못한다면 -1을 출력하면됩니다.

📌 알고리즘 선택

방법1: 단순히 지목하는 번호를 리스트에 담고, 그 번호를 가진 사람이 지목하는 번호를 뽑아 K와 일치하는지 확인하면서 몇 번 불렀는지 카운트하면 됩니다.

방법2: M번만에 보성이에게 도달하는 최단 경로를 찾는 문제이므로 bfs를 활용할 수도 있겠네요.

시간복잡도

1번 방법에서 최악의 경우 시간복잡도는 O(N)입니다. N의 최댓값은 150이므로 O(N)의 시간복잡도를 가진 알고리즘으로도 충분히 시간 내에 연산이 가능합니다.

📌 코드 설계하기

1. N, K를 공백을 두고 Input받습니다.
2. N줄에 걸쳐 각각 사람이 지목하는 사람의 번호를 Input받습니다.
3. 0부터 시작해서 해당 번호의 사람이 지목한 번호의 인덱스로 가서 다음 사람의 번호를 구합니다. 지목할때마다 count를 1씩 증가시키면서 K를 찾으면 count를 출력 후 반복문을 종료시키고, N번만큼 반복하여도 K를 찾지 못하면 종료하고 -1을 출력합니다.

📌 정답 코드

import sys

N, K = map(int, sys.stdin.readline().split())
numbers = [int(sys.stdin.readline()) for _ in range(N)]
count = 0
number = 0

for _ in range(N):
    if number != K:
        number = numbers[number]
        count += 1
    else:
        print(count)
        break
else:
    print(-1)            

👉 문제바로가기

입력

T: 테스트 케이스의 개수 N: 순열의 크기(2 ≤ N ≤ 1,000) 순열: 각 정수는 공백으로 구분

순열의 크기를 지정하고 순열이 주어진 경우 순열 사이클의 개수를 구하는 문제입니다. 한 숫자를 지정했을 경우 해당 숫자와 연결된 모든 노드를 탐색해야 합니다.

우리가 구해야 하는 것은 사이클의 수이며 사이클마다 정점은 하나씩 존재합니다. 결론적으로 우리는 정점의 갯수를 구해주면 됩니다!!

문제에서 주어진 순열을 예시로 들어보면, 8개의 순열 (3, 2, 7, 8, 1, 4, 5, 6)이 있을 경우 배열을 이용해 다음과 같이 표현할 수 있습니다.

1) 1 → 3, 3 → 7, 7 → 5, 5 → 1 2) 2 → 2 3) 4 → 8, 8 → 6, 6 → 4

위 순서를 참고하여 그림으로 나타내면 다음과 같습니다.

결국 1~8까지의 배열과 순열 (3, 2, 7, 8, 1, 4, 5, 6)를 하나씩 매치한 화살표가 노드와 노드의 연결을 의미합니다.

노드와 노드의 연결쌍을 알았으면 이전에 풀었던 문제들처럼 그래프를 기록할 수 있습니다.

1️⃣ 입력 및 변수 정의

먼저 테스트 케이스의 개수(T)와 순열의 크기(N)를 입력받습니다.

T = int(sys.stdin.readline())   #테스트 케이스 수
N = int(sys.stdin.readline())   #순열의 크기

이후 순열의 크기만큼 순열을 입력받고 방문 횟수여부를 담은 리스트visited를 정의합니다.

    arr2 = list(map(int, sys.stdin.readline().split()))   #순열
    visited = [False] * (N+1)
    count = 0   #정점의 수

arr1은 순열과 매치하기 위한 1~8까지의 숫자 리스트이기 때문에 반복문을 이용하여 1부터 순열의 크기만큼 숫자를 append해줍니다.

arr1 = []

for i in range(1, N+1):
    arr1.append(i)

2️⃣ 노드정보 저장 및 그래프 기록

1~8까지를 저장한 리스트 arr1과 8개의 수로 이루어진 순열을 저장한 리스트 arr2를 활용하여 노드와 노드의 연결 정보를 리스트newArray에 저장합니다.

newArray = [[] for _ in range(N)]

for i in range(N):
    newArray[i].append(arr1[i])
    newArray[i].append(arr2[i])

저장된 노드 정보를 활용하여 인접리스트를 활용해 리스트graph에 기록합니다. 이때 해당 리스트의 중복을 제거하고, 작은 수부터 시작하도록 정렬하기 위해 sort()를 사용합니다.

graph = [[] for _ in range(N+1)]

for i in range(N):
    graph[arr1[i]].append(arr2[i])
    graph[arr2[i]].append(arr1[i])

#graph의 각 요소들을 정렬
for i in range(N+1):
    graph[i] = list(set(graph[i]))   #중복제거
    graph[i].sort()    

3️⃣ DFS함수 정의

def dfs(start):
    visited[start] = True
    #현재 노드와 연결된 다른 노드를 재귀적으로 방문
    for i in graph[start]:
        if not visited[i]:
            dfs(i)

4️⃣ 순열 사이클 개수 구하기

1부터 시작해서 아직 방문하지 않은 연결된 노드들을 방문합니다. 모두 탐색했으면 방문하지 않은 다른 숫자를 정점으로해서 반복합니다. 정점이 하나 정해질때마다 count하여 정점의 개수를 구하고 출력합니다.

for i in range(1, N+1):
    if not visited[i]:
        dfs(i)
        count += 1

print(count)        

📌 알고리즘 선택

한 시작점이 정해지면 해당 노드와 연결된 노드를 끝까지 다 탐색해야 하므로 DFS를 활용하여 풀 수 있습니다.

시간복잡도

• 그래프 구축: O(N)

• 중복 제거 및 sort()를 사용하여 정렬: O(NlogN)
• dfs탐색: O(N+E)

최악의 경우 시간복잡도를 구하기 위해 N의 최대값이 1000인 경우, 모든 노드가 다른 모든 노드와 연결된 경우를 고려합니다. 이경우 E는 최대 N이며 결론적으로 E=N=1000입니다. 따라서 전체 시간복잡도는 O(N)+O(NlogN)+O(N)=O(NlogN)=O(1000*log1000)입니다.

📌 코드 설계하기

1. 테스트 케이스의 개수(T)와 순열의 크기(N)를 Input받습니다.
2. 노드의 정보를 저장하고 해당 정보를 활용해 그래프를 기록합니다.
3. DFS를 수행하면서 정점의 개수를 구하고 출력합니다.

📌 정답 코드

import sys

def dfs(start):
    visited[start] = True
    #현재 노드와 연결된 다른 노드를 재귀적으로 방문
    for i in graph[start]:
        if not visited[i]:
            dfs(i)

T = int(sys.stdin.readline())   #테스트 케이스 수

for _ in range(T):
    N = int(sys.stdin.readline())   #순열의 크기

    arr1 = []   
    arr2 = list(map(int, sys.stdin.readline().split()))   #순열
    visited = [False] * (N+1)
    count = 0   #정점의 수

    for i in range(1, N+1):
        arr1.append(i)

    newArray = [[] for _ in range(N)]

    for i in range(N):
        newArray[i].append(arr1[i])
        newArray[i].append(arr2[i])

    graph = [[] for _ in range(N+1)]

    for i in range(N):
        graph[arr1[i]].append(arr2[i])
        graph[arr2[i]].append(arr1[i])

    #graph의 각 요소들을 정렬
    for i in range(N+1):
        graph[i] = list(set(graph[i]))   #중복제거
        graph[i].sort()    

    for i in range(1, N+1):
        if not visited[i]:
            dfs(i)
            count += 1

    print(count)            

👉 문제바로가기

T: 테스트 케이스 개수 M: 배추밭의 가로 길이(1 ≤ M ≤ 50) N: 배추밭의 세로 길이(1 ≤ N ≤ 50) K: 배추가 심어져 있는 위치의 개수(1 ≤ K ≤ 2500) K줄에 배추의 위치X(0 ≤ X ≤ M-1), Y(0 ≤ Y ≤ N-1)가 주어진다.

배추가 심어져 있는 위치를 입력받고, 땅의 처음부터 끝까지 탐색하면서 정점의 개수를 찾는 문제입니다. 한 정점에 대해 탐색을 수행하면서 값이 1인 곳(배추가 심어져 있는 곳)의 방문 여부를 True로 변경시켜주면 됩니다.

1️⃣ 입력 및 변수 정의

M, N, K = map(int, sys.stdin.readline().split())
    arr = [[0] * M for _ in range(N)]  # 배추의 위치
    visited = [[False] * M for _ in range(N)]
    count = 0  # 정점의 갯수

2️⃣ 배추의 위치 설정

for _ in range(K):
    X, Y = map(int, sys.stdin.readline().split())
    arr[Y][X] = 1

3️⃣ 위치 탐색

for i in range(N):
        for j in range(M):
            if not visited[i][j] and arr[i][j] == 1:
                count += 1
                dfs(i, j) 

땅의 처음부터 끝까지 모두 탐색하면서 dfs()를 호출합니다. 한 번의 정점을 기준으로 탐색하고, 해당 탐색이 끝나면 다음 칸을 정점으로 잡고 다시 탐색합니다. 하나의 정점에 대해 탐색이 끝난 경우 배추흰지렁이는 더이상 이동할 수 있는 칸이 없으므로 1마리를 추가합니다. 정점의 갯수가 우리가 구하고자하는 배추흰지렁이의 수가 되는 것입니다.

4️⃣ DFS

def dfs(i, j): 
    visited[i][j] = True
    # 아래쪽 탐색
    if i + 1 < N and not visited[i + 1][j] and arr[i + 1][j] == 1:
        dfs(i + 1, j)
    # 위쪽 탐색
    if i - 1 >= 0 and not visited[i - 1][j] and arr[i - 1][j] == 1:
        dfs(i - 1, j)
    # 오른쪽 탐색
    if j + 1 < M and not visited[i][j + 1] and arr[i][j + 1] == 1:
        dfs(i, j + 1)
    # 왼쪽 탐색
    if j - 1 >= 0 and not visited[i][j - 1] and arr[i][j - 1] == 1:
        dfs(i, j - 1)
    else:
        return    

한 정점을 기준으로 사방(오른쪽, 왼쪽, 위쪽, 아래쪽)에 배추가 더 있는지 모두 탐색해야합니다. 배추가 더 있는 경우 탐색을 이어서 더 진행해야하기 때문에 재귀함수를 사용합니다.

📌 알고리즘 선택

한 정점과 인접한 가능한 모든 노드를 탐색해야 하므로 DFS를 사용하였습니다.

시간복잡도

for루프가 중첩되어있는 부분에서 전체 탐색에 대한 시간복잡도는 O(N*M)이며, 각 위치에 대한 DFS의 시간복잡도는 O(N*M)입니다. 따라서 전체 시간복잡도는 O(N*M)입니다. N, M의 최댓값은 50이므로 약 2500회의 연산이 수행됩니다. 이는 주어진 제한시간 1초 안에 충분히 가능한 연산입니다.

📌 코드 설계하기

1. T, M, N, K를 Input받고 배추가 심어져있는 위치는 K줄에 Input받습니다.
2. 입력받은 배추의 위치 좌표에 1을 대입하여 리스트값을 변경합니다.
3. 땅 위치의 처음부터 끝까지 탐색하며 정점의 갯수를 구합니다.

📌 시도회차 수정사항

1회차

테스트 케이스 개수를 고려하지 않았습니다.

2회차: 런타임 에러

런타임 에러란?

• 프로그램 실행 도중 비정상적으로 종료되는 것

  런타임 에러의 이유

  런타임 에러의 이유는 다양하지만.. 제가 작성한 코드에서의 런타임 에러 이유는 다음과 같습니다.

  • 백준 채점 시스템에서 최대 재귀 깊이를 디폴트 값으로 1000으로 정해놓았습니다.

• 런타임 에러는 그 최대 깊이를 초과하여 재귀 호출을 하기 때문에 발생하는 것입니다.

해결방법

import sys
sys.setrecursionlimit(10000)

위 코드를 사용하여 최대 재귀 깊이를 늘려주었습니다.

📌 정답 코드

import sys

sys.setrecursionlimit(10000)

def dfs(i, j): 
    visited[i][j] = True
    # 아래쪽 탐색
    if i + 1 < N and not visited[i + 1][j] and arr[i + 1][j] == 1:
        dfs(i + 1, j)
    # 위쪽 탐색
    if i - 1 >= 0 and not visited[i - 1][j] and arr[i - 1][j] == 1:
        dfs(i - 1, j)
    # 오른쪽 탐색
    if j + 1 < M and not visited[i][j + 1] and arr[i][j + 1] == 1:
        dfs(i, j + 1)
    # 왼쪽 탐색
    if j - 1 >= 0 and not visited[i][j - 1] and arr[i][j - 1] == 1:
        dfs(i, j - 1)
    else:
        return    

T = int(sys.stdin.readline())

for _ in range(T):
    M, N, K = map(int, sys.stdin.readline().split())
    arr = [[0] * M for _ in range(N)]  # 배추의 위치
    visited = [[False] * M for _ in range(N)]
    count = 0  # 정점의 갯수

    # 배추의 위치 입력
    for _ in range(K):
        X, Y = map(int, sys.stdin.readline().split())
        arr[Y][X] = 1

    # 모든 위치를 탐색하며 DFS 호출
    for i in range(N):
        for j in range(M):
            if not visited[i][j] and arr[i][j] == 1:
                count += 1
                dfs(i, j)     
    print(count)

📌 다른 풀이

아래 코드는 BFS를 활용한 코드입니다. (출처: @why_dev_says_no)

import sys

T = int(sys.stdin.readline())
dx = [-1, 1, 0, 0]
dy = [0, 0, -1, 1]


# 2. 한 노드에서 BFS를 탐색하는 과정을 구현합니다.
def bfs(x, y):
    queue = [(x, y)]
    global board
    board[x][y] = 0

    while queue:
        x, y = queue.pop()
        for i in range(4):
            nx = x + dx[i]
            ny = y + dy[i]

            if nx < 0 or nx >= M or ny < 0 or ny >= N:
                continue
            if board[nx][ny] == 1:
                board[nx][ny] = 0
                queue.append((nx, ny))


# 1. 문제의 input을 받습니다.
for _ in range(T):
    M, N, K = map(int, sys.stdin.readline().split())
    board = [[0 for _ in range(N)] for _ in range(M)]
    for _ in range(K):
        x, y = map(int, sys.stdin.readline().split())
        board[x][y] = 1

    ans = 0
    # 3. 문제의 배열에 대해 BFS 탐색을 진행하며 지렁이의 개수를 구합니다.
    for x in range(M):
        for y in range(N):
            if board[x][y] == 1:
                bfs(x, y)
                ans += 1
    print(ans)