PROJECT ECHO 2026 졸업 캡스톤 · A6 · 팀 O(1) · 6인 공식 분담 QA · 데이터 2026.03 – 06.10

PHONEME DECOMPOSITION · ECHO를 음소로 쪼개면 →

ECHO.

/EH//K//OW/ 단어를 소리의 최소 단위로 쪼개 오발음을 진단한다

사용자는 두 가지를 불평했다. 못 알아듣는다, 왜 틀렸는지 안 알려준다. 나는 그 둘을 데이터와 콘텐츠로 풀었다.

한국인 영어 발음 교정 앱 ECHO에서 3월 초부터 발표 당일 새벽까지 남긴 기여의 기록이다. 공식 분담은 QA·데이터였지만, 데이터 정제 전 과정을 단독 수행하고 기획·자산·발표 전반에 기여했다. 이 페이지의 모든 주장에는 근거 등급이 붙는다. 기록에 없는 수치와 성과는 싣지 않았다.

87GB+

정제 전 원천 음성 데이터

14,281건

직접 정제한 AI-ready 학습 데이터

39장

자발 제작한 발음 교정 시각 자산

읽는 법

모든 주장에 근거 등급이 붙는다

이 페이지는 프로젝트 중 작성한 용도 중립 기록(원장 6종)과 공식 제출물의 교차 대조에서 나왔다. 주장의 강도는 아래 세 등급을 넘지 않는다.

반영

공식 제출물 또는 최종 발표 전사에서 반영이 확인된 사실. 결과까지 단정한다: "채택되었다", "사용되었다".

기록

작업·대화 기록에서 확인된 수행 사실. 수행은 단정하되 효과·인과는 신중히 쓴다.

진술·공동

본인 진술 기반이거나 팀 공동 수행인 항목. 공동 수행은 반드시 '공동'을 밝힌다.

이 페이지는 프로젝트 중 작성한 기여 기록과 공식 제출물의 교차 대조에서 나왔다. 공식 제출·발표 자료는 하단 ‘더 깊게’에서 직접 열어 확인할 수 있다.

문제 — 마케터

기능이 아니라, 불만에서 출발했다

팀이 '발음 교정 앱'으로 방향을 잡았지만 무엇이 진짜 문제인지에 대한 1차 근거가 없었다. 앱 마켓은 불만 카테고리별 비중 통계를 공개하지 않았다. 그래서 막힌 통계 대신 경쟁 앱 저평점 리뷰 원문을 직접 크롤링해(듀오링고 1점 한국어 리뷰 63건 등) 불만 패턴을 분석했고, 두 갈래로 수렴함을 확인했다.

불만 ①

"맞게 말했는데 자꾸 틀렸대요"

발음을 제대로 인식하지 못한다. 엄격한 앱은 맞는 발음을 틀렸다 하고, 관대한 앱은 틀린 발음을 통과시킨다.

→ 모델이 한국인 발음을 듣게 하는 문제 (데이터)

불만 ②

"틀렸다는데, 어떻게 고치죠?"

왜 틀렸는지, 어떻게 고치는지 알려주지 않는다. 점수만 주거나, 알파벳·IPA(국제 발음 기호)로 설명해 한국인이 따라 할 수 없다.

→ 한국어로 교정을 보여주는 문제 (콘텐츠)

경쟁 앱 1점 리뷰를 직접 크롤링해 도출 기록 진술·증빙 | "두 가지 불만 수렴" 프레임은 제안서 첫 문장으로 채택 반영

직접 분류해 보기 — 불만 분류기

경쟁 앱 저평점 리뷰에서 반복된 불만이다(카드 문구는 취지를 간추린 재구성). 각 카드를 두 갈래 중 하나로 보내 보라. 전부 분류하면 ECHO의 문제 정의가 드러난다.

① 못 알아듣는다

인식 문제 → 데이터

② 왜 틀렸는지 모른다

피드백 문제 → 콘텐츠

0 / 6 분류됨

여섯 개 모두 두 갈래로 수렴한다. 기능을 먼저 정하지 않고 불만에서 출발했더니, ECHO가 풀어야 할 문제가 정확히 둘로 나뉘었다. 모델이 못 알아듣는 문제(데이터)와, 알아들어도 한국어로 설명하지 못하는 문제(콘텐츠). 이 프레임이 제안서 첫 문장이 되었고, 명칭 ECHO도 이 본질(듣고·따라하고·교정받는 반복)에서 나왔다.

