Victor의 AI 레퍼런스

낙동강자전거길 완주기(389km)

Victor’s Reference Note — Tue, 21 Apr 2026 10:45:58 +0900

이번 라이딩은 정보를 전달하기 보단 그간 종주 중 느꼈던 나의 생각들과 느낌들을 정리하고자 합니다.

[작은 회상]

자전거길은 산과 강, 들판과 논길을 따라 이어지는 경우가 많다 보니 벌레를 마주하는 일은 참 흔합니다. 그중에서도 유독 제 눈에 들어오던 건, 제 바퀴 앞을 향해 묵묵히 기어가던 작디작은 애벌레였습니다. 그 모습을 보고 있으면 이상하게도 목적지를 향해 쉼 없이 페달을 굴리는 제 모습이 겹쳐 보였습니다. 그래서 그 작은 친구의 길을 막고 싶지 않아 핸들을 좌우로 틀며 피해가곤 했습니다. 속으로는 조용히 완주를 응원하면서요.
그 작은 생명들을 보며 문득 이런 생각도 들었습니다. 현실에 안주한 채 익숙한 길만 택하며 살아가는 삶도 있겠지만, 때로는 위험을 감수하더라도 돌아가지 않고 정면으로 부딪치며 가장 짧은 길을 뚫고 나아가는 편이 더 빨리 목적지에 닿게 해준다는 것을요. 별것 아닌 장면 같지만, 제게는 그 애벌레들이 그런 마음을 다시 떠올리게 해준 고마운 존재처럼 느껴졌습니다.

[여정의 시작]

와이프가 정리해둔 계획대로 저의 출발은 낙동강 자전거길 하류 시작점인 강정고령보부터 시작되었습니다. 새벽 4시에 출발해 오전 8시에 도착했고, 사전에 알아둔 아침식사 가능한 식당 두 곳 중 먼저 돼지국밥집으로 향했습니다. 그런데 어쩐지 손님도 없어 보이고 가게 분위기도 조용해서, 자연스럽게 ‘완뚝순두부’ 집으로 발길을 돌리게 되었습니다.
순두부는 아침으로 먹기엔 살짝 매콤했지만, 돌솥밥과 함께 나오니 속을 든든하게 채워주는 데는 부족함이 없었습니다. 식사를 하는 내내 옆 테이블에서는 02년생을 선배님이라 부르는 20대 초반쯤 되어 보이는 남녀가 소주를 4~5병이나 마시며 큰 소리로 대화를 나누고 있었는데, 그 순간에는 제 귀를 조금 거슬리게 했습니다. 하지만 시간이 지나 이렇게 돌아보는 지금은, 그 장면 또한 현장을 함께 지켜본 우리 부부에게 소소하게 웃으며 꺼낼 수 있는 추억거리 하나로 남은 것 같습니다.

낙동강자전거길 일정

이제 정말 시작입니다. 강정고령보에 도착해서 장거리 운전으로 식사도 제대로 못하신 우리 띠용가리치킨너겟 바로 사료 급여해드리고 저도 출발하기전 화장실에서 양치부터... (사실 라이딩 전날 임플란트 수술을 해서 운동을 하면 안된다는 의사선생님과 GPT의 조언이 있었습니다) 하고, 생각보단 전날 온 비 덕분에 쌀쌀해진 날씨로 옷을 두겹이나 입고 헤어밴드부터 장갑, 무릎보호대, 헬멧, 그리고 에너지바 두개, 에너지 요술 드링크(이거 먹으면 진짜 힘이 납니다)두 개 까지 야무지게 챙겨서 출발합니다. 아! 이번엔 물통도 두개로 준비하여 하나는 이온음료 그리고 하나는 물로 채워서 아주 마음이 든든하다 못해 넉넉했습니다. 자전거길 가이드는 https://www.youtube.com/watch?v=8vDuMmIknX4 < 이 영상을 참고해서 계획했습니다.

[강정고령보]
다리를 건너는 것으로 시작되는 길입니다. 다음 목적지인 달성보로 가기위해서는 23km를 이동해야합니다. 간만에 하는 라이딩였지만 몸은 금세 기억을 하고 라이딩모드로 전환됨을 느꼈습니다. 처음 라이딩을 시작할 때 벌레를 싫어하는 제가 이제는 조금은 무뎌졌는지 역시나 사람은 환경에 적응을 하는 동물이구나 하는 걸 또 느꼈습니다.(그러고보니 이런 사람이 어떻게 군생활을 한 건지 저 또한 의문입니다.. 그것도 신병교육대 조교로.....) 라이딩을 시작하면서 오늘도 역시나 뱀 친구를 만났습니다. 다행히(?) 이 친구는 살아있진 않았는데 그래도 또 다시 목격을 하니 아! 내가 낙동가자전거길 그리고 국토종주 중이구나 하는 걸 새삼 깨닫게 되었습니다.

[달성보]
달성보에 도착하자 와이프와 띠용이가 저를 반겨줍니다. 정말 힘이 납니다. 이런 게 가족인가 봅니다. 저를 기다려준 그 마음만으로도 다시 달릴 힘이 생깁니다. 고마운 마음을 가슴에 안고 다음 목적지인 합천창녕보를 향해 다시 페달을 밟아갑니다.
가는 길에는 ‘도동서원’을 지나게 됩니다. 잠시 스쳐 지나며 본 것뿐인데도 기와를 얹은 목조 건물들의 위용이 참 인상 깊었습니다. 그리고 이어서 마주한 곳이 무심사였습니다. 처음엔 ‘여기 절이 있네? 이 길로 가는 게 맞나?’ 싶었는데, 무심사를 통과해 가는 길이 맞았습니다. 문제는 그다음부터였습니다. 이 길은 제가 지금까지 올라본 오르막길 중 가장 힘든 구간으로 느껴졌습니다. 그냥 산 하나를 오른다고 생각하면 될 정도였습니다.
많이 힘들었습니다. 정말 숨이 턱끝까지 차오른다는 게 어떤 느낌인지 알 수 있을 만큼 벅찼습니다. 그래도 오기로 버텼습니다. 이를 악물고 처음부터 끝까지 페달을 밟으며 결국 그 오르막을 넘어냈습니다.
오르막길을 오를 때면 늘 떠오르는 말이 있습니다. 예전에 TV에서 이효리라는 가수가 어떤 아이에게 해준 이야기였는데, 저는 그 말을 참 오래 기억하고 있습니다.
“언덕 올라가는 거 너무 힘들지 않니? 내려오는 건 좋은데 올라가는 건 너무 힘들지? 인생이 원래 그런 거야. 서두르지 않고 올라가다 보면 어느새 정상에 올라갈 수 있어. 근데 또 한 가지 가르쳐줄까? 내려오는 건 한 방이야. 훅 간다는 얘기 알지?”
저는 그 말을 오를 때마다 가슴에 되새깁니다. 힘들어도 천천히 올라가면 결국 정상에 닿을 수 있다는 것, 그리고 내려가는 건 생각보다 너무도 순식간이라는 것을요.

무심사 업힐 참고 영상 https://youtu.be/uq8-YdBrw_I?si=dB0zCGOKYW2UdNNT

경사율이 20%가 넘는 구간(11:30부터)

[합천창녕보]
도착하니, 와이프와 띠용이가 저를 반겨줍니다. 완전 기분 띵호와 입니다. 합천창녕보 인증센터에서는 두겹으로 입은 옷 중 한겹을 벗어냅니다. 옷 한벌 벗은 거지만 정말 몸이 가벼워지는 느낌이였습니다. 에너지도 보충해줍니다. 와이프가 집에서 준비해온 오렌지를 입에 넣어줍니다. 참새 마냥 입만 벌리면 알아서 어미새가 넣어줍니다. 달콤하고 행복했습니다. 여기서 요술에너지드링크도 하나 먹어줍니다. 힘이 조금 달릴만 했는데 아침에 먹은 든든한 식사와 그리고 간식 에너지 드링크까지 겸비하니 다시 힘이 납니다. 출발하기 전 와이프가 띠용가리와 함께한 인증사진을 찍어주었습니다. 띠용이는 우리 가정에 '사랑' 그 자체입니다.

[창녕함안보]
가이드에 참고한 유튜브에서 알려준 우회코스로 주행했습니다. 무심사를 오기로 건너온 저는 이 판단을 한 저에게 특급 칭찬을 합니다.
*이미지출처: https://www.youtube.com/watch?v=8vDuMmIknX4

우회도로라서, 대부분이 공도였고 자전거도로가 아니라 조금은 위험했지만 차량 이동이 그렇게 많지 않아서 그나마 괜찮았습니다. 하지만 오르막길은 존재했습니다. 날이 많이 덥지 않아 다행이지 만약 햇빛이 강한 여름날이였다면 몇 번이고 강제로 휴식을 취해야 하는 시간을 가졌을 것 같습니다.

[양산 물문화관]
양산 물문화관까지는 차량으로 이동했습니다. 시간도 낙동강 하류를 완주하기엔 다소 부족했고, 날마저 어두워질 것 같아 결국 ‘뚝순’ 찬스를 사용하게 되었습니다. 사실은 도움을 아주 조금만 받으려 했는데, 차로 들어선 길이 자전거길과 완전히 강 건너편으로 멀어져버리는 바람에 어쩔 수 없이 양산 물문화관까지는 편하게 이동하게 되었습니다.
조금 아쉬운 마음이 없었던 건 아니지만, 나중에 여유를 가지고 국토종주를 처음부터 끝까지 다시 달려볼 생각이 있기 때문에 오늘의 찬스는 감사하게 받아들이기로 했습니다. 그리고 언젠가는 반드시 다시 이 코스를 제 힘으로 정복하리라 마음속으로 다짐해봅니다.
양산 물문화관 인증센터는 처음에 분위기가 꽤 으스스한 산골자락의 법당 쪽으로 잘못 도착했습니다. 순간 ‘여기가 맞나?’ 싶었는데, 알고 보니 인증센터는 건너편에 있었습니다. 와이프 말로는 그 길이야말로 ‘뚝순이가 가장 고생한 길’이었다고 합니다. 그렇게 다시 길을 되돌아 인증센터 근처로 이동했고, 양산 물문화관 인증센터에서는 저 혼자 도장을 찍었습니다. 그리고 드디어 낙동강 하류의 마지막 인증센터인 [낙동강하구둑] 으로 향하기 위해 다시 힘을 내어 출발해봅니다.

[낙동강하구둑]
원래대로라면 국토종주의 마지막 인증센터입니다. 가는 길 내내 설레이는 제 마음이 자전거길 풍경에 있는 바람에 날리는 갈대처럼 살랑입니다. 낙동강하구둑으로 가는길에는 공원+공원+공원 이였습니다. 생각보다 사람이 많았고 그리고 바람에 날리는 민들레꽃씨도 많았습니다. 기억에 하류길에서 도착지로 갈수록 경로 안내가 잘되어있지 않아서 아쉬웠고 덕분에 저는 네이버길 지도를 보면서 이동했지만 이리 갔다 저리 갔다 하며 몇 번의 생고생을 했습니다. 하지만 종착지라는 생각에 계속 힘을 내어 봅니다. 속으로 조금만 더 가면, 조금만 더 가면 도착이다 이제 끝이다. 계속 되내었습니다. 힘이 납니다. 저녁은 뭘로 먹지 하며 행복한 일상의 고민도 곁들여봅니다. 도착지에서 기다릴 띠용가리와 와이프를 생각합니다. 힘이 납니다................ 도착했습니다! 드디어! 도착입니다! 크게 외쳤습니다. "오케이!" [낙동강하구둑] 에서 사진을 찍고 도장도 찍고 마지막 풍경까지 눈도장을 찍어줍니다.

[휴일도스테이]
띠용가리와 함께해야 하는 우리는 애견동반호텔에서 휴식을 취하기로 했습니다. 숙소에 도착한뒤로 내일 라이딩을 위해 착용했던 장비를 재정비합니다. 저녁식사는 점심에 밀면을 많이 먹은 관계로 바나나 하나로 대체합니다. 식사할 때 사진을 찍기로 사전에 얘기해놓았었지만 허기 앞에서 모두 계획은 무산됩니다. 이번 여행에서 음식 사진은 없는걸로........ 띠용가리도 오늘 고단했는지 수건에 물을 적셔서 간단하게 먼지를 닦아내줬는데도 부시시한게 아바이 상태랑 똑같습니다. 그래도 오늘 산책 맘껏하고 어마이와도 알콩달콩 좋은 시간 보내고 차에서도 실컷 바람 쐬게 해줬으니 띠용가리도 행복했을 겁니다.

