기계를 길들이던 엔지니어, 사람에게 데이다: 강제에서 배려로의 하네스 엔지니어링
고백하자면, 저는 사람보다 기계를 다루는 게 훨씬 편한 백엔드 엔지니어입니다. AI가 제가 원하는 규칙대로 완벽하게 움직이도록 인프라를 짜는 일, 소위 ‘하네스 엔지니어링(Harness Engineering)’에 제 업무 시간의 3할 이상을 쏟아부었으니까요. 요즘 정보기술(IT) 업계가 입에 달고 사는 ‘AX(AI 전환)’의 바닥을 까는 작업이라고 보시면 됩니다.
하지만 최근, 정작 매일 얼굴을 맞대는 팀원들과의 피드백 과정에서 호되게 넘어지는 불미스러운 사태를 겪었습니다. 기계를 통제하는 법은 밤새워 고민했으면서, 정작 동료의 마음과 제 피드백 사이의 간극은 살피지 못했던 것입니다.
이 글은 기계를 길들이던 제가 사람에게 데이며 얻은 아픈 깨달음에 대한 기록입니다. 그리고 그 깨달음을 통해, AI에게 방식을 ‘강제’하던 저의 하네스 엔지니어링 철학이 어떻게 사람과 AI 모두를 ‘배려’하는 방향으로 뒤집혔는지, 그 6개월간의 생존기와 도구들을 소개하고자 합니다.
📌 목차
- 기계를 길들이던 내가 사람에게 데였습니다
- AI도 팀원입니다: ‘강제’에서 ‘배려’로 바꾸는 하네스
- 단어도 모른 채 반납했던 설날 연휴: 모든 것의 시작
- 디자이너가 코드를 직접 고치는 팀의 탄생
- 회고: 더 나은 방향이라 믿으며
1. 기계를 길들이던 내가 사람에게 데였습니다
얼마 전, 팀원에게 피드백을 전달하는 과정에서 서로 감정이 상하는 일이 있었습니다. 누구의 잘잘못을 따지기 전에, 분명한 건 제가 ‘어려운 말’을 다루는 데 무척 서툴렀다는 사실이었습니다.
마음이 무겁던 중 한기용 멘토님과 이야기를 나눌 기회가 있었고, 거기서 인생의 터닝포인트가 될 문장을 건졌습니다.
“가장 중요한 것은, 어려운 말을 하는 것에 익숙해져야 한다는 것이다.”
멘토님이 말씀하신 어려운 말이란, 서로 오해가 생기지 않도록 다음 네 가지 요소를 차근차근 꺼내놓는 대화법이었습니다.
- 기대: 내가 상대에게 무엇을 기대했는가
- 관찰: 실제로는 어떤 행동이나 결과가 관찰되었는가
- 간극: 그 둘 사이의 차이(gap)는 무엇인가
- 개선방안: 이를 기반으로 한 구체적이고 실현 가능한 대안은 무엇인가
이 네 가지가 빠지면 좋은 의도로 꺼낸 피드백도 날카로운 칼날이 되어 상처로 돌아옵니다. (더 깊은 내용이 궁금하시다면 한기용 멘토님이 추천해 주신 책 『결정적 순간의 대화』, 『리더십 연습』이나 유튜브 채널 ‘한기용 유니버스’를 참고해 보셔도 좋습니다.)
재미있는 건, 이 진리가 임용한 교수님의 강의를 통해 읽었던 손자병법 구절과 닿아 있다는 점입니다. 바로 상하동욕자승(上下同欲者勝), “윗사람과 아랫사람이 같은 목표를 바라면 반드시 승리한다”는 말입니다.
그 구절을 접한 지 6개월이 지난 이제서야 ‘같은 목표를 바라본다는 것’의 진짜 의미를 깨달았습니다. 오해를 없애기 위해 가장 먼저 해야 하는 일은 ‘나와 상대의 기대가 무엇인가’에 대한 합의를 하는 것이고, 이것이 결국 올바른 피드백의 본질이었습니다.
그리고 놀랍게도, 이 깨달음은 제가 AI를 대하는 태도까지 통째로 바꾸어 놓았습니다.
2. AI도 팀원입니다: ‘강제’에서 ‘배려’로 바꾸는 하네스
사람 팀원과 오해 없이 일하기 위해 기대를 맞추고 피드백을 주고받아야 한다면, AI와 일할 때도 똑같은 과정이 필요하지 않을까요? 요즘 저는 AI도 우리 팀의 신입 팀원이라 생각하고 하네스를 다시 구축하는 중입니다.
이전의 하네스 엔지니어링이 AI가 ‘내가 생각하는 올바른 방식으로 일하도록 강제하는 것’에 치중했다면, 지금은 ‘어떻게 하면 사람이 AI와 일하는 게 더 편하도록 만들 수 있는가’에 집중하고 있습니다. 기대를 먼저 맞추는 회의 프로세스를 시스템으로 이식한 것이죠.
아직 완성 단계는 아니지만, 새롭게 설계 중인 하네스 도구들의 핵심 메커니즘을 살짝 공유합니다.
- plan-intake: 본격적인 작업을 시작하기 전, 무엇을 왜 하려는지 목적과 요구사항을 명확히 접수하고 싱크를 맞추는 단계입니다.
- 파인만 이해 게이트: “쉽게 설명하지 못하면 제대로 이해한 것이 아니다”라는 파인만 기법에서 착안했습니다. AI에게 구현 방향을 역으로 쉽게 설명하게 만들어, 정말 제대로 이해했는지 검증하는 관문입니다.
- align-fix-direction: 문제를 해결하는 경로가 여러 개일 때, 곧장 코드를 짜는 대신 어느 방향으로 나아갈지 미리 합의하는 단계입니다.
- amazon 6 pager: 아마존의 서술형 문서 기반 회의 문화에서 빌려왔습니다. 핵심 맥락과 엔지니어링 고려사항을 글로 풀어 공유하는 장치입니다.
- design spec: 설계가 확정되면 구현 직전에 명세를 최종 확인하여 모두가 같은 그림을 보게 만드는 단계입니다.
3. 단어도 모른 채 반납했던 설날 연휴: 모든 것의 시작
이쯤에서 시간을 올해 1월 말로 되감아 보겠습니다. 제가 왜 설날 연휴까지 전부 반납해가며 밤낮으로 이 인프라를 구축하고 채팅 기능을 개발했었는지에 대한 이야기입니다.
당시 제가 이끄는 매니패스트(Manyfast) 팀의 구성원은 기획자, 디자이너, 프론트엔드 개발자, 그리고 백엔드인 저까지 총 4명이었습니다. 이 구성으로 고전적인 개발 프로세스를 고집하면 중간 소통 비용이 너무 컸습니다. 기획서를 받으면 디자인을 뽑고, 그걸 프론트엔드에게 설명하고, 프론트엔드는 다시 백엔드에게 필요한 API를 요청하고… 제품이 만들어진 뒤에도 수정 논의가 끝없이 반복되었습니다.
게다가 우리 팀은 이런 방식에 극도로 숙련된 시니어 집단도 아니었습니다. 간단한 작업조차 소통에 너무 많은 시간이 소요되어 일이 좀처럼 진척되지 않았죠. 팀장이 된 제 머릿속에는 오직 하나의 생각뿐이었습니다. “우리 팀은 AX(AI 전환)를 이뤄내지 못하면 살아남을 수 없다.”
그래서 절박한 마음으로 작성했던 사내 제안서의 제목이 바로 ‘매니패스트 가볍고 빠르게 움직이기’였습니다. 목표는 명확했습니다.
회사 내 전체 인원이 AI를 ‘자신에게 전담 배치된, 시키는 대로 잘하는 신입 개발자’로 활용할 수 있도록 프로세스를 변경합니다. 이를 위해 신입 개발자인 AI가 문제없이 작업할 수 있는 환경(인프라) 구축은 리드 엔지니어인 내가 진행하고, 각각의 작업물에 대한 최종 검토는 전문 개발자가 진행합니다.
당시에는 ‘하네스 엔지니어링’이라는 멋진 표현도 모른 채, 그저 생존을 위해 맨땅에 헤딩하듯 인프라를 만들고 있었던 셈입니다.
4. 디자이너가 코드를 직접 고치는 팀의 탄생
그렇게 설날을 반납하며 만든 하네스는 기대 이상으로 강력했습니다. 제가 하네스를 구축할 때 가장 신경 쓴 핵심은 ‘비개발 인원도 AI를 개발자처럼 부릴 수 있게 만드는 기본기’였습니다.
테스트 코드를 꾸준히 작성하며 동작을 확인하는 것(TDD), PR(Pull Request)을 올리기 전에 빌드가 정상적으로 되는지 체크하는 것, 프로그램을 직접 띄워 눈으로 확인하는 것 등 개발자라면 지켜야 할 루틴을 하네스 시스템에 새겨 넣었습니다.
팀원분들의 뛰어난 역량과 빠른 적응력 덕분에 놀라운 변화가 일어났습니다.
- 디자이너가 직접 코드를 수정하며 디자인 파이널 터치를 진행하기 시작했습니다.
- 운영팀장 jun님 역시 제품에서 발견한 결함들을 AI의 도움을 받아 스스로 수정해서 전달해 주셨습니다.
개발자가 아닌 팀원들이 직접 프로덕션 코드를 만지고 개선하는 팀이 된 것입니다. 덕분에 우리는 3월 초 성공적으로 서비스를 론칭했고, 지금은 감사하게도 예상보다 훨씬 많은 유저분들의 사랑을 받으며 안정적으로 서비스를 운영하고 있습니다.
5. 회고: 더 나은 방향이라 믿으며
저의 하네스 엔지니어링은 기계를 완벽하게 통제하려던 ‘강제’의 시대를 지나, 사람과 기계가 어떻게 더 편하게 협업할 수 있을지 고민하는 ‘배려’의 시대로 나아가고 있습니다.
단순히 AI의 생산성을 높이는 것을 넘어, AI를 팀원으로 바라보는 과정에서 역설적으로 ‘사람 팀원과 오해 없이 일하는 법’을 다시금 배우게 되었습니다.
지금 새롭게 빌드하고 있는 구조들이 앞으로 우리 팀을 또 얼마나 성장시킬지 기대됩니다. 당장에는 이전보다 훨씬 나은 방향으로 가고 있다는 확신이 들어, 시간 나는 대로 제 나름의 정리를 겸해 포스팅을 남깁니다.
여러분의 팀, 그리고 여러분의 AI 하네스는 지금 ‘강제’와 ‘배려’ 중 어디쯤에 위치해 있나요?