명칭 ECHO 기록반영

후보 5종 탐색 → "듣고·따라하고·교정받는 반복"을 메아리에 빗댄 ECHO(English Correction & Hearing Optimization) 선별. 공식 과제명으로 채택되어 전 제출물·발표 제목이 되었다.

리텐션 전략 3종 반영

손실 회피(전망 이론) 근거의 출석 환급, 게임화 속도 챌린지, 캐릭터 BOO. 3종 전부 제안서 본문 → 발표자료 → 설계서 → 중간보고 → 최종 제품으로 채택.

해결 — 마케터 · 전달

채점기가 아니라, 과외 선생님

두 불만의 답은 하나의 태도로 모인다. 맞다·틀리다만 말하는 채점기가 아니라, 어디가 왜 틀렸고 어떻게 고치는지를 학습자의 언어로 짚어 주는 과외 선생님이 된다. 그 언어는 IPA가 아니라 한국어다. 조선시대 영어 학습서 '아학편'(개정판)이 한글로 영어 발음을 적었듯, ECHO는 한국어 음운으로 교정을 보여준다.

이 한국어 음소 피드백이 실제로 선호되는지 학습자 67명 대상 설문으로 검증했다. 한국어 음소 방식이 알파벳·IPA 방식보다 가장 선호됐고(단어 rice 등 전 문항), 이 결과가 최종 발표의 핵심 설득 근거가 되었다. 설계·배포·분석은 팀 공동 수행이다. 진술·공동 반영

기존 앱채점기

"틀렸습니다." 점수와 정오 판정에서 끝난다. 사용자는 무엇을 어떻게 고쳐야 할지 모른 채 같은 실수를 반복한다.

ECHO과외 선생님

"have는 '해브' 대신 '해브(윗니로 아랫입술을 살짝 누르며)'처럼 발음해 보세요. 목을 울리며 소리를 내면 훨씬 자연스러워요." 틀린 음소를 짚고, 한국어로 교정법을 보여준다. 약점 음소까지 한국어로 짚는다: V(브~, 목 울림), AE(애, 입을 옆으로 넓게).

실제 앱 피드백 더 보기

"growth는 '그로우쓰' 대신 '그로우쓰(혀끝을 살짝 깨물고)'처럼, 윗니와 아랫니 사이에 혀끝을 살짝 내밀어 보세요. 첫 문장부터 아주 잘해주셨어요!"

"Curb는 '크브' 대신 '커브'처럼, '어' 소리를 낼 때 혀끝을 살짝 들어 올려보세요."

모두 실제 ECHO 앱이 생성한 피드백이다. 점수·약점 음소·문장별 음소 정렬을 보여주는 실제 화면은 아래 진단 섹션에 있다.

기존 앱 = 채점기 / ECHO = 과외 선생님

틀렸다고만 하는가, 어떻게 고치는지까지 말하는가.

발음 분석 = 받아쓰기 채점

들은 소리를 정답 철자와 한 칸씩 맞춰 어디가 틀렸는지 찾는 일.

좋은 앱 = 공정한 선생님

맞는 걸 틀렸다 하지도, 틀린 걸 봐주지도 않는다.

발표 전체의 용어 장벽을 없애는 쉬운말 번역 가이드로 정리해 팀에 공유했다. 이 비유들은 발표 멘트로 이어졌다. 기록 반영

경쟁 포지셔닝 — 글로벌 1위 ELSA를 선제 배치

심사 1순위 예상 질문("ELSA와 뭐가 다른가")을 발표에 선제 배치하도록 권고했다. 두 축은 '한국인 발음을 잘 인식하는가'와 '피드백을 이해하기 쉬운가'다. 실제 발표에 이 구도가 반영되었다.

★ 목표 영역

한국인 발음 인식 ↑ 한국인 발음 인식 ↓ 피드백 이해 어려움 피드백 이해 쉬움 ELSA 듀오링고 말해보카 ECHO

ELSA는 인식은 정확하지만 피드백이 영어다. "엘사는 피드백이 영어"가 발표 멘트로 쓰였다. 또한 외부 특강에서 업계 실무자의 "발음 분석은 어떤 강사도 못 하고 AI만 할 수 있는 영역" 발언을 제품 존재 이유의 외부 검증으로 포착해 발표 논리 축으로 제안했고, 최종 발표 자료와 도입 멘트에 반영되었다. 반영

