🤯: 이건 이렇게 판단하고, 저렇게 설계하고, 구현하려면 이 기능을 써야되는데 레퍼런스는 여기고, 테스트 케이스를 이렇게 만들어서 돌려봤더니 어떻고…
1. 베이직 과정을 완수하고, 내게 맺힌 ‘기본’이라는 열매들
❗
본문에서 언급하는 예시는 베이직 과정의 내용이 유출되지 않도록 실제 경험을 바탕으로 각색한 것이므로 부스트캠프 베이직 과정에서 제시된 문제들과는 연관이 없다.
기본. 개발에 있어서 기본이란 무엇일까?
프로그래밍 언어의 기초 문법을 알고, 코드를 작성할 수 있는 정도의 실력?
스트림, 멀티스레드 등의 고급 기술을 아는 것?
베이직 과정을 마치고, 우매함의 봉우리 정상으로 점점 달려가고 있는 내 입장에서 기본이란 무엇인가에 대해 말해보자면… (이하 n번 째 열매들에서 설명한다).
1.1. 첫 번째 열매: 문제 너머를 바라볼 수 있는 시각
❗
문제에 명시된 것들만 그대로 받아들이지 말자. 문제는 참고 자료일 뿐, 애매한 부분들은 내 스스로 가정하고 판단하자.
베이직 과정 초반부만 하더라도 나는 굉장히 수동적으로 ‘문제 푸는 것에만 집중’을 했다.
음, 이런 상황에서는 이렇게 하라고? 좋아. 구현해보지.
아, 그런데 저런 상황에서는 저렇게 하라고? 좋아. 그것도 구현하지.
좋아, 하라는 거 다 했다. 오늘 미션 끝!!
❓
자, 여기서 문제!
나는 미션을 잘 완수한 것일까? 다음 보기 중에 골라보자.
<보기>
아니다.
아니다.
아니다.
아니다.
자, 정답은 ~~~~ 두구두구두구두구. 아니다였습니다!!! 👏👏👏
부스트캠프의 과제들은 모두 애매한 구석을 하나쯤 가지고 있었다.
예를 들어 “사용자 인증 기능을 구현하라”는 큰 틀과 “사용자로부터 아이디와 비밀번호를 입력받고, DB에 저장된 정보와 일치하는 경우에만 로그인이 성공하도록 하세요” 정도의 요구사항은 문제에서 주어지지만, 무엇을 얼마나 어떻게 인증할 것인가에 대해서는 온전히 내가 판단할 몫이었다.
실제로 다음과 같은 추가적인 고려사항들을 스스로 도출해내고, 적당한 논리와 근거로 판단 후에 구현한다면 꽤나 탄탄한 구현이라고 할 수 있겠다.
사용자가 지속적으로 인증을 실패한다면, 이를 비정상적인 접근으로 판단하자.
사용자가 3회 연속 실패시 ‘5회 연속 실패시 ~와 같은 제한 조치가 적용됩니다.’라는 문구로 미리 경고하자.
5회 연속적으로 실패시 계정 락을 걸고, 가입시 작성했던 휴대폰 번호 또는 복구 이메일을 통해서만 락을 해제할 수 있도록 하자.
단순히 비밀번호를 까먹은 사용자가 아니라, 해커의 소행일 수 있으니 접속 지역과 시간대, IP를 기록한 후 해당 사용자의 복구 이메일로 경고 메일을 보내자.
사용자가 입력한 비밀번호가, 최근 변경하기 전의 비밀번호라면 ‘해당 비밀번호는 x개월 전에 변경되었어요’라는 알림 메시지를 주자. (구글에서는 실제 이렇게 한다.)
접속에 성공했더라도 사용자가 이전에 접속하던 지역과 크게 차이가 나는 지역(해외 등)에서 접속한 것이라면, 접속 직후 추가적인 2차 인증을 요구하도록 하자.
이처럼 주어진 문제를 스스로 재정의하는 과정을 통해 문제 자체를 더 논리적으로 해결하고, 그 너머의 사용자 편의성과 발생 가능한 위험 요소까지 생각할 수 있는 시각과 그에 대한 대처하는 법을 훈련할 수 있었다.
1.2. 두 번째 열매: 복잡해보이는 큰 문제를 잘게 쪼개는 기술
❗
기능을 세부적으로 분류하자.
‘회원가입 기능 구현하기’라는 큰 문제가 주어졌다고 하자.
과거의 나는 이런 큰 문제가 주어졌을 때 문제를 하나의 덩어리로만 바라보고 해결하려고 했다.
그러다 보니 ‘회원가입에 필요한 정보는?’, ‘나이 제한이나 보호자 인증은?’, ‘아이디 중복은 없을까?’, … 등의 생각들이 얽혀서 꼬여버리기 일쑤였다.
그런데 베이직 과정을 마음껏 즐기고 완주하겠다는 마음으로 ‘문제를 제대로, 잘 해결하기’라는 목표를 위해 노력하니 나도 모르게 문제를 잘개 쪼개서 단계별로 구현하고 있더라.
내 사고 흐름이 이렇게 꼬이도록 두지 말고, 작은 단위로 하나씩 쪼개면서 정의하다 보면 어느새 논리적으로 정돈된 모습을 확인할 수 있다.
아이디 중복 확인
비밀번호 암호화
이메일 형식 유효성 검사
모든 필드 입력 여부 확인
가입 성공 시 데이터베이스 저장
성공/실패 결과에 따른 UI 피드백
이렇게 세부 기능들로 쪼개고, 모듈화 시켜서 구현한다면 다음과 같은 이점들이 생긴다.
단위 테스트를 통해 각 기능을 빠르게 검증할 수 있다.
최종 구현에서 각 기능들을 호출할 때 문제가 생긴다면, 어떤 기능이 문제인지 빠르고 명확하게 확인이 가능하다.
어떤 기능을 수정해야 될 때, 해당 기능의 세부 로직만 변경하면 된다. 다른 기능들에서는 변경 사실을 몰라도 된다.
1.3. 세 번째 열매: 객체에게 적절한 책임만을 주는 판단력
❗
객체가 가지는 ‘책임’의 범위를 명확히 하라. 책임을 벗어나는 경우에는 그 책임을 가질 새로운 객체를 만들어라.
부스트캠프 이전에 OOP에 대해 학습하면서 단일 책임 원칙(SRP)에 대해서는 어느 정도 학습을 하고, 예제 코드도 작성해봤다.
하지만 평화로운 예제 코드 작성과 ‘실제 문제를 맞닥뜨린 상황에서의 코드 작성’은 결코 동일한 판단력으로 진행할 수가 없다.
문제가 주는 압박감에 정신을 놓고 개발하다 보면 어느샌가 내가 만든 User 클래스는 문제 해결을 위한 모든 일을 스스로 수행할 수 있는 클래스가 되어 있었다.
이렇게 막무가내로 구현을 끝내놓고 조금은 편안한 마음으로 내 코드를 다시금 보면 “내가 만든 User는 유저가 아니라 전지전능한 God인데?”라는 생각이 들더라.
이렇게 내 스스로 리뷰를 하면서 게시글과 관련된 로직은 PostService 클래스를 새롭게 만들어서 책임을 부여하고, 주문과 관련된 로직은 OrderService 클래스를 새롭게 만들어서 책임을 위임하는 등의 ‘객체지향스러운’ 리팩토링을 어느정도 할 수 있었다.
1.4. 마지막 열매: 개발에 한정되지 않는, 인생 그 자체에 적용할 수 있는 Core
❗
나는 부스트캠프에서 ‘개발’에 대해 배운 것이 아니라고 생각한다.
결국 내가 배운 것은 나이, 성별, 직무와 관계없이 누구나 인생을 살다 보면 마주하는 상황의 타개책, ‘문제를 해결하는 법’이다.
그리고 이 모든 것을 가능하게 한 것은 ‘몰입력’이다.
베이직 과정에서 절실히 느낀 점은 “이전에 내 스스로 정한 학습량은 정말 별 것도 아니었구나” 였다.
부스트캠프는 매일매일 내게 ‘미션’이라는 큰 파도를 준다. 이 파도를 어떻게 헤쳐 나갈지는 온전히 내 선택이다.
제트스키(ai)의 도움을 받아 단시간에 주파할 수도 있으며, 능숙하게 헤엄치기 어렵다면 바닥을 짚거나 튜브를 끼고 천천히라도 나아갈 수 있다.
(얼마나 노력할지는 내 스스로에게 달렸다. 그 누구도 나태해진 나를 멱살잡고 끌어주지 않는다.)
누군가 나에게 “이런 다양한 방법 중에서 무엇이 좋은가?” 라고 묻는다면, 단연코 이렇게 얘기할 것이다.
바닷물을 배 터지게 먹게 되더라도 나의 두 다리와 어깨를 마음껏 움직이며 파도를 즐겨라.
(정말 다행이게도 부스트캠프에서의 파도에는 식인 상어나 독성 해파리는 존재하지 않으며, 아무리 물을 먹거나 물 속에 잠기더라도 죽을 위험이 없다.)
내 경우에는 자바에 어느 정도 익숙했던 터라 ‘개헤엄 정도는 칠 수 있는’ 정도라고 할 수 있겠다. 그래서 나는 일단 개헤엄(내가 아는 지식)으로 파도를 한번 훑고, 접영과 배영 등에도 도전(구글이나 유튜브에서 레퍼런스를 참고)하며 파도가 내 침대처럼 편해지도록 연습했다.
이렇게 파도1에서 개헤엄에 만족하지 않고 접영과 배영도 가까스로 해냈다면, 다음 날 파도2에서는 나도 모르게 접영과 배영이 자연스러워지는 경험을 했다.
결국 인간은, 몸소 부딪힐 때 가장 가파르게 성장할 수 있다.
부스트캠프가 주는 파도를 즐기다 보면 나도 모르게 점심도 거른 채 집중하고 있었고, 이런 몰입의 상태에 들어가는 것을 2주동안 반복하며 훈련할 수 있었다.
사실 기말고사가 끝나고 조금 나태해져서 개인적인 공부를 하던 중에 자꾸 핸드폰을 확인하게 되는 등 스스로도 집중력이 떨어졌다는 것을 인지하고 있었는데, 베이직 과정을 시작하면서 산만한 나는 사라지고 하루종일 파도 속에서 놀고 있는 내가 되더라!
베이직 과정에서 문제 해결력 외에도 얻어간 것이 있다면, 눈 앞의 상황에 집중할 수 있는 몰입력이다!
2. 베이직에서 잘 성장하려면
❗
베이직 과정을 경험하며 힘들었던 점, 아쉬웠던 점을 중심으로 ‘새롭게 베이직 과정에 도전하려는 분들’을 위한 저만의 조언을 전달해요!
2.0. 어느 정도의 제약을 스스로 만들고 지키자
베이직 과정의 경우에는 코어타임*이 존재하지 않아요. 따라서 언제 시작해서, 얼만큼 열심히 하고, 언제까지 고민할 지 등은 모두 본인의 선택에 달렸어요.
*동료와의 실시간 소통, 개인 학습 등을 위해 반드시 참가해야 되는 시간대
이런 자유로움으로 인해 “나는 새벽형 인간이니까~” 등의 이유로 미션 시작을 뒤로 미룬다거나 “하루종일 공부하면 오히려 머리가 굳어~”라는 생각으로 베이직 과정에 여유롭게 임하게 되기가 쉬운데요.
제가 말씀드리고 싶은 점은 “그럼에도 불구하고 부스트캠프 측에서 권장하는 시간대는 존재한다”는 것이에요!
기본적으로 권장 시간대에 미션에 몰입하면 남들과 함께 하고 있다는 소속감과 더불어 동료들 간의 피드백 시간에서도 활발한 소통을 할 수 있는 기회가 많아져요.
제 경우에도 첫 날에는 미션에 대한 감이 제대로 잡히지 않아서 스스로 만족스러운 수준이 될 때까지 미루다가 늦게 제출을 했는데요.
이후 동료들의 코드를 리뷰하다 보니 내가 몰랐던 사실들을 더 빠르게 습득할 수 있었어요.
첫 작품을 완벽하게 만들어내겠다는 강박을 떨친다면, 함께 하는 동료들의 도움으로 이미 만든 내 작품을 더 탄탄하게 보강할 수 있을 거예요!
결론적으로 하고 싶은 말은 다음과 같아요.
완벽한 구현에만 매몰되지 말고 피어 리뷰나 제출 후 스스로의 코드를 개선하기 등 추가적인 작업을 위한 시간을 따로 배정해두고, 이를 지키려고 노력하자.
2.1. 단순히 구현이 전부가 아니다
베이직 과정에서는 평일동안 매일 새로운 문제를 마주해요. 하지만 우리가 할 일은 단순히 ‘구현’에만 그치지 않아요!
“이러이러한 것들을 하세요~”라고 엄격히 요구되는 바는 없지만 다음과 같은 활동들을 하면 좋다고 생각해요.
구현 과정
아래 과정들을 본인 머릿속에서만 진행하지 않고, 동료들이 내 사고 흐름을 읽고 피드백할 수 있도록 논리적으로 서술할 줄 알면 좋아요!
문제 해결을 위해 필요한 내용 학습
요구사항 분석, 문제 설계
구현
동료들과의 상호 피드백
서로의 구현 과정을 읽으며 자유로운 피드백을 진행
개선하기
상호 피드백이나 이후의 추가 학습 등을 통해 알게된 내용을 이용하여 이전 미션에 대한 구현을 개선하기
2.2. 판단은 모두 내가 한다
문제를 단순히 읽는 것만으로는 구현에 필요한 모든 정보를 얻을 수 없어요. 문제에서 얘기하는 사실들에만 얽매이지 말고, 스스로 생각하고 판단하면 더 탄탄한 논리 구조를 갖출 수 있어요.
문제에서 발생할 수 있는 케이스를 분류하고, 각 케이스마다 다른 규칙이 존재하지 않는지 확인해요.
문제에서 명시된 논리적 규칙이나 제약 등을 토대로, 언급되지는 않았지만 논리적 흐름에 의해 그럴 수밖에 없는 새로운 사실들을 정리해요.
본인의 구현이 제대로 되었는지 확인할 수 있는 다양한 테스트케이스를 만들어봐요.
2.3. 문제를 쪼개자
우리는 결론적으로 주어진 하나의 문제를 해결하는 것이 목표이지만, 결국 그 문제는 여러 개의 세부 문제로 구성되어 있는 경우가 많아요. 자세한 내용은 위 1.2. 에서 언급했던 내용을 확인해주세요!
.png%3Ftable%3Dblock%26id%3D22a3a35c-b1a1-807b-963f-cb565b204772%26cache%3Dv2&w=1920&q=75)
