2021-04-19 스파르타 42 모집 시작!

개인적으로 진행하는 멘토링은 항상 비슷한 스토리로 흘러가는 경향이 있습니다.
그리고 혼자 하다보면 여러 요인으로 인해 어려움이 생기기도 합니다.
결국 실전 회사와 비슷한 환경에서 진행하는 호준테크코스의 필요성이 있었습니다.

초창기 스파르타 42의 인원은 19명으로 굉장히 많은 숫자의 학생들과 시작하게 되었습니다. 하나의 프로젝트에 배치하기엔 많은 인원이었습니다.
하지만 우리의 이호준 멘토님께서는 묘안이 있었습니다.

절벽으로 내몰다

1. 소통하는 방법을 알려주지 않는다.

우리는 주로 서적, 인터넷 강의, 구글 등 혼자하는 학습에 익숙해져 있습니다.
굳이 다른 사람들과 소통하면서 학습을 진행 할 필요성이 크지 않았기 때문입니다.
결국 우리는 알게 모르게 소통의 중요성을 점차 잊어버리게 된것 같았습니다.
소통의 필요성과 소통하는 방법을 정의하는 과정에서 많은 이탈이 발생했습니다.

"깃허브 작성해두 충분한데 왜 지라를 사용해?"
"눈에 보이는 포트폴리오가 필요하지 내부 소통을 굳이?"
"카카오톡이나 슬렉으로 가볍게 해두 되는데?"
"회사가면 쓸텐데 굳이 여기서 사용 할 필요가 있을까?"

대체 왜 써야 하는지 ? 이유를 모르고 있으니 진행도 되지 않았습니다.
그래서 결국 이 과정 중에 필요성을 느끼지 못한 인원의 이탈이 발생했습니다.
그런 과정을 거쳐 결국 지라 도입에 성공하게 되었습니다.

2. 코드 작성하는 방법을 알려주지 않는다.

건물이 튼튼하려면 기초공사가 잘 되어야 나중에 건물이 무너지지 않습니다.
그와 마찬가지로 개발을 진행 할때는 바로 코드를 작성하는게 아니었습니다.
개발 환경, 언어 버전, 프레임워크의 버전 및 적합성 등 시작 하고나면 쉽사리
변경 할 수 없는 것들에 대한 것들을 정하는것이 우선이었습니다.
위와 같은 사항을 정하는 것에서도 많은 충돌이 발생했습니다.

"그냥 최신 버전으로 사용 하면 되는데?"
"남들이 가장 많이 쓰는게 좋은거 아닌가?"
"취업하기 가장 좋은걸 고르자!"
"아 몰라 책 예제 많은걸로 하자?"

아기가 성정하는 것과 같다.

돌아보면 마치 아기가 성장하는 과정을 경험 한것과 같다. 어느 누구도 아기에게 걷는 방법을 알려주지 않는다. 부모는 아이가 위험에 노출되지 않도록 지켜 볼 뿐이다.
멘토님께서는 이 과정 중에 우리가 잘못 된 길로 가지 않도록 방향성을 제시해주었습니다.
때론 엄청나게 욕뷁부렉뷁뷁뷁뷁뷁뷁뷁뷁뷁뷁을 먹을때도 있지만요!

돌아보면 마치 아기가 성장하는 과정을 경험 한것과 같다. 어느 누구도 아기에게 걷는 방법을 알려주지 않는다. 부모는 아이가 위험에 노출되지 않도록 지켜 볼 뿐이다.

2021-06-01 스파르타 42 과정들

스파르타의 최초 목표는 프론트, 백엔드, 인프라 팀이 협업하여 Hello World를
띄우는 것이었습니다! 언어를 배울 때 가장 먼저 관례적으로 띄우는 것이었는데
이 과정을 협업 과정을 통해 작성하게 되니 대략 한달 정도의 시간이 걸렸습니다.

Hello World를 띄우다.

