AI 개발 현장의 소통 미스, 우리는 정말 같은 언어를 쓰고 있을까?
AI 개발 프로젝트를 시작할 때, 팀장과 실무자는 모두 한 방향을 바라보고 있다고 확신합니다. 하지만 현실에서는 생각보다 서로 다른 '언어'를 쓰고 있곤 하죠. 소통의 간극이 작아 보여도 시간이 지날수록 큰 장애물이 될 수 있습니다. 특히 일정이 촉박한 상황이나 예상치 못한 변수 앞에서 이 차이는 더욱 두드러집니다.
이 글에서는 팀장과 실무자 사이에서 종종 발생하는 인식의 차이와 그로 인한 문제를, 실제 현장 사례를 바탕으로 살펴보고 어떻게 하면 이런 차이를 좁힐 수 있을지에 대한 다양한 방법을 공유합니다.
1. 우리 팀은 왜 가끔 다른 말을 하고 있을까?
프로젝트 초기 회의에서 팀장은 "고객사의 요청에 맞춰 이번 달 말까지 AI 기반 추천 시스템을 런칭해야 한다"고 말합니다. 실무자는 곧바로 '데이터 확보는 되었는가', '기존 모델을 튜닝해야 하는가', 'API 인터페이스는 정해졌는가' 등 구체적인 질문들을 떠올리죠.
팀장이 주로 전략과 방향, 일정 관리에 집중하는 반면, 실무자는 결과물을 구현하는 데 필요한 현실적인 정보와 조건에 집중합니다. 둘 다 맞는 방향이지만, 이 간극을 줄이려면 회의 초기부터 서로의 전제 조건과 기대치를 맞춰야 합니다.
2. 목표는 같지만 중요하게 여기는 것이 다르다?
예를 들어 AI 챗봇을 개발한다고 했을 때, 팀장은 일정 내에 MVP를 구현해 데모를 보여주는 데 초점을 둡니다. 반면 실무자는 사용자 의도 분류의 정확도나 멀티턴 대화의 안정성을 고민하죠.
이 차이는 프로젝트 후반으로 갈수록 격차로 드러납니다. 팀장은 “왜 아직도 완성되지 않았냐”고 묻고, 실무자는 “아직 모델의 정밀도가 기준 미달이다”라고 답합니다. 서로 같은 목표를 향하고 있지만, 중요하게 생각하는 기준이 다른 겁니다. 이럴 땐 각자의 우선순위를 명시하고, 서로의 기준을 이해하려는 노력이 필요합니다.
3. 왜 우리끼리 소통이 안 될까?
가장 흔하게 발생하는 문제는 정보의 비대칭입니다. 팀장은 외부 미팅을 통해 큰 그림을 보고 전략적 결정을 합니다. 하지만 그 내용이 실무자에게 충분히 전달되지 않는 경우가 많습니다.
“이 기능 왜 넣는 거예요?”, “갑자기 방향이 바뀐 이유가 뭔가요?” 같은 질문이 실무자 사이에서 나오는 이유도 여기에 있습니다. 팀장이 알고 있는 비즈니스 배경이나 전략 변화가 빠르게, 투명하게 공유될 수 있는 구조를 만드는 것이 소통 문제 해결의 핵심입니다.
4. IT 기술이 발전할수록 더 힘들어진다고?
클라우드, 컨테이너, MLOps, VLM 등 다양한 기술이 동시다발적으로 등장하면서 팀 내 역할은 점점 더 세분화되고 있습니다. 백엔드, 프론트엔드, 데이터 엔지니어, 모델 엔지니어, 인프라 엔지니어 등 각자의 전문 분야가 깊어질수록 전반을 이해하기 어려워지죠.
이런 상황에서는 단순한 정보 전달만으로는 부족합니다. 각자의 역할과 사용 기술을 간단한 다이어그램이나 시각 자료로 정리하고, 팀원들이 서로를 이해할 수 있도록 돕는 문화가 필요합니다.
5. 경력에 따라 기대치도 달라진다?
주니어 개발자는 정해진 일을 충실히 수행하는 데 집중하지만, 시니어 개발자는 시스템 전체의 설계 방향과 품질, 확장성을 고민합니다. 이 차이에서 생기는 대표적인 갈등 중 하나는 '일 처리 속도'입니다.
“왜 이렇게 오래 걸리지?”라는 질문은 팀장이 주니어에게, 또는 주니어가 시니어에게 모두 할 수 있습니다. 하지만 그 이면에는 단순한 속도 문제가 아니라, 어떤 기준과 철학으로 일을 하는가에 대한 이해가 부족한 경우가 많습니다. 이럴 땐 단순히 결과를 평가하기보다는, 왜 그런 결정을 내렸는지, 어떤 배경 지식과 우선순위가 있었는지를 함께 공유해야 합니다.
시작부터 명확히 하자, '인풋과 산출물'
많은 프로젝트에서 인풋(초기 제공 정보)과 산출물(최종 기대 결과물)을 명확히 정리하지 않고 시작하는 경우가 많습니다. 이는 추후 혼선과 재작업으로 이어지기 쉽습니다.
예를 들어 AI 모델을 만들 때, 팀장은 “고객 데이터를 기반으로 90% 정확도의 분류 모델을 6월까지 배포”라고 말합니다. 실무자는 그 말만으로는 시작할 수 없습니다. 데이터 라벨의 기준은? 전처리는? 어떤 방식으로 성능을 검증할 건지? 이런 부분이 빠져 있으면 결국 중간에 다시 확인하고, 수정하고, 일정이 미뤄집니다.
프론트엔드 작업도 마찬가지입니다. 팀장은 “2주 안에 대시보드 페이지 완성”이라고 말하지만, 실무자는 디자인 시안, API 문서, 사용 시나리오가 모두 필요합니다. 이를 미리 정리하지 않으면 디자이너나 기획자의 피드백이 늦어지고, 작업도 지연되기 마련입니다.
진짜 고객은 누구인가?
제품을 만들 때, 우리는 흔히 "사용자 중심 개발"을 이야기합니다. 그런데 팀장과 실무자가 생각하는 ‘사용자’가 서로 다를 수 있습니다.
팀장은 고객사나 비즈니스 파트너, 투자자 등 외부 이해관계자를 진짜 고객이라 생각합니다.
실무자는 자신이 직접 구현하고 테스트해야 하는 내부 사용성이나 시스템의 안정성을 더 민감하게 인식합니다.
그래서 '이건 왜 이렇게 만들어야 하죠?' 같은 질문이 자주 나옵니다. 내부 요구사항과 외부 요구사항을 구분하고, 무엇을 기준으로 우선순위를 잡을 것인지 명확히 해야 갈등이 줄어듭니다.
Stakeholder Alignment Framework처럼 다양한 이해관계자의 요구를 정리하고 조율하는 구조적 방법론이 실제로 유용합니다. 각자의 목표와 선호도를 시각적으로 정리하고, 우선순위 조정 기준을 팀 전체와 공유해야 합니다.
우리 팀의 현실적인 실험과 변화들
한국딥러닝은 이 문제를 해결하기 위해 아래와 같은 작은 실험들을 시작했습니다.
프로세스 시각화: 업무 흐름을 단계별로 도식화하고, 각 단계에서 기대하는 인풋과 산출물을 명확히 정의해 문서화했습니다.
스크럼에서의 ‘고객 정의’ 질문: 매일 아침 스크럼 회의에서 오늘 우리가 일하는 대상은 누구인지, 이 기능은 누구를 위한 것인지 묻는 시간을 넣었습니다.
실무자의 초기 기획 참여: 기획 초안 단계에서 실무자가 참여해, 기술적 제약이나 리소스 요구사항을 미리 공유할 수 있도록 했습니다.
짧은 싱크업과 빠른 피드백 루프: 긴 회의 대신 15분 이내의 싱크업과 결과물에 대한 빠른 피드백을 통해 생산성을 높였습니다.
Working Agreement 수립: 팀원들이 모두 공감할 수 있는 업무 원칙을 정리해 문서화하고, 신규 멤버 온보딩 시 공유하고 있습니다.
이 실험들은 아직 진행 중이고, 저희도 그 효과를 하나씩 검증해 나가는 중입니다. 완벽한 정답은 없지만, 중요한 건 문제를 명확히 정의하고 작은 시도부터 시작해 보는 것입니다.
AI 개발팀은 기술보다 ‘사람’의 문제로 인해 더 자주 멈춥니다. 그래서 우리는 ‘어떻
게 더 잘 만들까?’만큼이나 ‘어떻게 더 잘 일할까?’를 끊임없이 고민하고 있습니다.
이 글이 비슷한 고민을 하고 있는 팀에게 작은 참고가 되었기를 바랍니다. 앞으로도 한국딥러닝 AI팀의 시행착오와 실험기를 계속 나눌 예정이니, 많은 관심과 피드백 부탁드립니다.
