한화시스템 BEYOND 캠프 3기 2월 회고

GyeongNam·2024년 3월 3일

한화시스템 BEYOND SW CAMP 3기 회고록

목록 보기

14/14

프로젝트

실제 본 프로젝트 기간은 2월 19일 ~ 2월 23일이다.

팀원은 개발 경험이 있는 사람을 a와 b라고 하고 없는 인원은 c와 d라고 하겠다.

아무래도 초심자가 두명이나 존재하는 상황속에 앞에 먼저 조금씩 공부하는 과정이 필요하다고 생각했고 다른 팀들에 비해 조금 이른 시간 속에 프로젝트를 진행하게 되었다.

팀장은 평소에 PM 경험이나 대학 입시생들 컨설턴팅을 주로 해오셨던걸 자랑스럽게 말씀하셨던 d가 맡게 되었고
프로젝트에 어느정도 경험이 있는 a는 전체적인 백업
spring에 기본적인 부분은 아는 b는 새로운 서비스 개발
c와 d는 초심자이기 때문에 페어 프로그래밍을 진행하는 방향으로 정해졌다.

1월 22일

주로 어떤 서비스를 만들 것인지. 하나씩 의견을 제출했다.
a는 주제보단 구현할 기능을 위주로
  1. 회원가입 (이메일, 구글, github)
  2. 일반 로그인(이메일),
  3. 소셜 로그인 (구글, github)
  4. 알림 서비스 FCM
  5. SMTP 이메일 전송 시스템 (일반)
  6. 에디터를 이용한 글작성
  7. 파일 업로드
  8. 파일 다운로드
  9. 캘린더 기능
  10. 실시간 채팅 기능 (n:m)
  11. 공유 페이지 기능 (위키디피아, 동시성 문제 해결)
  12. 댓글, 대댓글 기능
  13. 트래픽 관리
등을 제안하였고,
b,c,d의 의견은 커뮤니티을 말하고 있었기에 이번회의에서 커뮤니티 개발하는걸로 방향을 정하게 되었다.

다만 그 과정이 무려 3시간이나 걸렸다. 개발자가 서비스에 대해 심도 있게 생각하는 것은 좋은데 개인적으로 d가 원하는 것은 business model 이다는 생각이들었다. 회의 진행에 올바르지 못하다는 생각이 들었다. 분명 회의방향을 돌려도 돌아오는 마법에 걸렸다.

또한 a와 b가 spring에 대해 경험이 있다는 점을 이유로 d팀장님은 a와 b가 먼저 프로젝트를 개발해 나가고 c와 d는 그걸 공부하는 방향을 제안했었다.
물론 a와 b는 거절했고 모두 개발에 참여하는 방향으로 되었다.

1월 26일

저번 회의 마지막에 다음 회의까지 본인이 생각하는 요구사항 정의서를 간단하게 적어오기로 했다.
a는 전체적인 내용, b는 a가 작성한 내용을 알고있었기에 누락되었던 관리자 부분에 대해서 작성해왔으며
c와 d팀장님은 뭘했는지 모르겠고 일단 그 상황에서 진행되었다.
모두 만들면 좋겠지만 능력이 따라줄지 알지 못했기에 일단 기본적인 것만 하나씩 만들어가는 것으로 방향을 잡았다.
당시 요구사항 정의서의 수정할 사항이 없다고 느꼈을순 있지만 초안이기때문에 엄청 많은 수정이 필요했다. 하지만 아직 모두 인지하지 못하고 있었다.
그 다음으로 a가 결과물로 필요한 것을 설명하는 시간이 있었다.
0. 표지
1. 목차
2. 개요
3. 요구사항정의서
4. 스토리보드
5. 인포메이션 아키텍처
6. 화면 플로우 차트
7. api 명세서
8. 테스트 명세서-> (아직 모르겠다. 시연? 테스트 코드?)
또한 협업툴을 쓰는거에 대해 어떤지 의논을 해보고 교육시간에 배웠던 적 있던 Jira를 사용하기로로 하고, 디자인 툴은 Figma 를 생각해 보는 것으로 결정됐다.

이때부터 a는 평일에는 교육 끝나고 밤 12시까지 팀원들의 질문을 받기 위해 팀 디스코드에 상주해 있었으며, 주로 어떤걸 프로젝트에 사용할지 기술을 알아보는 시간을 가졌다.

1월 30일

매번 a가 준비해오던 회의를 이번에는 누구도 준비를 해오지 않았다. 아직도 서비스에 대해 구체적이지 않아 혼동하는 팀원들이었고. a는 이럴거면 요구사항정의서를 왜 작성했는지 의문이었다.
서비스에 대해 구체적이지 않아 힘들어했다면 요구사항정의서를 명확히 작성하지 않았다는 뜻 아닌가. 애초에 읽어보긴 했는지 의문이었다.

business model을 생각하는 건 좋은데 지금 우리는 수익구조나 수익창출에 대해 고민할 상황이 아니라 개발을 어떻게 진행해야할지 생각했어야 했다. 따라서 d팀장님의 의견을 잠시 밀어두고 DB 테이블을 다 같이 작성하기로 했다.
DB 테이블을 함께 작성하면 서비스에 윤각이 어느정도 잡힐거라 생각했다.

그렇게 기본적인 테이블 구조를 같이 만들고 결과로 나온 DB테이블은 실제로 큰틀은 프로젝트 진행하면서 달라진 것이 없다.

a는 이제 DB 테이블이 어느정도 짜였고, 요구사항에서도 어느정도 알았으니 개발을 조금씩 진행할 것을 제안했다. 특히 프로젝트를 처음 진행하는 c와 d팀장님에게 선택은 자유지만 가능한 조금 일찍 시작할 것은 권유했고, b또한 개발을 시작할 것이라고 말했다.

