우아한테크코스 프리코스 2주차 미션을 시작하기에 앞서

프리코스의 1주차 미션이 화요일 자정에 마감이 되고 2주차 미션이 시작되는 다음날 수요일 오후, 실시간으로 [코수타] (코치진과 수다하는 타임) 가 진행되었다.


1주차 미션에서는 총 7개의 문제가 출제되었는데, 이는 기존 프리코스 코테에서 4시간동안 풀어야 하는 일곱 문제가 출제된 것이고, 이번 프리코스에서는 7문제를 일주일간 해결하는 방식이었다.
모든 문제들은 어떠한 특정 알고리즘을 알아야 풀 수 있는 문제가 아닌 것들로 내기 위해 노력했다고 하셨고, 문제의 요구 사항이 명확하지 않은 것도, 빈틈이 있는 것도 제출자의 의도였다고 한다.

사실 문제들을 풀면서 고민을 많이 하긴 했지만, 슬랙 커뮤니티에서 활성화된 여러 토론의 장을 보았을 때 훨씬 더 많이 알고, 더 깊게 고민하고, 다양한 방식으로 접근하는 많은 분들이 있음을 깨달았다.
슬랙 커뮤니티에 거의 참여하지는 않았고, 가끔 해결하지 못한 내용이 있는 경우 검색하여 공유된 컨텐츠들을 참고하는 용도로 사용했음에도, 종종 올라오는 많은 분들의 지식 공유(테스트 케이스 공유, 언어의 다양한 기능들, 객체지향과 클린 코드에 대한 이야기 등) 컨텐츠들이 올라오는 것을 볼 때마다 조금 압도되었던 것 같다.

(여기 고수들만 참여하는 곳인가...? 나는 알지 못하는게 너무 많은데! 이제 막 Java 언어를 다시 익히려고 하는 나는 언젠가 중도 포기해야 하는 상황이 올 수도 있겠다 싶은 마음이 들기도 했다.)
다행히도, 코수타를 통해 오리려 막막함을 느껴왔던 순간을 극복하고 다시 새로운 미션에 도전할 용기를 얻을 수 있었다.

오늘 진행된 코수타와 2주차 미션 메일의 내용을 바탕으로, (2주차 미션과 관련된 내용은 제외) 2주차 미션을 시작하기에 앞서 주의하고 되짚어봐야 할 부분을 정리해보자.

---

 

코수타 란 무엇인가?

코수타(코치진과의 수다 타임)이란, 교육생들과의 소통을 원할히 하기 위해 익명으로 받는 질문들에 대해 코치분들이 답변을 해주는 우아한테크코스 본 교육 커리큘럼에에 포함되는 시간 중 하나이다.
기존에 프리코스에서는 커뮤니티도, 코수타도 없었다고 한다.
(이번에는 프리코스에도 이런 시간이 포함되어 있다니, 5기 프리코스 참여자로서 너무 감격스럽고 시간을 내주시는 교육자분들께 감사하다.ㅎㅎ)

즉 오늘의 코수타는, 저번주 슬랙에서 미리 받았던 질문들에 대해 답변을 해주는 시간이라 할 수 있다.

 

사전 질문들에 대한 답과 인사이트

 

1. 질문을 잘 해야 한다.

프리코스가 시작되며 슬랙이 오픈된 이후로 정말 많은 질문들이 올라왔는데, 반드시 스스로 해결해야 하는 일들 (예를 들면 Github 세팅과 기본적인 개발 환경 설정, 요구사항 중 기능 목록 작성, 커밋 메세지 작성) 에 대해서는 누군가에게 조언을 구하고 하나하나 무작정 질문해서는 안되는 부분이었다.
스스로 삽질을 하면서 학습하고, 다양한 시도를 통해 해결책을 찾아야 하는 것이 프리코스의 핵심인데 활성화된 슬랙 커뮤니티에는 이런 것들을 조금 위배하는 질문들과 토론이 많이 오갔다고, 코치분이 말해주셨다.

그리고 질문을 하고자 할 때는, 스스로 여러가지 선택지 중 고민을 하고, 다양한 방법들을 먼저 시도해 본 후에, 시도한 방법들에 대해 장단점을 제시해보며 많은 선택지들에 대한 다른 사람들의 의견을 묻는 열린 토론형의 질문들을 해야 한다.

