블로그에서 읽기 : https://velog.io/@soonmac/hh-plus-ai-week7

## 외부 특강 - AI를 처음 시작했을 때 알았더라면 좋았을 것들

이번 주에는 외부 연사 특강이 있었다.
컴퓨터 비전 엔지니어 한서우 님께서 '문제 중심 사고(Problem First)를 통한 AI 기술의 실무 적용법'이라는 주제로 강연하셨다.

최근 많은 회사들이 서비스나 사내 툴에 AI를 도입하려고 하지만, AI라는 도구를 제대로 이해하고 적절히 활용하는 회사는 많지 않다고 생각한다.
이로 인해 문제 해결 수단인 AI가 주객전도 되어, AI가 불필요한 상황에서도 이를 도입하려는 경우가 종종 발생하기도 한다.

이번 특강은 엔지니어 입장에서 이러한 상황을 어떻게 인식하고 대처해야 하는지에 관한 내용이었다.
나도 어쩌다가 AI 프로젝트를 맡게 된 입장인데, 기술도 중요하지만 AI를 잘 모르는 사람들과의 소통이 가장 중요하다고 생각한다. 왜냐하면 실제로 답변의 경계를 명확히 정하거나 UI/UX 수정만으로도 AI를 도입하지 않고 해결할 수 있는 문제가 많기 때문이다. 이번 특강은 실무에서 많은 도움이 되는 내용이었다.

## 1. ai를 꼭 써야하는 문제인가?

기술은 수단 목적이 x
- 최신 기술 적용 자체를 목표로
- 비즈니스보다는 기술에

ai를 도입하기 전 체크 리스트
1. 문제의 본질은 무엇인가
2. 현상과 원인을 명확히 구분했는가
3. 현재 사용 중인 해결책이 있는가

성공 기준 설정 단계
- 성공의 기준이 무엇인가?
- 현실적인 목표와 기대치를 설정했는가?

대안 비교 단계
- ai외에 고려할 수 있는 다른 해결책 찾아보기
- 대안, 설명, 장점, 단점, 리소스 등을 정리하고 비교

✨좋은 개발자 = 비즈니스 관점에서 문제를 해결할 수 있는 개발자

❗ 2. 정확도만 높다고 좋은 모델은 아니다
정확도 != 서비스 성공 현실 데이터의 예외 상황을 고려해야함
정확도보다는 할루시네이션 방지하는 것이 서비스에서 젤 중요한 문제

## 3. 협업이 곧 실력이다
기술 문제와는 별개 사람 간의 소통이 중요하다

비개발자와 소통하기 좋게 기술적 언어를 풀어서 언어를 간소화해서 관점 이해시키기
- 결과 ,효과 위주로 말하기 목표 명확화
- 백그라운드 설명, 숫자
- 우리가 왜 이걸하는지 문제에 대해 얘기함

## 4. 사이드 프로젝트와 기술 리더십 이야기

내가 연구하고 싶은 주제가 있을 때 사이드 프로젝트 하는 것이 좋다.

CTO 경험에서 배운 점
- 조직 규모에 따라 기대하는 역할이 다르다
- 작은 규모에서는 기술 문화 확립
- 내가 빨리 성장하고 싶으면 다른 도메인의 사람들과 협업을 하라

주니어 개발자에게 하고 싶은 말
- 회사가 알아주길 기다리지 말고, 내 목표와 원하는 경험을 명확히 표현하라
- 문제에 해결하는 능력에 집중
- 회사가 풀고싶어하는 문제가 무엇이고, 그걸 어떻게 해결해야할까. 기술이 언제나 답은 아니다
- 실패를 두려워하지 말고 우선 행동하기
- 요즘 취업시장이 힘든데 나는 그냥 인사팀 메일로 이력서를 보냈다. 적극적으로 접근해보길

### 사전질문

Q. 아직 AI가 완전히 대체할 수 없는 분야가 있을까요?
휴먼 터치가 필요한 곳
- 감정적 맥락과 공감이 중요한 커뮤니케이션
- 갈등 중재, 불만 응대, 민감한 상대(병원, 정신 케어 등) 윤리적 판단이 필요한 곳
- 공정성과 맥락 사후책임까지 고려해야할 때
창의적 통찰이 필요한 전략 수립, 데이터가 부족한 신제품, 신분야

Q. ai를 빠르게 접하고 적용하고 싶은사람에게 적합한 이직처
ai를 실험하고 주도적으로 적용할 수 잇는 회사가 좋다. 즉 ai 프로덕트를 판매하는 회사네
모든 회사가 ai 쓰려고 하는데 ai를 실험적으로 쓰려고 하는건지 진짜 진지하게 하는건지 확인이 필요함
면접 때 ai를 도입한 이유, 프로덕트의 미래에 대해 확인이 필요하다.
데이터 기반 전환이 빠른 산업 유통/물류 자동화 헬스케어 제조 공정 최적화 미디어, 콘텐츠 분야가 AI를 도입하기 좋은 도메인이다.

🎠 ## 개인 프로젝트 근황

저번주 회고 때도 썼지만 원래는 PDF 기반 QnA 봇을 만드려다가 과제 제출 때문에 급하게 이미지 분석 챗봇을 만들었었다.

그래서 이참에 이미지 분석 챗봇으로 주제를 바꿀까 고민을 했었는데 아래와 같은 고민들이 있었다.
1. 기능 구현에 시간이 오래걸린다. (이미지 분석 + 답변 생성 + 패션 관련 데이터 수집)
2. 내가 확실히 가져가고 싶은 것 = RAG, Langchain, 파인튜닝하는 법 에 집중하고 싶음
3. 바로 실무에 AI를 적용해야하는 상황
=> 좀 늦었지만 이러한 것들을 빠르고 확실하게 배워갈 수 있는 PDF QnA 챗봇을 만들기로 했다

다행히 PDF 기반 챗봇은 많은 사람들이 한 번 씩은 만들어보는 주제라서 깃헙에서 자료를 쉽게 구할 수 있었다.

### ConversationalRetrievalChain

https://github.com/HarryKane11/langchain/blob/main/streamlit_refer.py
이 분의 코드를 참고했다.

1.
ConversationalRetrievalChain
를 사용해서 대화 기록을 참조
2. 벡터 스토어에서 긁어온 원본 문서를 포함

### 멀티쿼리 검색기, 앙상블 검색기

음 기존의 gpt-4o-mini가 어느정도 성능이 보장되어 있어서 그냥
as_retriever
을 사용해도 대체로 잘 작동한다.
하지만 종종 한정된 답변을 하거나 쓸모 없는 정보들도 끌고 오는 경우가 있었는데, 이를 검색 기법을 통해 개선해봤다.

https://youtu.be/J2AsmUODBak?si=l4cnrkVIrYuPuZfK
https://youtu.be/ehP4vphl_Us?si=EGSETEKzGPCsrd3j
실전! RAG 고급 기법 - Retriever (1),(2)
모두의AI님의 영상들을 참고했다.

🦜멀티 쿼리 검색기
* 사용자의 질문을 다양한 유사 질문으로 재생성하여 좀 더 문맥을 잘 이해한 답변을 제공한다.
* 예시로 추상적인 질문에 대한 한정적인 답변을 피하기 위해, llm을 통해 다양한 관점에서 해석하게끔 한다.

🦜앙상블 검색기
* 여러 검색기를 합쳐서 쓰는 검색기이다.
* Sparse 검색기와 Dense 검색기를 조합하는 것이 국룰이다.
* Sparse 검색기는 문서마다 갖고 있는 단어의 출연 빈도를 통해 단어가 많이 겹치는 문서를 가져온다.
* 빠르고 간편하지만, 같은 의미를 가진 다른 단어는 제대로 처리하지 못하는 단점이 있다.
* Dense 검색기는 반대로 맥락을 고려해서 이음 동의어도 처리할 수 있다.
* 그러나 사용자의 의도와는 조금 맞지 않는 문서들을 끌고 올 수 있다.
* 앙상블 검색기는 키워드 기반과 맥락 기반의 검색 결과를 결합한 후, 재정렬해서 사용자에게 보다 더 적합한 정보를 제공한다.

나는 앙상블 검색기에 Sparse, Dense, 멀티 쿼리 이 3가지 검색기를 혼합해서 사용했다!
아래는 내가 작성한 코드다

# 스파스 검색기

def get_sparse_retriever(text_chunks):

    return BM25Retriever.from_documents(

        text_chunks,

    )

# 덴스 검색기는 as_retriever()을 쓰기로 했다.

# 멀티 쿼리 검색기

def get_multiquery_retriever(vectorestore, model):

    llm = ChatOpenAI(model=model, api_key=st.secrets["OPENAI_KEY"], temperature=0)

    ### 서치 타입을 mmr로 해서 답변의 다양성을 중시하도록 했다.

    retriever = vectorestore.as_retriever(search_type="mmr")

    multiquery_retriever = MultiQueryRetriever.from_llm(

        retriever=retriever,

        llm=llm,

    )

    return multiquery_retriever

# 앙상블 검색기 

def get_ensemble_retriever(sparse, dense, multi):

    return EnsembleRetriever(

        retrievers=[sparse, dense, multi],

        weights=[0.5, 0.3, 0.2],

    )

그리고
get_ensemble_retriever
로 생성한 앙상블 검색기를 AI 요청할 때 retriever 파라미터 값에 넣어주면 된다.

🦜결과 확인! (with 랭스미스)
LangSmith를 쓰면 랭체인으로 구성된 AI 요청 파이프라인을 쉽게 추적할 수 있다.
(이건 블로그 내용을 확인해주세요)

최종 출력값
```
딥시크(DeepSeek)는 중국의 스타트업으로, AI 모델인 DeepSeek-R1을 개발하여 주목받고 있습니다. 이 모델은 오픈소스 기반으로, AI 독립성을 강화하고 있으며, 특정 작업에서 오픈AI의 GPT-4와 경쟁할 수 있는 성능을 보이고 있습니다. 그러나 개인정보 보호와 보안 문제로 인해 국제적으로 사용이 제한되고 있습니다.
| 주요 내용 | 설명 |
|-----------|------|
| 회사명 | 딥시크(DeepSeek) |
| 모델 | DeepSeek-R1 |
| 특징 | 오픈소스 기반, AI 독립성 강화 |
| 성능 | GPT-4와 경쟁 가능 |
| 우려사항 | 개인정보 보호, 보안 문제 |
| 국제적 반응 | 사용 제한 조치 확대 |
딥시크는 2025년 1월 20일에 DeepSeek-R1 모델을 출시하며 AI 산업에서 중요한 역할을 하고 있습니다. 이 모델은 강화학습과 전문가 혼합(MoE) 기술을 활용하여 효율성을 극대화하고 있으며, 벤치마킹 결과에서 오픈AI의 GPT-4와 유사한 성능을 기록했습니다. 그러나 중국의 사이버 보안법에 따라 데이터 처리 방식에 대한 우려가 있으며, 여러 국가에서 개인정보 보호 문제로 인해 딥시크의 사용을 제한하는 조치가 취해지고 있습니다.
```
최대한의 관련 문서들을 잘 끌어내는 것들을 확인할 수 있다.
그러나 개선해야할 점 :
1. 멀티 쿼리 검색기에서 레이턴시가 좀 길다.
3.71초 정도인데, 솔직히 가장 중요한 핵심 정보는 sparse, dense에서 다 가져오기 때문에.. 꼭 질문을 3가지를 더 가져올 필요는 없어보인다.
암튼 어떻게 RAG를 개선해나가야할 지는, 해당 답변의 성능을 평가해봐야하는데
이것은 다음주에 하도록 하겠다.
### 프로젝트 앞으로 해야할 것!
1. Open LLM 경량화해서 파인튜닝하기
1. 어떤 데이터셋을 준비해야할까 고민하기
1. 벡터 스토어에 있는 청크들을 기반으로 OpenAI를 통해 데이터셋을 만들려고 생각중
2. LangSmith로 평가 플로우 만들기

------
항해 플러스에서 현재 백엔드, 프론트엔드 코스 수강생을 모집 중입니다!
추천 코드를 입력하시면 등록금 20만원을 할인받을 수 있어요. (커리어 코칭 제외)
관심 있으신 분들은 아래 링크에서 확인해보세요
추천 코드: 9T8Rkv
https://hanghae99.spartacodingclub.kr/hhplus-hub

#항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM #RAG #Langchain #streamlit #파인튜닝

블로그에서 읽기 : https://velog.io/@soonmac/hh-plus-ai-week7 ## 외부 특강 - AI를 처음 시작했을 때 알았더라면 좋았을 것들 이번 주에는 외부 연사 특강이 있었다.컴퓨터 비전 엔지니어 한서우 님께서 '문제 중심 사고(Problem First)를 통한 AI 기술의 실무 적용법'이라는 주제로 강연하셨다. 최근 많은 회사들이 서비스나 사내 툴에 AI를 도입하려고 하지만, AI라는 도구를 제대로 이해하고 적절히 활용하는 회사는 많지 않다고 생각한다.이로 인해 문제 해결 수단인 AI가 주객전도 되어, AI가 불필요한 상황에서도 이를 도입하려는 경우가 종종 발생하기도 한다. 이번 특강은 엔지니어 입장에서 이러한 상황을 어떻게 인식하고 대처해야 하는지에 관한 내용이었다.나도 어쩌다가 AI 프로젝트를 맡게 된 입장인데, 기술도 중요하지만 AI를 잘 모르는 사람들과의 소통이 가장 중요하다고 생각한다. 왜냐하면 실제로 답변의 경계를 명확히 정하거나 UI/UX 수정만으로도 AI를 도입하지 않고 해결할 수 있는 문제가 많기 때문이다. 이번 특강은 실무에서 많은 도움이 되는 내용이었다. ## 1. ai를 꼭 써야하는 문제인가? 기술은 수단 목적이 x- 최신 기술 적용 자체를 목표로- 비즈니스보다는 기술에 ai를 도입하기 전 체크 리스트1. 문제의 본질은 무엇인가2. 현상과 원인을 명확히 구분했는가3. 현재 사용 중인 해결책이 있는가 성공 기준 설정 단계- 성공의 기준이 무엇인가?- 현실적인 목표와 기대치를 설정했는가? 대안 비교 단계- ai외에 고려할 수 있는 다른 해결책 찾아보기- 대안, 설명, 장점, 단점, 리소스 등을 정리하고 비교 ✨좋은 개발자 = 비즈니스 관점에서 문제를 해결할 수 있는 개발자 ❗ 2. 정확도만 높다고 좋은 모델은 아니다정확도 != 서비스 성공 현실 데이터의 예외 상황을 고려해야함정확도보다는 할루시네이션 방지하는 것이 서비스에서 젤 중요한 문제 ## 3. 협업이 곧 실력이다기술 문제와는 별개 사람 간의 소통이 중요하다 비개발자와 소통하기 좋게 기술적 언어를 풀어서 언어를 간소화해서 관점 이해시키기- 결과 ,효과 위주로 말하기 목표 명확화- 백그라운드 설명, 숫자- 우리가 왜 이걸하는지 문제에 대해 얘기함 ## 4. 사이드 프로젝트와 기술 리더십 이야기 내가 연구하고 싶은 주제가 있을 때 사이드 프로젝트 하는 것이 좋다. CTO 경험에서 배운 점- 조직 규모에 따라 기대하는 역할이 다르다- 작은 규모에서는 기술 문화 확립- 내가 빨리 성장하고 싶으면 다른 도메인의 사람들과 협업을 하라 주니어 개발자에게 하고 싶은 말- 회사가 알아주길 기다리지 말고, 내 목표와 원하는 경험을 명확히 표현하라- 문제에 해결하는 능력에 집중- 회사가 풀고싶어하는 문제가 무엇이고, 그걸 어떻게 해결해야할까. 기술이 언제나 답은 아니다- 실패를 두려워하지 말고 우선 행동하기- 요즘 취업시장이 힘든데 나는 그냥 인사팀 메일로 이력서를 보냈다. 적극적으로 접근해보길 ### 사전질문 Q. 아직 AI가 완전히 대체할 수 없는 분야가 있을까요?휴먼 터치가 필요한 곳- 감정적 맥락과 공감이 중요한 커뮤니케이션- 갈등 중재, 불만 응대, 민감한 상대(병원, 정신 케어 등) 윤리적 판단이 필요한 곳- 공정성과 맥락 사후책임까지 고려해야할 때창의적 통찰이 필요한 전략 수립, 데이터가 부족한 신제품, 신분야 Q. ai를 빠르게 접하고 적용하고 싶은사람에게 적합한 이직처ai를 실험하고 주도적으로 적용할 수 잇는 회사가 좋다. 즉 ai 프로덕트를 판매하는 회사네모든 회사가 ai 쓰려고 하는데 ai를 실험적으로 쓰려고 하는건지 진짜 진지하게 하는건지 확인이 필요함면접 때 ai를 도입한 이유, 프로덕트의 미래에 대해 확인이 필요하다.데이터 기반 전환이 빠른 산업 유통/물류 자동화 헬스케어 제조 공정 최적화 미디어, 콘텐츠 분야가 AI를 도입하기 좋은 도메인이다. 🎠 ## 개인 프로젝트 근황 저번주 회고 때도 썼지만 원래는 PDF 기반 QnA 봇을 만드려다가 과제 제출 때문에 급하게 이미지 분석 챗봇을 만들었었다. 그래서 이참에 이미지 분석 챗봇으로 주제를 바꿀까 고민을 했었는데 아래와 같은 고민들이 있었다.1. 기능 구현에 시간이 오래걸린다. (이미지 분석 + 답변 생성 + 패션 관련 데이터 수집)2. 내가 확실히 가져가고 싶은 것 = RAG, Langchain, 파인튜닝하는 법 에 집중하고 싶음3. 바로 실무에 AI를 적용해야하는 상황=&gt; 좀 늦었지만 이러한 것들을 빠르고 확실하게 배워갈 수 있는 PDF QnA 챗봇을 만들기로 했다 다행히 PDF 기반 챗봇은 많은 사람들이 한 번 씩은 만들어보는 주제라서 깃헙에서 자료를 쉽게 구할 수 있었다. ### ConversationalRetrievalChain https://github.com/HarryKane11/langchain/blob/main/streamlit_refer.py이 분의 코드를 참고했다. 1. <code >ConversationalRetrievalChain</code> 를 사용해서 대화 기록을 참조2. 벡터 스토어에서 긁어온 원본 문서를 포함 ### 멀티쿼리 검색기, 앙상블 검색기 음 기존의 gpt-4o-mini가 어느정도 성능이 보장되어 있어서 그냥 <code >as_retriever</code> 을 사용해도 대체로 잘 작동한다.하지만 종종 한정된 답변을 하거나 쓸모 없는 정보들도 끌고 오는 경우가 있었는데, 이를 검색 기법을 통해 개선해봤다. https://youtu.be/J2AsmUODBak?si=l4cnrkVIrYuPuZfKhttps://youtu.be/ehP4vphl_Us?si=EGSETEKzGPCsrd3j실전! RAG 고급 기법 - Retriever (1),(2)모두의AI님의 영상들을 참고했다. 🦜멀티 쿼리 검색기* 사용자의 질문을 다양한 유사 질문으로 재생성하여 좀 더 문맥을 잘 이해한 답변을 제공한다.* 예시로 추상적인 질문에 대한 한정적인 답변을 피하기 위해, llm을 통해 다양한 관점에서 해석하게끔 한다. 🦜앙상블 검색기* 여러 검색기를 합쳐서 쓰는 검색기이다.* Sparse 검색기와 Dense 검색기를 조합하는 것이 국룰이다.* Sparse 검색기는 문서마다 갖고 있는 단어의 출연 빈도를 통해 단어가 많이 겹치는 문서를 가져온다.* 빠르고 간편하지만, 같은 의미를 가진 다른 단어는 제대로 처리하지 못하는 단점이 있다.* Dense 검색기는 반대로 맥락을 고려해서 이음 동의어도 처리할 수 있다.* 그러나 사용자의 의도와는 조금 맞지 않는 문서들을 끌고 올 수 있다.* 앙상블 검색기는 키워드 기반과 맥락 기반의 검색 결과를 결합한 후, 재정렬해서 사용자에게 보다 더 적합한 정보를 제공한다. 나는 앙상블 검색기에 Sparse, Dense, 멀티 쿼리 이 3가지 검색기를 혼합해서 사용했다!아래는 내가 작성한 코드다 <pre ><code># 스파스 검색기

def get_sparse_retriever(text_chunks):

 return BM25Retriever.from_documents(

 text_chunks,

 )

# 덴스 검색기는 as_retriever()을 쓰기로 했다.

# 멀티 쿼리 검색기

def get_multiquery_retriever(vectorestore, model):

 llm = ChatOpenAI(model=model, api_key=st.secrets["OPENAI_KEY"], temperature=0)

 ### 서치 타입을 mmr로 해서 답변의 다양성을 중시하도록 했다.

 retriever = vectorestore.as_retriever(search_type="mmr")

 multiquery_retriever = MultiQueryRetriever.from_llm(

 retriever=retriever,

 llm=llm,

 )

 return multiquery_retriever

# 앙상블 검색기 

def get_ensemble_retriever(sparse, dense, multi):

 return EnsembleRetriever(

 retrievers=[sparse, dense, multi],

 weights=[0.5, 0.3, 0.2],

 )</code></pre> 그리고 <code >get_ensemble_retriever</code> 로 생성한 앙상블 검색기를 AI 요청할 때 retriever 파라미터 값에 넣어주면 된다. 🦜결과 확인! (with 랭스미스)LangSmith를 쓰면 랭체인으로 구성된 AI 요청 파이프라인을 쉽게 추적할 수 있다.(이건 블로그 내용을 확인해주세요) 최종 출력값```딥시크(DeepSeek)는 중국의 스타트업으로, AI 모델인 DeepSeek-R1을 개발하여 주목받고 있습니다. 이 모델은 오픈소스 기반으로, AI 독립성을 강화하고 있으며, 특정 작업에서 오픈AI의 GPT-4와 경쟁할 수 있는 성능을 보이고 있습니다. 그러나 개인정보 보호와 보안 문제로 인해 국제적으로 사용이 제한되고 있습니다.| 주요 내용 | 설명 ||-----------|------|| 회사명 | 딥시크(DeepSeek) || 모델 | DeepSeek-R1 || 특징 | 오픈소스 기반, AI 독립성 강화 || 성능 | GPT-4와 경쟁 가능 || 우려사항 | 개인정보 보호, 보안 문제 || 국제적 반응 | 사용 제한 조치 확대 |딥시크는 2025년 1월 20일에 DeepSeek-R1 모델을 출시하며 AI 산업에서 중요한 역할을 하고 있습니다. 이 모델은 강화학습과 전문가 혼합(MoE) 기술을 활용하여 효율성을 극대화하고 있으며, 벤치마킹 결과에서 오픈AI의 GPT-4와 유사한 성능을 기록했습니다. 그러나 중국의 사이버 보안법에 따라 데이터 처리 방식에 대한 우려가 있으며, 여러 국가에서 개인정보 보호 문제로 인해 딥시크의 사용을 제한하는 조치가 취해지고 있습니다.```최대한의 관련 문서들을 잘 끌어내는 것들을 확인할 수 있다.그러나 개선해야할 점 :1. 멀티 쿼리 검색기에서 레이턴시가 좀 길다.3.71초 정도인데, 솔직히 가장 중요한 핵심 정보는 sparse, dense에서 다 가져오기 때문에.. 꼭 질문을 3가지를 더 가져올 필요는 없어보인다.암튼 어떻게 RAG를 개선해나가야할 지는, 해당 답변의 성능을 평가해봐야하는데이것은 다음주에 하도록 하겠다.### 프로젝트 앞으로 해야할 것!1. Open LLM 경량화해서 파인튜닝하기1. 어떤 데이터셋을 준비해야할까 고민하기1. 벡터 스토어에 있는 청크들을 기반으로 OpenAI를 통해 데이터셋을 만들려고 생각중2. LangSmith로 평가 플로우 만들기 ------항해 플러스에서 현재 백엔드, 프론트엔드 코스 수강생을 모집 중입니다!추천 코드를 입력하시면 등록금 20만원을 할인받을 수 있어요. (커리어 코칭 제외)관심 있으신 분들은 아래 링크에서 확인해보세요추천 코드: 9T8Rkvhttps://hanghae99.spartacodingclub.kr/hhplus-hub #항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM #RAG #Langchain #streamlit #파인튜닝

