꼽행착오

Build Tool 이란, 프로젝트 내에서 소스 코드를 가지고 실행 가능한 Application 을 자동으로 생성해 주는 도구이다. 빌드에는 소스 코드를 컴파일하고 링크 및 패키징을 통해 실행 가능한 형태로 변환하는 것이 포함된다.

기본적으로 빌드의 자동화는 소프트웨어 개발자가 다음과 같은 일상적으로 수행하는 다양한 작업을 스크립트화 하거나 자동화하는 행위로 볼 수 있다.

• Downloading Dependencies
• Compiling Source Code into Binary Code.
• Packaging that Binary Code.
• Running Tests.
• Deployment to Product System.

그렇다면, 이러한 빌드 툴은 왜 사용하는 것일까?

소규모의 프로젝트에서는 위와 같이 의존성이 있는 라이브러리나 API 를 직접 설치하고, 소스 코드를 빌드하고 실행하는 것이 큰 문제가 되지 않는다. 하지만 프로젝트의 규모가 커지고, 소스 코드가 방대해질 경우에 각각의 라이브러리들을 일일히 설치하고 사용하는 것은 프로젝트를 수행함에 있어 불필요한 업무의 비중이 높은 것으로 생각될 수 있다. 개발자는 이러한 불필요한 업무를 하지 않기 위해, 자동으로 의존성을 관리하고 소스를 빌드할 수 있는 도구를 사용하는 것이다.

Gradle / Maven

그럼 Java Application 에서 사용하는 Build Tool 은 무엇이 있을까? 대표적으로 Ant, Gradle, Maven 이 있다.

이 중 내가 비교할 것은 Gradle 과 Maven 이다. Ant 는 초기 Java 의 빌드 툴이고, 이를 보완해서 등장한 것이 Maven 이기 때문이다.

우선, Maven 은 pom.xml 을 이용해 정형화된 빌드 시스템을 제공한다. 또한 프로젝트에 대한 정보를 제공하고 개발 가이드라인을 제공한다. 물론 Build Tool 이기에, 새로운 기능을 쉽게 설치하고 업데이트할 수도 있다.

다른 Build Tool 인 Gradle 은 Maven 에 비해 최근 출시된 Tool 로, Ant 와 Maven 의 장점을 모아서 개발되었다고 한다. Build 라는 동적인 요소를 XML 로 정의하는 것에는 설정한 내용의 가독성이 떨어진다거나 의존관계가 복잡한 경우 등의 한계가 있었다. Gradle 은 Maven 과 달리 Groovy 를 사용하기 때문에 동적인 빌드의 경우 Groovy 스크립트로 플러그인을 호출하거나 코드를 직접 짤 수 있다. 또한, 성능적으로도 차이가 있는데 Gradle 이 Maven 에 비해 최대 100배 빠른 성능을 보여준다고 한다.

Gradle 의 단점이라고 한다면, Groovy 문법에 대해 새롭게 공부를 해야 한다는 점으로 볼 수 있을 것이다. 하지만 개발자로서 새로운 것을 배우는 것은 항상 거쳐가야 하는 단계라고 생각을 하기도 하고, 굳이 더 좋은 Gradle 이 있는데 Maven 을 사용해야 할 이유도 없어 Gradle 을 일반적으로 사용하게 될 것 같다.

관계형 데이터베이스 (RDB ; Relational DataBase)

글을 적기에 앞서 우선, RDB 가 무엇인지부터 얘기해 보려고 한다. RDB 란 Relational DataBase 즉, 관계형 데이터 모델에 기초를 둔 데이터베이스이다. 여기서 관계형 데이터 모델이란, 자료를 2차원 구조의 테이블 형태로 표현하는 것을 말한다.

간단한 예로, 학생들의 정보를 저장한다고 할 때 다음과 같이 표현을 할 수 있다.

이러한 관계형 데이터 모델에서 사용되는 용어는 다음과 같다.

- 릴레이션 (Relation) : 데이터들을 2차원 테이블의 구조로 저장한 것.

- 속성 (Attribute) : 릴레이션의 열(=Column), 개체를 구성하는 속성들.

- 튜플 (Tuple) : 릴레이션의 행(=Row), 속성들의 집합이며 레코드(Record) 라고도 부름.

- 차수 (Degree) : 릴레이션을 구성하는 속성 수(열의 개수)

- 카디널리티 (Cardinality) : 릴레이션에 입력된 튜플의 수

RDBMS 는 이런 RDB 를 관리하기 위한 소프트웨어라 정의할 수 있다. SQL 이라는 구조화된 질의어를 사용해 RDB 를 생성하고, 관리할 수 있는데 대표적으로 MySQL, Oracle DB, Maria DB 등이 있다.

MySQL

우선, MySQL 은 세계적으로 널리 사용되는 오픈 소스 DBMS 이다. 오픈 소스이기 때문에 무료로 사용이 가능하고, 다양한 운영체제에서 여러 가지의 프로그래밍 언어와 사용할 수 있다. 널리 알려진 표준 SQL 형식을 사용하며 크기가 큰 데이터의 집합도 빠르고 효과적으로 처리가 가능하다.

