DevRadon

MDN 주소 : https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/every

그 동안 알고리즘 문제 등을 풀면서 배열의 모든 요소들이 특정 조건을 만족하는지 여부를 따질 때, 반복문을 만들어서 어떤 조건을 달성하지 못하면 boolean값을 담은 변수를 false로 만들고 동시에 반복문을 break; 하는 형식으로 코드를 작성했었다. 그런데 오늘 스터디모임을 통해 다른 분이 작성한 코드를 보면서 배열의 메소드를 새로 발견하게 되어 잘 활용하면 간결한 코드를 작성하는데 도움이 될 것 같아 정리해 보고자 한다.

every는 callback이 거짓을 반환하는 요소를 찾을 때까지 배열에 있는 각 요소에 대해 한 번씩 callbackFn 함수를 실행합니다. 해당하는 요소를 발견한 경우 every는 즉시 false를 반환합니다. 그렇지 않으면, 즉 모든 값에서 참을 반환하면 true를 반환합니다.

그동안 사용하던 반복문을 이용하던 방식에서는 break;를 사용하지 않으면 반복문을 전부 순회해야 해서 연산수가 많아진다는 단점이 있어서  break;를 사용했었는데, 위 설명을 보아 every를 활용하면 그런 걱정은 하지 않아도 되겠다.

- 아래는 MDN 문서 내용 중...!

"참고: 빈 배열에서 호출하면 무조건 true를 반환합니다!"

할당한 값이 있는 배열의 인덱스에서만 callbackFn을 호출합니다. 삭제했거나 값을 할당한 적이 없는 인덱스에서는 호출하지 않습니다.

callbackFn은 요소의 값, 해당 요소의 인덱스 및 순회하고 있는 배열 세 가지 인수와 함께 호출됩니다.

thisArg 매개변수를 every에 제공한 경우 callbackFn의 this로 사용됩니다. 그 외엔 undefined값을 사용합니다. 최종적으로 callbackFn이 볼 수 있는 this의 값은 함수가 볼 수 있는 this를 결정하는 평소 규칙을 따릅니다.

every는 호출한 배열을 변형하지 않습니다.

every가 처리하는 요소의 범위는 callbackFn의 첫 호출 전에 설정됩니다. every 호출 이후로 배열에 추가하는 요소는 callbackFn이 방문하지 않습니다. 배열에 존재하는 요소가 변경된 경우, callbackFn에 every가 방문하는 시점의 값을 전달합니다. 삭제한 요소는 방문하지 않습니다.

every는 (이산)수학에서 전칭(∀) 정량자(quantifier, 한정자)처럼 행동합니다. 특히, 빈 배열에 대해서는 true를 반환합니다. (이는 공집합의 모든 요소가 어떠한 주어진 조건도 만족하는 공허한 참입니다.)

코드 :

1. 불필요한 import문 등 코드를 정리하는 요령 등이 부족

2. 깃 레포관리 readme 파일은 내가 보려고 만드는게 아니라는 걸 간과함 (내가 작성한 코드를 처음 볼 사람들에게 안내판 같은 역할을 해야 할텐데, 작성한 내 위주로만 생각해서 readme를 작성했던 것 같다.)

지식 : 

1. 컴퓨터 공학, HTTP 통신에 대한 이해 등이 부족함을 느꼈다. 특히 프로세스, 스레드 부분은 예전에도 배워서 동시성, 병렬성 내용 등과 함께 정리한 적이 있지만 프로세스에 대한 이해가 부족하였는지 설명을 제대로 하지 못했다. 비전공자인 만큼 컴퓨터 공학, HTTP통신에 대한 이해 등을 보완하려는 노력이 더 필요하다.

