lionhairdino

@lionhairdino@hackers.pub · 34 following · 33 followers

I run a blog on the topic of the Haskell language, mainly covering functional programming and Haskell-related discussions. If someone talks about these topics, I act like we're old friends, even if it's our first time meeting.

Blog
lionhairdino.github.io
1

우연히 클릭되어, 모니터 사진을 풀 사이즈 이미지로 봤는데요. 모니터 먼지 제거엔, 여자분들 토너 묻혀서 닦는 솜?이 딱이더라고요. 여자 친구나 와이프, 혹은 딸이 한 번 사용한 것 재활용 하시면 됩니다. ;-) @perlmint

0

우연히 클릭되어, 모니터 사진을 풀 사이즈 이미지로 봤는데요. 모니터 먼지 제거엔, 여자분들 토너 묻혀서 닦는 솜?이 딱이더라고요. 여자 친구나 와이프, 혹은 딸이 한 번 사용한 것 재활용 하시면 됩니다. ;-) @perlmint

0
0
2
3
0
1
2
1

Compile 이 대충 com (with의 뜻) pile 쌓다 느낌 아닐까 했는데요. 어원 찾아 보니, compile과 compress가 비슷한 뜻이군요. compile은 이 것 저 것 모아서 패키징하는 느낌이고, compress는 여기에 눌러 담다란 느낌이 추가되는 것쯤으로 보입니다.

1

꼿꼿한 자세에 모니터(32인치, 모니터암 사용중)를 눈높이까지 올려 보는게 대부분 추천 자세로 알고 있는데요. 이렇게 맞춰 놓으면, 항상 몸이 의자에서 흘러내려, 높은 모니터를 보려면 눈을 치켜 뜨면서 보게 되는 안 좋은 습관이 생겨 버렸습니다. 남들한테 다 좋아도, 저한테는 안좋은 건가 봅니다. 그래서, 권장되는 모니터 셋팅을 과감히 무시하고, 가장 낮춰서 썼습니다. 그랬더니, 이 번엔 아래 쪽을 볼 때 불편함이 생겼습니다. 까다롭지요.
그런데, 우연히 노트북 모니터마냥 비스듬히 눕혀 놓고 2~3주째 사용 중인데, 이 거 편합니다. 32인치에 기계식 키보드 달린 노트북 느낌 납니다.

1

꼿꼿한 자세에 모니터(32인치, 모니터암 사용중)를 눈높이까지 올려 보는게 대부분 추천 자세로 알고 있는데요. 이렇게 맞춰 놓으면, 항상 몸이 의자에서 흘러내려, 높은 모니터를 보려면 눈을 치켜 뜨면서 보게 되는 안 좋은 습관이 생겨 버렸습니다. 남들한테 다 좋아도, 저한테는 안좋은 건가 봅니다. 그래서, 권장되는 모니터 셋팅을 과감히 무시하고, 가장 낮춰서 썼습니다. 그랬더니, 이 번엔 아래 쪽을 볼 때 불편함이 생겼습니다. 까다롭지요.
그런데, 우연히 노트북 모니터마냥 비스듬히 눕혀 놓고 2~3주째 사용 중인데, 이 거 편합니다. 32인치에 기계식 키보드 달린 노트북 느낌 납니다.

2

안녕하세요, 업으로 프로그래밍을 하고 있는 컴퓨터 학부생 김무훈입니다.
현재 3년차 웹 프론트엔드 개발자로서, 다가오는 7월부터 함께할 정규직 포지션을 적극적으로 찾고 있습니다.

최근 학과 사무실에서 졸업 요건을 확인한 결과, 전공 필수 한 과목전공 선택 2학점(총 5학점)이 남아있음을 확인했습니다.
본래는 다음 2학기까지 수료 후 내년 2월에 졸업할 예정이었으나, 교수진과 상의한 결과 취업 및 재직이 확정된다면 수업 이수 방식을 보다 유연하게 결정할 수 있다는 긍정적인 답변을 받아 적극적으로 조기 취업을 추진하게 되었습니다.

