2022 마스터즈 코스(백엔드) 2일차 회고(2022. 1. 4.) - "그룹 리뷰를 통해 생각 넓히기"

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

 

수강 회고

오늘부터 10:00~10:30간 그룹 소모임원들과 데일리 스크럼을 통해 어제 수강하면서 느꼈던 점들에 대해서 가볍게 대화를 나누었다. 아직 제대로 대화를 나눠본 적이 없었기 때문에 약간 서먹서먹했지만 다들 적극적으로 소통하려고 노력해주신 덕에 금방 적응되어 대화가 원활하게 진행될 수 있었다.(다들 늦은 시간까지 CS10 과제를 수행하느라 지친 기색들이 보였다.)

 

이후 JK의 마스터 클래스 강의가 진행되었다. JK가 오늘 강의 초반에 설명했었던 아날로그, 디지털, A/D 컨버터, 디지털 논리 게이트 등의 설명은 대학 학부 시절 배웠었던 내용이라 익숙했었다. 이후 부동소수점의 개념과 오류에 대해 엑셀을 통한 예시와 함께 설명해주었는데, 예전부터 부동소수점에 대해서는 꼭 한 번 기술블로그를 통해 정리해보고 싶었기 때문에 이번 수업이 많은 참고가 되었다. 

 

또한 JK의 수업을 듣기 전까지 인지하지 못하고 있었던 것이 있었는데 바로, 컴퓨터가 메모리에 데이터를 저장할 때는 비트 단위가 아니라 바이트(8비트) 단위로 저장하고 관리하는 것이다.(컴퓨터에 따라서 바이트 단위가 아닌 워드 단위 16비트 이상으로도 주소를 할당하는 것도 있다고 한다.)

 

예를 들면 100과 200을 더한다고 가정해보자. 이때  메모리에 데이터를 비트 단위로밖에 저장할 수 없다면 100과 200은 비트 단위로 저장될 수 없기 때문에 이 값들을 비트 단위로 1100100과 11001000으로 변환하여 이 값들을 다시 비트 단위로 연산해주어야하는 불편함이 생긴다. 이처럼 비트 단위로 데이터를 저장 및 관리하면 명령들이 너무 세분화되어 프로그래밍 시에도 상당히 불편할 수 있다. 반면 메모리에 데이터를 바이트 단위로 저장한다면 1바이트는 0 ~ 255의 값을 저장할 수 있으므로 100과 200을 변환할 필요 없이 연산이 가능해진다.

※ 참고 : 이러한 1바이트 단위의 메모리들은 각각 주소(Address)를 가지고 있는데, 일반적으로 16진수로 표현하며 이 주소 역시 데이터이다. 이 주소 데이터를 저장하는 메모리(포인터)의 크기는 통상적으로 운영체제의 기본 처리 단위(ex. 32bit, 64bit)와 일치한다.

 

여기서 중요한 점은 이 1Byte는 다시 8개의 bit로 구성되어 있는데, Byte Order(엔디안)에 따라 Byte 위치 순서가 달라진다해도 그 Byte를 구성하는 8개의 bit 순서는 바뀌지 않는다는 것이다.

 

또한 어제 과제에서 잠깐 언급되었던 리틀 엔디안과 빅 엔디안에 대한 설명도 있었다. 어제 개인적으로 학습했었던 내용 상으로 리틀 엔디안이란 가장 작은 단위(LSB, Least Significant Bit)부터 가장 낮은 메모리 주소(맨 앞)에 저장되는 Byte Order를 의미하고, 빅 엔디안이란 가장 큰 단위(MSB, Most Significant Bit)부터 가장 낮은 메모리 주소(맨 앞)에 저장되는 Byte Order를 의미하는 것이었다.

 

예를 들어, java라는 데이터가 있을 때 이를 빅 엔디안으로 표현하면 java로 표현할 수 있다. 해당 데이터 메모리의 가장 낮은 주소(맨 앞)에 가장 큰 자리수(가장 왼쪽)인 MSB부터 순차적으로 저장되기 때문이다. 반대로 이를 리틀 엔디안으로 표현하면 avaj로 표현할 수 있다. 해당 데이터 메모리의 가장 낮은 주소(맨 앞)에 가장 작은 자리수(가장 오른쪽)인 LSB부터 순차적으로 저장되기 때문이다.

 