2. 타입스크립트 : 처음 타입스크립트로 코드로 작성할 때는 모든 변수 모든 함수 등에 다 타입을 지정하는 식으로 했다가, 이런 식으로 하지 않아도 처음 그 변수가 사용되거나 파라미터자리에 값이 들어올 때 타입이 자동으로 지정된다는 점을 배운 후에는 그냥 JS로 코드를 작성하는 것과 거의 비슷하게 코드를 작성하였는데... 이렇게 하는 것도 아닌 것 같다... 타입스크립트로 작성된 좋은 코드 예제 등을 찾아보고 참고해야 겠다.

데이터베이스(RDBS)에 대한 이해 : 

1. 데이터베이스 정규화에 대한 내용을 정리하면서 조금 안다고 생각했었는데, 특정 상황을 가정하고 DB를 어떻게 설계하면 좋을 것인가? 라는 질문을 받았을 때 머릿속에서 바로 정리하여 답변하기 어려웠다... 특히 여러개의 데이터를 갖고있는 테이블에 저장하는 문제 같은 경우엔 프로젝트를 할 당시에 많이 고민했던 부분이라 잘 알고 있다고 착각했다... 처음 데이터베이스를 배울 때 했던 '웹 서비스의 특정 화면' 등을 보고 관련된 데이터들을 어떤식으로 저장해서 불러오면 좋을 지 생각해보는 연습을 다시한번 해보면 도움이 될 듯 하다.

Node.js 에 대한 이해 :

1. 진행하고 있는 스터디에서 서버 언어에 대해 이야기 하다가 Node.js 서버의 성능에 대한 이야기가 나왔던 적이 있는데, 그 당시에 관련 내용을 좀 더 찾아보고 정리하지 않았던 점이 아쉬웠다... Node Performance 에 대해 설명해야 할 기회가 있었는데, 그나마 알고 있던 싱글스레드로 작동되고 비동기 처리를 할 수 있다는 부분도 답변하지 못한 점이 매우 아쉽다..!

 얼마전 REST API와 GraphQL의 특징들을 비교하고 간단하게 알아보는 내용으로 블로그 글을 작성한 적이 있었는데, 바로 그 다음주에 취업활동 중 과제로 GraphQL서버 구현을 하게되었다. 서버 구현을 해본일 자체가 몇번 없긴 하지만 그 몇번 없는 경험 마저 express만을 활용하는 REST API형식의 서버들 뿐이어서 과제를 처음 받고 굉장히 난감했었다. 과제의 기본조건이 ORM의 일종인 Prisma를 사용하는 것과, apollo-server를 사용하는 것 그리고 mysql을 사용하는 것 이었는데 이중에 무엇인지 알아들었던 건 사실 mysq뿐이었다...

 검색을 통해 급하게 알아본 결과 Prisma는 ORM의 일종으로 v1같은 경우에는 GraphQL을 통해 모델을 정의할 수 있다는 사실을 알았다. Apollo 서버는 GraphQL API를 제공하는 서버를 개발할 수 있게 도와주는 패키지로서 기존에 Node.js에서 사용하는 Express와 역할이 비슷하다고 한다.

 처음엔 무엇부터 시작을 해야하나 막막하였는데, 공식문서를 쭉 살펴본 결과 새로 접한 스택들 모두 기존에 내가 다루어 보았던 것들과 유사한 점이 많아 어느정도 접근이 가능해 보였다! 과제에서 Prisma를 이용하여 테이블들을 생성하고 속성들간의 관계를 설정하라고 하였는데, sequelize를 사용하면서 했던 방식을 떠올리면서 공식문서를 살펴보니 어느정도 이해를 할 수 있었다. Apollo 서버의 경우에도 Express를 생각하면서 보니 어느정도 맥락이 비슷한 부분들도 있었고 어떤식으로 서버객체를 불러와 사용하는지 알 수 있었다. 과제를 다 마친 이후에도 아직 해결 못한 궁금증이 많이 있었는데 그 중에서 Apollo 서버에서는 라우팅을 어떤식으로 구현해내는지? 또 Express에서 사용하는 미들웨어와 같은 것들을 Apollo서버에서는 사용할 수 없는지 궁금했다. 검색을 해보다가 express로 서버를 구현하면서 라우팅 구현과 미들웨어등을 사용하되, Apollo 서버또한 동시에 같이 구현하여 원하는 엔드포인트마다 다른 형식의 서버를 통해 응답하는 걸 보았는데 Apollo 서버 단독으로는 불가능한 지 여부도 궁금했다.

 굉장히 생소하고 어려운 도전이 된 과제였지만 덕분에 GraphQL API를 제공하는 서버를 처음으로 만들어 볼 수 있었고, 기존에 내가 프로젝트에서 구현했던 REST API가 몇몇 부분에선 잘못되었다는 점도 알게 되었다. 