불만 ① 해결 — · QA

형식이 다른 두 원천을, 하나의 학습 데이터로

모델이 한국인 발음을 듣게 하려면, 정발음·실제 발음 음소 쌍 데이터가 필요했다. 두 원천은 형식이 전혀 달랐다. L2-ARCTIC은 음성 정렬 파일(TextGrid)에 ARPAbet 표기, AI-Hub 한국인 영어 음성은 JSON 라벨에 IPA 표기. 담당 변경으로 이 정제 전 과정을 단독 수행하게 되었고, 환경 확보부터 검증까지 직접 했다.

87GB+

두 원천 원본

이종 형식 통합

14,281

직접 정제 산출

65,486

서버 통합 전수 검증

SSH

원격 GPU 서버 자력 합류

환경부터 자력 구축 직접 수행

80GB+ 데이터의 일반 다운로드가 반복 실패하자 용량 대조로 원인을 좁혀, 전용 도구(aihubshell)와 WSL을 마련했다. 노트북에서 계속 막히자 가상화(BIOS) 제약을 의심해 데스크탑으로 전환하는 판단까지 내렸다. 원격 GPU 서버 합류용 다단 SSH는 접속 실패 원인(원격 플랫폼 오인)을 로그에서 추적해 해결했다.

정제 규칙 설계 직접 수행

비정상 토큰 포함 발화 제외, 정발음 표기 이상은 표준 음소 변환 도구로 재생성, 분리 표기된 이중모음 병합, 검증된 오픈소스 참조 구현 기준의 41개 ARPAbet 음소 정규화. 스크립트 3종을 작성·실행해 14,281건을 직접 산출했다. 초기 리서치에서 최우선 추천했던 L2-ARCTIC은 실제 채택 데이터셋과 일치했다.

"많이 모은다 ≠ AI-ready" — 정제의 본질은 무엇을 버릴지 정하는 것

AI-Hub 발음 평가(PRN) 라벨에 정제 규칙을 적용하면 어떻게 되는지, 한 단계씩 펼쳐 보라.

원본AI-Hub PRN 라벨: 대규모(학습 91,594 · 검증 11,450건)

− 제외대응 음소 없는 위치 표시(***)를 하나라도 포함한 발화 (전체의 87.8%)

− 제외실제 발음 필드의 비정상 토큰(x · null · nan · 특수문자) 발화

− 제외41개 ARPAbet으로 변환 불가능한 토큰을 가진 발화

= 보존신뢰 가능한 음소 쌍만 남김 (보존율 약 10%)

데이터 담당으로서의 통찰

원본의 약 90%가 정제 과정에서 떨어졌다. 이것은 데이터가 나빠서가 아니라, 오발음 진단 모델이 학습할 수 있는 신뢰 가능한 음소 쌍만 남긴 결과다. 가장 큰 결정은 "얼마나 모으나"가 아니라 "무엇을 버리나"였다.

이 원칙으로 두 원천을 정제해 내가 직접 산출한 1차분이 14,281건이다. 최종 학습에는 2차 처리분과 L2-ARCTIC을 합친 서버 통합본 65,486건(= 61,990 + 3,496)이 쓰였고, 나는 이 통합본 전체를 전수 품질 검사·고정 시드 표본의 원본 대조·학습 전처리 코드 검토로 검증해 최종 발표의 표기 "총 65,486 발화 · 화자 906명"과 정합함을 확인했다. 위 10%는 규칙을 정하려고 일부 데이터로 시험한 결과이고, 61,990건은 그 규칙을 AI-Hub 전체에 적용한 2차 정제분이다. 기록 반영

불만 ② 해결 — PM · 콘텐츠

왜 틀렸는지 보여주는 자산을, 39장

"한국어 설명이 직관적이지 않다"는 문제의 해결책으로 '조음 위치 이미지 제공'이 나왔다. 39개 음소 분량을 동일 품질로 만들어 낼 생산 체계가 필요했다. 필요를 먼저 발굴해 자발 제안하고, 39장 전량을 제작했다.

사양서로 변동성 차단 기록