따라서 a는 회원가입, b는 웹소켓을 이용한 채팅, c와 d팀장님은 페어 프로그래밍으로 게시판기능을 개발하는 걸로 결정되었다.

2월 05일

2월이 되었다.
a는 주중에 c에게 질문을 받았다 내용은 브랜치에 관한 것이다.
개발을 진행할 것인데 브랜치를 어떻게 써야할지 모르겠다는 거다. 초심자가 괜히 남의 코드를 건들까봐 불안한 것이다. 따라서 이번회의 때 a는 브랜치전략에 대해 준비해왔다.
a는 일반 웹 개발이니깐 git flow 전략보단 github flow전략을 선택하고 혹시 모를 상황을 대비해서 바로 메인에 Merge하는게 아니라 develop 브랜치를 만들어서 거기다 Squash Merge를 하고 나중에 어느정도 만들어졌으면 메인브랜치에 Rebase Merge 할 것을 제안했다.

a는 spring의 디렉토리 구조를 짜왔으며 도메인 중심 구조를 제안했다.
그리고 이메일 발송과 redis등을 가지고 일반이메일 회원가입 서비스를 만들어왔다.

b는 웹소켓 채팅에 대한 참고자료가 많기 때문에 한가지 강의를 듣고 그대로 따라해서 다른 spring 프로젝트에 기능을 만들어왔다. 다만 만들어온 것이 1대 1 채팅이기 때문에 우리가 만들어야하는 n : m 채팅은 조금 더 걸릴 거라고 했다.

c는 강사님과 함께 교육한 board 프로젝트를 기반으로 완성되지 않았으지만, 그래도 어느정도 CRUD를 구현한 것을 b와 마찬가지로 다른 spring 프로젝트에 만들어왔다.

d팀장님은 jira에 대해 공부해왔다(?) 무엇보다 Figma로 화면 디자인을 해왔는데 깔끔해서 보기 좋았다 나름 센스가 있는 것 같아서 vue 작업할 때 잘하실 것 같았다.

a는 b에게 본인이 다른프레임워크이긴 하지만 웹소켓을 이용한 채팅을 만든 경험이 있기도 하고 이미 spring에서도 어느정도 찾아봤으니깐 막히는 부분이 있으면 본인에게 질문할 것을 조언했고
b도 알았다고 했다.

a는 c에게 이제 브랜치에 대해 알았으니깐 본 프로젝트에서 브랜치를 하나 만들어서 진행하면 된다고 했다. 그리고 가능한 교육시간에 들었던 textarea보단 editor를 사용해보는 것이 어떤지 권유했다.

a는 d팀장님에게 c도 개발을 시작했으니깐 둘은 페어 프로그래밍이니깐 슬슬 개발에 참여하는 것이 어떻겠냐고 권유했다. 하지만 d팀장님은 지금 강사님께 듣는 강의에 좀더 집중을 하고 공부할 것을 원한다고 했다.

a는 팀원 모두에게 저번 회의때부터 가장 이상적인 개발속도는 우리가 vue를 배우기 전에 기본적인 벡엔드 부분을 어느정도 개발해두고 vue는 모두 처음이기도 하고 평균적으로 프론트에서 많은 시간이 소비될 것이라고 vue를 배우는 동시에 프론트 개발을 진행하는게 가장 이상적이라고 말했다.

다음 회의는 언제가 좋을지 의논하는 과정에서 a는 월요일까지 설연휴였기 때문에 화요일을 제안하였고 d팀장님은 설연휴때 한번 모이는 것을 제안했다. b와 c는 12일에 모이는 것에 대해 큰 문제 없다고 하였고 a는 굳이? 라는 생각이 있었지만 팀원 모두 모이기에 12일에 참여하는 걸로 했다.

2월 12일

거리를 생각해서 중간부분인 홍대입구에서 만났다.
a는 oauth2를 이용해 github, google회원가입 부분을 마무리했고 jwt도 어느정도 적용해두었다.

b는 아직 웹소켓에 대해 공부중이었다. 팀원들에게 본인이 강의를 보고 공부한 내용을 간단하게 설명해주었다. 다만 만들어온 것이 제대로 작동하지 않아 안타까웠다.

c는 아직 게시판기능을 개발중이다.

d팀장님은 주중에 강사님께 배운 vue와 본인이 결제한 강의를 기반으로 디자인을 해왔다. 다만 저번 회의에서 보여줬던 Figma 디자인과 많이 달랐고 우리가 Tailwind CSS 를 사용하는 방향으로 말했었는데 그저 순수 CSS로만 만들어 오셨다.

a는 d팀장님에게 방향이 이러면 안될 것 같다 우리가 말했던 것과 많이 다르다고 말하고 a 본인도 이제 슬슬 vue개발에 참여할 거라고 말했는데 d팀장님은 갑자기 더이상 프론트는 못하겠다고 벡엔드를 하겠다고 한다.

그리고 a씨가 프론트를 주도해서 진행해달라고 말했다. 그리고 캘린더와 칸반도 말이다.
a는 평소에 벡엔드 부터 만드는 것을 제안했지만 갑자기 vue를 만들어 오셨고 일단 씁쓸했지만, 알겠다고 했다.

이후에 가벼운 술과 간단한 저녁회식을 같이하고 헤어졌다.

2월 13일

a는 아침 출근시간에 만난 d팀장님께 본인 블로그에 허락없이 올라간 a의 사진을 내려달라고 부탁했다.

13일 저녁 a가 c에게서 연락을 받았다. c가 d팀장님께서 본인이 만들어둔 게시판기능을 인수인계하라는 내용이었다.

