hyerong's Dev_world🎡

안녕하세요! 9기 DX트랙 에이블 기자단 입니다!
이번에 소개드릴 내용은 빅프로젝트 결과물 제출 후기입니다.

지난 8주차에 에이블스쿨 교육과정의 마지막을 장식하는 빅프로젝트가 어느덧 결과물 제출 단계까지 마무리되었습니다! 🎉

저희 조는 퇴직연금 서비스를 주제로, 금융 AX서비스를 기획했습니다. (자세한 주제는 10기 입교해서 확인하시길..!) 

아직 최종 발표가 남아 있어 프로젝트의 자세한 내용은 소개해 드리기 어렵지만, 이번 글에서는 빅프로젝트를 준비하며 팀원들과 함께 협업한 과정을 전해드리려고 합니다.

2달 전, 빅프로젝트는 주제에 관한 자료를 조사하고 아이디어를 제안하는 것부터 시작했습니다.

팀원마다 문제를 바라보는 관점과 중요하게 생각하는 부분이 달랐기 때문에, 초반에는 각자 조사한 내용을 공유하며 프로젝트의 방향을 맞춰 나갔습니다. 사실 이때가 가장 힘들고 어렵습니다. DX는 답이 있는 문제를 푸는 게 아니라 무엇이 문제인지부터 정의해야하는 직무기 때문에 다양한 도메인에서 무엇이 문제인가 찾느라 정말 어려웠어요. (팀원들도 이 주제 아이데이션이 가장 머리에 쥐가 났던것 같다고 하시더라구요) 그래도 초반에 정한 저희 조만의 그라운드 룰을 지키며 정말 열심히 또 적극적으로 의견을 나눴답니다!! 

특별히 저희 조는 엑셀로 각 주제를 모두 정리하고 투표하면서 어떤 문제에 집중할지, 고객에게 어떤 경험을 제공할지 함께 고민하며 하나의 방향으로 정리했습니다. 이후 해당 주제 후보들을 가지고 실무코치님과 프로젝트 코치님께 주제 평가를 받게 됩니다! 

2주에 걸쳐 주제가 정해지면,  팀원별 강점과 역할을 고려해 업무를 나눕니다. 

처음부터 명확하게 업무가 분담된 건 아니었는데요, 아무래도 다들 배경지식과 전공이 모두 다르고 각자 잘하는 부분도 다르다보니, 

강점을 살려서 역할을 분배하는게 더 팀워크를 다지기 좋았습니다! 

물론,,, 이렇게 역할을 분배하고 분업하면서 협업한다 해도 프로젝트가 항상 계획대로 진행된 것은 아닙니다.. 

저희 조도 조사를 이어가면서 기존 아이디어를 다시 검토해야 할 때도 있었고, 팀원들이 서로 다르게 이해한 부분을 조정해야 하는 순간도 있었습니다.. 특히 누구 하나 전문적으로 알고 있는 사람이 하나도 없던 금융 도메인이라 더욱 어려웠고 많은 자료 조사가 필요했습니다. 

그래도 그럴 때마다 단순히 각자의 의견을 주장하기보다, 프로젝트의 목표와 고객의 관점으로 돌아가 어떤 방향이 더 적절한지 함께 판단하려고 노력했습니다. 이 과정에서 협업은 단순히 일을 나누는 것이 아니라, 서로의 작업을 이해하고 하나의 결과물로 연결하는 과정이라는 점을 배울 수 있었던 것 같아요. 그렇게 달려온 빅프로젝트..! 치열하게 고민하고 정리하면서 하루하루 보내며 끝이 보였고, 결국 끝이 났습니다. 

7주차 금요일에는 DCC근처 스튜디오에서 다같이 모여 제안 발표를 녹화하고 부지런히 바로 편집에 들어갔습니다.

1분 숏영상도 같이 찍고 편집해야했기 때문에 부지런히 움직였는데요, 8주차 금요일 산출물 제출하는 날엔 정말 2달 간의 긴 프로젝트의 중요한 한 단계를 함께 끝냈다는 점에서 뿌듯함을 느꼈습니다.

(사실 이날이 오프라인 교육장을 사용할 수 있는 마지막 날이었는데요, 저는 몸이 안 좋아서 마지막으로 팀원 분들을 오프라인으로 만나지 못했다는게 좀 아쉬웠네요 ㅠ_ㅠ) 

그래도, 이번 빅프로젝트를 통해 서비스 기획 과정뿐만 아니라, 서로 다른 강점을 가진 팀원들과 목표를 맞추고 결과물을 완성해 나가는 협업의 중요성을 배울 수 있었습니다.

아직 9주차 수요일에 최종 발표가 남아 있는 만큼, 제출한 내용을 다시 점검하고 발표 준비도 팀원들과 함께 차근차근 이어갈 예정입니다.

저희 조가 빅프로젝트를 잘 마무리할 수 있도록 끝까지 많은 응원 부탁드립니다! 😊

지금까지 9기 DX트랙 에이블 기자단이었습니다.
감사합니다!

