데이터 과학과 웹 페이지
웹 페이지를 만들어보다
하루에 한 가지 일에 2~3시간 온전히 몰입해라.
그날은 그것만으로도 성과가 있을 것이다.
그리고 이러한 날을 그렇지 않은 날보다 더 많이 있게 하라.
데이터 과학과 웹 페이지는 어떤 관련이 있을까?
바로 빅데이터이다. 데이터가 엄청나게 많아지면서 하나의 컴퓨터로는 데이터를 저장하고 처리하는 것이 불가능해졌다.
우선 지금의 컴퓨터 환경부터 살펴보자. 하드디스크(HDD)의 성능은 꾸준히 향상해왔다. 생산 가격도 하락하면서 빅데이터의 저장은 기술적, 비용적으로 불가능한 문제가 아니게 되었다. 하지만 보조 기억장치인 HDD는 처리 속도가 느린 단점이 있다. 이를 극복하기 위해서 컴퓨터의 실행 체계는 임시(주) 기억 장치를 사용한다. 바로 RAM(Random Access Memory)이라는 성능 좋은 메모리이다.
RAM의 단점은 용량이 작다는 것이다. 그래서 컴퓨터는 HDD에서 필요한 부분만 조금씩 떼어다가 RAM에 올려놓고 저장해 둔다. RAM은 운영 체제(Operation System, OS)에 데이터를 보낸다. 운영 체제는 연산을 담당하는 중앙처리장치(CPU)를 운영하는 윈도우나 리눅스와 같은 소프트웨어이다. 이러한 OS에도 메모리가 있다. 여기에 RAM이 보낸 정보를 받아놓고 CPU에게 연산을 명령한다.
요약하자면 HDD의 용량이 아무리 커져도 중간에 있는 RAM의 성능과 용량이 컴퓨터의 속도를 좌우한다.
문제는 RAM의 가격은 아직까지도 비싸는 점이다. RAM 생산에 관해서는 많이 들어보았을 것이다. 우리나라 기업인 삼성전자나 SK하이닉스가 생산하는 반도체가 바로 RAM이다. 이 기업들은 훌륭한 성능의 D램을 생산하면서 폭발적으로 성장했다. 하지만 RAM 성능의 향상 속도는 느려지고 있다. 가격도 어느 선 이하로는 낮아지고 있진 않다. 이제는 RAM의 성능을 올리는 것은 기술적으로 한계에 온 것이다. 게다가 초 고성능 RAM을 매번 사다 쓰기에도 비용적으로 더더욱 무리가 있다.
그렇다면 이제는 컴퓨터의 성능을 향상시키는 방법을 없을까? 좀더 싸게 좋은 성능을 낼 수는 없을까?
하나의 RAM의 성능을 높일 수 없다면 많은 RAM에게 일을 나누어서 시키면 되지 않을까?
이는 바로 맵리듀스라고 하는 분산처리 개념이다. 구글이 세계적인 기업이 된 이유 중 하나이다. 논리적으로 작업을 나누고 이를 물리적으로 떨어져 있는 RAM들이 처리한 다음에, 그 각각의 결과를 다시 합칠 수 있다면 불가능한 답이 아닌 것이다. 이를 해낸 것이 구글이다. 하둡(HADOOP)이라는 분산 처리 OS를 만들어낸 것이다.
자, 이제 해결책은 나누어서 일하는 것이다. 그렇다면 물리적으로 떨어져있는 컴퓨터들에게 작업을 나누어주고 그 결과를 다시 받으려면 무엇이 필요할까?
바로 통신(Communication)이다. 요즘은 IT (Information Technology)가 아니라 ICT(Information & Communication Tech)라는 말을 더 많이 쓰는 것은 이러한 이유이다. 각각의 컴퓨터에서 아무리 빨리 작업을 처리해도 그것을 다시 전송하고 받는 데에 오래 걸린다면 분산 처리는 의미가 없어진다. 다시 말해, 통신망과 통신 기술의 발달로 데이터를 주고 받는 것이 아주 빨라졌기에 분산 처리는 실현될 수 있었다.
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20130308082702&lo=zv40웹 페이지를 만들어보다
이번 5월에 2주에 걸쳐 JSP를 사용해 웹 페이지를 개발하는 팀 프로젝트를 진행했다. 개발하는 동안 웹을 공부를 하며 많은 어려움을 느꼈다. 특히 수많은 IT 용어에 압도 당하는 기분이었다. IT 관련 용어는 대부분이 영어로 되어 있으며 그것마저도 표준화되어 있지 않다. 특히 제대로 정리된 책이나 문서를 찾기가 쉽지 않다. 다행히 뒤늦게 공부를 시작한 셈이라 앞서간 선배님들 덕분에 맨땅에 헤딩은 아니었다. 그럼에도 궁금한 점은 구글 검색을 하며 찾아다녀야 했고 그게 올바른 것인지 틀린 것인지도 구분해야 했다.
하나의 컴퓨터만을 사용해왔기 때문에 통신은 잘 와닿지 않았다. 마치 공기 같은 존재랄까? 그동안 게임이나 웹 서핑을 하면서 주워들으며 꽤 친숙한 용어들도 있지만 하나 하나 살펴보면 제대로 알고 있는 것은 없었다. 그러나 웹 페이지를 만들면서 페이지 요청(Request)와 응답(Response)에 대해 조금이나마 이해할 수 있게 되었다. 서버와 클라이언트를 구분하게 되면서 서비스 로직과 비즈니스 로직을 구분하여 웹 페이지를 개발하는 것에 대하여 고민하게 되었다. 그리고 이는 SPRING이라는 훌륭한 웹 개발 프레임워크를 공부하게 되는 동기가 되었다. (다음 기회에 MVC의 개념과 더불어 스프링에 대해서 글을 쓰도록 하겠다.)
백문이 불여일견이라고 했던가. 직접 웹 페이지를 만들어보며 서버도 구축해보고 데이터베이스도 설계해보았다. 거대하게만 느껴졌던 IT가 윤곽은 보이는 느낌이 든다. 물론 지금도 장님이 코끼리 만지듯이 헤메이고 있다. 지금껏 손 놓고 구경만 하고 있었다는 생각에 후회도 조금 들었다.
그렇지만 만져본 게 어딘가?
https://dribbble.com/shots/747387-make-something웹 페이지 개발을 하며 느낀 점
JSP 공부 중인 초짜 중에 초짜인 세 명이 모여서 자유게시판 웹 페이지를 만들었다. 단순한 게시판을 만드는 데에도 엄청난 품이 든다는 사실을 알게 되었다. 당연하다고 생각했던 기능들이 절대 단순하지 않았다. 모든 문제가 복합적이었다. 또한 생산자로서(혹은 개발자로서) 제공할 기능과 사용자(소비자)에게 필요한 기능이 달랐다. 그렇기에 사용자의 행동도 예측하고 대응해야 했다.
JSP란?
JSP(Java Server Page)는 자바 서버 페이지의 약자로서 흔히 사용하는 웹 환경에서 작동되는 웹 어플리케션을 개발 할수 있는 도구
다루기 어려운 서버 언어인 서블렛을 자바 언어를 기반으로 제어할 수 있게 해주는 프로그램
http://javacpro.tistory.com/43첫째, 단순한 기능은 없다
기본 중에 기본이라고 생각했던 로그인 기능도 만만하지 않았다.
HTML(Hyper Text Markup Language)에서 로그인 form을 만들어 사용자에게 아이디와 비밀번호를 받아서 메인 페이지로 넘기는 것 자체는 쉽다. 단순히 input 태그 두 개만 쓰면 되는 일이기 때문이다. 하지만 사용자는 어떻게 기능이 구현되어 있는지 모른다. 아이디에 특수문자를 써도 되는지 비밀번호는 몇 자인지 처음 들어온 사람이 알 수 있는 방법은 없다. 이외에도 사용자의 행동을 예측할 건 많다. 기존 사용자와 중복되는지 혹은 아무것도 입력하지 않은 채 가입하기 버튼을 누르면 어떻게 해야 하는지 등등...
데이터베이스에
아이디와 비밀번호를
저장하는 것이 전부는 아니다.
회원정보 관리도 생각보다 복잡하다. 아니, 복잡할 것도 없는데 그 기능을 구현하고 이해하는 것이 쉽지 않다. 예를 들면, 사용자가 로그인을 할 때에 회원정보를 받아와야 한다. 그리고 입력받은 아이디가 가입된(저장된) 아이디에 일치 여부를 확인해야 한다. 또한 일치한 아이디에 해당하는 비밀번호가 맞는지도 확인해야 한다.
회원을 확인(Identify)하는 방법도 여러 가지이다. 서버 페이지에서 확인하는 방법이 있고, DBMS에서 확인해서 정보가 있는지 없는지 여부만 가져오는 방법도 있다.
굳이 서버 페이지에 함수를 넣어서 복잡해 보이는 코딩을 하기 싫었다. 그래서 후자의 방법을 사용했다. SELECT 쿼리문 자체에서 WHERE 절을 이용해 입력받은 아이디와 비밀번호가 동시에 일치하는 데이터가 있으면 가져온다. 이는 논리가 간단하면서도 코딩의 길이도 짧았다. 반환값이 오면 로그인이 되는 것이고, 오지 않으면 로그인을 거부하면 된다.
그러나 이 방법은 사용자에게 불편함을 준다. 사용자는 입력한 아이디가 잘못되었는지, 비밀번호가 잘못되었는지를 알 수 없기 때문이다. 물론 요즘은 보안강화로 인해 로그인 실패시 많은 정보를 주지는 않고 있다.
이처럼 사용자에게 편의성을 주기 위해서는 신경 쓸 것이 많다. 회원가입할 때 정보를 받아서 DB에 insert 쿼리만 날리는 기능을 만든다고 해보자. 이 경우 DB 조건에 안 맞는 값일 경우에 오류가 난다. 그러나 당연히 사용자는 이를 모른다. 그렇기에 오류가 날 수 있는 기능을 사용자 책임으로 두면 안 된다. 미리 검사를 해서 사용자가 오류를 만나지 않도록 해야한다.
예를 들어, 아이디 중복 검사 기능은 단순히 중복검사만 하는 것이 아니라 검사된 아이디를 사용자가 변경하지 못하게 해야한다. 검사 후에도 사용자가 아이디를 바꿀 수 있게 한다면 결국 오류가 나기 때문이다.
비밀번호를 입력받을 때에도 하나의 input 태그로만 받는 게 아니라 비밀번호 확인을 만들어서 사용자가 입력한 비밀번호를 확실하게 인지하게 해주여야 한다. 잘못 입력하는 경우까지 생각해야 했던 것이다.
물론 비밀번호를 잘못 입력하더라도 가입하는 기능 자체에는 문제가 없지만 사용자는 로그인을 하지 못해 페이지를 이용하지 못한다면 애써 개발한 나에게도 좋지 않은 일이다.
컴퓨터는 똑똑하지만 멍청하다.
시키는 일만 한다.
그래서 단순한 기능이란 없다.
http://egloos.zum.com/isao76/v/2584187둘째, 디테일은 언제나 아쉽다
게시판 기능도 까다로운 면이 있다. 이 부분은 내가 직접 개발한 부분은 아니었지만 코딩을 merge하며 자연스럽게 들여다보게 되었다. 그리고 담당하는 팀원이 개발하면서 막히면 같이 논의하며 수정했기에 수없이 코딩을 읽게 되었다.
글 작성, 수정, 삭제, 검색까지 게시판의 기본적인 모든 기능을 구현했다. 하지만 시간 제약 때문에 구현하지 못했던 기능은 삭제를 할 때에 본인이 작성한 글만 삭제가 될 수 있어야 하는 기능이다. 실상 로그인만 하면 누구나 어떤 글이든 수정, 삭제할 수 있었다. 로그인시 누가 로그인했는지 알 수 있도록 아이디를 세션에 저장했기에 조금만 더 하면 충분히 개발할 수 있는 기능이였는데 아쉽다.
다만, 글 작성시에 사용자가 입력하지 않아도 본인의 아이디로 글이 저장되도록 하는 기능은 구현했다. 이는 처음에 생각해보지 않은 디테일이였다. 어떤 게시판은 글 작성할 때에 글마다 비밀번호를 아예 사용자한테 받는 게시판도 있다. 왜 그런가 했더니만 이렇게 관리하는 것이 더 개발자 입장에서 편리하기 때문이다. 사용자가 로그인 한 후에 그 사용자를 파악해 작성자와 비교를 하여 삭제가 가능한지를 검사해야 한다.
더 사용자에게 편리한 기능이라면 사용자가 작성자와 일치하는 경우에만 글 삭제나 수정 버튼이 보이게 하는 것이 더 사용자에게 편리한 기능일 것이다. 다만 글 작성시마다 비밀번호를 입력받아 관리하려면 DB 테이블에 하나의 컬럼을 더 추가해야 한다.
개발을 할수록, 공부를 더 할수록 아쉬운 점이 계속 눈에 보인다.
하지만 이에 사로잡히면 안 된다.
SHOW MUST GO ON.
http://socialdistillery.com/more-facebook-news-feed-updates-the-show-must-go-on/셋째, 데이터베이스 설계의 중요성
데이터베이스 설계가 철저하지 못했다. 기능을 개발한 후 한참 뒤에 외래키(FK) 문제가 발생했다. 처음엔 쿼리문 문제인줄 알고 시간낭비를 꽤 했다. 하지만 DB설계가 문제였다. 내가 개발한 부분은 회원탈퇴 기능이었다. 그래서 DB에 DELETE 쿼리만 날리게 하면 된다고 생각했다. 그래서 그 기능을 구현했고 테스트할 때에도 문제가 없었다.
하지만 이럴수가!
게시판에 글을 작성하면 회원탈퇴가 불가능했다. 회원정보 테이블에서 게시판 테이블이 외래키(FK)를 따서 가져갔기 때문이다. FK는 제약조건이기 때문에 세세하게 설정할 필요가 있었다. DBMS(데이터베이스를 관리하는 소프트웨어, Data Base Management System)는 외래키가 설정된 데이터는 다른 곳에서도 쓰이는 중요한 데이터라고 인식하기 때문에 함부로 삭제하지 못하게 해놓는다. 그래서 FK가 설정되면 내 데이터긴 하지만 함부로 삭제하지 못한다.
삭제가 가능하게 하려면 DB설계를 다시 해야 했다. FK 제약조건을 ON DELETE NO ACTION이 아니라 CASCADE로 해야 한다. CASCADE는 폭포라는 뜻으로 상위의 키가 사라지면 키를 참조했던 테이블의 데이터들도 삭제되는 것을 뜻한다.
또한 삭제가 된 아이디에 NULL이 아니라 그 아이디가 그대로 게시판에 남아있게 하려면 다른 기능을 추가해야 한다. 오라클 DB에서는 제공하고 있지만 MySQL은 DEFAULT 기능을 제공하고 있지는 않다. 이는 키가 삭제되면 비워져있다는 뜻인 NULL이 아니라 설정한 디폴트 값으로 대체해주는 기능이다. 다시 말해, 오라클 DB였다면 제약조건만 재설정하면 되겠지만 MySQL은 트리거를 구성해야 한다는 뜻이다. 트리거까진 구성하진 않았는데 앞으로 공부해야할 필요성은 충분히 느꼈다.
DB 문제는 생각보다 중요하다.
올바른 설계는 까다롭고 어렵다.
사실 작은 게시판을 만들면서 DB가 문제가 될 것이라고는 전혀 생각하지 못했다.
https://sc.greenart.co.kr/curriculum/curriculum_detail.asp?idx=6288넷째, 프레임워크의 필요성
서비스 로직과 비즈니스 로직을 구분해야 한다. 왜냐하면 하나의 파일로만 작업하는 것은 페이지가 작동하지 않을 때 매우 곤란한 상황을 초래한다. 어느 기능이 문제인지를 알 수가 없기 때문이다. 서비스 로직은 사용자에게 보여지는 부분을 말한다. 반면에 비즈니스 로직은 사용자가 볼 수는 없지만 사용자가 입력한 정보들을 처리해서 다시 서비스 로직으로 보내는 부분이다.
만약에 보여주고 싶은 기능이 안 보인다면 서비스 로직 자체가 잘못된 것일 수도 있지만, 비즈니스 로직이 잘못되어 서비스 로직으로 값을 못 보낸 경우일 수도 있다. 이처럼 서비스 로직 페이지와 비즈니스 로직 페이지는 서로 값을 주고 받도록 연결이 되어야 한다.
웹 페이지를 개발하며 가장 어려웠던 점은 페이지끼리의 연결이다. 하나의 컴퓨터만 사용해왔는데 값을 주고 받는다는 개념조차 상상해보지 못했기 때문이다. 그냥 내 컴퓨터에 저장하면 되는거 아니야? 이 정도 생각뿐이었다.
하지만 페이지는 독립 공간이다. 연결해주지 않으면 전 페이지와 뒤 페이지는 전혀 상관없는 공간이다. 연결을 한다는 것은 전 페이지에서 작업한 값을 뒤 페이지에서 받을 수 있게 해주는 것이다. 페이지끼리 값을 주고 받도록 코딩하는 일은 머리가 참 아프더라.
또한 프론트 엔드와 백 엔드의 개념을 정립하기가 어려웠다. 하지만 이번에 페이지 처리에 골머리를 썩다보니 어느 정도는 이해가 되었다. 그리고 MVC 개념에 대해서 공부할 수 있는 계기가 되었다.
왜 웹 개발에서 스프링을 사용하는가?
개발 규모가 커질수록 마구잡이식 개발보다 정형화된 프레임워크를 쓰는 것이 편하기 때문이다.
다섯 째, 유지-보수는 언제나 필요하다
개발은 혼자하는 것이 아니다. 그리고 한번에 하는 것이 아니다. 그래서 유지-보수가 필요하다. 이를 제대로 느꼈다. 그래서 객체 지향 언어의 장점을 알게 되었다. 객체 지향 언어는 직관적이다. 그래서 개발을 함에 있어서 굉장히 개발자를 편하게 해준다. 자바를 배우며 그 장점이 코드의 중복성 감소라는 것은 외우기만 했지 와닿지 않았었는데 개발을 해보면서 중복성 감소의 강점을 알게 되었다.
절차 지향이라고 하면 순서에 따라서 개발을 해야 하는데 이는 여러 명이서 개발할 때에 엄청난 불편을 가져 온다. 윗 부분에 해당하는 로직을 담당한 사람이 코딩을 하지 않으면 아랫 부분 로직을 코딩하는 사람은 코딩을 돌려볼 수가 없다. (물론 절차 지향은 객체 지향 언어보다 처리 속도가 빠르다는 장점이 있다. 구글에서 진행하는 자율주행자동차는 절차지향언어인 C로 개발되고 있다고 한다. 모든 언어는 장단점이 있다는 점 분명히 말씀드리고 싶다.) 예를 들면, 메인 페이지를 개발하는데 아직 공지사항 게시판, 질문 게시판, 자유 게시판 영역이 개발되지 않은 상태였다. 해당 페이지의 기능이랑 파일명도 몰랐지만 임시로 그 이름을 정하여 코딩을 하고 시험삼아 코딩을 돌려보며 개발할 수 있었다. 이는 객체 지향 언어가 아니였다면 불가능했을 것이다.
또한 코딩을 유지-보수를 하는 데에도 편리하다. 페이지에서 어떠한 기능이 돌아가지 않으면 그 기능을 담당하는 코드만 수정하면 된다. 처음부터 코딩을 다시 훑어보는 시간을 줄여주는 것이다.
http://www.ciokorea.com/news/24505여섯 번째, 개발 환경과 형상 관리
개발 환경을 통일하는 문제는 중요하다. 그냥 내 컴퓨터에서 돌아간다고 남의 컴퓨터에서 돌아가지 않는다. 처음엔 파일 디렉토리부터 파일명명까지 개발 환경을 통일할 생각을 못하고 각자 개발했다. 그러다 보니 코딩을 합치는(merge) 데에 시간과 품이 너무 많이 들었다. 결국은 중간부터 깃허브(gitHub)를 도입했다. 깃허브에 능숙하건 아니건 간에 형상 관리의 최고의 도구는 깃허브이다. 혼자 코딩할 때에도 다음날 보면 내가 코딩했나 싶을 정도로 낯설다. 다른 사람의 코딩을 볼 때엔 더더욱 그 어려움은 커질 것이다. 그렇다고 개발을 하면서 일일이 주석을 달아서 남들이 알아보기 쉽게 하는 것도 어려운 일이다. (물론 주석을 다는 것은 굉장히 중요하다) 이를 도와주는 것이 깃허브이다.
다음은 내가 사용한 환경과 버전 관리를 적어둔 것이다.
개발 환경:
운영체제 - Window 10
소스작성도구 - Eclipse
WAS - Tomcat 8.5
데이터베이스 - MySQL 6.3
형상관리도구 - Google Drive, GitHub
FRONT-END Language - HTML5, Javascript
BACK-END Language - JSP, JAVA SE 8
버전관리:
구글 드라이브로 버전 관리했던 주소입니다. (보기전용)
깃허브 - (연습)(최종) 몇 번하다가 branch 꼬여서 merge 실패했다. Repository를 새로 만들다보니 초기 commit이 사라짐...
RAM에 대한 간단한 정보
램 (RAM) 임시기억 장치
(출처: 네이버 사전)
메모리는 크게 램(RAM)과 롬(ROM)으로 나뉜다. RAM은 기억된 정보를 읽어내기도 하고 다른 정보를 기억시킬 수 있는 메모리이다. 'Random Access Memory'의 약자로 전원이 끊어지면 휘발유처럼 기록된 정보도 날아가기 때문에 휘발성 메모리(Volatile Memory)라고 한다. 따라서 RAM은 컴퓨터의 주기억장치, 응용 프로그램의 일시적 로딩(loading), 데이터의 일시적 저장 등에 사용된다. 기존의 자기를 이용한 자기 코어와 달리 TR(트랜지스터)를 집적한 IC를 이용하여 기억소자로 사용하고 읽을 때 순차적이 아닌 랜덤하게 읽을 수 있기 때문에 읽기 또는 쓰기 속도가 매우 빠르다. 기록과 해독의 두 회로가 있어서 정보의 기록, 해독이 가능하고 컴퓨터나 주변 단말기기의 기억장치에 널리 쓰인다. 대표적인 RAM의 종류에는 DRAM, SRAM이 있다.
D(Dynamic)램은 전원이 차단될 경우 저장되어 있는 자료가 소멸되는 특성이 있는 휘발성 기억소자이며, 시간이 지나가면 축적된 전하가 감소되기 때문에 전원이 차단되지 않더라도 저장된 자료가 자연히 소멸되는 단점이 있다. 따라서 지속적으로 재기록할 수 있고 저장용량이 커서 PC의 주요 메모리로 쓰인다. 256메가D램 제품의 경우 데이터 저장용량은 신문지 2100장, 원고지로 따지면 8만4000장에 달한다. 얼마 전까지 일반 S(Synchronous)D램이 주로 쓰였는데 요즘에는 PC업체들이 이 제품보다 데이터 처리 속도가 2배 더 빠른 DDR(더블데이터레이트) SD램을 주기억장치로 채택하고 있다.
S(Static)램은 전원이 공급되는 한 기억된 데이터가 지워지지 않는다. 플립플롭 방식의 메모리 셀을 가진 임의 접근 기억장치로서 전원 공급이 계속되는 한 저장된 내용을 계속 기억하며, 복잡한 재생 클록(refresh clock)이 필요 없기 때문에 소용량의 메모리나 캐시메모리에 주로 사용된다. 소비전력이 적고 D램에 비해 정보처리속도가 6배나 빨라 주로 PC의 수치계산 용도로 이용된다. 교환기의 메모리로도 활용된다.
Dynamic RAM
(출처: 나무위키)
IBM이 1964년 개념을 창안하고, 1966년 시제품을 개발해 DRAM에 대한 특허를 취득했다. 최초의 DRAM 상용 제품은 1969년 이 특허의 사용권을 취득해 AMD에서 나왔다. DRAM에 대한 IBM의 특허권은 개선 제품이 나올 때마다 계속해서 갱신되어 2017년인 현재도 유효하여, 대한민국의 삼성전자나 SK하이닉스에서 이 특허를 사용한 칩을 제조할 때마다 일정 금액을 IBM에 지급해야 한다.
동적 램은 기록된 내용을 유지하기 위하여 주기적으로 재충전(Refresh)이 필요하다. 기본적으로 캐퍼시터(Capacitor)로 이루어지며 이것의 충전 상태로 정보를 기록한다. 계속 재충전해야 하는 이유는 캐퍼시터가 시간이 지나면 저절로 방전되기 때문.
동적 램은 속도가 SRAM보다는 느리지만 구조가 간단하여 집적도를 쉽게 높일 수 있다. SRAM이 보통 트랜지스터 사이에서 루프를 돌리고 '상정되지 않은 입력'을 걸러내는 게(SDRAM의 경우 클럭에 대한 반응도) 필요한 플립플롭의 구조상 최소 4개 이상으로 셀 하나를 만들지만 DRAM은 트랜지스터 하나와 캐패시터 하나로 만들어져 있기에 고집적화가 가능하다. 또한 정적 램에 비해서 가격이 매우 싸고 전력 소비도 그렇게 많지 않아 CPU의 주 기억 장치로 가장 많이 사용되고 있다. 파워 서플라이와 같은 다이오드 계열이 기초 소자 중 가장 비싸다.
우리가 말하는 모든 '램'은 전부 DRAM이다. DRAM 구조에 따라 DDR이니 SD이니 RD이니 붙는 것.