c가 b에게도 말했는데 b는 페어프로그래밍이니깐 원래 그럴려고 했던거 아니었냐고 들었다고 했다.

a는 일단 c에게 왜 본 프로젝트에서 브랜치를 따로 만들어서 작업하지 않았냐, 본인이 못하겠으면 나한테라도 미리 말해야하지 않았냐, a는 본인이 매일매일 2주도 넘게 디스코드에 상주해 있는데 오는 사람을 단 한명도 못봤다면서 혼냈다(?)

a는 c에게 d팀장님께 줄거면 주라고 했다. 다만, c가 한것이 d팀장님께서 한 걸로 남들이 오인할수 있는데 괜찮겠냐고 물었다.

c는 d팀장님께서 페어프로그래밍임에도 불구하고 c에게 모두 맡겼다는 것이다. c는 5일 회의에서부터 d팀장님을 기다렸고 끝내는 진행되지 않아 먼저 개발에 시작했고 어제 d팀장님께서 c에게 게시판기능을 모두 넘겼다는 것이다.

a는 어제 회의(12일)에서 게시판 자체를 c에게 맡겼다면 오늘(13일) 인수인계를 해달라는 것이 말이 안맞는거 아니냐고 의문을 가졌고

c는 12일에 본인에게 게시판을 넘기고 13일 오전에 금요일부터 페이프로그래밍을 하겠다고 했다가
13일 저녁에 인수인계 해달라고 해서 a에게 이런상황 자체가 맞는 것인지 물어보러 온 것이라고 했다.

a는 c에게 거의 게시판기능을 다 마무리지어가는거 아니냐고 물었다.
c는 거의 마무리 지어가는데 a가 숙제로 준 에디터와 좋아요 동시성 문제, 이미지 캐싱문제에 대해서는 아직 부족하다고 말했다.

a는 c에게 그런상황에 만약 나라면 못해도 좋으니깐 끝까지 진행해 볼것이라고 했다. 선택은 본인의 몫이고 잘 생각해서 d팀장님과 둘이 합의점을 찾을 것을 제안했다.
솔직히 a는 c가 프로젝트 바로 전날까지 못하면 본인이 처리해버릴 생각이었다.

2월 14일

a는 b에게 슬슬 채팅을 16일까지 마무리 할 것을 제안했다. 그때까지 최대한 본 프로젝트에 붙일 것을 제안했다. a도 더이상 물어보지 않는 b를 기다릴 필요성을 못 느꼈다. 16일까지 진전이 없으면 채팅기능을 제외하는 방향으로 생각하고 있었다.

c는 게시판기능에 대해 d팀장님과 합의를 보려고 했다. c는 게시판 기능을 마무리하는 방향으로, c는 d팀장님께 캘린더, 칸반을 하시는게 어떤지 물어봤는데 d팀장님께서는 그건 a가 할일이니 신경쓰지 말라고 했다.
그래서 해당 내용을 들은 a는 d팀장님께 본인의 업무 과다로 d팀장님께서는 그룹관련된 기능과 캘린더, 칸반 관련된 벡엔드 기능을 만드는 것을 제안했다.
a는 의문이었다. 이걸 왜? 내가 합의를 보는것인지 d팀장님께서는 c가 말하는 것은 듣지 않고 a의 말은 듣는 그러한 상황이 되었다.

a는 d팀장님에게 언제 진행하실건지 물어보았고 토요일부터 진행할 것이라고 답변을 들었다.
a는 계획한 것보다 진행사항이 느리다 진행하셔야 한다. 그리고 서비스를 축소할 것을 제안했고 d팀장님은 알았다고 했다.

14일까지 일 자체가 모두 틀어짐을 느낀 a는 16일 회의 자체가 유의미한 의미가 없다고 느꼈고 마침 c와 b역시 16일 회의가 필요없음을 느꼈다.
c가 마침 회의하지 말자고 말했고, a와 b가 동의했다.
하지만 d팀장님은 회의가 필요하다 말하였다. 사유는 각자 맡은 일을 명확히 하자는 이유였다.
하지만 c의 완고한 태도로 16일 회의는 넘어갔고 프로젝트 시작날인 19일에 진행하는 걸로 결정됐다.

2월 16일

d팀장님은 a에게 본인 브랜치 만드는 법(?)을 배워갔으며 저녁에 드디어 벡엔드 개발을 시작하셨다. 커밋기록을 확인한 a는 안도감을 잠깐 가질 수 있었다.

a는 b에게 웹소켓 채팅 개발 상황을 물어보았고 b는 기간을 지키지 못했지만 거의 다 알것 같다고 말했다.
b는 계속 하기를 원했다. a는 개발하다보면 구조를 늦게 깨닫는 경우도 있고 지금까지 b가 저 기능하나에 쏟은 시간을 알기에 b를 한번 더 믿어보고 19일까지 붙여올 것을 부탁했다. 그리고 잘 이해가 안되는 부분이 있으면 반드시 a 자신에게 물어보라고 했다.

c는 한 14일부터 a와 디스코드에 상주해있다. c는 평균 새벽 4시 길게는 새벽 5시까지 남아있었고
12시에서 새벽1시까지 있는 a에게 꾸준히 질문하기 시작했다.

2월 17~18일(주말)

a는 본인이 벡엔드에서 빠지면 서비스의 규모가 많이 축소될 것을 알고있지만 프론트를 책임질 팀원이 없기도 하고 d팀장님께서 a에게 믿고 맡겼기에
2월 13 ~ 16일동안 vue에 이런저런 ui 프레임워크를 적용시켜보며 판단했을 경우 가장 쉽고 vue3에 적합한 ui 프레임워크인 Quasar Framework을 적용시키는 방향을 결정했다.
물론 팀원들과 합의가 있어야 했기에 바로 본 프로젝트에 합치지 않았으며 월요일까지 어느정도 브랜치를 따로 빼서 개발해가고 회의를 통해 합칠지 결정하고자 했다.