#KT에이블스쿨 #AIVLESchool #에이블스쿨9기 #DX트랙 #에이블기자단 #빅프로젝트 #AI서비스기획 #팀프로젝트 #협업 

안녕하세요! 9기 DX트랙 에이블 기자단 입니다!
이번에 소개드릴 내용은 빅프로젝트 현장 실무 코칭입니다!  (근데 이제 피자를 곁들인.. 

빅프로젝트가 한창 진행되던 날, 저희 팀의 프로젝트 방향을 점검해 주시기 위해 실무 코치님께서 직접 대전 교육장을 찾아오셨습니다! 👏

매주 화, 목 온라인으로 진행되는 코칭도 많은 도움이 되었지만, 최종 발표 전에 현업에 계시는 코치님을 직접 만나 프로젝트를 설명하고 바로 피드백을 받을 수 있어 더욱 뜻깊은 시간이었습니다.

저희 팀은 카카오뱅크의 퇴직연금 신규 고객을 위한 AI 서비스를 기획하고 있었는데요.

코칭에 앞서 지금까지 조사한 고객의 불편 사항과 서비스 사용자 여정, 주요 기능, 프로토타입을 정리해 코치님께 설명드렸습니다.

이전 실무 코치님께서는 금융 서비스를 기획할 때는 아이디어 자체뿐만 아니라 실제 고객이 어느 단계에서 어려움을 느끼고 이탈하는지, 제안한 기능이 그 문제를 어떻게 해결하는지가 명확하게 연결되어야 한다고 말씀해 주셨습니다.

다행히 해당 내용에 대해 고민해보고 직접 자료 조사하면서 내용 구성의 완성도를 높일 수 있었고, 오늘 방문해주신 현장 코치님께도 잘 준비가 된것 같다는 피드백을 받았어요!! 

그리고 사실 이 날 점심시간에는 깜짝 피자 타임이 이어졌습니다! 🍕✨

팀원들과 함께 피자를 먹으며 잠시 쉬어가는 시간을 가졌는데요. 계속되는 회의와 발표 준비로 지쳐 있던 만큼, 모두 조용히 피자를 먹으며 충분히 쉬는 시간을 가졌습니다..ㅎㅎ 

7주차 현장 방문 실무 코칭을 통해 현업에서는 서비스를 어떤 관점으로 바라보고 검토하는지를 배울 수 있었던 시간이었습니다.

프로젝트에 진심 어린 조언을 전해주신 실무 코치님께 감사드리며, 맛있는 피자와 함께 잠시 에너지를 충전할 수 있도록 준비해 주신 매니저님께도 감사드립니다! 😊💕

코칭에서 받은 피드백을 바탕으로 더욱 완성도 높은 결과물을 만들기 위해 마지막까지 열심히 달려보겠습니다.🔥🔥🔥🔥

#KT에이블스쿨 #에이블스쿨 #에이블스쿨9기 #DX트랙 #에이블기자단 #빅프로젝트 #실무코칭 #현직자코칭 #서비스기획 #금융AX 

안녕하세요! 

이번에 소개드릴 내용은 에이블 스쿨의 특강입니다!

지지난주 월요일 'AI 결과 해석과 컨설팅 제안화'라는 주제로 특강이 진행되었습니다.

빅 프로젝트를 진행하다 보면 자연스럽게 모델의 성능에 집중하게 되는데요, 저 역시 이전 대학시절 캡스톤 할때 Accuracy나 Recall과 같은 성능 지표를 높이는 것이 프로젝트의 가장 중요한 목표라고 생각했던 적이 많았습니다.

하지만 이번 특강은 그 생각을 완전히 바꾸어 준 시간이었습니다.

자세한 내용은 보안상 공유가 불가하지만, 가장 인상 깊었던 것 하나만 꼽으라면 

"좋은 모델보다 중요한 것은 사용할 수 있는 의사결정 구조다."

입니다! 

저는 컴퓨터공학을 전공하며 자연스럽게 모델의 성능이나 알고리즘 구현, 기술적인 완성도에 집중하는 경우가 많았습니다.

프로젝트를 발표할 때도 Accuracy나 Recall과 같은 성능 지표를 중심으로 설명하는 것이 익숙했는데, 하지만 이번 특강에서는 "좋은 모델을 만드는 것"보다 "좋은 비즈니스 의사결정을 만들 수 있는 AI를 설계하는 것"이 더 중요하다는 새로운 관점을 얻을 수 있었습니다.

단순히 모델이 얼마나 정확한지를 설명하는 것이 아니라, 그 결과를 누가 활용하고 어떤 업무가 개선되며 어떤 가치가 창출되는지를 함께 이야기해야 한다는 점이 특히 인상 깊었습니다!! 

KT AIVLE School DX 트랙에서 지금까지 배운 내용과도 자연스럽게 연결되는 강의였는데요, 

DX 컨설턴트는 단순히 AI 기술을 구현하는 사람이 아니라, 기업의 문제를 분석하고 데이터를 기반으로 해결 방안을 제안하며, 기술을 실제 비즈니스 가치로 연결하는 역할을 수행하는 사람입니다. 

이번 특강은 DX 컨설턴트의 역할을 더욱 구체적으로 이해할 수 있는 시간이었고, 기술 중심의 사고에서 한 걸음 더 나아가 고객과 현업의 관점에서 AI를 바라보는 시각을 키울 수 있었습니다.

앞으로 진행할 빅 프로젝트에서도 너무 기술에 집착하느라 단순히 모델의 성능을 높이는 데 그치지 않고, 왜 이 AI가 필요한지, 누구의 어떤 문제를 해결하는지, 그리고 어떤 비즈니스 가치를 만들어낼 수 있는지까지 함께 고민하는 프로젝트를 만들어 보고 싶습니다.

에이블 기자단에 DX트랙으로 지원한 이유가 바로 이 부분이었기 때문에 남은 빅프로젝트까지 더 힘내서 해보겠습니다! 

안녕하세요 :) 다시 돌아온 9기 에이블 기자단입니다. 