Hello World를 띄우는 Get Controller를 작성하고 그것을 인프라팀이 배포하고 그것을 프론트엔드에서 접근하는 것부터 시작했습니다.
이 단순한 서버를 배포하는것 조차 각 팀마다 다르게 이해하고 있었고 작동여부를
서로에게 파악하고 이야기 할때 각 팀의 배경을 알아봐야 하는 과정이 필요했습니다.

프론트엔드

바닐라 자바스크립트로 서버에 어떻게 접근하고 정보를 받아오는 과정을 거쳤습니다.
단순하게 화면을 띄우고 콘솔로그를 보면서 작동 방식에 대한 이해하는 것이 목표였습니다.

위와 같은 과정을 통해 정상 작동 여부를 파악하고 본격적으로 코드를 작성했습니다.

백엔드

백엔드는 스프링 시큐리티를 사용해서 42 OAuth를 사용해서 인증 할 수 있도록 구성하였습니다. 이를 통해 프론트엔드와 API 문서를 통해 소통하는 방법을 정의했습니다. 타 팀과 어떻게 문서로 의사소통 할지를 정하는데 많은 시간을 할애하였습니다.

서버

네트워크 지식이 부족해서 세부적인 관리의 어려움을 겪고 있습니다.
그러나 그럼에도 불구하고 서버를 배포하여 테스트 할 수 있는 환경을 구축하였습니다. 그런데 그 과정에서 서버가 죽는 에러가 발생하였는데 백엔드, 서버 문제인지 파악하기 어려운 점이 있었습니다. 이 과정을 해결 하려고 노력하고 있습니다.

의사소통은 이미지를 활용해서!

각각의 카뎃의 회고

1주차 (5/10 ~ 5/14)

AWS Cloud Tag

VPC

• 배포된 지역을 나타낸다.
• Dev / Stg / Prod 를 접미사로 사용한다.
  ex) Zenly-ap-ne2-Dev, Zenly-ap-ne2-Stg, Zenly-ap-ne2-Prod

Subnet

• VPC + Scope + Availability Zone

  • Scope = Public/Private

    ex) Zenly-ap-ne2-Dev-Public-a

EC2

• whatever your team needs-<(dev/Stg/prod/whatever)>-EC2

  ex) Zenly-APISvr-Dev-EC2

S3

• whatever your team needs-<(dev/Stg/prod/whatever)>-S3

  ex) Zenly-StaticHosting-Dev-S3

Terraform Convention

• 각 중첩 수준에 대해 두 개의 공백을 들여 씁니다.

  resource "aws_route_table_association" "fotk_public_route_a" {
    subnet_id      = aws_subnet.fotk_public_a.id
    route_table_id = aws_route_table.fotk_public_route.id
  }

• 단일 행 값이 있는 여러 인수가 동일한 중첩 수준에서 연속 된 행에 나타나면 등호를 정렬합니다.

  subnet_id      = aws_subnet.fotk_public_a.id
  route_table_id = aws_route_table.fotk_public_route.id

• 인수와 블록이 모두 블록 본문 안에 함께 나타나면 모든 인수를 맨 위에 함께 배치 한 다음 그 아래에 >>중첩 된 블록을 배치합니다. 하나의 빈 행을 사용하여 블록에서 인수를 분리하십시오.

• 한 블록 내의 논리적 그룹을 나눌 때는 한 줄 떨어져 있어야 한다.

• 가장 상위 블록은 그 다음 블록과 반드시 한 줄 떨어져 있어야 한다.

• 중첩된 블록도 다른 블록과는 한 줄 떨어져 있어야 한다.

느낀점

위에 aws cloud tag, terraform convention외에도 이슈를 어떻게 관리할지에 대한 규칙을 정하는 시간이었습니다.\
다만 이런 경험이 없어서 이슈와 관련해서 어떻게 기록하는지에 대한 의문점이 많이 남았습니다.

2주차 (5/17 ~ 5/21)

Jira & Confluence

느낀점

