최근 LLM의 성능이 좋아지면서 한국어 <-> 영어 번역을 많이 활용하고 있습니다.외국업체에 이메일을 보낼 때나 논문, 기사 중 어려운 문장이 있는 경우, 빠르게 논문이나 기술 자료를 읽어야 할때 자주 사용하는데요.몇년 전만해도 구글 번역기나 네이버 파파고를 사용했었는데, 요즘은 ChatGPT, Claude, Gemini에 바로 물어보고 빠르게 답을 얻곤 합니다.최근 업무에서 정식적으로 한영/영한 번역 기능이 필요하여 객관적인 LLM 모델간 성능 비교가 필요했는데,그동안 제가 개인적으로 했던 번역 성능은 주관적이다 보니 평가지표가 없는지 찾아봤습니다.LLM 이 평가자가 되어 번역 성능을 평가하는 흥미로운 논문이 있어 리뷰해보려고 합니다.이 연구는 거대 언어 모델(LLM)을 활용한 영어에서 한국어로의 문학 기계번역을 자동화된 방식으로 평가하는 프레임워크를 제안하고, 그 가능성과 한계를 심도 깊게 분석하고 있습니다.최근 GPT, Claude, Gemini와 같은 LLM 모델들은 나올 때마다 기존의 모델들의 성능을 뛰어넘으며, 전반적인 성능이 빠르게 발전하고 있습니다.기본적으로 언어간 번역 성능도 뛰어난 편이지만 문학 번역은 단순히 텍스트의 의미를 전달하는 것을 넘어, 미묘한 언어의 미학적, 정서적 사용, 문학적 표현에도 중점을 두어야 합니다.또한 문화적 맥락이 매우 중요하며, 원문의 뉘앙스, 작가의 의도, 등장인물 간의 관계 등을 섬세하게 포착해야 하기에 일반 기사나 기술자료의 번역보다 난이도가 높은 편입니다.문제는 이러한 문학 번역의 복잡성 때문에 기존의 성능 평가 지표들, 예를 들어 BLEU나 BLEURT 같은 것들이 문학 번역의 미묘한 뉘앙스를 제대로 평가하지 못한다는 점입니다.그렇다고 매번 비용이 많이 드는 숙련된 언어 전문가의 평가에만 의존할 수도 없으니,LLM 에이전트나 파이프라인 개발자들에게 번역이 필요한 기준을 충족하는지 알려줄 수 있는 자동화된, 세분화된 평가 방법이 절실한 상황입니다.이 논문은 바로 이러한 필요성에서 출발합니다.이 연구는 문학 번역 평가의 복잡성을 해결하기 위해 두 단계로 구성된 프레임워크를 제안합니다.프레임워크의 첫 번째 단계는 DA-MQM(Direct Assessment-Multidimensional Quality Metric) 이라고 불립니다.연구진들은 먼저 기계 번역 시스템이 영어를 한국어로 번역할 때 자주 범하는 네 가지 주요 오류 유형을 식별했습니다.• None 단어/구/표현 문제: LLM은 지나치게 직역하여 비유적인 표현 등에서 어색하거나 부자연스러운 한국어 단어를 선택할 수 있습니다.• None 문맥 관련 문제: 문화적, 역사적 뉘앙스가 종종 사라집니다. 예를 들어, 'abolitionist(노예제 폐지론자)'와 같은 용어는 한국어에 직접적인 역사적 대응어가 없어 혼란스러운 번역으로 이어질 수 있습니다.• None 형식 관련 문제: 구두점, 문장 구조, 일관성 없는 이름 표기 등의 문제는 글의 흐름을 방해할 수 있습니다.• None 경어법(Honorifics): 이는 한국어에서 매우 중요한 요소입니다. 관계와 사회적 지위를 반영하는 복잡한 경어법 체계가 MT 시스템에 의해 잘못 해석되어 부자연스럽거나 틀린 대화로 이어지는 경우가 많습니다.이를 위해 전문가들이 직접 설계한 세분화된 평가 rubric (Extensive human curated rubric)을 사용하며,이 루브릭은 영어-한국어 번역에서 흔히 발생하는 기계번역 오류 유형을 감지하도록 특별히 고안되었습니다.평가 기준은 다음 네 가지 주요 범주에 초점을 맞춥니다:• None 어휘 선택 (Lexical Choice): 숙어 표현 및 전반적인 단어 선택이 목표 언어의 유창성을 얼마나 잘 보여주는지 평가합니다.• None 대화에서의 적절한 존대법 사용 (Proper Use of Honorifics in Dialogues): 한국어만의 고유한 특성으로 문학 텍스트에서도 특히 중요한 요소입니다. 존댓말과 반말이 명확하게 구분되어 있는 한국어에서 대화 참여자들의 사회적 지위와 관계를 정확히 반영하는 동사 어미 선택이 자연스러운 한국어 대화를 만들어내는지 평가합니다. 존대법 오류는 독자의 독서 경험에 부정적인 영향을 줄 수 있습니다.• None 구문 및 문법 (Syntax and Grammar): 문장의 문법적 정확성, 삽입절, 접속사, 문장 연결의 적절성, 문장의 내부 논리 및 구두점 등을 평가하여 한국어로 번역문이 얼마나 자연스럽게 읽히는지 확인합니다.• None 내용 정확도 (Content Accuracy): 원문의 의미를 얼마나 잘 보존하고 있는지, 특히 문학적 표현이 제대로 번역되었는지 평가합니다. 명확성을 위해 일부 추가나 생략이 있을 수 있지만, 원문의 내용과 맥락에 필수적인 중요한 단어나 구절이 변경되거나 생략되어서는 안 됩니다.DA-MQM 단계에서는 LLM이 1점부터 5점까지의 척도로 점수를 부여합니다.기술적으로 완벽한 번역이 반드시 훌륭한 '문학적' 번역은 아닙니다.VERSE(VERification-based Story-specific Evaluation) 라고 명명된 두 번째 단계는 원작의 고유한 문학적 특성이 잘 보존되었는지를 평가하여 이 문제를 해결합니다.작동 방식은 다음과 같습니다.• None 질문 생성: 뛰어난 성능의 LLM(이 연구에서는 GPT-4)에게 원문과 이야기 요약을 컨텍스트로 제공하고, 특정 단락의 문학적 측면에 대한 검증 질문 목록을 생성하도록 지시합니다. 이 질문들은 텍스트의 문학적 구조를 더 깊이 파고들도록 설계되었습니다.• None 평가: 다른 LLM이 심사관 역할을 하여, 생성된 질문들을 바탕으로 기계 번역 결과물을 1점에서 3점 척도(1점=불만족, 2점=부분 만족, 3점=완전 만족)로 평가합니다.먼저 고성능 LLM 모델 (이 연구에서는 GPT-4o)이 성공적인 문학 번역에 필요한 검증 질문 목록을 생성합니다.해당 질문들은 역사적 및 문화적 맥락, 이미지 및 묘사 품질, 인물화, 대인 관계 역학, 관용적 자연스러움, 미묘한 함의, 서사적 속도 및 리듬, 문체적 공명, 전반적인 일관성 및 응집력 등 다양한 문학적 측면을 고려합니다.그다