몇달 전 KT AIVLE School DX 컨설턴트 트랙 2차 에이블 데이를 마무리했습니다. 

1차때 에이블데이를 경험했지만, 이번 2차에서 다시 소개하자면, 에이블 데이는 KT AIVLE School에서는 교육 과정 중 자신의 성장을 점검할 수 있는 시간입니다. 이번 2차 에이블데이에서도 지금까지 학습한 내용을 바탕으로 코딩테스트에 도전하는 시간을 가졌습니다.

이번 코딩테스트는 단순히 문제를 해결하는 시험이 아니라, 교육 과정에서 배운 Python과 알고리즘 사고력을 실제 문제 해결에 얼마나 적용할 수 있는지를 확인하는 자리였습니다. 제한된 시간 안에 문제를 분석하고, 효율적인 알고리즘을 설계하며 코드를 구현하는 과정에서 평소 학습 습관의 중요성을 다시 한번 느낄 수 있었습니다.

DX, AI트랙 모두 코딩테스트를 수행하면서 다른 에이블러들과 함께 시험을 치르면서 모두가 같은 목표를 향해 성장하고 있다는 분위기를 느낄 수 있었고, 시험이 끝난 뒤에는 서로 풀이 방법을 공유하며 다양한 접근 방식을 배울 수 있었습니다.

1차보다 조금 더 어려워졌다고 느낀 2차 에이블데이 코딩테스트였는데요,

취업 준비를 생각해보면 코딩테스트는 단순 실력 평가가 아니라 현재 나의 역량을 객관적으로 확인하고 앞으로 어떤 부분을 더 보완해야 하는지 알 수 있었던 성장의 기회였습니다.

앞으로도 꾸준한 문제 풀이와 복습을 통해 실력을 더욱 향상시켜 나가고 싶습니다!!!

DX트랙 AI트랙 모두 이제 남은 빅프로젝트까지 파이팅입니다! 

안녕하세요 :) 다시 돌아온 에이블 기자단.... 입니다. 

몇주 전 KT AIVLE School DX 컨설턴트 트랙 6차 미니프로젝트를 마무리했습니다. 

이번 프로젝트는 이전처럼 아이디어를 제안하는 것에서 끝나는 것이 아니라, 실제 서비스를 구축하기 전에 필요한 설계 문서를 작성하는 프로젝트였습니다.주제는 저희 조가 직접 정할 수 있어서 공개하자면 '응급 환자를 위한 최적 병원 실시간 매칭 서비스'였습니다! 

주제 선정에 필수인 도메인 조사를 해보면서 주제를 선정했는데요, 응급 상황에서는 몇 분의 차이가 환자의 생명을 좌우하기도 합니다.

하지만 현실에서는 병원의 수용 가능 여부를 일일이 확인해야 하고, 병원에 도착한 뒤에도 수용이 거부되어 다른 병원으로 이동하는 사례가 발생하기도 합니다. 이번 프로젝트에서는 이러한 문제를 해결하기 위해 실시간 병원 정보와 응급환자 정보를 기반으로 가장 적합한 병원을 추천하는 서비스를 설계했습니다.

이번 프로젝트에서 느낀점

프로젝트를 진행하면서 가장 크게 느낀 점은 좋은 서비스를 만드는 것만큼, 그 서비스를 어떻게 설계하는지가 중요하다는 것이었습니다.

처음에는 서비스를 기획하는 프로젝트라고 생각했지만 실제로는 서비스 기획보다도 설계 문서를 작성하는 과정이 대부분이었습니다.

서비스를 개발하기 전에 어떤 요구사항이 있는지, 어떤 시스템 구조를 사용할지, 장애가 발생하면 어떻게 대응할지를 미리 설계하는 과정이 실제 프로젝트에서 얼마나 중요한지 체감할 수 있었습니다.

이번 프로젝트는 크게 다섯 단계로 진행되었는데요, 간단하게 설명만 하자면! 

