프로젝트 워크숍

이번 주 읽기: 나는 상담사인가, 개발자인가?

학기가 거의 끝나간다. 2주차에 바이브 코딩을 시작해서, AI 대화 기능을 만들고, 윤리 원칙을 배우고, 모니터링 시스템을 추가하고, API 분석까지 연동했다. 코딩을 해본 적 없던 상담심리 전공 학생이 자기만의 상담 플랫폼을 만든 것이다. 그런데 여기서 한 가지 질문이 생긴다 — “나는 상담사인가, 개발자인가?”

이 질문은 단순한 역할 혼란처럼 보이지만, 사실 꽤 근본적인 물음이다. 프로젝트를 만들다 보면 어느 순간 코드에 빠져든다. 색상을 맞추고, 버튼 위치를 조정하고, API 호출을 최적화하는 데 시간을 쏟다 보면 정작 “이게 내담자에게 도움이 되는가?”라는 질문을 잊는다. 반대로 상담 이론만 고민하면 기술적 구현이 막혀서 아이디어가 코드로 바뀌지 못한다. 이 두 축 사이에서 균형을 잡는 것이 13주차의 핵심 과제다.

Gainer(2025)는 이 질문이 단순한 역할 혼란이 아니라, 전문 정체성(professional identity)을 다시 구성하는 과정이라고 말한다. 기술은 상담의 수단이지 목적이 아니다. 프로젝트에서 내린 모든 기술적 결정은 하나의 질문으로 검증되어야 한다 — “이것이 내담자에게 어떤 영향을 미치는가?” 화려한 기능을 추가하는 것보다, 위기 안전장치를 하나 더 넣는 것이 상담사다운 선택이다.

비유를 하나 들어보자. 의사가 수술 로봇을 다루는 법을 배웠다고 해서 “나는 의사인가, 엔지니어인가?”라고 고민하지 않는다. 로봇은 도구이고, 의사의 정체성은 환자를 치료하는 데 있다. 상담사도 마찬가지다. 코드를 짤 줄 안다고 해서 개발자가 되는 게 아니다. 기술을 활용해서 내담자의 정신건강을 돕는다면, 그것은 여전히 상담사의 일이다.

칼 로저스

상담의 핵심은 기법이 아니라 관계다. 어떤 도구를 사용하든, 결국 상담사와 내담자 사이의 진정한 만남이 치료의 본질이다.

— Rogers (1961)

Rogers의 말을 다시 곱씹어보자. “어떤 도구를 사용하든” — 이 한마디에 답이 있다. 1960년대에 Rogers가 이 말을 했을 때 “도구”란 모래상자, 인형, 그림 도구 같은 것이었다. 2025년에 그 도구가 AI와 코드로 바뀌었을 뿐, 원리는 같다. 도구가 바뀌어도 관계의 본질은 변하지 않는다. 상담사의 정체성은 어떤 도구를 다루느냐가 아니라, 그 도구를 통해 어떤 관계를 만드느냐에 달려 있다.

코드 리뷰: AI로 코드를 점검하기

코드 리뷰(code review)란, 작성한 코드를 다시 한번 꼼꼼히 살펴보는 것이다. 내가 쓴 글을 다시 읽으면 오탈자가 보이듯, 코드도 다시 보면 빠진 부분이 보인다. AI 코딩 도구(Cursor AI, Claude Code 등)를 활용하면 코드 전체를 보여주고 “보안 취약점과 UX 개선점을 찾아줘”라고 요청할 수 있다.

코드 리뷰의 원리는 상담에서의 수퍼비전(supervision, 경험 많은 상담사가 초보 상담사의 작업을 검토해주는 것)과 비슷하다. 수퍼비전에서 수퍼바이저가 상담 축어록을 읽으면서 “여기서 내담자의 감정을 놓쳤네요”라고 피드백을 주듯, AI 코드 리뷰 도구는 코드를 읽으면서 “이 부분에서 오류 처리가 빠졌어요”라고 알려준다. 다만 수퍼바이저의 피드백을 무조건 따르지 않듯, AI의 제안도 비판적으로 검토해야 한다.