항해플러스 AI 후기(7주차) - AI 실무 적용법, RAG 개선하기

﻿
이번 딱 한 번만 눈 감고 모른척하자는 생각과 단 한 번도 허락하지 않고 이번에도 기준 따라 행동하는 것 사이에 매일 갈등이 일어납니다. ‘한 번만’ 하자는 생각은 편리합니다. 눈에 보이는 쉬운 길로 요리조리 장애물을 피해 갈 수 있기 때문입니다. 장애물은 정도를 걸으면 만나는 예상되는 어려움이고, 쉬운 길은 정도를 어긋나는 지름길로 기준이 없고 타협만 존재합니다.

‘한 번도’ 허락할 수 없다는 대쪽같은 생각은 상대적으로 피곤합니다. 지켜야 할 기준을 떠올려 예상되는 피곤한 과정을 거쳐야 하기 때문입니다. 시간과 노력을 사용하여 장애물을 넘고, 달려야 겨우 도달할 수 있는 과정과 목표입니다. 기준을 지켰을 때 누릴 수 있는 건 겨우 뿌듯함 정도일 것입니다. 그래서 ‘한 번도’ 허락할 수 없다는 삶은 손가락질 받습니다.

‘뭘 그렇게 뻣뻣하게 굴어. 이 번 한 번만 그냥 대충 쉬운 길로 가자고’ 우리들의 일상엔 ‘한 번만’ 이렇게 하자는 생각이 팽배합니다. 굳이 쉬운 길을 놔두고 어려움이 예상되는 바보 같은 선택을 하지 말자는 것입니다. 많은 사람들이 그렇게 생각하고 말하니 연약한 우리고 다수 의견에 휩쓸리기 십상입니다. 그렇게 한두 번 사람들 생각 따라 살다가 보면 기준 없이 쉬운 길만 찾게 됩니다. 

정도를 지키며 사는 일은 쉽지 않습니다. 외롭고 고된 삶을 선택하는 것입니다. 주변 사람들의 따가운 시선을 받으며 기준을 고집하는 일이 과연 옳은 것인가 자신의 내면과 끊임없이 싸워야 합니다. 정도를 지킨다고 누가 상을 주는 것도 아니고, 하늘에서 대단한 축복이 떨어지는 것도 아닙니다. 그저 오늘도 기준을 지키며 살았노라 평범한 일상에 안도하며 감사하는 것이 전부일 수 있습니다.

문제는 ‘한 번만’ 기준을 무시하고 편리한 길을 선택하는 인생은 무엇이 중요하고 옳은 것인지 모르고 살게 된다는 것입니다. 빨간 신호를 봐도 무시하고 지금 가고 싶은 길을 가게 됩니다. 가지 말아야 할 길인데 편리해 보이고, 빨리 갈 수 있는 지름길 같지만 그 길 끝에 무엇이 기다리고 있을지 모릅니다. 높은 확률로 기대보다 덜 좋은 것을 만나게 된다고 생각합니다.

반면, ‘한 번도’ 기준을 벗어난 선택을 하지 않는 인생은 흔들림이 없습니다. 어디로 가야 하는지 무엇을 선택해야 하는지 명확하기 때문입니다. 바람이 불고 폭우가 쏟아져도 흔들리지 않습니다. 자리를 지키고 있으면 이 또한 지나가리라는 것을 알고 있기 때문입니다. 지금의 고난이 영원할 것 같지만, 순간이라는 것을 알기에 쉬운 길을 선택하지 않고, 해야 할 일을 찾아서 묵묵하게 나아갑니다.

‘한 번만’ 부당한 이익을 취하는 삶에 진짜 이득은 없습니다. 현실과 타협하는 사람에게 돌아오는 것은 적당한 이익입니다. 더 많아 보이고 좋아 보이지만 막상 손에 남는 건 별 볼일 없는 것뿐입니다. 그래도 원래 사는 게 그런 거라며 스스로 위로합니다. ‘한 번만’ 대충 살자고 생각하는 사람들끼리 동병상련의 마음으로 위로하는 척, 서로의 옳지 않음을 눈감아 줍니다.

‘한 번도’ 대충 일하지 않는 삶에 진짜 이득은 깨끗한 마음입니다. 주변 사람들에게 인정받지 못하고, 큰 상이 주어지지 않는다고 해도 모두 알고 있습니다. ‘한 번도’ 벗어나지 않는 모습이 얼마나 대단하고 아름다운지 말로 표현하지 않아도 사실 모두가 잘 알고 있고 훌륭하다고 생각합니다. ‘한 번도’ 기준을 벗어나지 않는다고 해서 좋은 일만 생기는 것은 아니지만, 그 삶에 불안함은 없습니다. 어지러운 마음을 가진 친구들이 많은 것보다 혼자 평온함을 유지하는 것이 훨씬 좋습니다.

오늘도 우리는 수많은 선택의 기로에 놓입니다. 갈 것인가, 말 것인가, 할 것인가, 말 것인가, 무수한 경로 앞에서 고민하고 갈등합니다. 다만, 어디로 가는 것이 옳은 길인지 마음은 알고 있습니다. 그 마음 따라 선택하는 우리가 되길 진심으로 응원합니다. 더 좋아 보이는 길이나 더 편해 보이는 길 말고, 우리가 오늘 가야 할 길을 갑시다. 더 많은 것을 얻을 수 있을 것 같은 일 말고, 더 재미있어 보이는 일 말고, 우리가 해야 할 일을 합시다. 옳은 선택이 쌓이면 반드시 그에 합당한 결과를 내는 사람이 된다고 믿습니다.

﻿이번 딱 한 번만 눈 감고 모른척하자는 생각과 단 한 번도 허락하지 않고 이번에도 기준 따라 행동하는 것 사이에 매일 갈등이 일어납니다. ‘한 번만’ 하자는 생각은 편리합니다. 눈에 보이는 쉬운 길로 요리조리 장애물을 피해 갈 수 있기 때문입니다. 장애물은 정도를 걸으면 만나는 예상되는 어려움이고, 쉬운 길은 정도를 어긋나는 지름길로 기준이 없고 타협만 존재합니다. ‘한 번도’ 허락할 수 없다는 대쪽같은 생각은 상대적으로 피곤합니다. 지켜야 할 기준을 떠올려 예상되는 피곤한 과정을 거쳐야 하기 때문입니다. 시간과 노력을 사용하여 장애물을 넘고, 달려야 겨우 도달할 수 있는 과정과 목표입니다. 기준을 지켰을 때 누릴 수 있는 건 겨우 뿌듯함 정도일 것입니다. 그래서 ‘한 번도’ 허락할 수 없다는 삶은 손가락질 받습니다. ‘뭘 그렇게 뻣뻣하게 굴어. 이 번 한 번만 그냥 대충 쉬운 길로 가자고’ 우리들의 일상엔 ‘한 번만’ 이렇게 하자는 생각이 팽배합니다. 굳이 쉬운 길을 놔두고 어려움이 예상되는 바보 같은 선택을 하지 말자는 것입니다. 많은 사람들이 그렇게 생각하고 말하니 연약한 우리고 다수 의견에 휩쓸리기 십상입니다. 그렇게 한두 번 사람들 생각 따라 살다가 보면 기준 없이 쉬운 길만 찾게 됩니다.&nbsp; 정도를 지키며 사는 일은 쉽지 않습니다. 외롭고 고된 삶을 선택하는 것입니다. 주변 사람들의 따가운 시선을 받으며 기준을 고집하는 일이 과연 옳은 것인가 자신의 내면과 끊임없이 싸워야 합니다. 정도를 지킨다고 누가 상을 주는 것도 아니고, 하늘에서 대단한 축복이 떨어지는 것도 아닙니다. 그저 오늘도 기준을 지키며 살았노라 평범한 일상에 안도하며 감사하는 것이 전부일 수 있습니다. 문제는 ‘한 번만’ 기준을 무시하고 편리한 길을 선택하는 인생은 무엇이 중요하고 옳은 것인지 모르고 살게 된다는 것입니다. 빨간 신호를 봐도 무시하고 지금 가고 싶은 길을 가게 됩니다. 가지 말아야 할 길인데 편리해 보이고, 빨리 갈 수 있는 지름길 같지만 그 길 끝에 무엇이 기다리고 있을지 모릅니다. 높은 확률로 기대보다 덜 좋은 것을 만나게 된다고 생각합니다. 반면, ‘한 번도’ 기준을 벗어난 선택을 하지 않는 인생은 흔들림이 없습니다. 어디로 가야 하는지 무엇을 선택해야 하는지 명확하기 때문입니다. 바람이 불고 폭우가 쏟아져도 흔들리지 않습니다. 자리를 지키고 있으면 이 또한 지나가리라는 것을 알고 있기 때문입니다. 지금의 고난이 영원할 것 같지만, 순간이라는 것을 알기에 쉬운 길을 선택하지 않고, 해야 할 일을 찾아서 묵묵하게 나아갑니다. ‘한 번만’ 부당한 이익을 취하는 삶에 진짜 이득은 없습니다. 현실과 타협하는 사람에게 돌아오는 것은 적당한 이익입니다. 더 많아 보이고 좋아 보이지만 막상 손에 남는 건 별 볼일 없는 것뿐입니다. 그래도 원래 사는 게 그런 거라며 스스로 위로합니다. ‘한 번만’ 대충 살자고 생각하는 사람들끼리 동병상련의 마음으로 위로하는 척, 서로의 옳지 않음을 눈감아 줍니다. ‘한 번도’ 대충 일하지 않는 삶에 진짜 이득은 깨끗한 마음입니다. 주변 사람들에게 인정받지 못하고, 큰 상이 주어지지 않는다고 해도 모두 알고 있습니다. ‘한 번도’ 벗어나지 않는 모습이 얼마나 대단하고 아름다운지 말로 표현하지 않아도 사실 모두가 잘 알고 있고 훌륭하다고 생각합니다. ‘한 번도’ 기준을 벗어나지 않는다고 해서 좋은 일만 생기는 것은 아니지만, 그 삶에 불안함은 없습니다. 어지러운 마음을 가진 친구들이 많은 것보다 혼자 평온함을 유지하는 것이 훨씬 좋습니다. 오늘도 우리는 수많은 선택의 기로에 놓입니다. 갈 것인가, 말 것인가, 할 것인가, 말 것인가, 무수한 경로 앞에서 고민하고 갈등합니다. 다만, 어디로 가는 것이 옳은 길인지 마음은 알고 있습니다. 그 마음 따라 선택하는 우리가 되길 진심으로 응원합니다. 더 좋아 보이는 길이나 더 편해 보이는 길 말고, 우리가 오늘 가야 할 길을 갑시다. 더 많은 것을 얻을 수 있을 것 같은 일 말고, 더 재미있어 보이는 일 말고, 우리가 해야 할 일을 합시다. 옳은 선택이 쌓이면 반드시 그에 합당한 결과를 내는 사람이 된다고 믿습니다.﻿

한 번만 vs 한 번도

ChatGPT 사용할 때 어떤 모델을 선택해야할지 망설여집니다. 모델명만 봐서는 어떤게 좋은지 모르겠더라고요.

그래서 ChatGPT에게 설명을 부탁해봤습니다.

🧠 GPT-3.5 (2022)
→ 중학생처럼 똑똑한 AI. 질문 잘하지만 가끔 헷갈림.

🎓 GPT-4 (2023)
→ 고등학생 수준의 AI. 더 정확하고 추론도 잘함.

⚡ GPT-4-turbo (2023 말~)
→ GPT-4보다 빠르고 저렴한 버전. 급식 줄 안 서는 느낌!

🧑‍🎓 GPT-4.5 (비공식 명칭)
→ GPT-4랑 5 사이. 중3.5학년 느낌의 중간단계 모델.

🧞 GPT-4o = o4 (2024)
→ ‘omni’ = 만능! 글, 이미지, 음성까지 다 되는 AI 친구.

🧪 o3
→ GPT-4o의 시험판. 모의고사 버전 느낌.

🎯 o4-mini
→ GPT-4o보다 작고 빠른 축소형. 시험 족보 외우는 친구 느낌.

ChatGPT 사용할 때 어떤 모델을 선택해야할지 망설여집니다. 모델명만 봐서는 어떤게 좋은지 모르겠더라고요. 그래서 ChatGPT에게 설명을 부탁해봤습니다. 🧠 GPT-3.5 (2022)→ 중학생처럼 똑똑한 AI. 질문 잘하지만 가끔 헷갈림. 🎓 GPT-4 (2023)→ 고등학생 수준의 AI. 더 정확하고 추론도 잘함. ⚡ GPT-4-turbo (2023 말~)→ GPT-4보다 빠르고 저렴한 버전. 급식 줄 안 서는 느낌! 🧑‍🎓 GPT-4.5 (비공식 명칭)→ GPT-4랑 5 사이. 중3.5학년 느낌의 중간단계 모델. 🧞 GPT-4o = o4 (2024)→ ‘omni’ = 만능! 글, 이미지, 음성까지 다 되는 AI 친구. 🧪 o3→ GPT-4o의 시험판. 모의고사 버전 느낌. 🎯 o4-mini→ GPT-4o보다 작고 빠른 축소형. 시험 족보 외우는 친구 느낌.

ChatGPT 버전명 설명

현재 진행 중인 리트코드 스터디 4기와 디자인 시스템 프로젝트의 진행 상황을 공유하고, 앞으로 시작될 새로운 스터디와 프로젝트에 대해서 함께 이야기 나누는 시간을 가지려 합니다.

🎉 Trivia 퀴즈 시간과 🎁 "헬로 Bun" 도서 증정 이벤트도 준비되어 있으니, 소프트웨어 개발과 그룹 스터디, 해외 취업, 오픈소스 프로젝트에 관심 있으신 분들의 많은 참여 부탁드립니다! 😁