먼저 프로젝트의 배경과 문제를 정의했습니다. 응급환자가 발생하면 구급대원은 환자의 상태를 확인한 뒤 여러 병원에 연락하여 수용 가능 여부를 확인해야 합니다. 이 과정에서 시간이 지연되고, 병원에 도착한 뒤에도 병상이 부족하거나 진료가 어려워 다시 다른 병원으로 이동하는 경우가 발생합니다. 우리 팀은 이러한 문제를 해결하기 위해 응급환자의 상태와 병원의 실시간 수용 정보를 기반으로 최적의 병원을 자동 추천하는 플랫폼을 기획했습니다. 이어서 AWS 기반 클라우드 환경을 활용하여 실시간으로 데이터를 처리하는 구조를 제안했습니다.

다음으로는 프로젝트를 조금 더 구체화하기 위해 5W1H 문제 정의서를 작성했습니다. 육하원칙 같은 건데요, 미프를 하면서 새롭게 배우게 된 내용이에요. 이 정의서를 통해 우리가 서비스를 누구를 위해 만드는지, 언제 사용되는지, 왜 필요한지 등을 하나씩 정리하면서 프로젝트의 방향이 더욱 명확해지더라구요. 특히 실제 사용자는 환자가 아니라 119 구급대원과 응급의료센터(B2B!!!!)라는 점을 고려하면서 사용자 관점에서 서비스를 바라보는 연습을 할 수 있었습니다.

다음 단계로는 서비스의 성공 여부를 판단하기 위한 KPI도 설정했습니다.

예를 들어, AI 분석 결과 제공 시간 1초 이내 / 최적 병원 추천 결과 3초 이내 등 실제 서비스 운영 시 측정 가능한 지표를 정의했습니다.

그동안 프로젝트에서는 기능 위주로 생각했다면, 이번에는 정량적인 목표-KPI를 설정하는 방법을 처음 배울 수 있었던 시간이었습니다.

또 이번 프로젝트에서 가장 새롭게 배운 내용은 요구사항 정의였습니다. MoSCoW 기법을 활용하여