데이터베이스 정규화

- 관계형DB 설계에서 중복을 최소화하는 프로세스

(테이블 간의 중복을 막는 것)

- 정규화를 통해 이루고자 하는 것들

1. 저장 효율 개선 

2. 데이터 무결성 (데이터 수명주기 동안 정확성/일관성 유지하는 것)

3. 이상현상(갱신, 삽입, 삭제)

- 정규화 과정 간략하게 (제 1 ~ 제 3)

1. 테이블의 컬럼이 하나의 값(원자값)을 갖도록 테이블을 분해하는 것

예 : 학번(1) 이름(1) 수업(N)

2.완전 함수 종속을 만족하도록 테이블을 분해하는 것

(기본키의 부분집합이 결정자가 되어서는 안된다는 것)

예 : 학번 이름 수업 성적 강의실 / 학번이름수업 -> 성적 수업-> 강의실

3. 이행적 종속을 없애도록 테이블을 분해하는 것

예: 학번 수업 수강료 / 학번 -> 수업 수업 -> 수강료

 REST API란 무엇일까? 검색해보면 이에 대해 정의해 놓은 글과 관련된 자료들을 굉장히 많이 찾아볼 수 있어서 이걸 어떻게 설명해야 하지 할때마다 검색해보지만 머리에 잘 남지는 않았다... 그러다 오늘 한 유튜브영상을 통해 간단하게 특징을 얕게 정리할 수 있는 계기가 되어서 글로 남겨보고자 한다. 

 보통 입문자들을 위해 REST API를 설명할 때 식당 메뉴판이나 자판기를 예로 많이 드는데, 나에게는 '버튼마다 나오는 것이 일정하고 확실한 자판기'라는 비유가 와닿았다. REST API를 좀 더 구체적으로 설명해보면 '메소드 + URI(자원을 구조와 함께 나타내는 형태의 구분자)'를 조합해서 예측가능하고 일정한 정보와 작업을 요청하는 것이라 할 수 있는데, 마치 자판기의 특정한 버튼을 누르는 행위(어떤 버튼을 누름으로서 이 음료가 나오기를 원한다는 걸 알 수 있으니까!)처럼 REST API에 대한 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것이 특징이다.

 GraphQL의 경우 예를 들어서 설명해보면... 국어강사가 학생들의 국어성적을 보고자 할 때 서버에 요청을 보냄으로서 받고자 하는 응답은 학번 / 이름 / 국어성적 을 포함하고 있다면 충분할 것이다. 그렇지만 REST API 형식으로 된 응답을 받게된다면 학번/이름/국어성적 외에 다른과목성적, 학생의 성별, 반 등등 필요로 하지 않는 정보들 까지 응답으로 받게 될 것이다. 물론 REST API의 경우에도 정보를 특정할 수 있지만 여러번의 요청 단계가 필요하게 된다. 반면에 GraphQL은 내가원하는 정보만 골라서 요청하기가 수월하다. 요청에 포함될 정보의 depth등에 크게 구애받지 않고 유도리 있는 요청을 보낼 수 있는 것이다.

 아직 GraphQL을 직접 다뤄본 적도 없고 RESTFUL하게 API를 만든다는 것도 나같은 초보 개발자에게는 너무 먼 이야기이지만  GraphQL의 특징에 대한 설명 영상을 보면서 내가 프로젝트 때 구현했던 응답들은 어떤 부분에서 REST API와 거리가 멀었는지 생각해 볼 수 있었고, 또 GraphQL과 같은 형식으로 응답을 하고자 억지로 노력했던 흔적들이 보여서 어떤 부분에서 GraphQL이 유용할 지에 대해서도 고민해 볼 수 있는 계기가 되었다.