칸반보드, 스프린트등 워크플로우를 관리하는 방법에 대해 학습하면서 멘토님이 강조한 Agile을 어떻게 달성해나가야할지에 대해 생각할 수 있어서 유익했습니다.
각자의 hr을 명확히 측정하는게 왜 중요한지에 대해서 많이 느낄수 있었음.

3주차 (5/24 ~ 5/28)

AWS CodePipeline

AWS Console

Terraform

느낀점

스프린트 기간인 3일동안 어느 정도의 Task를 할수 있는지 측정해보기 위해 CI파이프라인 구축을 해보았습니다.\
AWS Console을 이용한 부분에 있어서는 생각보다 빠르게 끝났지만 Terraform을 이용해 IaC로 관리하는 부분에서 엄청나게 시간사용하는것을 확인했습니다.\
스스로 생각했던것보다 훨씬 능력이 부족하다는 것을 많이 느낄수 있었습니다.\
또한 스프린트에 걸린 Task를 처리하다보니 다른 팀에서 요청한 이슈를 스프린트 기간내에 처리하지 못해 전체적으로 계획이 밀리는 것을 확인하며 스프린트에 Task를 발행할떄 나의 역량과 우선순위를 기준으로 여유를 두고 발행해야겠다고 생각했습니다.

4주차 (5/31 ~ 6/4)

장애대응

3주차때부터 빈번하게 발생하던 문제였으나 원인을 파악하지 못하고 회고, 버퍼기간에 추가적 조사를 통해 대략적으로 하드웨어 스펙중 메모리 부족으로 인한 원인으로 추정하기 시작했습니다.\
추정이라고 하는 이유는 AWS CloudWatch에서 제공해주는 모니터링 값중 메모리에 대한 부분이 없어서 명확하게 확정지을수가 없었기 때문입니다.\
개별적 모니터링 툴이 필요하다는 점을 학습할수 있었습니다.\
또한 장애보고 이후 해결까지 시간을 측정하면서 기록을 남겨뒀습니다.

Prometheus

하드웨어적 요소에서 발생한 장애중 CloudWatch로 모니터링 하지 못하는 부분으로 인해서 어떤것을 도입할까 고민하던중 ft_services에서 했던 TIG스택 Telegraf, InfluxDB, Grafana를 도입할까하다가 Kubernets모니터링 표준인 Prometheus를 테스트 삼아 도입해봤습니다.\
구체적인 원리를 모른체 사용하는 것이라 의도한 매트릭은 정상적으로 수집하는것으로 확인했으나 추후에 다양한 모니터링 툴들을 공부하기로 결정했습니다.

느낀점

4주차에 CD파이프라인을 구축하기로 Task를 발행했지만 내가 알고 있는 지식수준에서는 온전히 구현할수 없는 점을 확인했습니다.\
특히 스프린트 기간에는 학습을 하지 않고 내가 가진 지식수준으로 발행한 Task를 해결하려고 시도하는데 얼마나 지식이 부족한지 느낄수 있었습니다.

Phase1 계획

• Prometheus 도입
• CD파이프라인 구축
• Sonarqube 도입

[1, 2주차]
jira와 slack을 통한 소통방법 확인.
느낀 점 : 프로젝트 관련 세팅할 내용들이 많고, frontend에 대해 아는 것이 없는 상황이라 공부의 필요성을 느낌.
[5/22 ~ 5/27]
개발환경, 배포환경 세팅 및 코딩 컨벤션 정의.
느낀 점 : front-end자체가 처음이기에 더 많은 노력이 필요하겠다는 자각을 하게됨.
[5/29~6/3]
jwt token을 이용한 login 및 user 정보 받아오기 구현.
느낀 점 : 진행하면서 많이 막혔으나, 다른 팀원들과 문제를 공유하며, 해결방법을 찾아보고, 다른 해결방법에 대해 알아가며 FE에 재미를 느끼기 시작.

OT