착수 전 39음소 전수 목록(자음 24 + 모음 15), 한국인 난이도 기준 우선순위 15장 선제작, 파일명·시각 규약을 문서로 확정했다. 특히 유성/무성 8쌍은 입 모양을 공유해, 형상 8개로 자음 16개를 커버하는 효율 규칙을 설계했다.

생성형 AI를 프롬프트로 통제 기록

기준 이미지를 역설계한 표준 템플릿 위에서 '샘플 선검증 후 확산'으로 양산하고, 생성형 AI의 실패 모드(화살표 방향·접촉점 위치)를 좌표 명시·배제 조항 같은 프롬프트 제약으로 통제해 39장을 같은 틀로 통일했다.

직접 제작한 발음 조음 이미지 4종 — 직접 제작한 39장 중 일부(AE · ER · NG · OY). 계열이 달라도 같은 템플릿·같은 표기 규칙을 유지한다.

양방향 검수 — 출력과 입력을 모두 의심한 QA 사이클

결함을 발견하면 원인을 격리해 프롬프트 제약으로 바꿔 재발을 막았다. 다섯 계열에서 반복됐고, 가장 큰 결함은 납품 직전에 잡혔다.

화살표마찰음 공기 화살표가 입 안쪽을 향하던 결함 → 꼬리·화살촉 방향을 좌표로 명시한 최우선 지시문을 만들어 이후 모든 마찰음·파찰음에 이식.

접촉점CH·JH 혀 접촉점이 너무 뒤(연구개)로 그려져 K·G와 혼동 위험 → 후속 작업 영향을 근거로 재생성 결정, "윗앞니 뒤 잇몸~경구개 앞" 명시 + 배제 조항.

예시 오기P·K 어말 예시 카드에 cat(/t/ 종결)이 잘못 들어감 → cup · book으로 재생성.

매핑 오류납품 직전 통합본 검증 중 파열음 zip의 G.png가 구버전 K 이미지로 잘못 매핑된 것을 차단, 진짜 G로 교체 후 나머지 38장 매핑 전수 재확인.

입력 실수본인의 업로드 실수 가능성까지 검수 범위에 넣어, 실제로 EY·OY 중복 첨부를 포착했다. 산출물뿐 아니라 입력 단계까지 의심하는 양방향 검수다.

인계·유지보수 설계 기록

통합본과 그룹별 zip 7종의 이중 구조로 인계하고, 수정 요청이 오면 해당 발음만 재생성해 그 zip만 갱신하는 유지보수 방식을 정의했다. 이 39장은 인앱 '조음 위치 이미지' 기능의 자산으로, 최종 발표에서 기능 동작이 시연되었다. 반영

★ 앱의 학습 뼈대 tracks.json 기록

39장이 '보여주는' 자산이라면, 이건 앱이 무엇을 가르칠지를 정한 콘텐츠 설계다. 원천 자료(PDF 4종)를 수집·문서화하고 큐레이션 정책을 정한 뒤, 트랙 구성 3안을 검토해 하이브리드·학습 경로 방식을 채택했다. 5트랙 · 25챕터 · 206스텝의 학습 데이터로 구축해 인계했고, 이것이 앱 전체 학습 흐름의 뼈대가 되었다.

두 갈래가 만나는 곳 — 시그니처

음소 정렬 진단 — 데이터와 자산이 한 화면에서 만난다

데이터(갈래 A)가 한국인 발음을 알아듣고, 자산(갈래 B)이 한국어로 교정을 보여준다. 두 갈래가 실제 화면에서 합류하는 지점이 이 진단이다. 단어를 고르면 정답 음소열과 한국인 전형 오발음이 한 칸씩 정렬되고, 빨간 칸이 틀린 음소다. 그 음소를 누르면 한국어 조음 카드가 열린다.

PHONEME ALIGNMENT DIAGNOSIS · 재현 데모

단어를 골라 진단을 실행하라

한국인이 가장 자주 혼동하는 자음: R↔L, TH↔S, V↔B. 빨간 음소를 누르면 실제 앱에 쓰인 조음 이미지가 열린다.

정답

내 발음

위 진단은 실제 ECHO 앱의 동작을 그대로 재현한 것이다. 단어를 음소 단위로 정렬해 틀린 음소를 표시하고, 그 음소를 누르면 한국어 조음 이미지(내가 제작한 39장 자산)가 뜨는 흐름이다. 아래는 실제 앱 화면이다.