한 줄로 요약해 보면! REST API는 요청은 단순 하지만 데이터는 복잡 / GraphQL은 요청은 복잡 하지만 데이터는 효율적

GraphQL 영상 주소 : https://www.youtube.com/watch?v=EkWI6Ru8lFQ

얼마전 알고리즘 문제를 풀다가 아무리 생각해도 오류가 날리 없는 부분에서 자꾸 오류가 발생한 일이 있었다. 소숫점 자리값이 있는 간단한 두 수의 뺄셈이었는데 예상과는 다르게 소수점 값이 매우 긴 다른 숫자가 리턴되었다. 원인을 몰라 전체적인 코드를 계속 바꿔보다가 코드가 잘못되서 그런건 아닌것 같다는 생각이 들어 다른 원인을 찾아보았더니... 소수점 연산 등에서 오류가 발생하는 이슈에 대해 정리해 놓은 글들을 많이 볼 수 있었다. 숫자를 저장하는 방식의 한계에서 온 문제였는데 좀 더 자세히 정리해보고자 한다.

먼저 계산오류가 어떤 것이었는지 보면

let a = 4.001

let b = 2

*a - b = ?

위 뺄셈계산의 답은 당연히 2.001이어야 한다. 하지만 JS로 위의 코드를 실행해 본다면 2.0010000000000003이라는 정체모를 숫자가 나타난다. 위의 문제는 JS에서만 일어나는 문제는 아니며 나타나게되는 잘못된 숫자의 경우는 언어마다 조금씩 다를 수 있다.

사실 숫자는 64비트 형식, IEEE-754(컴퓨터에서 부동소수점을 표현하는 가장 널리 쓰이는 표준)로 표현되기 때문에 숫자를 저장하기 위해서는 정확히 64비트가 필요하다. 64비트 중에서도 52비트는 숫자를 저장하는데 사용되고, 11비트는 소수점 위치를 그리고 1비트는 부호를 저장하는 데 사용된다. 그런데 너무 큰 숫자는 표현하려면 64비트를 초과하기 때문에 '무한'(infinity)으로 처리 된다.

위의 예시로 든 연산의 경우에는 숫자도 별로 크지 않고 소수점 자리수도 적어보이는데 문제가 무엇일까? 컴퓨터가 계산을 할 때에는 2진법을 사용하는데, 몇몇 소수의 경우에는 10진법을 2진법으로 변환할 때 무한소수가 되어버리는데, 위에서 말했듯이 숫자를 저장하는 공간은 한정되어있기 때문에 무한한 값을 저장할 수는 없어 유한한 수로 바꾸게 된다. 그 과정에서 발생하는 오차로 인해서 계산에 오류가 발생하게 되는 것이다.

오류를 해결하기 위한 방법들

1. toFixed(n) 메소드

toFixed 메서드는 파라미터로 0부터 20까지 숫자를 넘길 수 있는데 해당 값이 소수점 이후의 자릿수를 결정한다.(반환되는 값이 문자열임에 주의)

2. Math 메서드 활용(ceil, floor, trunc, round 등)

 데이터베이스 정규화란 관계형 데이터베이스 설계에서 중복을 최소화하는 프로세스를 말한다. 바꾸어 말하면 테이블 간의 중복된 데이터를 허용하지 않는 것이다. 이를 통해서 데이터의 무결성(Integrity)를 유지할 수 있으며, DB의 저장 용량 또한 줄일 수 있다. 데이터베이스 정규화를 위해서는 크게 다음 부분들이 중요하다. 

