[커널아카데미] 백엔드 12기 18주차 회고 - 설계에 집중했고 이제는 구현에 집중

이번 주 내가 한 일 

• 주제영역정의서, 표준용어정의서 작성
• 논리 모델링, 물리 모델링 설계 
• 테스트 데이터 삽입 (아파트 관련 데이터, 고객 데이터, 마이데이터 동의 이력) 
• 시퀀스 다이어그램 작성 (팀원과의 소통을 위한!)

 

이번 주 느낀 점 

설계의 중요성. 문서 정리하다보면 이해가 된다.

주제영역정의서, 표준용어정의서 같은 ERD 관련 문서들 작성하면서 '기존 서비스에 어떻게 LangChain을 위한 설계를 덧붙여 설계해야하는지 문제를 정의하고, 해결 방법을 정리하고 그 중에서 우리의 상황에는 어떤 방법이 최선이겠다'라는 사고 과정을 거칠 수 있었습니다. 특히 주제영역정의서를 작성하면서 서비스의 이해도가 높아졌습니다. 표준용어정의서는 처음 작성해보는 것이라 막막했는데, 표준용어정의서를 작성해보신 팀원 분이 있어 도움을 많이 받았습니다.

 

표준용어 정의서는 '공공데이터 공통표준용어'에 있는 표준용어, 표준단어, 도메인을 참고해 작성했습니다. (5차, 7차 사용)

- 표준 용어 검색 후 있으면 그대로 사용

- 없으면 표준 단어에서 검색 후 조합하여 사용 . 이 경우는 우리 서비스에서 정의한 것이므로 엑셀에 따로 정의를 해두었습니다.

- 단위(명, 금액 등)가 포함된 컬럼은 도메인에서 검색 후 어떤 타입을 쓸지 팀원분과 논의해 결정

 

[참고] 공공데이터 포털 공통 표준용어 5차 

https://www.data.go.kr/bbs/ntc/selectNotice.do?pageIndex=1&originId=NOTICE_0000000002690&atchFileId=FILE_000000002577873&searchCondition2=2&searchKeyword1=%EA%B3%B5%EA%B3%B5%EB%8D%B0%EC%9D%B4%ED%84%B0+%EA%B3%B5%ED%86%B5%ED%91%9C%EC%A4%80%EC%9A%A9%EC%96%B4

공공데이터 포털

 

여기서 고민이 들었던 지점은 다음과 같습니다. 

1) 주제영역에는 프롬프트 템플릿에 관한 내용이 없고, '비기능 요구사항'인데 이것 또한 표준용어 정의서에 작성해야할까? 

- 표준용어정의서에는 기능적 요구사항, 비기능적 요구사항을 모두 반영해야합니다. 표준용어 정의서에는 주제영역정의서에 다룬 내용만 작성해야 하는 줄 알고 프롬프트 템플릿 관련 용어를 작성하지 않았습니다.

- 하지만 ISO/IEC/IEEE 24765:2017, Systems and software engineering – Vocabulary 부분에서 도메인과 시스템 설계 시 사용되는 모든 관련 용어를 정의 및 표준화하라는 권고가 있습니다. 그래서 다음 주에 시간이 남으면 수정할 예정입니다. 

https://www.iso.org/standard/71952.html

ISO/IEC/IEEE 24765:2017

 

2) 실제 논리 모델링과 물리 모델링 하면서 변경사항이 발생했는데, 주제영역정의서와 표준용어정의서를 변경 다 해야하나? 

- 해야한다.

 

[참고] 

ERD Cloud에서 Domain의 의미를 또한 알게 되었습니다. Domain은 미리 타입을 정의해 놓으면 도메인 이름을 작성할 때 자동으로 해당 타입을 컬럼에 적용할 수 있는 기능입니다. 

 

주제영역정의서에 추출된 핵심엔티티와 표준용어정의서에 작성된 용어와 단어를 바탕으로 논리 모델을 설계했습니다. 이미 정의된 속성들을 가져다 쓰니 편한 느낌을 받았습니다. 

 

주제영역정의서

표준용어정의서

시퀀스 다이어그램의 필요성을 느끼다.

팀원들 모두 이전에 LangChain을 공부한 적이 없고, LLM을 이용한 애플리케이션 설계를 한 경험이 없어 언제 RDB 혹은 Vector DB를 접근해야하는지 흐름을 잡지 못했습니다. 각자 공부한 후에는 어느정도 데이터를 주고 받는 주체와 흐름은 알고 있었지만, 팀원들이 공유할 하나의 흐름도를 정하지 않아 의사소통할 때 같은 말을 하고 있는지 확인하는 과정, 흐름을 잊어버려 다시 묻는 과정 때문에 시간이 소요되어 제가 시퀀스 다이어그램을 그렸습니다. 이걸 토대로 강사님께 피드백을 받고 흐름은 맞다고 평가를 해주셔서 한결 팀원들과 소통하는데 편했습니다.

 