[칠곡보]
낙동강상류 시작입니다. 출발하기전 인생 돼지국밥집을 만나게 됩니다. 이번 라이딩에서는 와이프가 선택한 음식점들이 사진은 못찍었지만 하나 같이 최고였습니다. 맛도 가격도 영양도 더할나위 없었습니다. 경북까지와서 돼지국밥을 못먹었으면 서운할뻔했는데 되려 인생국밥집을 만나서 행복했습니다. 와이프와 든든하게 식사를 마친 뒤, 근처 마트에서 저는 이온음료를 마나님은 디카페인커피를 사서 이제 다시 출발전 최종 준비를 마칩니다.
사실 오늘 라이딩은 어제가 힘이 들었어서 다음 일정으로 잡을까 고민했었는데 이왕 온거 마무리하는걸로 결심합니다. 다시 마음을 잡아보니, 오늘은 100km 정도만 타면되는거라서 몸도 마음도 매우 가볍다고 최면을 걸어봅니다. 낙동강하류 시작했을때와 동일하게 세팅을 해줍니다. 패달을 밟아봅니다. 확실히 어제 보단 힘찬 패달링이 되진 않습니다. 그래도 낙동강상류길 완주를 마음먹은뒤라 힘을 내 봅니다.

[구미보]
구미보에서는 띠용가리와 와이프를 만나지 못했습니다. 힘이 덜 납니다. 다시금 느꼈습니다. 가족의 소중함을. 그리고 에너지의 원천임을. 구미보에 도착하고나서 도장을 찍는 동안 제 자전거에 관심을 가져주시는 아저씨 두 분과 작은 담소를 나눴습니다. 자전거에 대한 지식 자랑을 맘껏 하시는데 경상도 출신인 아버지 생각이나서 이야기를 끝까지 들어줬습니다. 잠시 벤치에 앉아 있는동안 귀와 입은 쉬지 못했지만 조금이나마 에너지를 축적한 저는 안전한 라이딩을 하라는 인사를 받으며 [낙단보]로 이동합니다.

[낙단보]
낙단보에서는 띠용가리와 와이프를 다시 만났습니다. 역시 힘이 납니다! 낙단보에는 깔끔한 화장실이 있었는데, 이 곳에서 세수도 한번 하고 헤어밴드도 물에 적셔줍니다. 그러면서 잠시 휴식을 취해봅니다. 이 곳에서도 바나나 한개와 에너지드링크를 섭취합니다. 서포트를 해주는 와이프에게 다시금 고마운 마음이 듭니다. 저의 라이딩은 처음과 끝 모두 혼자가 아닌 와이프의 도움으로 완주할 수 있었습니다. 제 마누라가 최고입니다!

[상주보]
상주보에서 띠용가리와 와이프를 만났습니다! 역시나 저의 엔돌핀! 이제 사실상 마지막 인증센터인 [상주상풍교]만 남겨두고 있어서 도착해서도 바로 힘이 났습니다. 그래도 혹시 모르니 잠시 여유를 가져봅니다.
상주보로 오는길은 저를 시험에 들게 하는 오르막길이 많았고 내리막길도 많았습니다. 대부분의 길이 산을 넘어가는 코스였습니다. 내리막길을 가는 동안에 반대편에서 오르막길을 오르고있는 라이더들을 볼 때면 '좀만 힘내! 이제 곧 내리막길이 시작될거야' 라고 속으로 응원했습니다. 그리고 저는 내리막길이 끝난 지점부터는 다시 오르막을 오르는 상황이 반복되었고 이제 정말 끝을 보고 있는 저였기에 여유를 한껏 가지고 천천히 오르고 천천히 내려오고 하는 라이딩을 반복했습니다. 그리고 한가지 느낀게 낙동강하류보다는 낙동강상류길을 라이딩할 때 맞은편에서 오고 있는 라이더들이 인사를 잘 해주었다는 점입니다. 이 점은 참 인상이 깊었는데 상류쪽으로 갈수록 제 마음이 편안해서 인건진 모르겠다만 사람들하고 주고받는 인사가 반가웠습니다. 또 한가지 공유하고 싶은점도 있는데 국토종주를 하는 사람들 대부분이 외국이였다는점입니다. 우리나라 사람들은 대부분 국토종주라기보단 단순 라이딩을 하는 사람들로 보였고, 외국인들이 자전거에 짐도 주렁주렁 달고 있어서 누가봐도 아! 국토종주를 하고 있구나 하는 생각이 들게 하였습니다. 이런걸 보면 우리나라 풍경이 참으로 아름다워서 외국인들이 관광하고 그리고 라이딩을 하기에 좋은 곳이구나 하는 생각이 들어 속으로 제가 살고 있는 이 땅에 국민이라는점이 내심 뿌듯했습니다.

[상주상풍교]
마지막입니다! 낙동강상류길 종점입니다. 안동댐은 국토종주에 포함되지 않고 도장만 찍으면 사실 인정되는거라 무리하지않고 위에서 언급했듯 여유가 된다면 다시 국토종주를 처음부터 끝까지 논스톱으로 할거기 때문에 [상주상풍교]가 저에게는 마지막 여정지입니다. 패달을 밟을때마다 마지막이라는 생각때문에 거리가 줄면 줄수록 기분이 좋아집니다. 처음으로 드롭바를 활용해봅니다. 여태까지는 속도를 내는것보다 지치지 않고 완주를 하는게 목표였기때문에 무리하지 않는 선에서 주행을 이어왔는데 [상주상풍교]는 마지막이기도 하면서 자전거길로 안내도 잘되어 있는 평지로 된 지형이 이어져서 드록바를 잡고 허리를 숙인채 평속 30km 이상은 유지하며 달렸습니다. 새삼 저의 뱃살이 이정도이구나 라는 사실을 자각하게 되는 순간이였습니다. 10km 남았을무렵부터는 조금 아쉬운 마음도 들기 시작했습니다. 어제는 낙동강상류길을 다음에 할까 고민해놓고선 이제는 아쉽다니, 사람 마음 참 갈대같습니다. 5km 남았을때부터는 안동댐에서 먹기로 한 소고기 생각에 침이 고입니다. 간고등어도 먹고 찜닭도 먹을 수 있을 것 같습니다. 저기 멀리서 와이프의 실루엣이 보입니다! 이제 끝인가 봅니다! 와....... 도착했습니다. 행복합니다. 성취감은 이루말할 수 없습니다. 행복한 이 시간이 계속 이어졌으면 좋겠습니다. 제 사랑하는 가족이 저의 처음과 끝을 함께하고 그리고 마지막 도착지점에서의 반김에 조금은 울컥도 합니다. 도착한 기념으로 저의 가장 소중한 와이프와 사진을 찍어봅니다. 와이프왈 "우리 둘 모두 행복해보여요"

[안동댐]
안동댐에 도착해서는 바로 밥부터 먹으러 갑니다. 아래는 제가 도장 찍으러 다녀온 동안에 와이프가 찍어둔 사진입니다.

소고기 먹으러 가봅니다. 그런데, 1인분에 200g 입니다. 혼자서 1kg는 먹을 수 있을 것 같은데,, 양을 제대로 체크 못했습니다. 맛은 좋았지만 재방문 의사는 없습니다. 30분컷으로 10만원 지출했습니다.

허기가 쉽게 가시질 않아 2차로 밥을 먹으러 갑니다. 주차장 직원분의 추천을 받아 간고등어집으로 향했습니다. 3만원 남짓한 비용으로 식사를 했는데, 배가 어찌나 부르던지 우리 띠용가리 덕분(?)에 방으로 안내를 받아 보다 안락한 분위기에서 식사를 마칠 수 있었습니다.
돌아오는 길에는 이제 남은 새재자전거길 일정을 언제로 잡을지 이야기를 나누며, 피곤한 몸을 이끌고 운전대를 잡았습니다. 옆을 돌아보니 하루 종일 저를 응원하고 서포트해주느라 지쳤는지 와이프와 띠용이가 나란히 잠들어 있었습니다. 그 모습이 참 사랑스럽고, 또 괜스레 마음 한편이 몽글몽글해졌습니다.
돌이켜보면 저의 모든 여정에는 늘 저의 반쪽인 와이프가 있었고, 사랑으로 품은 띠용이가 함께하고 있었습니다. 이제 국토종주의 완주를 앞두고 있는 시점에서, 제 가정이 주는 에너지가 결국 저를 움직이게 하는 가장 큰 힘이라는 것을 다시 한 번 깊이 느끼게 됩니다. 제가 여기까지 올 수 있었던 것도 결국은 사랑하는 가족들이 함께해주었기 때문입니다.
앞으로도 저는 제가 사랑하는 가족들과 이런 행복한 여정을 계속 이어가고 싶습니다.
그리고 다시 한 번, 진심으로 고맙고 사랑한다는 말을 전하고 싶습니다.

마누라!!!!!!!!!!!! 사랑합니다!!!! 띠용가리도!!!!!!!! 아바이 띠용가리치킨너겟!!!!!!

낙동강자전거길 끝!

Data Management 실무 정리 ②

Victor’s Reference Note — Tue, 14 Apr 2026 13:30:49 +0900

DATA MANAGEMENT · STORY 02

Data Management 실무 적용 정리 ②

구조를 이해하는 데서 멈추지 않고, 실제 문서와 흐름에 어떻게 적용했는지 제가 정리한 방식대로 풀어보았습니다.

Business Case

Service Context

Requirements

Use Case

Traceability

Data Management 실무 적용 정리 ②

지난 글에서는 Data Management를 어떤 구조로 보고 있는지 전체 관점 위주로 정리했습니다. 이번에는 한 단계 더 들어가서, 그 구조를 실제 업무에 어떻게 적용했고 어떤 기준으로 문서를 구성했는지 정리해보려고 합니다.

실제로 업무를 하다 보면 용어를 이해하는 것만으로는 정리가 끝나지 않습니다. Business Case, Service Context, Service Needs, Requirements, Use Case를 알고 있어도, 문서를 어디까지 어떤 기준으로 나눌지 정하지 않으면 결국 다시 섞이게 됩니다.

저도 처음에는 기능 단위로 정리하려고 했지만, 그렇게 접근하면 상위 목적과 실제 흐름이 분리되어 보이는 경우가 많았습니다. 그래서 현재는 문서 구조와 서비스 흐름을 같이 보는 방식으로 정리하고 있습니다.

1. 실무 적용의 시작점은 “경계”를 나누는 것이었습니다

제가 먼저 했던 일은 기능을 나열하는 것이 아니라, 어떤 내용이 어느 계층에 속하는지 경계를 나누는 것이었습니다. 실제로는 이 경계가 흐려지면 Service Context에 Requirements가 섞이기도 하고, Business Case에 구현 세부사항이 들어가기도 합니다.

그래서 문서를 작성할 때는 먼저 무엇이 목적이고, 무엇이 맥락이며, 무엇이 구체 요구사항인지 를 분리하는 작업부터 잡았습니다. 이 작업이 되어야 뒤에서 Use Case와 Traceability까지 자연스럽게 연결할 수 있었습니다.

2. 제가 실제로 적용한 문서 아키텍처

Practical Document Architecture

Business Case

왜 필요한가 / 어떤 가치와 목적을 설명할 것인가

↓

Service Context

어떤 이해관계자 / 어떤 운영 환경 / 어떤 범위와 제약인지 정리

↓

Service Needs

서비스 관점에서 필요한 기능 그룹과 역할 단위로 정리

Requirements

각 기능 그룹을 조건과 기준으로 구체화

↓

Use Case / Traceability

실제 동작 흐름으로 풀어보고, 상위 문서와 연결 관계를 검증

지금은 이 구조를 기준으로 문서를 보고 있습니다. 상위에서는 “왜 필요한가”를 설명하고, 중간에서는 “어떤 환경에서 어떤 역할이 필요한가”를 정리하며, 하위에서는 “무엇을 어떤 기준으로 구현·검토할 것인가”로 내려가도록 구성했습니다.

이렇게 나누어 보니 각 문서의 목적이 조금 더 분명해졌고, 나중에 Use Case를 만들거나 Traceability를 연결할 때도 어디서 무엇을 가져와야 하는지가 정리되기 시작했습니다.

3. 서비스 관점에서는 기능 그룹 단위로 먼저 묶었습니다

실제 서비스 구조를 볼 때는 세부 기능부터 쪼개기보다, 먼저 기능 그룹 단위로 묶어보는 방식이 더 정리하기 좋았습니다. 제가 적용할 때도 개별 API나 세부 컴포넌트부터 들어가기보다, 상위 기능 그룹을 먼저 정의하고 그 아래에서 역할을 정리했습니다.

Service Architecture View

Gateway + ASR

입력 수신 / 세션 시작 / 음성 인식

Auth

인증·권한 검토 대상

NLU

도메인/인텐트 분류

Dialog Engine