SK Hynix의 김병도 입니다.이번 포스팅은 제가 사내에서 LLMops를 운영&개발하면서 느꼈던 필수 요건, 팁 등을 공유드리겠습니다.Chat PPT는 대중적으로 나와있는 PPT 분석기와 매우 유사합니다.VLM(Vision Model)이 슬라이드 마다 API를 호출하여 분석 후 결과를 출력하며, 이 결과들을 User Prompt에 넣고 LLM을 통해 결과를 호출하는 프로그램입니다.크게 1. 목표 설정 / 2. 개발 과정 / 3. 품질 향상 과정 으로 구성 하였습니다.• None 회사에서 제공하는 API를 활용 ( Qwen2-VL-72B / Llama3.3_70B ) * 유동적 변경• None API가 Local LLM이기에 보안 제약이 없음.• None 많은 구성원이 '필요'로 하는 기능과, 쉽게 접근 할 수 있도록 구현 -- pyinstaller기능을 통한 .exe로 구성(Web은 보안상 불가)• None 서비스에 Input 될 규격이 항상 일정하고, 사내 가장 많은 자료를 갖고 있는 PPT를 공략• None 매우 전문적이고, 숫자하나, 단어하나 놓치지 않고 출력 할 수 있도록 구성• None 단순히 단어 뿐아니라 그림, 모식도,도표 등을 이해하고 출력 할 수 있도록 Fine Tunning• None 속도 vs 정확성에서 전문적인 지식을 도출하는 만큼 정확성을 선택.• None DRM으로 인해, 일방적으로 PPT를 읽는 것은 불가능. -- PPT를 한 장씩 클립보드에 담아 VLM으로 보내는 방식 채택• None DPI 고정을 통해 캡쳐된 PPT의 화질이 손상되는 것을 예방• None LLM Api 부하가 걸리지 않게 break time 설정 및 한장 씩 호출 - 결과 추출을 반복• None -- Progress : 각 SIlde 마다 데이터 추출 진척사항, 에러 등을 보여주며, 종료 후 csv 형태로 저장• None ASK 답변에는 200 page 이상 추출된 Data가 한 번에 Input 가능한 LLM 사용• None 가 Open 이후 주변 동료에게 Feedback 요청• None 한문, 형상문자 출력 / 디테일한 정보 부족 / 숫자 추출 부정확 / 도표 이해 / 그림 이해 등 많은 문제를 해결필요 -- VLM의 메타인지를 위해 System Preprompt에 들어갈 내용을 ChatGPT를 통해 생성. -- 질문 예시) "나는 Skhynix 반도체 회사에 다니는 LLMops 개발자야. 회사내 전문적인 지식을 기반으로 만들어진 PPT를 Vision Model 에게 질의하여 최대한 자세한 답변을 받고 싶어. 0000등을 정확히 추출할 수 있도록 Pre-prompt 를 영어로 작성해줘."• None VLM 성능 향상을 위해 답변은 최대한 영어로 하되 의미를 최대한 살리게함(최종 답변은 한글로)• None 실제 자료 추출 결과와 비교해가며 다시 1번부터 품질향상 과정 진행 반복다음 이야기 : Progress에 저장된 데이터를 기반으로 Graph-RAG 구성제가 실제로 사내에 Chat PPT라는 프로그램을 구현했던 개발과정을 담았으며,사용 친화적이고 Error 나 할루시네이션 등이 최소화되는게 중요하다고 생각합니다. 사용 중 부정확한 성능이나, 불만이 생기면 사용자는 빠르게 이탈하기 때문입니다.오직 글로만 존재하여 지루하셨겠지만, 개발 과정에서 도움을 드릴게 있을까하여 내용을 담았습니다.필요하신 내용은 답글연락주시면 답변드리겠습니다. ( + 하트 한 번 부탁드립니다.)