MySQL 은 CLI 를 통해 사용할 수도 있고, MySQL 에서 공식적으로 개발/지원하는 MySQL Workbench 를 사용해 GUI 를 활용할 수도 있다.

Oracle DB

Oracle DB 는 오라클 사의 관계형 데이터베이스 관리 시스템의 이름이다. 현재 유닉스 환경에서 가장 널리 사용되는 RDBMS 라고 한다. 검색이나 업데이트를 위한 언어로 SQL 과 PL/SQL 을 지원한다.

* PL/SQL 은 오라클 DB 에서 SQL 언어를 확장하기 위해 사용하는 컴퓨터 프로그래밍 언어 중 하나이다. 주로 자료 내부에서 SQL 명령문만으로 처리하기에 복잡한 자료의 저장이나 프로지서 / 트리거 등을 작성하는 데 쓰인다고 한다. 

MySQL vs. Oracle DB

MySQL 과 Oracle DB 중 무엇을 사용할 것인가?

오라클은 일반적으로 충분히 큰 예산과 복잡한 비즈니스적 요구, 기업 고객을 위해 설계되었다. 반면, MySQL 은 가장 일반적으로 데이터베이스 기반 웹 사이트나 Non-Critical 애플리케이션을 위해 사용되는 저가의 데이터베이스이다.

Oracle DB 의 특징

오라클 DB 의 특징은 아래와 같이 크게 5가지로 표현할 수 있다.

• Oracle Management Server
  • 오라클 DB 는 중앙 집중 방식으로 Administration Monitoring 이 가능하고, Multiple Database 를 튜닝할 수 있다.
  • 다른 Admin User 들과 공유가 가능하다.
• Oracle Change Manager
  • 변경 Plan 을 작성하고 실제로 구현하기 전에, 변경 사항의 효과를 볼 수 있다.
  • 생산 시스템을 방해하지 않는다.
• Administrative Alerts
  • 오류 발생 시 오라클은 이메일이나 설정되어 있는 계정으로 연락을 줄 수 있다.
  • 경고는 예정된 정지 시간동안 차단될 수 있다.
• Capacity Planning
  • 업그레이드 관리자의 계획을 돕기 위해 사용 패턴의 추적이 가능하다.
  • 병목 현상을 쉽게 파악할 수 있다.
• Query Optimizer
  • 쿼리 최적화 프로그램으로 오라클은 SQL 문을 실행하는 가장 효율적인 방법을 선택한다.
  • Cost 비용의 최소화를 위해 테이블 / 인덱스를 분석한다.

MySQL 의 특징

MySQL 의 특징은 다음과 같다.

• 사용이 타 RDBMS 에 비해 쉽다.
• 무료로 사용 가능한 GUI Tool 이 많다.
• Device 에 적은 Overhead 가 가해진다.
• 버전이 업그레이드됨에 따라 고급 기능을 지원하기 시작했다.

MySQL 과 Oracle DB 는 목적에 맞게 적절한 사용이 필요할 것으로 보인다. 작은 프로젝트나 데이터를 많이 저장하지 않는 시스템의 경우는 MySQL 을 사용하는 편이 좋을 수 있고, 데이터의 사용량이 매우 많고 고도화된 시스템의 경우에는 Oracle DB 를 사용하는 편이 좋을 것으로 생각된다.

광고 도메인과 광고 시스템에서 사용할 기술들에 대해 공부하다 보니 따로 알고리즘 문제를 풀고 그걸 정리할 시간이 너무 부족해졌다.

이대로 블로그를 방치하면 또 잊혀질 것 같아 지금 공부 중인 내용들을 글로 적고 스스로 정리할 수 있도록 하려 한다.

본 내용에 대해서는 내가 들었던 강의 내용과 따로 찾아본 내용들을 조합해서 내가 생각하는 바를 적은 것이므로 실제와 다를 수 있다.

다분히 개인적으로 정리를 위해 적는 내용이라고 생각하면 좋겠다.

AdTech 란 뭘까 ?

AdTech 는 Advertising + Technology 의 합성어로, 광고를 위한 기술적인 환경 혹은 생태계 전반을 의미한다.

광고 거래는 Advertiser, Publisher, Audience 의 상호 작용으로 이루어지는데, 이 상호 작용을 기술적으로 어떻게 지원할 것인가에 대한 내용으로 볼 수 있을 것 같다.

초기 광고 거래는 Advertiser 가 직접 Publisher 와 계약을 맺고, 어떠한 매체에 광고를 게재하는 방식으로 이루어졌다 한다.

이 때 광고를 게재할 공간을 인벤토리라 한다.

적은 수의 광고주와 매체가 거래하기에는 이러한 Direct Buying 의 형태가 문제가 없었지만, 광고주가 늘어나고 매체 또한 늘어남에 따라 Direct Buying 은 광고주와 매체 모두에 문제를 일으켰다.