정책 / 대화 흐름 / 응답 결정

Domain Agent

외부 기능 호출 / 도메인 처리

이렇게 먼저 그룹을 나누면 문서를 작성할 때도 정리가 쉬워집니다. 예를 들어 Service Context에서는 이 그룹들이 어떤 역할을 담당하는지와 상호 관계를 설명하고, Requirements에서는 각 그룹별로 어떤 기준과 제약이 필요한지를 구체화하는 방식으로 내려갈 수 있습니다.

특히 실무적으로는 같은 내용을 어디에 적어야 하는지가 자주 헷갈리는데, 기능 그룹을 기준으로 잡아두면 문서 범위를 조금 더 안정적으로 유지할 수 있었습니다.

4. 실제 검토는 서비스 플로우로 풀어보는 방식으로 진행했습니다

구조를 세운 뒤에는 결국 흐름으로 풀어봐야 빠진 부분이 보입니다. 그래서 저는 문서를 검토할 때 정적인 구조도만 보지 않고, 실제 서비스가 어떻게 흘러가는지를 플로우로 다시 정리하는 방식을 같이 사용했습니다.

Operational Flow View

STEP 1

음성 호출

→

STEP 2

세션 시작

→

STEP 3

ASR 처리

→

STEP 4

NLU 분류

→

STEP 5

Dialog 처리

→

STEP 6

Domain 처리

→

STEP 7

응답 생성

→

STEP 8

운영/모니터링

이런 식으로 플로우를 만들어두면 Use Case를 작성할 때도 훨씬 명확해집니다. 각 단계에서 누가 주체인지, 어떤 입력과 출력이 있는지, 어디서 예외가 발생할 수 있는지, 그리고 어떤 항목이 상위 문서와 연결되어야 하는지가 보이기 때문입니다.

5. 적용하면서 가장 많이 조정한 부분

실무 적용 시 조정 포인트

아키텍처상 검토 대상과 Business Case 문서 범위는 항상 동일하지 않았습니다. 예를 들어 인증(Auth)과 같은 영역은 전체 서비스 구조에서는 검토 대상이 될 수 있지만, 현재 기준에서는 예정 기술 여부나 문서 목적에 따라 Business Case 서술 범위에서는 조정이 필요했습니다.

이 부분이 실무적으로 꽤 중요했습니다. 구조도에 들어간다고 해서 반드시 상위 문서에 같은 비중으로 서술해야 하는 것은 아니고, 문서 목적과 현재 범위에 따라 어디까지 다룰지를 다시 판단해야 했습니다.

결국 저는 “전체 구조는 보되, 현재 문서 목적에 맞는 범위만 담는다”는 기준으로 정리하고 있습니다. 그래야 문서가 과하게 넓어지지 않고, 실제 검토 대상도 더 선명해집니다.

6. 정리하고 보니 기준이 더 명확해졌습니다

현재까지 적용하면서 느낀 건, Data Management 실무는 단순히 문서를 채워 넣는 작업이 아니라 서비스를 설명 가능한 구조와 검증 가능한 흐름으로 바꾸는 작업에 가깝다는 점입니다.

문서 아키텍처를 먼저 정리하고, 그 다음 서비스 플로우로 검토하니 어떤 내용이 상위 개념인지, 어떤 내용이 실제 요구사항인지, 그리고 어떤 항목이 Use Case와 Traceability로 연결되어야 하는지가 훨씬 선명하게 보였습니다.

한 줄로 정리하면

제가 현재 적용하고 있는 방식은 Data Management 구조를 문서 계층으로 먼저 정리하고, 이를 실제 서비스 플로우와 연결해 Use Case와 Traceability까지 검증하는 방식입니다.

이번 글에서는 전체 구조를 실제 업무에 어떻게 적용했는지 정리해보았습니다. 다음 글에서는 Use Case와 Traceability를 어떤 기준으로 연결하고 있는지 조금 더 구체적으로 정리해보려고 합니다.

Data Management 실무 정리 ①

Victor’s Reference Note — Tue, 14 Apr 2026 13:26:15 +0900

DATA MANAGEMENT

Data Management 실무 정리 ①

Business Case부터 Use Case까지, 현재 제가 업무를 정리하는 흐름을 기준으로 구조를 정리해보았습니다.

Business Case

Service Context

Service Needs

Requirements

Use Case

Data Management 실무 정리 ①

최근 Data Management 관련 업무를 진행하면서 가장 먼저 느낀 건, 문서를 많이 만드는 것보다 전체 구조를 일관되게 정리하는 것이 더 중요하다는 점이었습니다.

실무를 하다 보면 Business Case, Service Context, Service Needs, Requirements, Use Case 같은 항목들을 계속 보게 됩니다. 처음에는 각각의 정의를 이해하는 데 집중하게 되지만, 실제로는 이 항목들이 따로 존재하는 것이 아니라 하나의 흐름으로 연결되어 있다는 점을 보는 것이 더 중요하다고 생각하고 있습니다.

한눈에 보는 정리 플로우

STEP 1

Business Case

→

STEP 2

Service Context

→

STEP 3

Service Needs

→

STEP 4

Requirements

→

STEP 5

Use Case

제가 현재 업무를 정리하는 흐름도 크게 다르지 않습니다. 먼저 왜 필요한지를 Business Case에서 정리하고, 그 다음 어떤 환경과 전제가 있는지를 Service Context에서 봅니다. 이후 Service Needs와 Requirements로 내려가며 필요한 내용을 구체화하고, 마지막에는 Use Case를 통해 실제 흐름으로 검증하는 구조로 보고 있습니다.

문서 아키텍처 관점에서 보면

Data Management Document Architecture

Business Case

왜 필요한가 / 어떤 가치를 만드는가

↓

Service Context

어떤 환경 / 어떤 이해관계자 / 어떤 제약이 있는가

↓

Service Needs

서비스가 성립되기 위해 필요한 요소와 구조를 정리

Requirements

필요 요소를 조건과 기준으로 구체화

↓

Use Case / Traceability

실제 흐름으로 검증하고 연결 관계를 확인

이렇게 보면 Data Management는 단순히 항목별 문서를 나누는 작업이라기보다, 서비스와 요구사항을 설명 가능한 구조로 아키텍처화하는 작업에 더 가깝습니다. 그래서 각 문서의 완성도만 보는 것이 아니라, 앞 단계와 뒤 단계가 얼마나 자연스럽게 이어지는지를 같이 봐야 한다고 생각합니다.

제가 현재 중요하게 보고 있는 포인트

첫 번째는 출발점입니다. Business Case가 명확해야 뒤에 이어지는 문서들도 방향을 잃지 않습니다. 이 단계가 흐려지면 Service Context도 애매해지고, 결국 Requirements까지 내려갔을 때 기준이 흔들리기 쉽습니다.

두 번째는 연결 관계입니다. 실무에서는 문서 하나하나가 잘 써져 있는 것보다, 어떤 항목이 상위 개념이고 어떤 항목이 이를 구체화하는지가 더 중요하게 느껴집니다. 문서가 많아질수록 이 연결 관계가 더 중요해집니다.

세 번째는 검증 관점입니다. Use Case는 단순한 예시 시나리오가 아니라, 앞에서 정리한 구조가 실제 동작 관점에서도 맞는지 확인하는 단계라고 보고 있습니다. 문서상으로는 자연스러워 보여도 흐름으로 풀어보면 빠진 부분이 의외로 잘 보입니다.

정리하면

제가 보고 있는 Data Management의 핵심은 개별 문서 작성 자체보다, Business Case부터 Service Context, Service Needs, Requirements, Use Case까지 이어지는 흐름을 하나의 구조로 정리하고 검증하는 데 있습니다.

이번 글은 현재 제가 업무를 진행하면서 정리하고 있는 전체 관점을 가볍게 정리한 첫 번째 기록입니다. 다음 글에서는 Business Case와 Service Context를 조금 더 실무 관점에서 나누어 정리해보려고 합니다.

신규 STT 엔진의 WER 분석

Victor’s Reference Note — Tue, 3 Feb 2026 08:30:31 +0900

목적

본 보고서는 새로운 음성 인식(Speech-to-Text, STT) 엔진의 성능을 평가하기 위해 단어 오류율(WER, Word Error Rate)을 분석한 내용을 다룹니다.

WER은 STT 엔진의 성능을 평가하는 데 사용되는 중요한 지표로, 이 문서는 STT 엔진의 WER 평가 절차, 오류 처리 방식, 통합 고려사항 등을 설명하며, [KR2] 환경에서의 통합 및 배포와 관련된 기술적 사항을 정리하였습니다.

내용

WER(Word Error Rate) 소개

WER은 음성 인식 엔진의 성능을 평가하는 데 사용되는 일반적인 지표로, STT 엔진이 생성한 텍스트와 참조 텍스트를 비교하여 정확도를 측정합니다.
WER 공식: WER=S+D+INWER = \frac{S + D + I}{N}WER=NS+D+I
- S: 대체된 단어의 수 (잘못 인식된 단어)
- D: 삭제된 단어의 수 (누락된 단어)
- I: 삽입된 단어의 수 (추가된 단어)
- N: 참조 텍스트의 전체 단어 수
WER은 퍼센트로 표현되며, 낮을수록 성능이 우수함을 의미합니다.
Word Error Rate (WER): 음성 인식 성능의 대표적인 지표로, 잘못 인식된 단어, 삽입된 단어, 삭제된 단어의 비율을 나타냅니다. WER이 낮을수록 정확도가 높습니다.
WER=Substitutions+Insertions+DeletionsTotalWordsinReferenceWER = \frac{Substitutions + Insertions + Deletions}{Total Words in Reference}WER=TotalWordsinReferenceSubstitutions+Insertions+Deletions
Sentence Error Rate (SER): 전체 문장이 정확히 인식되지 않은 비율을 측정하며, 문장 단위의 오류를 평가하는 데 유용합니다.
Character Error Rate (CER): WER과 유사하나, 단어 대신 문자 단위로 계산됩니다. 특히 언어적 특성에 따라 유용합니다.
Precision, Recall, F1 Score: 특정 음성 명령어 또는 키워드 인식 성능을 평가하는 데 사용됩니다.
- Precision: 정확히 인식한 키워드의 비율
- Recall: 실제 존재하는 키워드 중 인식한 비율
- F1 Score: Precision과 Recall의 조화 평균
Confusion Matrix: 잘못 인식된 단어들이 어떻게 혼동되는지 보여주는 매트릭스입니다.

Latency (지연 시간): 입력 음성부터 텍스트 변환이 완료되기까지의 시간입니다. 실시간 응용 프로그램에서 중요합니다.
Real-Time Factor (RTF): 처리 속도를 측정하며, 실시간 처리에 얼마나 가까운지를 나타냅니다. RTF가 1 이하이면 실시간 처리가 가능함을 의미합니다.
Throughput: 단위 시간당 처리할 수 있는 음성 입력의 양입니다.

Noise Robustness: 다양한 소음 조건에서의 음성 인식 성능을 평가하며, SNR 변화에 따른 WER 변화를 측정합니다.
Speaker Variability: 다양한 화자의 인식 성능을 평가하며, 연령, 성별, 억양, 방언을 고려합니다.
Domain Adaptability: 특정 도메인에서 사용되는 용어들을 얼마나 잘 인식하는지를 평가합니다.

User Satisfaction: 사용자 만족도를 설문조사나 피드백을 통해 평가합니다.
Error Recovery Rate: 오류 발생 후 문제 해결의 용이성을 측정합니다.
Ease of Use: 인터페이스의 직관성을 평가합니다.

Computational Cost: 음성 인식을 처리하는 데 필요한 리소스(CPU/GPU)의 양을 측정합니다.
Scalability: 시스템의 확장 가능성을 평가합니다.

Multilingual Support: 여러 언어에 대한 음성 인식 성능을 평가하며, 각 언어별 WER을 비교합니다.
Language Model Accuracy: 특정 언어의 발음 및 문법적 구조를 정확하게 반영하는지 평가합니다.

STT 엔진 사양

새로운 STT 엔진의 주요 사양:
- 입력 형식: 최대 30분 길이의 WAV 또는 MP3 오디오 파일
- API 요청: 오디오 파일과 API 키를 포함한 POST 요청
- API 응답: JSON 형식의 텍스트 변환 결과

WER 평가 절차

데이터 수집: 다양한 악센트, 말하기 속도, 배경 소음 수준을 포함한 대표적인 오디오 샘플을 수집하여 명확한 오디오와 어려운 조건의 오디오 모두를 포함합니다.
전사 비교: 각 오디오 파일에 대해 엔진이 생성한 전사 결과를 수작업으로 확인된 참조 텍스트와 비교합니다.
WER 계산: 각 전사 쌍에 대해 WER 공식을 적용하여 엔진의 성능을 측정합니다.
분석: WER 결과를 통해 특정 단어의 오인식, 배경 소음 처리 문제, 불완전한 문장 처리 문제 등을 파악합니다.

