1. 안녕하세요! 2023-05-22 회고특강에서 분업에 대한 내용을 이해하던 중 의문점이 드는 게 있어서 질문 올립니다. 책 "클린 아키텍처"에서는 컴포넌트 간의 분리를 매우 중요시하고 팀 사이에 간섭을 최소화 하는 것을 목표로 삼는다고 합니다. 저는 이것을 '분업의 효율화'라고 이해했는데, 수업시간과 배운 내용과 충돌이 있는 것 같습니다. 예를 들어 UI팀과 DB팀이 한 자리에 모이는 것보다 경계를 사이에 두어 각자 맡은 몫에 최선을 다하는 방식이 바람직할 거라고 생각이 듭니다. 선생님의 의견이 궁금합니다! 물론 어느 방법론이 최고인지를 따지는 광신도적 질문이 아님을 알립니다. 메시지를 작성하다보니 문득 프로젝트가 설계 전 후로 나뉘어 양상이 바뀐다는 것을 알게 된 것 같습니다. 현재까지 제가 이해한 바로는

   1. 프로젝트 초반부, 사람들이 부서 구분없이 한데모여 문제해결을 위한 설계도를 작성한다. 이때 요구사항을 컴포넌트, 유스케이스 단위로 적절하게 분할한다. ==> 협업
      1. 프로젝트의 케바케, 스타트업에서 애자일을 많이 쓸 수밖에 없음. 성공확률 < 실패확률
      2. 어떤 프로젝트이느냐에 따라 다름. 협업, 분업, 독립적인 작업이 수시로 발생하는 데에 애자일이 적합.
      3. SI와 같이 확실성이 높고 납기일이 정확한 팀의 경우 애자일 보다는 분업이 효율
   2. 설계초안이 완성되면, 그에 따라 구성원들이 팀을 꾸리게 되어 흩어진다. 팀 간에 의사소통은 이제부터 문서로 진행되며, 중대한 변경사항이 아닌 이상 서로 독립적인 속도로 발전한다. ==> 분업
   3. 요구사항이 변경되어 핵심 비즈니스 로직에 수정이 가해질 경우, 밀접한 관련이 있는 컴포넌트(eg, DB스키마)에는 영향이 가겠지만, 구체적인 세부사항(eg, UI/UX, REST api)은 영향을 아예 받지 않거나 느리게 전파된다. ==> 독립

   두서없이 작성한 것 같은데 잘 전달이 되었기를 바랍니다... 선생님의 현업 경험에 기반한 현실적인 조언과 피드백 부탁드립니다.

답변

양 옆 자리, 대각선 자리도 되게 중요함. 내가 코칭해야 할 사람은 좌우에, 내가 얻어가야 할 사람은 대각선에 앉히는 경향.

-> 애자일 스크럼에서는 직군별 팀보다는 프로젝트 구성원(고객참여를 적극 권장)으로 구성. - BTB의 경우엔 고객사, BTC에는 소비자. => 고객을 프로젝트에 참여하는 걸 의미함.

개발 아키텍처는 독립과 경계와의 상호작용인데. 신규 컴포넌트(아주 복잡한)를 여러개 만들어야 할 때, 구성원이 수시로 요구사항과 중간 설계 상황을 상호동작여부를 점검하는 것이 좋겠죠? → noti로 자주, 브로드캐스팅 하고, 다양한 관점의 피드백을 동시에 받으면 낭비를 줄일 수 있다

암묵지가 많거나 요구사항이 변할 가능성이 있다면 상호 피드백잉 중요한 환경일 것으로 판단. 대화가 많으면 몰입이 떨어질 수 있을 수도 있다. 하지만 뭐가 더 좋은지는 결국 환경에 따라 다르다. 회사에서 그런 몰입공간을 제공하는 것이 중요. 무조건적으로 한 공간에서만 협업에 유리하게 만드는 것이 아니라 공간의 다양성을 만들어주면 좋다.

온전히 집중할 수 있는 시간을 규칙으로 정해볼까? 단, 구성원의 자발적인 공감에 의한 참여를 필요로 한다. 메신저가 꺼져있다는 것에 대한 상호존중.

추가 답변

• 건설현장 = 정해진 목표, 정해진 아키텍처(워터폴)
• 토스, 당근마켓 = 망한 서비스 엄청많음. 정해지지 않은 목표(실험), 중간중간 정해야 하는 아키텍처(애자일)
• SW공학은 "복잡한 문제를 풀기 위한 시각적 추상화"의 역사 -> 다양한 독립성이 혼재해 있는데, 얼마나 유기적인지, 얼마나 최적한지에 협업능력이 매우 중요한 역할을 가지고 있다.
  • 개별 코딩/테스팅 능력이 자리를 바꿔앉는다고 유의미하게 달라지지 않는다.