제 248호 (2026.10.19.)

문제를 모르니 문제가 없다?!

얼마 전, 아이가 물었습니다.

“아빠는 회사에서 무슨 일 해?”

실제로 하는 일을 하나씩 설명하려니 오히려 더 어려워질 것 같았습니다. 잠시 생각하다가 이렇게 대답했습니다.

“AI를 활용해서 문제를 해결하는 사람이야.”

그러자 아이가 다시 물었습니다.

“문제가 뭔데?”

이번에는 쉽게 대답하지 못했습니다. 문제를 해결한다는 말은 자주 했지만, 정작 문제가 무엇인지 깊이 생각해 본 적은 별로 없더군요. 아이에게 설명하려다가 제가 먼저 궁금해졌습니다.

정말, 문제란 무엇일까요.

이전 뉴스레터 [「용사의 검으로 택배 상자만 뜯고 있다면」]에서는 UN의 지속가능발전목표, SDGs를 소개했습니다. 빈곤과 기후변화처럼 우리가 함께 해결해야 할 과제를 살펴보며, AI를 어디에 써 볼지 생각해 보자는 이야기였습니다.

하지만 이미 정리된 과제를 설명하는 것과, 제가 무엇을 어떤 이유로 문제라고 생각하는지 설명하는 것은 다른 일이었습니다. 저는 일하면서 어떤 상황을 문제로 받아들이고 있었을까요. 무엇이 달라져야 한다고 생각했고, 왜 그 변화가 필요하다고 판단했을까요.

가령 “회의가 너무 길다”고 말할 때, 제가 문제 삼는 것은 한 시간이라는 길이일까요. 그 시간을 쓰고도 결정을 내리지 못했다는 사실일까요. 아니면 제 의견을 충분히 이야기하지 못했다는 아쉬움일까요.

같은 회의를 두고도 무엇을 문제로 보느냐에 따라 해결하려는 일이 달라집니다. AI에게 도움을 요청할 때도 마찬가지일 것입니다. 제가 무엇을 문제라고 설명하느냐에 따라 함께 찾아갈 방향도 달라질 테니까요.

그래서 이번에는 제가 습관처럼 사용하던 ‘문제’라는 말을 들여다보려 합니다. 세 편의 오래된 논문이 길잡이가 되어 주었습니다. 아래의 회의 이야기는 그 관점을 우리 일에 연결하기 위해 구성한 예시입니다.

윌리엄 파운즈는 1969년 「The Process of Problem Finding」에서 관리자가 풀어야 할 문제를 어떻게 발견하는지 살폈습니다. 그는 문제를 현재 상황과 바라는 상황 사이의 차이와 연결합니다. 문제를 발견하는 과정에는 자신이 지각한 상황을 어떤 비교 모델과 대조하는 일이 포함됩니다. 현실을 보는 동시에, 현실을 판단할 기준도 사용하고 있다는 뜻입니다. 파운즈, 1969

회의가 한 시간 이어졌다는 사실만으로는 문제가 있었는지 알기 어렵습니다. 중요한 결정을 충분히 논의했다면 필요한 시간이었을 수 있습니다. 같은 이야기를 반복하면서 아무 결정도 내리지 못했다면 이야기가 달라집니다.

“회의가 너무 길다”는 말에는 이미 기대가 들어 있습니다. 이 정도 안건은 삼십 분이면 충분하다는 기대일 수도 있고, 시간을 들인 만큼 결정이 나와야 한다는 기대일 수도 있습니다. 불편함을 느낀 사람이 무엇을 기대했는지 알게 되면 문제의 모양도 드러납니다.

그 기대는 어디에서 왔을까요. 전임자의 방식, 예전의 성과, 다른 팀의 관행을 기준으로 삼았을 수 있습니다. 그러나 과거보다 다루는 일이 복잡해졌다면 예전의 회의 시간을 그대로 기준으로 삼기는 어렵습니다. 기준을 확인하지 않은 채 시간을 줄이면 필요한 논의까지 사라질 수 있습니다.

그래서 저는 문제를 발견했다고 느낄 때 두 문장을 나란히 적어 보고 싶어졌습니다. ‘실제로 어떤 일이 일어나고 있는가’와 ‘나는 어떤 상태를 기대하고 있는가’입니다.