a는 개인적으로 디자인센스가 부족하다고 생각하기에 예전에 d팀장님이 만들어둔 Figma를 베이스로 같이 디스코드 지박령이된 c에게 색상같은 사소한 부분에 대해 조언을 얻었다.

2월 19일 (프로젝트 1일차)

a는 본 벡엔드 프로젝트에 지금까지 개발했던 것을 모두 합치는 작업을 제안했다.
그리고 프론트부분에서 본인이 준비해온 Quasar Framework을 발표하고 제안했다.
전체적인 디자인, 레이아웃, 그리고 각 페이지 라우팅까지 해왔기에 만장일치로 그대로 진행하는 것으로 했다.

a는 팀원들에게 Quasar를 접해본적이 없기에 당연히 어려울테니 docs나 본인에게 물어보라고 했다(다른 ui 프레임워크에 비해 접근장벽이 낮은편이라고 생각한다). 그리고 a는 회원가입과 로그인 부분을 벡엔드와 연결하기 시작했다.

오전 중으로 d팀장님이 만든 그룹기능과 그 그룹마다 글을 작성할수 있는 c가 만든 게시판 기능을 합칠수 있었으며, b도 합쳐서 드디어 채팅기능이 어디까지 진행됐는지 확인할 수 있었다.

a는 그때 다시 강사님께서 교육하셨던 Merge에 대해 다시 설명해야했다.

솔직히 말해서 진행상황은 그냥저냥 처음했다는 것치곤 무난했으며, 투자한 시간에 비해 부족함은 많다고 생각됐다. 어찌하겠는가 b는 코로나 타격으로 거의 팀프로젝트를 해본 경험이 없으며, c나 d팀장님은 개발 초심자이기 때문에 기대를 하지 않았다. 그냥 지금 할수있는 수준에서 최고의 모습을 보여줘야하지 않겠는가.

2월 20일 (프로젝트 2일차)

a는 캘린더와 칸반 벡엔드 부분을 d팀장님께서 이미 하셨다고 해서 회원가입과 로그인은 거의 끝내두고 캘린더와 칸반을 준비하고 있었다. 아무래도 vuex store or pinia 같은 기능이 중요하기 때문에 그부분을 만들고 있었다.

당시 a는 20일 21일 캘린더, 칸반을 마무리하고 22일 발표자료 준비, 23일 발표로 생각하고 있었다.
d팀장님의 그룹 관련된 부분은 크게 어려운 것이 없고 c의 게시판 기능도 에디터만 붙이면 crud 자체는 끝나는 것이기 때문에 문제없다고 판단했다.
b는 채팅이라기 보다 그냥 웹소켓 연결 및 통신으로 데이터 주고 받는걸로 프로젝트를 마무리해야한다는 생각을 가지고 있었다.
그렇기에 본인 개발 부분에 대해 집중하고 있었다.

d팀장님은 개발을 진행해야하는 상황에서 a가 만들어온 로그인, 회원가입 기능을 보고있었고 b는 뭘하는지 모르겠다. c는 일이 a에게 몰려있고 더 이상 a에게 물어볼수있는 상황이 안되니깐 강사님께 도움을 요청했다.

a는 c의 행동이 잘한 행동이라고 말하기 어렵다고 생각했다. 다만 그 부분은 d팀장님이나 b도 그 상황을 알고 있었고 a가 직접 제재해야 할 상황이 아니라고 판단했다.

끝내는 강사님께서 a를 언급하셨고 업무분담에 대한 아쉬움을 말씀하셨다. 그리고 서로 도와서 진행하라고 조언하셨다. 그제야 d팀장님이나 b도 c를 도와서 만들겠다고 한다.
이때부터 a도 말을 강하게 해야한다고 생각했다.

a는 반쯤 만든 캘린더를 버렸다. a는 고민했었다.
a는 1월에 강사님께서 몇 교육생들과 같이 점심을 사주셔가지고 얻어먹는 기회가 있었다.
그때 a는 다음 프로젝트는 프로젝트 완성에 초점을 두고 개발하는지 아니면 개개인의 발전에 초점을 두고 개발해야하는지 조언을 구한적이 있었고 강사님께서는 프로젝트 완성에 초점을 두라고 하셨다.

a는 만들면 캘린더와 칸반 기능이 나오긴 하지만 우리 프로젝트에서 메인 서비스는 그룹마다 게시글을 작성하는 서비스와 실시간 채팅 서비스이기 때문에 a는 백업하기로 마음 먹었다.

집에 돌아가는 길에 a는 c에게 에디터 관련해서 너무 걱정하지 말고 못해도 a자신이 해버리면 되니깐 내일까지한번 노력해보라고 말했고 c도 그러겠다고 했다.

2월 21일 (프로젝트 3일차)

a는 아침에 바로 d팀장님에게 저희 메인 서비스 2가지중 하나도 완성된 것이 없다고 말했고 캘린더와 칸반을 진행하기보단 게시판 기능과 채팅 기능에 붙어서 마무리 지어야할 것 같다고 말했고 d팀장님께서도 그러라고 말했다.

a는 둘다 본인이 맡아서 진행시키기 어려울 것 같다고 둘중 어느 서비스에 붙으면 좋을지 여쭸고 d팀장님께서는 a씨가 채팅 개발 경험이 있으니깐 본인은 에디터 붙이는 쪽을 도와주고 a는 채팅에 붙어달라고 말하셨다.