상담 도구에서 특히 점검해야 할 세 가지가 있다. 첫째, 데이터 흐름 추적 — 내담자가 입력한 데이터가 어디에 저장되고, 누가 볼 수 있고, 언제 삭제되는지를 코드에서 확인한다. 예를 들어 사용자가 채팅창에 “요즘 자꾸 울적해요”라고 입력하면, 그 텍스트가 서버로 전송되고, AI API로 보내지고, 분석 결과가 저장된다. 이 모든 경로에서 데이터가 암호화되어 있는지, 제3자가 열람할 수 없는지 확인해야 한다.

둘째, AI 응답 안전장치 — AI가 혹시 진단을 내리거나, 약물을 권하거나, 자해 방법을 알려주는 등 부적절한 답변을 생성할 가능성에 대비한 필터가 있는지 본다. 실제로 GPT 기반 챗봇이 “우울증이세요”라고 진단하거나, “세로토닌 수치가 낮은 것 같으니 약을 드세요”라고 답한 사례가 보고된 적 있다. 이런 응답이 나오지 않도록 프롬프트(prompt, AI에게 주는 지시문)에 명확한 제한을 걸어야 한다.

세네카 R. 게이너

AI 상담 도구의 코드 리뷰는 기술적 리뷰인 동시에 윤리적 리뷰다. 코드 한 줄의 오류가 내담자의 안전에 직결될 수 있기 때문이다.

— Gainer (2025, p. 267)

셋째, 오류 처리 — API 호출이 실패했을 때 “오류가 발생했습니다”로 끝나면 안 된다. “잠시 연결이 불안정합니다. 긴급한 도움이 필요하면 1393(자살예방상담전화)으로 전화해 주세요” 같은 임상적 맥락을 반영한 메시지가 필요하다. 일반 앱에서 “서버 오류”는 불편이지만, 상담 앱에서 오류는 위기 상황의 내담자를 버려두는 것과 같다. 기술적 실패가 곧 돌봄의 실패가 되지 않도록, 오류 화면에도 따뜻한 안내와 대안 연락처를 넣어야 한다.

스티브 크루그

사용자가 생각하지 않아도 되도록 만들어라. 정신건강 도구의 사용자는 인지적으로 지친 상태일 수 있다. 복잡한 인터페이스는 그 자체가 장벽이 된다.

— Krug (2014)

접근성: 가장 도움이 필요한 사람이 쓸 수 있어야

정신건강 도구는 일반 앱보다 더 높은 접근성 기준이 필요하다. 사용자가 우울하거나 불안하거나 인지적으로 지친 상태일 가능성이 높기 때문이다. 우울증을 겪는 사람은 집중력이 떨어지고, 작은 결정도 어렵게 느낀다. 불안장애가 있는 사람은 새로운 화면이 뜰 때마다 긴장한다. 이런 상태의 사용자에게 복잡한 회원가입 절차나 긴 설문을 먼저 보여주면, 첫 화면에서 이탈할 가능성이 높다.

점검할 항목 네 가지가 있다. 색상 대비 — 글자와 배경의 대비가 충분한가? 빨간 경고 배지는 색각 이상(색맹)인 사용자를 위해 아이콘이나 텍스트를 함께 써야 한다. WCAG(Web Content Accessibility Guidelines, 웹 접근성 지침) 2.1 기준으로 일반 텍스트의 대비율은 최소 4.5:1이어야 한다. 키보드 내비게이션 — 마우스 없이 탭(Tab) 키만으로 모든 기능에 접근할 수 있는가? 손이 떨리거나 마우스를 사용하기 어려운 사용자에게 키보드 접근성은 필수다.

모바일 반응형 — 상담 앱 사용자의 약 70%가 스마트폰을 쓴다. 특히 위기 상황에서 사람들은 대부분 핸드폰을 들고 있다. 작은 화면에서도 핵심 기능이 다 작동해야 하고, 위기 자원(상담 전화번호 등)은 터치 한 번으로 연결되어야 한다. 로딩 상태 — AI API는 응답에 몇 초가 걸린다. “분석 중입니다...”라는 안내 없이 화면이 멈춰 있으면, 사용자는 앱이 고장 난 줄 안다. 특히 불안한 상태의 사용자는 “내 말이 전달된 건 맞나?”, “앱이 꺼진 건가?”라는 걱정이 더해져서 불안이 악화될 수 있다.

