오래된 SW 엔지니어의 평생 공부

매주 반복되는 고민: '성찰'은 왜 이렇게 힘들까?

매주 대화 훈련 파트너와 함께 상호 코칭을 하며 동기면담(MI)을 연습하는 시간은 나에게 매우 소중하다. 하지만 늘 풀리지 않는 숙제가 있었다. 대화가 끝나고 녹음 파일을 축어록으로 변환해 살펴보는 과정이 너무나 고되었기 때문이다.

어렵게 만든 축어록을 앞에 두고도 "공감이 부족한 것 같아요"라거나 "내가 너무 말을 많이 했네요" 같은 모호한 감상 이상의 피드백을 나누기는 쉽지 않았다. 피드백이 자칫 상대방을 평가하는 것처럼 느껴질까 봐 조심스러워지기도 했고, 정작 중요한 성찰의 포인트는 일상의 바쁨 속에 금세 휘발되곤 했다. 저는 이 '막막함'을 해결하고 싶었다. 대화의 복잡함을 걷어내고, 우리가 무엇을 실험해야 할지 알려주는 명확한 틀이 필요했다.

'Generative Sequence'로 쌓아 올린 나만의 성찰 공간

이 프로젝트를 시작하며 제가 선택한 방법은 한꺼번에 완벽한 서비스를 만드는 것이 아니었습니다. 대신 CLAUDE.md에 정의한 Generative Sequence 원칙에 따라, 시스템의 '생명력'을 한 단계씩 키워나갔다.

처음에는 그저 대화를 기록할 수 있는 '그릇'을 만드는 것에서 시작했다. 이어 외부 툴에서 만든 축어록을 손쉽게 가져오는 기능을 넣었고, 여기에 AI가 특정 관점(Lens)으로 대화를 관찰해 질문을 던져주는 기능을 더했다. 이렇게 차근차근 벽돌을 쌓아 올리듯 구현해 나가는 과정은, 제가 코칭 현장에서 느꼈던 갈증을 하나씩 해소해 나가는 과정이기도 했다.

전율의 순간: MITI 정밀 분석과 연습 카드의 만남

가장 결정적인 순간은 MITI 4.2 정밀 분석(T-013)을 시스템에 이식했을 때 찾아왔다. 동기면담의 전문적인 평가 기준이 AI를 통해 데이터로 치환되어 화면에 뿌려지는 순간, 저는 비로소 "이게 내가 바라던 거구나"라는 확신을 얻었다.

단순히 "잘했다"는 칭찬 대신, 상담자의 역량과 내담자의 반응이 Radar Chart로 그려지며 대화의 역동이 눈앞에 시각화되었다. 특히 감동적이었던 것은 '연습 카드(Practice Cards)'였다. 대화 중 놓쳤던 결정적 순간을 포착해 "이 상황에서 이 대안 문장을 써봤다면 어땠을까요?"라고 제안하는 카드를 뒤집어보며, 저는 평가의 부담에서 벗어나 '실험의 재미'를 발견했다.

다음 상호 코칭이 기다려지는 이유

이제 저와 파트너의 연습은 이전과 전혀 다른 양상을 띠게 될 것이다. 우리는 더 이상 서로를 '평가'하지 않을 것같다. 시스템이 제공하는 구체적인 관찰 지표를 놓고 함께 '연구'한다.

"이번 세션에서는 이 연습 카드에 나온 '열린 질문'을 중점적으로 실험해 볼까요?"라고 제안하며, 대화는 판정으로 닫히는 결과물이 아니라 다음 대화를 여는 풍부한 재료가 된다. 이 시스템은 우리를 더 잘 말하게 만들기보다, 우리의 대화를 더 깊게 만들고 있다.

이 시스템이 우리의 대화 훈련에 더 큰 도움이 되고, 다른 사람들과도 이 시스템을 나누게 될 것이라는 기대가 크다. 이 시스템의 여정은 이제 막 시작되었다.

참고 문서

Dialog Lab : https://github.com/blcktgr73/DialogueLab

