‘좋은 팀’에 대한 고민 _ 자바 프로젝트 회고(1)

Keep(1): 소통은 편안함에서 나온다

​ 대망의 첫 프로젝트. 개발공부를 시작한 후 처음으로 무언가를 만드는 것이다. 자바공부가 재미있어 꼼꼼히 복습한만큼 자신도 있었고 그동안 많은 대외활동을 해오며 그룹 활동에 익숙했고, 또 잘해왔다고 생각해 협업 활동은 부담되지 않았다.

​ 팀 활동은 분위기와 그 결과물이 비례하기에 팀이 구성된 날부터 편한 분위기를 만들려고 노력했다. 수업을 온라인으로 들을 수 있던 4월 초라 얼굴을 많이 못볼 수 있었지만 자발적으로 오프라인 수업을 나오게끔 설득하고, 새벽까지 스터디도 매일하면서 함께 의욕을 얻었다. 이렇게 친해진 사람들은 학원수료를 앞둔 지금까지 가장 친한 사람들로 남았다. 프로젝트 당시, 다른 팀들은 줌이나 디코에서 한마디도 안해 결국 오프라인으로 모일 수 밖에 없었지만 우린 매일 디스코드로 스터디를 했기 때문에 온라인 회의를 하는게 전혀 어색하지 않아 매일 오프라인으로 회의할 필요가 없어 시간이 많이 절약되었다. 이걸로 팀원들간 좋은 관계를 유지하는게 일적으로도 큰 도움이 된다는 걸 다시 한번 느꼈다. 결국 팀 프로젝트는 한사람이 다하는게 아닌 소통을 통해 해야하는것이고, 소통은 상대방이 나의 말에 집중해줄 거라는 전제에서 나오는거니까.

Keep(2):기획과 설계는 자신있지!

​ 프로젝트 주제는 자바의 ‘인터페이스’ 개념을 활용한 테니스 구현이다. 사실 객체지향쪽은 코딩에 활발하게 사용했다기보단 이론수업 위주로 수업이 진행되어 막상 코드로 구현하자니 다들 막막해 하는 것 같았다. 하지만 내부적인 원리와 과정, 추상적인 개념에 대해 탐구하고 이해하는걸 좋아하는 나는 다른 사람들은 지루하게만 느꼈던 개념수업을 오히려 재밌게 들었고 내가 이해한 걸 직접 손으로 그려보는걸 좋아해 정리또한 꼼꼼하게 해두었다.

​ 나는 우선 내가 알고있는 개념을 한번 더 점검하고 화면공유 기능을 통해 정리해둔 자료를 공유하며 객체지향 개념과 인터페이스의 사용법을 차근히 설명했다. 서비스 기획자를 준비하며 관련 활동을 많이 했던 만큼 기획과 설계, 구조 파악엔 자신이 있었고 자연스래 내 주도로 클래스 구조와 그 코딩 방향을 설계했다.

​ 아직 많은 수정이 필요한 설계단계지만 내가 공부한 개념으로 무언가 만들어지고 있다는 느낌이 들어 굉장히 벅찼다. 또, 학원이 시작된 후 전공자의 비율이 생각보다 높아 비전공자로서 많이 불안하고 위축되었는데 열심히 공부한게 빛을 발했던 것 같아 뭉클했다. 동시에, 가장 어림에도 불구하고 경청해주고 내 의견을 존중해주고 인정해주는 팀원들한테 굉장히 고마웠다. 만약 좋은 팀원들이 아니었다면 전공과 관련없는 분야에서 내 주도로 무언가가 진행되는게 불편하고 부담스러웠을 것 같다.

Problem:Plan A vs Plan B,C,D

​ 협업과정에서 가장 어려움을 느꼈던 부분은 안풀리는 문제를 다같이 할것인가, 각자 해볼 것인가에 대한 고민이었다.

1)