​
오티때 이호준 멘토님과의 시간이 있었다. 첫 OT인테도 불구하고 커뮤니티가 나아가는 방향을 확고하고 단호하게 말씀해주셔서 힘든 길이 되겠지만, 그만큼 후회 안할 시간이 될거라는 기분이 들었다. 가장 이해 안됐던 부분과 이젠 가장 와닿는 부분은 아래와 같다.
​

공부할 생각으로 온 ㅁㅁ들은 지금 나가.
​

첫번재 주차 (21.04.27 ~ 21.05.03)

​
첫주차엔 이슈 컨트롤이나 정보 아카이브 방법, 트러블 슈팅 등의 단어가 낯설었다. 협업을 단 한번도 안해본 나로썬 github 기능조차 제대로 알지 못했고, 칸반보드나 스크럼 등의 프로젝트 매니징 방식도 들어보지 못했다. 이런 단어의 그림조차 안그려지는 상태에서 우리가 개발하려는 서비스(젠리)의 유즈케이스를 작성해가기로 했다.
​

• 멘토링

  ​
  • 유즈케이스가 문제가 아닌 어떻게 이슈 컨트롤 하거나 프로젝트를 어떻게 관리할 것인지에 대한 문제를 지적해주셨다. 새로운 신입이 들어온다고 했을 때 정리되어 있는 문서만 보고 바로 투입될 수 있도록 하는 도큐멘트나 템플릿을 미리 만들어 놓기를 바라신 것 같았다.
    ​

두번째 주차 (21.05.04 ~ 21.05.14)

​
첫주차의 멘토링을 바탕으로 팀 협업을 어떻게 해나갈 건지에 대한 방법에 대해 더 집중하는 한 주가 되었던 것 같다. 어떤 커뮤니케이션 툴을 쓴건지, 그리고 그 툴을 어떻게 쓰는 건지에 대한 학습이 이루어졌다. 학습 후에 이슈 레이블과 발급 기준 등에 대해 토의를 나눴다. 결론은 지라 를 사용하기로 하였고, 이슈 유형과 이슈 레이블 등에 대해서 구체적으로 정하게 되었다. 하지만 아직 자료 아카이빙에 대해선 notion으로 할지 지라의 confluence로 할지 정해지지 않았다.
​

• 멘토링
  • 멘토님의 제자 분이 오셔서 협업을 어떤식으로 했는지에 대해 설명을 해주셨다. 적었던 것중 가장 신기했던 말은 동사는 메소드가 되고 명사는 클래스가 되거나 파라미터가 된다. 였다. 이런식으로 투두리스트를 작성한다고 한다.
  • 오늘에서야 스터디가 아닌 일을 하라는 말씀의 뜻을 이해한 것 같다. 스터디라는 것은 회의 등에서 의견이나 사안을 정할 때 가만히 있고 들으면서 그냥 배우기만 한다는 것을 뜻한다. 멘토님은 팀끼리의 소통이나 팀간의 소통이 있을 때, 학습은 미리 해가고(당연한 것) 그 현장에선 학습한 것을 바탕으로 자신이 쌓은 지식을 꺼내서 그 팀의 workflow의 일원으로서 참가하라는 말씀이신 것 같다.
• 느낀 점
  • 깨달았지만서도 현재까지도 잘 해내지 못하는 부분인 것 같다. 아마 이때의 핑계는 과제의 변동때문에 추가로 그래픽 과제가 생기기전에 현재 circle을 탈출해야 해서 미숙하게 해갔던 것 같다. 다음번부턴 핑계없이 완벽히 해와야 겠다는 생각을 분명히 이땐 했었다.
    ​

세번째 주차(21.05.15 ~ 21.05.21)

​
세번째 주차엔 이전에 정한 협업 툴(JIRA)에 대한 소통 방법과 전 주차에서 해결하지 못한 다양한 하위 이슈 생성 문제를 JIRA 회사 계정을 사용하는 것으로 해결을 하였다. 이에 22일 전에 jira를 통한 커뮤니케이션 규정 알파버전을 생성하였다.
​

​