통과 84점69점 · 교정72점 · 정렬55점 · 다중50점 · 조음

앱 전체 흐름 · 발표 시연 화면

결과

출발점보다 나아졌다 — 그리고 숫자를 사람 말로 옮겼다

정제한 데이터로 학습한 모델의 성능이 최종 발표에서 공개되었다. 세 지표가 모두 기존 모델보다 나아졌다. 그런데 셋이 비슷하게 들려 청중이 혼동하기 쉬웠다. 그 혼동을 푸는 한 줄 정의와 화법을 만들었고, 그것이 슬라이드 제목으로 그대로 채택되었다.

지표 (슬라이드 제목)	한 마디로	기존 모델 → 최종 모델(FiLM-128)
발음 분석의 정확도 상승	잘 듣는가	84.1% → 84.5%
잘못된 피드백이 나올 확률 감소	채점 실수 전체	21.4% → 19.2%
올바른 발음을 오답 처리하는 비율 감소 주 목표	그중 가장 화나는 실수: 맞게 말했는데 틀렸다 함(위 항목의 일부)	5.8% → 4.9% 상대 15.5% 감소

모델 수치 — 팀

세 지표의 측정·개선은 모델 학습 담당의 작업이다. 내가 정제한 데이터가 이 학습의 입력이 되었다. 표의 FiLM-128은 최종 개선 모델의 이름이다.

정의·화법 — 나

16·17·18을 "잘 듣는가 / 채점 실수 전체 / 가장 화나는 실수"로 정의하고 포함관계(18⊂17)와 "100번 중 몇 번" 화법을 확정 → 슬라이드 제목 그대로 채택.

참고로 제안서 단계의 베이스라인 수치는 한국어 평가 화자에서 FAR(틀린 발음을 맞다고 통과시킨 비율)이 화자별로 최대 54.52%였다. 나는 이 모델 영역의 수치를 청중 언어로 옮겼다. "오발음의 절반 이상을 그냥 넘긴다". 수치는 팀(모델)의 것이고, 번역은 나의 것이다.
이 예비 실험은 위 표의 세 지표와 데이터셋·지표가 다른 별도 측정이라, 수치를 표와 직접 비교할 수는 없다.

6월 10일 최종 발표. 검토는 당일 새벽 4시대까지 이어졌고, 발표는 "오발음을 시각적으로 보여주는 방식이 도움이 되겠다"는 취지의 교수 평가로 마무리되었다. 반영

한계 · 배움

끝까지 내가 먼저 짚지 못한 한 가지

결과가 좋았다고 한계가 없던 것은 아니다. 가장 정직하게 적어야 할 한 가지가 남아 있다.

CMU 발음 사전과 실제 발화의 괴리

기록

모델의 정답 발음 기준은 CMU 발음 사전(영어 단어의 표준 발음 기호 사전)이다. 그런데 사전형 표준 발음과 사람이 실제로 말하는 발음 사이에는 괴리가 있다. 이 괴리를 발견하고 원인을 규명했지만, 솔직히 말하면 프로젝트 내내 내가 선제적으로 짚어내지 못했던 영역이다. 마지막에 원인을 셋으로 정리해 방어 논리를 세웠으나, 더 일찍 데이터 단계에서 이 한계를 의심했어야 했다.

원인 1

사전형 발음의 한계

연음·축약(gonna·wanna류)이 표준 표기에 반영되지 않는다.

원인 2

문장 강세·연음 부재

단어를 이어 말할 때 생기는 소리 변화를 사전이 담지 못한다.

원인 3

모국어 간섭

비원어민 화자의 L1(모국어) 습관이 표준과 또 다른 편차를 만든다.

배운 것: 유연한 사고가 필요했다. 내 담당(데이터)이 정답으로 삼은 기준 자체를 의심하는 일은 담당 경계 밖처럼 보였지만, 사실 데이터의 정답이 흔들리면 모델 전체가 흔들린다. 한계를 발견했을 때 숨기지 않고 원인을 규명해 설명 가능한 형태로 바꾼 것은 맞다. 다만 다음에는 내 영역의 전제부터 더 일찍, 더 유연하게 의심하겠다.

협업

6인 팀에서 흐름을 조율한 방식

