비상비상🚨 벼락치기 토익스피킹 코칭 skill 개선기- ‘평가 도구’에서 ‘말하게 하는 루프’로

시험 직전, 토익스피킹 코칭 스킬을 ‘평가 도구’에서 ‘말하게 하는 루프’로 바꾼 과정

1. 시험이 코앞 입니다. 코덱스의 힘을 빌려보기로 했습니다

토익스피킹(시험이 이번 주 일요일로 다가왔습니다. 준비할 수 있는 시간은 많지 않았고, 지금 필요한 것은 집중력과 스피드입니다. 벼락치기만이 살 길이죠.

그래서 Codex(코덱스)의 힘을 빌려보기로 했습니다. 지난 주차 스터디에서 인상 깊게 들었던 논술 평가 사례글과 다른 학습 스킬들을 코덱스에게 자료로 전달하고, 제 답변을 연습시키고 평가해주는 toeic-speaking-coach Skill(토익스피킹 코칭 스킬)을 만들었습니다.

처음 실행은 잘 되었습니다. 문제 유형에 맞는 질문이 나오고, 답변을 저장하고, 평가와 개선안도 만들어냈습니다. 그런데 궁금했습니다.

이 스킬은 실제로 어떤 순서로 움직이는 걸까요? 무엇을 기준으로 저를 평가하고 개선하고 있는 걸까요?

그래서 코덱스에게 라우팅 흐름(routing flow, 요청이 어떤 처리 경로를 따라가는지)을 플로우 차트로 그려달라고 요청했습니다. 이때 visualize Skill(구조와 흐름을 시각화하는 스킬)을 사용했습니다.

ALT

비즈니스 프로세스 다이어그램

?

2. 플로우 차트에서 발견한 진짜 문제

플로우 차트를 보고 나서, 문제는 실행 실패가 아니라 기본 경로가 너무 많은 일을 맡고 있었다는 것임을 알게 되었습니다.

처음 만든 스킬은 한 답변에 대해 다음을 모두 처리할 수 있었습니다.

• 다섯 가지 문제 유형과 실전 시간 제한

• 답변 평가와 여러 개선 양식

• 표현을 자연스럽게 고치기와 만능 문장 만들기

• 암기 표현과 문장 수집

• 답변 저장과 실행 기록

• 재시도와 학습 계획

기능 자체는 모두 유용했습니다. 하지만 벼락치기 학습자인 제 입장에서는 비효율이 커 보였습니다. 답변을 하고 나면 바로 핵심만 짚어서 피드백을 받고, 다시 답변하면서 연습해야 하는데, 현재 스킬은 너무 많은 평가 항목과 개선 절차를 거치고 있었습니다.

특히 저는 이 시점에 평가 보고서를 많이 받고 싶은 것이 아니었습니다. 평가와 검증은 스킬이 제대로 작동하는지 확인하는 데 필요하지만, 벼락치기 학습자에게 가장 중요한 것은 빨리 말하고, 하나를 고치고, 다시 말하면서 표현을 입에 붙이는 것이었습니다.

3. 사용자에게 필요한 핵심 루프를 다시 정했습니다

그래서 기본 코칭 흐름을 핵심 루프(core loop, 사용자가 반복해서 경험하는 최소 학습 흐름)로 다시 정리했습니다.

one answer(사용자의 답변)
→ requested field(이번에 먼저 볼 평가 항목)
→ one bottleneck(가장 큰 문제 한 가지)
→ one repair(수정할 행동 한 가지)
→ same-prompt retry(같은 문제 재시도)
→ same-gate comparison(같은 기준으로 전후 비교)
→ next prompt(다음 문제) or stop(종료)

다시 말하면 다음과 같습니다.

1. 사용자가 문제 하나에 답합니다.

2. 요청한 항목을 먼저 봅니다.

3. 가장 큰 문제 하나만 고릅니다.

4. 바로 적용할 수정 방법 하나를 제시합니다.

5. 같은 문제를 다시 말하게 합니다.

6. 같은 기준으로 좋아졌는지 비교합니다.

7. 다음 문제로 가거나 멈춥니다.

여기서 중요한 점은 평가를 없애지 않았다는 것입니다. 평가를 사용자에게 부담이 되는 긴 보고서가 아니라, 다음 말하기 행동으로 연결되는 짧은 기록으로 바꾸었습니다.

기본 평가 기록은 다음과 같이 정리했습니다.

verdict(현재 답변에 대한 판단)
+ evidence(관찰 근거) 1개
+ unknowns(확인할 수 없는 부분)
+ primary repair(가장 중요한 수정 한 가지)
+ retry(재시도)
+ gate(통과 기준)
+ next move(다음 행동)

전체 보고서(full report, 모든 평가와 개선 내용을 담은 긴 결과물), 학습 계획(study plan, 여러 회차를 설계하는 계획), 표현 만들기(language building, 학습자의 문장과 표현을 발전시키는 과정)는 사용자가 요청할 때만 실행하도록 뒤로 보냈습니다.

4. 기능을 없앤 것이 아니라, 기본 경로에서 분리했습니다

이 과정에서 여러 개의 실행 스킬을 새로 만들어 사용자의 앞에 세우지는 않았습니다. 기존 toeic-speaking-coach Skill(토익스피킹 코칭 스킬)을 하나의 통합 진입점으로 유지하고, 그 안에서 기본 경로만 가볍게 바꾸었습니다.

핵심은 다음과 같습니다.

• 기본 경로: 한 답변, 한 근거, 한 수정, 한 번의 재시도

• 선택 경로: 전체 보고서, 표현 연습, 만능 문장, 장기 학습 계획

• 지원 기능: 답변 저장, 실행 기록, 시간 기록, 세션 관리

이렇게 하니 스킬의 기능 범위는 유지하면서도, 사용자는 기본적으로 복잡한 기능을 모두 거치지 않고 바로 말하기 연습으로 들어갈 수 있게 되었습니다.

5. 검증: 실제로 핵심 루프가 끝까지 도는가

좋은 설계처럼 보이는 것과 실제로 작동하는 것은 다릅니다. 그래서 핵심 루프를 실제 답변으로 실행해 보았습니다.

검증(verification, 정해둔 조건대로 실제 실행되었는지 확인)에서 확인한 것은 다음과 같습니다.

• 기본 답변 1개가 저장되었습니다.

• 같은 문제 재시도 1개가 새 시도로 생성되었습니다.

• 재시도는 이전 시도와 연결되었습니다.

• 재시도 전후에 같은 통과 기준을 사용했습니다.

• 두 시도가 완료된 뒤에만 세션이 종료되었습니다.

• 사용자의 원문 답변(raw answer, 사용자가 실제로 말한 내용)은 실행 기록(execution log, 처리 과정의 메타데이터 기록)에 노출되지 않았습니다.

검증 결과는 통과였습니다. 이번 검증의 목적은 공식 점수를 산정하는 것이 아니라, 코칭 루프가 약속한 방식으로 실제 실행되는지 확인하는 것이었습니다.

6. 실패 실험: 재시도는 정말 멈추는가

정상 실행만으로는 부족했습니다. 이번에는 실패 실험(failure experiment, 일부러 경계를 깨뜨려 취약점을 찾는 실험)을 했습니다.

질문은 단순했습니다.

같은 문제를 같은 수정 대상으로 세 번 연속 다시 말하게 만들면 어떻게 될까요?

수리 전에는 실제 실행에서 세 번째 시도까지 생성되었습니다. 문서에는 재시도 제한이 있었지만, 실행 저장소가 그 제한을 강제로 막지 못한 것입니다.

그래서 최소 수리(minimal repair, 문제가 발생한 지점만 가장 작게 고치는 작업)를 적용했습니다. 재시도 시작 지점인 retry_started(재시도 시작 기록)에 다음 조건을 넣었습니다.

• 이전 시도가 완료되어 있어야 합니다.

• 이전 시도를 parent attempt(이전 답변 시도)로 연결해야 합니다.

• 재시도 방식(retry mode, 같은 문제 재시도인지 다른 문제 적용인지)을 기록해야 합니다.

• 같은 문제 재시도는 한 번만 허용합니다.

• 다른 문제에 적용하는 전이 연습(parallel transfer, 배운 수리를 다른 문제에 적용하는 연습)은 한 번만 허용합니다.

수리 후 같은 실패 입력을 다시 넣자, 세 번째 같은 문제 재시도는 새 기록을 남기기 전에 차단되었습니다. 같은 기준으로 다시 평가해도 조건을 통과했습니다.

이 실험이 보여준 것은 명확했습니다.

재시도 제한은 문서에 적는 것만으로 충분하지 않고, 사용자의 다음 시도가 만들어지기 전에 실행 환경이 직접 막아야 합니다.

7. 사용자에게 생긴 변화

개선 전

답변
→ 여러 평가 항목
→ 여러 개선 양식
→ 긴 결과물
→ 다음에 무엇을 말할지 불명확

개선 후

답변
→ 문제 한 가지 확인
→ 수정 한 가지
→ 같은 문제 재시도
→ 전후 비교
→ 다음 문제 또는 종료

가장 큰 변화는 스킬이 더 많은 일을 하게 된 것이 아닙니다. 사용자가 더 빨리 다음 말을 할 수 있게 된 것입니다.

평가와 검증은 내부 품질을 지키는 장치로 남겼고, 사용자 화면에서는 말하기 연습을 방해하지 않도록 줄였습니다. 또한 같은 문제를 끝없이 다시 하면서 한 가지 오류에 갇히는 것도 막았습니다.

ALT

한국어 페이지 스크린샷

8. 이번 작업에서 배운 것

첫째, 스킬의 기능이 많다고 사용자에게 더 좋은 것은 아니었습니다. 중요한 것은 기능의 수가 아니라, 사용자가 다음에 무엇을 해야 하는지 바로 알 수 있는가였습니다.

둘째, 스킬을 나누는 목적은 스킬 개수를 늘리는 것이 아니었습니다. 사용자에게 보이는 기본 경로를 더 단순하게 만드는 것이 목적이었습니다.

셋째, 검증은 사용자를 평가하기 위한 절차가 아니라, 코칭 약속이 실제로 지켜지는지 확인하는 장치였습니다.

넷째, 실패 실험을 해보니 가장 중요한 수리는 새로운 기능을 추가하는 것이 아니라, 불필요한 반복을 멈추게 하는 경계에 있었습니다.

마무리

Codex(코덱스)를 이용해 토익스피킹 코칭 스킬의 복잡한 기능을 사용자 중심의 핵심 루프로 다시 정리했습니다. 그리고 실제 실행 검증과 실패 실험을 통해 한 번의 수리와 제한된 재시도가 끝까지 작동하도록 만들었습니다.

가장 필요한 것이 무엇인지 고민하고, 그 고민 끝에 걸린 것에 집중해보는 계기였습니다.