a는 평소 같았으면 채팅이라고 말하기도 어려운 저걸 짜르자고 말하고 싶었다.
a는 b옆에서 무엇이 문제인지 물었고 벡엔드와 프론트의 웹소켓 연결을 하고 싶은데 안된다길레
b가 작성한 코드를 보고 있는데 필요없는 코드와 섞여있어서 찾아 해석하기 어려웠다.
무엇보다 b가 설명을 못하는 상황이 제대로 이해하고 코드를 작성한 것 같지 않았다.
그래서 a는 그냥 다시 코드를 짜서 연결했다.

a는 본인이 연결한 방법을 b에게 설명하고 금일 밤 00시까지 데이터 통신 주고 받는걸 만들어와라 console.log라도 찍어와라 그것마저 안되어있으면 제외시킬거라고 말하고 집에갔다.

집에 가는 길에 c에게 에디터 상황에 대해 어쩐지 들었다.
글쓰는 것 자체는 잘 입력되는데 이미지 사진의 갯수를 동적으로 올리는 것이 안된다는 거다.
(Quasar 기본 에디터에는 이미지 파일을 올리는 기능이 없다. 따라서 커스텀 해줘야한다.)

a는 그부분만 본인이 봐주겠다고 하고 a가 c의 코드를 수정하는 것에 대해 허락 받았다.
a는 집에가서 11시 30분까지 에디터 붙여서 서버에 다중 이미지까지 구현해두었다. 그리고 00시까지 b의 연락을 기다리면서 알바가 끝난 c에게 본인이 수정한 코드나 개발한 내용을 설명했다. 그리고 금일 개발내용이나 수정사항을 체크하고 있었다.

아쉽게도 못했다고 새벽 2시에 연락이 왔다.
a는 b에게 그동안 고생많았다고 하루남은거 crud 같이 붙어서 작업해달라고 했다.

2월 22일 (프로젝트 4일차)

a는 지금까지 팀에서 발표자료를 준비안하고 있다는 점을 매우 잘 알고 있었다.
따라서 팀 모두 개발을 정지하고 지금까지 한걸로 발표준비를 해야한다고 생각했다.

하지만 d팀장님의 생각은 조금 달랐다. a에게 b에게 붙어서 채팅을 마무리하라는 것이다.
못해도 내일 오전중까지 만들어보고 안되면 말겠지만 그때까지 최선을 다하라는 거다.

a는 반대했다. 이미 채팅이라고 말하기도 어려운 상태를 붙어서 개발하는 것 자체가 다음날 발표해야하는 이 시점에서 맞지 않다고 a는 본인 구조나 시스템을 가장 잘 알고 만들었으니깐 발표자료를 준비해야한다고 말했다.

그리고 내일 오전중으로 발표자료를 다 정리 못한다고 말했다.

이때 강사님께서 오셔서 b의 상황을 보시고 연결이 되었다면 통신만 주고 받을수있을 것 같은데 계속 만들어보시죠 하고 가셨다.

a는 d팀장님께 내일 본인을 대신해서 발표자료까지 만들어오라고 했다. 그러진 않고 a는 발표 못한다고 말했다. d팀장님은 당당하게 알았다고 걱정말라고 말했다.
a는 b의 채팅을 오후 4시까지 데이터 주고 받는 것까지 만들고 b에게 설명까지 해주었다.

d팀장님는 메인화면을 수정하고 있는 것 같았다. 그리고선 본인이 이미지 파일을 보여주는것이 잘 안된다면서 나한테 하라고 했다. 내가 강사님께서 알려주시지 않았냐. 그거 그대로 붙여넣기만 해도 잘 나온다고 했지만 끝내는 내가 해야했다.

집에가서 d팀장님께서 말씀하셨던 이미지 파일 바인딩 부분을 수정하려했는데

???

a가 작성한 프론트 코드가 수정되어있는거 아닌가.
c가 작성한 게시판 기능의 코드도 수정되어 있었다.

a는 극도로 하기 싫어졌다. 보통 타인의 개발부분에 있어 수정사항이 생긴다면 말하고 수정해야하는 거 아닌가. a는 일단 단체톡방에 다음부터 수정해야할 내용 있다면 말해달라고 말씀드렸고
이와중에 d팀장님께서는 미안요 a씨가 한번씩 확인좀해줘요 말하고 사라지셨다.

2월 23일 (프로젝트 발표)

c는 프로젝트 발표 당일 아침에 정보처리기사 필기 시험을 치뤄야해서 늦게 온다고 했다.
b는 어제 통신 붙여둔 것에 vue로 데이터 바인딩 한 것말곤 더 진행된 사항이 없었다. 이쯤되면 저걸 b가 개발했다고 말하는게 맞는지도 의문이었다.
d팀장님은 a의 발표자료를 준비해 오지 않았다. 그렇기에 a는 11시까지 이미지 바인딩 오류사항, 에디터 문제 이미지파일 오류를 해결하고 서비스 전체적인 테스트까지 마무리했다. 그리고 점심을 안먹고 1시 30분까지 본인 발표자료 준비를 했다. 솔직히 이렇게까지 준비 안된적이 처음이라 당황스럽기도 했다.

a는 고의로 기분나쁜 티를 냈다. a가 느끼기에 d팀장님과 b는 진짜로 a가 괜찮은줄 아는 것 같았다. 그렇기에 발표 저장소로 우리 프로젝트를 복사하는 것을 도와주지 않았다. 강사님께서는 좀 도와주시죠?라고 말씀하셨지만 진짜로 저것마저 도와주면 안될 것 같단 생각이 들었다.