“우리 팀은 소통이 안 된다”는 말은 그 자체로는 확인하기 어렵습니다. “지난 세 번의 회의에서 담당자와 기한을 정하지 못해 같은 안건을 다시 논의했다”라고 쓰면 다른 사람도 확인할 수 있습니다. 기대 역시 “소통이 잘되어야 한다”보다 “회의가 끝나면 누가 언제까지 무엇을 할지 알아야 한다”라고 적을 때 선명해집니다.

막연했던 불편이 관찰과 기대로 나뉩니다. 이제 문제를 설명할 단서가 생겼습니다. 하지만 무엇이 달라져야 하는지 안다고 해서 곧바로 바꿀 수 있는 것은 아닙니다.

무엇을 바꾸고, 어떻게 확인할 것인가

허버트 사이먼은 1973년 「The Structure of Ill Structured Problems」에서 잘 구조화된 문제와 그렇지 않은 문제를 검토했습니다. 그의 논의에는 현재와 목표 상태, 가능한 행동, 해답을 판단할 기준, 필요한 지식 등이 등장합니다. 그는 두 종류의 문제 사이에 명확하고 고정된 경계가 있다고 보지 않았습니다. 사이먼, 1973

회의 문제에도 아직 정해지지 않은 것이 많습니다. 줄이고 싶은 것은 회의 시간일까요, 결정을 기다리는 시간일까요. 진행자가 바꿀 수 있는 것은 안건 순서일까요, 참석자 범위일까요. 회의가 나아졌다는 사실은 무엇으로 알 수 있을까요.

이런 질문을 따라 ‘회의를 개선하자’는 요청을 조금 더 구체화해 볼 수 있습니다. 앞으로 네 번의 정기회의에서는 결정할 안건을 미리 공유합니다. 회의가 끝나기 전에 결정 사항과 담당자, 기한을 확인합니다. 그리고 같은 안건을 다시 논의하는 횟수와 참석자들의 이해 정도를 살펴봅니다.

이것이 사이먼이 제시한 회의 개선법은 아닙니다. 그의 관점을 적용해 무엇을 바꾸고 무엇을 관찰할지 정해 본 예시입니다. 중요한 것은 사람들이 움직여 보고 그 결과를 확인할 수 있는 형태로 질문이 바뀌었다는 점입니다.

그 과정에서 처음의 설명이 달라질 수도 있습니다. 회의록을 살펴보니 논의가 반복되는 이유는 마지막 결정을 내릴 사람이 정해져 있지 않기 때문일 수 있습니다. 모두가 의견은 말하지만 결정할 권한은 없는 것입니다. 그렇다면 발언 시간을 제한하는 것만으로는 기대한 변화가 생기기 어렵습니다.

구조화는 모르는 것을 드러내는 일이기도 합니다. 어느 단계에서 결정이 멈추는지, 담당자가 일을 미루는 것인지 시작할 정보가 없는 것인지 구별할 수 있을까요. 답을 모르는 부분을 표시하면 곧바로 실행할 일과 먼저 알아볼 일을 나누게 됩니다.

여기까지는 꽤 명료해 보입니다. 관찰과 기대의 차이를 확인하고, 목표와 행동과 판단 기준을 구체화하면 됩니다. 그런데 한 가지 어려움이 남습니다. 그 목표를 모두가 원하는 것은 아니라는 점입니다.

누구에게 좋은 회의인가

팀장은 빠른 결정을 원하지만 실무자는 위험을 충분히 검토하고 싶어 할 수 있습니다. 새로 합류한 사람에게는 배경 설명이 필요하지만 오래 일한 사람에게는 같은 설명이 반복처럼 들립니다. 삼십 분 안에 끝나는 회의를 성공으로 정하면 누군가는 필요한 정보를 얻지 못할 수 있습니다.

리텔과 웨버는 1973년 「Dilemmas in a General Theory of Planning」에서 사회정책의 이런 어려움을 ‘난제’, 곧 wicked problems라는 개념으로 논의했습니다. 문제의 최종적인 정의와 해법을 깔끔하게 분리하기 어렵다는 것이 핵심 주장 중 하나입니다. 문제를 어떻게 설명하는가에 따라 해결 방향이 달라지고, 해결책을 검토하면서 문제를 이해하는 방식도 바뀝니다. 리텔·웨버, 1973

