우리는 지금, 이상적인 모습보다 현실적인 문제를 먼저 이야기하려 합니다.
그리고 함께하면 배울 게 많은 팀으로 기억되길 바랍니다.
언젠가는 반드시 해낼 것 같은 팀,
이 팀은 진정성 있게 일하고,
완성형이 아니더라도,
조금씩, 그러나 분명히 앞으로 나아가고 있습니다.
"잘하고 있는 걸까?"라는 질문을 스스로에게 던지며,
지금 이 순간에도 우리는
하루하루 실험하고 정리하고 깨지고 다시 일어섭니다.
기술 선택에서 협업 방식까지, 더 나은 방향을 만들기 위해
실제로 바꾸기 위해 움직이는 팀입니다.
때로는 시행착오를 겪고, 때로는 답을 몰라 헤매지만,
우리는 문제를 외면하지 않습니다.
그 고군분투의 현장을 솔직하게 드러내고자 합니다.
개발팀 안에서 무슨 일이 벌어지고 있고, 어떤 문제와 마주하며 어떻게 버텨내고 있는지,
완벽하지 않습니다. 하지만 감추지 않습니다.
기획 취지
왜 우리는 열심히 일하는데도 개발 생산성은 낮을까?
•
우리는 개발팀의 생산성을 높이기 위해 끊임없이 고민하고 있습니다. 전략 수립, 보고 방식, 회의 문화, 그리고 업무 과정 속 재작업과 불필요한 절차들을 되짚으며, 진짜 필요한 것만 남기기 위한 여정을 시작했습니다.
•
이 여정은 단순한 내부 개선이 아니라, 잠재적인 동료가 될 여러분과 나누고 싶은 이야기입니다. 개발팀과 인사팀이 함께 문제를 정의하고, 각자 인터뷰와 실험을 통해 해답을 찾아가는 과정을 기록하고 공유하려 합니다.
•
우리는 복지나 외형적인 조건보다도, “어떻게 일하는가”, 즉 개발 방식, 기술 선택, 성장 환경 같은 본질적인 요소에 더 큰 가치를 둡니다. 이 글을 통해 우리가 일하는 방식과 그 안에서의 고민, 실험, 그리고 변화의 과정을 보여드리고자 합니다.
누구나 겪는 AI 개발자들의 문제 지도
개발 생산성이 낮은 이유는 단순한 “열정 부족”이 아닙니다.
문제는 훨씬 복잡하고, 눈에 보이지 않는 구조적인 병목에서 시작됩니다.
우리는 지금, “왜 개발 생산성이 오르지 않는가?”에 대한 근본적인 질문에서 출발해
AI 개발팀의 문제 지도를 하나하나 완성해 나가고 있습니다.
기획이 빈번히 바뀌거나, 개발된 기능이 폐기되는 일이 반복되고 있지 않습니까?
•
왜, 재작업이 발생할까?
•
재작업은 초기에 방지하자.
•
KDL 개발팀 다섯 가지 요소로 업무를 파악한다.
같은 목표를 향해 가고 있는 줄 알았지만, 실제로는 다른 언어로 일하고 있지는 않나요?
•
도대체 업무의 목적은 무엇인가
•
인풋은 무엇인가
•
성과물의 이미지는 일치하는가?
•
진짜 고객은 누구인가?
•
새로운 진행 방식을 제안한다!
정보가 제때 공유되지 않아 결정이 늦어지고, 일의 흐름이 끊기고 있지는 않나요?
•
실무자 스스로 메시지 전달 기술이 부족하다.
•
팀장 스스로 메시지를 받아들이는 기술이 부족하다.
•
보고, 연락, 상의에 대한 규칙이 없다.
회의는 많은데 남는 건 없고, 정작 필요한 논의는 놓치고 있지 않나요?
•
쓸모없는 회의를 구성하는 다섯 가지 요소
•
‘회의의 효용성을’을 높이는 네 가지 대책
•
마인드를 바꾸려면 프로세스를 바꿔라
•
회의 관리에도 ‘업무의 다섯 가지 요소’에 해당한다.
◦
거창하지 않지만 개발팀 내 만족도를 높이는 회의 아이디어
5. 업무 소요 시간을 예측할 수 없는가?
일을 언제 끝낼 수 있을지 아무도 모르는 상태에서, 마감만 정해져 있지는 않나요?
•
소요 시간을 즉답할 수 없는 두 가지 배경
•
비극의 3無 연쇄 현상
•
소요 시간을 예상할 수 없으면 어떨게 될까?
•
‘일회성 작업’과 ‘반복 작업’의 구분이 되어 있는가
•
‘갑’. ‘을’, ‘병’으로 나타낼 수 있을까?
6. 매뉴얼이 없다
기존의 반복 업무나 중요한 흐름에 대한 기준이 없어, 같은 질문이 반복되고 있지는 않나요?
•
속인화는 없앨 수 없다. 사람이니까
•
사람들은 왜 ‘탈속인화’ ‘매뉴얼화’를 싫어할까
•
눈에는 눈, 이에는 이, 인정 욕구에는 인정 욕구를!
•
‘좋은 속인화’와 ‘나쁜 속인화’를 구분한다.
•
‘나쁜 속인화’에서 탈출하자
•
매뉴얼은 인수인계 시에 만들어 두자!
•
‘전임자의 취향이나 고집으로 계속된 쓸데없는 작업’을 잘라내자
◦
하기 싫은 업무일수록 매뉴얼화하자
7. 과잉 서비스가 발생하는가?
애초에 요구되지 않았던 기능이나, 필요 이상으로 복잡한 구현이 진행되고 있지는 않나요?
•
전임자는 해줬는데, 왜 안된다는 거죠?
•
과잉 서비스는 왜 발생하는가?
•
처음부터 커뮤니케이션이 이루어졌다면
•
어설픈 선의와 정의감이 뒤통수를 친다
8. ‘무엇을’, ‘어디까지’가 모호하다
업무의 범위와 기준이 명확하지 않아, 팀원들이 각자 다르게 이해하고 있지는 않나요?
•
그 업무는 그쪽에서 해주면 안 될까?를 거절할 수 없는 비극
•
‘모호함’을 만들어내는 세 가지 문제
•
업무를 제대로 설계하고 관리하기 위한 네 가지 단계
•
서비스 수준을 설정하자
•
서비스 수준을 알리고 주지시키자
•
서비스 수준을 측정하자
9. 일을 하지 않는 사람이 있는가?
기여가 눈에 보이지 않거나, 책임과 역할이 모호해 일의 균형이 무너지고 있지는 않나요?
•
‘일을 하지 않는 사람’은 이렇게 해서 생겨난다
•
일을 하지 안는 사람을 만들어 내는 다섯 가지 원인
•
일하지 않는 사람이 또다시 일하지 않는 사람을 만들어낸다
10. 누가 무엇을 하고 있는지 모른다
업무의 흐름과 소유권이 불분명해, 커뮤니케이션 비용이 계속 늘어나고 있지는 않나요?
•
왜 ‘누가 무엇을 하고 있는지 모르는 상태’가 발생하는가
•
‘누가 무엇을 하고 있는지 모르는 상태’가 만들어내는 질병
•
돈을 들이지 않더라도 커뮤니케이션의 ‘기회’를 만들 수 있다
•
‘안타깝고 답답하다’는 태도로 문제를 대면하자
11. 경영진에게 실태가 전달되지 않는가?
문제는 분명 존재하는데, 위에서는 "문제가 없다"고 인식하고 있지는 않나요?
•
현장의 수준에서는 개선에 한계가 있다
•
결과’만’ 보고하기 때문에…
•
보고해야 하는 것은 ‘프로세스’다!
•
무엇을 측정해서 보고해야만 하는가?
•
‘정의→ 측정 → 보고→ 개선’의 사이클을 유지한다!
우리는 더 나은 복지보다, 더 나은 방식을 만들어가고 있습니다.
성과는 자연스럽게 따라옵니다.
진짜 문제를 마주하고, 해결하는 순간 —
AI 개발팀은 한 단계 성장합니다.
함께 고민하고, 함께 성장할 동료를 찾습니다
AI솔루션개발팀은 재작업을 ‘피할 수 없는 숙명’이 아니라 ‘함께 해결해야 할 과제’로 바라봅니다.
우리는 더 나은 개발 방식을 고민하고, 실험하고, 실패하고, 다시 도전합니다.
이 여정에 함께할 ‘일하는 방식에 진심인 개발자’를 기다립니다.
•
AI 엔지니어 3y+
•
데이터 센트릭 AI엔지니어 1y+
•
프론트 엔지니어 3y+
•
백엔드 엔지니어 3y+