이는 전공 필수 과목의 경우에만 해당이 되는 문제이고, 전공 선택 2학점의 경우 앞으로의 여름 학기 현장 실습 또는 다음 학기에 개설되는 하나의 원격 강의로 대체하여 문제가 없는 상태입니다.

지금까지의 업무 경험과 프로젝트는 아래의 포트폴리오에서 확인하실 수 있습니다.
📌 경력기술서 겸 포트폴리오 페이지: https://www.frontend.moe/portfolio/

좋은 인연을 찾을 수 있도록, 많은 관심과 연락 부탁드립니다!

8
1
0

뉴럴넷을 설계할수 있는 GUI를 프로토타이핑 해야하는데 좋은 방향이 생각이 안난다. 첨에 착수할땐 자명하다고 생각했는데, 막상 시작하고나니 의외로 참고할 물건도 적고 난감한 상태다.

3
0

올 해 2025년은 음력 6월이 두 번 있습니다. 지금까지 "윤"은 4년에 한 번씩 있겠거니 했는데, 19년에 7번 윤달(閏月)이 들어간다네요. 똑 떨어지지 않는 수로 주기가 도는 느낌입니다.

컴퓨터 부동소수점 계산도 그렇고, 이가 칼같이 맞아서 정확할 것 같은 것들이 그러지 않는 걸 보면, 세상이 원래 부정확해야 살 맛이 나지 않을까 하는 개똥 철학으로 연결되네요.

1

올 해 2025년은 음력 6월이 두 번 있습니다. 지금까지 "윤"은 4년에 한 번씩 있겠거니 했는데, 19년에 7번 윤달(閏月)이 들어간다네요. 똑 떨어지지 않는 수로 주기가 도는 느낌입니다.

2
2
0
0

@lionhairdino 자바에서도 기본적인 것은 다 됩니다. 객체지향 프로그래밍을 가능하게 하는 최소 요건을 맞추는 것은 어렵지 않아요. ‘잘‘ 갖추는 것과 사용자들이 그것을 적절히 쓰게 만드는 게 어려운 거고 많은 자바 레거시는…후략

0
0

이론적으론 자바는 반쪽짜리 OOP인가 봅니다. 모든 건 객체고, 객체들끼리 함수 호출이 아닌 메시지 패싱을 해야되고, 이 메시지들 처리 방식을 객체가 능동적으로 결정해야 Pure OOP라 부르나 봅니다. 어디까지나 이론적인 얘기입니다. 스몰토크나, 아니면 얼랭등을 만져봤으면 더 쉽게 이해할 것 같은데요. 낮에 객체 지향 얘기가 보여 교양 공부 해봤습니다.

1
1
0
0

엑스와 쓰레드에서 모나드글을 가끔 올려서, 함수형 프로그래머분들을 "낚는데요". (이 거 좀 더 좋은 표현이 없을까요? ㅎ) 방금 전, SICP 역자 분으로 보이는 분(추정)이 팔로우를 해주셨네요! 해커스펍으로 모셔 오려고 하는데, 쓰레드는 DM이 없나봐요.

1
0

@lionhairdino 사실 테스트 통과 조건만 가지고 프로그램을 완성하는 건 (더 잘 정립된 방법으로) 현재에도 이곳저곳에 활용되고 있습니다. 대표적으로 엑셀(Excel)의 플래쉬 필(Flash Fill)이 있지요. 이와 관련된 분야를 프로그램 합성(Program Synthesis)라고 하고, 수십년 전부터 (AI보다는 투명한 방법으로) 꽤 활발하게 연구되어왔습니다.

0