회의를 ‘시간 낭비’로 설명하면 줄이거나 없애려 합니다. ‘결정 권한의 혼란’으로 설명하면 책임과 권한을 정리하게 됩니다. ‘정보에 접근하는 기회의 차이’로 설명하면 자료 공유와 설명 방식에 주목합니다. 같은 장면에서 출발했지만 손대는 곳이 달라집니다.

어떤 설명이 관찰된 사실에 맞는지 확인해야 합니다. 동시에 그 설명에 누구의 경험이 들어 있고 누구의 경험이 빠져 있는지도 살펴야 합니다. 팀장의 불편만 들으면 실무자의 어려움을 놓칠 수 있고, 자주 발언하는 사람만 보면 조용히 참석하는 사람의 필요를 알기 어렵습니다.

리텔과 웨버가 다룬 사회정책에서는 가치 충돌과 실행의 책임이 더 깊어집니다. 관련 집단이 원하는 결과가 다를 수 있고, 정책의 영향은 실제 사람들의 삶에 남습니다. 누구에게 좋은 결과이며 어떤 비용을 치르는지 함께 물어야 하는 이유입니다.

모든 회의를 그들이 말한 난제로 부를 필요는 없습니다. 다만 회의 시간이 줄었다는 숫자만으로 개선을 판단하기 전에, 그 변화가 다른 사람에게 어떤 일을 만들었는지는 확인할 수 있습니다. 공식 회의가 짧아진 대신 개별 설명과 연락이 늘었다면 부담이 다른 곳으로 이동했을 수 있습니다.

세 논문을 따라오니 아이의 질문에 조금은 답할 수 있을 것 같습니다. 우리가 어떤 상황을 문제로 부를 때는 기대와 판단 기준을 사용하고 있습니다. 그것을 다루려면 행동과 확인 방법이 필요하고, 그 과정에는 다른 사람의 경험과 서로 다른 가치도 들어와야 합니다.

이 순서는 세 학자가 함께 제시한 공식은 아닙니다. 서로 다른 논의를 연결해 읽는 하나의 방식입니다. 실제로는 행동을 정하다가 목표를 고치고, 다른 사람의 이야기를 듣다가 새로운 차이를 발견하며 세 질문 사이를 오가게 될 것입니다.

그런데 저는 아이에게 ‘AI를 활용해’ 문제를 해결한다고 말했습니다. AI는 이 과정의 어디에 들어와야 할까요.

AI 전환기 — 무엇이 달라졌는지 묻기

먼저 기존에 하던 일에 AI를 도입하는 환경을 생각해 보겠습니다. 사람이 정리하던 회의록을 AI가 요약하고, 혼자 고민하던 기획에 AI가 만든 대안을 더합니다. 여기서는 “시간이 줄었는가”, “더 좋은 결과를 얻었는가”라는 비교가 자연스럽습니다.

문제 정의에서도 이런 비교는 필요합니다. 다만 대안이 많아지는 것, 결과물이 좋은 평가를 받는 것, 문제를 더 정확하게 이해하는 것, 실제 상황이 나아지는 것은 서로 다른 성과입니다.

Shin 등의 2025년 연구에서는 최종 분석에 포함된 280명을 대상으로 사람이 직접 문제를 재구성하는 조건과 여러 AI 지원 조건을 비교했습니다. 전문가가 평가한 관점의 참신성과 유용성에서는 유의한 개선이 확인되지 않았습니다. 주어진 디자인 문제를 다시 바라보는 과제의 결과이므로 모든 AI 사용에 효과가 없다는 뜻은 아닙니다. 그러나 설명을 여러 개 생성한다고 더 나은 문제 정의가 보장되는 것도 아니라는 점을 생각하게 합니다. Shin 외, 2025