오류 처리 및 프로토콜 호환성

불명확한 오디오 처리: 엔진이 불완전하거나 명확하지 않은 오디오를 처리하는 방식과 기존 프로토콜과의 호환성을 확인합니다. 예를 들어, no result UEPD와 같은 오류 코드의 반환 여부를 테스트합니다.
오류 관리: 엔진이 오류를 관리하고 보고하는 방식이 현재 시스템의 오류 관리 프로토콜과 일치하는지 평가합니다.

통합 고려사항

기존 시스템과의 호환성: 새로운 STT 엔진의 텍스트 출력이 Chappie 및 OpenBuilder와 같은 기존 시스템과 원활하게 통합될 수 있는지를 확인합니다.
엔진 위치: [KR2]에 위치할 예정인 새로운 엔진의 배치와 관련된 인프라상의 고려사항을 평가합니다.
직접 API 접근: 중계 서버를 우회하여 STT 엔진에 직접 접근하는 방법의 가능성을 조사하고, 이에 따른 시스템 수정 필요성을 평가합니다.

예시 문장 및 테스트 시나리오

1. 일상적인 대화 문장

"오늘 아침에 일찍 일어나서 산책을 다녀왔어요."
- 목적: 일상적인 대화 속에서의 음성 인식 성능을 평가합니다. 간단한 문장 구조와 일상적인 표현을 통해 엔진이 기본적인 대화를 얼마나 정확하게 인식하는지 확인할 수 있습니다.
"주말에는 친구들과 영화를 보러 갈 예정이에요."
- 목적: 일상 표현을 포함한 문장으로, 엔진이 일반적인 주제에 대한 대화를 정확하게 처리하는지 평가합니다.

2. 숫자와 날짜 포함 문장

"내 생일은 5월 15일이고, 친구 생일은 7월 7일이에요."
- 목적: 날짜와 숫자 인식 정확도를 평가합니다. 숫자와 날짜가 포함된 문장은 음성 인식 엔진이 숫자를 정확하게 처리하는 능력을 테스트하는 데 유용합니다.
"오후 3시 45분에 회의가 있습니다."
- 목적: 시간 표현의 인식 성능을 테스트합니다. 엔진이 시간 관련 정보를 올바르게 인식하는지를 평가합니다.

3. 전문 용어 포함 문장

"의사는 환자에게 진통제와 항생제를 처방했습니다."
- 목적: 의료 분야에서 자주 사용하는 전문 용어가 포함된 문장으로, 엔진이 도메인 특화된 용어를 얼마나 정확하게 인식하는지 평가합니다.
"프로그래머는 코드 리뷰를 통해 버그를 발견했습니다."
- 목적: 기술 용어가 포함된 문장으로, IT 분야의 전문 용어 인식 성능을 테스트합니다. 도메인 특화된 용어에 대한 인식 능력을 평가할 수 있습니다.

4. 유사 발음 단어 포함 문장

"나는 사과를 먹었는데, 그 사과는 정말 맛있었어요."
- 목적: 유사한 발음의 단어("사과")가 반복되는 문장을 통해 음성 인식 엔진이 동일한 발음을 여러 번 인식할 때의 정확도를 평가합니다.
"이 자료는 잘못된 정보가 포함되어 있어요."
- 목적: 발음이 유사한 단어들이 포함된 문장으로, 발음 혼동 상황에서의 인식 성능을 평가합니다.

5. 다양한 화자 변이 포함 문장

"저는 서울에서 태어나서, 표준어를 사용합니다."
- 목적: 억양이나 방언이 없는 표준어 문장을 통해 엔진의 기본 발음 인식 성능을 평가합니다.
"나는 경상도 출신이라서, 사투리를 자주 써요."
- 목적: 특정 방언이나 억양이 포함된 문장을 통해 음성 인식 엔진이 화자의 억양 변이를 얼마나 잘 처리하는지 평가합니다.

6. 복잡한 문장

"오늘은 비가 오고 있어서 우산을 챙겼어요, 그런데 바람이 너무 강해서 우산이 뒤집혔어요."
- 목적: 문장 구조가 복잡하고 길이가 긴 문장을 통해 엔진이 긴 문맥에서 발생하는 복잡한 구문을 얼마나 정확하게 인식하는지 평가합니다.
"내일은 중요한 발표가 있어서 아침 일찍 일어나야 해요, 발표 준비가 다 끝났는지 확인해 주세요."
- 목적: 복합 문장을 통해 음성 인식 엔진의 문맥 이해 능력을 테스트합니다. 긴 문장과 여러 가지 정보를 포함하는 문장에서의 인식 성능을 평가할 수 있습니다.

7. 의도적인 오타 및 정정 문장

"내일 회의는 오전 열 시였지... 아니, 오후 세 시로 변경되었어요."
- 목적: 사용자가 말을 수정하는 상황을 시뮬레이션하여 엔진이 정정된 발언을 얼마나 정확하게 인식하는지 테스트합니다. 오류 복구 능력을 평가할 수 있습니다.

8. 문맥에 따른 다의어 평가 문장

"나는 은행에서 일해, 오늘도 은행에 갔어."
- 목적: 같은 단어("은행")가 다른 의미로 사용되는 상황에서의 인식 성능을 평가합니다. 문맥에 따른 단어 의미 구분 능력을 테스트하는 데 유용합니다.

테스트

테스트 방법

데이터 준비

테스트 문장 선정: 다양한 시나리오에 맞는 테스트 문장을 준비합니다. 예를 들어, 일상적인 대화, 숫자와 날짜가 포함된 문장, 전문 용어가 포함된 문장 등을 선택합니다.
참조 텍스트 준비: 각 테스트 문장의 정확한 텍스트(참조 텍스트)를 준비합니다. 이는 음성 인식 엔진이 제대로 인식했는지 비교하기 위한 기준이 됩니다.
음성 파일 생성: 준비된 테스트 문장을 실제 사람이 발화한 음성 파일로 녹음합니다. 다양한 화자, 억양, 속도, 소음 조건을 고려하여 다양한 음성 데이터를 준비합니다.

음성 인식 엔진 테스트

음성 파일 입력: 준비된 음성 파일을 STT 엔진에 입력합니다. 이 과정은 일반적으로 API 요청을 통해 수행되며, 음성 파일과 함께 API 키를 포함한 POST 요청을 보냅니다.
출력 텍스트 수신: STT 엔진이 음성 파일을 텍스트로 변환하여 반환한 결과(출력 텍스트)를 수신합니다.

WER 계산

비교 작업: STT 엔진이 반환한 출력 텍스트를 참조 텍스트와 비교합니다. 이때 다음 요소를 확인합니다:
- Substitutions: 잘못 인식된 단어의 수
- Insertions: 추가된 단어의 수
- Deletions: 누락된 단어의 수
WER 공식 적용: 다음 공식에 따라 WER을 계산합니다: WER=Substitutions+Insertions+DeletionsTotalWordsWER = \frac{Substitutions + Insertions + Deletions}{Total Words}WER=TotalWordsSubstitutions+Insertions+Deletions 여기서 Total Words는 참조 텍스트의 전체 단어 수입니다.

4. 결과 분석

WER 분석: 계산된 WER 값을 분석하여 음성 인식 엔진의 성능을 평가합니다. WER 값이 낮을수록 인식 성능이 우수함을 의미합니다.
오류 유형 분석: Substitutions, Insertions, Deletions의 비율을 분석하여 주로 발생하는 오류 유형을 파악하고, 개선이 필요한 부분을 확인합니다.

5. 테스트 반복 및 개선

- 다양한 시나리오 테스트: 다양한 시나리오에 대해 반복적으로 테스트를 수행하여 엔진의 전반적인 성능을 평가합니다.
- 피드백 및 개선: 테스트 결과를 바탕으로 음성 인식 엔진을 개선하거나, 최적의 설정을 찾습니다.

음성엔진PoC 업무 관련 검토사항

1. 신규 음성 엔진의 배치 및 인프라 설치

KR2 인프라 설치 필요성
검토사항: 신규 STT 엔진을 테스트하기 위해서는 KR2라는 장소에 인프라를 설치해야 합니다. 이 인프라는 신규 엔진이 정상적으로 작동하고 기존 시스템과의 통합 테스트를 수행할 수 있는 환경을 제공합니다.
대체 가능성: 신규 엔진이 [KR2]에 위치될 예정이나, 기존 엔진과의 직접적인 대체는 현재 사용 중인 VSC가 Kakao i 서비스에 종속되어 있어 어렵습니다. 이로 인해 Kakao와의 협의가 필요하며, VSC에서 STT 엔진을 대체하기 위해서는 시스템 수정이 필요합니다.

2. VSC에서 KC에 설치된 신규 음성 엔진 호출 가능성

검토사항: VSC에서 KC에 설치된 신규 음성 엔진을 호출할 수 있는 방법에 대한 검토가 필요합니다. 현재 VSC는 Kakao i 서비스에 통합되어 있으며, 이를 통해 음성 인식 엔진을 호출하고 있습니다.
대안: STT 엔진 호출이 어려운 경우, 음성을 미리 인식하여 텍스트로 변환한 뒤, 이 텍스트를 VSC의 입력으로 사용하는 방법을 고려할 수 있습니다. 이를 통해 기존 VSC 환경에 대한 대대적인 수정 없이도 음성 인식 결과를 활용할 수 있습니다.

3. 신규 STT 엔진의 텍스트 형식 호환성

검토사항: 신규 STT 엔진이 반환하는 텍스트 형식이 Chappie 엔진 및 오픈빌더에서 문제없이 처리될 수 있는지 확인이 필요합니다.
결론: 텍스트 형식만을 사용하므로, 큰 문제가 없을 것으로 예상됩니다. 다만, 구체적인 테스트를 통해 최종 확인이 필요합니다.

4. 오류 처리 및 현재 프로토콜과의 호환성

검토사항: 신규 STT 엔진이 불완전하거나 명확하지 않은 오디오에 대해 어떻게 오류를 처리하는지 확인해야 합니다. 특히, 현재 사용 중인 오류 관리 프로토콜과 일치하는지 검토가 필요합니다.
현재 상황: 무음 데이터의 경우 "no result UEPD"라는 에러가 반환됩니다. 하지만, 불완전하거나 명확하지 않은 오디오에 대한 처리는 명확하지 않으며, 이로 인해 인식된 결과가 잘못된 분류를 초래할 가능성이 있습니다. 이러한 상황을 테스트를 통해 명확히 하고, 필요한 경우 오류 처리 프로토콜을 수정하거나 보완해야 합니다.

5. 뉴톤을 통한 음성 엔진 호출 및 직접 호출 가능성

검토사항: VSC에서 뉴톤 음성 중계서버를 호출하지 않고, 직접 음성 엔진을 호출할 수 있는지에 대한 확인이 필요합니다.
현재 상황: 현재 VSC는 뉴톤 음성 중계서버를 통해 음성 엔진을 호출하고 있으며, 직접 음성 서버를 사용하는 사례는 없습니다. 내용이 잘못 전달된 것으로 보이며, 이 부분에 대한 추가 확인이 필요합니다.

6. 기타 고려사항

저작권 이슈: 신규 STT 엔진에 대한 저작권 관련 문제와 TTS(speed & volume) 기능 추가 작업이 진행 중입니다. 이와 관련된 사항은 최종 PoC 단계에서 함께 검토해야 합니다.
기존 엔진 대체 검토: 새로운 커스텀 엔진을 사용하는 것과 기존 AI Hub를 적용하는 방법 사이에서의 선택도 고려되고 있습니다. 이 부분에 대해서는 각각의 장단점과 비용 효율성을 분석하여 최종 결정을 내려야 합니다.

음성 인식률 테스트 계획

Victor’s Reference Note — Tue, 3 Feb 2026 08:26:34 +0900

목적

문서 이름: 음성 인식률 성능 테스트 계획서 (가안)
작성 목적: 음성 인식률 90% 이상 달성을 위해 다양한 조건 및 환경을 세분화하여 구체적인 테스트를 수행하고, 테스트 결과를 분석하여 성능을 개선하기 위함.
목표 인식률: 90% 이상
대상 엔진: Custom STT
평가지표: WER (Word Error Rate), 인식 정확도
테스트 환경: 모바일 기기, 네트워크 품질, 통화 시나리오, 배경 소음을 고려한 테스트

내용

1. 데이터 다양성 테스트

1.1 다양한 발화 패턴