• Data redundancy 
• Data integrity
• Anomaly

데이터 중복(Data redundancy)은 실제 데이터의 동일한 복사본이나, 부분적인 복사본을 뜻한다. 이러한 중복으로 데이터 복구 등의 경우엔 이점이 있을수도 있으나 대체로 DB내에서는 다음과 같은 문제점을 지닌다. 

1. 일관된 자료 처리의 어려움

2. 저장 공간 낭비

3. 데이터 효율성 감소

데이터베이스 정규화는 데이터 무결성을 강화하는 목적도 지닌다. 데이터 무결성(Data integrity)은 데이터의 수명 주기 동안 정확성과 일관성을 유지하는 것을 뜻한다. 다시 말해 입력된 데이터가 오염되지 않고, 입력된 그대로 데이터를 사용할 수 있다는 뜻.

데이터 이상현상(Anomaly)은 기대한 데이터와 다른, 이상현상을 나타내는 말로 '갱신이상, 삽입이상, 삭제이상' 이 있다.

// 구체적인 데이터베이스 정규화 단계

테이블을 분해하는 정규화 단계가 있음(제1 ~ 제3 정규화 + 제4, 제5)

1. 제 1 정규화 (비정규형 -> 1NF)

제 1정규형을 갖추려면 도메인 원자값 이라는 조건이 만족해야 한다.

도메인 원자값을 만족시킨다는 것은 아래와 조건과 같다.

1) 반복 그룹이 존재하면 안된다.

2) 모든 행은 식별자로 완전하게 구분되어야 한다.(prime key, 복합키 등으로 구분되어야..!)

// 조금 더 자세한 설명 

제 1정규형은 한 릴레이션을 구성하는 모든 도메인이 원자값(Atomic Value)만으로 구성되도록 하는 정규형을 말한다. 

예: 회원정보 저장시 전화번호가 여러개라면 한 컬럼에  여러번호를 010~~, 010~~ 이런식으로 입력했다면 원자값이 아니게 된다.

2. 제 2 정규화 (부분함수 종속 제거) 

(필요 충분 조건 : 후보키 K와 K에 속하지 않는 속성 A가 있을 때, A를 결정하기 위해 K의 일부가 아닌 K 전체를 참조해야만 하는 경우 1NF 테이블은 2NF이다.)

위의 조건은 무슨 말인지 이해하기 어렵다... 다시 말해보면 Key가 아닌 값들은 모두 Key에 종속 되어야 한다는 말이다.

조건은 다음과 같다.

1) key가 아닌 컬럼(속성)은 key 컬럼이에 종속 되어야 한다.

2) key가 아닌 컬럼(속성)은 key 컬럼에만! 종속 되어야 한다. 그래서

3) 복합키 일때만! 제 2정규형의 조건이 되는것이지요. (복합키가 아니면 제 2정규형을 넘어 제 3정규형을 보면 됩니다)

TiP) 결과적으로 Key 값에 주목하는것이 제2 정규화의 핵심!

3. 제 3 정규화 - 이행적 함수 종속 제거

(필요 충분 조건 : 제 2정규형을 만족하고, 테이블 내의 모든 속성이 키에만 의존하며 다른 후보키에 의존하지 않는다.)

정리하면

1) 모든 key가 아닌 컬럼(non-key)은 key 컬럼(속성)에 완전히 종속 되어야 한다.

2) 모든 non-key 컬럼은 key 컬럼(속성)에만 종속 되어야 한다.

3) 그래서 key가 아닌 값에 주목!

출처 블로그 :

1. https://mr-dan.tistory.com/10