글. 오미람(Rami) / UX Designer여기어때에는 호텔, 펜션, 게스트하우스, 캠핑장 등 다양한 숙소들이 있는데요. 매출의 중심에는 모텔이 있어요. 특히, 모텔 파트너 분들은 내 숙소를 앱 안에서 더 잘 보이게 하고, 더 많은 예약을 끌어내기 위해 광고를 진행하고 있어요. 여기서 말하는 광고는 흔히 말하는 CPC(Click per Cost)·CPM(Click per Mile) 방식이 아니라 서비스 내에 입점된 숙소를 지역·리스트 등 위치 기준으로 노출시키는 계약형 광고예요.그런데 문제가 하나 있었어요. 고객들은 기존 상위 노출 광고에 대해 점점 피로감을 느끼고 있었고, 영업 사원들은 더 이상 새로운 광고 상품을 제안할 수 없어서 매출 증대에 어려움을 겪고 있었죠. 이제는 기존 틀 안에서 더 팔려고 애쓰기보다는 새로운 광고 지면을 만들어야 할 시점에 도래했어요.저는 UX Designer로서 이 문제를 풀기 위해 작년 한 해 동안 광고 프로젝트에 집중했어요. 이번 글에서는 광고가 단순히 ‘노출’이 아닌, 서비스 흐름 속에서 자연스럽게 어울리는 광고 경험을 만들어가기 위해 고민했던 이야기를 풀어보려고 해요.탐색 흐름에서 출발한 새로운 기회먼저 광고를 만들기에 앞서 모텔 고객들의 행동 패턴을 살펴봤어요. 주로 파티, 게임, 야간 대실 같은 특정 목적 중심으로 탐색하거나, 내 주변에서 비슷한 가격대의 숙소를 빠르게 찾고 싶어하는 욕구가 강했는데, 기존 PLP(상품 리스트 페이지)에서는 이런 니즈를 충족시켜주기가 어려웠죠.다른 서비스들을 벤치마킹해보니, 단순히 위치 기반 노출을 파는 방식이 아니라 고객의 탐색 흐름에 맞춰 상품을 추천하거나 키워드 기반으로 상위 노출을 제공하는 광고를 운영하고 있었어요. 단순한 광고 판매가 아닌, 고객의 탐색 맥락과 맞닿은 광고 경험이었죠. 이 방식은 고객에게는 덜 피로하고, 파트너에게는 새로운 노출 기회를 줄 수 있는 균형점을 제시해주었어요.이 인사이트는 새로운 광고 지면 발굴의 출발점이자 이후 일련의 실험과 전략 논의의 방향타가 되었어요. 특히, 기존 광고 지면을 방해하지 않으면서도 모텔 고객들의 “내 주변 숙소를 빠르게 찾고 싶다”는 실질적인 니즈와 맞닿아 있는 지면으로, 주변 탭이 가장 유력한 후보로 떠올랐죠. 이처럼 벤치마크를 통해 발견한 관점이 새로운 문제 해결의 실마리로 작용했고, 이후 주변 핀 실험, 광고 방향성 정립, 스쿼드 출범까지 자연스럽게 이어지는 밑그림이 되어주었어요.하지만 주변 탭에는 문제가 있었는데요, 제휴점이 몰린 곳은 가격 핀이 겹쳐서 클릭하기 어렵고, 가격 외에 쿠폰, 특가, 시설 같은 정보는 한 눈에 보이지 않았죠. 사장님들은 ‘내 숙소가 잘 보여야 한다’는 강한 욕구가 있지만, 동시에 가격 핀을 무분별하게 강조할 경우 광고 효과가 약해진다라는 단점도 존재했어요.그래서 저희는 이렇게 접근했어요. 상위 광고 제휴점만 하이라이트하고, 비광고 핀은 지도 줌 레벨에 따라 미니핀으로 축소해서, 광고 숙소가 상대적으로 더 눈에 띄게 만드는 방식을 고안했죠.총 A,B,C,D 4개 버전으