테스트 설명: 억양, 속도, 발음의 차이를 반영하여 다양한 사용자 음성 테스트
테스트 조건: 성별(남성, 여성), 나이대(10대, 20대, 30대 이상), 방언(표준어, 지역 방언 포함), 속도(빠름, 보통, 느림)

1.2 배경 소음

테스트 설명: 콜센터 환경을 고려하여, 다양한 배경 소음이 포함된 환경에서의 인식 성능 평가
테스트 조건: 배경 소음 수준(없음, 약간, 보통, 많음), 소음 유형(대화 소음, 차량 소음 등), 위치(실내, 실외)

1.3 실생활 표현

테스트 설명: 실생활 대화와 유사한 구어체 발화를 테스트
테스트 조건: 비공식적 언어, 줄임말, 비속어 포함 여부, 구어체(반말) 및 예의 표현 비교

항목	테스트 설명	테스트 조건	세부 조건
다양한 발화 패턴	다양한 억양, 속도, 발음의 차이를 반영	-성별: 남성, 여성 -나이: 10대, 20대, 30대 이상	• 방언: 표준어, 경상도, 전라도 방언 포함 • 속도: 빠름, 보통, 느림
배경 소음	배경 소음을 포함한 환경에서의 인식 성능	-소음 없음 -낮은 소음 (TV 소리, 공기청정기 등) - 보통 소음 (사무실, 카페) - 높은 소음 (도로, 공사 현장)	• 소음 유형: 대화 소음, 차량 소음 등 • 위치: 실내, 실외
실생활 표현	구어체 및 비공식 발화를 반영	-일상적인 대화 패턴 -줄임말 -비속어 포함 여부	• 구어체(반말) 및 예의 표현 비교

2. 성능 지표 테스트 (WER)

2.1 WER 측정

테스트 설명: 인식된 단어 오류율(WER) 측정을 통해 정확도 확인
테스트 조건: WER 구성 요소(Substitutions, Insertions, Deletions) 기록, 대화 형식 vs. 설명 형식 문장 비교, 명령어 문장(예: "열어") 테스트

2.2 다양한 문장 길이

테스트 설명: 짧은 문장부터 긴 문장까지 문장 길이별 인식 성능 테스트
테스트 조건: 짧은 문장(5단어 이하), 중간 문장(10단어), 긴 문장(15단어 이상), 복잡한 구문(종속절 포함)

2.3 문장 복잡도

테스트 설명: 복잡한 문장 구조나 긴 문장에서의 인식 성능 테스트
테스트 조건: 단순 문장, 종속절 포함 복잡 문장, 질문 형식, 의문문, 명령문, 서술문 차이 비교

3.콜센터 및 핸드폰 기반 테스트

3.1 기기 다양성 테스트

테스트 설명: 다양한 모바일 기기에서 인식률을 확인
테스트 조건: Android, iOS 기기별 인식 성능 비교, 핸드폰 내장 마이크와 유/무선 헤드셋 사용 시 인식률 비교

3.2 통신 환경 테스트

테스트 설명: 네트워크 품질 변화에 따른 인식 성능 확인
테스트 조건: 와이파이, 4G, 5G 연결 품질 및 통화 연결 품질 변화에 따른 인식 성능 확인, 통화 중 신호 세기 변화나 끊김 현상 포함

3.3 콜센터 시나리오 테스트

테스트 설명: 콜센터에서 자주 발생하는 발화 및 응대 패턴에 대한 인식 성능 확인
테스트 조건: 인바운드/아웃바운드 통화에서 고객과 상담사의 발화 패턴에 따른 성능 테스트, 대기음이 포함된 응답 상황 반영

3.4 잡음 환경 테스트

테스트 설명: 다양한 배경 소음을 포함한 통화 환경에서 인식 성능 확인
테스트 조건: 실외(길거리, 차량, 공공장소 등) 및 핸드폰 헤드셋의 노이즈 캔슬링 효과 비교

콜센터 시나리오 테스트 (세분화)

인바운드 테스트

고객 발화 패턴 테스트
- 문의 유형: 고객의 질문, 요청, 불만 등 다양한 발화 유형에 따른 인식 성능 평가
- 반복성 발화: 고객이 동일 질문을 반복하는 경우(예: “다시 한 번 말씀해주세요”) 인식 성능 확인
- 감정 표현: 고객의 다양한 감정(화남, 좌절, 의문 등)에 따른 발음 변화와 이에 따른 인식률 비교
- 배경 소음: 고객이 조용한 환경에서 통화하는 경우와 소음이 있는 환경에서 통화하는 경우(예: 차량 내부, 야외)
상담사 응대 패턴 테스트
- 응답 유형: 상담사의 정보 제공, 확인, 공감 등 응대 방식에 따른 인식 성능 확인
- 대기음 포함 응답: 고객을 대기 상태로 전환 후 다시 연결 시, 대기음이 포함된 응답 시나리오에서 인식률 확인
- 확인 질문 반복: 상담사가 고객 요청에 대해 확인 또는 재확인 질문(예: "이 정보가 맞습니까?")을 할 때의 인식 성능
- 동시 발화: 고객과 상담사가 동시에 발화하는 상황(예: 서로의 말을 끊지 않고 말할 때)에서의 인식 성능 확인

아웃바운드 테스트

상담사 발화 패턴 테스트
- 안내 발화: 상담사가 고객에게 일방적으로 안내할 때의 인식 성능 (예: 제품 안내, 정보 제공 등)
- 질문 발화: 상담사가 고객에게 질문을 던지고, 답변을 기다리는 상황에서의 인식 성능
- 권유 발화: 특정 상품을 권유하거나, 고객의 응답을 이끌어내는 발화(예: "이 상품에 관심 있으십니까?") 시 인식률 평가
- 반복적 발화: 고객이 응답이 없거나 혼란을 보일 때, 상담사가 동일한 정보를 반복하거나 강조하는 상황에서의 인식 성능
고객 반응 패턴 테스트
- 간단 응답: 고객이 짧은 답변(예: "네", "아니요")으로 응답하는 경우와 다양한 억양에 따른 인식률 비교
- 질문 반문: 고객이 상담사의 질문을 다시 질문으로 되묻는 경우(예: "그게 무슨 뜻이죠?")에 대한 인식 성능
- 불만 반응: 고객이 거부하거나 불만을 표시하는 경우의 다양한 발화 패턴 인식률 확인
- 배경 소음: 고객이 소음이 있는 환경(예: 도로, 지하철 등)에서 응답할 경우 인식 성능 확인

4. 모델 성능 최적화

4.1 데이터셋 확장

테스트 설명: 추가 데이터를 통한 모델 최적화
테스트 조건: 방언 및 특수 발음을 포함한 추가 발화 데이터 사용 전후 성능 비교

4.2 전처리 및 후처리 개선

테스트 설명: 소음 제거 및 발화 구분 최적화
테스트 조건: 소음 필터링, 문장 분리 성능, 음성 볼륨 및 톤 변화 대응 여부

항목	테스트 설명	테스트 조건	세부 조건
데이터셋 확장	추가 데이터를 통한 모델 최적화	-추가 발화 데이터: 방언 포함 여부, 특수 발음 포함 여부	• 데이터 확장 전후 성능 비교
전처리 및 후처리 개선	노이즈 제거 및 발화 구분 최적화	-소음 필터링, 문장 분리 성능	• 음성 볼륨 변화, 음성 톤 변화 대응 여부

5. 테스트 수행 방법 및 분석

5.1 테스트 단계별 수행 절차

테스트 준비: 각 테스트 항목에 필요한 데이터와 조건에 맞춘 환경 준비
테스트 수행: 세부 조건에 따른 테스트 케이스 실행
데이터 수집: 각 항목의 성능 데이터 수집(WER 및 인식률 기록)
결과 분석: 인식률 90% 이상 달성 여부 확인 및 개선 사항 분석
결과 보고서 작성: 성능 개선 방안 도출 및 최종 보고서 작성

주요 항목(가안)	문제점	개선 방안	성능 전/후 비교
배경 소음이 높은 환경	인식률 저하	소음 필터링 기능 강화	인식률 85% → 90% 이상
긴 문장 인식	긴 문장에서 WER 증가	문장 분리 후 처리 기능 개선	인식률 80% → 92%
구어체 발화 인식	비공식적 언어 인식률 저조	비공식 발화 데이터 추가 학습	인식률 82% → 90% 이상

음성엔진 교체방안

Victor’s Reference Note — Tue, 3 Feb 2026 08:17:32 +0900

목적

본 내용은 신규 STT 엔진 내재화 전략과 VPN 장비 교체 과정에서의 음성 엔진 교체 여부에 대한 검토 및 대응 방안을 제시합니다.

1. 음성 엔진 교체 여부에 따른 대응 방안

기존 음성 엔진 유지 시
- 기대 효과 및 예측: 기존 음성 엔진을 유지하면 음성 인식 성능에는 변동이 없을 것으로 예상되며, 교체에 따른 추가적 리스크가 최소화됩니다. 이에 따라 안정적인 운영 환경을 유지할 수 있습니다.
- 고객사 고지 필요: 고객사에게 향후 음성 엔진을 교체할 가능성이 있음을 사전에 안내하는 것이 중요합니다. 이로 인해 고객사가 불편함을 느끼지 않도록 충분히 설명하고, 관련 이슈가 발생할 때 빠른 대응이 가능하도록 협의의 장을 마련할 필요가 있습니다.
- 테스트 절차 및 목표: 이관 이후 예상치 못한 음성 인식 오류가 발생할 가능성에 대비해, 전환 후 필수 테스트 절차를 수립할 예정입니다. 해당 테스트는 음성 인식률, 정확도, 응답 속도 등 핵심 성능 지표를 검증하는 것으로, 오류 가능성을 사전에 파악하고 대응 방안을 마련하는 데 목적이 있습니다.
신규 음성 엔진 교체 시
- 성능 저하 가능성 및 예측: 신규 음성 엔진 교체 시 음성 인식 성능의 하향 가능성을 염두에 두어야 합니다. 특히 초기 설정이나 최적화 작업에서 기존 엔진과 차이를 보일 가능성이 크므로, 잠재적인 성능 저하에 대한 대비책을 수립할 필요가 있습니다.
- 성능 기준과 계약 요건: 고객사와의 계약 조건에 따라 음성 인식률은 90% 이상의 기준을 충족해야 합니다. 이를 위해 과거 테스트 자료를 참조하고, 이전 테스트에서 만족했던 기준이 이번 교체 후에도 유지될 수 있도록 적절한 조치를 마련하고 있습니다.
- 추가 테스트 필요성: 음성 엔진 교체 시에는 기존 운영 환경과 새로운 엔진의 인식 성능을 비교 검토하여 오류 가능성을 최소화해야 합니다. 이를 위해 다양한 테스트 시나리오를 설정하고, 기존 엔진과 신규 엔진의 성능을 면밀히 비교하는 방식으로 테스트를 진행할 예정입니다.

2. 고객사와의 협의 사항 및 역할

고객사의 이해 및 협의 필요성: 고객사와의 협의가 중요한 이유는 음성 인식률 유지와 같은 계약 조건이 만족되지 않을 경우, 품질 보장을 위해 추가적인 조정과 협상이 필요할 수 있기 때문입니다. 고객사와의 원활한 소통과 각종 요구 사항 및 우려 사항에 대해 충분히 논의하여 합의를 이끌어내는 것이 중요합니다.
협의 방식: 고객사와의 협의 과정에서 음성 엔진 교체에 따른 잠재적 영향과 이점, 그리고 이에 따른 관리 방안을 투명하게 공유하여 고객사의 신뢰를 구축하는 것이 중요합니다. 고객사와의 협의는 주기적인 성능 보고서 제공, 예상되는 리스크 관리 방안, 사후 관리 절차 등을 포함하는 방식으로 이루어질 수 있습니다.

3. 운영 이슈 관리 및 피로도 문제 해결 방안

운영 이슈의 피로도 해소: 현재까지 지속적인 운영 이슈 처리로 인해 누적된 피로가 존재하며, 이는 원활한 운영을 방해하는 요소로 작용하고 있습니다. 이를 해결하기 위해 운영 이슈와 성능 관련 문제를 동시에 다루는 종합적인 관리 방안이 필요합니다.
효율적 관리 방안 수립: 교체 작업을 통해 운영과 관련된 이슈들을 명확히 정의하고, 이를 체계적으로 관리할 수 있는 방안을 마련하는 것이 필요합니다. 운영 이슈 해결 방안에는 예상치 못한 오류에 대한 사전 대응 방안과 신속한 고객 응대 방안 등이 포함되어야 합니다.

추가 자료 요청