이때 Byte Order에서 Bit 자리수를 의미하는 LSB와 MSB라는 단어를 써도되는지 의문이 들어 이에 대해 개인적으로 찾아본 결과 실제로 LSB나 MSB를 상황에 따라 Least Significant Byte나 Most Significant Byte의 의미로 사용하고 있는 자료들도 발견할 수 있었다.(아래 자료 참고) 정식 명칭은 Bit가 맞는 거 같긴 한데 관습적(?)으로 Byte로도 사용되는 것 같다.

 

// 참고자료 1 : https://whatis.techtarget.com/definition/most-significant-bit-or-byte 

The most significant bit (MSB) is the bit in a multiple-bit binary number with the largest value. This is usually the bit farthest to the left, or the bit transmitted first in a sequence. For example, in the binary number 1000, the MSB is 1, and in the binary number 0111, the MSB is 0.

The most significant byte, also abbreviated MSB, is the byte in a multiple-byte word with the largest value. As with bits, the MSB (byte) is normally the byte farthest to the left, or the byte transmitted first in a sequence.

 

// 참고자료 2 : https://uynguyen.github.io/2018/04/30/Big-Endian-vs-Little-Endian/

 

 

 

끝으로 JK가 강의 말미에 했었던 말 중 "내가 만든 코드는 언젠가 반드시 바뀐다는 가정하에 작성해야한다. 즉, 코드를 처음 작성할 때 추후 유지보수를 고려해서 작성해야한다."라는 말이 인상깊었다. 그동안 기능 구현에 급급해서 코드를 작성했었던 내 자신을 되돌아보는 계기가 되었다.

 

학습 회고

• 소모임원들과 각자의 CS10 과제 풀이 방법 공유 및 수정 작업
  • Java 웹 백엔드 클래스 내 소모임원들과 zoom 회의실에서 학습

 

오늘은 그룹 리뷰를 통해 어제 풀었던 CS10 과제를 소모임원들별로 순서대로 풀이 방법을 발표하는 과정에서 소모임원들간 조언도 해주고 조언도 받을 수 있었다. 단순히 "이렇게 풀었어요"하는 게 아니라 어떤 의도를 가지고 또 어떤 시행착오가 있었는지도 공유가 되어 많은 참고가 될 수 있었다.

 

소모임원들의 풀이 방법을 보면 내 풀이와 비슷하게 푸신 분들도 계셨고 나와 다른 방식으로 접근해서 문제를 푸신 분들도 많았다. 이때 아무래도 다른 방식으로 푸신 분들의 풀이에 좀 더 관심이 많이 갔었고 기존의 내 접근 방법과 다른 접근 방법으로 생각해볼 수 있는 기회가 되었다. 특히 Jay님 덕분에 진법 변환 시 % 연산자를 이용하지 않고 푸는 방법과 각 케이스별로 테스트하는 방법을 배울 수 있었다.

 

오늘 오전 JK가 강의를 진행할 때 본 과제에 대해서 테스트 코드를 작성해야 하는데, 이때 진리표처럼 모든 경우에 대해서 테스트 하는 방식을 언급했었다. 진리표 처럼 모든 경우에 대해서 테스트를 하면 해당 코드의 신뢰도가 제대로 검증될 수 있기 때문인 것 같다. 기존에 나는 테스트 코드를 Main 함수에서 콘솔로 값을 입력받아 해당 경우에 대해서만 테스트 하는 방식을 취했었는데, 다음 과제부터는 JK가 언급한대로 테스트 코드를 제대로 작성해봐야겠다.

 

좋았던 점

• 그룹 리뷰를 통해 어제 풀었던 과제에 대해 팀원들간 풀이 방법을 공유하며 서로 도움을 줄 수도 있었고 도움을 받을 수도 있었다. 어제 보다 좀 더 팀원들간의 교류가 많아져서 앞으로 있을 다음 과정에서도 팀원들과의 팀워크가 기대된다.

 

아쉬웠던 점

• 어제 보다 나아지긴 했지만 아직 다소 몸살 기운이 있어 오후에 모각코 시간에 학습하는데 집중력이 다소 흐트러졌다. 개발자는 코딩뿐만 아니라 건강 관리(운동 등)도 중요하다고 말했었던 호눅스가 생각났다.

 

참고자료

• https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=tipsware&logNo=221537443580
• https://jhnyang.tistory.com/172
• https://jhnyang.tistory.com/226