타입스크립트 핸드북(한글) 링크

 

타입스크립트 핸드북

 

joshua1988.github.io

주의 깊게, 다시 볼 부분

  • 여러 인터페이스를 상속받는다는데 두 번째 예시에서 왜 Developer는 Person만 extends하는가? -> Drinker가 그냥 빠진 것이었다니!
 

인터페이스 | 타입스크립트 핸드북

인터페이스 인터페이스는 상호 간에 정의한 약속 혹은 규칙을 의미합니다. 타입스크립트에서의 인터페이스는 보통 다음과 같은 범주에 대해 약속을 정의할 수 있습니다. 객체의 스펙(속성과 속

joshua1988.github.io

  • 딱 와닿게 이해되지 않는 제네릭 부분... 두 번 더 봐야겠다.
 

제네릭 | 타입스크립트 핸드북

제네릭(Generics)의 사전적 정의 제네릭은 C#, Java 등의 언어에서 재사용성이 높은 컴포넌트를 만들 때 자주 활용되는 특징입니다. 특히, 한가지 타입보다 여러 가지 타입에서 동작하는 컴포넌트를

joshua1988.github.io

  • 순차적으로 코드를 깔끔하게 정리하는 과정이 너무나 인상깊었다.
 

맵드 타입 | 타입스크립트 핸드북

맵드 타입(Mapped Type)이란? 맵드 타입이란 기존에 정의되어 있는 타입을 새로운 타입으로 변환해 주는 문법을 의미합니다. 마치 자바스크립트 map() API 함수를 타입에 적용한 것과 같은 효과를 가

joshua1988.github.io

  • 모듈 부분은 (연습이든, 아니든) 실제로 프로젝트에 적용할 때 다시 한 번 찾아봐야 할 것 같다.
 

모듈 | 타입스크립트 핸드북

소개 타입스크립트에서 가리키는 모듈이라는 개념은 ES6+의 Modules 개념과 유사합니다. 모듈은 전역 변수와 구분되는 자체 유효 범위를 가지며 export, import와 같은 키워드를 사용하지 않으면 다른

joshua1988.github.io

오늘 한 일

  • 어제 오후부터 회원가입과 로그인 절차에 대한 전체적인 테스트를 (혼자) 해보고 있었는데, 퇴근 직전부터 회원가입 페이지에서 이메일을 입력하면 날아오는 인증메일이 발송되지 않았다. 회원가입 페이지를 완료한 지가 며칠이 지나서 그동안은 확인해볼 일이 없었는데 오랜만에 해보니 갑자기 안되는 것이었다. 메일은 오지도 않고 콘솔창에는 "Email address is not verified. The following identities failed the check in region US-EAST-1: id@email.address"라고 에러 메시지가 찍히는데 이것만 보고는 무슨 상황인지 이해할 길이 없었다. 구글링해봐도 다들 나와는 다른 상황인 것 같고 별로 참고할 만한 내용이 없었다. 무슨 에러인지 알고 나서야 뒤늦게 스택오버플로우에 있던 해결책이 보였다.
  • 사용자 인증을 AWS cognito를 통해 처리하고 있다. cognito에서 인증메일을 보내는 방식은 cognito 자체에서 보내주는 디폴트 설정과 AWS SES를 통해서 보내는 설정, 두 가지 중 선택할 수 있다. 처음에는 디폴트 설정으로 진행했었는데, 그러면 발신 주소가 no-reply@verificationemail.com이라는 별로 예쁘지 않은 걸로 자동 설정된다. 이사님이 이걸 좀 더 보기 좋은 계정으로 바꾸려고 하셨는데, 이 FROM email address를 바꾸려면 반드시 디폴트가 아닌 AWS SES를 이용해야 하기 때문에 이 설정을 바꾸셨다.
  • 디폴트로 설정을 돌려놓으면 다시 인증메일이 제대로 오기 시작하고, AWS SES만 선택하면 다시 에러가 떴다. 에러 메시지에 나온 것처럼 이메일 주소를 확인되게 하려면 AWS SES의 해당 리전에 접속해서 직접 처리해야 한다. 처리한 후에는 확인한 이메일 주소에 인증메일을 보낼 수 있게 된다.
  • 하지만 여기서 문제: 회원가입을 하고 싶어하는 사용자가 입력하는 사용자의 이메일 주소인데, 그리고 이건 불특정 다수에게 발송될 메일인데, 이 메일을 받을 그 모두의 이메일 주소를 등록해야 한다고? 그럴 리가 없다.
  • 이 문제의 근본적인 원인은, AWS SES를 처음 사용하면 계정이 샌드박스에 들어간다는 데 있었다. 누구에게 어떤 메일을 보낼지 알 수 없는 AWS 입장에서는 콘솔에서 인증 처리를 거치지 않은 이메일 주소에는 어떤 메일도 발송할 수 없게 제한해둔 것이었다. 물론, 메일을 보낼 발신자의 주소 역시 인증을 거쳐야 한다.
  • 한 마디로, 인증메일에서 no-reply@verificationemail.com이 발신자 주소로 찍히는 게 보기 싫어서 이 주소를 바꾸고자 한다면 반드시 AWS SES에 연결하고 + AWS SES 계정을 샌드박스에서 나가게 해야 한다. 여기에까지 이르느라 시간을 얼마나 썼는지

오늘 배운 것

  • 내가 맞닥뜨린 오류는 아래 링크에서 'Email address is not verified' 부분에 해당한다.
 

Amazon SES 이메일 전송 오류 - Amazon Simple Email Service Classic

Amazon SES는 여러 AWS 리전에 엔드포인트가 있으며 이메일 주소의 확인 상태는 AWS 리전마다 서로 다릅니다. 사용하려는 AWS 리전에서 각 발신자에 대해 확인 프로세스를 완료해야 합니다.

docs.aws.amazon.com

  • '이메일 계정 구성' 또는 '사용자 풀에 대한 이메일 구성' 항목에서 2단계(Amazon SES 샌드박스에서 계정 이동)를 참고하면 좋다.
 

Amazon Cognito 사용자 풀의 이메일 설정 - Amazon Cognito

이러한 단계에서 생성하는 리소스는 AWS 계정에서 공유할 수 없습니다. 예를 들어 사용자 풀을 구성한 한 계정을 다른 계정의 Amazon SES 이메일 주소로 사용할 수 없습니다. 여러 계정에서 Amazon Cogn

docs.aws.amazon.com

  • AWS SES에서 메일 주소 확인 처리를 할 때 참고하면 좋다.
 

Amazon SES에서 확인된 자격 증명 - Amazon Simple Email Service

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

  • 마지막으로, 이 모든 상황을 전부 파악하고 나서야 찾았던 스택오버플로우. 아는 만큼 보인다 했던가.
 

Email address is not verified (AWS SES)

I want to use Amazon's Simple Email Service to send emails. I verified my domain as well as the email address I want to send from. For both it says verified. Now when I use the Send Test Email f...

stackoverflow.com

오늘까지 한 일

  • 일이 엄청 많거나 너무 바쁜 건 아닌데, 그렇다고 하루하루 하는 일이 차근히 정리되고 있는 것 같진 않다. 사이트 개편 앞두고 일종의 마무리 작업 중이라서 그런 건지, 항상 느끼는 거지만 마치 깔끔하게 치워놓은 방이 어질러지듯이 처음엔 시작이 얼마나 정돈되었든 뒤로 갈수록 '일단 하고 본다'는 식의 임시방편성 코드가 많아지게 된다. 내 코드 내가 읽어도 정신이 하나도 없다.
  • 하루종일 허둥대며 코드를 짜다 보면 퇴근하고 나서는 생산적인 일은 별로 하고 싶지 않다. 그래서 요 며칠 TIL도 안 남기고 아무런 의미 없는 시간을 보냈는데, 또 다른 분들 글을 읽고 나면 나는 지금 뭐하나 싶다. 잠깐 해찰하며 여유를 가졌던 것에 만족해야겠다. 슬슬 다시 힘을 내야지.
  • 오늘은 동영상 인코딩 처리를 위한 큐를 구현하는 데 (완벽하게 성공했다고 장담할 수 없지만) 어떤 방법을 써야 할지 고민하면서 찾아봤던 반복문 사용의 차이점을 링크로 건다.

오늘 배운 것

  • for ... in 반복문에 대한 링크. for ... in 을 통해 직접적으로 가져올 수 있는 건 객체의 key-value 중 key이다. 객체의 요소들을 순서대로 가져온다는 보장이 없으므로 인덱스가 중요한 배열 등에 사용하는 것은 권장되지 않는다.
 

for...in - JavaScript | MDN

The for...in statement iterates over all enumerable properties of an object that are keyed by strings (ignoring ones keyed by Symbols), including inherited enumerable properties.

developer.mozilla.org

  • for ... of 반복문은 문자나 배열에 사용한다. 배열 안의 요소 자체를 가져온다. 아래 링크에 예시 코드와 함께 for ... in 과 for ... of 의 차이점이 잘 정리되어 있다. 나중에 다시 한번 읽어봐야 할 것 같다.
 

for...of - JavaScript | MDN

The for...of statement creates a loop iterating over iterable objects, including: built-in String, Array, array-like objects (e.g., arguments or NodeList), TypedArray, Map, Set, and user-defined iterables. It invokes a custom iteration hook with statement

developer.mozilla.org

  • 반복문들의 차이점에 대해 "한글로" 잘 정리해둔 곳을 찾았는데 뭐가 문제인지 모르겠지만 지금은 안 열린다(?!) 혹시 나중에 잘 뜰지도 모르니 일단은 저장..

https://jsdev.kr/t/for-in-vs-for-of/2938

 

오늘 한 일

  • 사실 Amplify를 연계한 로그인, 회원가입 페이지 작업은 지난 주에 끝냈지만... 오늘은 동영상 인코딩 문제 때문에 하루종일 씨름만 하고 성취해 낸 건 딱히 없는 기념으로 뒤늦게 가져와 봤다. 아니 그나저나 도대체 왜 어떤 mov는 인코딩 속도가 느려?!
  • AWS Amplify 문서는 정말 너무 깔끔하고 너무 좋다. 괜히 자꾸 읽고 싶고 정독해야 할 것 같고 다른 키워드도 다 클릭해봐야 할 것 같고 저 오렌지 색도 예쁘고 막... 어제 올린 멀티파트 업로드 쪽 문서가 Amplify의 반만 됐어도 그렇게까지 애먹지는 않았을 텐데, 같은 AWS여도 워낙 서비스가 다양해서인지 참 다르다.

오늘 아니고 그때 배운 것

  • 지난 번에도 올렸던 링크다. 그때는 sign in/out만 구현했었고, 이번에는 sign up까지 완료했다. 아무래도 회원가입 페이지가 로그인보다는 만들 게 많으니까 뒤로 미뤘었다. 그리고 Amplify에서 제공하는 UI components를 사용하면 더욱 간단했겠지만, 무엇보다 뷰 자체는 회사 기획안에 맞추다 보니 시간이 좀 더 걸렸다.
 

https://docs.amplify.aws/lib/auth/emailpassword/q/platform/js/

 

docs.amplify.aws

  • 이건 로그인 화면 어딘가에 위치한 '비밀번호 찾기'에서 쓰이는 함수를 포함한 부분이다.
 

https://docs.amplify.aws/lib/auth/manageusers/q/platform/js/

 

docs.amplify.aws

  • 근데 문제는 이 공식문서에서 소개하는 함수들을 그대로 사용하다 보면, 회원가입 절차가 [아이디(이메일), 비밀번호 입력 -> 회원가입 -> 입력한 이메일로 인증번호 발송 -> 인증번호 입력하면 회원가입 절차 완료] 이런 식으로 가게 된다. 하지만 기획안대로라면 [아이디(이메일) 입력 -> 입력한 이메일로 인증번호 발송 -> 인증번호 입력해서 확인되면 비밀번호 입력 -> 회원가입] 순서여야 한다. 인증 메일은 회원가입이 되고 난 후에나 보내주는 것인데, 우리는 가입을 완료하지 않은 시점에서 이메일만 우선적으로 확인하고 싶은 것이다. 회원가입 절차 자체를 커스터마이징 해야 하는 거라 이건 추후 Lambda Trigger를 활용하거나 해야 할 것 같다. 아직은 안 해봄
 

Pre Sign-up Lambda Trigger - Amazon Cognito

If an alias with the same phone number already exists, the alias will be moved to the new user, and the previous user's phone_number will be marked as unverified. The same is true for email addresses. To prevent this from happening, you can use the user po

docs.aws.amazon.com

오늘 한 일

  • 지난 주에도 뭔가 많은 걸 해내서 뿌듯했던 것 같은데 기록을 남기지 않았더니 기억이 안 난다. 이번 주부터는 그러지 맙시다...ㅠㅠ
  • 오늘은 지난 주 후반부터 작업한 AWS S3에 멀티파트 업로드하는 코드에, 업로드 진행상황을 알려주는 프로그레스바를 붙이는 작업을 했다. 프로그레스바 작업은 딱히 참고한 문서나 링크 없이 한 거라 별 게 없다. progress를 useState로 관리하고, progress의 setter 함수를 멀티파트 업로드 함수에 인자로 넘겨서 그 안에서 업로드 상황에 따라 progress를 설정하게끔 했다. 5MB 단위로 분할하게 해 놨기 때문에, 파일 전체 크기를 1024 * 1024 * 5로 나눈 후 그걸로 다시 100을 나눠서 파트 하나당 몇 %를 먹는지 계산하고, 그걸 그대로 progress에 넘겨서 프로그레스바의 너비로 지정해주었다. 뭔 소리..
  • AWS S3 멀티파트 업로드를 공부하며 애먹었던 가장 큰 이유는, 일단 AWS 사이트 내에 산재된 수많은 사용설명서들 중에 어떤 게 가장 직접적으로 큰 도움을 줄지 알 수 없었던 것이었다. 자꾸 아래에 레퍼런스라면서 다른 링크가 걸려 있는데 들어가보면 너무 예전 링크인 것도 있고, 딱히 별 도움이 안 되는 이론만 적혀 있는 것도 있고, 아까 봤던 링크를 다시 걸어놓은 것도 있었다. 혹시 나중에 또 멀티파트 업로드를 시도할 일이 있을까 봐 미래의 나 분명 삽질하고 있을 테니 그만하고 보라고 가장 도움 되었던 링크를 아래 붙인다.

오늘 배운 것

  • AWS S3 기본 사용설명서 링크. 영어로 보다가 속도가 안 나서 손절하고 한국어로 갈아탔다.
 

멀티파트 업로드를 사용한 객체 업로드 및 복사 - Amazon Simple Storage Service

멀티파트 업로드의 시작 및 완료 중간에 전송된 다른 요청을 우선 수행할 수 있습니다. 예를 들어, 특정 키를 사용하여 멀티파트 업로드를 시작한 후 업로드가 완료되기 전에 다른 작업에서 해

docs.aws.amazon.com

  • 위 링크를 통해 멀티파트 업로드가 어떤 원리로 돌아가는지 알게 되었다면, 그 다음은 SDK 문서를 보면 된다. 이게 가장 도움이 많이 되었는데 개인적으로는 가장 찾기 어려웠다. SDK로 제공하는 모든 함수들이 예제 코드와 함께 자세히 나열되어 있다.
 

S3 Client - AWS SDK for JavaScript v3

@aws-sdk/client-s3 Description AWS SDK for JavaScript S3 Client for Node.js, Browser and React Native. Installing To install the this package, simply type add or install @aws-sdk/client-s3 using your favorite package manager: npm install @aws-sdk/client-s3

docs.aws.amazon.com

  • 위 링크에 함수들이 있는 건 알겠는데 혹시 언제 어떤 함수를 써야 할지 헷갈린다면 이걸 보면 좋다. 여긴 한국어 지원이 안 된다.
 

CreateMultipartUpload - Amazon Simple Storage Service

After you initiate a multipart upload and upload one or more parts, to stop being charged for storing the uploaded parts, you must either complete or abort the multipart upload. Amazon S3 frees up the space used to store the parts and stop charging you for

docs.aws.amazon.com

  • 실제로 AWS SDK를 이용한 멀티파트 업로드로 동영상을 업로드한 코드를 올려놓은 블로그. 멀티파트 업로드는 말 그대로 업로드 과정만 지원하기 때문에 파일은 업로드하기 전에 알아서 분할을 해야 하는데, 파일을 분할한다는 게 감이 잘 안 잡혀서 조금 헤맸었다. 파일 분할하는 부분이 특히 참고할 만했다.
 

Upload Videos to Amazon S3 from the browser using React, Cognito and aws-sdk in multipart upload

I will help you out with the quickest and easiest way to upload videos files in multipart upload on AWS using React.

medium.com

 

들어가며

 

지금으로부터 5개월 전만 해도, 엄두도 내지 못하고 꿈에서조차 상상하지 못했던, 개발자로서 취업을 한 지 어느덧 한 달이 지났다. 시간은 시속 [현재 나이]km로 간다지만 지나는 속도가 빨라도 너무 빠르다. 이제는 회사로 출근하는 일상에 어느 정도 적응하기도 했고, 고맙게도 내 인생의 전환점이 되어 준 항해99에 대해 최종적으로 돌아보고 정리하는 시간을 가져보려고 한다.

 


- 목차 -
1. 항해99 지원 과정
2. 사전 준비: 첫 발을 떼기 위한 워밍업
3. 실전 프로젝트: 항해99의 꽃이자 최종 보스
4. 취업: 새로운 시작

 

항해99 지원 과정

 

처음부터 취업을 목적으로 항해99에 참여했던 건 아니었다. 돌이켜보면 코딩의 세계에 발을 들여놓게 된 맨 처음 시작점은 스파르타코딩클럽의 5월 가정의 달 이벤트에 참여하면서부터였다. 인스타그램 광고를 나도 모르게 클릭한 후 스파르타코딩클럽에서 제공하는 추억소환코딩패키지 강의를 수강하게 되었고, 인생 처음으로 HTML과 CSS를 이용해 웹페이지를 제작하고 배포해보는 경험을 했다. '요즘은 애들도 학교에서 코딩을 배운다는데 나는 코딩의 ㅋ도 모르는 게 말이 되나'로 시작했는데, 코딩이라는 건 생각보다 재미있었다.

이 다음 과정을 배우고 싶으면 무슨 강의를 들어야 하는지 찾아보다가 30만원짜리 웹개발종합반 과정을 찾았다. 그리고 항해99라는 부트캠프에 참여하면 부트캠프 시작 전 2주의 사전 준비 기간에 그 웹개발종합반 강의를 무료로 수강할 수 있었다. 비록 400만원이라는 참가비가 발생한다는 함정이 있었지만 99일간의 커리큘럼을 살펴보고 나니 구미가 당겼고, 본격적으로 공부해볼까 싶었다. 마침 2기 수강생을 모집하고 있어서 유튜브 라이브로 진행되는 설명회를 시청하고 나서 지원서를 넣었다.

지원서를 제출하고 며칠 지나지 않아 스파르타코딩클럽에서 전화가 왔다. 면접 일정을 잡는 전화였는데, 어쩌다 보니 서로 나누는 이야기가 길어졌다. 지원서에도 써내긴 했지만 지원동기를 다시 물어보기에 '재미있는 일을 직업으로 삼고 싶다, 아직 개발자로서의 취업을 고려하는 건 아니지만 항해99가 내 적성에 맞는 일을 찾아가는 과정이 되었으면 좋겠다'는 취지로 말했다. 30분이 넘는 통화에서 나는 내 적성에 개발이 맞을 것 같다는 얘기를 들었고, 굳이 화상 면접을 보지 않아도 되겠다고, 나는 항해99에서 찾는 "좋은 개발자"가 될 수 있는 사람이라는 말도 들었다. 사전 준비 과정에서 웹개발종합반 과정을 듣고 항해99의 본격적인 커리큘럼이 시작하기 전에 중도포기한다고 하더라도 웹개발종합반 수강료만 제외한 나머지는 환불 받을 수 있다는 얘기도 들었다. 덕분에 더욱 가벼운 마음으로 시작할 수 있게 되었다. 아무튼 결과적으로 화상 면접은 패스했고 바로 사전 준비 과정에 돌입했다.

 

사전 준비: 첫 발을 떼기 위한 워밍업

 

그때만 해도 다들 나처럼 면접을 패스하고 들어왔을 거라고 생각했다. 사전 준비 스터디에 참여했는데, 모두들 줌 사용에 익숙한 게 이상했다. 알고 보니 면접을 줌을 통해서 봤다고...? 나만 줌 사용이 처음이었던 거였다. 다들 공유하는 면접 경험이 나만 없었던 점에서 오히려 나는 약간 위축되었던 것도 같다.

아무튼 2주간의 사전 준비 과정에서는 내가 원래 듣고자 했던 웹개발종합반 강의를 들어야 했다. 강의를 들으면서 스터디원들과 미니 프로젝트를 진행했다. 하루의 시간을 어떻게 사용했는지를 적는 Daily Report 웹페이지를 만드는 거였는데, 프론트엔드와 백엔드를 나눴다. 그때의 나는 프론트엔드가 뭔지, 백엔드가 뭔지도 전혀 몰랐다. 몰라서 물어봤지만 설명을 들어도 몰랐다ㅋㅋㅋ 당시 나는 조장을 맡은 분과 함께 백엔드를 담당했고, 눈치껏 따라가고자 갖은 애를 썼다. 그때부터 무한 구글링의 역사가 시작되었던 것 같다. 내가 짜 놓은 망한 코드를 조장 분이 리팩토링하는 식으로, 엉성하게나마 뭐가 되어가긴 했다.

 

실전 프로젝트: 항해99의 꽃이자 최종 보스

 

2주간의 사전 준비 과정을 마친 후에는, 미니 프로젝트(1주), 알고리즘 강의 수강(2주), React, Spring, Node.js 중 선택한 주특기 강의 수강 및 개인 프로젝트 2번(2주), 프론트&백 협업 프로젝트 2번(2주)을 거쳤고, 그 다음이 6주간의 실전 프로젝트였다. 실전 프로젝트야말로 가장 큰 프로젝트였고 취업으로 향하는 핵심 관문이었으므로 실전 프로젝트 시작 1주일 전인 클론코딩 때부터 전체적으로 분위기가 어수선했던 기억이 난다. 실전 프로젝트 팀을 짜는 것을 다들 매우 중요하게 생각하고 있었기 때문에 실전 프로젝트 주간이 시작되자마자 팀 빌딩 방식에서 발생한 잡음으로 인해 전체적으로 모든 조 편성이 한 번 엎어지기까지 했다. 그러고 나서 확정된 우리 팀은 의견 조율도 잘 되고 분위기도 좋았다고 기억한다, 일단은...

우리 팀은 프론트엔드 3명에 백엔드 3명, 외부에서 들어오신 디자이너 두 분까지 해서 총 8명의 팀원으로 구성되었다. 기획 회의는 다같이 하고 기획안에 맞춰 디자이너분들이 피그마에 디자인을 그려주시면 그에 맞게 뷰를 짜고 기능을 붙이는 식으로 진행되었다. 이전의 프로젝트들에서는 디자인을 해주시는 분이 안 계셨기에 프론트엔드에서 디자인까지 담당했는데, 디자이너분들이 디자인을 전적으로 맡아주시니 비록 그걸 그대로 구현해내는 게 까다로웠을지언정 창작을 해낼 필요는 없었으니 마음이 좀 더 편했다. 그리고 확실히 전문가의 결과물은 퀄리티가 달랐다...

실전 프로젝트 3주차가 끝날 즈음 프로젝트 중간 점검이 있었고, 발표회 형식으로 지금까지 작업한 것들을 모두의 앞에서 소개하고 튜터분들에게 리뷰를 받는 자리였다. 나와 다른 두 분이 담당한 프론트엔드 쪽은 프론트엔드 개발자라면 당연히 신경써야 하는 기초적이고 기본적인 부분에서 지적을 많이 받았다. 그간 굳건했던 멘탈도 이때 좀 타격을 입었지만 해야 할 일이 산더미여서 덕분에 금방 다시 작업에 착수했다.

중간 점검이 있은 지 5일 정도 지났을 때, 진짜 문제는 다른 데서 터졌다. 프론트엔드 팀원 두 분이 각자 다른 이유로 한날 한시에 동반하차를 한 것이다. 그 시기 자체가 프로젝트 초반도, 후반도 아닌 너무 애매한 어느 시점이었다. 이미 세 명이서 벌여놓은 작업량이 있는데 그걸 나 혼자 진행해야 하는 거였고, 한편으로는 아직 프로젝트는 끝날 단계도 아닌 데다 개발하지 않은 기능도, 마무리해야 하는 기능도 너무 많이 남아 있었다. 항해99 매니저 분이 급히 불러서 1대1 면담도 했고, 긴급 팀 회의도 했고, 급박하게 돌아갔던 그날은 앞으로도 절대 잊지 못할 것 같다. 프로젝트의 방향이 기능을 추가하는 것에서 현상 유지를 잘 하는 것으로 바뀌었고 다른 조에서 다들 진행하는 프로덕트 마케팅에도 우리 팀은 비중을 많이 두지 않기로 했지만, 그때부터 나는 밤에는 거의 항상 깨어서 작업을 하고 아침이나 낮에 잠들곤 했다.

체력이 거의 바닥났을 무렵 실전 프로젝트가 마무리되고 최종 발표회가 열렸다. 우여곡절이 많았던 프로젝트가 끝났다는 사실에 후련하기도 했지만, 우리 팀 부스를 방문해주신 협력사 분들이 마감이 잘 되어 있다(이건 이후에 면접을 다닐 때도 많이 듣게 된 얘기다)며 혼자 해낸 것을 칭찬해주셔서 그간의 고생이 날아가는 것 같았다.

 

취업: 새로운 시작

 

최종 발표회가 끝나자마자 항해99에서는 마지막 단계인 취업 준비를 시작하게 된다. 우선 항해99의 협력사들 리스트 중에서 지원할 곳을 최대 30개까지 골라서 지원하고, 그러고 나서는 로켓펀치와 원티드를 통해 최소 15개사에 지원하라고 했다. 나는 재미있게 일할 수 있는 회사를 원했기 때문에 개발하게 될 서비스 내용을 보고 흥미가 가는 회사에 지원서를 넣었다. 협력사 30개, 그 외에는 40~50개 정도, 도합 70~80개 회사였다. 지원한 회사 수는 많았지만, 협력사에도 통일된 하나의 양식으로 지원서를 넣고, 로켓펀치와 원티드도 작성한 한 가지 양식으로 여러 회사에 지원할 수 있는 시스템이어서 지원하는 것 자체가 아주 고되진 않았다. 그리고 생각보다 많은 회사에서 서류 통과 연락을 받았고, 여러 번의 코딩테스트와 면접 일정을 안내 받았다. 그래서 그때 잠시, 섣불리 많은 회사에 지원서를 넣은 스스로를 탓했다.

코딩테스트는 알고리즘 기간에 백준이나 프로그래머스에서 풀었던, 말 그대로 알고리즘 문제로 치르진 않았다. 내가 받은 코딩테스트의 과제는 주로 회사에서 이미 서비스하고 있는 페이지를 클론코딩해서 제출하거나, 회사에서 요구하는 몇몇 사항을 반드시 충족하는 페이지를 만들어서 제출하는 식이었다. 며칠의 시간을 요하는 작업들이어서 안 그래도 바쁜 일정이 더욱 타이트해졌다.

면접에서는 주로 브라우저나 자바스크립트에 관한 지식을 묻거나, 프로젝트를 진행하면서 기술적인 어려움을 겪었던 것들에 대해 물었다. 그리고 거의 모든 면접에서 나에게 회사에 대해 궁금한 게 있다면 질문하라는 얘기를 들었다. 그때마다 나는 꼭 물어봤던 게, '왜 내 지원서를 좋게 봤는지'였다. 그러면 또 그때마다 최종 발표회에서 들었던, 이 모든 걸 혼자 해냈다는 것이 대단하다는 칭찬을 듣곤 했다. 그러고 보니 칭찬 받으려고 일부러 물어봤던 건가, 나...? 팀 프로젝트에서 혼자 남아 작업하게 된 그 에피소드가 결국 면접에서 주무기로 활용되었다.

취업을 결정한 회사는 내가 지원한 회사들 중 가장 재미있게 일할 수 있을 것 같았다. 그리고 실제로, 아직 출근한 지 한 달밖에 되지는 않았지만 재미있게 일하는 중이다. 회사에서는 프로젝트 때와 달리 어쩌면 일방적으로 주어지는 기획안과 일정에 맞춰 개발해야 하지만, 코딩이라는 즐거운 활동을 계속해서 이어나갈 수 있다는 사실이 아주 만족스럽다. 간단한 코드를 짜려고 해도 많이 찾아보고 알아가면서 시도해야 하지만, 계속해서 공부하며 새로운 걸 배워 나가야 하는 것도 마음에 든다.

처음에는 개발 분야에서 취업을 시도할지조차 확신하지 못했는데, 항해99가 끝나고 나니 어느새 개발자가 되어 있다. 항해99에서 지향하는 "좋은 개발자"가 과연 나인지는 아직 잘 모르겠지만, "좋은 개발자"가 되기 위해 앞으로 어떻게 방향 설정을 해야 하는지는 조금 알 것도 같다.

 


 

수강료 30만원 할인 혜택 + 사전 강의 4종 사전 제공

1. 항해 지원을 위한 자기소개서 작성 시, 추천인 이름을 입력해 주세요!
  ex) 이동민님이 추천해 주셨습니다!