2.https://mangkyu.tistory.com/110

 최근 '코어 자바스크립트'라는  책을 통해 자바스크립트의 기본적인 개념들을 다시 정리하고 있다. 얼마 전 '클로저'를 정리하는 과정에서 잘못 알고 있던 부분을 수정할 수 있던 좋은 기회가 되어서 다른 개념들에 대해서도 정리해보려고한다.

 내가 JS를 공부하면서 처음으로 불변성(Immutable)에 대해 고민해 본 것은 코딩 문제를 풀다가 오류를 만나 검색하던 중 '깊은복사와 얕은복사'라는 걸 만나게 된 때였다. 어떤 변수에 할당된 배열을 또 다른 변수에 할당시키고 값을 추가하거나 빼서 원래있던 변수에 할당된 배열을 건드리지 않으려는 의도였는데, 결과는 두 변수에 해당된 배열 모두 값이 바뀌어 있었다. 도무지 이유를 몰라 검색을 해보니 "배열은 Immutable한 값이 아니기 때문이다." 라는 딱 한 줄로 설명하고 있었다... 그리고 이를 해결하기 위한 방법으로 깊은 복사와 얕은 복사에 대한 설명이 있어서 제대로 이해하지 못한 채 그냥 배열, 객체는 이런식으로 다루어야 하나보다 정도로 정리하고 넘어갔던 기억이 난다.

 지금 다시 불변성에 대해 정리해보자면, 우선 단어의 뜻 그대로 '변하지 않는다.'가 맞다! 그런데 다른 의미의 '변하지 않는다'와 혼동하지 말아야 한다. JS를 다루면서 변수(let)와 상수(const)를 많이 쓰게 되는데 주로 어떤 값(변수?)에 새로운 값을 할당할 일이 발생한다면 변수를 사용하고 새로운 값을 할당할 일이 없거나 바뀌는 일이 없도록 하고 싶을 때 상수를 사용한다. 여기서 상수의 바꿀 수 없는 성질을 위의 Immutable 과 혼동할 수 있는데 이 둘을 명확히 구분할 필요가 있다. 

1. 불변성(Immutable) 이란?

 정확하지는 않지만 간단하게, 변수를 선언할 때 메모리 영역에서 어떤 작업을 수행하는지 표현하자면...

let a = 'abc';

위와 같이 선언했을 시, 컴퓨터는 메모리에서 비어있는 공간(1) 하나를 확보하고 그 공간의 이름(식별자)을  a라고 지정한다. 이 공간(1)에 'abc'라는 문자열을 저장하면 될 것 같지만!!! 실제로는 직접 저장하지는 않는다. 대신 이 문자열 데이터를 저장하기 위한 별도의 메모리 공간(2)을 다시 확보하고 그곳에 'abc'를 저장하고, 이 "메모리 공간의 주소"를 아까 변수를 위해 확보한 공간(1)에 저장한다.

a = a + 'def';

위의 재할당 명령을 내리면 어떻게 될까? 물론 결과가 a = 'abcdef'가 되는 것은 쉽게 알 수 있지만, 메모리영역에서 어떤 변화가 일어나는지 알아보자. 아까 문자열 데이터를 저장하기 위한 공간(2)에는 'abc'가 저장되어 있을 것이다. 그럼 이 공간(2)의 데이터가 'abcdef'가 되는 것일까? 그렇지 않다! a + 'def'의 결과는 'abcdef'가 되고 이 결과는 전혀 다른 새로운 메모리 공간(3)에 저장된다. 기존의 공간(2)에 'abc'는 메모리상에 그래도 남아 있는 것이다. 이렇게 변수에 값을 재할당을 한다고 해서 실제 메모리에 저장된 어떤 값을 변경하지는 않는다고 하여서 '불변성(Immutable)'이라 하는 것이다.

2. 상수(Constant) 의 변하지 않는 성질

 변수와 상수를 구분짓는 변경 가능성의 대상은 '변수를 저장한 메모리 영역'(1)이다. 즉 한 번 데이터 할당이 이루어진 변수 공간에 다른 데이터를 재할당할 수 있는지 여부가 관건. 즉 const abc = '1234' 했다면 abc = '5678' 등의 재할당 행위는 불가능하다는 것이다.