과거 음성 인식 테스트 자료: 기존 음성 엔진의 성능을 검토하고 신규 엔진과의 비교 자료를 확보하기 위해 과거 테스트 자료가 필요합니다.
현재 음성 인식 관련 계약서 주요 요건: 음성 인식률과 관련된 고객사와의 주요 계약 조건을 확인하여, 이를 기준으로 목표 성능을 설정하고 성능 평가에 반영하는 것이 필요합니다.

1. 기술적 영향 요소

기존 시스템과의 호환성: 신규 음성 엔진을 도입할 경우 기존 시스템과의 호환성이 낮을 수 있으며, 이로 인해 예상치 못한 기술적 오류나 연결성 문제(예: 네트워크 지연 또는 응답 지연 등)가 발생할 가능성이 있습니다.
업데이트 및 유지 보수 주기: 신규 음성 엔진의 업데이트 주기와 유지 보수 빈도에 따라 운영 부서의 관리 부담이 증가할 수 있습니다. 특히 새로운 엔진이 기존 운영 팀의 관리 역량을 초과할 경우, 추가적인 학습이나 인력 지원이 필요할 수 있습니다.
긴급 복구 계획: 음성 엔진 교체 후 초기 안정화가 되기 전, 예상치 못한 긴급 복구 상황에 대비한 백업 및 복구 계획이 필요합니다. 특히 신규 엔진의 안정화 기간 동안에는 기존 엔진으로 복구할 수 있는 빠른 대응 절차가 마련되어야 합니다.

2. 고객 경험 및 사용자 피드백 관리

고객 불편 최소화: 음성 인식 오류가 발생할 경우 고객사가 느낄 수 있는 불편을 최소화하기 위한 대응 계획이 필요합니다. 엔진 교체 시 고객의 사용자 경험이 변화할 가능성이 있으며, 특히 음성 인식 오류가 발생할 경우 이를 즉각적으로 해결할 수 있는 프로세스를 마련하는 것이 중요합니다.
사용자 피드백 관리 시스템: 엔진 교체 후 고객사 및 최종 사용자로부터 얻은 피드백을 체계적으로 관리하고, 성능 향상이나 오류 수정에 반영할 수 있는 체계적 시스템이 필요합니다.

3. 운영 측면에서의 리스크

운영 피로도 증가: 신규 엔진 교체와 그에 따른 테스트, 문제 해결 과정에서 운영 주체의 피로도가 더해질 수 있으며, 장기적인 운영 부담으로 이어질 수 있습니다. 이는 운영 관리 측면에서의 적절한 역할 분담과 업무 조율 방안을 수립할 필요가 있음을 시사합니다.
비용 효율성 고려: 음성 엔진의 교체 및 추가적인 테스트, 유지 보수 등 관련 비용을 적절히 산정하여 예산 관리에 반영해야 합니다. 예산 초과가 예상될 경우, 그에 따른 추가 승인 절차나 계획 조정이 필요할 수 있습니다.

4. 계약 및 법적 측면에서의 고려 사항

계약 조건 변경 가능성: 신규 음성 엔진의 성능이 기존과 다를 경우, 고객사와의 계약 조건에 대한 재검토가 필요할 수 있습니다. 성능 변화가 클 경우, SLA(Service Level Agreement) 조건을 수정하거나, 고객사와 새로운 계약 조건을 협의할 가능성을 고려해야 합니다.
데이터 보안 및 프라이버시 규정 준수: 신규 음성 엔진을 사용할 때 음성 데이터의 보안 및 프라이버시 보호 관련 법규 준수를 확인해야 합니다. 특히 데이터 처리 방식이 기존과 달라지거나 외부 클라우드에 의존하게 될 경우, 추가적인 보안 검토와 관리가 요구될 수 있습니다.

5. 장기적 관점에서의 확장 가능성

확장성 및 업데이트 유연성: 신규 음성 엔진이 중장기적으로도 유연하게 업데이트 및 확장될 수 있는 구조를 갖추고 있는지 검토가 필요합니다. 만약 장기적으로 엔진이 구식화되거나 확장성에 한계가 있을 경우, 향후 교체 작업이 필요할 수 있습니다.
기술 트렌드 및 경쟁사 동향 파악: 음성 인식 기술은 빠르게 발전하고 있어, 경쟁사의 기술 도입 현황과 트렌드를 주기적으로 점검하고 내부적으로 비교 분석할 필요가 있습니다. 이를 통해 향후 기술 개선이나 교체 시점에 대한 전략적 의사결정을 뒷받침할 수 있습니다.

신규 음성 엔진 도입 및 성능 검증 계획

Victor’s Reference Note — Tue, 3 Feb 2026 08:16:32 +0900

1. 업무 배경 및 전제 조건

1.1 배경 및 필요성

프로젝트 요구 사항: ** 1.5차 프로젝트 계약서에 명시된 바와 같이, 음성 인식률을 최소 90%로 유지해야 함.
기존 음성 엔진 사용 불가: 현재 사용 중인 음성 엔진을 유지할 수 없는 상황이 발생하여 신규 음성 엔진 도입이 필수적임.

1.2 전제조건

고객사: **
프로젝트 계약서 요구 사항: 음성 인식률 90% 준수
현재 상황: 기존 음성 엔진을 사용하지 못하고 신규 음성 엔진 도입이 필요하며, 운영 중인 현재 엔진의 인식률은 딥러닝 및 학습 데이터가 누적되어 있는 상태.
리스크: 새로운 음성 엔진으로 교체 시 학습 데이터 손실로 인해 인식률 저하 예상.

2. 테스트 방법

❶ 기존 음성 엔진 대비 정확한 성능 평가의 어려움:

기존 엔진은 운영을 통해 딥러닝 기반 학습이 누적된 상태로, 현재 테스트 결과와 신규 엔진을 직접 비교하기에는 어려움이 있음.
초기 설정 및 운영 데이터의 차이로 인해 동일한 테스트 시나리오로도 인식률 비교가 불명확할 가능성이 있음.

❷ 학습 데이터 소실의 리스크:

신규 음성 엔진 전환 시, 기존 엔진에 축적된 학습 데이터가 반영되지 않아 인식률이 하락할 위험이 있음

2.1 테스트 시나리오 준비

구축 당시의 음성 엔진과 현재 운영 중인 엔진의 테스트 시나리오를 그대로 활용하여 신규 음성 엔진을 테스트하는 것이 좋음.
동일한 조건에서 진행하여 현재 엔진과 신규 엔진의 성능을 최대한 비슷하게 비교할 수 있는 데이터를 확보.

2.2 시나리오 및 데이터 처리 방안

일반 발화 테스트: 주요 사용자가 일반 대화에서 자주 사용하는 발화 패턴을 중심으로 테스트합니다. 인식률, 응답 시간, 처리 속도 등을 평가합니다.
고객 상황별 테스트: **에서 자주 사용하는 용어나 발화 유형(e.g: Agit)을 반영하여, 신규 엔진이 실제 운영 환경에 적합한지 확인합니다.
파일럿 테스팅: 새로운 엔진을 소규모로 배포하여 파일럿 테스트를 진행하고, 그 결과를 바탕으로 테스트 방법을 조정합니다. 이렇게 하면 실제 운영 환경에서의 성능을 미리 파악할 수 있습니다.

2.3 학습 데이터 손실에 따른 리스크 관리:

기존 음성 엔진이 학습을 통해 인식률이 향상된 상태이므로, 신규 엔진이 동일한 인식률을 즉시 달성하기 어려울 수 있음을 감안.
신규 엔진이 구축 후 학습을 통해 향후 개선될 여지를 테스트에 반영.

3.구축 당시 음성 엔진, 현재 사용 엔진, 신규 엔진 비교표

구분	구축 당시 음성 엔진	현재 사용 중인 음성 엔진	신규 음성 엔진
음성 인식률 목표	90%	딥러닝으로 인식률 최적화	초기 90% 목표
데이터 학습 상태	초기 상태	학습 데이터 누적	학습 데이터 없음
테스트 환경	동일 시나리오 테스트	운영 환경 시나리오 기반	동일 시나리오 + 추가 테스트
리스크 요인	설정된 시나리오 제한	고도화된 인식률	학습 데이터 손실 가능성
비교 기준	구축 당시 인식률 데이터	현재 운영 데이터 기반 인식률	동일 테스트 후 비교 가능

4. 추가 고려사항 및 실행 방안

4.1 학습 데이터 누적 효과 확인:

기존 음성 엔진이 학습을 통해 인식률이 향상된 상태이므로, 신규 엔진이 동일한 인식률을 즉시 달성하기 어려울 수 있음을 감안.
신규 엔진이 구축 후 학습을 통해 향후 개선될 여지를 테스트에 반영.

4.2 인식률 하락 시 조치 방안 마련:

초기 설정으로도 인식률 목표에 미치지 못할 경우, 학습 데이터 추가나 튜닝 방법을 마련해 장기적인 인식률 향상을 도모할 수 있는 조치 준비.

항목	테스트 설명	테스트 조건	세부 조건
데이터셋 확장	추가 데이터를 통한 모델 최적화	-추가 발화 데이터: 방언 포함 여부, 특수 발음 포함 여부	• 데이터 확장 전후 성능 비교
전처리 및 후처리 개선	노이즈 제거 및 발화 구분 최적화	-소음 필터링, 문장 분리 성능	• 음성 볼륨 변화, 음성 톤 변화 대응 여부

5. KAP(Kakao AI platform) 음성 엔진 정보 요약

1. KAP 개요

정의: Kakao AI Platform(KAP)은 AI 모델 학습과 추론 서비스 환경을 제공하는 클라우드 기반 플랫폼으로, AI 모델을 손쉽게 관리하고 서비스에 적용할 수 있도록 지원합니다.
주요 기능: 모델의 추론(Inference)과 학습(Training), 맞춤형 파인튜닝(Fine-tuning) 기능을 포함하며, 다양한 데이터를 기반으로 한 지속적 최적화가 가능합니다.

2. AI 모델 제공 및 관리

모델 관리: KAP의 Model Catalog에서 제공된 모델 목록을 확인하고, 프로젝트 내에서 필요한 모델을 선택해 추론용 엔드포인트(Inference Endpoint)를 생성할 수 있습니다.
지원 모델: 카카오의 대화형 언어모델 kanana-essence를 시작으로, 향후 텍스트 생성 외 이미지, 오디오 모델 등으로 확장 예정.

3. 모델 등록 및 활용

모델 등록 절차:
- 모델 이름, 종류, GPU 유형, 추론용 엔드포인트 URL, 문서 URL 등 필요한 정보를 입력하여 모델을 등록할 수 있습니다.
- Revision 등록을 통해 버전 업데이트가 가능하며, 이를 통해 추론 성능 향상 및 유지보수가 용이합니다.

4. 기술적 특징 및 관리 옵션

추론 엔드포인트 관리: 생성된 엔드포인트는 모니터링 및 상태관리 기능을 제공하여, 모델 성능을 실시간으로 확인하고 유지할 수 있습니다.
Graceful Option: 배포 시 안정적인 전환을 위한 헬스체크 및 종료 절차 옵션이 제공됩니다.
Binary Download 기능: 모델 업데이트 시 Docker 이미지 대신 모델 Binary만 업데이트할 수 있는 기능으로, 빠른 개선 작업이 가능합니다.

KAP(Kakao AI Platform) AI 모델 등록 및 관리 가이드

Kakao AI Platform(KAP)에서는 kanana-essence를 시작으로 다양한 인공지능 모델을 제공하며, text generation 외에도 image, audio 등 다양한 분야의 AI 모델을 제공할 계획입니다. 모델이 KAP에서 서빙되기 위해서는 특정 절차를 따라야 합니다.

모델 등록 과정

모델 정보 입력
- 모델 이름, 종류, GPU 선택, 태그, 모델 설명 등 기본 정보 입력.
- Inference endpoint URL, 관련 문서 URL, 내부 port 등 활용 정보 입력.
- 활성 상태 설정(Enabled/Disabled), 공개 상태 설정(Private/Public).
Revision 정보 입력
- 모델 버전, Docker 이미지 URL, 배포 상태, 릴리즈 노트 등 입력.
- Graceful Option 설정을 통한 신규 버전으로의 전환 관리.
- Binary Download 사용 여부 설정 및 관련 옵션 설정.
모델 공급 신청
- 공개 전환을 위해 Kakao AI Platform 문의 아지트에서 '모델 공급 신청(공개 전환 요청)' 양식을 통해 신청.

특이사항(Graceful Option 및 Binary Download)

Graceful Option
- Pod가 준비되었는지 확인하기 위한 readiness probe와 pod가 정상적으로 동작 중인지를 확인하기 위한 liveness probe 설정 가능.
Binary Download
- 모델 바이너리만 변경할 경우 사용. Tenth Storage에 미리 업로드된 모델 바이너리를 사용하여 운영.

공개 상태 변경

