ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • DEVGROUND JUNIOR 2019 참여 후기 (4)
    IT행사 2019. 12. 19. 14:14

     

    DEVGROUND JUNIOR 2019 참여 후기 (1) 

       개발자가 갖추어야 할 9가지 기술 / AI: 막막해하는 당신에게 

    DEVGROUND JUNIOR 2019 참여 후기 (2)

       내가 주니어 개발자 때 알았더라면 좋았을 것들 / 성장을 바라는 웹 프론트엔드 개발자를 위한 제언

    DEVGROUND JUNIOR 2019 참여 후기 (3) 

      오픈소스 속에서 성장하기  / 절망 드리븐 성장: 함께 일하고 싶은 개발자가 되기까지

    DEVGROUND JUNIOR 2019 참여 후기 (4) - 현재 글

      개발자도 DB 모델링을 알아야 할까요? / AI/데이터 시대를 사는 개발자를 위한 생존 가이드


     

     

    개발자도 DB 모델링을 알아야 할까요?

    용영환 잇츠팩토리

    •  

      개발자와 DB모델링? 서로 관련이 없어 보이지만 그렇지 않다. 나 또한 잘못 설계한 데이터베이스 모델로 고생해본 적이 있기 때문에 (사실 아직 고생ing) 이 세션을 선택했다. 

     

    모든 것의 본질은 DATA

     

    https://drive.google.com/file/d/1fNONNGSGFvsHG0r6-T6LW0rh3jsMCZMN/view

     

     웹 개발자, 모바일 개발자, 백엔드 개발자 등 모든 직군에서의 본질은 데이터이다. 

     개발 직전, 화면 계획서를 딱 받았을 때 가장 먼저 해야 하는 일은 바로 데이터 요소를 뽑아내는 것이다. 그리고 어떻게 효율적이게 저장할지 저장의 형태에 대해서 고민해보아야 한다.

     

    소프트웨어를 만드는 과정

     1. 무엇을 만들지 정한다. -> 데이터 범위를 정한다.

     2. 요구사항을 정리한다. -> 데이터 요소를 정한다.

     3. 어떤 환경에 대응할지 정한다. -> 데이터 사용자를 정한다.

     4. 사용자가 어떤 흐름으로 사용할지 설계한다. -> 데이터 흐름을 설계한다.

     5. 화면을 설계한다. -> 데이터를 표현한다.

     6. 어떻게 만들지 정한다. -> 데이터 환경을 정한다.

     7. 실제로 구현한다. -> 데이터를 제어한다.

     

     소프트웨어를 만드는 과정의 전반은 모두 데이터와 관련되어있다.

     소프트웨어를 만든다는 것은 곧 데이터를 제어한다는 것이다.

     결국, 데이터는 우리 모두의 공통 사항이다.

     

    DB 모델링은

     DB 모델링은 소프트웨어 본질에 더 깊게 다가가는 과정이라고 한다.

     숲과 나무를 모두 보기 위한 방법이다.

     

    ERD

     ERD(Entity-Relationship Diagram)은 데이터 간의 관계를 그림으로 표현해준다.

     

     

     이러한 테이블 형태의 데이터를

     

     

     데이터간의 관계를 기준으로 표현해준다. 

     테이블과는 다른 관점으로 데이터를 바라볼 수 있게 되고, 전체 구조를 파악하여 데이터를 예측할 수 있게 된다.

     

    DB 모델링의 이점

     DB 모델링을 하게 되면 '전체'를 볼 수 있게 된다고 한다. 용영환 님의 경우에는, 구현 전에 ERD를 그리는 습관을 만들었더니 자연스럽데 회사 안에서 전체 구조를 가장 잘 알게 되었다고 한다. 😮

     DB모델링은 곧 논리 모델이라고 한다. 어렵게 생각할 것이 아니라, 구현 전에 종이에다가 테이블 구조를 끄적거리는 것도 DB모델링이라고 한다. 더 잘하고 싶다면 ERD 전문 설계 툴을 사용하면 된다.

     

    더 공부하면 좋을 것

     - DBMS의 동작 원리 

     - SQL 쿼리와 튜닝

     - UML

     

    DB 관련 책

     한빛미디어 책이 엄청 잘 나와있다면서 추천해주셨다 ㅋㅋㅋㅋ 🤣

    https://book.naver.com/bookdb/book_detail.nhn?bid=9585476

    프로젝트 성패를 결정짓는 데이터 모델링 이야기

    멘토가 들려주는 따스한 데이터 모델링 이야기 객체지향과 패턴의 원리를 이해하면 코딩에 자신감이 붙듯, 데이터 모델링도 그 본질적 원리를 제대로 깨우치면 어떤 과제든 완수할 수 있다는 자신감이 생긴다. 이 책은 공학과 철학을 넘나들며 다른 책에서 충분히 다루지 않은 모델링의 본질적 이야기를 담았다. 저자가 친절히 그려준 책 구성 지도(책 8~9페이지)를 함께 보며 엔터티 정의부터 관계, 코드 속성 표준화, 유연성 등 추상적이고 어렵게만 느껴지던 개념들을 명

    book.naver.com

    https://book.naver.com/bookdb/book_detail.nhn?bid=10160776

    SQL 레벨업

    『SQL 레벨업』은 《SQL 첫걸음》으로 성공적인 입문을 마치고, 다음 고지를 바라보는 이들을 위한 책이다. 고성능 SQL 작성 방법을 초보자 눈높이에 맞춰 다양한 예제를 통해 설명한다. 특히 오라클과 호환성을 목표로 하는 오픈소스인 POSTGRESQL을 사용하여 모든 예제를 작성했고, 둘의 수행 결과가 상이한 경우에 대해서도 설명한다. 값비싼 오라클이 없어도 엔터프라이즈급 데이터베이스를 다루는 데 필요한 기술을 누구나 경험할 수 있다.

    book.naver.com

     

    Q&A

    Q. DB모델링을 작성한 뒤, 피드백을 받을 방법이나 검증 방법이 있다면?
    A. 쿼리 자체의 문제는 DB모델링 툴에서 SQL 에러를 알려준다. 하지만 논리적인 관계, 컬럼 설계가 잘못되었을 때는 인간이 판단할 수밖에 없다. 이렇게 디버깅이 쉽지 않은 점에서 데이터를 잘하는 사람이 많지 않고, 데이터를 잘 하는 것이 중요하다.
    Q. ERD 툴을 추천한다면?
    A. MySQL을 사용한다면, MySQL workbench / ERWin

     

     


     

     

    AI/데이터 시대를 사는 개발자를 위한 생존 가이드

    임백준 삼성전자

     마지막 세션은 삼성전자의 임백준 님이 진행해주셨다. 현장 분위기를 보니, 많은 분들이 임백준 님의 강의를 기다리셨던 것 같다.

     

     임백준 님은 막 입사했을 시절에 매우 두꺼운 Oracle 7.0 책을 읽었다고 한다. 그냥 읽은 정도가 아니라 거의 암기할 정도로 읽으셨다고 한다. 그 당시에는 이러한 책을 통하지 않고서는 개발에 대한 정보를 접하기 쉽지 않은 시대였다.

     그러나 Jeff Atwood, Joel Spolsky가 스택오버플로우를 만들었고, 많은 것이 바뀌었다. 두꺼운 책을 보며 프로그래밍을 하던 일명 '선사시데'에서, 온라인으로 질문을 하며 프로그래밍을 하는 '르네상스'시대로 발전한 것이다. 코딩이 더 재미있어졌다. 실제로 스택오버플로우는 게임적 요소를 차용해서 코딩을 재미있는 행위로 만들고자 했다고 한다.

     

    Humans Need Not Apply

    https://www.youtube.com/watch?v=7Pq-S557XQU

     임백준 님은 동영상 하나를 소개해줬다. 임백준 님도 동료들과 함께 돌려보며 충격을 받았던 동영상이라고 한다.

     이 영상에서는 인조 지능과 인조 노동자의 탄생에 대해서 이야기한다. 인공지능의 발전이 계속되다 보면, 인간이 로봇의 능력을 통제할 수 있는 능력이 상실될 것이라고 말한다. 이미 인공지능 기술을 가지고 있는 소수의 사람들에게 부가 집중되고 있고, 빠른 시일 안에 인공지능 기술을 갖고 있지 않은 회사들은 도태될 것이다. 이것은 기술의 문제를 떠나, 인간으로서 생존에 관한 문제이다.

     

     

    Software 2.0

     Andrey Karpathy에 의해 만들어진 용어이다. 우리가 알고 있는 프로그래밍은 Software 1.0이며, 컴퓨터 스스로 로직을 만드는 것이 Software 2.0이라고 한다. 아직 찬반 논의점은 많지만, 앞으로 굉장히 많은 프로그래밍이 Software 2.0 이 될 것이라고 한다.

    Software 2.0은 Software 1.0에 비해서  Program Space가 매우 넓다. 여기서 Program Space는, 그 코드로 풀 수 있는 문제 영역을 말한다.

     

     

    Software 2.0 시대의 코딩은 먼저 풀고자 하는 문제와 목적을 정한 뒤 뉴럴 네트워크 아키텍처를 설계하고, 컴퓨터에게 일을 맡기는 방식으로 진행될 것이라고 한다.

     

    Software 2.0에는 두 종류의 프로그래머가 존재할 것이다.

      1. 전통적인 코딩을 하는 프로그래머

         - Software 2.0 개발자가 작업하는 환경이나 툴, 분석, 시각화, 인프라를 제공한다.

     2. Software 2.0 프로그래머

         - 데이터 정제, 레이블링, 전처리, 연계 통합관리를 한다.

     

     

    Survivla Guide

     이런 시대에서 살아남기 위해선 어떻게 해야 할까?

     배워야 하는 것은 너무나도 많다. (언어, 프론트엔드 프레임워크, 데이터 엔지니어링, 데이터 Analytics, 딥 러닝, 클라우드, Git, 애자일...)

     하지만 이 모든 것을 아는 사람은 세상에 존재하지도 않고, 세상이 필요로 하지도 않는다.

     DevOps란, 모든 것을 경험해 본 사람이 아닌, 하나만 알아도 다 잘할 것 같은 사람이라고 한다.

     

     Fundamental을 공부해라

      프레임워크나 API는 길어야 3년이다.

      패러다임이나 패턴, 리팩토링, TDD, Principle은 10년 이상 간다.

      인간 자체가 가지고 있는 문제 해결 능력은 평생 간다.

         문제 해결 능력은 "습관화와 태도"의 문제라고 한다. 추상적이게 느껴지지만, 매우 중요한 문제이다.

     

     올바른 습관과 태도

      Fake it till you Make it

      될 때까지 그런 척하면 된다. = 일단 도전하고 보자.

      

      Job vs Career

       항상 Career의 관점에서 넓게 생각해보자.

     

      People Skill

       개발만 잘해서는 되지 않는다. People Skill이 커리어에 결정적인 역할을 한다.

      

      Add value to others

       우리는 왜 일을 하는가? 내 일이 다른 사람에게 가치를 제공할 때 일의 본질이 생긴다.

     

      Don't be afraid to liik like an idiot

       질문하는 것을 두려워하지 말라.

     

      함께 일하고 싶은 사람이 되자

       밝은 에너지, 태도로 정확하고 명쾌한 커뮤니케이션을 하자.

     

    프로그래밍의 본질은 팝콘을 튀기는 것이다!

     전자레인지로 팝콘을 튀기고 싶을 때, 전자레인지에 대해서 전부 공부해야 할까? 전자공학을 공부하고, 물 분자의 회전에 대해서 이해하고 있어야 할까? 아니다. 그저 전자레인지의 사용법만 알고 있으면 된다.

     그런데 사람들은 왜 무턱대고 머신러닝에 대해 만드는 법을 공부할까? 임백준 님은 머신러닝, 딥러닝, 알고리즘을 '이용해서' 흥미로운 것을 만들어 내는 것이 더 중요하다고 말한다. 문제를 먼저 보고, 문제를 해결하는데 필요한 기술을 익히면 되는 것이다.

     

     

    Q&A

    Q. 문제 해결 능력을 구직활동에서 증명할 수 있는 방법이 있는가?
    A. 자신감이 있어야 한다. 당당한 태도와 알면 안다, 모르면 모른다고 말하는 시원한 커뮤니케이션이 중요하다.
    Q. Fundamental을 잘 관리하는 방법이 있다면?
    A. 구체적인 방법은 일반화하기 어렵다. 태도, 커뮤니케이션, 자존감의 문제이다.

     

     

    댓글

Designed by Tistory.