2022 마스터즈 코스(백엔드) 55일차 회고(2022. 3. 25.) - "보람있었던 페어와의 한 주"

해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)

 

수강 회고

오늘로 이번 한 주 5일간 Sammy와의 페어 프로그래밍을 모두 마무리할 수 있었다. 지난 일주일을 되돌아보면 첫 날에 페어와 함께 프로그래밍을 했을 때보다 5일차인 오늘 함께 프로그래밍을 했을 때 훨씬 '호흡'이 잘 맞았던 것 같다. 이는 하루하루 페어 프로그래밍을 하면서 각자가 주어진 상황에 따라 서로의 스타일을 파악하고 자연스럽게 자신만의 '역할(position)'을 조금씩 찾아갔었던 덕으로 생각된다.

 

또한 지난 한 주간 페어 프로그래밍하면서 페어와 나 모두 '어떻게 하면 현실적이되 최선의 결과물'을 만들어 낼 수 있을지 고민했었던 것 같다. 즉, 이번 웹 서버 미션을 함께 진행하면서는 '완성도'에 집중하기 보다도 '미션 요구사항'에 좀 더 집중했었던 것 같다. 물론 각자만의 완성도있는 프로그램 구현에 대한 욕심은 있지만 페어와 나 모두 웹 서버 프로그램을 구현하는 것이 처음이었기에 이번 미션은 과제에 명시된 사항을 위주로 구현하고 나머지 리소스(시간, 비용)로 관련된 학습을 하는데 초점을 두고 미션을 진행하고자 했었던 것이다.

 

개인적으로 아쉬운 점은 한 주 중간(수요일~목요일)에 컨디션이 급격히 안 좋아져서 페어와 프로그래밍할 때도 영향을 받았다는 점이 아쉬웠다. 아울러 스크럼 활동과 그룹 리뷰 시간에도 많이 불참하게 되어 아쉬운 점이 있었다. 오늘뿐만 아니라 지난 일일 회고 중에서도 '건강', '체력'과 관련한 주제의 내용이 많았었는데, 예상컨대 마스터즈 코스 과정이 끝날 때까지 이러한 회고는 여러 번 반복될 것으로 보인다... 😂

 

다음주에는 또 다른 다음주의 미션이 주어질텐데 이번 한 주 보다 더 개선된 '팀워크'가 발휘될 수 있길 기대해본다. 이를 위해서는 우선 나부터 페어의 의견에 귀 기울이고, 페어와 적극적으로 소통해야겠다는 생각이 들었고 더욱이 '어떻게 협력해야 더 나은 결과물을 낼 수 있을지'에 대한 고민이 필요하다는 생각이 들었다.

 

 

학습 회고

• 웹 서버 관련 미션 과제 풀이
  
  • 페어와 zoom 회의실에서 학습

 

문자 코드 vs 인코딩

문자 코드는 각 문자별로 추상적인 숫자(2진수, 8진수, 10진수, 16진수 등)로 짝지어(매핑해) 놓은 것, 말 그대로 코드(ex. 아스키 코드, 유니 코드 등)를 의미하며, 인코딩이란 코드화 또는 암호화를 의미하며 어떤 정보를 정해진 규칙(문자 코드)에 따라 변환(ex. UTF-8, EUC-KR 등)하는 것을 일컫는다.

 

예를 들어, 다음과 같은 문자 코드가 있다고 해보자.

‘가’ : 1, ‘나’ : 2, ‘다’ : 3, ‘하’ : 14

 

‘가나다’라는 문자를 한 자릿수 방식으로 인코딩 한다면 123일 것이다. 이때 한 자릿수 방식으로는 문자 ‘하’는 표현할 수 없다. 만일 ‘가나다하’라는 문자를 두 자릿수 방식으로 인코딩 한다면 01020314이 될 것이다.

 

UTF-8

UTF-8은 전세계 언어와 호환되는 가변 길이 유니코드에 기반한 인코딩 방식으로 가장 많이 사용되는 인코딩 방식이다. UTF-8은 최소 1바이트 최대 6바이트 가변 인코딩 방식으로 UTF-8로 표현 가능한 길이는 최대 6바이트지만 다른 인코딩과의 호환을 위해 4바이트까지만 사용한다. 그래서 한 글자가 1~4바이트 중 하나로 인코딩될 수 있다.

 

이때 1바이트 영역은 아스키 코드와 하위 호환성을 갖는다. 즉, 아스키 코드의 0~127까지는 UTF-8로 완전히 동일하게 기록된다. 유니코드가 널리 쓰이기 전부터 형성된 인터넷 문서들은 대부분 아스키 코드를 기본으로 해서 작성되었고, 특히 기존 HTML, 자바스크립트 등 아스키 코드로 구축된 사이트를 별다른 변환 처리 없이 그대로 쓸 수 있는 장점이 있다.

 

UTF-8 인코딩 방식은 영어(아스키 문자)의 경우 1Byte 방식으로, 한글의 경우 3Byte 방식으로 인코딩을 한다. 영어, 한글 외에 전세계 언어 모두 표현 가능하며 각각의 언어에 따라 Byte 수가 다를 수 있다.

 

EUC-KR

EUC-KR은 한글 또는 영어 두 가지에 국한된 언어 환경을 구축할 경우 선택 가능한 8비트 문자 인코딩 방식으로 KS X 1001와 KS X 1003라는 문자 코드를 사용하는 8비트 문자 인코딩 방식이다. 대표적인 한글 완성형 인코딩이기 때문에 보통 완성형이라고 불린다. EUC-KR 인코딩 방식은 영어(아스키 문자)의 경우 1Byte 방식으로, 한글의 경우 2Byte 방식으로 인코딩을 한다.

 

UTF-8 vs EUC-KR

웹 서비스의 주요 고객 대상이 전 세계의 외국인들이라면 여러 언어와 호환성이 있는 UTF-8 방식의 인코딩이 적합할 것이다. 반면에 웹 서비스 상 한글의 사용 비중이 월등이 높고 대상도 국내 사용자로 한정된다면 굳이 한글을 3Byte 형식으로 인코딩하는 UTF-8 보다는 한글을 2Byte 형식으로 인코딩하는 EUC-KR을 사용하는 것이 용량 절감 차원에서 적합할 것이다.

 

 

좋았던 점

• 지난 한 주를 되돌아 보았을 때 월요일부터 금요일까지 Sammy와 페어 프로그래밍을 하면서 많이 배울 수 있었고 또한 재밌게 프로그래밍 할 수 있었습니다. 🏃‍♂️

 

 

아쉬웠던 점

• 이번주 컨디션 관리를 제대로 하지 못해 수요일~목요일 그룹 리뷰에 참여하지 못했던 점이 아쉬웠습니다. 😭

 

 

이전 보다 개선되었던 점

• 금요일인 오늘 Sammy와 페어 프로그래밍을 하면서 확실히 월요일보다 합이 잘 맞았던 것 같고 '팀워크'가 생긴 느낌을 받을 수 있었습니다. ✨