• 멘토링
  • 드디어 커뮤니케이션 문서가 만들어져서 이것에 관해서는 괜찮으시다고 말씀하셨다.
  • 하지만 개발 면에서 어떠한 프레임워크를 쓸건지에 대한 것과, 왜쓰는지, 다른 것과 비교해서 어떤게 좋은지 또한 브라우저 동작 등에 대한 원리적인 것들을 꼭 알아야 한다는 말씀을 해주셨다. 여기서 놀랐던 점은 어떤 IDE를 써서 할건지도 팀끼리 맞춰서 진행해야 한다는 것이었다. 정말 내가 왜 이 에디터를 쓰는지조차 생각을 해보지 않았는데, 멘토님의 말씀으로 웹스톰과 VSCode의 비교를 통해 어떤 에디터를 쓸건지에 대한 고민을 해보게 되었다.
• 느낀점
  • 이때까지도 적극적인 참여를 하지 못하였다. 전 주차와 마찬가지로 써클을 통과하는 데 과제가 하나 더 생겨 마저 끝내는 것에 집중 했던 것 같다. 다 사정이 있어도 해오시는 분들이 많을텐데, 이대로면 얻는 것도 없을 것 같다는 생각을 하게 되었다.
    ​

네번째 주차 (21.05.22 ~ 21.05.28)

​
멘토님이 해주신 말씀들을 바탕으로 개발 환경을 똑같이 맞추는 한주가 되었다. 프론트 엔드 팀은 바닐라, React JS, vue 등에서 어떤 것을 선정해서 코드를 짤 것인지와 그 이유에 대한 것을 분명히 했다. 결국은 바닐라로 하기로 했는데, 그 이유는 지도에 대한 openlayers를 직접 만들려고 할 때 DOM에 대한 접근이 많고 이를 좀더 직관적으로 구성할 수 있는게 바닐라여서 였다. 이외에도 npm 버전이라던가 Node 버전, 코딩 컨벤션, bundler 등에 대해 어떤 버전을 어떠한 이유로 정하게 되었는지에 대해 토의가 이루어졌다. 또한 webstorm과 vscode간의 경쟁에서 일단은 vscode를 써본 후에 한계를 느낀 직후 webstorm을 써보면서 장점을 절실히 느껴보기로 결정했다.
​

• 멘토링
  • 팀간의 소통과 더불어 각 팀간의 역할에 대한 것을 말씀해주셨다. 백엔드는 어떤 것을 준비해야 하고, 프론트는 ops팀에 제공받아야 할 것을 미리 알려주는 등의 전체 팀간의 flow를 설명해주셨다.
• 느낀점
  • 어떤 버전을 선택하고 어떤 도구를 사용할지에 대한 고민을 해본 적이 없었는데, 이를 계기로 개발 환경에 대한 각각의 베네핏을 고민해보고 적용을 하는 경험을 해보았다. 계속해서 좋은 방향으로의 말씀들을 해주시지만 100퍼센트 받아들이지 못하는 것에 대해 노력을 해야겠다는 생각이 또 들었다.
    ​

다섯번째 주차 (21.05.29 ~ 21.06.04)

​
멘토님이 말씀해주신 대로 전체 팀끼리의 개발 플로우에 대해서 맞춰보는 주차가 되었다. 프론트 엔드 팀은 로그인 서비스를 구현하면서 백엔드와 소통을 어떤식으로 할 것인지에 대해 경험을 했고, 백엔드 팀은 swagger 문서로 프론트 팀에게 API 명세를 해주는 방식으로 커뮤니케이션이 진행되었다. 시스템 쪽과도 마찬가지로 npm 버전이 각 OS환경에 따라 조금씩 달라져서 같은 환경을 맞추려는 이유로 ssh 환경 위에서 작업을 하기 위해 서버를 띄워줄 것을 요청했다. 이를 JIRA의 요청 이슈를 발급하는 식으로 소통이 진행되어 팀간의 소통도 미리 정하였던 커뮤니케이션 규정에 기반하여 이루어지는 주차가 되었다.
​

