본 포스팅은 백준 Online Judge의 자주 틀리는 요인을 바탕으로 작성한 글입니다. 하지만 백준에만 종속되지 않은 내용이 대부분이니 코딩 테스트를 위해 파이썬을 선택했다면 도움이 될 것입니다.

파이썬은 문법이 직관적이지만, 다른 언어들에 비해 성능은 좋은 편이 아니다. 따라서 극도로 효율적이어야 하는 프로그램을 만들어야 하거나, 시간 제한이 아주 엄격한 코딩 테스트에는 적합하지 않다. 만약 코딩 테스트를 위해 파이썬을 선택했다면 아마 풍부한 자료와 쉬운 난이도 때문일 것이다.

필자가 파이썬을 선택한 이유는 다음과 같다.

• 파이썬에 익숙하고, 코딩 테스트 관련 자료가 많다.
• 파이썬은 쉽고 직관적이다. 부수적인 코드 없이 코딩 테스트에서 요구하는 풀이만 코드로 작성할 수 있어서 명확하다.
• JavaScript를 가장 많이 사용하지만 JavaScript는 내장 자료 구조가 부실하여 코딩 테스트에 적합하지 않다.

어떤 이유로 파이썬을 선택했건, 코딩 테스트를 위해서 필수로 알아야 하거나, 알아두면 좋을 만한 배경 지식들이 있다. 본 포스팅에서는 파이썬으로 코딩 테스트를 보거나 연습할 때 도움이 될 만한 다양한 배경 지식들을 다룬다.

ORM Entity와 DB Table을 별 고민 없이 단지 일대일 대응하는 설계는 좋지 않다. DB를 데이터의 적재 수단으로써 생각하고, 비즈니스를 잘 분석하여 설계한 도메인과 적재 형태를 매핑해주는 것이 좋은 설계다. 마찬가지로 API 또한 도메인 모델을 그대로 사용하는 것이 아니라 비즈니스에 맞게 잘 설계해야 한다.

REST API는 개념이 단순하여 직관적으로 이해하기 쉽다. 또 몇 가지 가이드에 따라 설계하면 쉽게 REST를 흉내낼 수 있다. 하지만 이런 특징 때문에 오히려 올바른 설계와 멀어지고, REST API의 진짜 목적과 장점을 잊기 쉬운 것 같다. 앞 문단에서 이야기했던 도메인 설계와 API 설계는 분리되어야 한다는 것과 같은 맥락이다. 또 REST는 단지 API의 설계 뿐만 아니라 더 포괄적인 목적을 갖고 있다. 본 포스팅은 Roy.T.Fielding의 논문 “Architectural Styles and the Design of Network-based Software Architectures“을 바탕으로 REST의 개념을 정리하고, 그 목적과 효용성을 상기한다.

이전 포스팅(객체 지향 프로그래밍의 진짜 본질은 무엇인가?)에서는 객체 지향의 개념과 좋은 설계의 방향성을 설명했다. 좋은 설계는 변경과 확장에 대응하기 쉬운 구조를 지향하는 것이고, OOP의 핵심은 메시징(Messaging)이라는 것을 알 수 있었다. 본 포스팅에서는 객체 설계에 더 초점을 맞추어 간결하게 정리한다.

객체와 클래스

먼저 객체 지향 시스템을 다시 떠올려본다. 객체 지향 시스템은 하나의 시스템을 개별 객체 간의 협력으로 구조화하는 것이다.

객체가 중요하다

• 객체 지향 프로그래밍 언어의 속성인 캡슐화, 추상화, 상속, 다형성 혹은 클래스보다 객체가 중요하다.
• 또한 객체(object) 그 자체보다는 메시지(message)가 중요하다.

학부 2학년 시절, Java 언어 중심의 객체 지향 프로그래밍 강의를 수강했다. 객체 지향 프로그래밍은 현실 세계의 복잡성을 객체라는 관점에서 관찰하여 코드에 투영하는 것이라고 배웠다. 또한 객체 지향의 요소로 캡슐화, 다형성, 추상화, 상속이 있다고 했다. 이 네 가지 개념이 객체 지향을 이루는 근간이라고 배웠다. 잘 이해가 가지 않았고, 개인적으로 학습하며 흔히 알려진 ‘붕어빵-붕어빵 틀’ 비유를 보며 객체와 클래스가 무엇인지 이해하는 듯 했다. 본 수업에서 3-Match Game 게임을 개발하는 프로젝트를 하며 GameBoard, Tile, TileGrid, Timer, MenuPanel, OptionPanel 등 다양한 클래스를 설계했고, 객체 지향 프로그래밍을 잘 수행했다고 착각했다. 이후에도 몇년 동안이나 백엔드 개발을 하면서도 관례적인 Layered Architecture의 Controller, Service, Entity 클래스들을 만들고, DI Framework로 결합도를 낮추기도 하며 좋은 객체 지향 프로그래밍을 하고 있다고 착각했다.

