보고, 연락, 상의가 원활하지 않은가?
정보 흐름의 단절이 생산성에 미치는 영향과 우리의 고민
“왜 우리는 열심히 일하는데도 개발 생산성은 낮을까?”
이 질문에서 시작된 우리의 여정은 단순히 효율을 높이자는 구호를 넘어서, 일의 본질과 방식을 다시 묻는 과정이었습니다. 이번 글에서는 개발팀 내에서 ‘보고, 연락, 상의’가 원활하지 않아 정보가 제때 공유되지 않고, 그로 인해 의사결정이 늦어지며 일의 흐름이 끊기는 문제에 대해 이야기하고자 합니다.
정보가 흐르지 않을 때, 생산성은 어떻게 무너지는가
개발 현장에서 가장 자주 마주치는 문제 중 하나는, 필요한 정보가 제때 전달되지 않아 업무가 지연되고, 불필요한 대기와 재작업이 반복된다는 점입니다. 예를 들어, 실무자가 작업 중 중요한 이슈를 발견했지만, 이를 어떻게 보고해야 할지, 누구에게 연락해야 할지 명확하지 않다면, 문제 해결이 지연되고 프로젝트 전체 일정에 영향을 미칠 수 있습니다.
구체적인 상황 예시로 설명드려볼까요?
AI OCR 및 Deep Image 솔루션을 개발하는 팀이 있다고 가정해볼게요.
이 팀의 목표는 비정형 문서(계약서, 증빙자료 등)를 자동으로 인식·분류하고, 주요 정보를 추출해 ERP 등 내부 시스템과 연동하는 것입니다. 그러나 정보의 흐름이 원활하지 않을 때, 생산성은 다음과 같은 방식으로 무너집니다.
1. 정보 단절이 초래하는 문제
•
요구사항 전달 미흡
◦
고객사로부터 받은 요구사항이 기획자에서 개발자, QA, 운영팀으로 제대로 전달되지 않음.
◦
예: 계약서 내 특정 조항(예: 리스크 항목) 추출이 중요하다는 사실이 일부 인원에게만 공유됨.
•
기술적 결정의 불투명성
◦
어떤 딥러닝 모델을 쓸지, 데이터 라벨링 기준이 무엇인지 등 핵심 결정이 문서화되지 않고 구두로만 전달됨.
•
테스트 결과 피드백 지연
◦
QA담당자가 발견한 버그, 인식률 저하 원인 등이 개발팀에 늦게 전달되어 수정이 반복적으로 지연됨.
2. 생산성 붕괴의 구체적 양상
문제 상황 | 실제 발생 예시 | 결과 |
요구사항 미전달 | "계약서의 날짜·금액만 추출"
→ 실제론 "주요 조항, 리스크 항목도 추출 필요" | 재개발, 일정 지연, 신뢰도 하락 |
라벨링 기준 불명확 | 데이터 라벨링 가이드가 팀마다 다름 | 모델 성능 저하, 인식 정확도 하락 |
모델 변경 정보 누락 | 모델 버전업 사실이 운영팀에 미공유 | 구버전 배포, 오류 발생, 고객 불만 |
피드백 루프 단절 | QA가 발견한 오류가 개발팀에 전달되지 않음 | 동일 오류 반복, 품질 저하 |
문서 자동화 연동 누락 | ERP 연동 방식이 일부만 공유됨 | 수작업 병행, 자동화 효과 반감 |
3. 가상의 문제 사례로 보는 정보 흐름의 중요성
•
가상의 고객사 AI OCR 프로젝트
◦
기존에는 23종의 신청·증빙 서류를 하나의 PDF로 받아 수작업으로 분류·입력, 문서 누락·입력 오류·병목이 반복.
◦
DEEP OCR+ 도입 후, 문서 병합 해제·분류·주요 항목 추출 전 과정이 자동화되고, 실시간 대시보드·RPA 연계로 후속 업무까지 연동.
◦
핵심: 각 단계별 정보가 실시간으로 공유되어야만 자동화의 효과가 극대화됨. 정보가 막히면, 자동화 시스템도 수작업 보완이 필요해지고 생산성은 다시 하락.
4. 개발팀 내부에서의 정보 흐름 개선 방안
•
문서화와 시스템 연동
◦
요구사항, 라벨링 가이드, 모델 변경 내역 등을 위키·이슈트래커에 기록, 모든 팀원이 접근 가능하게 함.
•
자동화된 피드백 루프
◦
QA 결과, 운영 이슈를 슬랙·이메일 등으로 자동 공유, 실시간 알림 제공.
•
API·RPA 연동 현황 대시보드
◦
ERP 등 외부 시스템 연동 상태를 시각화하여, 연동 누락·오류 발생 시 즉시 감지.
AI OCR & Deep Image 솔루션 개발팀에서 정보가 흐르지 않으면,
•
요구사항 오해, 라벨링 오류, 모델 성능 저하, 자동화 효과 반감 등으로 생산성이 급격히 무너집니다.
•
실제 현장에서는 문서 자동화 솔루션의 도입 효과도 정보 흐름의 원활함에 달려 있습니다.
•
정보의 흐름을 체계적으로 설계·관리하는 것이 자동화·AI 프로젝트의 성공과 생산성 유지의 핵심입니다.
실무자와 팀장, 모두의 커뮤니케이션 역량이 필요하다
•
실무자 입장에서는, 자신의 생각과 이슈를 명확하게 전달하는 메시지 전달 능력이 중요합니다. 하지만 때로는 “내가 이 정도는 혼자 해결해야 하지 않을까?”라는 생각에, 필요한 정보를 제때 공유하지 못하는 경우가 생깁니다.
•
반대로, 팀장 역시 실무자로부터 올라오는 메시지를 열린 마음으로 받아들이고, 필요한 질문을 던지며 상황을 정확히 파악하는 역량이 필요합니다. 하지만 바쁜 일정과 여러 업무에 치이다 보면, 실무자의 신호를 놓치거나 오해하는 일이 발생하기도 합니다.
예시 상황 1: 요구사항 해석의 차이로 인한 혼선
어떤 AI 개발팀이 OCR 기반 문서 자동화 솔루션을 구축하고 있다. 고객사에서 "계약서의 주요 조항을 자동 추출해달라"고 요청했지만, 실무 개발자는 '날짜·금액'만 추출하는 것으로 이해했다. 팀장은 고객사와의 미팅에서 '리스크 조항'까지 포함해야 한다는 점을 파악했으나, 이를 개발팀 전체에 명확히 공유하지 않았다. 결국, 개발 결과물이 고객 요구와 어긋나 재작업이 발생했고, 일정이 지연됐다. 이 사례는 실무자와 팀장 모두가 요구사항을 정확히 해석하고, 서로의 이해 차이를 조율하며, 정보를 명확히 전달하는 커뮤니케이션이 필수적임을 보여준다.
예시 상황 2: 기술적 결정의 불투명성과 팀 내 갈등
딥러닝 모델의 선택을 두고 실무 개발자들은 최신 논문 기반의 모델을, 팀장은 검증된 안정적 모델을 선호했다. 하지만 각자의 의견을 명확히 설명하거나, 상대방의 우려를 충분히 듣지 않은 채 결정을 밀어붙였다. 이 과정에서 일부 팀원은 소외감을 느끼고, 프로젝트에 대한 동기부여가 떨어졌다. 이처럼 효과적인 커뮤니케이션이 없다면, 기술적 의사결정이 불투명해지고 팀워크에 금이 갈 수 있다. 실무자와 팀장 모두 자신의 의견을 논리적으로 전달하고, 상대방의 관점을 경청하는 역량이 필요하다.
예시 상황 3: 외부 협업과 정보 전달의 공백
프로젝트 후반, 외부 시스템(ERP) 연동이 결정됐다. 팀장은 고객사 담당 부서와의 협의를 통해 연동 방식과 일정 변경을 조율했으나, 일부 실무자에게 정보가 늦게 전달됐다. 결국 개발 일정에 차질이 생기고, 불필요한 야근과 혼란이 발생했다. 이 사례는 팀장뿐 아니라 실무자도 외부와의 소통 내용을 적극적으로 확인하고, 필요한 정보를 능동적으로 요청하는 커뮤니케이션 역량이 필요함을 보여준다.
AI 개발팀에서는 실무자와 팀장 모두가
•
정보를 명확히 전달하고
•
서로의 관점을 경청하며
•
외부와의 협업 내용까지 투명하게 공유하는
커뮤니케이션 역량을 갖출 때, 프로젝트의 속도와 품질을 모두 높일 수 있다.
기술력 못지않게 소통 능력이 프로젝트 성공의 핵심임을 잊지 말아야 한다.
명확한 규칙이 없다면, 혼란은 반복된다
보고, 연락, 상의에 대한 명확한 규칙이 없다면, 팀원들은 각자 다른 기준으로 행동하게 됩니다. 아래와 같은 상황 예시와 유사한 고민이 반복되면, 결국 정보 흐름이 단절되고, 중요한 결정이 늦어지며, 프로젝트의 생산성은 떨어질 수밖에 없습니다.
1. “이 정도 이슈는 말해야 하나, 말지 않아도 되나?”
C엔지니어는 최근 OCR 엔진의 한글 인식 정확도가 특정 서식에서 2~3% 정도 낮아진 것을 발견했습니다. 이 현상은 일부 문서 유형에서만 나타났고, 전체 서비스 품질에는 큰 영향을 주지 않을 수도 있다고 생각했습니다. 하지만, 팀 내에 ‘보고, 연락, 상의’에 대한 명확한 규칙이 없었기 때문에 C엔지니어는 고민에 빠졌습니다.
•
이 정도 인식률 저하는 꼭 보고해야 할까?
혹시 너무 사소한 문제를 보고한다고 생각하지 않을까 걱정되었습니다.
•
일단 혼자서 원인을 분석해보고, 나중에 정리해서 말하는 게 나을까?
하지만 나중에 더 큰 이슈로 번지면, ‘왜 미리 공유하지 않았냐’는 말을 들을 수도 있겠다는 생각이 들었습니다.
•
팀원들과 먼저 가볍게 상의해볼까?
하지만 모두 바쁜 상황에서 이런 작은 이슈까지 공유하는 것이 오히려 혼란을 줄 수도 있다고 망설였습니다.
결국 C엔지니어는 우선 혼자서 문제를 더 분석해보기로 했고, 팀에는 바로 공유하지 않았습니다. 며칠 뒤, 같은 문제가 다른 문서 유형에서도 발견되어 서비스 품질에 영향을 주기 시작했습니다. 그제서야 팀 전체에 이슈가 공유되었지만, 이미 고객사에서 불만이 접수된 뒤였습니다.
팀 리더는 “이런 문제는 초기에 바로 공유했어야 한다”고 지적했고, 다른 팀원들은 “이 정도 이슈까지 다 공유하면 일이 너무 많아진다”고 의견이 엇갈렸습니다.
이처럼
•
‘이 정도 이슈는 말해야 하나, 말지 않아도 되나?’라는 고민이 반복되면,
•
정보가 적시에 공유되지 않아
•
중요한 결정이 늦어지고
•
프로젝트의 생산성이 저하될 수밖에 없습니다.
따라서,
•
어떤 수준의 이슈까지 공유해야 하는지
•
보고와 상의의 기준을 명확히 세우는 것이
AI 개발팀의 효율적인 협업과 프로젝트 성공을 위해 꼭 필요합니다.
2. “누구에게 먼저 연락해야 할까?”
B엔지니어는 새로 도입한 이미지 전처리 라이브러리에서 예기치 않은 오류를 발견했습니다. 이 오류는 OCR 인식률에 직접적인 영향을 줄 수 있는 중요한 이슈였습니다. 그러나 팀 내에서 ‘보고, 연락, 상의’에 대한 명확한 규칙이 없었습니다. B엔지니어는 다음과 같은 고민에 빠졌습니다.
•
팀 리더에게 바로 연락해야 할까?
하지만 팀 리더는 회의 중이거나 바쁠 때가 많아, 작은 이슈로 판단되면 괜히 방해가 될까 걱정되었습니다.
•
담당 파트 동료에게 먼저 상의해야 할까?
하지만 이 문제가 전체 서비스 품질에 영향을 줄 수 있으니, 동료에게만 공유하는 게 맞는지 확신이 없었습니다.
•
테크니컬 기획자에게도 알려야 할까?
혹시 내가 직접 연락하면 혼선이 생기지 않을까, 혹은 내 선에서 해결할 수 있는 문제일까 망설였습니다.
이처럼 명확한 연락 및 보고 체계가 없다 보니, B엔지니어는 누구에게 먼저 연락해야 할지 결정을 내리지 못하고 시간을 허비했습니다. 그 결과, 오류 수정이 지연되었고, 테스트 일정에 차질을 빚었습니다. 이후 팀 리더는 “이런 중요한 이슈는 바로 공유했어야 한다”고 지적했지만, 동료들은 “작은 이슈는 먼저 내부에서 검토하는 게 맞지 않냐”고 의견이 엇갈렸습니다.
이처럼 AI OCR 개발팀에서 ‘누구에게 먼저 연락해야 할까?’라는 고민이 반복되면,
•
정보 전달이 지연되고
•
중요한 결정이 늦어지며
•
프로젝트의 생산성이 저하될 수밖에 없습니다.
따라서, 팀 내에서 ‘보고, 연락, 상의’의 명확한 기준과 절차를 정립하는 것이 필수적입니다.
3. “내가 먼저 상의해야 할까, 아니면 기다려야 할까?”
새로운 OCR 엔진 도입 여부를 두고 중요한 프로젝트 논의가 있었습니다. 회의가 끝난 뒤, 팀장은 각자의 의견을 정리해 오라고 했지만, 구체적인 다음 행동 지침은 없었습니다. 이때 한 실무 개발자는 다음과 같은 고민에 빠집니다.
•
“내가 먼저 팀장에게 내 생각을 정리해서 상의해야 할까?”
•
“아니면, 다른 팀원들의 의견을 기다렸다가, 그들의 생각을 참고해서 내 의견을 추가하는 것이 더 좋을까?”
실무자는 혹시 자신의 의견이 너무 앞서 나가면 팀 분위기를 주도하거나, 반대로 동료들의 생각을 충분히 듣지 못할까 걱정합니다. 반면, 기다리다 보면 논의가 지연될 수도 있고, 자신의 아이디어가 묻힐까 불안하기도 합니다.
결국, 명확한 상의 및 의견 제출 절차가 정해져 있지 않으니,
•
어떤 팀원은 바로 팀장에게 의견을 전달하고,
•
어떤 팀원은 동료들과 먼저 비공식적으로 이야기를 나눈 뒤 의견을 모아 제출하며,
•
또 다른 팀원은 아무런 액션 없이 기다리기만 합니다.
이렇게 각자 다른 방식으로 행동하다 보니, 팀 내 의견 수렴이 비효율적으로 이뤄지고, 중요한 결정이 늦어지거나 일부 의견이 누락되는 문제가 발생합니다.
이 사례는, 중요한 논의 후 ‘누가, 언제, 어떻게 의견을 제출하고 상의할지’에 대한 명확한 규칙이나 프로세스가 없을 때, 팀원들이 혼란에 빠질 수 있음을 보여줍니다.
이런 상황에서는 팀장이 구체적으로 “각자 언제까지, 어떤 방식으로 의견을 제출해 달라”는 가이드라인을 제시하거나, 팀원 간 사전 합의된 커뮤니케이션 규칙이 필요합니다.
우리가 시도하는 변화
이 문제를 해결하기 위해, 우리는 다음과 같은 실험을 시작했습니다. 이런 규칙을 통해, 우리는 팀 내 소통과 협업의 효율성을 크게 높일 수 있습니다.
1. 보고, 연락, 상의의 기준과 절차를 팀 내에서 명확히 정하고, 누구나 쉽게 접근할 수 있도록 시각화합니다.
•
팀 위키나 Notion, 사내 인트라넷에 ‘보고/연락/상의 플로우차트’를 게시합니다.
◦
예를 들어,
▪
“긴급한 장애 발생 시 → 팀장 및 관련 파트너에게 즉시 슬랙 DM 및 전화 보고”
▪
“일상적 이슈나 건의사항 → 주간 회의 전 팀 채널에 공유”
▪
“의사결정이 필요한 사안 → 관련자와 사전 상의 후, 팀장에게 공식 보고”
◦
새로 입사한 팀원도 쉽게 이해할 수 있도록 실제 사례와 함께 시각 자료(다이어그램, 체크리스트 등)로 안내합니다.
2. 실무자와 팀장이 서로의 메시지를 더 잘 주고받을 수 있도록, 커뮤니케이션 워크숍과 피드백 세션을 운영합니다.
•
분기별로 ‘커뮤니케이션 워크숍’을 열어,
◦
효과적인 보고 방법,
◦
질문하는 법,
◦
피드백을 주고받는 연습을 진행합니다.
◦
매주 1회 ‘피드백 데이’를 운영해,
▪
실무자와 팀장이 서로의 소통 방식에 대해 자유롭게 의견을 나눕니다.
◦
실무자가 팀장에게, 팀장이 실무자에게 ‘좋았던 점’과 ‘개선할 점’을 직접 이야기하는 시간을 마련합니다.
3. 정보 전달의 책임을 개인이 아닌 팀 전체가 함께 지는 구조로 바꿔, 누구나 자유롭게 의견을 공유할 수 있는 환경을 만듭니다.
•
모든 이슈와 논의 사항을 팀 전체 채널(예: 슬랙, 팀 노션)에 기본적으로 공유하도록 합니다.
◦
‘이슈 공유의 날’을 정해, 각자 발견한 문제나 아이디어를 자유롭게 발표하는 시간을 갖습니다.
◦
특정 이슈에 대해 한 명이 책임지고 공유하는 것이 아니라,
▪
“누구든 발견한 정보는 팀에 알리는 것이 원칙”이라는 문화를 강조합니다.
◦
팀 리더가 먼저 솔선수범해, 사소한 정보도 팀에 오픈하여 심리적 안전감을 높입니다.
여러분은 문제 분석 및 해결을 어떻게 진행하고 계신가요?
저희의 이야기가 여러분께도 도움이 되기를 바라며, 더 나은 개발 문화를 만들기 위한 저희의 여정에 함께하시겠어요?
“어떻게 일할 것인가?”에 대한 고민,
KDL에서 함께 나누고 싶습니다.
다음 글에서는 ‘쓸모없는 회의가 많은가?’에 대한
우리의 실험과 변화를 이야기합니다.
함께 고민하고, 함께 성장할 동료를 찾습니다
AI솔루션개발팀은 재작업을 ‘피할 수 없는 숙명’이 아니라 ‘함께 해결해야 할 과제’로 바라봅니다.
우리는 더 나은 개발 방식을 고민하고, 실험하고, 실패하고, 다시 도전합니다.
이 여정에 함께할 ‘일하는 방식에 진심인 개발자’를 기다립니다.
•
AI 엔지니어 3y+
•
데이터 엔지니어 3y+
•
프론트 엔지니어 3y+
•
백엔드 엔지니어 3y+