요즘 알고 지내는 비개발자들이 Vibe Coding/Agentic Coding에 푹 빠져 사는게 보인다. 나에게도 AI는 내 아이디어를 실현해 주는 구세주와 같다. 하지만 여러 가지 개발을 해보다 보니, 어느 정도 개발이 진행되다 보면 "AI가 왜 답답하게 굴지?" 혹은 "고쳤다는데 왜 똑같은 에러가 나지?" 같은 도돌이표 상황에 빠지게 된다. 새삼, 개발자들이 AI가 만든 코드를 완전히 믿지 못한다는 것도 공감이 가기도 한다.

내 경험을 기반으로 '바이브 코딩(Vibe Coding)'의 한계를 넘어서, 프로젝트를 끝까지 완수하게 만드는 실전 팁을 정리했보았다.

1. AI가 제자리걸음을 할 땐 '피드백'을 요청하자

AI가 비슷한 코드가 너무 오래 걸린다거나, 혹은 문제 수정 상황이 반복되는 느낌이 있다면, 어떻게 하는가? 그렇다면 대화의 주도권을 가져와야 한다. 피드백을 달라고 요청해야 한다.

• 설명 요청: AI로 생성한 코드가 시간이 오래 걸리는 경우가 종종 있다. 그럼, 세우고 "어떤 동작을 하고 있는지 사용자가 알수 있도록 해줘"라고 해보자. UI로 진행 상황을 표현하기도 하고, Command Line Interface(CLI) 코드라도 중간 진행 사항을 알려준다.
• 회고 요청: "지금 상황을 설명해줘", "지금까지 시도한 방법들을 요약해줘", 혹은 "왜 실패했는지 네 생각을 말해줘"라고 시켜보자.
• 관점 전환: "지금 방식 말고 아예 다른 접근 방식 3가지만 제안해 봐"라고 요청하면, AI가 스스로 고정관념에서 벗어나 새로운 길을 찾기도 한다.

계속 같은 상황을 반복시키는 것은 토큰 낭비이기도 하지만, 귀중한 우리의 시간도 낭비하고 있게 된다.

2. AI의 눈과 귀가 되는 상세한 '로그(Log)'

개발자들이 디버깅한다는 이야기를 많이 들어보았을 것이다. 여러 가지 방법이 있지만, 가장 많은 방법이 로그를 확인하는 것이다. 우리도 내 컴퓨터 안에서 무슨 일이 일어나는지 모르지만, AI도 마찬가지이다. 문제가 일어나는 상황을 정확히 전달해야 한다.

• 로그 추가 요청: 에러 원인을 모를 땐 "어디가 문제인지 알 수 있게 로그(console.log 등)를 추가해 줘"라고 하자.
• 환경별 대응: 브라우저 콘솔, 서버 터미널, 심지어 모바일 앱에서도 로그를 뽑아 AI에게 먹여주면 정답률이 비약적으로 올라간다.

3. '정책(Policy)'과 '패턴(Pattern)' 문서화

개인적으로는 Claude Code를 초기에 많이 써서, 개발 방법을 CLAUDE.md에 저장해 두고 쓴다. 개발 세션을 시작할 때, 이런 약속들을 상기 시키고 시작한다. 하지만, 시간이 지나가거나 프로젝트가 커지면 AI는 이전에 약속했던 규칙(예: 디자인 스타일, 변수 이름 규칙 등)을 잊어버린다.

• 규칙 저장소: 반복적으로 지켜야 하는 정책이나 코드 패턴은 별도의 .md 문서(예: POLICY.md)로 정리하자.** 최근에는 LLM을 통해 생성한 결과를 json으로 받을 때, 예외가 많이 생기고 해서 이 부분을 해결하는 부분을 공통코드로 만들었다. 이 때, 패턴 문서를 만들어 AI가 참고하도록 하고 있다.
• 참조 지시: "새 기능을 짤 때 항상 POLICY.md 문서를 참고해서 작성해 줘"라고 지시하면, 프로젝트의 일관성이 유지되고 나중에 코드를 갈아엎는 불상사를 막을 수 있다. 최근에 pdf를 생성하는 규칙도 반복되니 정책(Policy)라는 이름으로 markdown 문서를 생성하고 참고하게 했다.