질문하는 것은 개발자로서도 매우 중요한 역량이다. 그동안 초중고등학교를 겪으며, 하나의 정답을 찾는 방식으로만 우리는 교육을 받아왔기 때문에 좋은 질문을 하는 것은 사실 어려울 수 있다.
그러나 현장에서는 "정답" 이 명확히 나오는 문제들이 거의 없다.
실제로 우아한 형제들에서도, 질문을 장려하는 분위기를 독려하고 있으며서 동시에 질문에 대해서 답이 아닌, 오히려 역질문을 통해 토론의 분위기가 형성되는, 그런 개방형 질문들을 할 수 있도록 유도한다고 한다.

그리고 학습할 때 "조급함" 을 버리자. Comfort Zone, 편한 방법으로만 하면 성장하지 않는다고 한다. 어려운 문제에 봉착했을 때 머리를 쥐어 짜내며 고민하는 시간이 필요하다. 어떻게 설계 해야 할지, 어떻게 기능 목록을 구현해야 할지를 오랜 시간동안 스스로 깊이 몰두하여 고민하는 과정을 꼭 거치는 것이 중요하다.

다른 사람들의 속도와 비교하며, 휘둘리지 말고 내 중심을 잡고 내 속도대로 묵묵히 내가 가야 할 길을 걷자.
다른 사람들이 중요하다고 하는 부분에 휩쓸려 이것저것 나도 다 해보려는 그런 욕심을 부리지 말자!

당연히 프리코스를 참여하고 있는 3000 명의 지원자 가운데에서, 잘하는 사람도 이제 처음 막 시작하는 사람도 있을 것이다. 잘하는 누군가로 인해 좌절하거나 힘들어 하지 말고, 꿋꿋하게 내 실력을 늘리고, 내가 성장하는 것에 집중하자!
라고 독려해주셨다. 

 

결론, 어떤 질문으로 인해 토론이 일어날 수 있도록 좋은 질문을 하자.

그리고 조급함을 버리고, 내 속도대로 학습하자.

 

 

 

2. 미션 제출 시간

요구사항을 잘 읽는 것이 중요하듯, 공지 문서를 꼼꼼히 읽는 것도 개발자로서 중요한 역량 중 하나이다.
제시된 가이드, 원칙대로 지켜야 한다. 물론 실수가 발생할 수도 있지만, 한 번이라도 잘못을 했다면 본인이 책임을 지녀야 하는 것이 맞다.

 

3. 정답은 없다

코치의 피드백은 있되, 프리코스에서 진행되는 모든 문제에 대한 설계와 답은 제공하지 않을 것이라고 한다.
요구사항을 자의적으로 해석하여 스스로 해결해나가는 것이 핵심이기 때문..!

이번 1주차 문제들은 일반적인 코테 문제들처럼 명확한 예외사항이 제시되지 않았는데, 이는 예외사항들을 스스로 발견해내도록 하기 위함이었다고 한다. 현장에서도 명확하지 않은 요구사항들이 너무 많기 때문에 이를 연습하는 과정으로 삼으라고 하셨다. 완벽함과 정답만을 추구하지 않기를!

 

---

 

1주차 미션 관련 질의 응답

 

1. 기능 목록은 어떻게 만들면 좋을까?

기능들은 최대한 잘게 쪼개보는 것이 좋다. 실제 현실 세계에서 서비스를 개발할 때에는, 내가 모르는 문제들, 전에 해결해 보지 못했던 문제들에 접근해야 하므로 막연한 경우가 많다. 이러한 막연해 보이는 문제를 해결하기 위해, 해결할 수 있는 가장 작은 단위로 쪼개어 보면 된다.

 

작성한 코드의 동작을 지금 당장, 빠르게 확인할 수 있을 정도로 작게 쪼개라. 이것보다 더 작게 쪼갤 수 있는가? 라는 생각이 들 정도로 쪼개고, 그 이후로 문제에 익숙해 진다면 비슷한 것들을 묶어보면 된다. divide and conquer 을 기억하고 이 방법으로 근하자.

그리고, 작게 쪼갠 기능들 중 가장 핵심적인 동작을 담당하는 기능을 먼저 접근하자.

2. 보기 좋은 Commit Message란?

읽어봐라. 이해가 잘 된다면 좋은 커밋이다.
결국 사람이 읽기 위한 커밋이고, 각자 작성한 코드를 공유해야 하는 것이므로, 이해하기 쉬운 커밋이여야 한다.
커밋 또한 다른 누군가가 읽고 이해해야 할 하나의 문서라고 생각하면 된다.