• 멘토링
  • 버그가 발생했을 때 어떠한 문제 때문에 발생했는지와 어떤 방식으로 해결했는지에 대해서 문서화 시켜, 다음번에 같은 버그가 생기면 바로 처리할 수 있게끔 하라는 말씀을 해주셨다. 또한 백엔드 팀의 swagger문서가 프론트 엔드팀이 보기에 이해가 쉬웠는지에 대해서도 확인하고 어려웠다면 어떻게 주고 받는 게 더 좋은지에 대한 소통도 이루어져야 한다는 말씀을 해주셨다.
    ​
• 느낀점
  • 팀간의 소통이 내가 생각하는 그 이상으로 더 깊게 이루어져야 한다는 것을 느꼈다. 이해가 어려웠다면 내가 더 이해해야지가 아닌, 그에 대한 문제를 해결하기 위한 소통을 해야겠다는 생각을 하게 되었다. 아직까지 git flow에 익숙하지 않아서 여러모로 질문을 하게 되었다. 하지만 모르는게 부끄러운게 아니라는 팀원분들의 말씀 덕분에 질문을 하게 되었다. 하지만 회고할 때, 내 질문이 곧 다른 팀원들의 질문이 될 수 있다는 생각을 하면 좋다는 말씀을 듣고 이제부터 개인 DM이 아닌 질문 채널에 올려야 겠다는 생각이 들었다.
  • 한달이 넘게 지났는데도 과제를 완벽히 하지 않아 자신감이 많이 없어지게 되는 것 같다. 아는 게 없어서 질문하는게 두려워지지만 다른 사람들은 모르는 상황에서도 질문을 자신있게 하는 것을 좀 더 본받고 노력해야 겠다는 생각이 들었다.

1주차(5.3 ~ 5.7)

Sparta가 시작되고 협업 방식을 정하기 시작, 툴체인 선정, 당시에는 팀별로 툴체인을 선정하였다. 유저가 사용하는 상황에 대한 유스케이스를 작성하였다.
소감: 커뮤니케이션의 방법을 정의해야 했다. 이 시점에서 각 팀간의 소통을 정의할 워크플로우가 정의되고 문서화되었어야 하나 아직 어떤식으로 이 프로젝트를 접근해야 할지 모호했기 때문에 팀 내에서도 정해야 할 사항들이 확실하지 못하였다. 따로 유스케이스를 작성하였으나, 해당 과정이 앞선 과정(기능 정의 등)이 생략된 상태였기에 명확한 결론이 나오지 못하였다. 프로젝트 진행 전 먼저 선정되어야 할 부분(커뮤니케이션 방식이나 툴 사용법 등)이 진행되지 않고 프로젝트가 진행될때 생길 수 있는 문제점들을 경험했다. 해당 과정을 얼마나 잘 수행하고 정의하느냐에 따라 프로젝트의 초기 진행속도가 결정된다고 느꼈다.

2주차(5.10 ~ 5.14)

Jira 사용법 논의 및 workflow 회의
소감: Jira의 사용법에대해 논의하고 정했어야 했지만, 이 때 왜 지라를 사용해야 하는지 어떤 방식으로 지라를 사용해야 하는지가 명확하지 않아 회의가 겉돌았다. 이런 부분도 커뮤니케이션의 부재가 가져온 부분이라고 생각하고 크게 소리를 내지 못했던 것에 대해 다시 생각해보게 되었다.

3주차(5.17 ~ 5.21)

workflow guide문서 작성 및 커뮤니케이션 방법 선정
Atlassian
소감: 지라의 사용에 대해 팀 간 커뮤니케이션과 요청이 어떤 방식으로 진행되어야 하나를 정의하였다. 목표는 슬랙이나 말로 요청하던것을 지라만으로 가능한 방법을 고안하려 하였고 해당 과정에서 지라의 사용법을 상당히 알게 되었다. 이 주 멘토링에서 개발 환경을 왜 구축하는것이 중요한지에 대해 멘토링을 받았다.