개입 시점에 따라 결과가 달라진 연구도 있습니다. Wu·Kim·Lin의 2025년 워킹페이퍼는 MBA 학생 305명을 AI를 쓰지 않는 집단, 대안 생성에만 쓰는 집단, 문제 정의와 대안 생성 모두에 쓰는 집단으로 무작위 배정했습니다. 여기서 ‘전략적 대안’은 새로운 사업에 진출하는 것처럼 사업의 방향이나 범위를 바꾸는 선택을, ‘운영적 대안’은 비용 절감이나 서비스 사용성 개선처럼 기존 사업의 과정과 효율을 개선하는 선택을 가리킵니다.

AI를 사용한 두 집단 모두 더 많은 대안을 만들었습니다. 다만 문제 정의부터 AI를 쓴 집단에서는 운영적 대안의 비중이 상대적으로 커졌습니다. 전체 대안 중 전략적 대안이 차지하는 비중은 AI를 쓰지 않은 집단보다 약 7%포인트 낮게 추정됐습니다. 비중이 낮아졌다는 것이 전략적 대안의 개수까지 줄었다는 뜻은 아닙니다. Wu·Kim·Lin, 2025, pp.12–16·Table 2

어느 쪽이 더 좋은 해법인지는 이 결과만으로 판단할 수 없습니다. 운영 개선이 전략적 변화보다 언제나 열등한 것도 아니고, 이 연구가 실제 경영 성과를 측정한 것도 아닙니다. 다만 AI와 함께 생각할 때는 아이디어가 얼마나 늘었는지와 함께, 어떤 방향의 아이디어가 늘었고 어떤 질문이 충분히 다뤄지지 않았는지도 살펴볼 필요가 있습니다.

회의 사례로 돌아오면, AI 덕분에 회의록 작성 시간이 줄었다는 사실과 결정 권한의 불명확함을 발견했다는 사실은 다른 성과입니다. AI가 다음 행동을 분명하게 해 주었는지, 반복되는 혼선을 줄였는지, 누군가에게 부담을 떠넘기지는 않았는지까지 살펴보고 싶습니다.

이때 사람이 잠정적인 설명을 먼저 적고 AI의 설명과 비교해 볼 수도 있습니다. 처음부터 AI와 함께 탐색하거나 중간에 반론을 받아 볼 수도 있습니다. 사람이 먼저 생각하는 순서가 언제나 우월하다고 입증된 것은 아닙니다. 어떤 과정에서 무엇을 발견하고 어떤 판단을 수정했는지를 살펴야 합니다.

AI Native 시대에 문제를 함께 정의한다면

그런데 일을 시작할 때부터 AI가 함께한다면 어떨까요. 여기서는 그런 업무 환경을 ‘AI Native’라고 부르려 합니다. 전환기와 AI Native는 연도로 나뉘는 시대라기보다, 지금도 같은 조직 안에서 함께 존재할 수 있는 두 방식입니다.

다음은 그 차이를 생각하기 위한 가상의 운영 방식입니다. 회의를 마친 뒤 요약을 맡기는 데서 더 나아가, 준비할 때부터 AI와 지난 결정과 미완료 업무를 검토합니다. AI가 반복되는 안건의 후보를 제시하면 사람들은 그 기록과 해석이 실제 상황에 맞는지 확인합니다. 그 과정에서 “회의가 길다”는 불편이 “결정에 필요한 정보가 늦게 도착한다”는 질문으로 바뀔 수 있습니다.

여기서 AI는 무엇을 눈여겨보고 무엇을 문제라고 부를지 정하는 과정부터 참여합니다. 사람도 AI의 설명을 검토하면서 질문을 바꿉니다. 매번 AI를 만나기 전의 독립적인 문제 정의를 출발점으로 요구하기는 어려워집니다.

그래도 검증할 방법은 필요합니다. 두 방식 모두 AI를 쓰더라도 하나는 원인 설명만 제시하고, 다른 하나는 근거가 된 기록과 반대 증거를 함께 제시할 수 있습니다. 어느 방식에서 잘못된 원인을 더 빨리 알아차리는지 비교해 볼 수 있습니다. 일부 기능을 빼거나 AI 없는 조건을 두어 그 기여를 확인하는 비교도 여전히 의미가 있습니다.