- 날짜: 2025년 5월 18일 일요일
- 시간: 저녁 9시-10:30
- 장소: 달레 스터디 디스코드 "스테이지" 채널 (https://dales.link/discord)

참가를 원하시는 분들은 "공지사항" 채널에 들어오셔서 밋업 쓰레드에 ✅ 이모지를 달아주세요. (참가비 무료)

현재 진행 중인 리트코드 스터디 4기와 디자인 시스템 프로젝트의 진행 상황을 공유하고, 앞으로 시작될 새로운 스터디와 프로젝트에 대해서 함께 이야기 나누는 시간을 가지려 합니다. 🎉 Trivia 퀴즈 시간과 🎁 "헬로 Bun" 도서 증정 이벤트도 준비되어 있으니, 소프트웨어 개발과 그룹 스터디, 해외 취업, 오픈소스 프로젝트에 관심 있으신 분들의 많은 참여 부탁드립니다! 😁 - 날짜: 2025년 5월 18일 일요일- 시간: 저녁 9시-10:30- 장소: 달레 스터디 디스코드 "스테이지" 채널 (https://dales.link/discord) 참가를 원하시는 분들은 "공지사항" 채널에 들어오셔서 밋업 쓰레드에 ✅ 이모지를 달아주세요. (참가비 무료)

달레 스터디 온라인 밋업에 여러분을 초대합니다

블로그에서 읽기 : https://velog.io/@soonmac/hh-plus-ai-week6

이번 6주차는 5월 3일 휴강을 하게 되면서 2주로 연장되었다ㅎㅎ 오예~
연휴동안 쉬면서 프로젝트를 진행해보려고 했는데 하하 연휴 때 방송대 수업이나 여행으로 너무 바쁘게 움직여서 생각보다 많이 공부를 하지 못했다 흑흑...

6주차 발제 내용은 크게 3가지를 다뤘다.
1. Langchain과 Streamlit으로 챗봇 구현하기
2. LLM 챗봇 서빙하기
3. 멀티 모달 및 RAG를 LLM 챗봇에서 활용하기

거의 실습 코드 위주로 진행됐고, 이번 주부터 본격적으로 프로젝트 작업에 들어가는 거라서 발제 내용은 따로 정리하지 않을 것이다.

오픈소스로 풀린 LLM을 사용하기 위해 AWS 클라우드 환경을 미리 세팅해두었는데, 학습용 인스턴스 생성은 AWS 할당량 증가를 요청 해야 해서 하루 이틀 정도 걸린다.
다행히 발제 전에 세팅 튜토리얼이 올라오니까 인프라 모르는 사람들도 크게 걱정할 필요는 없을 것 같다.

## 🍀기본 과제 회고: 이미지를 가지고 질의응답을 하는 챗봇 구현

데모 앱 보러가기
https://app-chatbot-gkqvxwqzjxqytmb8e8e9dp.streamlit.app/

코드 보기
https://github.com/sosososoyoen/streamlit-chatbot/blob/practice/src/practice/pages/app_img_basic.py

지금 openAI API 2달러 밖에 안남아서 제대로 작동을 안할 수 있다.
추후에 자신의 API 키를 넣는 인풋을 넣어두겠다

여러 이미지를 입력 받고 해당 이미지를 기반으로 QnA를 할 수 있는 챗봇을 구현했다.

과제 요구 사항
- [x]  여러 이미지를 입력으로 받기
- [x]  업로드 된 이미지들을 가지고 자유롭게 질의응답 할 수 있는 챗봇 구현
- 채팅 내역을 prompt로 사용
- 그리고 사용자가 여러 번 질문을 입력해도 처음 주어진 이미지들로 답변할 수 있도록 이미지를 벡터DB에 저장
- [x]  다음 이미지들과 질문에 대한 챗봇의 답변 생성 - 이미지: 인터넷에서 강아지 사진과 고양이 사진 각각 1장씩 찾아 입력으로 쓰시면 됩니다.
- 질문 1: 주어진 두 사진의 공통점이 뭐야?
- 질문 2: 주어진 두 사진의 차이점이 뭐야?

솔직히 이번 기본 과제에서 많이 헤맸다...

파이썬 기초 밖에 모르는 초보자기도 했고, Langchain와 RAG를 제대로 다뤄보는 건 처음이라 애를 많이 먹었다. 실제로 여태까지 한 과제들 중에서 가장 많은 시간을 들였다.

특히 이미지를 벡터 스토어에 저장해서 모든 유저의 입력에 이미지의 context를 불러오게 하는 부분에서 많이 헤맸다.

1. RAG를 어떻게 관리해야하는가?
1. 벡터 DB를 로컬에 저장해서 persistent하게 관리할 것인가?
2. 아니면 인메모리로 관리해서 서버를 재시작할 때마다 벡터 DB를 초기화해야하나?

나는 처음에 로컬에 벡터 DB를 저장해두는 방식을 택했다.
그런데 여러 번 테스트를 해보니, 이전에 올려둔 이미지를 계속 context로 쌓여서 오히려 답변 생성에 방해가 됐다.

def get_vectorstore() -> Chroma:

 client = chromadb.Client()

 # clear_system_cache() 이 부분은 streamlit 오류 관련으로 적은 코드입니다.

 client.clear_system_cache()

 return Chroma(

 client=client,

 collection_name=COLLECTION_NAME,

 embedding_function=embeddings

 )

그래서 예전에 썼던 예제들처럼 인메모리로 관리를 하게끔 했다.

2. 벡터 DB에 이미지를 어떻게 저장할 것인가?

처음에는 이미지를 임베딩 모델에 통과시켜야 하나 싶었는데,
내 목표는 GPT에 여러 장의 사진을 보내주는 거라 Base64로 인코딩한 이미지를
page_content
에 저장하는 방식으로 작업했다.
def images_to_docs(images: list) -> list[Document]:

 docs = []

 for image in images:

 img = Image.open(image)

 buffered = BytesIO()

 img.save(buffered, format=img.format)

 # base64로 인코딩

 image_base64 = base64.b64encode(buffered.getvalue()).decode("utf-8")

 # Document 형태로 page_content 안에 

 docs.append(Document(

 page_content=f"data:image/{img.format.lower()};base64,{image_base64}",

 ))

 return docs

사용자의 입력을 쿼리로 사용해서 관련된 이미지들을 가져오고,
이 이미지들을 openAi API 문서에서 요구하는 형태의 구조로 가공했다.
https://platform.openai.com/docs/guides/images-vision?api-mode=responses&format=base64-encoded

 retriever = vectordb.as_retriever()

 docs = retriever.get_relevant_documents(prompt)

 formatted_docs = format_docs(docs)

 #(중략)

 for image_data in formatted_docs:

 img_msgs[0]["content"].append({

 "type": "image_url",

 "image_url": {"url": image_data}

 })

### 아직 해결하지 못한 이슈들

3. 파일 업로더에서 이미지 삭제하면 RAG에 쌓인 이미지 데이터도 함께 지워야 하는데, 어떻게 동기화할까?

떠오르는 방법은 업로드할 때 벡터 DB에 고유 ID를 붙여 두고, 렌더링할 때마다 현재 업로드된 ID 집합과 DB의 ID 집합을 비교해서 싱크를 맞추거나
업로드 리스트가 바뀔 때마다 벡터 스토어를 통째로 재생성하는 방식
근데 이게 Streamlit에서 깔끔하게 구현될지는 좀 더 확인해봐야 할 것 같다. 프로토타입 뚝딱 만들기엔 편한데 디테일한 기능을 구현하는 것에는 제약이 있다.

4. 유저가 올린 이미지들을 RAG로 관리하는 것이 맞을까?

솔직히 이건 아직 확신이 서지 않는다.
업로더에 올라온 이미지만 고려해서 답변해주면 되는 플로우라면, 굳이 RAG를 쓸 필요 없이 세션 메모리로도 충분히 관리할 수 있다.
그래서 심화 과제에서는 벡터 DB 대신 세션 메모리에 저장해서 처리했다.
물론 챗지피티처럼 채팅마다 이미지를 첨부할 수 있는 플로우일 경우에는 RAG가 유리하겠지만... 이 프로젝트에서는 좀 더 들여다볼 필요가 있을 것 같다.

### 💥 streamlit cloud에 chromaDB 사용하는 app 배포할 때 주의해야할 점!!

streamlit 앱을 streamlit cloud에 배포할 때 chromadb를 설치하는 과정에서 의존성 에러가 발생한다.
오류 로그에 있는 문서 링크를 타고 들어가서
pysqlite3-binary
를 설치한 후, 해당 소스코드 파일에 이 코드를 추가하면 된다.
import('pysqlite3')

import sys

sys.modules['sqlite3'] = sys.modules.pop('pysqlite3')

import pysqlite3 as sqlite3

## 🌼심화 과제 회고: 이미지 기반 패션 추천 서비스
데모 앱 보러가기
https://app-chatbot-gkqvxwqzjxqytmb8e8e9dp.streamlit.app/

따로 사이드바에서 본인의 openAI APi key를 입력해야 사용이 가능하다.

코드 보기
https://github.com/sosososoyoen/streamlit-chatbot/blob/practice/src/practice/pages/app_img.py

과제 요구 사항 및 추가한 기능
- [x]  여러 이미지를 입력으로 받아서 패션 추천 결과를 출력하기
- [x]  Langchain + Open AI(gpt-4o-mini)
- [x]  TavilySearchResults - 답변에서 키워드 추출해서 패션 아이템 검색

기본 과제에서는 RAG를 이미지 저장에 활용했다면
심화 과제에서는 웹 검색을 통해 답변의 퀄리티를 높이는 방향으로 작업을 했다.

원래는 논문 기반 QnA 서비스를 만들려고 했는데, 기본 과제에 힘을 너무 쏟아버린 나머지, 기본 과제와 비슷한 주제인 패션 추천 서비스로 주제를 바꿨다...
근데 솔직히 나는 패션 추천 주제에 관심이 매우 매우 없음... 또 멋대로 주제 바꿀지도 모른다

1. 웹 검색 도구를 어떻게 활용할까?

웹 검색 도구를 통한 RAG란 게 원래 답변을 생성할 때 context를 제공하는데 쓰이는 것인데
나는 반대로 답변 생성 -> 키워드를 통해 검색 -> 참고할만한 문서들 가져와서 답변 밑에 링크로 달아주는 플로우로 작업했다.
query_template = PromptTemplate.from_template("""

당신은 패션 스타일 전문 AI 어시스턴트입니다. 이미지 설명을 보고 그 사람에게 어울리는 스타일을 추천해주세요.

이미지 설명:

{caption}

유저 질문:

{user_input}

위 맥락을 참고해, 다음 형식으로 출력해줘:

답변: <전문적인 스타일 추천 텍스트>

키워드: <검색에 사용할 핵심 키워드 2~3개를 쉼표로 구분하여>

""")

# 사진을 분석하고 캡션을 만들어주는 함수

def generate_caption():

 if not st.session_state.image_data_list:

 return ""

 img_msgs = [

 {

 "role": "user", "content": [

 "위 이미지들을 설명하는 캡션을 한글로 만들어주세요."

 ]

 }

 ]

 for image_data in st.session_state.image_data_list:

 img_msgs[0]["content"].append({

 "type": "image_url",

 "image_url": {"url": f"data:image/{image_data['format']};base64,{image_data['base64']}"}

 })

 res = model.invoke(img_msgs)

 return res.content

# 답변 얻고 키워드 추출 후 웹 검색해서 답변 + 검색 결과 반환

def answer_and_search(caption: str, user_input: str, k: int = 3):

 # 2) 답변 + 키워드 생성

 raw = query_chain.invoke({"caption": caption, "user_input": user_input})

 

 # 3) 모델 출력 파싱

 answer = ""

 keywords = []

 for line in raw.split("\n"):

 if line.startswith("답변:"):

 answer = line[len("답변:"):].strip()

 if line.startswith("키워드:"):

 kws = line[len("키워드:"):].strip()

 keywords = [w.strip() for w in kws.split(",") if w.strip()]

 

 query = " ".join(keywords)

 search_results = search_docs(query, k)

 url_content_pairs = [{"url": doc.metadata["source"], "content": doc.page_content} for doc in search_results]

 return answer, keywords, url_content_pairs

# 답변 만들어내는 코드

 with st.chat_message("assistant"):

 with st.spinner("이미지 분석 중...."):

 caption = generate_caption()

 user_input = prompt

 

 if st.session_state.enable_search:

 with st.spinner("검색 중...."):

 answer, keywords, url_content_pairs = answer_and_search(caption, user_input, k=4)

 # 답변 먼저 보여주기

 st.markdown(answer)

 # 추출된 키워드

 st.caption("🔑 검색 키워드: " + ", ".join(keywords))

 # 이미지 출력

 for pair in url_content_pairs:

 st.markdown(f"- [🔗 {pair['content']}]({pair['url']})")

 st.session_state.messages.append({

 "role": "assistant",

 "content": answer,

 "keywords": keywords,

 "urls": url_content_pairs

 })

 else:

 # 검색 꺼져있으면 그냥 답변만

 with st.spinner("답변 생성 중...."):

 qa_only = query_chain.invoke({"caption": caption, "user_input": user_input})

 st.markdown(qa_only)

 st.session_state.messages.append({"role": "assistant", "content": qa_only})

왜 이렇게 했냐면 웹 검색 도구 Tavily가 생각보다 검색을 못해서 그리고 시간이 부족해서 별 다른 아이디어가 나오지 않았다.

gpt한테 이미지들을 보내고 이미지들을 설명하는 캡션 만들어달라 하기 -> 캡션과 유저의 입력을 넣고 답변 생성 -> 생성된 답변에서 키워드를 추출해서 웹 검색 -> 답변과 함께 웹 검색 결과를 출력해주기

이 플로우로 작업을 해보았는데, gpt 토큰을 너무 많이 소비하기도 하고, 속도도 느려서 다른 방법을 찾아보려고 한다.

지금 생각해보면 여러가지 의류 사진들을 임베딩 해서 벡터 스토어에 저장해두고, 유저가 추천해달라고 하면 비슷한 이미지 혹은 텍스트를 가져오는 방식이 괜찮아 보인다.

### 🐋 앞으로 개선해나가야 하는 점

1. 유저의 이전 대화 내용을 기억해서 컨텍스트로 활용하기
* https://python.langchain.com/docs/how_to/chatbots_memory/ 랭그래프를 활용해서 챗 히스토리 관리하기
* 이미지 캡션 같은 부분을 매번 생성하지 않고, 캐싱하는 방식으로
2. Base64 인코딩으로 인한 페이로드 부피 최적화
* 로컬에 경량 비전 모델을 두고 캡션, 임베딩을 처리해볼까..?
3. ✨ 제일 중요! 답변 내용의 평가 지표 정하고 평가하는 플로우 만들기
* 제일 중요한 것이 이것인데... 기능 만들기에 급급해져서 여기에 대해 고민을 1도 하지 않았다.
4. RAG를 어떻게 활용할 것인지 고민해보기
1. RAG를 통해 답변의 퀄리티를 높이려면?
2. 어떻게 하면 검색의 성능을 높일 수 있을까?

### 🐋 나의 목표가 무엇인지 인지하고 가자
나는 이 프로젝트에서 Langchain과 RAG를 최대한 잘 활용하여 gpt 4o까지는 아니어도 비교적 저비용의 모델을 사용해 최대한의 퀄리티를 끌어오는 것이다.
여기서 중요한건 RAG와 평가지표인데 남은 주차동안 여러가지를 시도해보아야겠다.

#항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM #RAG #Langchain #streamlit

블로그에서 읽기 : https://velog.io/@soonmac/hh-plus-ai-week6 이번 6주차는 5월 3일 휴강을 하게 되면서 2주로 연장되었다ㅎㅎ 오예~연휴동안 쉬면서 프로젝트를 진행해보려고 했는데 하하 연휴 때 방송대 수업이나 여행으로 너무 바쁘게 움직여서 생각보다 많이 공부를 하지 못했다 흑흑... 6주차 발제 내용은 크게 3가지를 다뤘다.1. Langchain과 Streamlit으로 챗봇 구현하기2. LLM 챗봇 서빙하기3. 멀티 모달 및 RAG를 LLM 챗봇에서 활용하기 거의 실습 코드 위주로 진행됐고, 이번 주부터 본격적으로 프로젝트 작업에 들어가는 거라서 발제 내용은 따로 정리하지 않을 것이다. 오픈소스로 풀린 LLM을 사용하기 위해 AWS 클라우드 환경을 미리 세팅해두었는데, 학습용 인스턴스 생성은 AWS 할당량 증가를 요청 해야 해서 하루 이틀 정도 걸린다.다행히 발제 전에 세팅 튜토리얼이 올라오니까 인프라 모르는 사람들도 크게 걱정할 필요는 없을 것 같다. ## 🍀기본 과제 회고: 이미지를 가지고 질의응답을 하는 챗봇 구현 데모 앱 보러가기https://app-chatbot-gkqvxwqzjxqytmb8e8e9dp.streamlit.app/ 코드 보기https://github.com/sosososoyoen/streamlit-chatbot/blob/practice/src/practice/pages/app_img_basic.py 지금 openAI API 2달러 밖에 안남아서 제대로 작동을 안할 수 있다.추후에 자신의 API 키를 넣는 인풋을 넣어두겠다 여러 이미지를 입력 받고 해당 이미지를 기반으로 QnA를 할 수 있는 챗봇을 구현했다. 과제 요구 사항- [x] &nbsp;여러 이미지를 입력으로 받기- [x] &nbsp;업로드 된 이미지들을 가지고 자유롭게 질의응답 할 수 있는 챗봇 구현- 채팅 내역을 prompt로 사용- 그리고 사용자가 여러 번 질문을 입력해도 처음 주어진 이미지들로 답변할 수 있도록 이미지를 벡터DB에 저장- [x] &nbsp;다음 이미지들과 질문에 대한 챗봇의 답변 생성 - 이미지: 인터넷에서 강아지 사진과 고양이 사진 각각 1장씩 찾아 입력으로 쓰시면 됩니다.- 질문 1: 주어진 두 사진의 공통점이 뭐야?- 질문 2: 주어진 두 사진의 차이점이 뭐야? 솔직히 이번 기본 과제에서 많이 헤맸다... 파이썬 기초 밖에 모르는 초보자기도 했고, Langchain와 RAG를 제대로 다뤄보는 건 처음이라 애를 많이 먹었다. 실제로 여태까지 한 과제들 중에서 가장 많은 시간을 들였다. 특히 이미지를 벡터 스토어에 저장해서 모든 유저의 입력에 이미지의 context를 불러오게 하는 부분에서 많이 헤맸다. 1. RAG를 어떻게 관리해야하는가?1. 벡터 DB를 로컬에 저장해서 persistent하게 관리할 것인가?2. 아니면 인메모리로 관리해서 서버를 재시작할 때마다 벡터 DB를 초기화해야하나? 나는 처음에 로컬에 벡터 DB를 저장해두는 방식을 택했다.그런데 여러 번 테스트를 해보니, 이전에 올려둔 이미지를 계속 context로 쌓여서 오히려 답변 생성에 방해가 됐다. <pre ><code>def get_vectorstore() -&gt; Chroma:

 client = chromadb.Client()

 # clear_system_cache() 이 부분은 streamlit 오류 관련으로 적은 코드입니다.

 client.clear_system_cache()

 return Chroma(

 client=client,

 collection_name=COLLECTION_NAME,

 embedding_function=embeddings

 )</code></pre>그래서 예전에 썼던 예제들처럼 인메모리로 관리를 하게끔 했다. 2. 벡터 DB에 이미지를 어떻게 저장할 것인가? 처음에는 이미지를 임베딩 모델에 통과시켜야 하나 싶었는데,내 목표는 GPT에 여러 장의 사진을 보내주는 거라 Base64로 인코딩한 이미지를 <code >page_content</code>에 저장하는 방식으로 작업했다.<pre ><code>def images_to_docs(images: list) -&gt; list[Document]:

 docs = []

 for image in images:

 img = Image.open(image)

 buffered = BytesIO()

 img.save(buffered, format=img.format)

 # base64로 인코딩

 image_base64 = base64.b64encode(buffered.getvalue()).decode("utf-8")

 # Document 형태로 page_content 안에 

 docs.append(Document(

 page_content=f"data:image/{img.format.lower()};base64,{image_base64}",

 ))

 return docs</code></pre> 사용자의 입력을 쿼리로 사용해서 관련된 이미지들을 가져오고,이 이미지들을 openAi API 문서에서 요구하는 형태의 구조로 가공했다.https://platform.openai.com/docs/guides/images-vision?api-mode=responses&amp;format=base64-encoded <pre ><code> retriever = vectordb.as_retriever()

 docs = retriever.get_relevant_documents(prompt)

 formatted_docs = format_docs(docs)

 #(중략)

 for image_data in formatted_docs:

 img_msgs[0]["content"].append({

 "type": "image_url",

 "image_url": {"url": image_data}

 })</code></pre> ### 아직 해결하지 못한 이슈들 3. 파일 업로더에서 이미지 삭제하면 RAG에 쌓인 이미지 데이터도 함께 지워야 하는데, 어떻게 동기화할까? 떠오르는 방법은 업로드할 때 벡터 DB에 고유 ID를 붙여 두고, 렌더링할 때마다 현재 업로드된 ID 집합과 DB의 ID 집합을 비교해서 싱크를 맞추거나업로드 리스트가 바뀔 때마다 벡터 스토어를 통째로 재생성하는 방식근데 이게 Streamlit에서 깔끔하게 구현될지는 좀 더 확인해봐야 할 것 같다. 프로토타입 뚝딱 만들기엔 편한데 디테일한 기능을 구현하는 것에는 제약이 있다. 4. 유저가 올린 이미지들을 RAG로 관리하는 것이 맞을까? 솔직히 이건 아직 확신이 서지 않는다.업로더에 올라온 이미지만 고려해서 답변해주면 되는 플로우라면, 굳이 RAG를 쓸 필요 없이 세션 메모리로도 충분히 관리할 수 있다.그래서 심화 과제에서는 벡터 DB 대신 세션 메모리에 저장해서 처리했다.물론 챗지피티처럼 채팅마다 이미지를 첨부할 수 있는 플로우일 경우에는 RAG가 유리하겠지만... 이 프로젝트에서는 좀 더 들여다볼 필요가 있을 것 같다. ### 💥 streamlit cloud에 chromaDB 사용하는 app 배포할 때 주의해야할 점!! streamlit 앱을 streamlit cloud에 배포할 때 chromadb를 설치하는 과정에서 의존성 에러가 발생한다.오류 로그에 있는 문서 링크를 타고 들어가서 <code >pysqlite3-binary</code>를 설치한 후, 해당 소스코드 파일에 이 코드를 추가하면 된다.<pre ><code>import('pysqlite3')

import sys

sys.modules['sqlite3'] = sys.modules.pop('pysqlite3')

import pysqlite3 as sqlite3</code></pre> ## 🌼심화 과제 회고: 이미지 기반 패션 추천 서비스데모 앱 보러가기https://app-chatbot-gkqvxwqzjxqytmb8e8e9dp.streamlit.app/ 따로 사이드바에서 본인의 openAI APi key를 입력해야 사용이 가능하다. 코드 보기https://github.com/sosososoyoen/streamlit-chatbot/blob/practice/src/practice/pages/app_img.py 과제 요구 사항 및 추가한 기능- [x] &nbsp;여러 이미지를 입력으로 받아서 패션 추천 결과를 출력하기- [x] &nbsp;Langchain + Open AI(gpt-4o-mini)- [x] &nbsp;TavilySearchResults - 답변에서 키워드 추출해서 패션 아이템 검색 기본 과제에서는 RAG를 이미지 저장에 활용했다면심화 과제에서는 웹 검색을 통해 답변의 퀄리티를 높이는 방향으로 작업을 했다. 원래는 논문 기반 QnA 서비스를 만들려고 했는데, 기본 과제에 힘을 너무 쏟아버린 나머지, 기본 과제와 비슷한 주제인 패션 추천 서비스로 주제를 바꿨다...근데 솔직히 나는 패션 추천 주제에 관심이 매우 매우 없음... 또 멋대로 주제 바꿀지도 모른다 1. 웹 검색 도구를 어떻게 활용할까? 웹 검색 도구를 통한 RAG란 게 원래 답변을 생성할 때 context를 제공하는데 쓰이는 것인데나는 반대로 답변 생성 -&gt; 키워드를 통해 검색 -&gt; 참고할만한 문서들 가져와서 답변 밑에 링크로 달아주는 플로우로 작업했다.<pre ><code>query_template = PromptTemplate.from_template("""

당신은 패션 스타일 전문 AI 어시스턴트입니다. 이미지 설명을 보고 그 사람에게 어울리는 스타일을 추천해주세요.

이미지 설명:

{caption}

유저 질문:

{user_input}

위 맥락을 참고해, 다음 형식으로 출력해줘:

답변: &lt;전문적인 스타일 추천 텍스트&gt;

키워드: &lt;검색에 사용할 핵심 키워드 2~3개를 쉼표로 구분하여&gt;

""")

# 사진을 분석하고 캡션을 만들어주는 함수

def generate_caption():

 if not st.session_state.image_data_list:

 return ""

 img_msgs = [

 {

 "role": "user", "content": [

 "위 이미지들을 설명하는 캡션을 한글로 만들어주세요."

 ]

 }

 ]

 for image_data in st.session_state.image_data_list:

 img_msgs[0]["content"].append({

 "type": "image_url",

 "image_url": {"url": f"data:image/{image_data['format']};base64,{image_data['base64']}"}

 })

 res = model.invoke(img_msgs)

 return res.content

# 답변 얻고 키워드 추출 후 웹 검색해서 답변 + 검색 결과 반환

def answer_and_search(caption: str, user_input: str, k: int = 3):

 # 2) 답변 + 키워드 생성

 raw = query_chain.invoke({"caption": caption, "user_input": user_input})

 

 # 3) 모델 출력 파싱

 answer = ""

 keywords = []

 for line in raw.split("\n"):

 if line.startswith("답변:"):

 answer = line[len("답변:"):].strip()

 if line.startswith("키워드:"):

 kws = line[len("키워드:"):].strip()

 keywords = [w.strip() for w in kws.split(",") if w.strip()]

 

 query = " ".join(keywords)

 search_results = search_docs(query, k)

 url_content_pairs = [{"url": doc.metadata["source"], "content": doc.page_content} for doc in search_results]

 return answer, keywords, url_content_pairs</code></pre> <pre ><code># 답변 만들어내는 코드

 with st.chat_message("assistant"):

 with st.spinner("이미지 분석 중...."):

 caption = generate_caption()

 user_input = prompt

 

 if st.session_state.enable_search:

 with st.spinner("검색 중...."):

 answer, keywords, url_content_pairs = answer_and_search(caption, user_input, k=4)

 # 답변 먼저 보여주기

 st.markdown(answer)

 # 추출된 키워드

 st.caption("🔑 검색 키워드: " + ", ".join(keywords))

 # 이미지 출력

 for pair in url_content_pairs:

 st.markdown(f"- [🔗 {pair['content']}]({pair['url']})")

 st.session_state.messages.append({

 "role": "assistant",

 "content": answer,

 "keywords": keywords,

 "urls": url_content_pairs

 })

 else:

 # 검색 꺼져있으면 그냥 답변만

 with st.spinner("답변 생성 중...."):

 qa_only = query_chain.invoke({"caption": caption, "user_input": user_input})

 st.markdown(qa_only)

 st.session_state.messages.append({"role": "assistant", "content": qa_only})</code></pre> 왜 이렇게 했냐면 웹 검색 도구 Tavily가 생각보다 검색을 못해서 그리고 시간이 부족해서 별 다른 아이디어가 나오지 않았다. gpt한테 이미지들을 보내고 이미지들을 설명하는 캡션 만들어달라 하기 -&gt; 캡션과 유저의 입력을 넣고 답변 생성 -&gt; 생성된 답변에서 키워드를 추출해서 웹 검색 -&gt; 답변과 함께 웹 검색 결과를 출력해주기 이 플로우로 작업을 해보았는데, gpt 토큰을 너무 많이 소비하기도 하고, 속도도 느려서 다른 방법을 찾아보려고 한다. 지금 생각해보면 여러가지 의류 사진들을 임베딩 해서 벡터 스토어에 저장해두고, 유저가 추천해달라고 하면 비슷한 이미지 혹은 텍스트를 가져오는 방식이 괜찮아 보인다. ### 🐋 앞으로 개선해나가야 하는 점 1. 유저의 이전 대화 내용을 기억해서 컨텍스트로 활용하기* https://python.langchain.com/docs/how_to/chatbots_memory/ 랭그래프를 활용해서 챗 히스토리 관리하기* 이미지 캡션 같은 부분을 매번 생성하지 않고, 캐싱하는 방식으로2. Base64 인코딩으로 인한 페이로드 부피 최적화* 로컬에 경량 비전 모델을 두고 캡션, 임베딩을 처리해볼까..?3. ✨ 제일 중요! 답변 내용의 평가 지표 정하고 평가하는 플로우 만들기* 제일 중요한 것이 이것인데... 기능 만들기에 급급해져서 여기에 대해 고민을 1도 하지 않았다.4. RAG를 어떻게 활용할 것인지 고민해보기1. RAG를 통해 답변의 퀄리티를 높이려면?2. 어떻게 하면 검색의 성능을 높일 수 있을까? ### 🐋 나의 목표가 무엇인지 인지하고 가자나는 이 프로젝트에서 Langchain과 RAG를 최대한 잘 활용하여 gpt 4o까지는 아니어도 비교적 저비용의 모델을 사용해 최대한의 퀄리티를 끌어오는 것이다.여기서 중요한건 RAG와 평가지표인데 남은 주차동안 여러가지를 시도해보아야겠다. #항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM #RAG #Langchain #streamlit

항해플러스 AI 후기(6주차) - Streamlit으로 챗봇 만들기

AI 기술이 우리 일상과 산업 전반에 스며들면서 소프트웨어 개발 환경 역시 큰 변화의 물결을 맞이하고 있다. 특히 코딩을 돕는 AI 에이전트의 등장은 개발 생산성에 대한 큰 변화를 만들고 있다. 나 역시 이러한 변화를 체감하며, 나에게 익숙한 소프트웨어 개발의 대표적인 두 축인 프론트엔드와 백엔드 영역에서 AI 기술이 미치는 영향과 그로 인해 변화하는 소프트웨어 엔지니어의 역할에 대해 개인적인 생각을 정리해 본다.

먼저 프론트엔드 영역을 살펴보자. 프론트엔드 엔지니어의 주요 업무 중 하나는 디자이너가 만든 시각적 결과물을 실제 사용자와 상호작용할 수 있는 인터페이스로 구현하는 것이다. 최근 커서(Cursor)와 같은 코딩 에이전트는 이 영역에서 놀라운 생산성 향상을 만들었다. 특히 피그마(Figma)와 MCP를 통한 연동 및 디자인 시스템의 활용은 정형화된 UI 구현 작업을 상당 부분 자동화하여, 엔지니어는 반복적인 코드 작성 시간을 줄이고 더 복잡한 문제에 집중할 수 있게 되었다. 물론 아직은 AI가 생성한 코드를 그대로 사용하기보다는 엔지니어의 검토와 수정이 필요하며, 복잡한 상태 관리나 비즈니스 로직 구현, 또는 매우 독창적인 인터랙션 구현에는 한계가 있다. 하지만 UI 구현에 드는 시간과 노력이 크게 줄어든다는 점은 부인할 수 없는 변화로 보인다.

다음으로 백엔드 영역도 살펴보자. 백엔드 엔지니어는 비즈니스 요구사항을 만족시키는 도메인 논리를 구현하고 안정적인 API를 제공하며, 나아가 대규모 시스템을 효율적으로 운영하기 위한 아키텍처 설계와 관리를 담당한다. 내 경험과 주변 동료들의 이야기를 종합해 보면, 백엔드 영역에서 코딩 에이전트의 생산성 향상 효과는 UI 구현만큼 극적이지는 않다. 복잡하게 얽힌 비즈니스 규칙, 레거시 시스템과의 연동, 데이터베이스 설계, 보안 및 성능 최적화 등 고려해야 할 요소가 많고, 도메인 맥락 의존성이 높기 때문일 것이다. 하지만 전혀 도움이 되지 않는 것은 아니다. 특정 로직 구현에 대한 아이디어를 얻거나, 테스트 코드 또는 API 문서 초안을 작성하고, 복잡한 아키텍처 패턴을 학습하거나 설계 대안을 탐색하는 과정에서는 분명 유용한 조력자 역할을 하고 있다. 또한, 클라우드 기술의 발전은 과거 백엔드 엔지니어의 주된 고민거리였던 인프라 구축 및 운영 부담을 상당 부분 덜어주며 비즈니스 요구사항 개발에 더 집중할 수 있는 환경을 만들어주고 있다.

이러한 변화 속에서 주목할 점은 프론트엔드와 백엔드 사이의 경계가 점차 흐릿해지고 있다는 것이다. AI의 도움으로 UI 구현 부담이 줄어든 프론트엔드 엔지니어는 자연스럽게 상태 관리 로직이나 서버와의 통신 너머, 즉 백엔드 영역의 문제 해결에 더 깊이 관여할 여지가 생겼다. 반대로 백엔드 엔지니어 역시 과거보다 표준화되고 있는 프론트엔드 기술(리액트)과 AI의 도움을 받아 사용자 인터페이스 개발에 대한 진입 장벽이 낮아졌다. 물론 각 영역의 깊이 있는 전문성은 여전히 중요하지만, 기술적인 장벽이 낮아짐에 따라 엔지니어들이 특정 기술 스택에 갇히기보다 제품 전체의 맥락을 이해하고 최종 사용자 가치를 중심으로 사고하는 것이 더욱 중요해지고 있다.

최근 여러 기업에서
프로덕트 엔지니어(Product Engineer)
라는 직군을 채용하는 모습은 이러한 변화를 반영하는 현상 중 하나라고 생각한다. 프로덕트 엔지니어는 단순히 프론트엔드와 백엔드 기술을 모두 다룰 수 있는 풀스택 개발자를 의미하는 것을 넘어, 사용자 경험부터 기술 구현, 데이터 분석, 인프라 운영까지 제품 개발의 전 과정에 걸쳐 주도적으로 문제를 정의하고 해결하며 제품의 성공에 기여하는 역할로 기대받고 있다. 불과 몇 년 전만 해도 이상적인 이야기처럼 들렸을지 모르지만, AI 기술의 발전과 개발 생태계의 변화는 이러한 역할의 현실화시키고 있다. 내 주변에서도 이미 기술 영역의 경계를 넘어 제품 자체에 집중하며 일하는 동료들을 어렵지 않게 찾아볼 수 있다.

2010년대 모바일 시대를 맞이하며 전문화되었던 프론트엔드와 백엔드의 역할 분담이, 이제 AI 시대를 맞아 다시 융합되는 듯한 흐름이 관찰된다. 물론 이는 나의 제한적인 경험과 관찰에 기반한 생각이며, 앞으로 기술이 어떻게 발전하고 시장이 어떻게 반응할지는 계속 지켜봐야 할 것이다. 하지만 한 가지 분명한 점은, 앞으로 소프트웨어 엔지니어에게는 깊이 있는 전문성과 더불어, 직군의 경계를 넘어 협력하고 제품 전체의 가치를 높이는 능력이 더욱 중요해질 것이라는 점이다. 이러한 변화의 흐름을 읽고 끊임없이 배우고 적응하는 자세가 그 어느 때보다 필요한 시점인 것 같다.

AI 기술이 우리 일상과 산업 전반에 스며들면서 소프트웨어 개발 환경 역시 큰 변화의 물결을 맞이하고 있다. 특히 코딩을 돕는 AI 에이전트의 등장은 개발 생산성에 대한 큰 변화를 만들고 있다. 나 역시 이러한 변화를 체감하며, 나에게 익숙한 소프트웨어 개발의 대표적인 두 축인 프론트엔드와 백엔드 영역에서 AI 기술이 미치는 영향과 그로 인해 변화하는 소프트웨어 엔지니어의 역할에 대해 개인적인 생각을 정리해 본다. 먼저 프론트엔드 영역을 살펴보자. 프론트엔드 엔지니어의 주요 업무 중 하나는 디자이너가 만든 시각적 결과물을 실제 사용자와 상호작용할 수 있는 인터페이스로 구현하는 것이다. 최근 커서(Cursor)와 같은 코딩 에이전트는 이 영역에서 놀라운 생산성 향상을 만들었다. 특히 피그마(Figma)와 MCP를 통한 연동 및 디자인 시스템의 활용은 정형화된 UI 구현 작업을 상당 부분 자동화하여, 엔지니어는 반복적인 코드 작성 시간을 줄이고 더 복잡한 문제에 집중할 수 있게 되었다. 물론 아직은 AI가 생성한 코드를 그대로 사용하기보다는 엔지니어의 검토와 수정이 필요하며, 복잡한 상태 관리나 비즈니스 로직 구현, 또는 매우 독창적인 인터랙션 구현에는 한계가 있다. 하지만 UI 구현에 드는 시간과 노력이 크게 줄어든다는 점은 부인할 수 없는 변화로 보인다. 다음으로 백엔드 영역도 살펴보자. 백엔드 엔지니어는 비즈니스 요구사항을 만족시키는 도메인 논리를 구현하고 안정적인 API를 제공하며, 나아가 대규모 시스템을 효율적으로 운영하기 위한 아키텍처 설계와 관리를 담당한다. 내 경험과 주변 동료들의 이야기를 종합해 보면, 백엔드 영역에서 코딩 에이전트의 생산성 향상 효과는 UI 구현만큼 극적이지는 않다. 복잡하게 얽힌 비즈니스 규칙, 레거시 시스템과의 연동, 데이터베이스 설계, 보안 및 성능 최적화 등 고려해야 할 요소가 많고, 도메인 맥락 의존성이 높기 때문일 것이다. 하지만 전혀 도움이 되지 않는 것은 아니다. 특정 로직 구현에 대한 아이디어를 얻거나, 테스트 코드 또는 API 문서 초안을 작성하고, 복잡한 아키텍처 패턴을 학습하거나 설계 대안을 탐색하는 과정에서는 분명 유용한 조력자 역할을 하고 있다. 또한, 클라우드 기술의 발전은 과거 백엔드 엔지니어의 주된 고민거리였던 인프라 구축 및 운영 부담을 상당 부분 덜어주며 비즈니스 요구사항 개발에 더 집중할 수 있는 환경을 만들어주고 있다. 이러한 변화 속에서 주목할 점은 프론트엔드와 백엔드 사이의 경계가 점차 흐릿해지고 있다는 것이다. AI의 도움으로 UI 구현 부담이 줄어든 프론트엔드 엔지니어는 자연스럽게 상태 관리 로직이나 서버와의 통신 너머, 즉 백엔드 영역의 문제 해결에 더 깊이 관여할 여지가 생겼다. 반대로 백엔드 엔지니어 역시 과거보다 표준화되고 있는 프론트엔드 기술(리액트)과 AI의 도움을 받아 사용자 인터페이스 개발에 대한 진입 장벽이 낮아졌다. 물론 각 영역의 깊이 있는 전문성은 여전히 중요하지만, 기술적인 장벽이 낮아짐에 따라 엔지니어들이 특정 기술 스택에 갇히기보다 제품 전체의 맥락을 이해하고 최종 사용자 가치를 중심으로 사고하는 것이 더욱 중요해지고 있다. 최근 여러 기업에서 <code >프로덕트 엔지니어(Product Engineer)</code>라는 직군을 채용하는 모습은 이러한 변화를 반영하는 현상 중 하나라고 생각한다. 프로덕트 엔지니어는 단순히 프론트엔드와 백엔드 기술을 모두 다룰 수 있는 풀스택 개발자를 의미하는 것을 넘어, 사용자 경험부터 기술 구현, 데이터 분석, 인프라 운영까지 제품 개발의 전 과정에 걸쳐 주도적으로 문제를 정의하고 해결하며 제품의 성공에 기여하는 역할로 기대받고 있다. 불과 몇 년 전만 해도 이상적인 이야기처럼 들렸을지 모르지만, AI 기술의 발전과 개발 생태계의 변화는 이러한 역할의 현실화시키고 있다. 내 주변에서도 이미 기술 영역의 경계를 넘어 제품 자체에 집중하며 일하는 동료들을 어렵지 않게 찾아볼 수 있다. 2010년대 모바일 시대를 맞이하며 전문화되었던 프론트엔드와 백엔드의 역할 분담이, 이제 AI 시대를 맞아 다시 융합되는 듯한 흐름이 관찰된다. 물론 이는 나의 제한적인 경험과 관찰에 기반한 생각이며, 앞으로 기술이 어떻게 발전하고 시장이 어떻게 반응할지는 계속 지켜봐야 할 것이다. 하지만 한 가지 분명한 점은, 앞으로 소프트웨어 엔지니어에게는 깊이 있는 전문성과 더불어, 직군의 경계를 넘어 협력하고 제품 전체의 가치를 높이는 능력이 더욱 중요해질 것이라는 점이다. 이러한 변화의 흐름을 읽고 끊임없이 배우고 적응하는 자세가 그 어느 때보다 필요한 시점인 것 같다.

무너지고 있는 프론트엔드, 백엔드 직군의 경계에 대한 고찰

#항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM #HuggingFace #Langchain

블로그에서 읽기 : https://velog.io/@soonmac/hh-plus-ai-week5

드디어 내가 가장 배우고 싶은 랭체인과 RAG 주차가 찾아왔다.
5주차부터 프로젝트 제작을 위한 실무 지식들을 배운다.
나는 랭체인과 RAG를 사용해서 도메인에 특화된 프로젝트를 진행하고 싶었다.
그래서 논문 pdf를 주면 해당 논문에 대해 질의응답을 해주는 챗봇을 만들어보려고 한다.

## 🍀심화 과제 회고: Langchain과 RAG로 논문 요약 서비스 만들어보기

[깃헙 코드 보기](https://github.com/sosososoyoen/hh_plus_ai_3/tree/main/work/week5/%E1%84%89%E1%85%B5%E1%86%B7%E1%84%92%E1%85%AA)
플로우는 대략적으로
논문 pdf 파일을 받으면 pdf 내의 텍스트를 추출하여, 임베딩한 후 RAG의 벡터 DB에 담아두고 해당 논문의 요약본을 생성하는 서비스다.
from langchain.document_loaders import UnstructuredPDFLoader

loader = UnstructuredPDFLoader("./example.pdf")

docs = loader.load()

text_splitter = RecursiveCharacterTextSplitter(

chunk_size=1500,

chunk_overlap=200

)

splits = text_splitter.split_documents(docs)

vectorstore = Chroma.from_documents(

documents=splits,

embedding=OpenAIEmbeddings(api_key=api_key)

)

나는
UnstructuredPDFLoader
를 사용하여 pdf에서 텍스트를 추출하여 청크 사이즈를 1500, 오버랩을 200으로 맞추어 텍스트를 청킹했다. 그 다음엔 Chroma에 이를 임베딩하여 집어넣어줬는데.. 사실 여기까진 별 거 없었다.

테스트로 사용한 논문은 https://arxiv.org/pdf/2005.11401 RAG에 관한 논문이고
내 파이프라인이 만들어낸 요약본은 아래와 같았다. (gpt-4o-mini)

-------------------
### 1. 논문의 목적
이 논문의 목적은 RAG( retrieval-augmented generation) 모델을 통해 사실 추출 및 검증을 수행하는 새로운 접근 방식을 제시하는 것이다. 이를 통해 기존의 복잡한 파이프라인 시스템과 비교하여 단순성과 효율성을 강조한다. 특히, RAG는 도메인 특정 아키텍처나 중간 검색 감독 없이도 성능을 발휘할 수 있음을 보여준다.
### 2. 주요 기여
- 성능: RAG 모델은 3-way 분류에서 최첨단 모델과 비교했을 때 4.3% 내외의 성과를 보였다(§4.4, p.14).
- 단순성: RAG는 복잡한 시스템 없이도 유효한 결과를 도출할 수 있는 능력을 지닌다.
- 응용 가능성: 다양한 언어 모델의 기능을 접목하여 사실 기반의 대화형 응용 프로그램 개발에 기여할 수 있다.
### 3. 사용된 방법론
- 데이터셋: FEVER 데이터셋을 사용하여 모델 성능을 검증한다.
- 모델 검증: RAG 모델의 성능을 3-way 분류로 평가하며, 복잡한 파이프라인 대비 단순한 구조를 강조한다(§4.4, p.14).
- 정량적 결과: RAG 모델이 생성한 응답의 사실 정확성은 높은 비율로 유지되며, 특정 입력에 대해 더 정교한 응답을 낸다.
### 4. 주요 결과
- RAG 모델은 3-way 분류에서 정확도가 4.3% 떨어지는 성과를 보였으며, 이는 기존 방법론에 비해 우수한 수치를 나타낸다(§4.4, p.14).
- 생성된 응답의 구체성과 사실 기반 정확성을 높여, 더 나은 대화형 AI의 기반을 마련한다.
### 5. 한계 및 미래 연구 방향
- 한계: RAG 모델의 데이터 기반이 외부 지식원(예: 위키피디아)의 완전한 사실성을 담보하지 않음으로 인해 생성된 콘텐츠의 신뢰성에 문제가 있을 수 있다(§4.4, p.14).
- 미래 연구 방향: 다루기 어려운 또는 편향된 내용을 자동으로 생성하지 않도록 개선할 수 있는 AI 시스템의 개발 필요성; 다양한 언어의 지원 범위를 확대하여 모델의 효용성을 높이는 연구가 제안된다.
--------------------------

나는 내 서비스가 생성한 요약본을 ROUGE와 BertScore를 기준으로 평가했다.
사용 모델 : gpt-4o-mini
정답용 모델 : gpt-4o

### 🔷 ROUGE

| 지표        | 점수   | 설명 |
|-------------|--------|------|
| ROUGE-1     | 0.2543 | 단어 수준 유사도 |
| ROUGE-2     | 0.0702 | 2-gram 연속성 유사도 (문장 구성 구조) |
| ROUGE-L     | 0.2197 | 문장 뼈대의 유사성 |
| ROUGE-Lsum  | 0.2428 | 전체 요약 구조 유사성 |

### 🔷 BERTScore

| 지표        | 점수   | 설명 |
|-------------|--------|------|
| Precision   | 0.7095 | 정답 요약 의미 중 포함된 비율 |
| Recall      | 0.6887 | 내가 쓴 요약이 정답을 얼마나 커버했는지 |
| F1          | 0.6990 | 의미 유사성 종합 점수 (사람 기준으로 매우 양호함) |

의미적으로는 핵심 내용을 잘 전달한 것 같으나,
문장 구성 방식이나 표현 스타일은 논문 요약 스타일과 차이가 있어보인다.
그리고, 출처를 적어달라했는데 얘가 출처를 제대로 못적는거 보면.. 아직 개선의 여지가 더 필요해 보인다.

다음 과제를 위한 액션 아이템 3가지를 잡아보았다.
1. 프롬프트 수정  
   → "논문 스타일로 학술적인 요약을 해줘" 같은 지시 문구 사용
2. 예시 문장 추가  
   → 학습 시 논문 스타일 예시 문장을 함께 제시
3. 문단 단위 요약 후 통합  
   → Recall + Precision 균형 잡기
심화 과제를 진행하면서, 궁금했던 점들을 과제 QnA 섹션과 멘토링 시간 때 코치님들께 여쭤보았다.
아래는 내가 한 질문들과 다른 분들이 질문해준 것 중에 나도 궁금했던 것들, 그리고 그 답변을 정리한 내용이다!
나처럼 실무에 LLM을 적용해야하는 사람들에게 도움이 됐으면 좋겠다.

## 🌼과제 QnA 섹션 정리

Q1. 요약 텍스트 생성 평가 지표 : ROUGE vs BertScore 어느 쪽이 더 좋을까요?

A.
ROUGE
* 전통적인 요약 태스크 평가 지표
* 정답과 모델이 예측한 요약을 갖고, 레퍼런스 요약 간의 겹치는 토큰 비율을 측정한다.
* 여러 LLM 간의 상대 비교에 유용하다. (=어느 모델이 더 좋은지 체크 가능)
BertScore
* 의미적 유사도 평가
* ROUGE와 달리 어휘가 달라도 유사한 문맥을 포착하기 때문에 점수가 높게 나올 수 있다.
=> 보통은 ROUGE, BertScore, GPT4 평가(LLM-as-a-Judge) 결과를 결합하여 최종 점수를 산출하는 방식으로 진행한다.
Q2. 한국어 텍스트를 평가할 때 중간에 영어로 번역 후 평가를 하는 것이 좋을까요?

A.
번역 품질이 낮으면 평가가 왜곡될 위험성이 많다.

Q3. OpenAI API 서버 불안정 시 대응 전략

A.
인하우스 LLM 대체 (오픈소스 LLM 파인튜닝)
* 규모가 큰 서비스의 경우, 오픈소스 LLM을 튜닝하는 방식으로 내재화를 많이 고려한다.
* 기존에 OpenAI API를 쓰고 있던 서비스라면 그 동안 쌓인 데이터를 통해 오픈소스 LLM을 튜닝하고,
* 모듈, 기능을 하나씩 대체하는 방식으로 진행한다.
Multi-LLM
* OpenAI 뿐만 아니라 Gemini, Claude 등 여러 api를 구성하여 한 쪽 모델에서 응답 실패 시 다음 모델로 전환하는 방식을 채택하기도 한다.
LLM 라우터
* 모든 기능에서 OpenAI를 쓰는 것은 가성비가 좋지 않기 때문에 LLM 라우터를 통해 쿼리 유형별로 최적의 모델을 라우팅한다.

질문 외 추가 팁
* RouteLLM - 프로젝트에 이런 오케스트레이션도 넣으면 좋지 않을까 싶다.
https://github.com/lm-sys/RouteLLM
* RAG 설계
* 모든 문서를 벡터 스토어에 넣기 어렵다면, 핵심 페이지만 선택적으로 저장하라
* 프롬프트 엔지니어링이나 function calling 등 LLM 관련 지식들이 모여있는 블로그
https://devocean.sk.com/blog/techBoardDetail.do?ID=165806&boardType=techBlog
* Outlines 라이브러리
* https://github.com/dottxt-ai/outlines
* LLM의 응답을 파싱해준다. 숫자만 추출하거나 json 포맷을 맞추기에 편해보임.
* 논문을 기반으로 질의응답을 해주는 챗봇 튜토리얼
* https://github.com/liner-engineering/liner-pdf-chat-tutorial

## 🌻멘토링 노트 정리

Q1. RecursiveCharacterTextSplitter에서 텍스트를 청크로 분할할 때 overlap하는 이유에 대해 궁금합니다.

A1.
* 만약 문서를 청크 단위로 완전히 잘라버리면, 문단의 앞뒤 맥락이 끊겨 의미 파악이 어려워진다.
* 어떤 설명이 문단 A 끝 + 문단 B 시작에 걸쳐 있을 경우, 완전히 분리되면 의미를 놓치게 됨.
* 오버랩 안한 chunk의 경우
```
일론 머스크 테슬라 최고경영자(CEO)가 자사 휴머노이드 로봇 '옵
티머스'의 생산이 중국의 희토류 수출 규제로 타격을 입었다고 밝혔다. 테슬라는 중 국 정부와 협의를 진행 중이며, 관련 자원 접근을 위한 승인 절차를 밟고 있다고 덧붙였다.
```
* '옵티머스'가 '옵'과 '티머스'로 분리되어서 옵티머스에 대해 물어보면 제대로 된 답변이 생성안될 가능성이 높다.

Q2. open ai의 서버 상태가 불안정해져서 gpt를 사용할 수 없을 때엔 어떻게 하는 것이 좋을까요?(QnA 섹션 때와 같은 질문을 했다.)

A2.
* 대부분의 회사들은 openLLM을 도입하려고 한다. LLM 서비스 전부를 openLLM으로 사용하거나, 일부 기능만 chatGPT를 사용하는 형태로 운영함.
* 1. 완전 자립
* Open LLM만 사용하여 API 의존성을 완전히 제거
* 2. 하이브리드
* 핵심 기능에는 GPT API를 쓰되, 부가 기능 또는 fallback 용도로는 Open LLM을 사용
* 장점
* api 비용 없음, 보안 이슈 없음(자체 서버에서 가능), api 서버 의존성 이슈 없음
* 단점
* 초기비용 큼(gpu 인프라) 또는 클라우드비용 증가, 상대적으로 낮은 성능
->인력을 통해 개선을 시켜야함 (프롬프트 엔지니어링, RAG, 튜닝)
chatGPT 크기: 1000B이상
openLLM 중에 큰 것들 700B -> GPU인프라 비용 최소 20억 이상
* Ollama를 통해 openLLM 활용할 때 적합한 것: 7B짜리
* 회사 내부 문서가지고 답변하는 것
* RAG -프롬프팅, 튜닝이 많이 필요

Q3. RAG의 동작방식에 대해: 유저의 입력 → 모든 벡터 DB의 문서들의 임베딩 유사도를 체크 → 가장 유사도가 높은 문서를 가져와서 프롬프트에 얹는다. 이 방식이 맞을까요? 맞다면 문서의 양이 많아질 수록 검색속도가 느려지지 않을까요?

A3.
ㅇㅇ 더 자세하게 말씀드리자면 아래와 같다.
1. 유저 질문을 입력
2. 입력을 임베딩하여 쿼리 벡터 생성
3. 벡터 DB (예: FAISS, Chroma, Weaviate 등)에서 유사도가 높은 문서 top-k를 검색 -> 검색된 문서들을 프롬프트에 넣어 LLM에게 전달
4. LLM이 응답 생성
* Retrieval: 저장된 벡터DB에서 프롬프트 벡터와 유사도가 높은 top k개 텍스트 추출
* 시간복잡도: O(log n) (헉..빠르다)
* Augmented: 추출된 텍스트를 context로 프롬프트 앞에 끼워넣기
* Generation : 문맥 + 질문을 포함하는 프롬프트에 대한 답변 생성
문서의 수가 많아지면 느려지는 게 맞다.
* 그래서 벡터DB 선택, indexing 방식, hardware infra가 중요하다.
* FAISS: CPU 기반, 빠르고 단순. 중소규모에 적합.
* Chroma, Weaviate: 실시간 대응 및 확장성에 유리.
* OpenSearch <- Elastic Search
* Pre-filtering (metadata filter) → 벡터 검색 → 프롬프트 구성: 속도 최적화 전략.
* 실무에서는 단순히 문서 다 넣고 “검색!”이 아니라, 도메인, 날짜, 문서 유형 등을 먼저 필터링하고, 벡터 검색은 그 후에 수행한다.

Q4. 사내에 있는 문서들을 미리 임베딩 후 벡터 DB에 넣어서 검색 속도를 높이고 싶습니다. 이럴 경우에는 벡터 DB를 띄워야할 것 같은데 실무에서는 어떻게 하고 있나요?

* 문서 전처리 및 임베딩 단계 (오프라인 작업)
* PDF, Word, Excel → 텍스트 추출
*
RecursiveCharacterTextSplitter
로 문서 분할
* Excel은 row, sheet별로 chunk를 하는 것이 효과적일 수 있음.
* github codebase의 경우에도, 파일, 클래스, 함수 단위로 chunking하는 것이 좋을 수 있음
* OpenAI 또는 local 모델로 임베딩
* 임베딩된 결과를 벡터 DB에 저장 (Chroma, FAISS 등)
* 이건 서비스 시작 전에 한 번 미리 돌려놓고 저장합니다. 실시간 아님.
* 서비스 운영 중
* Vector DB를 서버에 띄운 상태로 유지:
* 실무에선 보통 Docker로 띄우거나, AWS EC2 / GCP VM 등에 올려놓습니다.
* Chroma: 매우 가볍고 단일 서버에서 운영 가능
* Weaviate, Pinecone: Managed 서비스 or K8s 클러스터로 운영 가능

## 앞으로 작업할 프로젝트의 목표

나는 이번 AI 코스를 통해 이런 것들을 가져가고 싶다.

1. 프롬프트 엔지니어링 + RAG + openLLM 모델 파인튜닝 + LoRA + 양자화 등을 통해 하드웨어의 제약을 극복하고 비용을 절감하여 LLM 파이프라인을 구축하는 것.

2. 정량적인 성능 지표를 설정하여, 객관적인 성능 비교를 통해 LLM 모델의 퀄리티가 지속적으로 상향되는 것을 포트폴리오에 담기!

태스크별 평가 지표

* 텍스트 분류 – Accuracy, F-1
* 번역, 요약
* 정량평가 - ROUGE-L, BLEU
* 정성평가 - (open-ended) – GPT 평가 / 인간 평가
* test data가 1000개 있으면, chatGPT api로 1000번 (입력, 출력) 보내서 채점하게 하기
* 텍스트 생성 (채팅, 스토리) – Win rate / GPT preference
* 문서 검색 / RAG – MRR 또는 Recallk

주제의 참신함과 여러가지 기능 추가보다는 여러가지 프롬프팅 기법과 RAG로 다양한 경우의 수를 만들어내고, 성능을 비교하는 것에 초점을 맞출 것이다!

남은 3주 동안 화이팅!

#항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM #HuggingFace #Langchain 블로그에서 읽기 : https://velog.io/@soonmac/hh-plus-ai-week5 드디어 내가 가장 배우고 싶은 랭체인과 RAG 주차가 찾아왔다.5주차부터 프로젝트 제작을 위한 실무 지식들을 배운다.나는 랭체인과 RAG를 사용해서 도메인에 특화된 프로젝트를 진행하고 싶었다.그래서 논문 pdf를 주면 해당 논문에 대해 질의응답을 해주는 챗봇을 만들어보려고 한다. ## 🍀심화 과제 회고: Langchain과 RAG로 논문 요약 서비스 만들어보기 [깃헙 코드 보기](https://github.com/sosososoyoen/hh_plus_ai_3/tree/main/work/week5/%E1%84%89%E1%85%B5%E1%86%B7%E1%84%92%E1%85%AA)플로우는 대략적으로논문 pdf 파일을 받으면 pdf 내의 텍스트를 추출하여, 임베딩한 후 RAG의 벡터 DB에 담아두고 해당 논문의 요약본을 생성하는 서비스다.<pre ><code>from langchain.document_loaders import UnstructuredPDFLoader

loader = UnstructuredPDFLoader("./example.pdf")

docs = loader.load()

text_splitter = RecursiveCharacterTextSplitter(

chunk_size=1500,

chunk_overlap=200

)

splits = text_splitter.split_documents(docs)

vectorstore = Chroma.from_documents(

documents=splits,

embedding=OpenAIEmbeddings(api_key=api_key)

)</code></pre>나는 <code >UnstructuredPDFLoader</code>를 사용하여 pdf에서 텍스트를 추출하여 청크 사이즈를 1500, 오버랩을 200으로 맞추어 텍스트를 청킹했다. 그 다음엔 Chroma에 이를 임베딩하여 집어넣어줬는데.. 사실 여기까진 별 거 없었다. 테스트로 사용한 논문은 https://arxiv.org/pdf/2005.11401 RAG에 관한 논문이고내 파이프라인이 만들어낸 요약본은 아래와 같았다. (gpt-4o-mini) -------------------### 1. 논문의 목적이 논문의 목적은 RAG( retrieval-augmented generation) 모델을 통해 사실 추출 및 검증을 수행하는 새로운 접근 방식을 제시하는 것이다. 이를 통해 기존의 복잡한 파이프라인 시스템과 비교하여 단순성과 효율성을 강조한다. 특히, RAG는 도메인 특정 아키텍처나 중간 검색 감독 없이도 성능을 발휘할 수 있음을 보여준다.### 2. 주요 기여- 성능: RAG 모델은 3-way 분류에서 최첨단 모델과 비교했을 때 4.3% 내외의 성과를 보였다(§4.4, p.14).- 단순성: RAG는 복잡한 시스템 없이도 유효한 결과를 도출할 수 있는 능력을 지닌다.- 응용 가능성: 다양한 언어 모델의 기능을 접목하여 사실 기반의 대화형 응용 프로그램 개발에 기여할 수 있다.### 3. 사용된 방법론- 데이터셋: FEVER 데이터셋을 사용하여 모델 성능을 검증한다.- 모델 검증: RAG 모델의 성능을 3-way 분류로 평가하며, 복잡한 파이프라인 대비 단순한 구조를 강조한다(§4.4, p.14).- 정량적 결과: RAG 모델이 생성한 응답의 사실 정확성은 높은 비율로 유지되며, 특정 입력에 대해 더 정교한 응답을 낸다.### 4. 주요 결과- RAG 모델은 3-way 분류에서 정확도가 4.3% 떨어지는 성과를 보였으며, 이는 기존 방법론에 비해 우수한 수치를 나타낸다(§4.4, p.14).- 생성된 응답의 구체성과 사실 기반 정확성을 높여, 더 나은 대화형 AI의 기반을 마련한다.### 5. 한계 및 미래 연구 방향- 한계: RAG 모델의 데이터 기반이 외부 지식원(예: 위키피디아)의 완전한 사실성을 담보하지 않음으로 인해 생성된 콘텐츠의 신뢰성에 문제가 있을 수 있다(§4.4, p.14).- 미래 연구 방향: 다루기 어려운 또는 편향된 내용을 자동으로 생성하지 않도록 개선할 수 있는 AI 시스템의 개발 필요성; 다양한 언어의 지원 범위를 확대하여 모델의 효용성을 높이는 연구가 제안된다.-------------------------- 나는 내 서비스가 생성한 요약본을 ROUGE와 BertScore를 기준으로 평가했다.사용 모델 : gpt-4o-mini정답용 모델 : gpt-4o ### 🔷 ROUGE | 지표&nbsp; &nbsp; &nbsp; &nbsp; | 점수 &nbsp; | 설명 ||-------------|--------|------|| ROUGE-1 &nbsp; &nbsp; | 0.2543 | 단어 수준 유사도 || ROUGE-2 &nbsp; &nbsp; | 0.0702 | 2-gram 연속성 유사도 (문장 구성 구조) || ROUGE-L &nbsp; &nbsp; | 0.2197 | 문장 뼈대의 유사성 || ROUGE-Lsum&nbsp; | 0.2428 | 전체 요약 구조 유사성 | ### 🔷 BERTScore | 지표&nbsp; &nbsp; &nbsp; &nbsp; | 점수 &nbsp; | 설명 ||-------------|--------|------|| Precision &nbsp; | 0.7095 | 정답 요약 의미 중 포함된 비율 || Recall&nbsp; &nbsp; &nbsp; | 0.6887 | 내가 쓴 요약이 정답을 얼마나 커버했는지 || F1&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | 0.6990 | 의미 유사성 종합 점수 (사람 기준으로 매우 양호함) | 의미적으로는 핵심 내용을 잘 전달한 것 같으나,문장 구성 방식이나 표현 스타일은 논문 요약 스타일과 차이가 있어보인다.그리고, 출처를 적어달라했는데 얘가 출처를 제대로 못적는거 보면.. 아직 개선의 여지가 더 필요해 보인다. 다음 과제를 위한 액션 아이템 3가지를 잡아보았다.1. 프롬프트 수정&nbsp;&nbsp;&nbsp;&nbsp; → "논문 스타일로 학술적인 요약을 해줘" 같은 지시 문구 사용2. 예시 문장 추가&nbsp;&nbsp;&nbsp;&nbsp; → 학습 시 논문 스타일 예시 문장을 함께 제시3. 문단 단위 요약 후 통합&nbsp;&nbsp;&nbsp;&nbsp; → Recall + Precision 균형 잡기심화 과제를 진행하면서, 궁금했던 점들을 과제 QnA 섹션과 멘토링 시간 때 코치님들께 여쭤보았다.아래는 내가 한 질문들과 다른 분들이 질문해준 것 중에 나도 궁금했던 것들, 그리고 그 답변을 정리한 내용이다!나처럼 실무에 LLM을 적용해야하는 사람들에게 도움이 됐으면 좋겠다. ## 🌼과제 QnA 섹션 정리 Q1. 요약 텍스트 생성 평가 지표 : ROUGE vs BertScore 어느 쪽이 더 좋을까요? A.ROUGE* 전통적인 요약 태스크 평가 지표* 정답과 모델이 예측한 요약을 갖고, 레퍼런스 요약 간의 겹치는 토큰 비율을 측정한다.* 여러 LLM 간의 상대 비교에 유용하다. (=어느 모델이 더 좋은지 체크 가능)BertScore* 의미적 유사도 평가* ROUGE와 달리 어휘가 달라도 유사한 문맥을 포착하기 때문에 점수가 높게 나올 수 있다.=&gt; 보통은 ROUGE, BertScore, GPT4 평가(LLM-as-a-Judge) 결과를 결합하여 최종 점수를 산출하는 방식으로 진행한다.Q2. 한국어 텍스트를 평가할 때 중간에 영어로 번역 후 평가를 하는 것이 좋을까요? A.번역 품질이 낮으면 평가가 왜곡될 위험성이 많다. Q3. OpenAI API 서버 불안정 시 대응 전략 A.인하우스 LLM 대체 (오픈소스 LLM 파인튜닝)* 규모가 큰 서비스의 경우, 오픈소스 LLM을 튜닝하는 방식으로 내재화를 많이 고려한다.* 기존에 OpenAI API를 쓰고 있던 서비스라면 그 동안 쌓인 데이터를 통해 오픈소스 LLM을 튜닝하고,* 모듈, 기능을 하나씩 대체하는 방식으로 진행한다.Multi-LLM* OpenAI 뿐만 아니라 Gemini, Claude 등 여러 api를 구성하여 한 쪽 모델에서 응답 실패 시 다음 모델로 전환하는 방식을 채택하기도 한다.LLM 라우터* 모든 기능에서 OpenAI를 쓰는 것은 가성비가 좋지 않기 때문에 LLM 라우터를 통해 쿼리 유형별로 최적의 모델을 라우팅한다. 질문 외 추가 팁* RouteLLM - 프로젝트에 이런 오케스트레이션도 넣으면 좋지 않을까 싶다.https://github.com/lm-sys/RouteLLM* RAG 설계* 모든 문서를 벡터 스토어에 넣기 어렵다면, 핵심 페이지만 선택적으로 저장하라* 프롬프트 엔지니어링이나 function calling 등 LLM 관련 지식들이 모여있는 블로그https://devocean.sk.com/blog/techBoardDetail.do?ID=165806&amp;boardType=techBlog* Outlines 라이브러리* https://github.com/dottxt-ai/outlines* LLM의 응답을 파싱해준다. 숫자만 추출하거나 json 포맷을 맞추기에 편해보임.* 논문을 기반으로 질의응답을 해주는 챗봇 튜토리얼* https://github.com/liner-engineering/liner-pdf-chat-tutorial ## 🌻멘토링 노트 정리 Q1. RecursiveCharacterTextSplitter에서 텍스트를 청크로 분할할 때 overlap하는 이유에 대해 궁금합니다. A1.* 만약 문서를 청크 단위로 완전히 잘라버리면, 문단의 앞뒤 맥락이 끊겨 의미 파악이 어려워진다.* 어떤 설명이 문단 A 끝 + 문단 B 시작에 걸쳐 있을 경우, 완전히 분리되면 의미를 놓치게 됨.* 오버랩 안한 chunk의 경우```일론 머스크 테슬라 최고경영자(CEO)가 자사 휴머노이드 로봇 '옵티머스'의 생산이 중국의 희토류 수출 규제로 타격을 입었다고 밝혔다. 테슬라는 중 국 정부와 협의를 진행 중이며, 관련 자원 접근을 위한 승인 절차를 밟고 있다고 덧붙였다.```* '옵티머스'가 '옵'과 '티머스'로 분리되어서 옵티머스에 대해 물어보면 제대로 된 답변이 생성안될 가능성이 높다. Q2. open ai의 서버 상태가 불안정해져서 gpt를 사용할 수 없을 때엔 어떻게 하는 것이 좋을까요?(QnA 섹션 때와 같은 질문을 했다.) A2.* 대부분의 회사들은 openLLM을 도입하려고 한다. LLM 서비스 전부를 openLLM으로 사용하거나, 일부 기능만 chatGPT를 사용하는 형태로 운영함.* 1. 완전 자립* Open LLM만 사용하여 API 의존성을 완전히 제거* 2. 하이브리드* 핵심 기능에는 GPT API를 쓰되, 부가 기능 또는 fallback 용도로는 Open LLM을 사용* 장점* api 비용 없음, 보안 이슈 없음(자체 서버에서 가능), api 서버 의존성 이슈 없음* 단점* 초기비용 큼(gpu 인프라) 또는 클라우드비용 증가, 상대적으로 낮은 성능-&gt;인력을 통해 개선을 시켜야함 (프롬프트 엔지니어링, RAG, 튜닝)chatGPT 크기: 1000B이상openLLM 중에 큰 것들 700B -&gt; GPU인프라 비용 최소 20억 이상* Ollama를 통해 openLLM 활용할 때 적합한 것: 7B짜리* 회사 내부 문서가지고 답변하는 것* RAG -프롬프팅, 튜닝이 많이 필요 Q3. RAG의 동작방식에 대해: 유저의 입력 → 모든 벡터 DB의 문서들의 임베딩 유사도를 체크 → 가장 유사도가 높은 문서를 가져와서 프롬프트에 얹는다. 이 방식이 맞을까요? 맞다면 문서의 양이 많아질 수록 검색속도가 느려지지 않을까요? A3.ㅇㅇ 더 자세하게 말씀드리자면 아래와 같다.1. 유저 질문을 입력2. 입력을 임베딩하여 쿼리 벡터 생성3. 벡터 DB (예: FAISS, Chroma, Weaviate 등)에서 유사도가 높은 문서 top-k를 검색 -&gt; 검색된 문서들을 프롬프트에 넣어 LLM에게 전달4. LLM이 응답 생성* Retrieval: 저장된 벡터DB에서 프롬프트 벡터와 유사도가 높은 top k개 텍스트 추출* 시간복잡도: O(log n) (헉..빠르다)* Augmented: 추출된 텍스트를 context로 프롬프트 앞에 끼워넣기* Generation : 문맥 + 질문을 포함하는 프롬프트에 대한 답변 생성문서의 수가 많아지면 느려지는 게 맞다.* 그래서 벡터DB 선택, indexing 방식, hardware infra가 중요하다.* FAISS: CPU 기반, 빠르고 단순. 중소규모에 적합.* Chroma, Weaviate: 실시간 대응 및 확장성에 유리.* OpenSearch &lt;- Elastic Search* Pre-filtering (metadata filter) → 벡터 검색 → 프롬프트 구성: 속도 최적화 전략.* 실무에서는 단순히 문서 다 넣고 “검색!”이 아니라, 도메인, 날짜, 문서 유형 등을 먼저 필터링하고, 벡터 검색은 그 후에 수행한다. Q4. 사내에 있는 문서들을 미리 임베딩 후 벡터 DB에 넣어서 검색 속도를 높이고 싶습니다. 이럴 경우에는 벡터 DB를 띄워야할 것 같은데 실무에서는 어떻게 하고 있나요? * 문서 전처리 및 임베딩 단계 (오프라인 작업)* PDF, Word, Excel → 텍스트 추출* <code >RecursiveCharacterTextSplitter</code>로 문서 분할* Excel은 row, sheet별로 chunk를 하는 것이 효과적일 수 있음.* github codebase의 경우에도, 파일, 클래스, 함수 단위로 chunking하는 것이 좋을 수 있음* OpenAI 또는 local 모델로 임베딩* 임베딩된 결과를 벡터 DB에 저장 (Chroma, FAISS 등)* 이건 서비스 시작 전에 한 번 미리 돌려놓고 저장합니다. 실시간 아님.* 서비스 운영 중* Vector DB를 서버에 띄운 상태로 유지:* 실무에선 보통 Docker로 띄우거나, AWS EC2 / GCP VM 등에 올려놓습니다.* Chroma: 매우 가볍고 단일 서버에서 운영 가능* Weaviate, Pinecone: Managed 서비스 or K8s 클러스터로 운영 가능 ## 앞으로 작업할 프로젝트의 목표 나는 이번 AI 코스를 통해 이런 것들을 가져가고 싶다. 1. 프롬프트 엔지니어링 + RAG + openLLM 모델 파인튜닝 + LoRA + 양자화 등을 통해 하드웨어의 제약을 극복하고 비용을 절감하여 LLM 파이프라인을 구축하는 것. 2. 정량적인 성능 지표를 설정하여, 객관적인 성능 비교를 통해 LLM 모델의 퀄리티가 지속적으로 상향되는 것을 포트폴리오에 담기! 태스크별 평가 지표 * 텍스트 분류 – Accuracy, F-1* 번역, 요약* 정량평가 - ROUGE-L, BLEU* 정성평가 - (open-ended) – GPT 평가 / 인간 평가* test data가 1000개 있으면, chatGPT api로 1000번 (입력, 출력) 보내서 채점하게 하기* 텍스트 생성 (채팅, 스토리) – Win rate / GPT preference* 문서 검색 / RAG – MRR 또는 Recallk 주제의 참신함과 여러가지 기능 추가보다는 여러가지 프롬프팅 기법과 RAG로 다양한 경우의 수를 만들어내고, 성능을 비교하는 것에 초점을 맞출 것이다! 남은 3주 동안 화이팅!

항해플러스 AI 후기(5주차) - RAG로 논문 요약하기

블로그에서 이미지와 함께 보기 : https://velog.io/@soonmac/hh-plus-ai-week4

드디어 4주차부터 본격적으로 허깅페이스의 Trainer을 사용한다.
이번 주차부터 실습 위주라서 앞으로는 내가 진행한 과제를 위주로 WIL를 작성할 것 같다.

## 기본 과제 맛보기 : HuggingFace로 MNLI 문제 해결하기

지난주 과제로 파이토치로 BERT 모델을 학습시켜서 MNLI 문제를 해결했었는데 이 코드를 그대로 허깅페이스 라이브러리로 옮기는 것이 이번 주의 기본 과제였다.
자세한 코드는 아래에서 확인할 수 있다.

https://github.com/sosososoyoen/hh_plus_ai_3/blob/main/work/week4/%EA%B8%B0%EB%B3%B8/MNLI_HF_transformer.ipynb

### Multi-genre natural language inference(MNLI)란?

* 두 문장이 주어졌을 때 논리적으로 연결이 되어 있는지, 서로 모순되는지, 아니면 아예 무관한지 분류하는 문제!
*
MNLI 데이터 셋의 구성요소
* 모델 학습에 필요한 '전제, 가설, 라벨' 형태로 가공한다.
* premise (전제) hypothesis (가설) labels (라벨)
*
✅ 라벨의 종류
* 함의(Entailment): 전제가 가설을 지 지하는 경우. -> 0
* 중립(Neutral): 전제가 가설에 대해 중립적이거나 관련이 없는 경우. -> 1
* 모순(Contradiction): 전제가 가설과 모순되는 경우. -> 2
저번 주에 다른 수강생 분들이 과제를 진행한 것을 보니까, 데이터를 멋드러지게 dataframe으로 출력해서 체크를 하시길래... 이번 과제에서는 나도 데이터를 잘 정리하고 시각화 하는 것에 중점을 맞추었다.
![Pasted image 20250420232900](https://github.com/user-attachments/assets/b83d551c-f18a-413a-97bb-dbe4ba60b37d)

## 데이터 전처리에 따른 학습 모델 평가 비교

## 토크나이저를 활용하여 전제와 가설 문장들을 연결해서 학습시켰을 경우

tokenizer = AutoTokenizer.from_pretrained("bert-base-cased") 
# 전처리 함수 정의 
def preprocess_function(examples): 
	return tokenizer( examples["premise"], examples["hypothesis"], 
	truncation=True, padding="longest", )

- BERT 계열의 토크나이저는 문장쌍까지만 구조적으로 구분 가능 => premise, hypothesis 문장 따로 전달
tokenizer(

    text = "문장1",              # 또는

    text_pair = "문장2",         # 문장쌍일 때

    truncation = True,           # 너무 길면 자름

    padding = "longest",         # 가장 긴 입력의 길이에 맞춰서 패딩 토큰을 자동으로 채워줌

    max_length = 128,            # 최대 길이

    return_tensors = "pt"        # torch 텐서로 반환 (선택)

)

-
[CLS] premise [SEP] hypothesis [SEP]
 구조를 사용하기로 함
- token_type_ids(문장을 구분해주는 인덱스)을 통해 모델이 문장을 쉽게 분리할 수 있도록 처리
[7365/7365 21:08, Epoch 3/3]
| Epoch | Training Loss | Validation Loss | Accuracy | F1 |
| ----- | ------------- | --------------- | -------- | -------- |
| 1 | 0.866200 | 0.868188 | 0.603328 | 0.594561 |
| 2 | 0.796400 | 0.844906 | 0.624222 | 0.624192 |
| 3 | 0.732300 | 0.867255 | 0.623738 | 0.623072 |
Out[54]:
TrainOutput(global_step=7365, training_loss=0.7982978111210115, metrics={'train_runtime': 1268.5338, 'train_samples_per_second': 742.97, 'train_steps_per_second': 5.806, 'total_flos': 130220993318850.0, 'train_loss': 0.7982978111210115, 'epoch': 3.0})

## 스페셜 토큰 없이 전제와 가설을 이어서 한 문장으로 만들어서 학습 시켰을 경우

def preprocess_function(data):

    text = []

    for i in range(len(data['premise'])):

        text.append(data['premise'][i] + data['hypothesis'][i])

    return tokenizer(text, truncation=True)

| Epoch | Training Loss | Validation Loss | Accuracy | F1 |
| ----- | ------------- | --------------- | -------- | -------- |
| 1 | 0.932600 | 0.958541 | 0.527903 | 0.530360 |
| 2 | 0.899600 | 0.951936 | 0.532397 | 0.533510 |
| 3 | 0.852900 | 0.969038 | 0.533938 | 0.534887 |
TrainOutput(global_step=7365, training_loss=0.8950229787211473, metrics={'train_runtime': 354.5992, 'train_samples_per_second': 2657.882, 'train_steps_per_second': 20.77, 'total_flos': 39329901033570.0, 'train_loss': 0.8950229787211473, 'epoch': 3.0}

![output (1)](https://github.com/user-attachments/assets/69dea599-470d-48cb-a1c5-75e7fb987d35)

정확도가 약 10% 정도 상승한 것을 확인할 수 있었다.
이렇게 된 이유에는 BERT의 구조 때문인데,
BERT 자체가 문장 중간에 [SEP]토큰을 경계로 두고, self-attention으로 문장을 분석하고 학습하기 때문이다.

## 과제 Q&A 섹션

매주 평일 저녁, 그 주 발제를 맡으신 코치님이 직접 Q&A 세션을 진행하신다.
지금까지 시간이 맞지 않아서 4주차에 드디어 첫 참석을 하게 되었다.
세션 시작 전 구글폼으로 익명 질문을 받는데, 익명이니 사소한 질문들도 부담 없이 물어볼 수 있었다ㅋㅋㅋ
코치님이 질문 하나하나 열심히 답해주셔서 좋았음.
코치님이 마지막에 조언을 해주셨다.
✨ 좋은 AI 개발의 근본 = 끊임 없는 비교 실험을 통한 모델 개선 + 비용 절감! ✨
그래서 나도 곧 있을 개인 프로젝트에 랭체인과 RAG를 적극 활용하여서 가성비 있는 AI 서비스를 구축해보고자 한다.
아래에 내가 한 질문들과 답변을 정리해보았다.

질문 1.
기본 과제에서 Trainer 사용해서 학습하면 wandb 로그인하라고 뜨는데, 혹시 실무에서는 wandb가 필수일까요?

A.
네 wandb나 mlflow같은 실험 관리 도구는 실무에서 거의 필수다 싶을 정도로 매우 유용한 실험 도구입니다.
모델 하나의 학습 양상 뿐만 아니라 여러 설정 값(hyperparameter)에 따른 모델들의 성능도 직관적으로 확인할 수 있고, 수 백 개의 실험 중 가장 좋은 세팅을 찾아내는 데도 유용합니다.

질문 2.
허깅페이스의 evaluate에서 f1는 뭘 평가하는 것일까요?

A.
* f1 score는 recall(민감도)과 precision(정밀도) 의 조화 평균 값입니다.
* 문제 예시: 환자 정보를 보고 암인지 아닌지 분류하는 문제
* 모델: 암이면 1, 아니면 0을 출력 전체 환자 1000명, 암 환자 100명
* recall: 모델이 예측한 실제 암 환자 수 / 전체 암 환자 recall이 60%다 = 실제 암 환자 100명 중에 60명은 예측했다. recall을 100%로 만드는 방법? 모든 환자를 암 환자라고 예측하면 됩니다.
* precision: 모델이 예측한 실제 암 환자 수 / 모델이 암이라고 예측한 환자 수 recall을 100%면? precision의 분모가 1000, 분자가 100, -> 10% -> recall(민감도)이 증가하면, precision은 감소하는 경향이 있음. 이 두 개를 조화롭게 보면서 모델의 성능을 판단하기 위해 -> 이걸 조화 평균을 해서 f-1 score라는 게 만들어짐

추가 질문!
정확도보다 f1이 더 신뢰 가는 평가 기준일까요?

A.
* 정확도=accuracy=실제 라벨값과 예측한 라벨값의 일치도
* 근데 문제는 데이터가 불균형하면 정확도가 의마가 없음
* 전체 환자 1000명, 암 환자 10명 모델이 모든 환자를 암이 아니라고 예측 -> 정확도 99% (1000명 중에 990명은 맞혔으니까)
* 이러한 단점을 보완하기 위해 정밀도, 민감도, 특이도 등 다양한 지표 사용 Confusion Matrix 개념을 완벽히 이해하면, 데이터 분석/모델 평가에 있어 새로운 시각을 얻을 수 있습니다.
* -> 여기서 더 나아가면, AUROC, AUPRC

질문 3.
BERT를 학습시켰는데 이후에 데이터셋의 label 값들이 잘못되었다는 것을 알게 되었다면, 어떻게 해야 하나요?

A.
- Manual re-labeling: 직접 확인 후 수정
* 첫 모델 학습 후, 모델이 잘 틀리는 데이터들만 모아서 분석
* 라벨이 1인데, 모델 예측이 0.01 이런 경우 -> 데이터를 직접 보면서 라벨이 실제로 잘못된건지 확인
* -> 하나하나 전부 볼 수는 없으니, 이러한 데이터들의 특성, 통계적인 경향성을 분석해서, 모델의 학습이 잘못된 건지, 데이터가 이상한 건지 판단이 필요
* re-labeling 하거나, 학습/평가에서 제외 시켜야 함
* 애매한 경우라면 soft-labeling

질문4.
만일 프롬프트의 길이가 너무 길어지는 경우에는 어떻게 해야하나요?

A.
* 너무 길다면 프롬프트를 chunking 후 각 청크를 langchain의 load_summarize_chain과 같은 함수를 활용해서 요약할 수 있습니다.
* 코드 예시:
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(

chunk_size=1000,

chunk_overlap=100,

)

chunks = splitter.split_text(very_long_document)

# 각 Chunk 요약

from langchain.chains.summarize import load_summarize_chain

chain = load_summarize_chain(llm, chain_type="map_reduce")

summary = chain.run(chunks)

prompt = PromptTemplate(

input_variables=["summary"],

template="""

다음은 보고서의 요약입니다:

{summary}

이 요약을 바탕으로 독자가 궁금해할 수 있는 질문 5개를 생성하세요.

"""

)

llm_chain = LLMChain(llm=llm, prompt=prompt)

questions = llm_chain.run(summary)

질문 5.
만약에 챗봇서비스를 만드는데 정답이 분명하지않다, 라고 하면 어떻게 성능을 평가할 수 있을까요?? 예를들면 상담을 해주거나, 추천을 해주는 경우에요!

A.
* 기존에 동일한 서비스를 하고 있는데, 이걸 LLM으로 대체하는 경우는 상담만족도/구매내역 같은 데이터가 있기 때문에, 이걸로 학습/평가 같은게 가능 (새로운 데이터가 입력되더라도, 기존 데이터에 비슷한 데이터 찾아서(retrieval) 라벨링 가능)
* 우리가 새로운 서비를 만들 때 -> chatGPT 4o generation, labeling -Human Feedback으로 보상 설정 (추천결과에 대해 유저가 직접 scoring)
* 프로젝트 시작하는 시점에서 가장 중요한것
* 내 LLM 모델의 성능을 평가하는 지표 설정 (어떻게 평가해야 하나?)

## 마치며
4주차는 3주차에 비해 과제에 좀 더 집중할 수 있어서, 데이터 전처리에 대해 고민도 해보고, 데이터 분석하는 방식에 대해 많이 고민해보았다. (이 글에서는 데이터 분석에 대한 내용은 없지만 추후에 다른 포스트로 올릴 예정임)
5주차부터는 본격적으로 LLM 서비스 프로젝트를 위한 초읽기에 들어갈텐데, 부디 무사히 잘 완성할 수 있길 바란다ㅎㅎ
#항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM

블로그에서 이미지와 함께 보기 : https://velog.io/@soonmac/hh-plus-ai-week4 드디어 4주차부터 본격적으로 허깅페이스의 Trainer을 사용한다.이번 주차부터 실습 위주라서 앞으로는 내가 진행한 과제를 위주로 WIL를 작성할 것 같다. ## 기본 과제 맛보기 : HuggingFace로 MNLI 문제 해결하기 지난주 과제로 파이토치로 BERT 모델을 학습시켜서 MNLI 문제를 해결했었는데 이 코드를 그대로 허깅페이스 라이브러리로 옮기는 것이 이번 주의 기본 과제였다.자세한 코드는 아래에서 확인할 수 있다. https://github.com/sosososoyoen/hh_plus_ai_3/blob/main/work/week4/%EA%B8%B0%EB%B3%B8/MNLI_HF_transformer.ipynb ### Multi-genre natural language inference(MNLI)란? * 두 문장이 주어졌을 때 논리적으로 연결이 되어 있는지, 서로 모순되는지, 아니면 아예 무관한지 분류하는 문제!*MNLI 데이터 셋의 구성요소* 모델 학습에 필요한 '전제, 가설, 라벨' 형태로 가공한다.* premise (전제) hypothesis (가설) labels (라벨)*✅ 라벨의 종류* 함의(Entailment): 전제가 가설을 지 지하는 경우.​ -&gt; 0* 중립(Neutral): 전제가 가설에 대해 중립적이거나 관련이 없는 경우. -&gt; 1* 모순(Contradiction): 전제가 가설과 모순되는 경우.​ -&gt; 2저번 주에 다른 수강생 분들이 과제를 진행한 것을 보니까, 데이터를 멋드러지게 dataframe으로 출력해서 체크를 하시길래... 이번 과제에서는 나도 데이터를 잘 정리하고 시각화 하는 것에 중점을 맞추었다.![Pasted image 20250420232900](https://github.com/user-attachments/assets/b83d551c-f18a-413a-97bb-dbe4ba60b37d) ## 데이터 전처리에 따른 학습 모델 평가 비교 ## 토크나이저를 활용하여 전제와 가설 문장들을 연결해서 학습시켰을 경우 <pre ><code>tokenizer = AutoTokenizer.from_pretrained("bert-base-cased") 
# 전처리 함수 정의 
def preprocess_function(examples): 
	return tokenizer( examples["premise"], examples["hypothesis"], 
	truncation=True, padding="longest", )</code></pre>- BERT 계열의 토크나이저는 문장쌍까지만 구조적으로 구분 가능 =&gt; premise, hypothesis 문장 따로 전달<pre ><code>tokenizer(

 text = "문장1", # 또는

 text_pair = "문장2", # 문장쌍일 때

 truncation = True, # 너무 길면 자름

 padding = "longest", # 가장 긴 입력의 길이에 맞춰서 패딩 토큰을 자동으로 채워줌

 max_length = 128, # 최대 길이

 return_tensors = "pt" # torch 텐서로 반환 (선택)

)</code></pre>- <code >[CLS] premise [SEP] hypothesis [SEP]</code>&nbsp;구조를 사용하기로 함- token_type_ids(문장을 구분해주는 인덱스)을 통해 모델이 문장을 쉽게 분리할 수 있도록 처리[7365/7365 21:08, Epoch 3/3]| Epoch | Training Loss | Validation Loss | Accuracy | F1 || ----- | ------------- | --------------- | -------- | -------- || 1 | 0.866200 | 0.868188 | 0.603328 | 0.594561 || 2 | 0.796400 | 0.844906 | 0.624222 | 0.624192 || 3 | 0.732300 | 0.867255 | 0.623738 | 0.623072 |Out[54]:TrainOutput(global_step=7365, training_loss=0.7982978111210115, metrics={'train_runtime': 1268.5338, 'train_samples_per_second': 742.97, 'train_steps_per_second': 5.806, 'total_flos': 130220993318850.0, 'train_loss': 0.7982978111210115, 'epoch': 3.0}) ## 스페셜 토큰 없이 전제와 가설을 이어서 한 문장으로 만들어서 학습 시켰을 경우 <pre ><code>def preprocess_function(data):

&nbsp; &nbsp; text = []

&nbsp; &nbsp; for i in range(len(data['premise'])):

&nbsp; &nbsp; &nbsp; &nbsp; text.append(data['premise'][i] + data['hypothesis'][i])

&nbsp; &nbsp; return tokenizer(text, truncation=True)</code></pre> | Epoch | Training Loss | Validation Loss | Accuracy | F1 || ----- | ------------- | --------------- | -------- | -------- || 1 | 0.932600 | 0.958541 | 0.527903 | 0.530360 || 2 | 0.899600 | 0.951936 | 0.532397 | 0.533510 || 3 | 0.852900 | 0.969038 | 0.533938 | 0.534887 |TrainOutput(global_step=7365, training_loss=0.8950229787211473, metrics={'train_runtime': 354.5992, 'train_samples_per_second': 2657.882, 'train_steps_per_second': 20.77, 'total_flos': 39329901033570.0, 'train_loss': 0.8950229787211473, 'epoch': 3.0} ![output (1)](https://github.com/user-attachments/assets/69dea599-470d-48cb-a1c5-75e7fb987d35) 정확도가 약 10% 정도 상승한 것을 확인할 수 있었다.이렇게 된 이유에는 BERT의 구조 때문인데,BERT 자체가 문장 중간에 [SEP]토큰을 경계로 두고, self-attention으로 문장을 분석하고 학습하기 때문이다. ## 과제 Q&amp;A 섹션 매주 평일 저녁, 그 주 발제를 맡으신 코치님이 직접 Q&amp;A 세션을 진행하신다.지금까지 시간이 맞지 않아서 4주차에 드디어 첫 참석을 하게 되었다.세션 시작 전 구글폼으로 익명 질문을 받는데, 익명이니 사소한 질문들도 부담 없이 물어볼 수 있었다ㅋㅋㅋ코치님이 질문 하나하나 열심히 답해주셔서 좋았음.코치님이 마지막에 조언을 해주셨다.✨ 좋은 AI 개발의 근본 = 끊임 없는 비교 실험을 통한 모델 개선 + 비용 절감! ✨그래서 나도 곧 있을 개인 프로젝트에 랭체인과 RAG를 적극 활용하여서 가성비 있는 AI 서비스를 구축해보고자 한다.아래에 내가 한 질문들과 답변을 정리해보았다. 질문 1.기본 과제에서 Trainer 사용해서 학습하면 wandb 로그인하라고 뜨는데, 혹시 실무에서는 wandb가 필수일까요? A.네 wandb나 mlflow같은 실험 관리 도구는 실무에서 거의 필수다 싶을 정도로 매우 유용한 실험 도구입니다.모델 하나의 학습 양상 뿐만 아니라 여러 설정 값(hyperparameter)에 따른 모델들의 성능도 직관적으로 확인할 수 있고, 수 백 개의 실험 중 가장 좋은 세팅을 찾아내는 데도 유용합니다. 질문 2.허깅페이스의 evaluate에서 f1는 뭘 평가하는 것일까요? A.* f1 score는 recall(민감도)과 precision(정밀도) 의 조화 평균 값입니다.* 문제 예시: 환자 정보를 보고 암인지 아닌지 분류하는 문제* 모델: 암이면 1, 아니면 0을 출력 전체 환자 1000명, 암 환자 100명* recall: 모델이 예측한 실제 암 환자 수 / 전체 암 환자 recall이 60%다 = 실제 암 환자 100명 중에 60명은 예측했다. recall을 100%로 만드는 방법? 모든 환자를 암 환자라고 예측하면 됩니다.* precision: 모델이 예측한 실제 암 환자 수 / 모델이 암이라고 예측한 환자 수 recall을 100%면? precision의 분모가 1000, 분자가 100, -&gt; 10% -&gt; recall(민감도)이 증가하면, precision은 감소하는 경향이 있음. 이 두 개를 조화롭게 보면서 모델의 성능을 판단하기 위해 -&gt; 이걸 조화 평균을 해서 f-1 score라는 게 만들어짐 추가 질문!정확도보다 f1이 더 신뢰 가는 평가 기준일까요? A.* 정확도=accuracy=실제 라벨값과 예측한 라벨값의 일치도* 근데 문제는 데이터가 불균형하면 정확도가 의마가 없음* 전체 환자 1000명, 암 환자 10명 모델이 모든 환자를 암이 아니라고 예측 -&gt; 정확도 99% (1000명 중에 990명은 맞혔으니까)* 이러한 단점을 보완하기 위해 정밀도, 민감도, 특이도 등 다양한 지표 사용 Confusion Matrix 개념을 완벽히 이해하면, 데이터 분석/모델 평가에 있어 새로운 시각을 얻을 수 있습니다.* -&gt; 여기서 더 나아가면, AUROC, AUPRC 질문 3.BERT를 학습시켰는데 이후에 데이터셋의 label 값들이 잘못되었다는 것을 알게 되었다면, 어떻게 해야 하나요? A.- Manual re-labeling: 직접 확인 후 수정* 첫 모델 학습 후, 모델이 잘 틀리는 데이터들만 모아서 분석* 라벨이 1인데, 모델 예측이 0.01 이런 경우 -&gt; 데이터를 직접 보면서 라벨이 실제로 잘못된건지 확인* -&gt; 하나하나 전부 볼 수는 없으니, 이러한 데이터들의 특성, 통계적인 경향성을 분석해서, 모델의 학습이 잘못된 건지, 데이터가 이상한 건지 판단이 필요* re-labeling 하거나, 학습/평가에서 제외 시켜야 함* 애매한 경우라면 soft-labeling 질문4.만일 프롬프트의 길이가 너무 길어지는 경우에는 어떻게 해야하나요? A.* 너무 길다면 프롬프트를 chunking 후 각 청크를 langchain의 load_summarize_chain과 같은 함수를 활용해서 요약할 수 있습니다.* 코드 예시:<pre ><code>from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(

chunk_size=1000,

chunk_overlap=100,

)

chunks = splitter.split_text(very_long_document)

# 각 Chunk 요약

from langchain.chains.summarize import load_summarize_chain

chain = load_summarize_chain(llm, chain_type="map_reduce")

summary = chain.run(chunks)

prompt = PromptTemplate(

input_variables=["summary"],

template="""

다음은 보고서의 요약입니다:

{summary}

이 요약을 바탕으로 독자가 궁금해할 수 있는 질문 5개를 생성하세요.

"""

)

llm_chain = LLMChain(llm=llm, prompt=prompt)

questions = llm_chain.run(summary)</code></pre> 질문 5.만약에 챗봇서비스를 만드는데 정답이 분명하지않다, 라고 하면 어떻게 성능을 평가할 수 있을까요?? 예를들면 상담을 해주거나, 추천을 해주는 경우에요! A.* 기존에 동일한 서비스를 하고 있는데, 이걸 LLM으로 대체하는 경우는 상담만족도/구매내역 같은 데이터가 있기 때문에, 이걸로 학습/평가 같은게 가능 (새로운 데이터가 입력되더라도, 기존 데이터에 비슷한 데이터 찾아서(retrieval) 라벨링 가능)* 우리가 새로운 서비를 만들 때 -&gt; chatGPT 4o generation, labeling -Human Feedback으로 보상 설정 (추천결과에 대해 유저가 직접 scoring)* 프로젝트 시작하는 시점에서 가장 중요한것* 내 LLM 모델의 성능을 평가하는 지표 설정 (어떻게 평가해야 하나?) ## 마치며4주차는 3주차에 비해 과제에 좀 더 집중할 수 있어서, 데이터 전처리에 대해 고민도 해보고, 데이터 분석하는 방식에 대해 많이 고민해보았다. (이 글에서는 데이터 분석에 대한 내용은 없지만 추후에 다른 포스트로 올릴 예정임)5주차부터는 본격적으로 LLM 서비스 프로젝트를 위한 초읽기에 들어갈텐데, 부디 무사히 잘 완성할 수 있길 바란다ㅎㅎ#항해99 #항해플러스 #AI #AI개발자 #항해플러스AI후기 #LLM

항해플러스 AI 후기(4주차) - HuggingFace로 MNLI 해결

I recently received a job offer from one of FAANG. Here are some problems to help me pass the coding interview. Categories are LinkedList Stack Heap, PriorityQueue HashMap Graph, BFS, DFS Tree, BT, BST Sort Dynamic Programming Binary search Recursion Slid

60 LeetCode questions to prepare for coding interview

많은 회사들이 채용 프로세스의 과정 중에 하나로 코딩 테스트를 가지고 있습니다. 벼락치기로 준비하기도 힘들 뿐더러 요령을 알아야 하기 때문에 취준생들이 꽤나 골치아파 합니다. 

뻔한 말이지만 꾸준히 하는 것 밖에는 답이 없는 것 같습니다. 오늘은 '코딩 인터뷰를 위한 60가지 리트코드 문제'를 가져왔습니다. 

구글 시트로 깔끔하게 정리된 버전도 있어서 후다닥 가져왔습니다. 저자에게 감사를(_ _)
https://docs.google.com/spreadsheets/d/1Y98QKaYPazWImEt1nA_ocpGNJ-yQjH1FAsVQhUQ7OTw/edit#gid=0

📌 LinkedList

- Linked List Cycle 
- Linked List Cycle II
- Remove Duplicates from Sorted List
- Remove Duplicates from Sorted List II
- Add Two Numbers

📌 Stack

- Valid Parentheses
- Reverse Linked List

📌 Heap, PriorityQueue

- Kth Largest Element in a Stream
- Top K Frequent Elements
- Find K Pairs with Smallest Sums

📌 HashMap

- Two Sum
- Group Anagrams
- Intersection of Two Arrays
- Unique Email Addresses
- First Unique Character in a String
- Subarray Sum Equals K

📌 Graph, BFS, DFS

- Number of Islands
- Max Area of Island
- Number of Connected Components in an Undirected Graph
- Word Ladder

📌 Tree, BT, BST

- Maximum Depth of Binary Tree
- Minimum Depth of Binary Tree
- Merge Two Binary Trees
- Convert Sorted Array to Binary Search Tree
- Path Sum
- Binary Tree Level Order Traversal
- Binary Tree Zigzag Level Order Traversal
- Validate Binary Search Tree
- Construct Binary Tree from Preorder and Inorder Traversal

📌 Sort

- Sorting Algorithms Animations 
https://www.toptal.com/developers/sorting-algorithms

📌 Dynamic Programming(DP)

- Paint Fence
- Longest Increasing Subsequence 
- Maximum Subarray
- Unique Paths
- Unique Paths II 
- House Robber
- House Robber II
- Best Time to Buy and Sell Stock
- Best Time to Buy and Sell Stock II
- Word Break
- Coin Change

📌 Binary Search

- Search Insert Position
- Find Minimum in Rotated Sorted Array
- Search in Rotated Sorted Array
- Capacity To Ship Packages Within D Days

📌 Recursion

- Pow(x, n)
- K-th Symbol in Grammar
- Split BST

📌 Sliding Window

- Longest Substring Without Repeating Characters
- Minimum Size Subarray Sum

📌 Greedy + Backtracking 

- Permutations
- Subsets
- Combination Sum
- Generate Parentheses

📌 Others

- Move Zeroes
- Meeting Rooms
- Meeting Rooms II
- Is Subsequence
- Next Permutation
- String to Integer (atoi)
- ZigZag Conversion

🐣 문제가 깔끔해서 개인적으로 좋아하는 사이트입니다.
🐣 하나씩 도장깨기 해보자구요.

Medium

🕊️ 코딩테스트를 위한 리트코드 60

카카오에 처음 들어가서 놀랐던 또 한 가지는 장애를 공유하는 문화였습니다.

개발자의 장애 공유 문화

카카오에 처음 들어가서 놀랐던 또 한 가지는 장애를 공유하는 문화였습니다.

작고 큰 장애들이 자주 발생했습니다.
장애가 발생하면 즉시 전파하고, 원인을 파악하고 후속 대응까지 실시간으로 공유했습니다.
누구에게? 회사의 모든 사람들에게.
CS 부서나 운영팀처럼 상황을 빠르게 파악해야 하는 팀에게는 멘션까지 하면서.

'와, 이 사람들 특이한 사람들이네. 이런 건 살다 살다 처음 보는군.'
'다들 실수를 숨기고 싶어 하는데, 이 사람들은 실수한 걸 마치 자랑하듯이 게시판에 올리잖아? 그것도 전사 게시판에. (미친 사람들인가?)'

장애 공유 글에는 항상 좋아요가 많이 달렸습니다.
쪽팔림 같은 건 저기 던져버리고 자신의 얼간이 짓을 솔직하게 쓰면 쓸수록 좋아요가 더 많이 달렸습니다.

원인과 후속 조치, 여전히 가시지 않는 의문점들에 대해 댓글로 논의하기도 했습니다만…
장애를 낸 사람을 탓하는 경우는 한 번도 보지 못했습니다.
이건 불문율이었습니다. 이 불문율을 깨트리면 누구도 더 이상 솔직하게 공유하지 않을 테니까.

자신이 발생시킨 장애를 전 직원들에게 공유한다는 것이 절대 쉬운 일이 아닙니다.
직접 해봐야 그 당혹스러움과 부끄러움을 알 수 있습니다.
처음 겪으면 그냥 도망쳐버리고 싶다는 생각이 들 정도로 아찔합니다만…
몇 번 하다 보면 이 짓도 편안해집니다.

'아 오늘도 장애 공유 써야 되네, 젠장. 뭐 일하다 보면 장애 낼 수도 있는 거지.'
'열심히 코딩하고 배포하다 보니 장애를 많이 내는 것일 뿐, 내가 진짜 얼간이여서 그런 게 아니라고.'
(그래도 다음엔 실수하지 말아야겠다)

카카오에서보다 더 놀랐던 기억도 납니다.
2017년의 GitLab 장애.
rm -rf로 프로덕션 데이터베이스 전체를 날려먹었던가?
엄청난 장애를 어린 엔지니어 혼자 수습했습니다. 그것도 유튜브에 라이브 스트리밍을 하면서. (사람들이 댓글로 이걸 고쳐봐라 저걸 확인해 봐라… ㅋㅋㅋ)
와, 진짜 미친 사람들이 여기 있었구나. 저걸 회사의 다른 동료들이 아무도 뭐라 하지 않는 건가? 아니, 어쩌면 의도적으로 저렇게 공유하기로 한 건가?
문제를 공유하고 소통하는 것에 저 정도로 열려 있다면 GitLab의 다른 문화들도 충분히 멋질 거야. 라고 생각했던 것 같습니다.

https://jeho.page/essay/2025/05/15/failure-sharing.html

카카오에 처음 들어가서 놀랐던 또 한 가지는 장애를 공유하는 문화였습니다. 작고 큰 장애들이 자주 발생했습니다. 장애가 발생하면 즉시 전파하고, 원인을 파악하고 후속 대응까지 실시간으로 공유했습니다. 누구에게? 회사의 모든 사람들에게. CS 부서나 운영팀처럼 상황을 빠르게 파악해야 하는 팀에게는 멘션까지 하면서. '와, 이 사람들 특이한 사람들이네. 이런 건 살다 살다 처음 보는군.' '다들 실수를 숨기고 싶어 하는데, 이 사람들은 실수한 걸 마치 자랑하듯이 게시판에 올리잖아? 그것도 전사 게시판에. (미친 사람들인가?)' 장애 공유 글에는 항상 좋아요가 많이 달렸습니다. 쪽팔림 같은 건 저기 던져버리고 자신의 얼간이 짓을 솔직하게 쓰면 쓸수록 좋아요가 더 많이 달렸습니다. 원인과 후속 조치, 여전히 가시지 않는 의문점들에 대해 댓글로 논의하기도 했습니다만… 장애를 낸 사람을 탓하는 경우는 한 번도 보지 못했습니다. 이건 불문율이었습니다. 이 불문율을 깨트리면 누구도 더 이상 솔직하게 공유하지 않을 테니까. 자신이 발생시킨 장애를 전 직원들에게 공유한다는 것이 절대 쉬운 일이 아닙니다. 직접 해봐야 그 당혹스러움과 부끄러움을 알 수 있습니다. 처음 겪으면 그냥 도망쳐버리고 싶다는 생각이 들 정도로 아찔합니다만… 몇 번 하다 보면 이 짓도 편안해집니다. '아 오늘도 장애 공유 써야 되네, 젠장. 뭐 일하다 보면 장애 낼 수도 있는 거지.' '열심히 코딩하고 배포하다 보니 장애를 많이 내는 것일 뿐, 내가 진짜 얼간이여서 그런 게 아니라고.' (그래도 다음엔 실수하지 말아야겠다) 카카오에서보다 더 놀랐던 기억도 납니다. 2017년의 GitLab 장애. rm -rf로 프로덕션 데이터베이스 전체를 날려먹었던가? 엄청난 장애를 어린 엔지니어 혼자 수습했습니다. 그것도 유튜브에 라이브 스트리밍을 하면서. (사람들이 댓글로 이걸 고쳐봐라 저걸 확인해 봐라… ㅋㅋㅋ) 와, 진짜 미친 사람들이 여기 있었구나. 저걸 회사의 다른 동료들이 아무도 뭐라 하지 않는 건가? 아니, 어쩌면 의도적으로 저렇게 공유하기로 한 건가? 문제를 공유하고 소통하는 것에 저 정도로 열려 있다면 GitLab의 다른 문화들도 충분히 멋질 거야. 라고 생각했던 것 같습니다. https://jeho.page/essay/2025/05/15/failure-sharing.html

K리그 프로그래머

﻿
세상에서 내가 제일 어렵고 힘든 상황에 놓여 있는 것 같지만, 주위를 둘러보면 위로와 격려가 필요한 사람이 더 많습니다. 어제는 전 직장 동료의 부고 소식을 전해 들었습니다. 갑작스러운 사고로 인해 하늘나라로 간 고인과 그의 가족들 소식을 듣고 마음이 먹먹했습니다. 가족들의 슬픔을 어떤 말로 위로하기 어렵겠지만, 진심으로 기도하여 빠르게 평안을 찾길 바란다고 메시지를 보냈습니다.

그 어느 때보다 뚫기 어려운 취업 시장에서 매일 탈락 안내를 받고 마음이 무너진다는 소식을 듣습니다. 3개월 전에 직접 겪었던 상황이 떠올라 마음이 아팠습니다. 얼마나 힘들고 답답할까 상황이 잘 이해와 공감되었기에 더 마음이 쓰였습니다. 입사 지원한 결과를 알려주지 않거나 채용 전형에서 아쉽게 탈락했다고 해서 절대 지원자가 부족한 것은 아니니 너무 실망하지 말자고 격려했습니다. 제 말이 무슨 힘이 있어서 취업에 도전하는 사람들을 얼마나 위로할 수 있겠습니까. 다만, 진심으로 그의 어려움이 공감되어 상황에 무릎 꿇지 않고 담대한 용기를 갖기를 바라는 마음입니다.

우리의 직장 동료들도 자세히 들여다보면 하나같이 위로와 격려가 필요합니다. 동료가 하는 일과 그의 컨디션에 관심을 갖고, 자세히 보면 저마다 어려움을 안고 일을 하고 있습니다. 우리가 관심이 없으니 동료가 겪고 있는 고충이 보이지 않을 뿐입니다. 오히려 왜 저렇게 말하고 행동하는지 동료에 대한 불평과 불만을 갖고 있습니다. 알고 보면 각자 다 그럴만한 사정이 있고, 동료에게 필요한 건 조언이 아니라 위로입니다. 

매일 아침 눈을 뜨면 만나는 가족도 마찬가지입니다. 아내와 아들, 딸에게도 힘든 부분이 있을 것입니다. 직장을 다니는 아내에게 일과 사람에 대한 스트레스가 있을 것이고, 학교와 유치원을 다니는 아들과 딸에게도 공부하고 친구들과 지내는 관계에 어려움이 있을 것입니다. 매일 어려움을 가족에게 이야기하지 않을 뿐 각자 마음속으로 끙끙 앓고 있는 아픔이 있습니다. 그들에게 필요한 건 잔소리가 아니라 사랑이 담긴 말 한마디와 따뜻한 포옹입니다. 내 생활 방식과 다르다고 핀잔을 주는 것이 아니라 오늘은 어떤 일로 힘들지 않았나 세심하게 살펴보고 정성스럽게 대화를 나누는 것입니다.

아파트 경비 아저씨는 얼마나 힘들까요? 매일 쏟아져 나오는 쓰레기를 정리하고 처리해야 합니다. 날마다 방문하는 사람들에게 문을 열어주고, 붐비는 주차장을 관리하느라 실랑이를 벌입니다. 잠도 편하게 주무시지 못하고 추운 밤을 쓸쓸하게 혼자 보내는 마음은 어떨까요? 제가 도울 수 있는 일은 분리수거 잘하고, 엘리베이터에 붙은 아파트 주민으로 해야 할 일을 제때 잘 처리하는 것뿐입니다. 그리고 오늘도 마주친다면 반갑게 인사드리고, 수고해 주셔서 감사하다는 표현입니다. 이것으로 경비 아저씨가 힘을 얻을 수 있다면 만날 때마다 해야죠.

퇴근길을 터벅터벅 걸어오는 이웃의 발걸음을 보면 오늘 하루 얼마나 고되었을까 상상해 봅니다. 매일 아침 출근길에 만나는 이웃도 너무 일을 하고 싶어서 룰루랄라 일터로 가는 건 아니겠지요? 먹고살기 위해 고군분투하고 집으로 돌아오는 길이 힘없어 보이는 건 하루 종일 지지고 볶고 에너지를 쏟았을 쓸 이웃의 험난한 여정이 공감되었기 때문입니다. 일을 하느라 바빠서 자신을 돌아볼 여유도 없이 보냈을 하루가 정말 피곤했을 것 같습니다. 부디 저녁에는 편안하게 쉬고 에너지를 충전하길 마음으로 응원해 봅니다.

어제 만나고 떠오른 사람들 말고도 위로와 격려가 필요한 분들이 많이 계실 줄 압니다. 그들이 직접 힘들다고 우리에게 적극적으로 표현하지 않을 것입니다. 우리가 먼저 그런 시선을 가지면 좋겠습니다. 우리가 힘들었던 상황을 떠올려보면 공감하는 것이 그리 어려운 일은 아닙니다. 시선은 전적으로 우리 마음에 달려있습니다. 날카로운 눈으로 바라보는 것이 아니라 사랑으로 바라보면 모든 사람과 상황이 이해와 공감할 수 있다고 믿습니다. 오늘은 주변 사람들을 사랑의 눈으로 바라보고, 진심을 담아 응원하는 하루가 되면 좋겠습니다.

﻿세상에서 내가 제일 어렵고 힘든 상황에 놓여 있는 것 같지만, 주위를 둘러보면 위로와 격려가 필요한 사람이 더 많습니다. 어제는 전 직장 동료의 부고 소식을 전해 들었습니다. 갑작스러운 사고로 인해 하늘나라로 간 고인과 그의 가족들 소식을 듣고 마음이 먹먹했습니다. 가족들의 슬픔을 어떤 말로 위로하기 어렵겠지만, 진심으로 기도하여 빠르게 평안을 찾길 바란다고 메시지를 보냈습니다. 그 어느 때보다 뚫기 어려운 취업 시장에서 매일 탈락 안내를 받고 마음이 무너진다는 소식을 듣습니다. 3개월 전에 직접 겪었던 상황이 떠올라 마음이 아팠습니다. 얼마나 힘들고 답답할까 상황이 잘 이해와 공감되었기에 더 마음이 쓰였습니다. 입사 지원한 결과를 알려주지 않거나 채용 전형에서 아쉽게 탈락했다고 해서 절대 지원자가 부족한 것은 아니니 너무 실망하지 말자고 격려했습니다. 제 말이 무슨 힘이 있어서 취업에 도전하는 사람들을 얼마나 위로할 수 있겠습니까. 다만, 진심으로 그의 어려움이 공감되어 상황에 무릎 꿇지 않고 담대한 용기를 갖기를 바라는 마음입니다. 우리의 직장 동료들도 자세히 들여다보면 하나같이 위로와 격려가 필요합니다. 동료가 하는 일과 그의 컨디션에 관심을 갖고, 자세히 보면 저마다 어려움을 안고 일을 하고 있습니다. 우리가 관심이 없으니 동료가 겪고 있는 고충이 보이지 않을 뿐입니다. 오히려 왜 저렇게 말하고 행동하는지 동료에 대한 불평과 불만을 갖고 있습니다. 알고 보면 각자 다 그럴만한 사정이 있고, 동료에게 필요한 건 조언이 아니라 위로입니다.&nbsp; 매일 아침 눈을 뜨면 만나는 가족도 마찬가지입니다. 아내와 아들, 딸에게도 힘든 부분이 있을 것입니다. 직장을 다니는 아내에게 일과 사람에 대한 스트레스가 있을 것이고, 학교와 유치원을 다니는 아들과 딸에게도 공부하고 친구들과 지내는 관계에 어려움이 있을 것입니다. 매일 어려움을 가족에게 이야기하지 않을 뿐 각자 마음속으로 끙끙 앓고 있는 아픔이 있습니다. 그들에게 필요한 건 잔소리가 아니라 사랑이 담긴 말 한마디와 따뜻한 포옹입니다. 내 생활 방식과 다르다고 핀잔을 주는 것이 아니라 오늘은 어떤 일로 힘들지 않았나 세심하게 살펴보고 정성스럽게 대화를 나누는 것입니다. 아파트 경비 아저씨는 얼마나 힘들까요? 매일 쏟아져 나오는 쓰레기를 정리하고 처리해야 합니다. 날마다 방문하는 사람들에게 문을 열어주고, 붐비는 주차장을 관리하느라 실랑이를 벌입니다. 잠도 편하게 주무시지 못하고 추운 밤을 쓸쓸하게 혼자 보내는 마음은 어떨까요? 제가 도울 수 있는 일은 분리수거 잘하고, 엘리베이터에 붙은 아파트 주민으로 해야 할 일을 제때 잘 처리하는 것뿐입니다. 그리고 오늘도 마주친다면 반갑게 인사드리고, 수고해 주셔서 감사하다는 표현입니다. 이것으로 경비 아저씨가 힘을 얻을 수 있다면 만날 때마다 해야죠. 퇴근길을 터벅터벅 걸어오는 이웃의 발걸음을 보면 오늘 하루 얼마나 고되었을까 상상해 봅니다. 매일 아침 출근길에 만나는 이웃도 너무 일을 하고 싶어서 룰루랄라 일터로 가는 건 아니겠지요? 먹고살기 위해 고군분투하고 집으로 돌아오는 길이 힘없어 보이는 건 하루 종일 지지고 볶고 에너지를 쏟았을 쓸 이웃의 험난한 여정이 공감되었기 때문입니다. 일을 하느라 바빠서 자신을 돌아볼 여유도 없이 보냈을 하루가 정말 피곤했을 것 같습니다. 부디 저녁에는 편안하게 쉬고 에너지를 충전하길 마음으로 응원해 봅니다. 어제 만나고 떠오른 사람들 말고도 위로와 격려가 필요한 분들이 많이 계실 줄 압니다. 그들이 직접 힘들다고 우리에게 적극적으로 표현하지 않을 것입니다. 우리가 먼저 그런 시선을 가지면 좋겠습니다. 우리가 힘들었던 상황을 떠올려보면 공감하는 것이 그리 어려운 일은 아닙니다. 시선은 전적으로 우리 마음에 달려있습니다. 날카로운 눈으로 바라보는 것이 아니라 사랑으로 바라보면 모든 사람과 상황이 이해와 공감할 수 있다고 믿습니다. 오늘은 주변 사람들을 사랑의 눈으로 바라보고, 진심을 담아 응원하는 하루가 되면 좋겠습니다.﻿

위로

1. 뇌를 재설계하려면 무엇이 필요할까?

2. 많은 게 필요하지 않고 딱 다음 세 가지만 있으면 된다. 그나마 한 가지는 선택 사항이다.

3. 집중, 반복, 감정(두려움, 행복, 증오, 사랑, 열정 등)

4. 감정이란 치트키를 쓰면 뇌의 신경 회로가 가장 빨리 재구성된다. 하지만 감정 없이 리프레임에 집중하고 반복하기만 해도 뇌를 원하는 대로 재설계할 수 있다.

5. 뇌는 입력하는 자극에 반응하여 새로운 구조를 만든다. 집중과 반복은 아이디어(또는 리프레임)를 개념적인 것에서 물리적인 것으로 바꾼다.

6. 다시 말해 뇌 구조에 물리적인 변화를 가져온다.

7. 여기에 감정을 더하면 뇌가 더 빨리 재설계 되지만, 다시 말하는데 이 부분은 선택 사항이다.

#더리프레임 📚
#스콧에덤스
#하루한문장

1. 뇌를 재설계하려면 무엇이 필요할까? ​2. 많은 게 필요하지 않고 딱 다음 세 가지만 있으면 된다. 그나마 한 가지는 선택 사항이다. ​3. 집중, 반복, 감정(두려움, 행복, 증오, 사랑, 열정 등) ​4. 감정이란 치트키를 쓰면 뇌의 신경 회로가 가장 빨리 재구성된다. 하지만 감정 없이 리프레임에 집중하고 반복하기만 해도 뇌를 원하는 대로 재설계할 수 있다. ​5. 뇌는 입력하는 자극에 반응하여 새로운 구조를 만든다. 집중과 반복은 아이디어(또는 리프레임)를 개념적인 것에서 물리적인 것으로 바꾼다. ​6. 다시 말해 뇌 구조에 물리적인 변화를 가져온다. ​7. 여기에 감정을 더하면 뇌가 더 빨리 재설계 되지만, 다시 말하는데 이 부분은 선택 사항이다. #더리프레임 📚 #스콧에덤스 #하루한문장

< 뇌를 가장 빠르게 바꾸는 3가지 방법 >

현대 소프트웨어 개발에서 의존성(Dependency)은 필수 불가결한 존재입니다. 직접 구현해야 하는 코드를 줄여 생산성을 높여주지만, 관리되지 않고 방치된 의존성은 보안 취약점이나 호환성 문제로 이어지기 쉽죠.

이번 글에서는 깃허브에서 제공하는 Dependabot을 통해 의존성 관리와 보안 업데이트를 어떻게 자동화할 수 있는지 알아보겠습니다.

📝 포스팅: https://www.daleseo.com/github-dependabot/

Dependabot은 깃허브에서 제공하는 보안 취약점 경보 및 의존성 업데이트 기능입니다. 초기에는 독립 서비스였지만, 2019년 GitHub에 인수된 후 현재는 깃허브 플랫폼에 완전히 통합되어 무료로 사용할 수 있습니다. 덕분에 Dependabot에 대한 접근성과 사용성이 크게 개선되어 복잡한 과정없이 코드 저장소에 간단한 설정만으로 바로 쓸 수 있습니다.

Dependabot은 다음 세 가지 기능으로 이루어져 있습니다.
 * Alerts(알람): 코드 저장소의 보안 취약점을 감지하여 경고합니다.
 * Security Updates(보안 업데이트): 보안 취약점이 발견된 의존성을 업데이트하는 Pull Request을 자등으로 생성합니다.
 * Version Updates(버전 업데이트): 보안과 무관하게 의존성을 최신 상태로 유지하기 Pull Request을 자등으로 생성합니다.

npm이나 Maven, PyPI, RubyGems, Docker Hub 등과 같은 패키지 저장소를 통해 의존성을 내려받는 프로젝트는 모두 잠재적인 공급망 공격(Supply Chain Attack) 위험에 처해 있습니다. Dependabot은 점점 정교해지고 있는 공급망 공격을 방어하고, 알려진 보안 취약점으로부터 프로젝트를 지킬 수 있는 강력한 보안 도구입니다.

현대 소프트웨어 개발에서 의존성(Dependency)은 필수 불가결한 존재입니다. 직접 구현해야 하는 코드를 줄여 생산성을 높여주지만, 관리되지 않고 방치된 의존성은 보안 취약점이나 호환성 문제로 이어지기 쉽죠. 이번 글에서는 깃허브에서 제공하는 Dependabot을 통해 의존성 관리와 보안 업데이트를 어떻게 자동화할 수 있는지 알아보겠습니다. 📝 포스팅: https://www.daleseo.com/github-dependabot/ Dependabot은 깃허브에서 제공하는 보안 취약점 경보 및 의존성 업데이트 기능입니다. 초기에는 독립 서비스였지만, 2019년 GitHub에 인수된 후 현재는 깃허브 플랫폼에 완전히 통합되어 무료로 사용할 수 있습니다. 덕분에 Dependabot에 대한 접근성과 사용성이 크게 개선되어 복잡한 과정없이 코드 저장소에 간단한 설정만으로 바로 쓸 수 있습니다. Dependabot은 다음 세 가지 기능으로 이루어져 있습니다.<ul><li>Alerts(알람): 코드 저장소의 보안 취약점을 감지하여 경고합니다.</li><li>Security Updates(보안 업데이트): 보안 취약점이 발견된 의존성을 업데이트하는 Pull Request을 자등으로 생성합니다.</li><li>Version Updates(버전 업데이트): 보안과 무관하게 의존성을 최신 상태로 유지하기 Pull Request을 자등으로 생성합니다.</li></ul> npm이나 Maven, PyPI, RubyGems, Docker Hub 등과 같은 패키지 저장소를 통해 의존성을 내려받는 프로젝트는 모두 잠재적인 공급망 공격(Supply Chain Attack) 위험에 처해 있습니다. Dependabot은 점점 정교해지고 있는 공급망 공격을 방어하고, 알려진 보안 취약점으로부터 프로젝트를 지킬 수 있는 강력한 보안 도구입니다.

Dependabot을 통한 안전한 의존성 관리

롱블랙 프렌즈 C 여러분은 일할 때 가장 설레는 순간이 언제세요? 저는 어디서도 듣지 못한 이야기를 접했을 때예요! 2025년 4월 30일에 열린 <롱블랙 스토리 컨퍼런스 2025

스토리 2025 : 반짝거림에 기대지 않는, 스토리텔러 8인의 이야기 발견법

1️⃣ 불편한데 그래야만 할까?

“어느 시대든 성공한 비즈니스에는 그 업계의 감수성과 상식이라는 게 존재합니다. 그 상식에 도전하고, 부수면서 나아가는 것. 그것이 우리의 역할입니다. 그래서 우리는 기획할 때 ‘기성세대가 품은 상식을 어떻게 돌파할 수 있을지’를 중요하게 보죠.” - 다카하시 야스노리 CCC CEO (CCC는 일본의 1위 서점 츠타야 운영사)

① 왜 서점에는 책 파는 진열장만 있는 걸까? → ‘머무는 공간’을 만들기 위해 서점과 스타벅스를 경계 없이 융합했다.

② 왜 가전 매장은 할인 위주의 판매에만 집중할까? → ‘상상할 수 있는 공간’을 만들기 위해 고객이 가전제품을 체험할 수 있는 매장, 츠타야 일렉트릭스를 제안했다.

③ 왜 은행은 번화한 곳에 있는데 주말마다 문을 닫을까? → ‘가고 싶은 공간’을 만들기 위해 은행 영업시간 외에 문을 여는 공유오피스, 쉐어 라운지를 기획했다.

2️⃣ 아파트에 전기차 충전기를 설치하기 위한 솔루션, '출차 알림 시계'

2023년에 만든 ‘출차 알림 시계’를 소개했어요. 아파트의 이중주차 문제를 해결하기 위해, 차 위에 ‘나의 출차 시간’을 표시할 수 있는 시계였어요. 표시된 시간보다 먼저 나갈 차는 그 앞에 이중주차를 할 수 있게 한 거였죠.

"현장에 가니 답이 쉽게 보였어요. 이중주차 문제로 싸움까지 나는 아파트가 적잖았거든요. 주차 공간도 부족한데 전기차 충전기를 놓자고 하면? 당연히 반대가 나올 만했어요. 그래서 사람들의 근본적인 괴로움을 풀 방법을 찾았습니다. 그렇게 출차 알림 시계를 떠올렸죠. 이렇게 저는 누군가의 문제를 발견해 해결할 수 있다면, 형식이나 표현 방식에 제약을 둘 필요가 없다고 생각합니다. 눈에 보이는 모든 것을 미디어 삼아 광고할 수 있죠.” - 이승재 아이디엇 대표

https://www.longblack.co/note/1438?ticket=NT25205127e745725a7423751d7cce7b464a39

1️⃣ 불편한데 그래야만 할까? “어느 시대든 성공한 비즈니스에는 그 업계의 감수성과 상식이라는 게 존재합니다. 그 상식에 도전하고, 부수면서 나아가는 것. 그것이 우리의 역할입니다. 그래서 우리는 기획할 때 ‘기성세대가 품은 상식을 어떻게 돌파할 수 있을지’를 중요하게 보죠.” - 다카하시 야스노리 CCC CEO (CCC는 일본의 1위 서점 츠타야 운영사) ① 왜 서점에는 책 파는 진열장만 있는 걸까? → ‘머무는 공간’을 만들기 위해 서점과 스타벅스를 경계 없이 융합했다. ② 왜 가전 매장은 할인 위주의 판매에만 집중할까? → ‘상상할 수 있는 공간’을 만들기 위해 고객이 가전제품을 체험할 수 있는 매장, 츠타야 일렉트릭스를 제안했다. ③ 왜 은행은 번화한 곳에 있는데 주말마다 문을 닫을까? → ‘가고 싶은 공간’을 만들기 위해 은행 영업시간 외에 문을 여는 공유오피스, 쉐어 라운지를 기획했다. 2️⃣ 아파트에 전기차 충전기를 설치하기 위한 솔루션, '출차 알림 시계' 2023년에 만든 ‘출차 알림 시계’를 소개했어요. 아파트의 이중주차 문제를 해결하기 위해, 차 위에 ‘나의 출차 시간’을 표시할 수 있는 시계였어요. 표시된 시간보다 먼저 나갈 차는 그 앞에 이중주차를 할 수 있게 한 거였죠. "현장에 가니 답이 쉽게 보였어요. 이중주차 문제로 싸움까지 나는 아파트가 적잖았거든요. 주차 공간도 부족한데 전기차 충전기를 놓자고 하면? 당연히 반대가 나올 만했어요. 그래서 사람들의 근본적인 괴로움을 풀 방법을 찾았습니다. 그렇게 출차 알림 시계를 떠올렸죠. 이렇게 저는 누군가의 문제를 발견해 해결할 수 있다면, 형식이나 표현 방식에 제약을 둘 필요가 없다고 생각합니다. 눈에 보이는 모든 것을 미디어 삼아 광고할 수 있죠.” - 이승재 아이디엇 대표 https://www.longblack.co/note/1438?ticket=NT25205127e745725a7423751d7cce7b464a39

LongBlack

⟪스토리를 만드는 사람들⟫

2019년 2월 7일, 브런치에 첫 글이 발행 되었습니다. 매일 치열하게 고민한 것들이 휘발되는 것이 아깝기도 했고, 새로운 자극이 필요한 시기이기도 했습니다. 그렇게 브런치는 디자인 일기장 같은 공간이 되었습니다.

요즘처럼 트래픽이 흔해진 시대에, 6년간 151편의 글, 100만이라는 숫자가 자랑할 만한 일인지는 모르겠습니다. 다만 디자인이라는 단일 주제로 꾸준히 기록하며 여기까지 왔다는 것에서는 의미를 부여하고 싶습니다.

그 사이 세 권의 책을 냈고, 훌륭한 디자이너 분들과 소중한 교류의 기회를 얻었습니다. 좋은 기업들을 거쳐 현재는 독립을 했습니다. 돌아보니 그 여정 가운데 브런치와 글쓰기가 있었습니다.

긴 시간 제 글을 읽어주고 반응해준 분들께 감사함이 큽니다. 앞으로도 계속 디자인과 디자이너에 대한 기록을 이어가고자 합니다.

2019년 2월 7일, 브런치에 첫 글이 발행 되었습니다. 매일 치열하게 고민한 것들이 휘발되는 것이 아깝기도 했고, 새로운 자극이 필요한 시기이기도 했습니다. 그렇게 브런치는 디자인 일기장 같은 공간이 되었습니다. 요즘처럼 트래픽이 흔해진 시대에, 6년간 151편의 글, 100만이라는 숫자가 자랑할 만한 일인지는 모르겠습니다. 다만 디자인이라는 단일 주제로 꾸준히 기록하며 여기까지 왔다는 것에서는 의미를 부여하고 싶습니다. 그 사이 세 권의 책을 냈고, 훌륭한 디자이너 분들과 소중한 교류의 기회를 얻었습니다. 좋은 기업들을 거쳐 현재는 독립을 했습니다. 돌아보니 그 여정 가운데 브런치와 글쓰기가 있었습니다. 긴 시간 제 글을 읽어주고 반응해준 분들께 감사함이 큽니다. 앞으로도 계속 디자인과 디자이너에 대한 기록을 이어가고자 합니다.

브런치에서의 6년, 그리고 100만뷰

📰 인공지능만으로 운영된 스타트업의 실패

카네기 멜론 대학교의 연구자들은 “TheAgentCompany”라는 회사를 만들었다. 이 회사는 AI 모델들이 소프트웨어 엔지니어, 재무 분석가, 프로젝트 매니저로 일하는 곳.

인공지능 직원들은 인터넷에서 정보를 찾고, 사내 규정집을 참고하며, 웹사이트와 슬랙 같은 채팅 프로그램을 사용하고, 코드도 작성하고, 스프레드시트로 정보를 정리하고, ‘동료’들과 소통까지 했다.

그래서 결과는 어땠을까? 실패했다. 거의 코미디 수준으로.

인공지능 직원들은 회의하는 데 탁월했고 엄청나게 많은 회의를 했다. 내부 갈등도 많았다. 그리고 결국 아무 제품도 만들어내지 못했다. 우리가 맹목적으로 신뢰하는 인공지능이 회사를, 그것도 스타트업을 운영하면 어떻게 될까? 그 대답은 출시 제품 없이 실패하는 것이었다.

마치 스타트업에 관한 코미디 쇼의 패러디 같았다.

—

아니 근데, 이건 패러디 같은게 아니라 걍 인간 세상에 늘 있는 일인데요?..(…)

📰 인공지능만으로 운영된 스타트업의 실패 카네기 멜론 대학교의 연구자들은 “TheAgentCompany”라는 회사를 만들었다. 이 회사는 AI 모델들이 소프트웨어 엔지니어, 재무 분석가, 프로젝트 매니저로 일하는 곳. 인공지능 직원들은 인터넷에서 정보를 찾고, 사내 규정집을 참고하며, 웹사이트와 슬랙 같은 채팅 프로그램을 사용하고, 코드도 작성하고, 스프레드시트로 정보를 정리하고, ‘동료’들과 소통까지 했다. 그래서 결과는 어땠을까? 실패했다. 거의 코미디 수준으로. 인공지능 직원들은 회의하는 데 탁월했고 엄청나게 많은 회의를 했다. 내부 갈등도 많았다. 그리고 결국 아무 제품도 만들어내지 못했다. 우리가 맹목적으로 신뢰하는 인공지능이 회사를, 그것도 스타트업을 운영하면 어떻게 될까? 그 대답은 출시 제품 없이 실패하는 것이었다. 마치 스타트업에 관한 코미디 쇼의 패러디 같았다. — 아니 근데, 이건 패러디 같은게 아니라 걍 인간 세상에 늘 있는 일인데요?..(…)

📰 인공지능만으로 운영된 스타트업의 실패

카네기 멜론 대학교의 

ChatGPT의 Deep Researh에 GitHub을 연결 할 수 있게 되었군요!

와우! 대박! 와우! 대박적! 지금 만나러갑니다!

ChatGPT의 Deep Researh에 GitHub을 연결 할 수 있게 되었군요! 와우! 대박! 와우! 대박적! 지금 만나러갑니다!

ChatGPT의 Deep Researh에 GitHub을 연결 할 

www.55check.com공유하기게시하기웹에서 보기#레오 14세 즉위Cubs 팬 or Sox 팬? 새 교황님의 신상을 털어보자한국시간 금요일 새벽, 미국 시카고 출신의 로버트 프레보스트(Robert Prevost, 69) 추기경이 가톨릭 교회의 새 교황으로 선출. 레오 14세로 즉위. (첫 등장 영상. 소리 on 필수)레오 14세는 여러 면에서 독특한데,사진에도 보듯 흑인 + 백인 혼혈이심. 놀랍게도 노스트라다무스가 예언(!)고향 미국은 가톨릭 국가도 아님. (개신교 40%, 가톨릭 20%)페루에서 오랫동안 선교활동을 해서 미국-페루-바티칸 3중 국적 보유.영국 출신 하드리아노 4세(1154년~1159년 재위) 이후 두 번째로 영어가 모국어인 교황.800년 역사를 가진 아우구스띠노 수도회의 첫 교황. 이 수도회의 유명 멤버로는 종교개혁을 이끈 마르틴 루터(파문당함), 완두콩 덕후 그레고어 멘델, 철학자 에라스무스 등.레오14세는 레오13세(1878~1903)을 롤모델로 삼아 고른 이름으로 추측. 레오13세는 교회가 현대사회에 맞게 공장노동자들에게 더 다가가야한다고 주장했던 사람.코스트코에서 본 듯?레오 14세는 미국 출신이시다보니 이전 교황들보다 신비감은 떨어지고 좀 친근하게 느껴짐.아버지는 2차대전 해군 참전용사 출신이며 공립학교 교장. 어머니는 도서관 사서이며 독실한 가톨릭 신자.성직자가 되기 전 펜실베니아 주에 있는 명문 빌라노바대 수학과 전공. 이 학교 재학생들의 반응.MLB 시카고 컵스 팬이라는 소문이 돌았으나

2025년 5월 9일 (금) - 새 교황님 신상털기 총정리 : 오호츠크 리포트

OpenAI, 코딩 AI 서비스 Windsurf 인수

 * 금액은 4.2조원. 2025년 AI 스타트업 업계 첫 1조원 이상의 딜.
 * 현재 연간 반복 매출(ARR)은 560억원. 비슷한 코드에디터 기반의 경쟁사인 Cursor는 2년 만에 연매출 1억 달러(1400억원) 돌파해 주목 받아.
 * Windsurf는 프로그램 코드를 자동으로 짜주는 에디터 서비스. OpenAI는 윈드서프를 AI 에이전트와 연동해 문서 작성, 메모장, 노션 같은 기능의 생산성 도구 출시할 듯.
 * 또 웹 검색해 자료 정리하고, 그래프도 자동 제작하고, 이를 하나의 문서로 만들어주는 통합 도구까지 만들 듯. MS 오피스에 도전하기 위한 밑밥.
   
OpenAI 기업 구조 대변신, 그러나 마이크로소프트는 반대

 * OpenAI가 기존과 연결되는 새로운 회사 구조 발표. 기존 영리법인(LLC)을 공익법인(PBC)으로 전환 예정.
 * 최근 소프트뱅크(56조)와 마이크로소프트(13조)가 이 영리법인에 투자했었는데, 이번 회사 구조를 변경하는데 있어서 마이크로소프트가 반대하고 나섰음.
 * 핵심 이슈는 수익 배분. 2030년까지 매출의 20%를 인프라 사용료로 MS에 줄 예정이었으나 공익법인으로 바꾸면서 그 액수를 반으로 줄이겠다는 계획
 * 한편 OpenAI는 창업자 일론 머스크와도 소송 중. 머스크는 "비영리로 운영하겠다고 해서 돈도 주고 밀어줬는데, 영리 추구해 계약 위반했다" 주장.
 * 계약서에 명시된 내용이라 OpenAI에게 여러모로 골치 아픈 상황. 비영리냐 영리냐의 정체성 혼란.

아마존, 클라우드 시장을 넘어 우주 시장으로.

 * 아마존이 저궤도 위성 발사로 위성 기반 인터넷 제공 사업 본격화. 프로젝트명 카이퍼(Kuiper).
 * 최대 2600km 떨어진 위성끼리 안정적 양방향 링크 유지 가능. 이번에 27개 위성 탑재해 발사 및 연결 완료.
 * 최종 목표는 3200개 위성 연결로 지구 상당 부분 커버. 이미 80번 이상의 발사 예정
 * 흥미로운 점: 계열사인 블루오리진 로켓에 의존하지 않고 다른 회사 로켓들을 더 활용한다는 계획.
 * 저궤도 위성 인터넷은 해상 선박, 오지에서도 연결 가능한 아직 블루오션 시장. 일론 머스크의 스타링크가 압도적 1위. 2024년 기준 7135개 위성 띄워 전 세계에 서비스 제공 중. 우크라이나에서도 쓰고 각종 선박과 항공기들도 사용.
 * 블루 오리진은 SpaceX와 맞불, 아마존은 스타링크와 맞불. 아마존은 손해를 감수하고서라도 대량으로 밀어붙이는 스타일의 회사라 앞으로 위성 인터넷 시장의 경쟁 심화될 듯.

https://55check.com/newsletters?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&bmode=view&idx=163564390&t=board

OpenAI, 코딩 AI 서비스 Windsurf 인수 <ul ><li>금액은 4.2조원. 2025년 AI 스타트업 업계 첫 1조원 이상의 딜.</li><li>현재 연간 반복 매출(ARR)은 560억원. 비슷한 코드에디터 기반의 경쟁사인 Cursor는 2년 만에 연매출 1억 달러(1400억원) 돌파해 주목 받아.</li></ul><ul ><li>Windsurf는 프로그램 코드를 자동으로 짜주는 에디터 서비스. OpenAI는 윈드서프를 AI 에이전트와 연동해 문서 작성, 메모장, 노션 같은 기능의 생산성 도구 출시할 듯.</li><li>또 웹 검색해 자료 정리하고, 그래프도 자동 제작하고, 이를 하나의 문서로 만들어주는 통합 도구까지 만들 듯. MS 오피스에 도전하기 위한 밑밥. </li></ul>OpenAI 기업 구조 대변신, 그러나 마이크로소프트는 반대 <ul ><li>OpenAI가 기존과 연결되는 새로운 회사 구조 발표. 기존 영리법인(LLC)을 공익법인(PBC)으로 전환 예정.</li><li>최근 소프트뱅크(56조)와 마이크로소프트(13조)가 이 영리법인에 투자했었는데, 이번 회사 구조를 변경하는데 있어서 마이크로소프트가 반대하고 나섰음.</li><li>핵심 이슈는 수익 배분. 2030년까지 매출의 20%를 인프라 사용료로 MS에 줄 예정이었으나 공익법인으로 바꾸면서 그 액수를 반으로 줄이겠다는 계획</li><li>한편 OpenAI는 창업자 일론 머스크와도 소송 중. 머스크는 "비영리로 운영하겠다고 해서 돈도 주고 밀어줬는데, 영리 추구해 계약 위반했다" 주장.</li><li>계약서에 명시된 내용이라 OpenAI에게 여러모로 골치 아픈 상황. 비영리냐 영리냐의 정체성 혼란.</li></ul> 아마존, 클라우드 시장을 넘어 우주 시장으로. <ul ><li>아마존이 저궤도 위성 발사로 위성 기반 인터넷 제공 사업 본격화. 프로젝트명 카이퍼(Kuiper).</li><li>최대 2600km 떨어진 위성끼리 안정적 양방향 링크 유지 가능. 이번에 27개 위성 탑재해 발사 및 연결 완료.</li><li>최종 목표는 3200개 위성 연결로 지구 상당 부분 커버. 이미 80번 이상의 발사 예정</li><li>흥미로운 점: 계열사인 블루오리진 로켓에 의존하지 않고 다른 회사 로켓들을 더 활용한다는 계획.</li><li>저궤도 위성 인터넷은 해상 선박, 오지에서도 연결 가능한 아직 블루오션 시장. 일론 머스크의 스타링크가 압도적 1위. 2024년 기준 7135개 위성 띄워 전 세계에 서비스 제공 중. 우크라이나에서도 쓰고 각종 선박과 항공기들도 사용.</li><li>블루 오리진은 SpaceX와 맞불, 아마존은 스타링크와 맞불. 아마존은 손해를 감수하고서라도 대량으로 밀어붙이는 스타일의 회사라 앞으로 위성 인터넷 시장의 경쟁 심화될 듯.</li></ul> https://55check.com/newsletters?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&amp;bmode=view&amp;idx=163564390&amp;t=board

55check.com

5월 둘째주 - OpenAI 인수부터 마소에 반기까지. 다 하는군

주니어 개발자가 읽어보면 좋을 기술 블로그 글들과 포인트에 대해서 이야기해 보고자 한다.

주니어 개발자들이 읽으면 좋은 테크 아티클 모음

F-Lab 에서 주니어 개발자들이(사실 개발자라면 누구나) 보시면 좋을 아티클 모음을 공유해 주었네요!

검색엔진부터 비동기 처리, NoSQL 등 다양한 분야의 아티클들이 공유되어 있으니 관심있으신 분들은 보시면 좋겠습니다.

F-Lab 에서 공유해주신 아티클 주제를 나열해보면 다음과 같습니다.

📌 구글이 직접 말하는 검색엔진의 원리 (tali.kr)
📌 검색 엔진은 어떻게 작동하는가 (xo.dev)
📌 네이버의 검색엔진의 특징과 알고리즘 (tistory.com)
📌 [네이버 블로그]네이버 검색의 원리 : 네이버 블로그 (naver.com)
📌 지마켓 대기열 시스템 파헤치기 (gmarket.com)
📌 인증/인가는 어디에 어떻게 구현해야 할까? (gmarket.com)
📌 Sharded MySQL Cluster 도입 배경과 개발기 (부제: 우당탕탕 좌충우돌 개발기) (gmarket.com)
📌 웹 브라우저에 URL을 입력하면 어떤 일이 생기나요? | Amazon Web Services 한국 블로그
📌 네이버 메인 페이지의 트래픽 처리 (naver.com)
📌 How Discord Stores Trillions of Messages
📌 What ScyllaDB Is and Why You Should Care | by Mottakin Chowdhury | Better Programming
📌 How Discord Supercharges Network Disks for Extreme Low Latency
📌 비동기 서버에서 이벤트 루프를 블록하면 안 되는 이유
📌 카카오가 직접 회고한 1015 장애사태 원인과 대책 (brunch.co.kr)
📌 Lessons learned from operating our data serving layer | Coupang engineering | Coupang Engineering Blog (medium.com)
📌 The Missing Semester of Your CS Education (mit.edu)
📌 고려대학교 컴퓨터학과 특강 - 대학생 때 알았더라면 좋았을 것들 (slideshare.net)

F-Lab : 상위 1% 개발자들의 멘토링

주니어 개발자들이 읽으면 좋은 테크 아티클 모음📚

디즈니 OTT서비스 디즈니플러스, 내년 韓 론칭 발표

디즈니 플러스 내년 한국 진출 공식화!

디즈니에서 투자발표회를 맞이해 여러 발표를 내어놓았는데 한국 진출 발표 계획도 있네요. 2021년에는 한국 포함 동유럽, 홍콩에도 진출할 예정이라고 합니다.

이외에도
- 앞으로 수년간 마블 시리즈 10개, 스타워즈 시리즈 10개, 디즈니 라이브액션/애니메이션/픽사 시리즈 15개를 디즈니 플러스에 바로 공개할 것
- Star/Star+라는 해외 플랫폼을 디즈니 플러스와 통합시켜 상생시킬 것
등이 발표되었습니다.

참고: https://twitter.com/Disney/status/1337153230824943617

매일경제

Product Manager

근정

첫 이메일 계정을 생성한 것이 1994년. 첫 비즈니스 이메일을 보낸 것이 14세에 웹진 편집장을 맡았던 1997년. 그 후 20년 간 영리, 비영리, 공공 영역에서 직/간접적으로 일하며 수많은 이메일을 보내고 받았습니다. 이메일마케팅 서비스 ‘Stibee'를 기획하며 쌓은 노하우를 바탕으로 다양한 강연과 기고를 했습니다. 현재 크리에이티브솔루션 기업 슬로워크에서 CPO로 일하고 있습니다.

마이오렌지 CEO

조성도(펭도)

프로덕트 매니저/서비스 기획

쏘달리

유고은

학부에서 심리학을 전공했고, 데이터를 읽고 분석합니다. 데이터에 담긴 사람들의 마음과 행동에 관심이 많습니다. 그리고 미디어 뉴스레터 어거스트에서 에디터로서 레터를 발행합니다.
#데이터분석 #뉴스레터

댓글 0

함께 읽은 게시물

< '모든 것을 받아들이기'의 진짜 의미 >

👕무신사가 마뗑킴 일본 매장을 성공시킨 비결은

< 초동 100만 장, 그런데 팬은 어디 있죠? - 엔터 테크와 데이터로

대기업 전직 임원이 골프장 캐디가 된 이유

🍚한촌설렁탕의 파격적인 도전은 성공할 수 있을까요?

주간 인기 TOP 10

추천 프로필