2. 면접에서 면접관님께 한 번 더 알려주세요!
  ex) 안녕하세요, 이동민님이 추천해 주셔서 항해99에 지원했습니다!

추천인 소개로 지원 시, 30만원의 수강료 할인 혜택 + 사전 강의 4종이 사전 제공됩니다.
https://hanghae99.spartacodingclub.kr/

오늘까지 한 일

  • 금요일 퇴근하자마자 집에 다녀오느라 TIL도 남기지 못했다. 집에 갈 땐 가벼운 게 최고라며 노트북도 팽개치고 빈손으로 내갔다. 금요일 하루 빵꾸난 게 좀 아쉽지만 어쩌겠나, 뭐..
  • 금요일에는 게시판 모듈은 어떤 기능을 더 넣어야 할 지 아직 확실하지 않아서 기본적인 부분만 마무리했다. 그러고 나서 시작한 건 로그인, 회원가입 페이지였다. 여기서부터는, 앞으로 얼마큼이나 변경사항이 있을지 모르지만 일단 현재 나와 있는 기획안에 맞춰서 작업하기로 했다. 프로젝트에서는 기획에도 직접 참여했는데 회사에서는 기획을 담당하는 다른 누군가가 그 프로세스를 맡아준다는 것 자체가 새롭다. 뷰가 기획안대로 짜여져 나갈 때의 쾌감이란.. 기능이 하나 둘씩 붙고 코드가 점점 복잡해질수록 매 순간 당황하게 되겠지만 지금으로서는 충분히 행복하다.
  • 주말은 실컷 놀고 오늘 다시 서울로 돌아왔다. 동생이랑 이런저런 얘기를 하다가 갑작스럽게 프로젝트 하나를 하게 되어 버렸다(?!!) 코인이나 주식 투자에 관심이 많은 동생이 매수 최적 포인트를 찾기 위한 전략을 짰다는데(난 들어도 잘 모르겠고) 그 전략에 맞춘 프로그램이 필요한 상황이었다. 얘기를 들어보니 사실은 그 전략이라는 게 전부고 프로그램은 거들 뿐이라 아주 복잡하진 않을 것 같다. 일단 해봐야겠지만. 이거야말로 가내 수공업 아니고 프로젝트 아닌가ㅋㅋㅋ 암튼 재밌겠다 히히