정신건강 도구에 접근하지 못하는 사람은 대체로 가장 도움이 필요한 사람이다. 기술적 장벽이 돌봄의 장벽이 되면 안 된다. 세계보건기구(WHO)에 따르면 정신건강 서비스가 필요한 사람 중 실제로 서비스를 받는 비율은 선진국에서도 50%에 못 미치고, 개발도상국에서는 10% 이하다. 디지털 상담 도구는 이 격차를 줄일 수 있는 강력한 수단이지만, 접근성이 확보되지 않으면 오히려 “기술을 잘 쓰는 사람만 돌봄을 받는” 새로운 불평등을 만들 수 있다.

앨런 쿠퍼

소프트웨어를 설계할 때 가장 먼저 물어야 할 질문은 '이 기능이 가능한가'가 아니라, '이 사람에게 이 기능이 필요한가'다. 사용자의 목표에서 출발하라.

— Cooper (2014)

접근성은 “추가 기능”이 아니라 “기본 요건”이다. 마치 건물에 경사로(ramp)를 설치하는 것이 선택이 아니라 법적 의무이듯, 디지털 상담 도구에서의 접근성도 윤리적 의무다.Cooper(2014)가 강조한 것처럼, 설계의 출발점은 “가장 취약한 사용자가 쓸 수 있는가?”여야 한다. 그 사용자가 쓸 수 있다면, 다른 모든 사용자도 쓸 수 있다. 이것을 포용적 설계(inclusive design)라고 부른다.

접근성 검사를 직접 해보는 간단한 방법이 있다. 먼저 브라우저에서 자기 프로젝트를 열고, 마우스를 쓰지 않고 탭 키만으로 모든 기능에 접근해본다. 다음으로 브라우저 설정에서 글자 크기를 200%로 키워서 레이아웃이 깨지지 않는지 확인한다. 마지막으로 Chrome 개발자 도구의 Lighthouse 기능을 사용하면 접근성 점수를 자동으로 측정해준다. 100점 만점에 90점 이상이면 양호하고, 60점 이하면 개선이 시급하다. 이 세 가지 검사만으로도 대부분의 접근성 문제를 발견할 수 있다.

유발 노아 하라리

기술은 도구다. 도구 자체에는 선악이 없다. 기술이 누구를 위해 작동하는지가 윤리적 판단의 핵심이다.

— Harari (2018)

윤리 체크리스트: 내 프로젝트는 윤리적인가?

9~10주차에 배운 AI 상담 윤리 원칙을 이제 자기 프로젝트에 직접 적용할 차례다. APA(미국심리학회, 2023)는 AI를 상담에 활용할 때 네 가지를 지키라고 한다. 첫째, AI가 전문적 판단을 대체하지 않는다는 걸 내담자에게 알릴 것. 둘째, 데이터 수집·저장·전송 모든 단계에서 동의를 받을 것. 셋째, AI의 한계와 오류 가능성을 투명하게 밝힐 것. 넷째, 미성년자나 위기 상태의 내담자에게 추가 보호 장치를 마련할 것.

왜 이 네 가지가 필요할까? 상담은 다른 서비스와 근본적으로 다르다. 내담자는 자신의 가장 취약한 부분을 드러낸다. 우울, 불안, 트라우마, 가족 문제, 자해 충동 같은 민감한 이야기를 한다. 이런 정보가 유출되거나 오용되면 그 피해는 SNS 계정이 해킹되는 것과 차원이 다르다. 사회적 낙인(stigma, 정신건강 문제를 가진 사람에 대한 부정적 인식)으로 이어질 수 있고, 취업·보험·관계에 직접적 영향을 줄 수 있다.