우리팀은 2시에 발표를 진행해야했는데 d팀장님은 발표준비를 다 못하셨다. 그래서 a는 강사님께 가서 d팀장님 발표준비가 좀 늦어질 것 같다고 말씀드렸다. 물론 전체적으로 다른팀들도 모두 발표준비가 안되었기에 다행히 기존 시간보다 늦은 약 2시 30분 ~ 3시 30분 사이쯤 발표를 진행했다.

첫 발표자는 d팀장님이셨다. a와 b를 R&D팀이라고 소개하지는 않나 발표 도중에 자꾸 a를 언급하는 모습이 a입장에선 좋지 않았다.
d팀장님에 이어서 c가 발표하는데 c는 프론트에서 다 완성하지 못했고, 포스트맨으로 좀더 벡엔드에 관해 발표하려했지만 그것마저 에러가 발생했다.
a는 시간을 발표순서를 변경해서 c를 들어오게 하고 대신 나가서 발표했다.
a는 이렇게 개판인 발표는 처음이었다. 그렇게기에 팀원모두에게 포스트맨 체크 안했냐고 쓴소리를 했다.

이어서 b가 본인이 만든것처럼 말하는 발표를 하고 다시 c가 발표하는데 동일한 문제가 발생한다는 시점에서 왜 아무도 도와주는 사람이 없었다는 거에서 a는 화가 났다.
그래서 c가 발표하는 도중에 밖으로 나가있었다.
화좀 삼키고 있었는데 몇분있지도 못하고 메니저님께서 지금 교육시간이라 들어가셔야한다고 들여보내졌다.

이어서 질문을 받는데 왜 jdk 17을 썼는지였다.
왜 이 질문을 a가 대답하지 않아도 되었기에 a에게 b와 d팀장님께 왜 우리가 17을 썼는지 물어봤다. d팀장님의 대답은 우리는 앞서나가기 때문 명언이었다.

2월 23일 (프로젝트 뒷풀이)

a의 기분이 안좋은걸 a와 평소에 잘 다니던 교육생들은 모두 알고있었다.
그치만 a는 사실 기분이 그렇게 안좋았던건 아니다. 그저 이번 프로젝트만 잘 안된거 아닌가? 라는 생각이었다. 이 프로젝트가 최종 프로젝트가 아니기에 큰 문제 없었다.
a는 잘놀고 집에가서 팀톡방을 나가고 c에게 임의로 발표순서를 변경한 점에 대해 사과했다.

2월 24일

d씨에게서 연락이 왔다.
a님~! 미안해요! 그리고 고마워요!

내가 a님 발표자료 만들어준다는 조건으로 우리 리드미 만들 시간을 b님 채팅에 써달라고 부탁했고 실제로 나는 밤새면 충분히 a님 자료까지 만들어낼 수 있을꺼라 생각했는데 ..

변명이지만 생각보다 밤새며 c님 포스트 디테일 만들때 잠을 줄여서 그런지 뇌가 잘 작동안해서 대댓글, 좋아요까지는 구현을 못했고 코딩프로젝트는 처음이다보니 여러가지로 셀수 없는 여러 실수를 많이 한 것 같아서 팀원들이 선출해준 팀장으로서 팀원들에게 미안한 마음이 있어요!

어제는 내 스스로에게 좀 화가 나는 바람에 경우가 없어서 바로 사과를 못하고 오늘 정중히 사과할게요! 

a님과 함께 일 하면서 많은걸 배우고 있어서 항상 고마운마음이에요! 다음 배포 프로젝트때는 내자신을 좀 더 개선해서 더 나은 모습을 보여줄테니 한 번만 더 기회를 줄 수 있다면 답장 부탁해요~!

답장주면 다시 단톡방에 초대할게요!

추가로 내가 모르는 나의 실수가 또 있다면 알려주면 고쳐볼게요! 주말 잘 보내요! 
a는 d씨에게 더이상 기회를 줄 생각이 없었다.
그리고 사과문에 변명을 한다는 것 자체가 논점을 흐리기에 사과라고 생각하지 않았다 그저 변명.
a가 d씨의 잘못된 점을 반복해서 말했지만 수정되지 않아 실수를 알려줄 필요도 못느꼈다.
애초에 a는 d씨의 부모가 아니다. 따라서, a는 답장하지 않았다.

2월 26일

d씨가 아침에 메니저님께 자초지정을 말했다는 소리를 들었다.
그러면서 97년생 남자애하나가~ 팀을 2개로~ a입장에선 같잖은 소리였다.

다만 강사님께 말씀을 드리긴 해야할 것 같았다.
따라서 a는 강사님께 점심식사를 같이하자고 연락하려는데 c도 뭔가 할 말이 많아보였다.
a는 c에게 강사님께 점심데이트 신청하려는데 같이가실?
c는 같이 가겠다고 했고 점심을 셋이서 먹게 되었다.

a는 강사님께 이번 프로젝트에 대해 어떤 것 같은지 여쭤보았고 강사님께서는 본인 감상을 사실대로 이야기 하셨을것이다. 아마?
c도 나름대로 문제점을 이야기했고 a도 팀프로젝트에서 발생한 문제점을 이야기하면서
강사님께서 저희 팀 발표하고 나서 너무 개인 할것만 집중하고 주위를 돕지 않는 그런 모습은 좋지 않다 라고 말했지만 저희가 꼭 그랬던 것은 아니었다라고 다시 말하였다.

물론 그 과정속에 d씨와 b의 태도도 말했고 a는 강사님께 가장 팀내에서 이번프로젝트를 실패하게 된 원이으로 b를 말했다. c와 d씨는 잘만들던 못만들던 뭐라도 만들어왔으니깐 팀내 기여했다고 생각했다. 반대로 b는 과연 그걸 본인이 했다고 할수있는지 1월 말부터 지금까지의 결과가 그거 하나인 점, 그리고 계속 물어보라고 했지만 말이 없었던점 등을 말했다.