광고주는 더 많은 매체에 본인의 광고를 게재하고 싶을 것이고, 그러기 위해서 당연히 여러 매체에 광고 게재를 위한 계약을 해야 한다.

매체 또한 다양한 광고를 내보내 수익을 창출해야 하므로, 많은 광고주와 계약을 맺어야 한다.

이 과정에서 어떠한 규약이 정해져 있지 않고 모든 계약을 일일히 하는 것은 불필요한 소모값이라 여겨졌을 것이고,

광고주는 본인의 광고를 알아서 매체에 게재하고 싶고, 매체는 빈 인벤토리에 적절한 광고를 내보내고 싶었을 것이다.

DSP, SSP 의 등장 ?

이러한 요구를 충족하는 플랫폼이 DSP 와 SSP 다.

(중간에 광고 서버가 생겨나고, 여러 과정이 있지만 내게 중요한 것은 그게 아니니 넘어가겠다.)

DSP (Demand Side Platform) 는 광고주가 본인의 광고를 등록하고, 관리하기 위한 시스템이라 할 수 있고,

SSP (Supply Side Platform) 은 매체 입장에서 인벤토리에 적절한 광고를 내보내기 위한 시스템이라 볼 수 있다.

광고주는 DSP 에 자신의 광고를 등록하고, DSP 가 광고 게재를 하기 위한 인벤토리를 얻는 거래를 대신 수행한다.

이와 유사하게, 매체는 자신의 빈 인벤토리를 채울 광고를 직접 찾지 않고 SSP 가 찾아온(?) 광고를 게재한다.

실제로 광고 거래에 참여하는 것은 DSP, SSP 로 볼 수 있고 광고주와 매체는 이에 대해 따로 신경을 쓰지 않아도 되므로 비용적인 면에서 긍정적이라 볼 수 있다.

DSP 와 SSP 의 동작이나 구조에 대해서는 조금 더 공부를 한 후 다시 정리를 해야할 것 같다.

JPA 를 사용하지 않고 SQL 을 직접 다루게 되면, CRUD (Create, Read, Update, Delete) 기능 개발을 위해 SQL 을 작성하고, JDBC API (Java DataBase Connectivity API) 를 사용해 SQL 을 실행하고, 실행한 결과를 Java 의 객체로 매핑해야 한다. 하나의 기능을 위해서 이렇게 하는 것은 크게 불편하지 않을 수 있지만 여러 테이블을 다루고자 한다면, 매번 이 과정을 반복하는 것이 지루해질 수 있다. 또한 이렇게 개발한 시스템에서 데이터베이스에 추가적인 데이터를 저장하고자 한다면 SQL 부터 객체까지 모든 내용을 수정해야 한다.

비즈니스 요구 사항을 모델링한 객체를 Entity 라 칭하는데, SQL 에 의존한 개발 환경에서는 개발자들이 Entity 를 신뢰하고 사용할 수 없게 된다. 대신 DAO (Data Access Object) 를 열어 어떤 SQL 이 실행되고 어떤 객체들이 조회되는 지를 확인해야 한다. 이는 진정한 의미의 계층 분할이라 할 수 없다. 물리적으로는 SQL / JDBC API 를 DAO 에 숨겼을 지라도 논리적으로는 Entity 와 강한 의존관계를 갖게 되어 CRUD 기능 개발을 위해서나, 테이블의 필드 구성이 변경되었을 때 DAO 의 코드와 SQL 을 수정해야 한다.

JPA 를 사용하게 되면, 위의 문제를 간단하게 해결할 수 있다. 개발자는 직접 SQL 을 작성하지 않고 JPA 가 제공하는 API 를 사용할 수 있다. 그러면 JPA 가 개발자 대신 적절한 SQL 을 생성해 데이터베이스에 전달한다.

JPA 를 사용하는 간단한 예제는 다음과 같다.

// 저장 기능
jpa.persist(object);

// 조회 기능
String objectId = "id1";
Object object = jpa.find(Object.class, objectId);

// 수정 기능
Object object = jpa.find(Object.class, objectId);
object.setName("newName");

// 연관된 객체 조회
Object object = jpa.find(Object.class, objectId);
Group group = object.getGroup();

JPA (Java Persistence API) 는 Java 객체와 관계형 DB 사이에서 Data 를 접근, 관리하기 위한 Java 스펙이다. JPA 는 현재 Java 환경에서 ORM Standard 역할을 하고 있다. JPA 는 존재하는 어떤 상품이 아니라 단순한 Spec 이기 때문에, 그 자체로는 Interface 만 제공이 된다.

- Reference

[WikiBooks] What is JPA ? https://en.wikibooks.org/wiki/Java_Persistence/What_is_JPA%3F

[Book] 자바 ORM 표준 JPA 프로그래밍 https://book.naver.com/bookdb/book_detail.nhn?bid=9252528 

%spark.dep
z.load("...") // import 하려는 package 를 address:name:version 형식으로 ... 에 입력

후 import ... 형식으로 사용

ex)

%spark.dep

z.load("com.twitter.penguin:korean-text:4.0")

import com.twitter.penguin.***