내 프로젝트에서 점검해야 할 다섯 가지를 구체적으로 보자. 첫째, 동의 화면(Informed Consent) — 앱의 첫 화면에 “이 도구는 무엇이고, 어떤 데이터를 수집하며, AI가 어떤 역할을 하는지”를 설명하는 동의 화면이 있는가? 동의 없이는 서비스를 쓸 수 없도록 되어 있는가? 동의서는 법률 문서처럼 길고 어렵게 쓰면 안 된다. 사용자가 실제로 읽고 이해할 수 있도록 쉬운 말로, 핵심만 간결하게 써야 한다. 연구에 따르면 대부분의 사용자는 1,000자가 넘는 동의서를 읽지 않고 “동의” 버튼을 누른다. 그래서 핵심 내용을 3~5줄로 요약하고, 자세한 내용은 “더 보기”로 제공하는 것이 효과적이다.

둘째, 데이터 저장 정책 — 대화 기록, 검사 점수, 개인 정보가 어디에 저장되는가? 암호화가 적용되어 있는가? 보존 기간과 삭제 절차가 명시되어 있는가? 예를 들어 “대화 기록은 서버에 암호화되어 저장되며, 계정 삭제 시 30일 이내에 완전히 삭제됩니다” 같은 구체적 안내가 필요하다. 한국의 개인정보보호법에 따르면 목적 달성 후에는 지체 없이 파기해야 한다.

유발 노아 하라리

기술이 인간보다 나를 더 잘 알게 되면, 그 기술을 누가 통제하느냐가 가장 중요한 정치적 질문이 된다. 정신건강 데이터의 통제권은 반드시 내담자에게 있어야 한다.

— Harari (2018)

셋째, 위기 감지 안전장치 — 내담자가 자해·자살 관련 표현을 입력하면, 시스템이 즉시 위기상담 전화번호(1393, 109)를 안내하는가?Gainer(2025)는 단순 키워드 매칭이 아니라 맥락 분석을 권고한다. “과제 많아서 죽겠다”(비유)와 “진짜 죽고 싶다”(실제 자살 사고)를 구분해야 하고, 판단이 어려우면 안전한 방향으로 작동(safe-fail)해야 한다. 즉, 비유적 표현을 실제 위기로 오인하는 것(false positive, 과잉 감지)은 사용자에게 불편을 줄 수 있지만, 실제 위기를 놓치는 것(false negative, 미감지)은 생명의 문제다. 그래서 의심스러우면 안전 자원을 보여주는 방향이 맞다.

넷째, 면책 고지문 — “이 도구는 전문 상담을 대체하지 않습니다”라는 안내가 서비스 곳곳에 있는가? 이 고지문은 앱의 첫 화면에만 있어서는 안 된다. AI가 답변을 생성할 때마다, 자가 검사 결과를 보여줄 때마다 반복적으로 노출되어야 한다. 사용자가 AI의 답변을 전문 상담사의 조언과 동일하게 받아들이는 것을 방지하기 위해서다.다섯째, AI 투명성 — 사용자가 AI와 대화하고 있다는 걸 아는가? AI 응답에 “AI가 생성한 응답입니다” 표시가 있는가? 사용자가 AI를 사람으로 착각하면 기대 수준이 달라지고, 실망이나 배신감으로 이어질 수 있다.

무스타파 술레이만

AI 기술을 만드는 사람은 그 기술이 사회에 미칠 영향에 대한 책임이 있다. 기술의 힘이 커질수록 통제와 투명성의 요구도 비례해서 커져야 한다.

— Suleyman (2023)

README 작성: 프로젝트의 얼굴

README는 프로젝트의 첫인상이다. 마치 논문의 초록(abstract)이 논문 전체를 대표하듯, README는 프로젝트 전체를 대표한다. 코드를 처음 보는 사람이 이 문서만 읽고 프로젝트를 이해하고 실행할 수 있어야 한다. GitHub에 프로젝트를 올리면 README가 가장 먼저 보이는 페이지다. 여기서 사람들은 “이 프로젝트가 뭔지”를 30초 안에 판단한다.

포함해야 할 것들이 있다.프로젝트 제목과 한 줄 설명 — “MindBridge: CBT 기반 AI 상담 보조 플랫폼”처럼 정체성을 명확히. 프로젝트 목적 — 이 도구가 해결하려는 문제, 대상 사용자, 핵심 가치를 2~3문단으로. 설치 및 실행 방법 — 환경 설정부터 실행 명령어까지 단계별로. 상담 도구의 README는 일반 개발 프로젝트와 다른 점이 하나 있다 — 윤리적 고려사항 섹션이 반드시 포함되어야 한다는 것이다.