최근에 객체 지향의 요소가 캡슐화, 다형성, 추상화, 상속이 아니라는 글을 보았다. 곧바로 객체 지향 프로그래밍의 요소가 뭔지, 아니 객체 지향 프로그래밍이 뭔지 찾아봤다. 대부분의 결과는 캡상추다, SOLID 원칙, DI 등을 개념적으로만 설명하고 있을 뿐 객체 지향 프로그래밍의 진짜 의미를 포함하지 않았다. 이를 계기로 나는 객체 지향 프로그래밍의 본질과 창시자가 해결하고자 했던 문제점 등을 찾으며 깊게 고민했고, 진짜 객체 지향 프로그래밍이 무엇인지 점점 이해할 수 있었다.

Alan Kay의 이야기를 마음 속에 새기며…

“I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.”

…

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”

2003년 email exchange에서 Alan Kay의 발언 인용

객체 지향 프로그래밍이란?

객체 지향을 이해하기 위해 과거로 돌아갔다. OOP의 창시자 Alan Kay는 생물학 전공이었다. 그는 복잡한 생물체를 구성하는 세포로부터 영감 받아 소프트웨어를 구조화하는 방법을 창안했다. 행위를 기준으로 데이터를 조작하는 프로시저 프로그래밍하는 방식인 절차 지향 프로그래밍이 거대한 시스템을 만들기에 적합하지 않다고 생각하여 데이터, 행위를 독립 개체로 엮어 시스템을 구조화하는 방법을 생각해낸 것이다.

1. 개요(Outline)

컴퓨터는 내부적으로 0과 1, 두 가지만 활용해 모든 것을 표현합니다. 숫자의 표현 또한 마찬가지입니다. 사람은 일반적으로 숫자 표현에 10진법을 사용하지만, 컴퓨터는 0과 1만을 사용해야 한다는 제약 때문에 2진법을 채택해야 합니다. 이때 표현하고자 하는 숫자가 정수인지 아닌지에 따라 처리 방식이 크게 나뉩니다. 이번 포스팅에서는 컴퓨터의 숫자 표현 방법, 그 중에서도 부동 소숫점을 집중적으로 다룹니다.

Monitor

The difficulty of using semaphore

• 세마포어는 synchronizatio에 편리하고 효과적이다.
• 하지만 timing errors(타이밍 문제) 발생 e.g. semaphore’s problem
  • 모든 프로세스가 1로 초기화된 바이너리 세마포어 뮤텍스를 사용하는 경우, 모든 프로세스는 임계영역 진입 전에 wait(mutex)를, 임계영역을 빠져나올 때 signal(mutex)를 호출해야 한다. 만약 이 과정이 없다면 임계영역에 여러 프로세스가 존재하는 순간이 발생할 수 있다.

Background

• Cooperating 프로세스들은 서로 영향을 주거나 받을 수 있다.
• Cooperating 프로세스들은 논리적 메모리 주소 공간을 공유하거나 데이터를 할당 받을 수 있다.

이 때, 공유 데이터에 동시 접근하면 데이터 일관성이 깨질 수 있다(데이터 무결성).

• 동시 실행(Concurrent execution)
  • 프로세스의 명령어 실행 흐름 중 인터럽트가 발생할 수 있다.
  • 할당된 코어는 다른 프로세스에 의해 선점될 수 있다.
• 병렬 실행(Parallel execution)
  • 두 개 이상의 명령어 흐름(instruction streams)
  • 서로 다른 코어에서 동시에 실행

따라서 Coopereating 프로세스 실행에서는 아래 내용이 확실하게 보장되어야 한다.

CPU Scheduling 이란?

• 멀티 프로그래밍 OS의 기초
• 목적: 1) 여러 프로그램을 동시에 실행, 2) CPU 활용을 극대화

2021년 06월 08일 오후 7시 경, 열심히 공부하던 와중 카톡 하나를 보게 됐다.

본 글은 Node.js 공식 가이드 문서 중 ‘블로킹과 논블로킹 살펴보기’를 참고하여 작성되었습니다.

1. 블로킹과 논블로킹

1.1 블로킹

블로킹은 Node.js 프로세스에서 추가적인 JavaScript의 실행을 위해 JavaScript가 아닌 작업이 완료될 때까지 기다려야만 하는 상황을 의미한다. Node.js의 이벤트 루프가 블로킹 작업을 하는 동안 JavaScript 실행을 계속할 수 없기 때문에 발생한다.