원숭이가 키보드를 쳐도 수 억번 치면 확률상 실제 동작하는 프로그램이 나오는데, LLM이 로컬에서 브루트포스를 할 수 있는 때가 오면, 테스트 통과 조건만 깔짝대면 완성된 프로그램이 나오는 때가 얼마 안남았네요.

0
0

lionhairdino shared the below article:

논리와 메모리 - 논리와 저수준(Low-level) 자료 표현(Data representation) (2 편 중 2 편)

Ailrun (UTC-5/-4) @ailrun@hackers.pub

이 글은 "논리적"이 되는 두 번째 방법인 논건 대수를 재조명하며, 특히 컴퓨터 공학적 해석에 초점을 맞춥니다. 기존 논건 대수의 한계를 극복하기 위해, 컷 규칙을 적극 활용하는 반(半)공리적 논건 대수(SAX)를 소개합니다. SAX는 추론 규칙의 절반을 공리로 대체하여, 메모리 주소와 접근자를 활용한 저수준 자료 표현과의 커리-하워드 대응을 가능하게 합니다. 글에서는 랜드(∧)와 로어(∨)를 "양의 방법", 임플리케이션(→)을 "음의 방법"으로 구분하고, 각 논리 연산에 대한 메모리 구조와 연산 방식을 상세히 설명합니다. 특히, init 규칙은 메모리 복사, cut 규칙은 메모리 할당과 초기화에 대응됨을 보여줍니다. 이러한 SAX의 컴퓨터 공학적 해석은 함수형 언어의 저수준 컴파일에 응용될 수 있으며, 논리와 컴퓨터 공학의 연결고리를 더욱 강화합니다. 프랭크 페닝 교수의 연구를 바탕으로 한 SAX는 현재도 활발히 연구 중인 체계로, ML 계열 언어 컴파일러 개발에도 기여할 수 있을 것으로 기대됩니다.

Read more →
12
1
0

하스켈 위클리를 받아보는데, 끊임없이 블로그 글들이 새로 올라 옵니다. 제가 전공자가 아니라서 그런가, 확실히 포멀한 책과는 다른 방식으로 얻는 게 있습니다. 이런 글들이 누적되는 게 건강한 생태계로 가는 유일한 길 아닐까 싶어요.

1
0
0
0

lionhairdino replied to the below article:

애플리케이션 개발 측면에서 본 Drizzle ORM 대 Kysely 비교

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub

TypeScript로 백엔드 서버를 개발하면서 적절한 ORM 선택은 항상 중요한 결정 중 하나입니다. 최근 제 프로젝트에서 Drizzle ORM과 Kysely를 모두 사용해 볼 기회가 있었는데, 개인적으로는 Drizzle ORM이 더 편리하고 생산성이 높았던 경험을 공유하고자 합니다.

두 ORM에 대한 간략한 소개

Drizzle ORM은 TypeScript용 ORM으로, 타입 안전성과 직관적인 API를 강점으로 내세우고 있습니다. 스키마 정의부터 마이그레이션, 쿼리 빌더까지 풀스택 개발 경험을 제공합니다.

Kysely는 “타입 안전한 SQL 쿼리 빌더”로 자신을 소개하며, 타입스크립트의 타입 시스템을 활용해 쿼리 작성 시 타입 안전성을 보장합니다.

두 도구 모두 훌륭하지만, 제 개발 경험에 비추어 볼 때 Drizzle ORM이 몇 가지 측면에서 더 편리했습니다.

Drizzle ORM을 선호하게 된 이유

스키마 정의의 직관성

Drizzle ORM의 스키마 정의 방식은 매우 직관적이고 선언적입니다:

import { pgTable, serial, text, integer } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: serial('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email').unique().notNull(),
  age: integer('age')
});

Drizzle ORM은 이 스키마 정의로부터 자동으로 CREATE TABLE SQL을 생성할 수 있어, 스키마와 코드가 항상 동기화되어 있습니다.

반면 Kysely는 타입 정의에 더 중점을 두고 있어 스키마와 타입 정의가 분리되는 경향이 있습니다:

interface Database {
  users: {
    id: Generated<number>;
    name: string;
    email: string;
    age: number | null;
  };
}

이 타입 정의는 TypeScript 코드에서 타입 안전성을 제공하지만, 이 타입 정의만으로는 CREATE TABLE SQL을 생성할 수 없다는 것이 결정적인 단점입니다. 실제로 테이블을 생성하려면 별도의 SQL 스크립트나 마이그레이션 코드를 작성해야 합니다. 이는 타입과 실제 데이터베이스 스키마 간의 불일치 가능성을 높입니다.

Drizzle의 접근 방식이 데이터베이스 스키마와 TypeScript 타입을 더 긴밀하게 연결해주어 개발 과정에서 혼란을 줄여주었습니다.

마이그레이션 경험

Drizzle ORM의 마이그레이션 도구(drizzle-kit)는 정말 인상적이었습니다. 스키마 변경사항을 자동으로 감지하고 SQL 마이그레이션 파일을 생성해주는 기능이 개발 워크플로우를 크게 개선했습니다:

npx drizzle-kit generate:pg

이 명령어 하나로 스키마 변경사항에 대한 마이그레이션 파일이 생성되며, 이를 검토하고 적용하는 과정이 매우 간단했습니다.

반면 Kysely의 마이그레이션은 본질적으로 수동적입니다. 개발자가 직접 마이그레이션 파일을 작성해야 하며, 스키마 변경사항을 자동으로 감지하거나 SQL을 생성해주는 기능이 없습니다:

// Kysely의 마이그레이션 예시
async function up(db: Kysely<any>): Promise<void> {
  await db.schema
    .createTable('users')
    .addColumn('id', 'serial', (col) => col.primaryKey())
    .addColumn('name', 'text', (col) => col.notNull())
    .addColumn('email', 'text', (col) => col.unique().notNull())
    .addColumn('age', 'integer')
    .execute();
}

async function down(db: Kysely<any>): Promise<void> {
  await db.schema.dropTable('users').execute();
}

이러한 수동 방식은 복잡한 스키마 변경에서 실수할 가능성이 높아지고, 특히 큰 프로젝트에서는 작업량이 상당히 증가할 수 있었습니다.

하지만 Kysely의 마이그레이션에도 두 가지 중요한 장점이 있습니다:

  1. TypeScript 기반 마이그레이션: Kysely의 마이그레이션 스크립트는 TypeScript로 작성되기 때문에, 마이그레이션 로직에 애플리케이션 로직을 통합할 수 있습니다. 예를 들어, S3와 같은 오브젝트 스토리지의 데이터도 함께 마이그레이트하는 복잡한 시나리오를 구현할 수 있습니다. 반면 Drizzle ORM은 SQL 기반 마이그레이션이므로 이러한 통합이 불가능합니다.

  2. 양방향 마이그레이션: Kysely는 updown 함수를 모두 정의하여 업그레이드와 다운그레이드를 모두 지원합니다. 이는 특히 팀 협업 환경에서 중요한데, 다른 개발자의 변경사항과 충돌이 발생할 경우 롤백이 필요할 수 있기 때문입니다. Drizzle ORM은 현재 업그레이드만 지원하며, 다운그레이드 기능이 없어 협업 시 불편할 수 있습니다.

참고로, Python 생태계의 SQLAlchemy 마이그레이션 도구인 Alembic은 훨씬 더 발전된 형태의 마이그레이션을 제공합니다. Alembic은 비선형적인 마이그레이션 경로(브랜치포인트 생성 가능)를 지원하여 복잡한 팀 개발 환경에서도 유연하게 대응할 수 있습니다. 이상적으로는 JavaScript/TypeScript 생태계의 ORM도 이러한 수준의 마이그레이션 도구를 제공하는 것이 바람직합니다.

관계 설정의 용이성