평가할 시간의 범위도 넓혀야 합니다. 한 번의 대화에서 잘 정리된 문제 문장이 나온 것과, 그 문장에 따라 몇 주간 행동한 뒤 상황이 나아진 것은 다릅니다. 같은 안건을 다시 논의하는 횟수, 결정 이후의 혼선, 개별 설명에 드는 시간 등을 살펴볼 수 있겠습니다. 이런 운영 방식과 지표는 앞선 연구에서 검증된 표준이 아니라, 우리 업무에서 시험해 볼 제안입니다.

여기서 세 학자의 질문이 다시 필요해집니다.

파운즈의 관점에서는 AI가 어떤 기준으로 차이를 찾아냈는지 물을 수 있습니다. “평균보다 회의가 길다”고 한다면 평균의 출처와 비교 대상부터 확인해야 합니다. 다른 조직의 관행이 우리 업무에 적절한지도 살펴야 합니다. 측정하기 쉬운 발언 시간만 보다가 질문하기 어려운 분위기를 놓치고 있지는 않은지도 돌아볼 수 있습니다.

사이먼의 관점에서는 목표와 행동을 수정할 수 있어야 합니다. AI와 함께 목표를 ‘회의 시간 단축’으로 정했더라도, 실행 뒤 개별 연락과 재작업이 늘었다면 목표부터 다시 볼 필요가 있습니다. 정보를 공유하고 결정을 실행하는 데 드는 전체 부담이 더 적절한 기준일 수 있습니다. 처음의 목표를 고정한 채 효율만 높이면 잘못 정한 문제를 더 능숙하게 풀 수도 있습니다.

리텔과 웨버의 관점에서는 누구의 경험이 빠져 있는지 물어야 합니다. AI가 회의 기록을 읽는다고 해서 기록되지 않은 경험까지 확인한 것은 아닙니다. 조용했던 사람이 동의한 것인지, 발언할 기회를 얻지 못한 것인지는 별도로 알아봐야 합니다.

실제 사용자 진술을 활용한 PerspectiveCoach 연구는 참고할 만한 시도를 보여 줍니다. 개발자 18명이 사용자의 경험을 읽고 AI 피드백을 받으며 자신의 이해를 다시 표현했고, 참가자들은 긍정적으로 평가했습니다. 다만 무작위 대조 실험은 아니었고, 마지막 시도까지 원문과의 유사도가 계속 높아진 것도 아니었습니다. 반복해서 대화했다는 사실만으로 이해가 깊어졌다고 단정할 수 없습니다. Olson 외, 2026

우리 일에 적용한다면 실제 동료의 발언과 우리의 해석을 AI와 함께 대조한 뒤, 그 동료에게 이해가 맞는지 확인해 볼 수 있겠습니다. AI가 만든 가상의 직원 의견은 질문을 준비하는 자료가 될 수 있지만 실제 의견을 들었다는 증거는 되지 않습니다. 생성형 AI 페르소나의 위험을 검토한 Amin 등의 연구도 환각과 검증 문제를 지적하며 실제 사용자와 전문가의 검증을 권고합니다. Amin 외, 2025

물론 당사자의 말을 모두 듣는다고 목표가 저절로 합의되는 것은 아닙니다. 빠른 결정을 원하는 사람과 충분한 검토를 원하는 사람 사이에서 어느 비용을 감수할지 결정해야 할 수 있습니다. AI가 제안한 절충안을 받아들이는 이유와 결정에 이의를 제기할 방법, 결과에 책임질 주체도 함께 정해야 합니다.

AI 전환기에는 기존 일에 AI를 넣었을 때 무엇이 달라지는지 묻습니다. AI Native 환경에서는 AI와 함께 문제를 정하고 행동하고 수정하는 전체 과정을 어떻게 구성할지까지 묻게 됩니다. 도입 효과를 확인하는 질문에, 일하는 방식을 설계하는 질문이 더해지는 셈입니다.

아이에게 다시 대답한다면

처음에 저는 문제를 해결하는 사람이라고 말했습니다. 그런데 아이의 질문을 따라가다 보니, 제가 해야 할 일에는 무엇을 문제라고 부를지 알아보는 과정도 포함되어 있었습니다.

“회의가 너무 길다”는 불편은 결정 권한의 문제일 수도, 정보 전달의 문제일 수도 있었습니다. AI와 함께 탐색했다면 더 일찍 알아차렸을 수도 있고, 그럴듯한 설명 하나를 너무 빨리 받아들였을 수도 있습니다. 그래서 누구의 입에서 먼저 나온 설명인지보다, 그 설명을 받아들일 근거와 고쳐야 할 이유를 확인하는 일이 중요하다고 생각하게 됐습니다.

