조직이 성숙할수록 팀 내부보다 팀 사이의 회색지대 문제(책임 불명확, 다중 조직이 얽혔으나 소유자 없음)가 병목이 된다. AI 시대에 그 복잡도는 더 커진다.

개발 진행을 보고할 때 "진행 중" 같은 모호한 상태 표현은 가시성을 떨어뜨린다. 어떤 작업이 끝났는지 외부에서 알기 어렵다.

PR 리뷰가 적체되면 개발 속도가 느려진다. 큰 조직일수록 리뷰어 병목 심함.

Android 화면마다 체감 완료 시점을 따로 측정하면 성능 개선 범위가 제한되고 일관된 latency 지표를 얻기 어려웠다.

AI 도구는 개인 학습만으로 회사 전체에 안 퍼진다. 조직 차원의 학습 구조가 필요하다.

데이터 드리븐 의사결정이 "지표를 본다" 수준에 머물면 실행으로 안 이어진다.

라포랩스는 인수 후 더 큰 시장으로 확장하면서도 빠른 의사결정과 조직 밀도를 함께 지켜야 했다.

소프트웨어 작성 패러다임이 1.0(직접 코드) → 2.0(신경망 학습) → 3.0(자연어 의도로 LLM 작동) 로 이동 중. 엔지니어 역할이 달라진다.

AI 도구는 개인 별 격차가 크다. 회사 전체 "저점" 을 어떻게 끌어올릴지가 조직의 과제.

AI 가 코드를 만들지만 인간이 일일이 다 읽지 않는 시대가 온다. 그러면 코드 리뷰 / 품질 보증은 어떻게 바뀌어야 하나.

요기요 R&D Center가 한 해 동안 같은 목표를 향해 일해온 팀원들이 따로 모일 자리가 부족했고, 연말을 함께 정리할 비공식 시간을 만들고 싶었다.

"코드를 직접 쓰는 1.0 → 신경망 학습 2.0 → 자연어 의도로 LLM 작동 3.0" 패러다임 변화 속에 엔지니어 역할이 어떻게 바뀌나.

개발 경험이 없는 디자이너·기획자가 자기 업무 문제를 직접 자동화하기 어렵고, AI 도구를 외부 API 문서만 보고 쓸 때 정확도와 속도가 모두 떨어졌다.

새 백엔드 엔지니어가 입사 후 팀 컨벤션·도메인을 빠르게 익히지 못하면 첫 프로젝트 합류까지 적응 비용이 크고, 외부에서 보이는 "조용하지만 깊이 있는" 팀 문화도 신입에게는 진입장벽이 된다.

새 백엔드 개발자가 와도 팀 환경과 업무 흐름에 익숙해지기까지 시간이 걸렸고, 적응 동안 어디에 물어봐야 할지 모호한 구간이 길었다.

빠르게 변화하는 커머스 환경에서 사업·제품·개발 조직 간 복잡한 프로그램을 한 팀이 휘저으려면 단순 PM 역할로는 부족하고, Business Agility를 안정적으로 굴리는 운영 체계가 필요했다.

팀 단위 기술 스터디는 참여와 지속성을 1년 이상 유지하기 어렵고, 책 한 권 훑는 수준으로 끝나면 실무에 흡수되지 않는다.

올리브영 IT 개발자들이 업무 외 시간을 어떻게 쓰는지, 취미가 직무 만족과 멘탈 헬스에 어떤 영향을 주는지 사내 시선에서 정리할 필요가 있었다.

사내 개발자들의 간식 취향이 흩어져 있어 공용 간식 구매 시 기준이 모호하다는 가벼운 사내 문제가 있었다.

비개발 직무에서 프론트엔드 개발자로 전환하려는 직원이 자율적으로 커리어를 바꿀 수 있는 사내 경로가 필요했고, 신규 합류자가 큰 코드베이스에 어떻게 적응할지가 관건이었다.