모델은 기본적으로 'Private' 상태로 등록되며, 'Public' 상태로 전환을 위해서는 승인이 필요합니다. 이 과정은 Kakao AI Platform 문의를 통해 진행됩니다.

모델 카탈로그 및 관리

KAP에서 등록한 모델을 관리할 수 있는 'Model Catalog' 페이지에서 모델 등록 및 관리가 가능.
모델의 Inference Endpoint를 생성하고, 해당 모델의 Detailed Revision History를 조회할 수 있습니다.

추가 고려 사항

모델 공개 요청 시 필요한 정보 제공(사용 목적, 모델 생성 정보, 활용 데이터, GPU 유형 등).
AI 모델이 실제 상용 서비스에 사용될 때 고려해야 할 사항들(health check, timeout, graceful shutdown 등)을 준수하기 위한 설정 필요.

고객센터 콜봇(IVR+콜봇)

Victor’s Reference Note — Tue, 3 Feb 2026 08:16:00 +0900

개요

목적: 디케이테크인의 사업 진행에 따라 통신판매법에 의한 고객 전화 응대가 필수적으로 필요함.
현황: 현재 월데를 통해 카카오워크, 카카오i 등의 문의가 일 10여 건 발생 중이며, 이는 카카오 1:1 고객센터로 처리되고 있음.
운영: 웰데는 기존 업무 프로세스를 유지하며, 고객 CS용 대표번호와 분리하여 운영함.
응대 대상 서비스:
- 카카오워크
- 헤이카카오
- 카카오홈/카카오i
- 카카오 i 커넥트
상담사 인원: 상담사(CS서포터)는 2명으로 구성되며, 전화 응대와 1:1 고객 문의 업무를 진행 중임.
목표: 5월 말까지 고객 전화 응대 기본 세팅을 완료하고, 이후 CS 운영 추이 및 데이터를 통해 음성봇 시나리오를 업데이트할 예정임.

내용

서비스 카테고리:
- 2Depth로 구성될 예정
1차 카테고리:
- 카카오워크
- 헤이카카오, 제품 문의
- 카카오홈, kakao i
- 카카오 i 커넥트
- 기타 문의
시나리오 방향: DTMS 입력을 콜봇을 통해 음성으로 전환하여 방향을 정리함.
기본 제공 서비스: 5월 말까지 서비스 카테고리 확인을 통해 상담사 연결을 제공할 예정.
업무 외 시간 처리: IVR을 통해 1:1 고객센터로 유도할 예정이며, 링크를 전송함.
구축 비용: 구축 비용 검토 진행 중이며, 파트너사에 IVR 포함 인프라 구축 비용 견적 요청.

진행

시스템 구축 일정

프로젝트 기간은 4개월 수행과 1개월 안정화로 총 5개월.

1단계: IPCC(콜 업무)
2단계: 상담 어플리케이션(CMZ 버전)
3단계: 옴니채널 연동 오픈

기능 요구사항

IVR

RQ-0001: DKT 고객센터 콜봇 구축
RQ-0002: 서비스 확인 - call 유입 시 문의하는 서비스에 따라 분기 처리
RQ-0003: 시나리오 구현 - DKT가 제시한 시나리오 문서에 따라 IVR 시나리오 구현
RQ-0004: 시나리오 운영 및 스케줄 기능 - 시나리오 운영 기능과 휴일, 공휴일, 업무시간 지정 기능 제공
RQ-0005: DTMF 기능 - IVR 시나리오 구동 중 DTMF 감지 기능 제공
RQ-0006: 콜백 - 각 서비스 별 인입 번호 콜백 번호 저장 및 상담원 연결 불가 시 콜백 기능
RQ-0007: 콜백 정보 - 상담 APP 연동 - 콜백 정보와 상담 APP 연계 제공
RQ-0008: IVR 편집툴 기능 - UI 방식의 IVR 편집툴 기능 제공
RQ-0009: KICC 콜봇연동 - IVR에서 서비스 확인 후 기타 문의 선택 시 KICC 콜봇으로 연결
RQ-0010: 녹취 - 유저 콜 인입 시점부터 녹취 제공
RQ-0011: 상담원 연결 - 서비스 문의는 상담원으로 연결
RQ-0012: 개인정보 수집 및 상담 진행 안내 - 상담원 연결 전 안내
RQ-0013: 상담원 연결 대기 시 재안내 - 60초 후 재안내 및 상담원 연결 대기 안내 출력
RQ-0014: 유저 DTMF 입력 케이스 - 입력 시간 15초 적용
RQ-0015: 오입력 시 처리 - 직전 IVR 멘트 반복 및 오입력 3회 시 통화 종료
RQ-0016: 유저 무응답/입력 시간 초과 - 통화 종료 안내
RQ-0017: 이전 단계 이동 - 이전 단계로 이동 시 IVR 멘트 재안내
RQ-0018: 장애 발생 - 별도 IVR 멘트로 안내 후 통화 종료
RQ-0019: 근무 외 시간 - 근무 외 시간일 경우 통화 종료 안내

PBX

RQ-0020: SIP 기반 연동 - 070 회선에 직접 연동 가능
RQ-0021: 보안 - 음성 및 데이터 보안 기능 제공
RQ-0022: 대기상태 멘트 - 고객 대기 상태 시 다양한 멘트 제공
RQ-0023: 스팸차단 - 특정 전화번호에 대한 SPAM 전화 차단 기능
RQ-0024: 이중화 - 실시간 데이터 동기화를 통해 호 단절 방지
RQ-0025: 이중화 구성 - 장애 발생 시 기존 통화 유지
RQ-0026: 음성코덱 - OPUS, G.711, G.729 지원
RQ-0027: 조회 - 인입 경로 및 시간과 결과를 추적 조회
RQ-0028: 리소스 모니터링 - 서버 리소스 확인 화면 제공

CTI

RQ-0029: Soft phone 연계 - 소프트폰과 연계하여 상담원 전화 걸고 받기 기능
RQ-0030: 로그인 - 상담원이 어떤 좌석에서도 자신의 ID로 로그인 가능
RQ-0031: 라우팅 설정 - 라우팅 시나리오 최소 30분 단위 설정 가능
RQ-0032: 통계 다운로드 - 통계자료의 엑셀 변환 및 응용 가능
RQ-0033: 권한 - 세분화된 권한 부여 및 관리자가 직접 설정
RQ-0034: 모니터링 - 상담원 상태 및 전체 상담원의 업무 상태 실시간 모니터링
RQ-0035: 이중화 - 이중화 구성으로 서비스 안정성 제공
RQ-0036: 상태 - 최소 10가지 이상의 상태 제공 및 관리자가 직접 수정 가능
RQ-0037: 라우팅 기능 - 옴니채널, 스킬, 실적 균등, 비율, 전담/직전 상담원 등 다양한 라우팅 기능 제공
RQ-0038: 모니터링 - 옴니채널 및 AI에 대한 모니터링 및 통계 제공

녹취

RQ-0039: 관리 - 사용자 접속 이력 등 관리 화면 제공
RQ-0040: 녹음 파일 변환 및 청취 기능 - 다양한 파일 변환 및 청취 기능 제공
RQ-0041: 재생 - 일반적인 플레이어로 재생 가능
RQ-0042: 원본 입증 조작 방지 - 원본 입증 기능 및 변환 파일 조작 여부 확인 가능
RQ-0043: 보관일수 설정 - 파일 용량 등을 고려한 보관일수 설정 기능 제공
RQ-0044: 리포트 - 다양한 호 통계 조회 및 엑셀 다운로드 기능 제공
RQ-0045: 코덱 - 다양한 코덱 지원
RQ-0046: 화자분리 - 녹음 파일 화자 분리
RQ-0047: 조회 및 검색 - 다양한 조건으로 조회 기능 제공
RQ-0048: 실시간 청취 - 상담 내용 실시간 청취

비기능

RQ-0049: 테스트 - DKT 테스트 수행 표준에 따른 테스트 수행 및 결함 수정
RQ-0050: 설치 - 넥서스의 콜 인프라를 DKT 지정 클라우드 인프라에 설치

주요 기능 구현 방안

주요 기능

상담 메인 화면: 고객 정보 저장, 상담 이력 조회, 상담 이력 저장 기능을 제공합니다.
CTI 연동: IVR에서 전달받은 고객 키 값을 바탕으로 고객 정보 및 이력을 스크린 팝업으로 제공합니다.
인바운드 상담 관리: 전화 인입 시 고객 조회, 이전 상담 이력 조회, 상담 결과 등록 등의 기능을 제공합니다.
실시간 모니터링 기능: 상담사의 상태 및 업무 현황을 실시간으로 모니터링 할 수 있는 기능을 제공합니다.

사업 관리

프로젝트 수행 조직

프로젝트 PM
사업 담당
QA 담당
PL

품질보증 방안

품질보증 프로세스를 통해 프로젝트의 각 단계에서 품질을 보장합니다.

투입 인력 및 장비에 대한 보안 준수
망 분리 및 서버 접근 제한
품질 진단 및 개선안 제시
산출물 점검 및 실시간 모니터링

기획 검토

| [고객센터 콜봇 시나리오 설계]

1안) 고객센터 콜봇을 설계하는 과정에서 IVR(Interactive Voice Response)을 사용하여 봇을 구분하고, DTMF(Dual-Tone Multi-Frequency)를 통해 사용자의 입력을 받고 PBX(Private Branch Exchange)를 통해 통화를 라우팅하는 구조

• IVR (Interactive Voice Response): ◦ IVR은 사용자가 전화를 걸면 자동으로 음성 메뉴를 제공하여 사용자의 요청을 인식하고 적절한 작업을 수행하는 시스템입니다. ◦ 고객센터 콜봇의 IVR은 사용자가 통화를 시작하면 먼저 나타나는 음성 메뉴입니다. 이 IVR은 사용자가 어떤 작업을 수행하고자 하는지에 따라 다양한 옵션을 제공할 수 있습니다.

• DTMF (Dual-Tone Multi-Frequency): ◦ DTMF는 전화 키패드의 숫자와 기호를 나타내는 음향 신호를 말합니다. 각 버튼은 고유한 두 가지 주파수 조합으로 표현됩니다. ◦ 사용자가 IVR에서 원하는 옵션을 선택할 때 DTMF 키 입력을 사용합니다. 예를 들어, "1"을 누르면 카카오워크로 연결되는 등의 기능을 수행할 수 있습니다.

• PBX (Private Branch Exchange): ◦ PBX는 전화 교환 시스템으로, 내부 및 외부 전화 통화를 관리하고 라우팅하는 역할을 합니다. ◦ 고객센터 콜봇에서 PBX는 IVR 및 DTMF 입력을 통해 사용자가 선택한 옵션에 따라 적절한 콜봇 기능 또는 인간 상담원으로 통화를 라우팅합니다. PBX는 이를 가능하게 하는 기술적인 인프라를 제공합니다. 총론적으로, 사용자가 전화를 걸면 IVR을 통해 옵션을 선택하고, 선택된 옵션은 DTMF를 통해 전달됩니다. 그리고 PBX는 이 선택을 바탕으로 통화를 적절한 처리 단계로 라우팅합니다.

2안) 통합봇을 통해 내부 개발툴인 시나리오빌더를 활용하는 방식은 고객센터 콜봇을 구현하는 또 다른 설계 방안입니다. 이 방식에서는 시나리오빌더를 사용하여 대화 흐름을 정의하고 분기 처리를 수행합니다.

• 시나리오빌더: ◦ 시나리오빌더는 대화 기반 플로우를 시각적으로 구성할 수 있는 개발 툴입니다. ◦ 여기서는 고객의 요청에 대한 다양한 시나리오를 빌드하고, 그에 따른 흐름을 관리합니다.

• 분기 처리 방식: ◦ 시나리오빌더를 사용하여 다양한 상황에 대한 대화 흐름을 정의하고 분기 처리를 구현합니다. ◦ 예를 들어, 사용자가 "제품 문의"라고 말하면, 해당 시나리오 블록으로 분기되어 제품 관련 정보를 요청하거나 제공할 수 있습니다. 반면에 "결제 문의"라고 말하면 다른 시나리오 블록으로 분기되어 결제 관련 정보를 처리할 수 있습니다.

1안의 경우 고도화가 가능하지만, 시나리오빌더를 사용하지 않을 수 있어서 kicc(kakao i connect center)를 활용하지 않게되며 파트너사에 의존해야 될 것으로 보여집니다. 2안의 경우에는 내부 개발툴인 시나리오빌더를 사용하기 때문에 kicc를 활용할 수 있으며 고도화는 어렵습니다.

그리고, 현재 지난주에 공유받은 문서는 IVR을 통한 흐름(1안)에 최적화되어 있으므로 2안으로 진행 시 시나리오가 재구성되어야 합니다.