지금 AI와 함께 다루고 있는 문제 하나를 떠올려 보면 어떨까요. 우리는 무엇을 근거로 그것을 문제라고 정했을까요. 그 설명에는 누구의 경험이 빠져 있을까요. 어떤 결과가 나오면 처음의 정의를 고쳐야 할까요.

이 질문들에 답하려면 그동안 보지 않았던 기록을 찾아야 할 수도 있고, 아직 이야기를 듣지 못한 사람을 만나야 할 수도 있습니다. 어렵게 만든 계획을 고쳐야 할 수도 있습니다. 그 과정을 거치면서 우리가 풀기로 한 문제가 실제 상황에 더 가까워질 수 있을 것입니다.

아이가 다시 아빠는 무슨 일을 하느냐고 묻는다면, 이번에는 이렇게 말해 보고 싶습니다.

“사람들이 일하면서 겪는 어려움이 무엇인지 알아보고, AI도 써 가면서 바꿀 방법을 찾는 일을 해. 바꾼 뒤에 정말 나아졌는지도 살펴보고.”

여전히 긴 대답입니다. 그래도 이제는 제가 하는 일을 조금 더 정확하게 설명한 것 같습니다. 무엇을 풀 것인지 정하고, 그 정의가 틀렸다면 알아차리고 고쳐 가는 일. AI와 함께 문제를 해결한다는 말에, 앞으로는 그 과정까지 담아 보려 합니다.

—📝 우아한 세상을 소개하는 지식노동자, 앤드류—

💬 이번 주 더배러 톡방 하이라이트

🎨 만들어서 끝이 아니라, 누군가 써보는 데까지

ACH_안창현님은 한글과 영어를 함께 쓸 때의 어울림을 고민해 만든 폰트를 공개하고, 다음 날 용량을 줄이고 가변 폰트를 지원하도록 업데이트했다고 알렸습니다. 송세훈|달의이성|silentium님은 웹사이트에 적용한 모습을 보여줬고, 동백숲 / 한의사 / 지식관리님도 자신의 홈페이지에 적용하니 더 편안한 느낌이라고 후기를 전했습니다. ACH_안창현님은 별도로 PDF Craft에 한글 기능을 추가해 다시 패키징한 버전을 공유하면서, 한글 입력·저장과 서명 이미지 첨부를 직접 테스트했다고 설명했습니다. 개인 용도로 써달라는 당부까지, 만든 도구의 배포와 사용 경험이 함께 오간 대화였습니다.
ACH_안창현님이 공유한 폰트 업데이트·다운로드: https://achmage-sametone.achmage2.chatgpt.site/#download
ACH_안창현님이 개인 용도로 공유한 PDF Craft 재패키징 버전: https://github.com/laguna821/pdfcraft/releases/tag/v0.1.0

📅 새 앱을 만들기 전에, 쓰던 도구를 연결해보기

애런/경영전략/기록님이 일정과 루틴을 옵시디언에 남기는 방법을 묻자, 각자의 관리 방식이 모였습니다. 박종민님은 투두이스트를 계속 쓰면서 태스크 수집과 에이전트에게 맡길 일을 연결한다고 했고, 뀨야/연구/llm wiki님은 텔레그램과 구글 캘린더 등을 연동해 아침마다 할 일과 남은 일, 일정을 받는 방식을 소개했습니다. 애런님은 자신도 쓰고 있던 어사이드에서 이 방법을 시도해보겠다고 답했습니다. 새 도구 하나를 더 갖추는 것보다, 이미 쓰는 도구 사이의 끊긴 흐름을 잇는 방법이 구체적인 힌트가 됐습니다.

🔎 자격증 응시 후기에서, 실제 검증 방법 이야기로