주요 기능 설명 — 각 기능의 스크린샷과 함께 동작 방식을 보여준다. 스크린샷 한 장이 설명 열 줄보다 낫다. 기능 설명은 사용자의 관점에서 쓴다. “감정 분석 API가 연동되어 있습니다”(개발자 관점)보다 “대화 후 AI가 당신의 감정 변화를 시각적으로 보여줍니다”(사용자 관점)가 더 이해하기 쉽다.사용된 AI 모델과 API — 어떤 모델을 쓰는지, 비용 구조는 어떤지. 예를 들어 “Google Gemini 2.5 Flash API를 사용하며, 무료 티어 기준 하루 약 1,500회 요청이 가능합니다”처럼 구체적으로 쓴다.

윤리적 고려사항과 한계 — 이 도구가 할 수 없는 것, 주의해야 할 시나리오, 데이터 보안 정책을 솔직하게 쓴다. 상담사가 만든 도구이므로 이 섹션이 특히 중요하다. “이 도구는 전문 상담을 대체하지 않습니다”, “자살 위기 상황에서는 반드시 전문가에게 연락하세요”를 README에도 넣는다. 한계를 솔직하게 문서화하는 것은 약점이 아니라, 상담사로서의 전문성과 윤리 의식을 보여주는 것이다.

리팩터링: 코드를 깔끔하게 정리하기

리팩터링(refactoring)이란, 코드가 하는 일은 바꾸지 않으면서 내부 구조를 정리하는 것이다. 마치 방 정리와 비슷하다 — 옷을 더 사지 않아도 옷장을 정리하면 찾기 쉬워지듯, 코드도 기능을 추가하지 않아도 구조를 정리하면 읽기 쉬워지고 버그를 찾기 쉬워진다. 학기 중에 급하게 만든 코드에는 보통 세 가지 문제가 있다. 첫째, 중복 코드 — 같은 코드가 여러 곳에 복사-붙여넣기 되어 있다. AI API 호출 코드가 정서 분석, 주제 추출, 회기 요약에 각각 있다면, 하나의 공통 함수로 뽑아내야 한다. 같은 코드가 세 곳에 있으면, 수정할 때도 세 곳을 다 고쳐야 한다. 한 곳이라도 빠지면 버그가 생긴다.

둘째, 매직 넘버 — 코드에 15,10 같은 숫자가 맥락 없이 쓰여 있다. PHQ-9 기준이 15인지 GAD-7 기준이 10인지 코드만 봐서는 알 수 없다. PHQ9_CLINICAL_CUTOFF = 15처럼 이름을 붙여주면 된다. 이름을 붙이는 것만으로도 코드의 가독성(readability, 읽고 이해하기 쉬운 정도)이 크게 올라간다.

셋째, 긴 함수 — 하나의 함수가 100줄이 넘으면, 데이터 검증, API 호출, 결과 처리, 화면 표시가 다 섞여 있을 가능성이 높다. 각각을 별도 함수로 분리한다. 요리에 비유하면, 하나의 레시피에 “재료 준비, 조리, 플레이팅, 설거지”를 전부 쓰는 것보다, 각 단계를 나눠서 정리하는 게 따라 하기 쉬운 것과 같다. AI 코딩 도구에게 “이 함수를 더 작은 함수들로 나눠줘”라고 요청하면 자동으로 분리해주기도 한다.

아론 T. 벡

인지치료의 핵심은 자동적 사고를 의식적으로 검토하는 것이다. 코드 리뷰도 마찬가지다. 무의식적으로 작성한 코드를 의식적으로 점검하면, 숨어 있던 문제가 보인다.

— Beck (1976)

Beck의 인지치료와 코드 리뷰의 유사점은 생각보다 깊다. 인지치료에서 내담자는 자신의 자동적 사고(automatic thought, 의식하지 않고 떠오르는 생각)를 알아차리고 검토한다. 코드 리뷰에서 개발자는 자신이 무의식적으로 작성한 코드를 알아차리고 검토한다. 둘 다 “당연하다고 여기던 것”을 의식의 수면 위로 끌어올리는 과정이다. 이 과정이 없으면 같은 실수를 반복하게 된다 — 상담에서든, 코딩에서든.