2. 모호했던 제한 사항

제한 사항들은, 일부러 의도적으로 모호하게 작성한 것이라고 재차 말해주셨다.
왜 이렇게 모호하게 작성했는가? 현실에서도, 제한 사항이 명확하지 않기 때문이다.
현실에서 만들어 나갈 소프트웨어에도 정답이 없고, 사용자들의 니즈를 파악하고 처리해 나가는 과정을 모두 스스로 해낼 줄 알아야 한다.

모호한 상황에서 어떻게 대응할지, 어떻게 방어 케이스를 작성하고 테스트를 해야 할지를 프리코스에서 경험했으면 하는 것이라 덧붙여 설명해주셨다.
예를 들면, 사용자가 폼에 email 을 입력하는 기능을 만들 때, email 형식에 맞지 않는 문자열을 입력한 경우, 사용자에게 어떤 경고 메세지를 띄워 사용자가 정확히 다시 입력하도록 해야 할텐데 이를 프론트단에서 해결할지, 혹은 백에서 처리해야 할지 와 같은 고민이 생길 수 있다.
이러한 많은 경우의 수들에 대해 어떻게 접근해야 할지에 대해 고민해보는 과정이 매우 중요하다.

현실 세계를 반영하여 고려한 프로그래밍 과정을 미리 연습해 보도록 하자.

---

 

미션과 관련해 강조하고 싶은 4가지

 

1. 요구사항을 꼼꼼히 읽어 볼 것

꼼꼼히 읽지 않으면 분명히 실수하는 경우가 생긴다.
2주차 문제에서부터는, 요구사항을 꼼꼼히 읽지 않으면 실수하고 놓치고 있는 부분이 많을 것이다.
설계하는 코치분들은 한 문장 한 문장 신경 써서 만들기 때문에, 잘 읽자.

2. PR은 한 번만 보내도 된다.

PR 여유롭게 보내고, 나중에 추가적으로 커밋하며 보완하면 된다.

3. 의미 있는 Commit Message를 작성하자.

읽는 사람이 잘 이해할 수 있는지를 고민하며, 하나의 문서라 생각하고 작성하자.

4. 이름을 통해 의도를 드러내자.

네이밍을 통해 작성한 코드의 의미를 잘 드러내자.

for문의 i, h 등과 같이 알파벳 하나로 변수를 표기하는 것, 분리한 메서드의 이름이 너무 추상적인 경우는 적절하지 않은 예이다. 어플리케이션의 규모가 조금만 더 복잡해지면 손을 대기 어려워지므로, 메서드, 변수의 역할과 의도를 잘 드러내는 이름을 잘 고민해보자.

의도를 잘 드러내는 네이밍을 하기 위한 과정은?
1. 먼저 해당 함수가어떤 함수인지 긴 문장으로 써보자. 메서드가 무엇을 리턴하고, 어떠한 방식으로 동작하는 함수인지에 대해 작성해보자.
2. 이후로 의도를 단위별로 하나씩 빼가면서 다듬어 나가자.
어떤 과정을 통해 더 좋은 네이밍을 만들 수 있을까? 라는 과정에 집중해보자.

---

 

프리코스 커뮤니티

처음 일주일 간 슬랙에서 많은 대화가 오갔는데, 이는 이전에 의도했던 커뮤니티 활동의 의도와 방향이 맞았는가?
이 질문을 시작으로, 지난 1주차 커뮤니티의 모습을 회고하고 2주차 커뮤니티의 방향성을 제시하셨다.

1주차 커뮤니티는..

미션 문제, 요구 사항과 관련한 질의 응답들이 많았는데, 이는 미션을 진행하는 기간 동안은 논의해서는 안 되는 부분이라고 하셨다. 요구 사항을 이해하는 것은 재차, 스스로 고민해보고 해결해야 하는 문제라 강조하셨다. 그리고 테스트 케이스를 작성하여 공유한 분들이 많았는데, 이는 문제에 대한 해답을 코드 레벨로 공유하는 것과 동일하기 때문에 이 또한 지양해야 하는 부분이다.

해당 주차의 미션에 대해서는, 미션 기간이 끝난 후 PR을 통해 다른 사람이 작성한 코드들을 확인할 수 있기 때문에 복습하는 용도로 사용하도록 하자.
프리코스의 핵심은 요구사항을 내가 스스로 고민하고 작성해 나가는 과정을 훈련하는 것이기 때문!
최종 코딩테스트를 위해 나 스스로의 역량을 기르도록 하자.