AI 시대에, 나는 무엇을 상상하고, 어떻게 행동해야 하는가?AI 시대를 맞아, 스스로에게 다시 질문을 던지게 됩니다.“이 거대한 변화 앞에서 나는 무엇을 상상하고, 어떻게 행동해야 하는가?”2012년 마이리얼트립을 창업한 이후, 지난 13년간 여러 기술적 전환점을 마주해왔지만, 이번처럼 전면적이고 구조적인 전환은 처음입니다. 그 흐름 속에서 저는 창업자로서의 경험과 반성을 되짚어보고, 우리가 어떤 방향으로 나아가야 할지를 고민하게 되었습니다.모바일 시대의 후회: 상상력의 빈곤이 낳은 기회 손실정말 이런 앱에서 수백만원, 천만원 이상의 결제를 할까?마이리얼트립의 첫 앱은 창업 3년 뒤인 2015년에 출시됐습니다.그 전까지 저는 모바일이 수백만 원에 이르는 고관여 여행 상품을 구매하기엔 부적절하다고 판단했습니다. 작은 화면과 느린 반응 속도, 부족한 신뢰도 등 여러 이유로 우리는 PC 웹에 더 많은 자원을 투입했고, 실제 당시 데이터를 봐도 모바일에서의 구매는 10만 원 이하 소비에 집중되어 있었습니다.하지만 곧 상황은 급변했습니다. 우리는 모바일 중심의 변화에 뒤늦게 반응해야 했고, 그 경험은 제게 큰 교훈을 남겼습니다. 대표의 상상력이 부족하면 회사 전체가 중요한 흐름을 놓칠 수 있다는 것을, 뼈아프게 깨달았습니다. 그 이후부터 저는 다짐했습니다. 다음 변화가 온다면 가장 먼저 움직이고, 가장 넓게 상상하겠다. 그리고 지금, 그 ‘다음’이 눈앞에 와 있습니다. AI는 모바일보다 더 거대한 변화입니다.분업에서 통합으로: 조직 구조의 근본적인 전환AI의 본질은 기술이 아니라 구조의 변화에 있습니다.산업화 이후, 조직은 분업을 통해 복잡한 문제를 효율적으로 해결해왔습니다. 기획자는 기획을, 디자이너는 디자인을, 개발자는 개발을 담당하며 역할을 분리하는 것이 일반적이었습니다.그러나 기술이 비약적으로 발전할 때마다 이 구조는 도전을 받아왔습니다. 인터넷, PC, 모바일은 업무의 경계를 흐리게 했고, 이제 AI는 그 흐름을 근본적으로 가속화하고 있습니다. 실제로 많은 AI 기반 스타트업에서는 소수의 구성원이 다기능적으로 문제를 해결하는 구조가 빠르게 보편화되고 있습니다.분업이 무너질 때, 각 개인은 더 넓은 권한과 책임을 가지게 됩니다. 더 이상 팀 간의 조율에 의존하지 않고, 혼자서 문제를 정의하고 해결하는 구조가 만들어집니다. 이 흐름은 결국, 리더십의 ‘조율’ 기능이 축소되고, IC(Individual Contributor)의 시대를 여는 전환점이 될 것입니다.기능보다 문화가 먼저다: 리터러시가 변화의 시작점처음에는 AI 전담 조직을 만들어 특정 기능을 개발하고, 각 팀에서의뢰된 솔루션을 구현하는 방식으로 접근했습니다. 그러나 곧 병목이 발생했습니다. 요청 중심의 구조는 컨텍스트 이해에 많은 시간과 에너지를 소모했고, 팀 전체의 속도는 오히려 느려졌습니다.크몽과 비슷한 방식이라 생각해 ‘마리트크몽’ 이라는 귀여운 이름을 붙였습니다.그래서 우리는 전략을 바꾸었습니다. 특정 팀이 AI를 담당하기보다는, 모든 구성원이 AI를 이해하고 활용할 수