강사님께서 어떻게 자리를 한번 마련해주냐고 권유하셨지만 a는 그럴 필요없다고 앞으로 그런 문제가 있다는걸 알았으니깐 잘 대처하겠다, 그리고는 어떻게든 프로젝트 결과는 나오니깐 문제없을 거라고 답했다.
그리고 b = c = d 코딩 실력은 비슷한 것 같다고 말씀드렸다.

a는 마지막 최종프로젝트 팀에 이번 팀처럼 밸런스 한쪽으로 쏠리는 팀을 안만들었으면 하는 바램이 있었다.

2월 26일 저녁 8시

a는 d씨에게 연락을 받았다
a님 ㅋㅋ
사과도 안받아주고
기분도 오늘보니 풀린것같던데
강사님에게 내 뒷담화나 하고
원하는게 뭔지 말을해줘요
전화줘요
a는 한 8시 40분쯤 이 문자를 확인하고 d씨에게 연락했다.
d: 도대체 a님 원하는게 뭐예요. 내 사과도 안받고 강사님께 본인 뒷담화나고. 화 많이 났어요? 나한테?
a: 그 d님 그걸 지금 저에게 물어보시는게 맞다고 생각하십니까?
로 대화를 시작했다.
뭐 대충 통화내용은
왜 사과 안받냐.  (?)
뭘 잘못했는지 알려달라. (??)
팀 프로젝트를 안할거냐. (협박?)
본인은 노력을 했다. (뭘? 다른팀들도 이미 다 시작할때 혼자 늦게 시작한걸?, 도대체 뭘 공부했냐.)
프로젝트 시작전에 내가 논 것 같냐. (당신이 놀던 말던 모른다 다만 계속 경고는 했다.)
프로젝트 시작전에 진행상황이 안되서 화가났냐 (소통문제다. 아직도 문제상황 이해 못했냐.)
무시한거 없다 오해다 사실확인 하자. (참나.)
본인이 화가 나서 그랬다. 이유는 a가 강사님께 안좋게 말을 많이했다. (강사님께서 뭐라고 했던간에 있는 사실만 말했다.)
너 기분이 계속 않좋지 않았냐 나는 너 기분좋을때 연락해서 풀려고 연락했다. (전화 시작을 저렇게 했는데?)
a랑 싸울생각이 전혀 없다. 화가 나서 그랬다. (전화 시작을 저렇게 했는데?)
원하는게 뭐냐 본인아직 3개월차다 (c는 3개월차 아니냐, 누가 초심자에게 뭘 원하냐)
이런 내용이 진행됐다 약 30분 동안. 결론적으로
본인이 잘못한게 맞다 미안하다.
그런데...
이러이러한 상황때문이다.
너가 이해해라.

(? 그건 아니지 않냐.)

너가 그렇게 생각하는건 업무스타일 차이다. 
니가 이해해라.

(???)

그리고 무시한적 없다 오해다.

(반복된 경고했는데, 수정사항 매번 말했는데, 이거 팀플이라고 말했는데?)

오해다.
a에게는 d씨가 이제는 그냥 대화가 잘 안통하는 안타까운 사람이다.
a는 b에게 연락온 것도 아니라 d씨에게서 와서 더 어이가 없었다.
그냥 저 사람이랑 이야기하는걸 최소화 해야겠다.

2월 27일

a는 간만에 다시 velog를 작성하려고 한화시스템 BEYOND SW 캠프 3기_깃,블로그 엑셀에 접속했는데
2024년 2월 25일 버전의 d 인간관계 팁
어떠한 상황에서도 
다정할것.
내 카톡에는 2월 25일 기준. 1982명의 친구가 저장되어있다.
30대 중반 치고는 많은 사람을 겪었다고 생각한다
그리고 저 책을 추천해주신 분들은
내가 제일 영향을 많이 받은 
60대 중반의 박문호 박사님
그리고 누구나 알고 있는
70대가 되신 문재인 대통령님
께서 추천해주신 책이다.
물론 인간관계가 어려운 문제인 만큼 쉬운책은 아니지만
많은 힌트를 얻을 수 있는 책이다!

강사님께서도 후기에서
"팀으로 일을 할때에 항상 매너와 나이스함을 지향했으면 좋겠다. "
라는 말을 남겨주셨다.
매우 공감한다.

아직 사회경험이 없는 20대들은 잘 모를 수 있지만
면접에서 가장 잘 답변해야 하는 질문이
팀 활동에서 생긴 문제점과 해결방식에 대한 경험의 여부다.
모든 조직의 갈등과 고통은 여기서 시작된다.

사회가 성장하는 시기에는 능력주의가 존중받지만
사회가 성장을 마치고 안정을 추구하면서 능력보다는
다정한 사람들이 유리한 위치게 서게된다.
즉, 다정함 >> 능력 이런 세상이 온다는 것이다.

자신이 능력이 있다고 다정함을 등한시 하는 사람들은
능력이 없어도 다정한 사람들 보다 가치가 떨어지는 세상이 올거다.
그것이 저 2권의 핵심 메시지다.

능력보다 다정함이 우선이고
물론 능력과 다정함을 둘다 갖춘 사람은 
생존경쟁에서 매우 앞서게 될 것이다.

그러니 부디.. 능력이좀 있다고 상대를 무시하는 태도로
앞으로 오는 세상에서 살아남을 수 있다는 
느낌을 가지고 있는 자신이 '제정신이라는 착각' 을 
가지고 있다면 하루라도 빨리 버리길 바란다.