신뢰 기반의 커뮤니티

코치들이 제안 하고 싶은 것은, 스스로 자기주도적으로 학습할 수 있는 과정을 방해하지 말자는 것이라 하셨다.
커뮤니티가 활성화된 Slack에서도, 앞으로 사용하게 될 Github Discussion에서도, 스스로 할 수 있는 것을 방해할 만한 컨텐츠에는 눈알 이모지를 다는 것으로 통일하자고 제안하셨다. 기존에 있던 질의응답 채널, 테스트케이스, 깃헙 이슈 등의 채널은 자발적으로 폐쇄하고, 앞으로는 해결하지 못하는 문제에 대해서는 스스로 구글링하며 스스로 고민하여 답을 찾는 과정을 겪도록 하자.
그리고 피어 코드 리뷰는 Github Discussion 에서 진행하도록!

즉 결론, 커뮤니티 활동을 제한하는지의 기준은 스스로 학습하는데 방해가 되진 않는가? 이다.

프리코스 커뮤니티 기능들

5기 프리코스 커뮤니티 (Github Discussions)
프리코스 커뮤니티란 무엇인지?

Github Discussion 공간에서 활용할 수 있는 기능들은 다음과 같다.

1. 피어 리뷰
마감한 미션에 대해서, 서로에게 코드 리뷰를 해줄 수 있는 공간

2. 아고라
토론 또는 질의응답 커뮤니티
흥미 있는 주제가 있다면 발제하여, 댓글을 달아 서로의 의견과 경험, 생각을 주고받는 토론의 장으로 활용


3. 학습 컨텐츠 공유
본인이 학습한 내용, 회고, 도움 될만한 자료들을 함께 공유
스터디도 만들 수 있다.

---

 

그리고 2주차의 미션은?

2주차 미션을 알려주는 메일이 도착하여 1주차와 2주차 미션의 목표를 확인하였다.


1주 차 미션의 목표는

1) git 사용
2) 과정별 언어 (Java)
3) 미션 사이클

에 익숙해지는 것이었다고 한다.
그리고 1주차 미션의 공통 피드백 문서를 주셨다. 꼼꼼히 읽어 2주차 미션을 준비해야 되겠다.


2주차 미션의 목표는

1. 함수를 분리하는 것
2) 각 함수별로 테스트를 작성하는 것

이다.

스스로 학습해야 할 부분은 테스트 도구, 그리고 작은 단위의 기능부터 테스트를 작성하는 방법이다.

---

 

테스트 코드가 왜 중요한가?

코치분들이 중간에 테스트 코드가 무엇이며, 이것이 왜 중요한지에 대해 설명을 해주셨다.

앞으로의 미션을 통해서는 메서드들을 더 많이 구현해야 될텐데 메서드들을 역할에 따라 분리하는 연습과 더불어
테스트 도구에 익숙해지는 과정을 학습했으면 한다고 하셨다. 테스트 코드 작성은, 단순히 코드를 테스트하는 것 뿐 아니라 작성하는 과정 자체에서 굉장이 유용한 부산물로 남기 때문에 매우 중요한 과정이다.

켄트 백의 TDD
테스트 코드의 본질적인 핵심은, 내가 어떤 코드를 작성해야 겠다는 결정과, 피드백 사이의 갭을 인식하고 조절할 수 있는 테크닉이라고 한다. 즉, 작성하려는 코드에 대해, 테스트 코드를 통해 빠르게 피드백을 받을 수 있는 것이 테스트 코드의 핵심이며 장점이다.

따라서 기능 목록을 작게 쪼개면, 테스트 하기도 쉬워진다. 한 두줄만의 코드로, 핵심 기능을 구현하는데 잘 해내가고 있음을 느끼며 효능감을 느낄 수 있는 순간이 올 것이라 한다. 테스트 도구와 테스트 코드 덕분에 더 안정적으로 코드를 짜 나갈 수 있으며, 코드를 작성하는 과정에서 스스로 피드백을 얻을 수도 있다.

그리고 테스트 코드를 통해 나 뿐 아니라 다른 동료들, 그리고 일주일 뒤, 한 달 뒤 미래의 내가 볼 때 작성했던 코드를 잘 이해할 수 있도록 돕는 유용한 부산물이 될 것이다. 이 테스트 코드를 통해 훨씬 더 즐겁게 코딩할 수 있을 것으로 기대한다.