이번 포스팅은 현재 LLM Agent을 구현하기 위해서 가장 많이 쓰이는 Langchain과 Langgraph의함수의 차이점에 대해서 간략하게 알아봅니다.Agent는 보통은 특수한 영역 또는 기능에 특화된 일꾼 입니다.근데 여기에 이게 를 추가해서유저의 요청에 따라, 상황에 맞는 Tool를 사용해서 기존에 학습하지 못했던 기능을 가능케 합니다.이를위해서 ReAct(Reasoning and Action) Agent를 사용하게 됩니다.이때 기존 포스팅을 통해서, Scratch부터 Agent를 만들어 봤지만실제 Production에서는 Langchain이나 Langgraph를 사용하게 됩니다.Langchain에서는 함수를 통해서 Agent를 만들 수 있고prompt를 통해서 Agent가 어떤 Chain Of Thought 를 진행할지 기술하게 됩니다.그래서 사용자의 prompt작성 수준에 따라서 Agent의 Tools Call능력이나, Reasoning능력이 달라지게 됩니다.하지만 API문서에서 보면, 아래와 같은 문구를 확인할 수가 있습니다.Langchain Agent는 Production 용도에는 적합하지 않다는 내용이네요.Langchain의 경우 prompt를 이용해서 Agent가 Tool을 사용하게 유도합니다.이 덕분에 Tool Call이 학습되지 않은 모델에서도 Tool을 사용할 수 있다는 장점이 있습니다.Langgraph의 경우 동일한 이름의 함수를 제공합니다.대신 차이점을 보이는게Langgraph의 공식 문서에서는prompt입력에 대한 가이드 라던가, 복잡한 prompt를 입력하라고 안내해주지 않습니다.3. 둘이 뭔 차이에요?두 라이브러리의 실제 vLLM 또는 OpenAI로 보내지는 prompt를 확인하기 위해서 아래 코드를 사용합니다.이제 코드를 실행시키고, 디버깅 로그를 확인해봅니다.requests를 보내기 전에 이미 prompt부분이 Agent정의때 사용된 가 이미 포맷팅이 된 것을 확인할 수 있습니다.실제로 requests를 보내기 이전에 prompt 포맷팅이 진행되는 것음langchain의 create_react_agent 소스코드에서도 확인할 수가 있습니다.Langgraph는 prompt가 포맷팅 되지 않고 그대로 전달되게 됩니다.여기서 Langchain과의 큰 차이점은 requests의 parameter로 tools가 전달되게 됩니다.• None Langchain : Client Side에서 prompt를 처리함• None Langgraph : LLM Service Side에서 prompt를 처리함외부 환경에서 상용 서비스(ChatGPT, Gemini, Claude)를 이용할 경우langgraph로 tool call API를 이용할 수가 있습니다.그렇기 때문에 이런경우는 정상적으로 Tool을 사용하는 Agent를 구현할 수 있습니다.하지만 vLLM등을 이용하는 Private LLM환경에서는Tool Call이 허용되지 않는 모델이나, vLLM 설정에 따라 Tool Call이 불가능 할 수 있습니다.이런 경우에 Agent를 구현하기 위해서 Langchain을 사용한 Agent구현을 고려해 볼 수 있습니다.

