개요:
근래에 한국의 근간 사업이 되는 반도체 사업의 붐이 일어나며 해당 산업의 Pain Point가 드러나기 시작했다.
1. 새로운 반도체의 개발을 위해서 논문을 읽으며 회의를 하여 새로운 아이디어를 내는데 오랜 시간이 걸린다.
2. 반도체의 미래 방향성은 당사의 미래를 결정짓는 중요한 결정이다.
3. 끊임없이 나오는 논문과 기사들을 모두 읽을 수 없지만 읽으려면 많은 시간이 걸린다
4. 내부 R&D 자료를 활용하기 어렵다. 왜냐하면 수많은 데이터가 존재하고 이를 외부와 소통하는 LLM에 넣지 못한다
해당 포인트들은 다음과 같은 Solution으로 해결한다.
1. On-Premise Open Source LLM으로 사내 민감 자료를 사용할 수 있게 합니다
2. 반도체와 관련된 기사를 수집 및 Qdrant Vector DB에 저장합니다 - 스케쥴링으로 매일 오후 3시에 수집
3. 반도체와 관련된 논문을 수집 및 Qdrant Vector DB에 저장합니다 - 스케쥴링으로 매일 오후 3시에 수집
4. 보고서 작성 및 인사이트 제공을 위해 LLM이 정보를 취합하여 보고서 형태로 작성합니다
아키텍쳐:
문제점:
1. 마지막 보고서 작성 단계에서 퀄리티 좋은 보고서를 주지 못한다
2. 기존의 사내 R&D 리포트는 외부와 연결을 닫힌 상태로 정보를 누구에게도 주지 않고 안에서만 돌아야 한다
이러한 과정 중 현재는 1번 문제만 해결을 부분적으로 하였다.
2번의 경우 맞는 LLM을 선택하고 사내 서버에 설치하여야 하는데 적은 이틀동안 하기에 제약이 많아서 수행하진 못했다.
해결점:
1. LLM의 분리화
LLM의 Orchestration을 부분적으로 구현하여 해결하였다.
현재는 Agent 모델이 총 4개로 각각 R&D 자료, 논문, 기사 자료를 검색 및 정보를 추출하는 Agent가 존재하고 보고서 작성 Agent가 또 존재한다.
이를 보고서 작성 단계에서 논문 Agent와 기사 Agent 둘이 회의 혹은 결과물을 만들고 중재자 Agent가 결과물을 통합 및 보고서로 작성한다.
이 방향을 두 가지로 나눠서 구현해 보고 현재 비교 중이다.
1. 논문 Agent와 기사 Agent 둘이 서로 토의 및 질문을 하며 질문을 고도화 - 이후 중재자 Agent가 답변들을 취합 및 보고서로 저장합니다.
2. 중재자 Agent에게 Persona를 입힌 후 기준을 세웁니다. 이후, 논문 Agent와 기사 Agent가 주는 답변을 받습니다. 이후, 수정이 필요하면 instruction과 함께 다시 명령을 내립니다. 최종 통과된 답변들을 취합하여 보고서를 만드는 역할을 합니다.
예시:
질문: 모 기업의 미래 성장 방향성을 제시해 주고 HBM 수율 문제를 어떻게 해결할 수 있을지 알려주세요
결과:
(뒷 내용은 잘랐습니다)
현재는 사내 내부 R&D 자료를 사용하지 못하였으며 넣지 않습니다.
추후 계획:
On-Premise로 만들기에는 Mini-Project를 수행하며 수업을 병행하기 어려우니 최종 프로젝트에서 동일한 주제를 사용하게 된다면 그때 바꿀 계획입니다.
또한, 모기업의 뉴스룸 혹은 특허청과 같은 자료들을 수집 및 저장하여 보고서 만들 때 참조하여 사용할 수 있음을 시사하고자 합니다.
느낀 점:
이틀이라는 짧은 시간에도 불구하고 코딩하는 시간은 많이 걸리지 않았습니다.
오히려 아이디어를 만들고 구체화하는데 시간이 많이 걸렸으며 아키텍처를 생성하고 방법을 고안하는데 시간을 많이 할애했습니다.
최근에 본 Geek News의 "우리의 장인정신을 애도합니다"를 보며 많은 생각이 들었습니다.
https://nolanlawson.com/2026/02/07/we-mourn-our-craft/
We mourn our craft
I didn’t ask for this and neither did you. I didn’t ask for a robot to consume every blog post and piece of code I ever wrote and parrot it back so that some hack could make money off o…
nolanlawson.com
이러한 시대의 흐름 속에서 우리는 생각하는 방법을 끊임없이 길러야 하며 error 및 trouble shooting에서의 이해 능력을 길러야 살아남을 수 있을 것으로 보입니다.
비록 Vibe Coding의 생산력과 시간의 효율성은 압도적입니다. 하지만, 코드 리팩토링, 최적화, 창의적인 생각, 등의 능력들은 아직은 힘들다고 생각합니다. 물론 몇 년 사이에 정복될 것이라고 생각합니다. 하지만, 코드를 이해할 수 있는 개발자와 그렇지 못한 개발자는 AI를 쓰더라도 결과물의 퀄리티가 다를 것이라고 생각합니다.
본인의 강점을 끊임없이 생성하고 AI가 하지 못하는 영역을 고민하며 성장해 나가야 한다고 느끼는 좋은 시간이었습니다.