공식 분담은 QA·데이터였지만, 여러 사람이 만든 산출물이 충돌 없이 하나로 모이도록 하는 일에도 관여했다. 다인 협업에서 품질과 소유권을 지킨 두 가지다.

01 발표 감리 — 적발하고, 분류하고, 추적한다 기록

발표 자료를 두 차례 감리(34장→41장)해 구조 결함과 최우선 이슈 3건(수치 충돌·분담표/일정표 누락·테스트 표 부재)을 적발했다. 특히 "잘못된 피드백" 비율(19.2%)과 부록의 "피드백 적절성 96%"가 서로 모순으로 읽히는 지점을 찾아, 둘이 측정하는 단계가 다름을 규명했다. 검토 32건을 상태표시 체계(🔧7·✅9·⚠️7·💬4·★5)로 분류해 "고칠 것"과 "말로 덮을 것"을 갈랐다.

02 협업 — 원문 불가침 기록

원본 작성자와 보강 담당의 경계를 '원문 무수정 · 추가는 별도 섹션 · 전체 하이라이트'로 명문화해, 다인 문서 협업의 소유권 충돌을 구조적으로 막았다. 이 기준이 이후 프로젝트 문서 작업의 표준이 되었다.

협업의 기록을 넘어, 이 프로젝트를 학술적으로 마무리하는 작업이 남아 있다.

GO DEEPER 집필 중

졸업 논문 — ECHO의 데이터 파이프라인과 발음 진단

이 프로젝트의 데이터 정제 방법론과 음소 정렬 진단 설계를 학술적으로 정리하는 졸업 논문을 집필하고 있다. 완성되면 이 자리에서 전문을 열람할 수 있도록 연결할 예정이다.

PDF

졸업 논문 데이터 정제 · 음소 정렬 진단 방법론

집필 중 · 공개 예정

더 깊게 — 공식 제출물

팀이 제출한 원본 문서

아래는 팀 공동 산출물인 공식 제출·발표 자료다. 위 본문의 〔반영〕 주장을 직접 대조해 볼 수 있다. 내가 본문을 작성한 것은 T2 제안서·T3 1p 요약본이며, 나머지는 팀 공동 자료다.

T22p

원장(내부 기여 기록 6종)은 공개하지 않는다. 이 페이지가 그 정제 파생본이다. 면접에서 특정 주장의 세부 근거가 필요하면 해당 원장·로그로 확인할 수 있다.

ECHO.

모든 주장에 근거 등급이 붙는다

기능이 아니라, 불만에서 출발했다

직접 분류해 보기 — 불만 분류기

① 못 알아듣는다

② 왜 틀렸는지 모른다

명칭 ECHO 기록반영

리텐션 전략 3종 반영

채점기가 아니라, 과외 선생님

기존 앱채점기

ECHO과외 선생님

기존 앱 = 채점기 / ECHO = 과외 선생님

발음 분석 = 받아쓰기 채점

좋은 앱 = 공정한 선생님

경쟁 포지셔닝 — 글로벌 1위 ELSA를 선제 배치

형식이 다른 두 원천을, 하나의 학습 데이터로

환경부터 자력 구축 직접 수행

정제 규칙 설계 직접 수행

"많이 모은다 ≠ AI-ready" — 정제의 본질은 무엇을 버릴지 정하는 것

왜 틀렸는지 보여주는 자산을, 39장

사양서로 변동성 차단 기록

생성형 AI를 프롬프트로 통제 기록

인계·유지보수 설계 기록

★ 앱의 학습 뼈대 tracks.json 기록

음소 정렬 진단 — 데이터와 자산이 한 화면에서 만난다

단어를 골라 진단을 실행하라

출발점보다 나아졌다 — 그리고 숫자를 사람 말로 옮겼다

끝까지 내가 먼저 짚지 못한 한 가지

CMU 발음 사전과 실제 발화의 괴리

사전형 발음의 한계

문장 강세·연음 부재

모국어 간섭

6인 팀에서 흐름을 조율한 방식

01 발표 감리 — 적발하고, 분류하고, 추적한다 기록

02 협업 — 원문 불가침 기록

졸업 논문 — ECHO의 데이터 파이프라인과 발음 진단

팀이 제출한 원본 문서

제안서

제안서 발표자료

제안서 1p 요약본

설계서 발표자료

중간보고 발표자료

최종보고 발표자료