• 반드시 필요한 기능(Must Have)
• 있으면 좋은 기능(Should Have)
• 추후 확장 가능한 기능(Could Have)
• 제외할 기능(Won't Have)

위 기능의 우선순위를 나누었습니다.

기능이 많을수록 좋은 서비스라고 생각할 수도 있지만, 실제 프로젝트에서는 예산과 일정이 있기 때문에 우선순위를 정하는 것이 훨씬 중요하다는 것을 알게 되었습니다.

우선순위를 나누고 직접 프로토타입도 개발하면서 서비스가 어떤 문제를 해결하는지 정의하고, 요구사항을 분석하고, 시스템 구조를 설계하고, API를 정의하고, 장애 상황까지 고려해야 비로소 하나의 서비스가 완성된다는 것을 경험할 수 있었던 미프였네요!! 

이번 미프 6차를 정리하면서 DX 컨설턴트는 단순히 좋은 아이디어를 제안하는 사람이 아니라, 실제 구축 가능한 형태로 서비스를 설계하는 사람이라는 점도 알게 되었습니다. 지금까지 진행했던 프로젝트 중에서도 실무 문서를 가장 많이 작성했던 프로젝트였던것 같아요. 후.. 

서비스 기획에서 한 단계 더 나아가 시스템 설계와 아키텍처, 인터페이스 정의, 장애 대응까지 경험하면서 실제 SI 프로젝트가 어떤 방식으로 진행되는지 조금이나마 이해할 수 있었던 의미 있는 시간이었습니다.

컴공 전공으로 본의아니게 계속 기술 중심의 사고를 하는 경향이 있었는데 앞으로의 프로젝트에서 서비스를 기획할 때는 단순히 기능만 생각하는 것이 아니라, "이 서비스를 실제로 어떻게 구현하고 운영할 것인가"까지 함께 고민해봐야겠어요!

매번 플젝에 따라 팀원이 달라서 저같은 내향인이 적응하기 쉽지 않네요,,ㅎㅎ
그래도 이번 프로젝트도 함께 고생한 팀원분들 앞으로도 화이팅입니다!! 

안녕하세요! 에이블 스쿨 기자단입니다! 

최근 마친 7차 미프 시간에는 본격적으로 제조업 분야의 문제에 대해 DX 컨설팅 하는 시간을 가졌습니다! 

보안 상 작성할 수 없는 부분들은 제외하고 한번 블로그에 회고하는 시간을 가지겠습니다. 

특히 7차 미프는 단순히 서비스를 기획하는 것이 아니라 실제 고객사를 대상으로 IT 서비스 제안서와 IT 사업 제안서를 작성하는 프로젝트였습니다. 직접 서비스를 개발하는 입장이 아니라 DX 컨설턴트의 시각에서 고객의 문제를 분석하고, 해결 방안을 제안하는 경험을 할 수 있었던 프로젝트였습니다.

0. 프로젝트 주제

이번 프로젝트의 대주제는 다음과 같습니다. 

00기술 기반 스마트 제조 운영·안전 플랫폼 제안 (정확한 기술명은 프로젝트 보안상 가렸습니다!) 

대주제 이후로는 저희가 직접 설계해가는 내용이라 저희 조는 제안사로 포스코DX를 가정하였고, 제조업 고객사가 가지고 있는 다양한 문제를 해결할 수 있는 스마트팩토리 솔루션을 기획하는 프로젝트였습니다.

최근 제조업에서는 설비 노후화 / 작업자 안전사고 / 품질 불량 / 데이터 분산 관리 등 다양한 문제가 발생하고 있는데요,
특히 중대재해처벌법 강화(이전 아차사고 관련 2차 미프!) 와 스마트 제조혁신 정책 확대 등으로 제조업에서도 AI와 DX 기술의 필요성이 점점 커지고 있다는 점을 프로젝트를 준비하면서 많이 느낄 수 있었습니다.

1. 프로젝트 목표

이번 프로젝트의 목표는 단순했습니다.

"고객이 우리 서비스를 도입해야 하는 이유를 설득하는 것."

생각보다 쉽지 않았습니다.

서비스 기능을 만드는 것보다

• 왜 필요한가?
• 누구를 위한 서비스인가?
• 어떤 문제가 해결되는가?
• 기존 서비스와 무엇이 다른가?

를 논리적으로 설명하는 과정이 훨씬 어려웠습니다.

이번 프로젝트를 통해 서비스 기획과 사업 제안은 완전히 다른 영역이라는 것을 처음 실감했습니다...ㅠ 

2. 프로젝트 진행 과정

이번 프로젝트는 크게 두 단계로 진행되었습니다.

1. IT 서비스 제안서 작성

먼저 제조업 현장의 문제를 분석했습니다.

조사하면서 가장 많이 느낀 점은 제조업에서는 아직도 많은 업무가 사람의 경험에 의존하고 있다는 것이었습니다.

대표적으로 설비 이상 발견 / 작업자 안전관리 / 품질 검사 / 운영 보고 등이 대부분 사람의 판단과 경험에 의존하는 경우가 많았습니다.

2. IT 사업 제안서 작성

서비스를 기획한 이후에는 실제 고객에게 제안하는 사업 제안서를 작성했습니다.

이 과정에서는 사업 배경, 고객 Pain Point, 서비스 범위, 시스템 구성, 구축 방안, 기대 효과, 경쟁사 차별화 등 실제 제안서에서 사용하는 구성으로 작성했습니다. 서비스를 만드는 것보다 "왜 이 서비스를 도입해야 하는가?"를 설명하는 데 훨씬 많은 시간을 투자했던 것 같습니다. 아무래도 기술 개발자와 컨설턴트의 차이가 이것이겠죠! 

최종적으로 제안한 서비스는 스마트 제조 운영·안전 통합 플랫폼인데요,
이후 내용은 너무 세부적인 기술 내용이 들어가서 생략해야할 것 같네요..! 다음 기수 에이블러님들 스포 방지를 위해..ㅎㅎ  

대신 이번 프로젝트에서 가장 어려웠던 부분을 이야기 하자면 경쟁사와의 차별성을 만드는 것이었습니다. 무엇보다 고객사를 납득시키고, 저희 제안사만이 가지는 강점을 찾아야 만들 수 있던 내용이었기 때문에 기업 분석 기술 자료조사도 다루는 시간이었습니다. 

프로젝트를 마치며 이번 7차 미니프로젝트는 지금까지 진행했던 프로젝트 중 가장 컨설팅 실무에 가까웠던 프로젝트였습니다. (그래서인지 산출물도 대박 많음..^^)

서비스를 만드는 것보다 고객을 설득하는 것이 더 어렵다는 것을 느꼈고, 왜 많은 IT 기업에서 서비스 기획자와 DX 컨설턴트에게 비즈니스 관점을 중요하게 요구하는지도 이해할 수 있었습니다.

특히 이번 프로젝트를 통해 "기술은 목적이 아니라 문제를 해결하기 위한 수단"이라는 점을 다시 한번 배울 수 있었습니다.

앞으로 서비스를 기획할 때도 단순히 AI를 적용하는 것이 아니라, "고객은 어떤 문제를 가지고 있고, 이 서비스를 통해 어떤 가치를 얻을 수 있는가?" 를 가장 먼저 고민하는 기획자가 되고 싶네요!!  이번 프로젝트도 함께 고생한 우리 충남충북 7반 19조 팀원분들 감사해요! 빅프로젝트 팀도 이어서 간다는데 빅프도 화이팅....😊!! 

안녕하세요! 에이블 스쿨 기자단입니다! 

지난 3차 미프 시간에는 김대리를 위한 개인 비서 챗봇을 구축하는 시간을 가졌는데요, 보안 상 작성할 수 없는 부분들은 제외하고 한번 블로그에 회고하는 시간을 가졌습니다. 

1. 프로젝트 개요

이번 미니프로젝트 3차에서는 회의 내용을 분석하고, 업무 지시사항을 정리해주는 AI 개인비서 서비스를 구현했다.
서비스 이름은 ‘에이블(AIBLE)’로, 회의록을 단순히 요약하는 수준을 넘어 사용자의 업무 흐름을 도와주는 회의 분석 어시스턴트를 목표로 했다. 프로젝트 주제는 자세히는 말하지 못하지만 간단하게는 다음과 같다.

회의록과 회의 내용을 분석하고, 최소 요구 기능+팀이 원하는 기능을 지원하는 AI 개인비서 구축

실제 업무 환경에서는 회의 내용이 길어질수록 중요한 결정 사항이나 담당 업무를 놓치기 쉽다. 특히 회의에 참석하지 못한 사람이 나중에 내용을 확인해야 하는 경우, 전체 회의록을 읽고 핵심 업무를 파악하는 데 많은 시간이 필요하다.

이번 프로젝트에서는 이러한 문제를 해결하기 위해 회의록 분석, 업무 지시사항 추출, 민감정보 감지, 회의 기반 질의응답, 이메일 발송, 결과 다운로드 기능을 하나의 Streamlit 서비스로 구현했다.

2. 문제 인식

회의 업무에서 가장 큰 문제는 정보가 많다는 점이다.
회의록에는 여러 사람의 발언, 결정 사항, 논의 배경, 일정, 담당 업무가 섞여 있다. 이 중 실제로 사용자가 확인해야 하는 정보는 다음과 같다.

첫째, 회의에서 무엇이 결정되었는지
둘째, 누가 어떤 업무를 맡았는지
셋째, 업무 기한과 우선순위는 무엇인지
넷째, 공유 전에 민감정보가 포함되어 있지는 않은지
다섯째, 회의에 참석하지 못한 사람이 빠르게 내용을 이해할 수 있는지

따라서 이번 프로젝트에서는 단순 요약이 아니라 업무 실행으로 이어질 수 있는 회의 분석 서비스를 만드는 것을 목표로 했다.

3. 서비스 목표

이번 프로젝트의 핵심 목표는 AI가 회의 내용을 이해하고, 사용자가 바로 업무에 활용할 수 있는 형태로 정리해주는 것이었다.

구현 목표는 크게 네 가지였다.

1. 회의록 분석 및 요약
   회의 제목, 목적, 주요 안건, 결정 사항, 전체 요약을 자동으로 정리한다.
2. 담당 업무 및 우선순위 추출
   회의 내용에서 담당자별 업무를 추출하고, 업무의 우선순위를 높음·보통·낮음으로 분류한다.
3. 민감정보 감지 및 보안 경고
   개인정보, 전화번호, 주민번호, 급여·인사 정보, 대외비 표현 등이 포함되어 있는지 확인한다.
4. 업무 후속 처리 지원
   회의 결과를 바탕으로 리마인드 메일을 작성하고, 회의 요약 결과를 TXT 파일로 다운로드할 수 있도록 한다.

4. 구현한 서비스: Meeting AI 회의 분석 어시스턴트

최종 서비스는 Streamlit 기반 웹 인터페이스로 구현했다.
사용자는 회의록 텍스트 파일을 업로드하거나, 음성 파일을 업로드하거나, 직접 텍스트를 입력할 수 있다.

서비스 화면은 KT Enterprise의 업무용 서비스 느낌을 살리기 위해 KT 로고 컬러와 비즈니스용 UI 스타일을 적용했다.
또한 사용자가 기능을 쉽게 사용할 수 있도록 결과 화면을 탭 구조로 나누었다.

최종적으로 구성한 탭은 다음과 같다.

5. 주요 기능 정리

5-1. 회의 내용 분석

회의록을 입력하면 GPT 모델이 회의 내용을 JSON 형식으로 분석한다.
분석 결과에는 회의 제목, 목적, 결정 사항, 담당 업무, 주요 안건, 전체 요약, 키워드가 포함된다.

코드에서는 analyze_meeting() 함수를 통해 회의 내용을 분석했다.

def analyze_meeting(text):
    today = datetime.now().strftime("%Y년 %m월 %d일")

    prompt = f"""
다음은 오늘({today}) 진행된 회의 내용입니다. 아래 JSON 형식으로 분석하세요. 반드시 JSON만 출력하세요.

회의 내용:
{text}

{{
  "meeting_title": "회의 제목",
  "purpose": "회의 목적",
  "decisions": ["결정 사항 리스트"],
  "tasks": [
    {{"person":"담당자","task":"업무 내용","deadline":"기한","priority":"high|medium|low"}}
  ],
  "agenda_items": ["안건 리스트"],
  "summary": "전체 요약",
  "keywords": ["키워드1", "키워드2"]
}}
"""

이 부분에서 중요한 점은 모델이 자유롭게 문장을 생성하는 것이 아니라, 서비스에서 바로 활용할 수 있도록 정해진 JSON 구조로 결과를 반환하도록 설계했다는 점이다.

이를 통해 분석 결과를 회의 요약 탭, 할 일 탭, 이메일 생성, 다운로드 기능에 재사용할 수 있었다.

5-2. 담당 업무 및 우선순위 추출

회의록에서 담당자별 업무를 추출하고, 업무의 중요도를 high, medium, low로 분류했다.
사용자 화면에서는 이를 각각 다음과 같이 표시했다.

PRIORITY_LABEL = {
    "high": "🔴 높음",
    "medium": "🟡 보통",
    "low": "🟢 낮음"
}

이 기능을 통해 사용자는 회의록 전체를 다시 읽지 않아도 누가 어떤 업무를 해야 하는지, 어떤 일을 먼저 처리해야 하는지 빠르게 확인할 수 있다.

특히 회의에 참석하지 못한 사람도 회의 이후 자신의 업무를 바로 파악할 수 있다는 점에서 실무 활용성이 높다고 느꼈다.

5-3. 회의 결과 기반 이메일 생성 및 발송

회의가 끝난 후에는 회의 내용을 참석자나 불참자에게 공유해야 한다.
이를 위해 회의 분석 결과를 바탕으로 리마인드 이메일 초안 생성 기능을 구현했다.

이메일 생성에는 gpt-4o-mini를 사용했고, 다음과 같은 규칙을 프롬프트에 포함했다.

• 정중하고 전문적인 어조로 작성
• 첫 문장은 “KT Enterprise IT기술혁신팀 DX Consulting AI 비서 AIBLE입니다.”로 시작
• 마지막 서명은 “AIBLE 드림”으로 종료
• 직원 개인 서명은 포함하지 않음

또한 SendGrid API를 활용해 실제 이메일 발송 기능도 연결했다.

def send_email(to, subject, body):
    api_key = os.getenv("SENDGRID_API_KEY", "")
    sender = os.getenv("EMAIL_ADDRESS", "")

    resp = requests.post(
        "https://api.sendgrid.com/v3/mail/send",
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json"
        },
        json={
            "personalizations": [
                {
                    "to": [{"email": to}],
                    "subject": subject
                }
            ],
            "from": {"email": sender},
            "content": [
                {
                    "type": "text/plain",
                    "value": body
                }
            ],
        },
    )

    return resp.status_code == 202