[참고]

- 실제 시퀀스 다이어그램 작성 규칙에 맞춰 작성하지 않고 의사소통을 위해 개인적인 수정을 했습니다.

작성한 시퀀스 다이어그램 일부

 

용어를 명확히 정의하고 이해하자. 프롬프트 템플릿? 프롬프트? 퓨샷? 

DB 설계를 하다보니 프롬프트 템플릿과 Shot(예시)를 저장할 테이블 설계할 때, 어떤 것을 컬럼으로 넣어야할지 감이 잡히지 않았습니다. 그래서 랭체인 관련 책을 여러개 보면서 정의와 예시로 어떤 차이점이 있는지 알 수 있었습니다.

 

흐름.

Agent가 먼저 LLM에게 프롬프트 템플릿에서 존재하는 변수에 값을 대입하여 프롬프트를 만들고 전송한다. 그러면 LLM은 이에 대한 응답을 만들어 Agent에게 준다. 프롬프트를 구성할 때는 예제 선택기가 사용자 질문과 유사도가 높은 예제(shot)을 선택한다.

 

결론 

따라서 프롬프트 템플릿에 저장할 테이블과 예제를 저장할 테이블을 각각 설계해야한다 

프롬프트는 프롬프트 템플릿에 존재하는 변수에 대입된 값으로 만들어진 것이고, 변수들은 이미 사용자 발화에서 추출 후 값을 RDB에저장해야한다. 

 

 

팀별 KPT