Drizzle ORM에서 테이블 간 관계 설정이 매우 직관적이었습니다:

import { relations } from 'drizzle-orm';

export const usersRelations = relations(users, ({ one, many }) => ({
  profile: one(profiles, {
    fields: [users.id],
    references: [profiles.userId],
  }),
  posts: many(posts)
}));

이 방식은 데이터베이스 설계의 본질적인, 관계적인 측면을 명확하게 표현해주었습니다.

쿼리 작성의 편의성과 동일 이름 칼럼 문제 처리

두 ORM 모두 쿼리 작성을 위한 API를 제공하지만, Drizzle의 접근 방식이 더 직관적이고 관계형 모델을 활용하기 쉬웠습니다:

// Drizzle ORM - db.query 방식으로 관계 활용
const result = await db.query.posts.findMany({
  where: eq(posts.published, true),
  with: {
    user: true  // 게시물 작성자 정보를 함께 조회
  }
});

// 결과 접근이 직관적이고 타입 안전함
console.log(result[0].title);       // 게시물 제목
console.log(result[0].user.name);   // 작성자 이름 - 객체 구조로 명확하게 구분됨
console.log(result[0].user.id);     // 작성자 ID - 게시물 ID와 이름이 같아도 문제 없음

// Kysely
const result = await db
  .selectFrom('posts')
  .where('posts.published', '=', true)
  .leftJoin('users', 'posts.userId', 'users.id')
  .selectAll();

// 결과 접근 시 칼럼 이름 충돌 문제
console.log(result[0].id) // 오류: posts.id와 users.id 중 어떤 것인지 모호함
console.log(result[0].name) // 오류: 둘 다 name 칼럼이 있다면 모호함

Drizzle의 접근 방식이 테이블과 컬럼을 참조할 때 타입 안전성을 더 강력하게 보장하고, 관계를 활용한 쿼리 작성이 더 직관적이었습니다.

특히 여러 테이블 조인 시 동일한 이름의 칼럼 처리 부분에서 Drizzle ORM이 훨씬 더 편리했습니다. 이는 제 개발 경험에서 가장 중요한 차이점 중 하나였습니다.

// Drizzle ORM - 동일 이름 칼럼 처리
const result = await db.query.posts.findMany({
  with: {
    user: true  // posts.id와 users.id가 모두 있지만 자동으로 구분됨
  }
});

// 결과에 자연스럽게 접근 가능
console.log(result[0].id);        // 게시물 ID
console.log(result[0].user.id);   // 사용자 ID - 명확하게 구분됨
console.log(result[0].user.name); // 사용자 이름

// Kysely - 동일 이름 칼럼 처리를 위해 별칭 필요
const result = await db
  .selectFrom('posts')
  .leftJoin('users', 'posts.userId', 'users.id')
  .select([
    'posts.id as postId',       // 별칭 필수
    'posts.title',
    'posts.content',
    'users.id as userId',       // 별칭 필수
    'users.name as userName',   // 칼럼 이름이 같을 수 있으므로 별칭 필수
    'users.email as userEmail'  // 일관성을 위해 모든 사용자 관련 칼럼에 접두어 필요
  ]);

// 별칭을 통한 접근
console.log(result[0].postId);    // 게시물 ID
console.log(result[0].userId);    // 사용자 ID
console.log(result[0].userName);  // 사용자 이름

Drizzle ORM은 테이블과 칼럼을 객체로 참조하기 때문에, 동일한 이름의 칼럼이 있어도 자연스럽게 계층 구조로 처리되며 타입 추론도 정확하게 작동합니다. 반면 Kysely에서는 문자열 기반 접근 방식 때문에 별칭을 수동으로 지정해야 하는 경우가 많았고, 복잡한 조인에서 이런 작업이 번거로워졌습니다. 특히 여러 테이블에 같은 이름의 칼럼이 많을수록 모든 칼럼에 명시적인 별칭을 지정해야 하는 불편함이 있었습니다.