오늘 한 일

  • 어제 퇴근 전에 주어진 게시판 모듈 만들기 작업을 하고 있다. 해당 컴포넌트에 DB에 저장된 리소스 이름, 테이블 형태로 보여줄 데이터 중 선택한 키 배열을 props로 넘기면 자동(?)으로 게시판을 생성하는 기본적인 기능은 거의 구현했고, 좀 더 사용성 좋게 만드는 일만 남았다. 물론 그게 하루 이틀 만에 될 일은 아니겠지만.
  • 게시판 모듈에 반드시 포함되어야 하는 기능 중 하나가 페이지네이션이었다. 예전에 프로젝트 할 때 서버에서 페이지별로 데이터를 어떻게 끊어서 보내줄 것인가, 그 다음 페이지가 있는지 없는지를 어떻게 확인하도록 해줄 것인가를 가지고 백엔드 분하고 같이 고민해본 기억이 난다. 이사님께 말씀드렸더니 서버에서 보내주는 응답 헤더에 있는 Content-Range를 확인하면 DB에 저장된 데이터의 총 개수를 알 수 있다고 하셨다. 오... 전혀 몰랐다...
  • 요청에 대한 응답이 올 때마다 헤더로 데이터 총 개수를 확인할 수 있고, DB로 API 요청을 보낼 때 range 쿼리를 날리면 딱 그만큼의 범위에 해당하는 데이터만 돌아온다. 그렇다면 페이지네이션은 내가 쿼리만 잘 날리고 헤더만 잘 보면 되는 것이었다! 고민했던 그때의 경험에 비하면 너무 손쉽게 해결되어 버렸다.

오늘 배운 것

  • 서버의 응답 헤더 속 Content-Range에 대한 설명
 

Content-Range - HTTP | MDN

The Content-Range response HTTP header indicates where in a full body message a partial message belongs.

developer.mozilla.org

+ Recent posts