AI 기술의 발전으로 누구나 쉽게 도구를 활용해 복잡한 문제를 해결할 수 있는 시대가 열렸습니다. 아이디어가 있다면 AI 도구로 개발을 바로 실행해 볼 수 있습니다.이번 글에서는 교육 분야의 개인 맞춤형 학습 앱(가칭 GRE Mind) 개발을 예시로 들어 AI 도구 활용의 잠재력에 대해 공유하고자 합니다.LLM을 활용한 기확과 클로드와 파일시스템 MCP를 활용한 기획안의 구현을 통해 초기 결과물을 신속하게 얻어 낼 수 있습니다.아이디어 기획과 LLM의 역할에빙하우스 망각곡선 이론을 기반으로 한 GRE 학습 앱 개발 사례를 통해 AI 도구의 잠재력을 탐구합니다.GRE Mind의 기획은 LLM(Large Language Model)을 활용해 시작해 볼 수 있습니다."GRE 공부", "망각곡선" 과 같은 키워드를 입력해 초기 아이디어를 제시하면 이를 바탕으로 상세 기획안을 도출해 줍니다.핵심적인 아이디어만 있다면 복잡하지 않은 프롬프트로도 효과성이 있다는 걸 확인해 볼 수 있습니다.LLM은 수험생의 주요 Pain Point(단어 암기, 복습 관리, 취약점 분석)를 분석해 앱의 핵심 컨셉—스마트 망각곡선 단어장 & 문제은행—을 제안했습니다.생각하고 있던 아이디어 대비 크게 나쁘지 않아 그대로 진행해 볼 수 있습니다.이 과정에서 LLM은 시장 조사, 사용자 니즈 분석, 기능 제안을 단 몇 분 만에 수행하며 기획 속도를 획기적으로 단축했습니다.GRE Mind의 코딩은 프롬프트 기반으로 진행하였습니다.코딩 구성에 직접적으로 영향을 주는 프롬프트는 첫 줄에 표현해서 전체 구성에 대한 요구사항을 전달할 수 있습니다.• None 핵심사항 : 코딩 언어 구성(html, js, css), 데이터 처리(sqlite, json), 모듈화(200라인 넘지 않도록 정의: 일반적인 LLM은 200라인을 넘으면 넘어서는 코드를 하지 못하고 반복적인 재 작성을 하는 빈번한 실수를 사전에 차단), 파일 시스템 MCP 활용, 로컬에 프로젝트 구조를 직접 만들어서 파일을 생성해 가면서 개발을 진행하도록 지시그 다음 줄에 기획안을 포함하여 기능별 요구사항(대시보드, 단어장, 퀴즈, 통계)을 명확히 제공해서 시행착오를 줄이고, 즉시 구현에 집중할 수 있도록 했습니다.이는 전통적인 개발 방식 대비 시간을 대폭 단축시켜 줄 뿐만 아니라 자동화 수준을 높일 수 있었습니다.AI 도구(Claude)는 MCP(Model Context Protocol) 파일 시스템을 활용해 프로젝트 구조를 자동 생성했습니다.GRE Mind의 경우, index.html, css/main.css, js/dashboard.js 등 필수 파일을 체계적으로 구성하고, LLM이 각 파일의 초기 코드를 생성했습니다.이를 통해 로컬 환경에서 프로젝트 초기 설정이 단 몇 분 만에 완료되었으며, 개발자 입장에서는 즉시 코딩 결과를 검토하고, 의사결정을 진행하는 단계로 바로 돌입할 수 있었습니다.GRE Mind의 index.html은 대시보드, 단어 학습, 복습 퀴즈, 통계 페이지를 포함한 완전한 웹앱 구조를 제공합니다.AI는 HTML과 JavaScript 코드를 생성하며, 망각곡선 알고리즘을 적용한 복습 시스템과 UI를 구현했습니다.테스트 단계에서는 AI가 생성한 더미 데이터를 활용해 단어 퀴즈, 학습 진행률 표시, 통계 시각화를 검증했습니다.예를 들어, 대시보드의 "오늘의 학습" 카드는 새로운 단어, 스마트 복습, 취약점 극복을 표시하며, 사용자가 클릭 시 즉시 학습 또는 퀴즈로 전환됩니다.몇 분 만에 동작하는 웹앱GRE Mind는 AI 도구를 활용해 단 몇 분 만에 동작 가능한 프로토타입으로 완성되었습니다.index.html은 네비게이션, 대시보드, 단어 학습, 퀴즈, 통계 페이지를 포함하며, 각 페이지 간 전환은 js/navigation.js로 부드럽게 처리됩니다.개발자는 입장에서는 AI가 생성한 코드를 검토하고, UI 스타일(css/main.css)이나 학습 데이터와 같은 세부 사항만 보정하면 완성도 높은 앱을 얻을 수 있었습니다.LLM은 GRE Mind에 필요한 GRE 단어(초기: 5개 단어), 예문, 퀴즈 데이터를 생성해 앱에 통합했습니다.예를 들어, 단어 "abate"에 대해 뜻, 어원, 예문, 동의어/반의어를 생성하고, 이를 플래시카드와 퀴즈 형식으로 제공했습니다.또한, 사용자의 학습 데이터를 기반으로 망각곡선에 따라 복습 주기를 계산하는 JavaScript 로직(js/forgetting-curve.js)도 AI가 제안해 빠르게 구현했습니다.추가로 100개의 데이터를 더 생성해 달라고 다음과 같이 손쉽게 LLM에게 요구할 수 있습니다.생성된 데이터를 코드에 통합하면 100개의 데이터를 기반으로 학습할 수 있는 앱으로 확장을 할 수 있게 되었습니다.앱 완성 후, 사용자의 피드백을 반영해 추가 기능을 구현할 수 있습니다. 예를 들어, "나만의 단어장" 기능을 추가해 사용자가 "학습중" 또는 "마스터"로 단어를 분류할 수 있도록 할 수 있습니다.지금 부터는 다양한 새로운 아이디어와 함께 요구사항을 분석하고, 의사결정에 집중해서 지속적인 개선과 혁신을 통해 완성도를 높여 갈 수 있습니다.결론: AI 시대의 새로운 개발 패러다임GRE Mind 개발 사례는 AI 도구가 아이디어 기획, 코드 생성, 데이터 통합, 테스트까지 전 과정을 가속화할 수 있음을 보여줍니다.LLM과 MCP 파일 시스템을 활용하면 몇 분만에 동작하는 앱을 만들고, 사용자의 요구에 맞춰 지속적으로 개선할 수 있습니다.AI 시대의 개발 자체는 더 이상 전문가만의 영역이 아닙니다. 누구나 아이디어를 빠르게 현실로 구현할 수 있는 이 패러다임은 다양한 분야에서 혁신을 가속화할 것입니다.앞으로 개발자 또는 엔지니어의 역할은 무엇일까요?어쩔 수 없이 진행해야 했던 프로젝트 기본 구조를 생성하고, 다른 프로젝트이지만 동일한 모듈을 작성해야 했던 반복적인 구현 작업에서 벗어나거나 해방 시켜줘서 의사결정이 필요한 영역에서 역할을 더 할 수 있을 것으로 예상해 볼 수 있습니다.이번 글에서 소개시켜 드린 파일시스템MCP 활용의 강력함은 높은 코드 생산성을 체감할 수 있게 해 주었습니다.최근 우연히 본