추가 참고 사항 • IPCC_제안서: 넥서스 제안서 • DKT고객센터콜봇_과업정리: 시나리오 변경에 따른 반영 및 업데이트 필요 . • 요구사항명세서: 과업정리 + 콜봇 문서 내용 반영하여 작성.

결론: 1안) IVR시나리오의 1차분류(카카오워크/헤이카카오/카카오홈/카카오i/카카오i 커넥트)를 사용하여 상세내용에 대한 응대 2안) AI봇을 이용하여 2차분류(기타 문의 사항)하이브리드 형태로 진행함이 가장 효율적으로 판단

최종: IPCC를 통한 IVR 시나리오 도입, ARS를 통해 응대 추후 콜봇 연계하여 기타 문의 사항을 통한 응대까지 마련.

IVR 관련 검토사항

IVR을 통한 최초 안내 이후, 추가 문의 사항은 콜봇으로 연결됩니다.

시나리오 작성
- 시나리오 설계(가)안 작성
- 요구사항 정의 후 재 설계 필요
시나리오 빌더 적용
- 카카오고객센터 콜봇 시나리오로, 시나리오 빌더에 적용
- 현재 소*공 환경에 적용
  - 사용자 발화가 등록되지 않음
  - 소*공 환경에서는 세팅 불가(신규 세팅을 하더라도 기존의 세팅으로 다시 원복해야하고 해당 과정의 영향도도 예상하기 어려움)
  - 해결방안으로는 KR2로 이전하는 작업에 카카오고객센터 콜봇의 인프라를 구축 할 예정이기 때문에 구축 완료 이후부터는 소*공과 별개로 오픈빌더에 발화를 등록하여 사용 가능. *고객센터 콜봇 인프라 구축 이후 추가로 테스트 환경 구축 예정

춘천 → 팔당, 북한강 자전거길 종주기

Victor’s Reference Note — Tue, 2 Dec 2025 14:29:11 +0900

한 줄 평

“짧다고 방심했다가 편의점 양갱·초코바에 구원받은 날. 그리고 늘 내 옆자리를 지켜주는 사람 덕에 끝까지 기분 좋게 들어왔다.”

코스 한눈에

구간: 춘천(경강교) → 강촌 → 가평(신매대교) → 양평(샛터삼거리) → 남양주(밝은광장, 팔당)
거리/시간: 약 70km 전후 / 라이딩만 3.5–5시간(휴식 제외, 평지 위주)
난이도: ★★☆☆☆ (대부분 평탄, 중간중간 짧은 롤링·언덕)
인증센터(동→서 순서): 경강교 → 신매대교 → 샛터삼거리 → 밝은광장
권장 출발 방향: 춘천 → 팔당(서쪽)
- 이유: 전체적으로 미세한 하강 경사 + 아침 시간대 바람이 약한 편.
- 단, 서풍이 강한 날엔 역풍을 정면으로 맞으니, 전날 풍향 예보 보고 결정.

구간별 스토리 & 포인트

1) 춘천—경강교: 스타트는 가볍게, 마음은 든든하게

출발: 경강교 인증센터에서 도장 ‘꽝’.
“짧다 싶어 방심했다가” 이른 타이밍에 **편의점 보급(양갱 + 초코바)**로 당 보충. 가벼운 코스도 초반 1~2시간 내 당 보급이 끝까지 미묘한 차이를 만든다.

• [경강교 인증센터] — “도장 찍고, 출발!”

2) 강촌: 추억 회상 구간(번지점프의 성지…였던 나)

강촌/구 곡선철교 라인은 북한강 뷰가 가장 드라마틱하게 열리는 곳.
예전에 번지점프하던 기억이 스쳐갔지만, “이젠 못 할 듯…”이라는 속마음 고백. 대신 오늘은 다리로 점프(페달링) 잘 함.

• [강촌 거울 셀피] — “강촌 추억”

3) 가평—신매대교: ‘짧고 굵게’ 리듬 끊기지 않게

신매대교 인증센터에서 스탬프.
이 구간은 평지 위주지만 짧은 업다운이 간헐적으로 나타난다. 기어비 한두 단 여유 주면서 케이던스로 풀어주는 게 체력 방어에 좋다.

• [신매대교 인증센터] — 인증 센터 옆

4) 양평—샛터삼거리: 보급, 카페, 그리고 ‘다음엔 가족이랑’

샛터삼거리 인증센터까지는 편의점·카페가 드문 듯 보이다가도, 급하면 다 있다. 이날 내 심신을 구제한 건 양갱+초코바 조합.
도로변에 괜찮은 식당들이 여럿 보여 “다음엔 가족이랑 와서 한 끼 제대로”라는 생각이 자동 저장.

• [샛터삼거리 인증센터]

5) 남양주—밝은광장(팔당): 연인들의 산책길을 지나 ‘피니시’

밝은광장으로 들어가는 마지막 라이드는 연인들 + 가족 나들이 풍경 속을 통과한다.
한적한 강변의 노을/반사광이 라이딩 막판의 피로를 부드럽게 식혀준다. 완주 도장 찍고, 서로 하이파이브.

• [밝은광장 인증센터] — “완주” , 마무리 컷

코스 정보(실전)

지형 난이도(체감)

평지 80% + 짧은 언덕(롤링) 20%
힘 빠지는 짧은 업힐은 주로 가평~양평 사이와 샛터 이후 소소한 구간.
팁: “평로라 페달링”으로 앞기어 가볍게, 케이던스 유지가 체력 효율 최고.

보급/화장실

편의점/카페 밀도: 강촌·가평·양평 진입부는 비교적 수월.
물 리필: 집에서 준비, 편의점 생수.
당 보급: 양갱·초코바·젤 2~3개면 끝 구간 멘탈 지킴이.

위험/주의

산책로 공존 구간(밝은광장 주변): 속도 줄이고 벨/콜아웃.
자갈/낙엽: 강촌 인근 그늘진 코너, 비 온 뒤 특히 주의.

인증 & 교통

도장 순서(춘천 시작): 경강교 → 신매대교 → 샛터삼거리 → 밝은광장
복귀 교통: 팔당·양수역 ITX/경의중앙, 또는 동행 차량 픽업.
주차: 춘천(경강교 주변 공영), 팔당 공원 일대 공영주차장 활용.

먹거리 로그

라이딩 후 식사: _“닭갈비는 춘천이 국룰”_이지만, 이날은 서울 중화동 ‘동창 닭갈비’로 원정. 국물 자작하게 볶음 들어가면 탄수화물 보충까지 한 번에.
보급 베스트: 편의점 양갱 + 초코바(= 당+지방의 안정감 있는 든든함). 카페인 필요하면 라떼 한 잔까지.

이번 코스가 좋은 이유(다른 강길과 비교)

한강 본류(서울 구간)보다 러너·보행자 밀도 낮음 → 주행 리듬 유지 쉬움.
남한강보다 관광 동선(강촌·가평)과 뷰 포인트가 가까움 → 라이딩 + 동행자(가족·연인) 볼거리 균형이 좋다.
금강·영산강 대비 접근성/대중교통/주차가 편리 → 당일치기·하프(왕복X) 설계가 쉬움.

함께한 사람,

오늘도 조수석/보급/사진/응원으로 나를 완주 지점까지 데려다 준 와이프에게 고마움 가득.
다음엔 샛터~밝은광장 사이 그 예쁜 식당들 중 한 곳에 꼭 앉아, 북한강 뷰를 천천히 함께 즐기자.

체크리스트(요약)

바람 예보 확인(서풍 강하면 체감 난이도↑)
인증센터 위치 저장(경강교/신매대교/샛터삼거리/밝은광장)
밝은광장 진입 전 보행자 밀집 구간 서행

즐거운 북한강 라이딩, 다음엔 가족과 ‘뷰 맛집’ 예약까지 걸고 천천히 즐겨요! ‍♂️

남한강자전거길 132km 완주기 (충주댐 → 능내역)

Victor’s Reference Note — Mon, 24 Nov 2025 10:50:43 +0900

0) 한 줄 개요

출발: 06:30 기상 → 09:23 페달 온
코스: 충주댐 → 탄금대 → 강천보 → 여주보 → 이포보 → 양평 자전거쉼터 → 능내역
기록: 131.80km · 5:41:07 · Avg 23.1km/h · 누적고도 623m
총평: 무엇이 가장 소중한 지 깨닫게 된, 남한강 자전거길

1) 남한강자전거길, 핵심 정보 한 장

공식 구간: 충주댐 ↔ 팔당/능내(약 132km)
성격: 강둑 전용 자전거도로 비율이 높아 차 스트레스↓, 표지/쉼터 체계적.
지형: 충주 → 서울권 방향은 완만한 하강 흐름, 중후반에 오르막길이 아주 긴 코스가 여럿 존재.
인증 포인트(주요): 충주댐, 탄금대, 강천보, 여주보, 이포보, 양평 자전거쉼터, 능내역
보급권: 충주·여주·양평 도심 접근 쉬움(편의점/식당/화장실 풍부).
난이도 체감: ★★☆(체력 2.5/5, 길찾기 1/5) – 페이스 유지형 장거리.

2) 우리의 라이딩 로그 (시간순 + 사진)

09:00 충주댐 도착 → 09:23 스타트

옷에 묻은 체인오일로 잠깐 열 올릴 뻔… 하지만 “사람이 장비보다 소중”하다는 걸 스스로 다짐하고 출발.

충주댐 인증센터

10:00 초반 탄금대

강변 공원·편의시설 좋고, 인증 찍기 수월. 몸 풀기에 딱.

충주탄금대 인증센터

11:30 강천보

여주 상류의 보. 쉼터/카페·주차장 접근 괜찮음.

강천보 인증센터

13:00 여주보 도착 → 점심

여주 시내 접근성 최고. 오늘의 선택은 여주솥반. 보리굴비+제육 조합으로 탄수/단백 완벽 충전. 집사람이 “보리굴비 대찬성” 선언.

보리굴비 조만간 식탁에서 다시 볼 것 같다.. ^^;;

여주보 인증센터 / 여주솥반 점심

오후 초반 이포보

강변 직선에서 리듬 회복. 사진 맛집.

이포보 인증센터

오후 중반 양평 자전거쉼터

자동판매기/화장실/편의점 접근 쉬움. 막판 40km 전 마지막 리셋 포인트.

양평자전거쉼터 인증센터

17:41 능내역 피니시

자전거 시작 초기에 어머니·동생과 찍었던 그 자리. 이번엔 아내·띠용과 같은 프레임으로 완주 마무리. 감회가 남다름.

능내역 인증센터

(+보조 스팟) 강천보 & 비내섬도 중간 포토/보급 포인트로 훌륭합니다.

3) 코스 운영 팁 (남한강 실전형)

길찾기

표지와 빨간 인증부스만 따라가면 됩니다. 강둑 전용로 비율이 높아 헤맬 일이 거의 없음.
다리·보 진입/출구에서만 잠깐 감속·주의.

페이싱

충주 → 능내 순하강 흐름. 초중반은 워밍업, 여주 이후 40km는 “먹고 밀어넣기”.
역풍만 아니면 평속 22~25km/h 페이스가 가장 무난.

보급

물 1보틀(한 병은 집에서 준비, 점심 먹으면서 다시 보충)
여주를 메인 식사/보급지로 잡으면 후반이 정말 편해집니다.

비교 체감

금강길(146km): 평지 지구력 싸움, 거리 부담 큼.
오천길(105km): 공도/농로 섞여 멘탈 관리 필요.
남한강(132km): 노면·표지·보급 밸런스 최고. 자전거 지도가 없다면 불가능. (꼭 필요!)

4) 인증센터 체크리스트

충주댐
탄금대
강천보
여주보
이포보
양평 자전거쉼터
능내역

5) 오늘의 데이터 메모

131.80km / 5:41:07 / 평균 23.1km/h / 평균심박 124bpm / 3,783kcal / 누적고도 623m
(상단 콜라주 이미지 참고)

6) 결론

강을 따라 도시로 들어오는 재미, 도중에 맛있게 먹는 보급의 위력, 마지막에 추억의 능내역에서 느끼는 벅참.
오늘의 완주는 기록이라기보다, 우리 가족이 함께 만든 하루였습니다.

P.S. (아주 중요)

출발 전에 옷에 기름 묻었다고 괜히 신경 세웠던 저에게 —
라이딩 내내 깨달았습니다. 가장 소중한 건 장비가 아니라, 내 옆의 사람.
새벽부터 함께 움직여주고, 중간중간 사진도 찍어주고, 끝나고 지친 나 대신 운전까지 맡아준 아내에게.
오늘의 132km는 제 기록이 아니라 우리의 완주로 남깁니다. 사랑합니다.