공통	한 주간 좋았던	아쉬운 점	개선 방향
김경민	평소에 해보지못하였던 설계를 집중적으로 해보아서 좋았던것 같다. 평소 설계없이 개발만 했었는데 전체적인 개발 방향과 방식등을 설계해보고 만들어보는 과정에서 많은 깨달음을 얻은것같다.	전체적인 설계를 하는데있어서 소통을 다른분들과 많이못해서 문제를 발생시킨것같아 아쉬웠다. 또한 내가 맡은 개발부분을 빠르게 끝내지못하여서 개발기간을 맞을수있을지 잘모르겠다.	쫌더 명확한 개발 방향과 방식을찾아 팀원들과 열심히 개발을 해봐야할것같고 조금더 열심히 문제를 해결하기위해 노력 해야할것같다.
김승현
김현정	RAG 챗봇의 핵심 기능을 갖춘 프로토타입(v0.1)을 성공적으로 구축했다. 목표했던 대로 FastAPI 서버 구동, CSV 데이터의 벡터 변환 및 ChromaDB 저장, 그리고 각 핵심 모듈의 단위 테스트까지 완료하여 안정적인 개발 기반을 확보했다. 각 컴포넌트가 독립적으로 정상 작동함을 확인함으로써 향후 기능 확장을 위한 견고한 토대를 마련했다.	프로젝트 초기 단계에서 개발 환경 설정 관련 이슈를 해결하는 데 예상보다 많은 시간이 소요된 점은 아쉬운 부분이다. 특히 파이썬 가상환경 설정, 모듈 경로 문제, OpenAI API 키 할당량 초과 문제 등 비즈니스 로직 개발 외적인 부분에서 리소스가 집중되었다. 이를 통해 향후 프로젝트 진행 시 개발 환경 표준화 및 API 사용량 모니터링 프로세스를 사전에 강화해야하는 필요성을 더 깨닫게 되었다.	챗봇의 핵심 기능인 검색 성능을 고도화하는 데 집중할 계획이다. 현재의 의미 기반 벡터 검색에 메타데이터 필터링 기능을 추가하여 하이브리드 검색을 구현할 것이다. 구체적으로는 retreiver 모듈을 수정하여 사용자가 "10억 이하"와 같은 정형 데이터 조건을 제시했을 때 이를 벡터 검색과 함께 처리할 수 있도록 개선할 것이다.
박지형	ERD 관련 문서를 주제영역정의서, 표준용어정의서부터 작성하면서 서비스에 대한 이해도가 높아져 시퀀스 다이어그램을 작성할 떄 많은 도움이 되었습니다.	수정사항이 계속 발생하다보니 이를 반영하느라 생각한 데드라인보다 ERD 작업이 길어진 것 같아 아쉬웠습니다. 다행히 ERD 관련 큰 작업은 마무리가 되어서 LLM 파트 부분을 개발에 전념할 생각입니다. LLM 설계할 때마다 각 컴포넌트의 목적을 두루뭉술하게 알고 있어 다시 개념으로 돌아오는 시간이 상당한 것 같아 아쉬웠습니다. 한번 볼 때 간단하더라고 명확히 짚고 넘어가는 것이 필요하다 느꼈습니다.	LLM과 LangChain 관련 컴포넌트에 대한 이해를 한번 볼 때 간단하더라도 명확히 짚고 넘어갈 것 입니다.
이지현	어쩌다 보니 FastAPI를 맡게 되었다 배워본 적도 없고 하나도 모르던 터라 걱정을 많이 했지만 이왕 맡게 된 김에 한 번 배워보자 라느나 마음으로 시작했다 처음에는 흐름을 이해하는 것이 어려웠지만 코드를 보면서 공부하니 조금씩 감을 잡았다 무엇보다 팀원분이 도와주셔서 훨씬 수월하게 진행할 수 있었고 덕분에 많은 것을 배울 수 있었다 아직 부족하지만 FastAPI를 접해볼 수 있었던 좋은 기회였다	전체적인 흐름을 이해하는 데 여전히 어려움을 느꼈다 어렵다고 느끼는 순간 스스로 깊이 고민하거나 이해하려는 노력을 충분히 하지 않았던 것 같다 완벽하게 이해하지 못하면 쉽게 포기하려는 경향이 있는데 이번에도 그런 모습이 보였던 것 같다 이런 습관을 꼭 고치고 개선해야한다고 생각한다	앞으로는 처음부터 완벽하게 이해하려 하기보다는 전체적인 흐름이나 감을 먼저 잡고 코드를 작성해보면서 몸으로 익히는 방식을 시도해보려고 한다 LLM을 실제로 돌려보면서 동작을 체감하고 그 과정을 통해 이해를 쌓아가야겠다 이제 한 주밖에 남지 않았지만 남은 시간 동안 더 열심히 참여해서 랭체인에 대한 이해를 넓히고 프로젝트도 꼭 완성하고 싶다
홍우진	매일 짧은 회의로 진행 상황을 공유하고 이슈를 빠르게 해결하는 구조를 유지하고 있다.LangChain, Chroma, OpenAI API를 활용한 RAG 시스템을 도입해 실제 유저 질의에 대한 자동 응답을 성공적으로 구현했다.	아파트 리뷰 데이터나 정책 문서의 정제 및 구조화가 예상보다 시간이 많이 소요되었다.특히 메타데이터 태깅과 필터 조건의 일관성 확보에서 일부 삽질이 있었다.	남은 기간 동안 부족한 부분을 채우고, 팀의 목표를 잘 마무리해 좋은 결과를 만들어 내고 싶다.

 

 

 

개인 KPT 회고

 

Keep (잘한 점, 계속 유지할 것) : 설계가 올바른지 계속 고민한 것. 

이번 프로젝트에서 제가 가장 중요하게 생각한 것은 기존 시스템에 AI를 도입할 때 어떻게 재설계해야 하는지에 대한 설계 역량을 기르는 것이었습니다. 그래서 단순히 코드 구현보다는 설계에 중점을 두고 프로젝트를 진행했고, 이를 통해 향후 유사한 프로젝트를 수행할 때 시행착오를 크게 줄일 수 있을 것이라고 생각합니다.

Problem (아쉬운 점, 문제점) : 데드라인을 정했으나 수정 사항이 생길까봐 다음 단계를 밟지 않은 것.

데이터베이스 설계 작업이 예상했던 데드라인보다 2일 정도 더 소요되어 아쉬웠습니다. 설계 학습에 중점을 두는 것도 중요했지만, 실제 구현 과정에서 어떤 문제들이 발생하는지도 경험해보고 싶었기 때문입니다. 또한 구현 단계에서 설계를 수정해야 할 상황들이 분명히 있을 텐데, 이전 회고에서 다짐했던 '빠른 실패' 원칙을 제대로 적용하지 못한 점이 아쉬웠습니다.

Try (다음에 시도할 것) : 데드라인 정했으면 수정 사항이 있어도 다음 단계 밟을 것.

LLM과 관련 컴포넌트를 학습할 때, 간단해 보이는 개념이라도 그 목적과 동작 원리를 명확하게 파악한 후 다음 단계로 넘어가겠습니다. 또한 학습한 내용을 간단한 문서나 메모로 정리하여 설계 과정에서 바로 참고할 수 있도록 하겠습니다.