4주차(5.24 ~ 5.28)

저번 주 멘토링 과제를 중심으로 개발 환경을 어떻게 셋팅해야 할지에 대한 회의를 진행. 개발 환경 문서가 작성됨
Atlassian
소감: 프론트의 개발환경을 세팅할때 고려해야할 사항들을 정리할 수 있었다. bundler, node환경등등, 그래서 통일을 위해 해당 환경을 docker나 ec2등 특정 개발 환경에 올려야 할 것이라 느끼게 되었다.

5주차(5.31 ~ 6.4)

로그인 구현을 통한 서버 통신 확인 및 기초적인 배포 환경 확인
Sparta front
소감: 최초의 결과물이 나온 시점이다. 결과물이 나온것 보다 각 팀의 커뮤니케이션이 지라를 통해 활발히 이루어졌으며 해당 작업에 대한 결과나 과정이 일괄적으로 작성되어 트래킹이 가능한 점이 결과물이 나왔다는 느낌이 들었다.

6주차(6.7 ~)

Code convention 및 개발 환경 최종 세팅, github 워크플로우 설정 및 review방식 선정

Phase 0

우리의 phase 0의 주 목적은 각 프론트엔드, 백엔드, ios, devOps 팀의 팀 내에서의 소통 방법과 다른 팀과의 소통 방법에 대해 정의하는 시간을 가졌습니다. 입사하게 되면 jira, confluence 문서 작성 등, 이미 전부 세팅되어 있는 상황이지만 이번 팀 프로젝트에서 개발환경을 세팅해봄으로써 입사 이후 각 기업의 소통 방식을 이해하고 적응하기에 훨씬 효율적일 수 있을 것 같아 의미있는 시간들이었습니다.
환경 세팅 후에 팀원 각자의 개발 이해도에 대한 확인을 위해 같은 로그인 기능을 구현하였는데 같은 기능을 정말 다양하게 구현한 코드들을 비교해보면서도 많은 것을 배울 수 있는 시간이었습니다.
react에서는 쉽게 사용하던 기능들을 vanilla js로 이해하기 어려워하는 스스로를 돌아보면서 어떤 지식이 부족한지도 확인할 수 있었던 기회였습니다.

"Hello, World!", 스스로 정답을 찾아 모험했던 1달을 돌아보며.
첫 모임, 멘토님께선 함께 일하는 방식을 맞추라고 하셨다.
어디에 회의를 올리고, 어떻게 소통하고, 개발은 어떻게 진행할 건지 정하고, 그 끝에 hello world 를 찍어 보는 것이 첫 한 달의 목표였다.
처음엔 사람도 많고, 팀별로 한번에 관리하기가 어렵단 점, 비교적 진입장벽이 낮다 판단되는 툴을 쓰자는 점에서 각 팀마다 툴이 갈렸었다.
그러나 시간이 지나며 다른 팀의 내용을 함께 한 자리에서 모두 보고 공유해야 만한다는 사실을 자연스럽게 알게 됐다.
다른 팀들의 일정을 모두 꿰고 있을 수 없었고, 그들의 작업 내용을 매번 다른 툴에서 확인하는 건 꽤 불편하다는 걸 알게 되었기 때문이었다.
서로 노력한 덕일까. 발을 맞춰가며 굳이 말을 하지 않고 툴만 이용해도 의사소통이 되기 시작했다. 그렇게 각 팀마다의 일하는 방법, 더 나아가 Jira, Slack, 등 도구를 이용한 팀 커뮤니케이션 방법마저 하나 씩 하나 씩 정리되었다.
그리고 한 달이 다 되어 갈 때 즈음, 첫 Swagger 문서가 탄생하고, 이를 통해 Backend와 통신하여 간단한 로그인 기능을 구현할 수 있었다. "이 한번의 통신을 위해 얼마나 힘을 들였는지."
아마 오랜 기간 동안 잊지 못할 좋은 기억이 되지 않을까 싶다.
처음엔 "함께 일할 수는 있을까" 싶었는데,
이젠 "함께 무엇을 하면 좋을지"란 생각이 든다.
매주 피드백하며 애써주신 멘토님과, 함께 고생한 팀원들에게 감사함을 전한다.
이젠 Hello World를 넘어 다음 발자국을 힘차게 내딛어봐야지.