리팩터링을 할 때 AI 코딩 도구를 활용하는 구체적 방법이 있다. 프로젝트 전체 코드를 AI에게 보여주고 “중복되는 코드를 찾아줘”, “변수 이름을 더 명확하게 바꿔줘”, “이 함수가 너무 길어. 작은 함수들로 분리해줘”라고 요청한다. AI가 제안하는 변경 사항을 하나씩 검토하고, 동의하는 것만 적용한다. 모든 제안을 무조건 수용하면 안 된다. 상담에서도 수퍼바이저의 피드백을 검토 없이 받아들이면 자기만의 상담 스타일을 만들 수 없듯, 코드에서도 AI의 제안을 비판적으로 검토해야 자기만의 프로젝트가 된다.

세네카 R. 게이너

리팩터링은 코드를 위한 것이 아니라 미래의 나를 위한 것이다. 3개월 후에 다시 열었을 때 이해할 수 있는 코드가 좋은 코드다.

— Gainer (2025, p. 273)

1:1 코칭: 기술 문제 진단과 해결

프로젝트 워크숍의 핵심은 교수와 15~20분간 1:1로 프로젝트를 함께 보는 것이다. 이 과정은 상담에서의 수퍼비전(supervision, 경험 많은 전문가가 초보자의 작업을 검토하는 것)과 구조가 비슷하다. 코칭을 받기 전에 “지금 막혀 있는 부분”을 명확히 정리해 오면 시간을 훨씬 효율적으로 쓸 수 있다. “전반적으로 잘 안 돼요”보다 “API 호출 시 429 오류가 나요”가 구체적이고, 문제 해결도 빠르다.

자주 나오는 기술 문제는 네 가지다. 첫째, API 연동 오류 — “401 Unauthorized”는 API Key가 잘못됐거나 만료된 것, “400 Bad Request”는 요청 형식이 틀린 것, “429 Too Many Requests”는 너무 많이 호출한 것이다. 오류 메시지를 정확히 읽고 API 문서와 대조하면 대부분 해결된다. 오류 메시지는 프로그래밍 세계의 “증상 보고”다. 상담에서 내담자가 “머리가 아파요”라고 하면, 어디가, 언제부터, 어떻게 아픈지 구체적으로 물어보듯, 오류 메시지도 정확히 읽어야 원인을 찾을 수 있다.

둘째, 상태 관리 버그 — 입력한 내용이 화면에 안 나오거나, 새로고침하면 데이터가 사라지거나, 여러 화면 사이에 데이터가 안 맞는 문제다. React의 상태 관리 원칙(한 방향으로 데이터 흐르기, 상태를 부모로 올리기)을 점검한다. 이 문제를 만나면 AI 코딩 도구에게 오류가 발생하는 코드를 보여주고 “데이터가 화면에 반영되지 않는 이유를 알려줘”라고 요청하면 원인을 찾는 데 도움이 된다. 상태 관리 버그는 상담에서의 “전이(transference)”와 비슷하다 — 데이터가 엉뚱한 곳으로 흘러가서 예상치 못한 결과를 낳는다.

셋째, 배포 문제 — 내 컴퓨터에서는 되는데 배포하면 안 되는 경우. 환경 변수를 안 넣었거나, CORS(Cross-Origin Resource Sharing, 서로 다른 서버 사이의 통신 규칙) 문제이거나, 빌드 오류인 경우가 많다. 로컬(내 컴퓨터)과 프로덕션(배포된 서버) 환경의 차이를 이해하는 것이 핵심이다. 넷째, 성능 문제 — AI 응답이 너무 오래 걸려서 사용자가 기다리다 떠나는 경우. 로딩 표시를 추가하거나, 자주 쓰는 응답을 저장해두거나(캐싱), 응답을 한 글자씩 보여주는(스트리밍) 방법이 있다. 사용자 입장에서 “기다리는 시간”과 “기다리면서 아무것도 안 보이는 시간”은 체감이 완전히 다르다. 로딩 애니메이션 하나만 추가해도 사용자 이탈률이 크게 줄어든다.