ACH_안창현님은 클로드 자격증 공부와 응시 경험을 나누며, 절차를 자세히 지정하는 것이 예외 상황에 대한 대응을 좁힐 수도 있다고 이야기했습니다. 이 과정에서 자신이 풀어본 모의고사 사이트를 공유했지만, 실제 시험은 그보다 훨씬 헷갈렸다는 후기도 함께 전했습니다. 대화는 업무에서 결과를 검증하는 방법으로 이어져, 강인구/PM님은 테스트와 수치적 근거를, 루테넌트(김민석)|개발님은 도메인 지식과 규칙·테스트를 구축하는 방식을 소개했습니다. 푸른양/사무직/지식관리님도 끝까지 실제 동작을 검증한다고 보탰습니다. 시험에서 마주한 질문을 계기로 각자의 설계와 검증 경험을 비교한 시간이었습니다.
ACH_안창현님이 자격증 응시 후기와 함께 공유한 모의고사: https://claudecertificationguide.com/mock-exam

✍️ AI 글의 어색함은 취향일까, 정확성의 문제일까

뀨야/연구/llm wiki님은 AI가 그럴듯한 글을 만들어도 전문적인 문맥에 맞는 단어를 고르는 데 아쉬움이 있다고 했습니다. 반면 책쓰는듀공 / 제육우동먹기님은 처음 마음에 들지 않았던 AI 글을 나중에 다시 읽으니 좋았던 경험을 이야기하며, 낯섦에 적응하는 과정일 수도 있다고 봤습니다. 주말에 뀨야님은 샘플과 윤문 규칙을 줘도 보고서에 들어갈 내용과 빠져야 할 내용을 구분하지 못한 사례를 덧붙였습니다. 익숙한 문체인지와 필요한 내용을 정확히 담았는지는 서로 다른 기준이라는 점이 드러났습니다.

⚙️ 많이 돌리는 시스템에서, 오래 운영할 시스템으로

푸른양/사무직/지식관리님의 시스템 구축 이야기는 토큰을 얼마나 쓰는지, 운영을 어떻게 줄일 수 있는지로 이어졌습니다. 앤드류 | 지식노동자님은 각 단계에 꼭 AI가 필요한지, 스크립트로 해결할 부분과 백업·복구 구조를 살펴보자고 제안했습니다. 러브님은 더 저렴한 모델이 어디까지 처리할 수 있는지가 중요하다고 봤고, 최은우/연구원/이직지망생님은 AI로 템플릿을 뽑고 필요하면 코드로 만드는 방식을 공유했습니다. 기능 구현을 넘어, 반복 비용과 안정성을 함께 따지는 운영의 질문이 등장했습니다.

🎬 처음의 신세계에서, 긴 영상을 완성하는 어려움으로

루테넌트(김민석)|개발님은 영상 편집을 모르는 상태에서 AI와 영상을 만들며, 비개발자가 처음 바이브 코딩을 할 때의 기분을 느꼈다고 했습니다. 방법을 묻는 질문에는 인코딩과 음성 합성, 시각 요소를 여러 도구로 조합하는 과정을 설명했습니다. 며칠 뒤에는 롱폼 제작에 도전한 경험을 이야기하며, 짧은 영상 여러 개와 비슷한 분량이어도 작업은 훨씬 어려웠다고 전했습니다. 만들 수 있다는 놀라움이, 긴 결과물 하나를 끝까지 완성하는 수고를 체감하는 경험으로 이어졌습니다.
루테넌트(김민석)|개발님이 롱폼 제작 경험을 이야기하던 중 공유한 영상: https://youtu.be/p4bVraelitc

🎓 AI가 연구를 도와줘도, 연구자의 길은 따로 있다

주말에는 논문 심사와 대학원 생활에 관한 경험담이 길게 이어졌습니다. 문샤인님은 GPT의 도움으로 여러 논문 작업을 진행하고 있다고 했지만, ACH_안창현님은 지금 박사과정을 시작한다면 분야를 고르는 일이 특히 중요하다고 봤습니다. Tofukyung/프리/llmwiki님과 루테넌트(김민석)|개발님은 석사과정에서 배운 연구를 대하는 태도가 오래 도움이 된다고 이야기했습니다. 학위를 권하거나 만류하는 서로 다른 경험 속에서도, AI의 도움만으로 연구의 방향과 진로까지 정해지는 것은 아니라는 고민이 남았습니다.

  

📅 더배러 활동 소식

오늘의 뉴스레터 어떠셨나요?