이 기능을 통해 회의 분석 결과가 단순히 화면에 출력되는 것에서 끝나지 않고, 실제 업무 커뮤니케이션으로 연결될 수 있도록 했다.

5-4. 회의 내용 기반 질의응답

회의록을 분석한 이후에도 사용자는 추가로 궁금한 점이 생길 수 있다.
예를 들어 “김대리의 주요 업무가 뭐야?”, “가장 급한 일정이 뭐야?”, “회의에서 결정된 사항만 다시 알려줘”와 같은 질문을 할 수 있다.

이를 위해 회의 원문을 시스템 프롬프트에 포함하고, 사용자가 질문하면 회의 내용을 바탕으로 답변하는 챗봇 기능을 구현했다.

full_messages = [
    {
        "role": "system",
        "content": f"{sys_role_chat}\n\n[회의 원문]\n{st.session_state.transcript}"
    }
]

full_messages.extend(st.session_state.messages)

또한 st.session_state.messages를 활용해 대화 기록을 저장하고, 최근 10개의 대화를 기억하도록 구성했다.

이 부분을 통해 단발성 질의응답이 아니라 회의 기반 멀티턴 대화가 가능해졌다.

5-5. TXT 다운로드 기능

회의 분석 결과를 사용자가 다시 보관하거나 공유할 수 있도록 TXT 다운로드 기능도 추가했다.