4. GitHub 저장소 활용: AI와의 협업에서 '세이브 포인트' 만들기

컴퓨터로 작업하는 사람들이 공동적이면서 기본으로 말하는 작업의 가장 중요한 부분은 백업인 것 같다. 개발자에게 backup에 해당하는 것이 코드 저장소라고 할 수 있다. Agentic Coding에서 코드 저장소(Repository)는 단순히 코드를 보관하는 창고가 아니다. AI와 대화하며 코드를 고치다 보면, 잘 되던 코드가 갑자기 엉망이 되어 "어디서부터 잘못됐지?"라고 자책하게 되는 순간이 온다.

• Commit은 '세이브'이다: 기능 하나가 성공적으로 구현될 때마다 Commit(기록)을 남기세요. "로그인 기능 구현 완료"라고 적어두면, 나중에 AI가 사고를 쳐도 클릭 한 번으로 가장 완벽했던 상태로 되돌아갈 수 있다.
• AI에게 과거를 보여주자: "이전 버전에서는 잘 작동했는데 지금은 안 돼. 이전 코드랑 비교해서 뭐가 달라졌는지 분석해 줘"라고 요청할 수 있다. GitHub에 기록된 히스토리는 AI에게 가장 강력한 학습 데이터가 된다.
• Branch로 실험하기: 새로운 기능을 시도할 때는 기존 코드를 건드리지 말고 '새 가지(Branch)'를 치자. 마음껏 실험하다가 망하면 그냥 삭제하고 원래 가지로 돌아오면 그만이다. 비개발자가 '두려움 없이' 코딩하게 만드는 가장 큰 힘이다.
• 버전 관리 도구 활용: git의 "터미널 명령어가 어렵다면 앱을 사용해도 좋다. VS Code도 기본적인 git/github 연동은 잘 되는 편이다.

5. Playwright로 '자동 검사기' 세우기

나도 마찬가지이지만, 비개발자가 가장 무서워하는 것은 "하나를 고쳤는데 기존에 잘 되던 기능이 망가지는 것"일 것이다.

• End to End (E2E) 테스트: Playwright를 사용해 사용자의 클릭과 이동 경로를 테스트 코드로 짜달라고 하자. 명령어 한 줄 혹은 자동화 기법으로 추가 개발한 내용이 기존 동작을 망가뜨리는지 확인할 수 있다.
• 안전장치: 새 기능을 넣은 후 테스트를 돌려 "기존 기능이 여전히 안전함"을 확인받는 순간, 코딩에 대한 막연한 공포가 자신감으로 바뀌게 된다.

6. GitHub Actions로 '24시간 관리자' 채용하기

위와 같은 E2E 테스트를 내가 직접 테스트를 돌리는 것조차 잊어버릴 수 있다. 이때 GitHub Actions가 해결책이 된다.

• 자동화: 코드를 올릴 때마다 서버가 자동으로 Playwright 테스트를 실행해 "합격/불합격"을 알려준다.
• 신뢰도: 시스템이 "이 코드는 안전하다"라고 보증해 주니, AI의 코드를 훨씬 더 믿고 빠르게 수용할 수 있다.

Vercel과 같은 서비스는 github action과도 잘 연계가 되어서, 내가 수정한 사항을 github에 적용하면 자동으로 배포해 준다.

개발의 최종 목표는 '시스템'

단순히 AI에게 코드를 짜달라고 하는 단계를 넘어, 나만의 검증 시스템과 규칙을 갖추게 되면 상용 수준으로 올라가는 기본이다.

1. 전략 회의: 막힐 땐 AI에게 해결 전략을 묻기.
2. 철저한 기록: 로그와 정책 문서화로 AI에게 컨텍스트 제공하기.
3. 자동 검증: Playwright와 GitHub Actions로 안전장치 만들기.

이 시스템만 갖춰지면, 비개발자도 수만 줄의 코드를 가진 복잡한 서비스를 전문가처럼 안정적으로 운영할 수 있는 기본을 갖추게 된다. 이제 AI는 단순한 도구가 아니라, 여러분의 든든한 '엔지니어링 팀'이 될 것이다.