[출처] 한화시스템 BEYOND 캠프 3기 15주차 회고|작성자 d
정말 인상깊은 글이다.

항상 매너와 나이스함을 지향하는 것은 존중과 소통을 말하는 것이고
애초에 현 사회에서도 다정함을 등한시 하면 금쪽이 취급당한다.
능력보다 다정함이 우선이라는 것은 능력이 모두 동일했을 경우를 의미한다.
예를 들어 a와 b가 1+1을 모두 할수있다 그런데 b는 착하고 a는 끔쪽이라면 당연하게 사회에선 b가 살아남는다. 그걸 있어보이게 적었을 뿐이다.
본인이 다정하지 않은 상황에서 타인에게 다정함을 강요하는 것 자체가 다정하다고 말하기 어려울 것 같다.

그리고 설마 팀 활동에서 생긴 문제점과 해결방식에 대한 경험의 여부 이걸위해 희생하신 거라면 인정한다. 반박불가.
근데 a는 이 팀말고 몇개 있어요. 굳이 해결안된 내용을 적을 필요는 없는걸요?

미안하지만 a도 사회경험이 있다. d처럼 길지 않겠지만 설마 그걸 시간의 길이로만 말하는거라면 유감이다. 말할 가치를 못 느끼겠다.
능력이 있다고 남을 무시했으면 혼자 다했겠지? 남아서 누굴 도와주거나 알려주지 않았겠지?

누가 제정신이라는 착각을 가지고 있는건가? 흠. 난 모르겠다.

c가 b랑이야기하고 b가 a와 이야기 하기를 원했다.
a는 b에게 강사님께 프로젝트 실패 원인을 b 당신이라고 말했다고 직접 말했다.
b는 a에게 미안하다고 말했다. a는 b의 잘못된 점을 한번 더 말했다.
사과받고 안받고를 떠나서 처음이니깐 그럴수있고 다시는 반복하지 말라고 말했다. b는 c가 말하기 전까지 이상황 자체를 몰랐다고 한다. a는 팀이니깐 관심좀 가지라고 했다.

c가 d씨와 이야기한다고 한다.
a는 굳이 할 필요성이 있냐고 물어봤었고, c는 해봐야겠다고 하길레 내버려뒀다.

2월 28일 ~ 29일

a는 c에게 어제 이야기 잘했는지 물어봤다.
c가 잘 해결했다고 말하면서 대답을 계속 피했고

다른 교육생들에게 들어보니깐 뭐 여자는 군대를 안다녀와서 상명하복을 몰라?
a랑 c랑 좋은 감정있는거 아니냐고 잘해보라는 소리를 들었다는거다.

그래도 a와 d 사이에서 나온소리가 아니기에 a는 일단 조용히 있었다. 다음 프로젝트를 진행해야 하기에 다만 a는 c에게 사실인지 확인했다.
사실이렌다.

다음 데브옵스 프로젝트는 b가 팀장이 되었다. a와 d가 갈등이 있고 c와 d가 갈등이 있는 만큼 어느정도 갈등이 해소된 b가 팀장이 되는것이 좋은것 같다고 c가 말했다.
a는 그 누가 되도 똑같을 것 같다고 생각했다.

현재

참고로 d는 현재 또 같은 잘못을 반복했다.

먼저 각 팀원들이 레포를 가져가기 전에 작업을 진행했다는점.
myPage같은 회원 정보는 원래 내가 만들어야 하는 부분인데 본인이 개발하고 있다.

a는 제재하거나 해당 프로젝트를 더 진행한다는 사실을 명확히 우리에게 알려주지 않은 b팀장님께 한소리 했다.

그리고 a는 분명 코드를 수정할 일이 있으면 그 부분 개발했던 사람에게 말하고 수정하거나 개발하라는 것을 말했음에도 불구하고 본인 멋대로 진행하는 모습을 보면 굳이 같이 프로젝트를 진행해야 하는가에 대한 의문이 든다.

후기

그렇다 a가 나다.
모든 내용은 사실기반이다.
내가 프로젝트를 진행하면서 이렇게 개차반인 경우는 처음봤다.
이번 프로젝트에서 내가 원하는 수준은 컴퓨터 관련 학과 2~3학년 수준의 지식과 강사님께서 알려주셨던 board, order-system 에서 한발짝 앞으로 나가는 정도였다.

다른팀도 물론 좋지 않은 상황이 존재했지만 어떻게든 잘 넘긴 것 같고
짧은 시간내에 많은 기능을 구사하는데 성공해 잘하는 모습이 보기 좋았다.

반대로 스스로에게 그 많은 시간이 있었지만 잘 대처할 수 없었다는 점에서 과연 방법을 없었던 것인가 하고 반성하게 된다.
글 자체에 객관화를 의심한다면 의심하는게 맞다. 내가 보고 경험한 것을 적은 것이니깐 내 주관이 들어가있다. 굳이 객관적으로 확인을 원한다면 b,c,d 모두에게 물어볼 것.

나는 늘 개발 프로젝트에 있어 가장 중요한 것은 1순위는 소통이라고 생각한다.
그런데 이번 개발은 간만에 소통이 불가능한 경우를 만났다. 그저 아쉬움만 남았다.

강사님이나 메니저님께 도움을 요청하면 됐던거 아니냐는 말에
강사님께서는 우리를 가르치시는 분이고, 평가하시는 분이고 메니저님들은 우리가 교육을 잘 받을 수 있도록 옆에서 서포트 하시는 분들이다. 어떠한 팀 자체에서 이래라 저래라 하는것 자체가 형평성에서 어긋난다고 판단했다.

다음에는 조금 더 잘 해결할 수 있도록 노력해보자 파이팅!