다운로드 파일에는 다음 내용이 포함된다.

• 회의 제목
• 회의 목적
• 결정 사항
• 주요 안건
• 전체 요약
• 담당 업무 및 우선순위
• 핵심 키워드
• 회의 원문

처음에는 화면에 분석 결과를 출력하는 것만 고려했지만, 실제 업무에서는 결과를 저장하거나 전달해야 할 가능성이 높다고 판단했다.
그래서 st.download_button()을 활용해 회의 결과를 파일로 저장할 수 있도록 개선했다.

6. 사용한 기술 스택

이번 프로젝트에서 사용한 주요 기술은 다음과 같다.

이번 프로젝트에서는 단순히 LLM을 호출하는 것보다, LLM 결과를 서비스 기능과 연결하는 흐름이 중요했다.
특히 JSON 구조화, 세션 상태 관리, 탭 기반 UI 구성, 메일 발송 API 연동 등이 핵심 구현 포인트였다.

7. 프로젝트 시나리오

발표에서는 AB카드 DX 전략 수립 미팅을 예시 시나리오로 사용했다. (합성 시나리오 만들던 인턴 경력이 여기서....)

회의 상황은 다음과 같았다.

• 회의명: AB카드 DX 전략 수립 미팅
• 일시: 2026년 4월 30일 오전 10시
• 장소: 제2회의실
• 참석자: 팀장, 장과장, 박사원
• 김대리: WIS 현장 지원으로 회의 불참
• 에이블: 김대리를 대신해 회의 내용을 기록하고 요약