또한 Drizzle ORM은 결과 타입을 자동으로 정확하게 추론해주어 별도의 타입 지정 없이도 안전하게 결과를 사용할 수 있었습니다.

Kysely의 장점

물론 Kysely도 여러 강점이 있습니다:

  1. 더 가벼운 구조: 필요한 기능만 포함할 수 있는 모듈화된 구조
  2. SQL에 더 가까운 접근: SQL 구문에 매우 충실한 API 설계
  3. 유연성: 복잡한 쿼리에서 때로 더 유연한 작성이 가능

또한 앞서 언급했듯이, Kysely의 TypeScript 기반 마이그레이션과 양방향(up/down) 마이그레이션 지원은 특정 상황에서 Drizzle ORM보다 우위에 있는 기능입니다.

SQLAlchemy와의 비교 및 앞으로의 기대

JavaScript/TypeScript 생태계의 ORM을 이야기하기 전에, 여러 언어 중에서도 Python의 SQLAlchemy는 특별한 위치를 차지합니다. 개인적으로 여태 사용해본 다양한 언어의 ORM 중에서 SQLAlchemy가 가장 기능이 풍부하고 강력하다고 느꼈습니다. 복잡한 쿼리 구성, 고급 관계 매핑, 트랜잭션 관리, 이벤트 시스템 등 SQLAlchemy의 기능은 정말 방대합니다.

Drizzle ORM은 JavaScript 생태계에서 매우 인상적인 발전을 이루었지만, 아직 SQLAlchemy의 경지에는 이르지 못했다고 생각합니다. 특히 다음과 같은 부분에서 SQLAlchemy의 성숙도와 기능 풍부함이 돋보입니다:

  • 복잡한 서브쿼리와 윈도우 함수 지원
  • 다양한 이벤트 리스너와 훅
  • 다양한 상속 전략
  • 복잡한 트랜잭션 관리와 세션 관리
  • 대규모 프로젝트에서 검증된 안정성
  • Alembic을 통한 비선형적 마이그레이션 지원
  • 놀라울 정도로 방대하고 상세한 문서화

결론

두 ORM 모두 훌륭한 도구이지만, 제 개발 스타일과 프로젝트 요구사항에는 Drizzle ORM이 더 잘 맞았습니다. 특히 스키마 정의의 직관성, 강력한 마이그레이션 도구, 그리고 전반적인 개발자 경험 측면에서 Drizzle ORM이 더 생산적인 개발을 가능하게 해주었습니다.

동일 이름 칼럼 처리와 같은 실질적인 문제에서 Drizzle ORM의 객체 기반 접근 방식이 가져다주는 편리함은 실제 프로젝트에서 큰 차이를 만들었습니다.

ORM 선택은 결국 프로젝트 특성과 개인 선호도에 크게 좌우됩니다. 새로운 프로젝트를 시작한다면 두 도구 모두 간단히 테스트해보고 자신의 워크플로우에 더 적합한 것을 선택하는 것이 좋겠지만, 제 경우에는 Drizzle ORM이 명확한 승자였습니다.

앞으로 Drizzle ORM이 더욱 발전하여 SQLAlchemy 수준의 풍부한 기능과 유연성을 제공하게 되길 바랍니다. JavaScript/TypeScript 생태계에도 그런 수준의 강력한 ORM이 있으면 좋겠습니다. 다행히도 Drizzle ORM은 계속해서 발전하고 있으며, 그 발전 속도를 보면 기대가 큽니다.

여러분의 경험은 어떤가요? 다른 ORM 도구나 언어를 사용해보셨다면 의견을 공유해주세요!

Read more →
0