​ 시간이 한정적이니 완성되어있는 다른 코드를 활용하자는 조장오빠의 의견과, 다른 코드는 객체지향개념을 활용하지 않아 오히려 변형하는게 더 어려울 것 같다는 의견 차이가 있었다. 고민끝에 나머지 인원들은 회의때 설계한 내용을 바탕으로 개발을 진행하고 조장오빠는 그 코딩을 따로 변형하는 방향을 제안했다. 그 이유는 첫째로 시간이 한정되어있기에 언제까지 기획만 할 순 없었고, 두번째는 한 개발방향이 실패했을 때를 대비할 플랜 b를 마련하기 위함이었다. 한 마디로 “둘중 하나라도 성공하면 그걸로 하자” 방식이었다.

​ 하지만 돌이켜보면 조장은 팀원들의 기술적인 부분을 계속 봐줘야하는 역할이기에 단독행동을 하는건 좋은 해결방안은 아니었던 것 같다. 그렇다고 한쪽 의견을 완전히 배제할 수는 없었기에 단독행동을 하되 오전까지라던지 시간제한을 걸어두고 더 진척이 보이는 쪽에 모두가 집중하였다면 조금 더 여유있게 개발이 진행되었을 것같다는 생각이 든다.

​ 마감일 전날, 다른 부분 개발을 마무리하고 main 구현만 남았던 상황이었고, 그 방법에 의견차이가 있었다. 어느쪽이 옳은 방향인지는 아직도 잘 모르겠다. 나눠서하면 막힐때 그 해결책이 단체로 하는것보다 훨씬 더디게 나오고 서로의 진행상황을 알지 못해 각 팀마다 단독적으로 진행하게 된다는 단점이 있었다. “되는쪽을 밀자” 해결방식이지만 한정된 인원의 분담은 오히려 그 어떤방향도 안될 수 있다는 위험도 분명히 존재했다. 반면 한 사람이 화면공유를 통해 진행하고 그 코딩을 보며 다같이 의견을 내는 방식이었다면 각자 하는것보다 속도가 나고 좋은 해결책을 찾을 수 있겠지만 동시에 해당 방향이 잘못된 거였다면 플랜 b 없이 단체로 시간을 날린셈이 된다.

​ 이에 대해 세팀으로 나누어 각자 구현하되, 조장이 각 팀의 상황을 계속 점검하고 기술적으로 도움을 주며 각 팀의 구현부분을 합치는 역할을 하고, 일정 시간이 되면 가장 가능성이 있는 방향에 전원이 집중하는 두가지 해결방안을 제안했다. 결과적으로 각자의 코딩의 장점을 가져다 쓴 조장오빠가 깔끔하고 좋은 코딩은 아닐지라도 프로그램 구현에 성공했고 우리는 아슬아슬하게 시간내에 개발을 완료할 수 있었다. 아쉬웠던건 다들 욕심이 있던 만큼 시간이 지나도 자신이 하던 코딩을 포기하지 못했고 결국 한쪽에 집중하자는 두번째 방안은 잘 실현되지 못했다. 다들 첫프로젝트인만큼 욕심도, 의욕도 많았기에 당연했지만 나를 포함해 안되는건 과감하게 끊고 다른 단계에 집중하는 자세가 필요했을 것 같다.

Try : ‘적당한 관계’에 대한 고민

​ 첫 프로젝트였던만큼, 또 팀원들이 끈끈했던 만큼 기억에 정말 많이 남는 프로젝트이지만 동시에 협업에 있어 ‘관계’에 대해 많은 생각이 들었다. 분명 서로 친했던만큼 의견을 말하거나, 상황을 공유하는건 굉장히 수월했지만 동시에 공적으로 일을 한다는건 의견이 대립하고 서로의 의견에 대한 비판과 피드백이 오갈수 밖에 없는데, 사적으로 너무 친하다보니 피드백을 주는쪽도, 받는쪽도 괜스리 더 서운했고 공적인 분위기가 형성되기 어려웠다. 이전까지는 무조건 친할수록 소통이 잘되니 좋은거지! 라고 생각했는데 오히려 적당히 거리가 있는 공적인 관계가 주는 장점이 분명히 있다는걸 인지했다. 소통이 원활하게 될정도의 편한함과 일 자체에 집중할 수 있는 어느정도의 격식, 그 균형과 조율점을 잘 찾는게 중요할 것 같고 여기에 있어 리더가 어떤 역할을 수행해줘야할지 고민해보는 계기가 되었다.