스티브 크루그

사용성 문제의 대부분은 테스트하면 바로 발견된다. 5명만 테스트해도 전체 문제의 85%를 찾아낸다. 완벽함을 기다리지 말고, 지금 테스트하라.

— Krug (2010)

윤리 체크리스트 실습

Gainer(2025)의 윤리 원칙으로 만든 체크리스트를 자기 프로젝트에 직접 적용한다. 코드를 열어서 실제로 확인하며 체크한다. 이 실습이 중요한 이유는 윤리를 이론으로만 배우는 것과 자기 프로젝트에서 직접 확인하는 것 사이에 큰 차이가 있기 때문이다. “위기 감지가 중요하다”는 교과서 문장이지만, 실제로 “죽고 싶다”를 입력해보고 시스템이 어떻게 반응하는지 확인하는 건 체험이다.

동의 화면이 구현되어 있는가? — 앱의 시작 화면에서 직접 확인. 위기 감지가 작동하는가? — “죽고 싶다” “자해하고 싶다” 같은 테스트 입력을 넣어서 시스템 반응을 확인. 이때 다양한 표현을 테스트해본다: “살기 싫다”, “다 끝내고 싶다”, “없어지고 싶다” 같은 간접적 표현도 감지되는지 확인한다. 면책 고지가 보이는 위치에 있는가? — 사용자가 거치는 주요 화면에서 고지문이 눈에 띄는지 검증. AI 응답에 “AI 생성” 표시가 있는가? — AI가 만든 모든 텍스트에 해당 레이블이 붙어 있는지 확인.

체크리스트는 합격/불합격 시험이 아니다. 각 항목에서 현재 상태와 개선 방안을 함께 기록한다. 예를 들어, “위기 감지: 키워드 기반으로 구현됨. 개선 방안 — 맥락 분석 추가, 비유적 표현 구분 로직 필요” 처럼 구체적으로 적는다. 이 기록은 14주차 사용자 테스트와 15주차 최종 발표에서 “알려진 한계” 섹션의 기초 자료가 된다. 한계를 정직하게 문서화하는 것은 부족함을 인정하는 게 아니라, 전문가로서의 자기 인식(self-awareness)을 보여주는 것이다.

앨런 쿠퍼

완벽한 소프트웨어는 없다. 하지만 자신의 한계를 정직하게 문서화한 소프트웨어는 사용자의 신뢰를 얻는다. 한계를 숨기는 것이 가장 위험한 설계 결함이다.

— Cooper (2014)

세네카 R. 게이너

윤리적 AI 상담 도구는 '무엇을 할 수 있는가'보다 '무엇을 하지 말아야 하는가'를 먼저 정의한 도구다.

— Gainer (2025, p. 271)

README 작성 실습: AI와 협업하되, 윤리는 직접 쓰기

README 작성에 AI를 활용하면 효율적이다. AI 코딩 도구에게 프로젝트 코드를 보여주고 “이 프로젝트의 README.md를 만들어줘”라고 요청하면 기본 구조를 잡아준다. 하지만 AI가 생성한 초안을 그대로 쓰면 안 된다. 특히 “윤리적 고려사항” 섹션은 반드시 직접 써야 한다. AI는 일반적인 윤리 원칙을 나열할 수 있지만, 내 프로젝트에서 실제로 어떤 한계가 있고, 어떤 위험을 발견했고, 어떤 안전장치를 넣었는지는 개발자 본인만 안다.

README에 넣을 윤리적 고려사항의 예시를 보자. “이 도구는 전문 상담을 대체하지 않습니다. 자살·자해 위기 시 1393(자살예방상담전화) 또는 109(정신건강위기상담전화)로 연락하세요.” “AI의 감정 분석은 100% 정확하지 않습니다. 결과를 진단으로 받아들이지 마세요.” “대화 내용은 암호화되어 저장되며, 계정 삭제 시 완전히 삭제됩니다.” 이런 구체적 안내가 사용자의 신뢰를 만든다.