시간순

iOS 팀 1주차:

• sparta42 레포를 만듦.
• xcode 버전을 결정
• swift 언어 버전을 결정
• 의존성 관리도구를 결정
• git commit 양식을 결정
• 배포할 iOS 버전을 결정.

kchoi: git commit 방식도 맞추고 레포를 만들고 회의도 잘 진행했으니 다같이 으쌰으쌰 해서 무언갈 만들어보고 싶다는 생각을 함.

iOS 팀 2주차:

당시 팀원 총 4명 중 2명은 회의에 참여하지 않음.

남은 두 명이서 다른 팀들과 회의를 하고 공지를 하였으나 팀내 참여율이 저조해 사실상 아무것도 진행되지 않음.

• jira 및 confluence를 사용하기로 결정

kchoi: 1주일 넘게 팀원들과 소통이 제대로 되지 않는 느낌이라 이번 프로젝트가 제대로 흘러갈 수 있을까에 대해 의구심이 듦.

iOS 팀 3, 4주차:

iOS 팀원이 한 명이 됨.
그동안 정하지 못한 사항들에 대해 빠른 의사결정이 가능해짐.
아래 사항들을 모두 이행. (문서화는 모두 confluence)

• 깃 사용형식을 정함.
• 깃 사용형식 문서화
• swift 와 objective-c 중 무엇을 사용할지에 대해 결정 & 문서화
• xcode 버전을 12.5로 결정한 이유를 문서화
• swift 버전을 5로 결정한 이유 문서화
• iOS 타겟을 13 이상으로 잡은 이유를 문서화
• 디자인 패턴으로 MVVM 채택 & 채택 이유 문서화
• 의존성 관리도구로 cocoapods를 사용하기로 한 이유를 문서화
• 화면 간 정보전달 방식을 RxSwift를 이용하기로 결정 & 문서화
• TDD 를 어떻게 해나갈지 결정 & 문서화
• 스토리보드를 쓸 것인지, 코드베이스로 갈 것인지 결정 & 문서화

kchoi:

팀원에 단 한 명밖에 남지 않았지만 그런대로 의사결정을 매우 신속하게 할 수 있어서 한편으론 다행스러움.
jira를 이용해 에픽과 스프린트라는 큰 목표를 세우고 그것을 다시 이슈라는 작은 단위로 나누어 관리하니 진정한 협업을 하는 것 같은 느낌이 듦.
confleunce에 모든 결정사항이나 회의록을 문서화 해두니 내 뒤에 누군가가 iOS 파트로 들어온다 하더라도 바톤터치가 쉽게 가능할 것이라는 자신감이 생김.

phase순

phase 0

• sparta42 레포를 만듦.
• xcode 버전을 결정
• swift 언어 버전을 결정
• 의존성 관리도구를 결정
• git commit 양식을 결정
• 배포할 iOS 버전을 결정.
• jira 및 confluence를 사용하기로 결정.
  ​
• 깃 사용형식을 결정 & 문서화
• swift 와 objective-c 중 무엇을 사용할지에 대해 결정 & 문서화
• xcode 버전을 12.5로 결정한 이유를 문서화
• swift 버전을 5로 결정한 이유 문서화
• iOS 타겟을 13 이상으로 잡은 이유를 문서화
• 디자인 패턴으로 MVVM 채택 & 채택 이유 문서화
• 의존성 관리도구로 cocoapods를 사용하기로 한 이유를 문서화
• 화면 간 정보전달 방식을 RxSwift를 이용하기로 결정 & 문서화
• TDD 를 어떻게 해나갈지 결정 & 문서화
• 스토리보드를 쓸 것인지, 코드베이스로 갈 것인지 결정 & 문서화