딱 ORM은 아니지만, 목적은 같은 하스켈의 opaleye 가 있습니다. 쿼리에 타입을 도입한 모양이라, 쿼리 검사에 타입 체커의 도움을 받을 수 있습니다. 처음 봤을 때, 함수형 방식으로 ORM 같은 걸 만든다면, 이렇게 되는 구나 감탄했는데, 익히는 비용이 만만치 않은 것 같습니다. @hongminhee洪 民憙 (Hong Minhee)

0
0

@lionhairdino 사실 전 어떤 좋은 설명을 제공해야한다는 생각 자체에 좀 회의적입니다. 그냥 하다보면 알게되도록 보조해주는게 최선이라고 생각합니다. 약간 별개의 얘긴데, 옛날에 파인만 빨간책 읽다가 참 좋은 책이란 생각이 들었지만 설명이 너무 똑똑해서 덮었습니다.

0

@lionhairdino 사실 전 어떤 좋은 설명을 제공해야한다는 생각 자체에 좀 회의적입니다. 그냥 하다보면 알게되도록 보조해주는게 최선이라고 생각합니다. 약간 별개의 얘긴데, 옛날에 파인만 빨간책 읽다가 참 좋은 책이란 생각이 들었지만 설명이 너무 똑똑해서 덮었습니다.

큰 틀에서는 동의합니다. 파인만 아저씨 책을 보셨다니..며칠전 전공자들의 고집을 짚었던 걸로 보아, 전공은 아니신가 했는데, 셀프 디스를 하셨던 건가!) (다른 비함수형 언어와 달리) 워낙 IO란 걸, 잘 구분해야 하는 게, 쉽지 않은 미션인데, 시작을 너무 전통 hello world 에 얽매이는 건 아닐까 싶어서요. 굳이 쉽지 않은 걸 보여주고, 모르고 넘어가자라고 하느니, 차라리 더하기 하며, 로그 남기는 걸, 직접 순수 함수로 만들어 보는 게, 낫지 않을까 혼자 상상해 봤습니다. @bglbgl gwyng

1
main = do
  n <- getLine
  putStrLn $ "hello " <> n

설명해야 될 게 한가득인데, 나중에, 나중에 하며 넘어가야 한다. 꼭 Lazy 평가처럼 말이다. 전통적인 "hello world"에서 출발하지 않아도 되는 것 아닐까? 첫 언어가 아닌 분들한테는, Writer 혹은 State 만들기부터 시작하면 어떨까? 단, "모나드"라고 말하지 않고.

2

첫째 학원 데려다 주고 버거킹에 가서 치즈와퍼 단품 먹고 카페에 와서 아아를 마신다. 비가 오고 나서 그런지 날은 흐린데 길거리 식물들 생기가 넘쳐 보이고 뭐든지 맑게 보인다. 한 30분 정도 자유 시간인데 하스켈 책 연습 문제만 풀고 가야지!

0
1

익숙한 정main, 부sub를 써서 정작용(주작용), 부작용을 같이 보여주면 "부"의 뜻을 인지하는데 도움을 줄 것 같긴 한데, side effect 얘기를 할 때 primary effect를 거론하는 자료도 드물고, 뭔지 궁금해하는 분들도 못봤습니다.(왜 안 궁금해할까요? ㅎㅎ)

어떤 논문은 Side-effect를 Computational Effect 전반을 가리키는 용어로 쓰고, 어떤 논문들은 Effect 중 mutation을 가리키는 용어로만 씁니다. 오래된 논문일수록 전자처럼 쓰고, 요즘은 후자로 자리잡아 가고 있다고 합니다.

그동안 본 번역은 부작용, 부수 효과 정도고, 그 외 생각해 본 번역은 "부차 효과"정도가 있습니다. 맥락에서 특별히 튀지 않으면, 저는 문장에서, 원어에 바로 연결되지 않는 단점이 있긴 하지만, 의미 전달에는 유리하다 생각하는 "비순수 효과"를 쓰기도 합니다. @hongminhee洪 民憙 (Hong Minhee)

2