회의 주제는 AB카드의 디지털 전환 전략 수립이었다.
마케팅 데이터, 고객관리 데이터, 결제 승인 데이터가 분산되어 있는 문제를 해결하고, 데이터 레이크와 웨어하우스를 기반으로 AI 분석 환경을 고도화하는 방향을 논의했다.

이 시나리오를 통해 에이블이 단순 요약 도구가 아니라, 회의에 참석하지 못한 사람을 대신해 내용을 정리하고 후속 업무까지 도와주는 AI 개인비서라는 점을 보여주고자 했다.

8. 우리 조만의 차별점

분석 결과를 TXT 파일로 다운로드할 수 있다.
회의 요약, 담당 업무, 원문을 파일로 저장할 수 있어 회의 결과 관리가 편리하다. 단순히 화면에서 확인하는 것이 아니라 문서화와 공유까지 고려했다.

담당 업무와 우선순위를 자동으로 추출한다.
회의 내용을 사람이 직접 정리하지 않아도 담당자별 업무와 중요도를 자동으로 분류해준다. 이를 통해 업무 누락을 줄이고, 후속 조치의 속도를 높일 수 있다.

9. 구현하면서 어려웠던 점

이번 프로젝트에서 가장 신경 쓴 부분은 LLM 출력 결과를 서비스에서 안정적으로 활용하는 것이었다.

LLM은 자연어 답변에는 강하지만, 서비스 내부에서는 정해진 형식의 데이터가 필요하다.
따라서 회의 분석 결과를 반드시 JSON으로 출력하도록 프롬프트를 설계했고, 이후 json.loads()를 통해 Python 객체로 변환했다.

또 하나의 어려움은 Streamlit의 session_state 관리였다.
회의 분석 결과, 원문, 채팅 기록, 메일 초안이 각각 다른 탭에서 사용되기 때문에 상태를 잘 관리해야 했다.

예를 들어 새로운 회의록을 분석하면 이전 채팅 기록과 메일 본문이 남아 있으면 안 된다.
그래서 새로운 분석이 시작될 때 다음과 같이 상태를 초기화했다.

st.session_state.messages = []
st.session_state.mail_body = ""

이 과정을 통해 사용자가 새로운 회의록을 업로드했을 때 이전 결과와 섞이지 않도록 개선했다.

10. 개선하고 싶은 점

발표에서도 언급했지만 현재 서비스에도 몇 가지 한계가 있다.

첫째, 일정 정보를 텍스트로만 제공하기 때문에 실제 캘린더와 연결되지는 않는다.
향후에는 Google Calendar API를 연동해 회의록에서 추출한 일정을 자동으로 캘린더에 등록할 수 있도록 개선할 수 있다.

둘째, 현재는 한국어 중심으로 동작한다. (김대리가 한국인이긴 해서...)
글로벌 업무 환경을 고려하면 영어, 일본어, 중국어 등 다국어 회의록 분석과 이메일 작성 기능으로 확장할 수 있다.

셋째, 음성 명령은 주변 소음에 영향을 받을 수 있다.
이 부분은 팀원의 아이디어였다. 나는 전혀 고려하지 못한 부분이었는데 꽤나 좋은 아이디어라 생각해서 작성했다. 실제 회의실 환경에서는 여러 사람이 동시에 말하거나 배경 소음이 섞일 수 있으므로, 노이즈 캔슬링이나 화자 분리 기능을 추가하면 정확도를 높일 수 있다.

11. 3차 미프를 통해 배운 점 & 마무리 

이번 프로젝트를 통해 가장 크게 배운 점은 AI 기능을 실제 업무 흐름과 연결하는 방법이었다.

이전까지는 LLM을 활용해 답변을 생성하거나 요약하는 기능에 집중했다면, 이번 프로젝트에서는 요약 결과를 다시 이메일, 다운로드, 질의응답 기능과 연결했다. 단순히 “AI가 답변을 잘하는가”가 아니라, AI가 생성한 결과를 사용자가 실제 업무에서 어떻게 활용할 수 있는가를 고민한 프로젝트였다. 아마 DX로 일하게 되면 이런 부분을 가장 중점적으로 생각해야하지 않을까? 

미프에선 Streamlit을 활용해 사용자가 직접 사용할 수 있는 형태의 UI를 만들면서, AI 서비스에서 인터페이스의 간결함을 학교 다닐때보다 더 크게 느끼고 있다. 학교에서 프로젝트할 땐 컴공과다 보니까 더 완성도 있고 탄탄한 기본 웹/앱 구축하는데 시간을 많이 들렸다면 이젠 그냥 Streamlit을 조금 두드리면 바로 웹사이트가 만들어지니 신기하기도 하다.  

개인적으로 사이드 프로젝트를 하게 된다면 Streamlit을 적극 활용해서 테스트 구축을 위한 시간을 줄이고 문제 정의에 더 시간을 많이 들여야겠다고 생각이 들었다. 미프나 아이데이션 시간을 가질수록 중요한건 문제정의와 도메인에 대한 인식+자발적인 공부라는 생각이 든다.