게임 엔진이라고 하면 보통 Unity나 Unreal 같은 큰 도구부터 떠올리기 쉽습니다. 물론 그런 엔진들은 강력하지만, 처음부터 너무 큰 도구를 잡으면 오히려 간단한 게임 하나를 만드는 일도 무겁게 느껴질 수 있습니다. 반면 SpriteKit은 Apple 플랫폼에서 2D 게임을 만드는 데 필요한 핵심 기능을 단순한 형태로 제공합니다. 퍼즐 게임, 간단한 아케이드 게임, 탭 중심 미니 게임처럼 규모가 크지 않은 프로젝트라면 특히 잘 어울립니다.

이 글에서는 SpriteKit이 어떤 프레임워크인지, 어떤 구조로 게임을 만들게 되는지, 그리고 왜 입문용으로 꽤 괜찮은 선택인지 가볍게 정리해 보려 합니다.

SpriteKit은 무엇인가?

SpriteKit은 Apple이 만든 2D 그래픽 및 게임 프레임워크입니다. 쉽게 말하면, 화면에 캐릭터와 배경을 올리고, 움직이고, 충돌을 처리하고, 애니메이션을 처리하는 일을 편하게 해주는 도구입니다.

예를 들어 2D 게임을 만든다고 하면 보통 이런 일을 해야 합니다.

• 캐릭터나 배경 이미지를 화면에 배치하기
• 터치 입력 받기
• 특정 오브젝트를 움직이기
• 충돌을 판단하기
• 간단한 물리 효과 넣기
• 장면 전환하기
• 사운드나 애니메이션 붙이기

SpriteKit은 이런 기능들을 기본으로 제공합니다. 그래서 개발자는 아주 낮은 수준부터 그래픽 처리나 게임 루프를 직접 만들지 않아도 됩니다. 특히 Swift로 앱 개발을 해본 사람이라면, “완전히 다른 세계”라기보다 익숙한 Apple 개발 환경 위에서 게임 쪽 기능이 확장된 느낌으로 배워서 쓰기 좋습니다.

어떤 게임에 잘 맞을까?

SpriteKit은 이름 그대로 스프라이트 기반 2D 게임에 잘 맞습니다. 화면 위에 이미지 노드(스프라이트)들을 배치하고, 그 노드들이 움직이거나 반응하도록 만드는 게 편하기 때문입니다.

이런 종류의 게임을 만들기 매우 편합니다.

• 퍼즐 게임
• 타일 기반 게임
• 간단한 액션 게임
• 점프 게임
• 탭/드래그 중심 캐주얼 게임
• 충돌 판정이 들어가는 미니게임

반대로 복잡한 3D 게임이나, 멀티플랫폼 프로젝트를 염두에 둔다면 SpriteKit은 좋은 선택이 아닐 수 있습니다. 하지만 간단한 2D 게임을 직접 만들고 싶다는 목적에는 최적일 수 있습니다.

SpriteKit의 기본 구조

SpriteKit을 처음 보면 가장 먼저 익숙해져야 하는 개념이 몇 가지 있습니다. 이 구조를 한 번 이해하면 이후 코드를 읽기도 훨씬 쉬워집니다. AI가 생성하는 코드를 이해하기에도 좋습니다.

SKView

게임 화면을 실제로 보여주는 뷰입니다. 앱에서 SpriteKit 장면을 표시하는 도화지 같은 역할을 합니다.

SKScene

하나의 게임 화면이라고 생각하면 이해하기 쉽습니다. 예를 들어 타이틀 화면, 스테이지 화면, 게임 오버 화면을 각각 다른 Scene으로 만들 수 있습니다.

SKNode

장면(Scene) 안에 들어가는 개별 요소의 기본 단위입니다. 위치(좌표)가 있고, 자식 노드를 가질 수 있고, 계층 구조를 만듭니다.

SKSpriteNode

이미지가 붙은 노드입니다. 캐릭터, 상자, 벽, 배경 같은 것들은 보통 이 클래스로 다루게 됩니다.

update(_:)

매 프레임마다 호출되는 메소드입니다. 게임 진행 중에 지속적으로 상태를 갱신해야 할 때 사용합니다.

이 구조를 아주 단순하게 표현하면 이렇습니다.

• 앱 안에 SKView가 있고
• 그 안에 하나의 Scene이 올라가고
• Scene 안에 여러 Node와 SpriteNode들이 들어간다

즉, SpriteKit은 장면(Scene) 안에 노드(Node)를 배치해서 게임 화면을 구성하는 방식이라고 보면 되겠습니다.

시작해 보면 어떤 느낌일까

Xcode에서 SpriteKit 프로젝트를 만들면 기본 템플릿이 생성됩니다. 처음에는 약간 낯설 수 있지만, 실제로 자주 보게 되는 파일은 생각보다 몇 개 없습니다.

• 앱의 시작 지점
• SpriteKit 장면을 띄우는 부분
• 실제 게임 로직을 넣을 GameScene.swift
• 이미지를 넣는 Assets

가장 먼저 하게 되는 일은 대개 GameScene 안에서 배경색을 바꾸고, 스프라이트 하나를 올려보는 것입니다. 이 단계가 별것 아닌 것 같아도 중요합니다. 왜냐하면 게임 개발은 결국 “화면에 뭔가가 보이고, 그것이 반응하는 경험”을 반복하면서 나아가는 과정이기 때문입니다.

예를 들어 아주 단순한 장면은 이런 식으로 시작할 수 있습니다.

import SpriteKit

final class GameScene: SKScene {
    override func didMove(to view: SKView) {
        backgroundColor = .white
        let player = SKSpriteNode(imageNamed: "player")
        player.position = CGPoint(x: size.width / 2, y: size.height / 2)
        addChild(player)
    }
}

이 코드가 하는 일은 단순합니다. 장면(Scene)이 화면에 나타났을 때 배경을 흰색으로 바꾸고, player라는 이미지를 중앙에 배치하는 것입니다.

게임이라고 부르기엔 아직 이르지만, SpriteKit의 핵심 방식은 이미 드러납니다. 노드를 만들고, 위치를 정하고, 장면에 추가했습니다.

입력을 연결하면 비로소 게임 같아집니다.

화면에 스프라이트를 띄우는 것만으로는 아직 그냥 고정된 화면일 뿐입니다. 여기에 터치 입력을 연결하면 게임처럼 움직이게 할 수 있습니다.

SpriteKit에서는 touchesBegan, touchesMoved, touchesEnded 같은 메서드로 입력을 처리할 수 있습니다.

예를 들어 화면을 탭 한 위치로 캐릭터를 곧바로 이동시키는 식의 간단한 동작도 만들 수 있습니다.

override func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent?) {
    guard let touch = touches.first else { return }
    let location = touch.location(in: self)
    
    if let player = childNode(withName: "//player") as? SKSpriteNode {
        player.run(SKAction.move(to: location, duration: 0.2))
    }
}

실제 코드에서는 노드 이름을 지정해 두거나, 오브젝트 속성으로 참조를 들고 있는 방식을 쓰겠지만, 핵심은 간단합니다. 사용자의 입력을 받고, 그에 따라 노드에 액션을 실행하면 됩니다.

이런 식으로 탭, 드래그, 스와이프를 붙이기 시작하면 작은 퍼즐 게임이나 캐주얼 게임을 금방 만들 수 있어요.

애니메이션과 액션을 처리하기 편하다

SpriteKit에서 체감상 꽤 좋은 부분 중 하나는 애니메이션을 붙이는 과정이 비교적 간단하다는 점입니다. 복잡한 시스템을 처음부터 짜지 않아도, SKAction만으로 꽤 많을 연출을 만들 수 있습니다.

예를 들면 이런 작업들을 할 수 있죠.

• 이동
• 회전
• 확대/축소
• 페이드 인/아웃
• 반복 동작
• 여러 액션의 순차 실행

let moveUp = SKAction.moveBy(x: 0, y: 30, duration: 0.2)
let moveDown = SKAction.moveBy(x: 0, y: -30, duration: 0.2)
let bounce = SKAction.sequence([moveUp, moveDown])

player.run(bounce)

이런 간단한 코드로 화면에서는 꽤 즉각적인 생동감을 줄 수 있습니다. 작은 버튼 반응, 캐릭터의 튀는 느낌, 아이템 획득 효과 같은 것을 붙일 때 특히 유용합니다.

게임을 처음 만들 때는 “이게 진짜 게임처럼 느껴지는가”가 중요한데, SpriteKit은 이런 부분을 짧은 코드로 빠르게 확인하기 좋습니다.

충돌 같은 물리 엔진 처리도 지원

SpriteKit은 간단한 물리 엔진도 제공합니다. 그래서 물체끼리 부딪치는 상황이나 중력, 속도, 반발 같은 효과를 구현할 수 있습니다.

물론 모든 게임이 물리 엔진을 적극적으로 써야 하는 것은 아닙니다. 예를 들어 퍼즐 게임에서는 현실적인 물리보다는 충돌 감지만 필요한 경우도 많습니다. 그럴 때도 SpriteKit의 물리 시스템은 유용합니다.

• 벽과 부딪히면 멈추기
• 아이템을 먹었는지 판정하기
• 바닥 아래로 떨어졌는지 감지하기
• 적과 닿았는지 확인하기

이런 기본적인 판정 로직을 넣을 때, 프레임워크가 제공하는 구조를 활용하면 직접 좌표 비교를 반복해서 작성하는 수고를 줄일 수 있습니다.

아쉽게도 제 이번 퍼즐 게임에 물리 엔진을 사용하지는 않았습니다만, 다음 게임에는 한 번 활용해 보고 싶습니다.

간단한 구조로 작은 게임을 만든다

SpriteKit의 또 다른 장점은, 작은 프로젝트에서는 구조를 비교적 단순하게 유지할 수 있다는 점입니다. 모든 것을 거창하게 만들 필요 없이, 장면(Scene) 중심으로 정리해도 꽤 잘 관리할 수 있습니다.

예를 들어, 이렇게 구성할 수 있습니다.

• TitleScene
• GameScene
• ClearScene

그리고 GameScene 안에는,

• 플레이어 노드
• 맵 노드
• UI 노드
• 상태값

이 정도만 나눠도, 간단한 퍼즐 게임이나 액션 프로토타입은 충분히 만들 수 있습니다.

물론 프로젝트가 커지면 데이터 구조, 입력 처리, 상태 관리, 레벨 로딩 같은 부분을 더 정리해야 하겠습니다. 하지만 입문 단계에서 너무 큰 구조부터 고민하면 오히려 진도가 안 나가거나 중단되기 쉽죠. SpriteKit은 그런 의미에서 먼저 빠르게 만들고, 점점 정리해 나가기 좋은 프레임워크입니다.

SpriteKit의 장점

직접 써보니 SpriteKit의 매력이 꽤 분명히 드러납니다.

첫째, 진입 장벽이 매우 낮습니다. Swift와 Xcode 환경에 이미 익숙하다면, 완전히 새로운 툴체인을 배우는 부담이 없습니다.

둘째, 2D 게임에 필요한 핵심 기능이 잘 모여 있습니다. 화면 구성, 입력, 애니메이션, 충돌, 장면 전환 같은 기본 작업을 빠르게 붙일 수 있습니다.

셋째, 애플 플랫폼에 집중한 개발에 잘 맞습니다. iPhone, iPad, Mac 쪽 앱과의 연결도 자연스럽죠. 게임이 아주 큰 규모가 아니라면 이 점은 꽤 실용적입니다.

넷째, 프로토타입을 빠르게 만들기 좋다. 아이디어가 있을 때 “일단 움직이는 걸 만들어보자”라는 접근이 잘 통합니다.

아쉬운 점

물론 한계도 있습니다.

가장 먼저 떠오르는 건 멀티플랫폼 대형 엔진에 비해 생태계가 상대적으로 작다는 점입니다. 자료도 많지 않은 편이에요. 애플 공식 개발자 문서가 거의 전부다시피 한 점이 사실 좀 불안했는데, 좀 더 써보니, 그걸로도 충분하기에 더 많은 자료가 없는 게 아닐까 하는 생각이 들었습니다. 프레임워크 자체가 단순하고 잘 정리돼 있으니, 더 많은 자료가 꼭 필요하지는 않은 거죠.

또 SpriteKit은 기본적으로 2D 중심이기 때문에, 3D 연출이나 더 복잡한 씬 편집 워크플로를 기대하면 부족하게 느껴질 수 있습니다. 3D 게임이라면 다른 선택을 해야 하겠습니다.

그리고 규모가 커질수록, 프레임워크가 단순해서 좋은 부분이 오히려 직접 구조를 더 잘 잡아야 하는 숙제로 바뀌기도 한다. 즉, 작은 게임에는 가볍고 좋지만, 프로젝트가 커지면 설계 감각이 더 중요해질 수 있겠습니다.

그래서 SpriteKit은 누구에게 추천?

제가 보기에 SpriteKit은 이런 사람에게 좋습니다.

• Swift를 이미 조금 다뤄본 사람
• iPhone용 2D 게임을 직접 만들어보고 싶은 사람
• 퍼즐이나 캐주얼 게임 프로토타입을 빨리 만들고 싶은 사람
• 거대한 엔진보다 가벼운 출발점을 원하는 사람

반대로 처음부터 고급 3D 그래픽이나 멀티플랫폼 게임을 염두에 둔다면, 다른 선택지를 먼저 보는 게 나을 수도 있겠습니다.

하지만 작은 게임 하나를 완성해 보는 경험은 생각보다 만족스러웠습니다. 캐릭터를 보이고, 입력을 받고, 스테이지를 넘기는 흐름을 직접 구현해보니 게임 개발이 훨씬 구체적으로 느껴지고 자신감이 생겼습니다.

SpriteKit은 바로 그 첫 경험을 만들어주기에 꽤 괜찮은 도구입니다. 저도 그래서 첫 게임을 완성해 출시할 수 있었던 거 같습니다.

그렇게 만들어 출시한 게임

• 애플 앱스토어 링크
• 데모 유튜브 영상

그렇게 처음으로 SpriteKit을 만들어 출시한 게임입니다. 현재 버전 기준, 155판까지 출시되어 있는데, 꽤 재미있습니다. 오프라인에서도 플레이 가능하기 때문에, 비행기 같은 데서도 재밌게 즐기실 수 있어요. 머리쓰는 퍼즐 게임 좋아하시면 꽤 재밌을 거예요.

마무리

SpriteKit은 매우 강력하고 화려한 프레임워크라기보다는, 작은 2D 게임을 실제로 만들어보게 해주는 실용적인 도구에 가깝습니다. 게임 엔진 전체를 배우는 부담 없이, Apple 생태계 안에서 비교적 자연스럽게 시작할 수 있다는 점이 가장 큰 장점입니다.

처음에는 스프라이트 하나를 띄우는 것부터 시작해도 충분하겠습니다. 거기에 입력을 붙이고, 움직임을 넣고, 충돌을 추가하다 보면 어느새 게임다운 형태가 됩니다. 그 과정에서 SpriteKit의 구조도 자연스럽게 익히게 됩니다.

간단한 2D 게임을 만들고 싶다면, SpriteKit은 매우 매력적인 출발점입니다.

SpriteKit 소개 — 첫 게임 앱을 출시하며 배운점 (2) was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

제 직업적 정체성을 말하자면 아마도 저는 백엔드 개발자일 텐데요, 그 정체성과는 꽤 다르게도 이번에 아이폰/아이패드용 퍼즐 게임을 만들어 출시했습니다. 그야말로 갑자기요. 어려서부터 게임을 만들어 보고 싶었고, 또 그간 몇몇 광고 수익 기반 서비스 회사를 다니다 보니 유료 앱이나 서비스에 대한 갈망(?)이 있었던 거 같아요.

게임 제작자 지인의 중도포기작

동네 도서관에 갔다가, 신간도서 코너에서 게임 프로그래밍에 관한 책을 발견했습니다. 책 제목을 보고 있노라니 어려서 게임을 만들어보려 했다는 기억이 되살아나더라고요. 마침, 퇴사 후 한가하던 타이밍이라, 친한 게임 제작자 지인 H에게 가서 물어봤습니다. “혹시 작업하다가 버려둔 프로젝트 없어요?” 별 기대 없이 물었는데, 마침 오래전에 ‘소코반’ 아류작을 만들려다가 버려둔 이미지 셋이 있다고 답하지 뭡니까?

사실은 2D 슈팅 게임을 만들어보고 싶었던 상황이라, 퍼즐 게임이라는 점은 조금 아쉬웠지만, 그래도 오히려 만들기는 쉽겠다는 생각이 들었습니다. 그래픽이 화려하거나 이동이 빠르지는 않아도 될 테니, 저 같은 초보자가 성능 고민 없이 개발하기엔 딱 맞을 수도 있겠다 싶었죠.

예전 애셋들 찾아서 보내주겠다 합니다. 그럼 전 그걸 받아서 개발만 하면 되겠다는 희망을 품었죠.

소코반

소코반은 저 어릴 적 했던 게임입니다. 일본어고, 뜻은 아마 ‘창고지기’일 거예요. 창고를 지키는 사람이요. 게임의 내용은, 창고지기가 창고 안에 있는 상자들을 밀어서 정해진 목표 위치에 놓는 퍼즐 게임입니다. 상자를 하나씩 밀 수는 있지만 당길 수는 없어요. 또 상자를 밀려면 플레이어가 빈 공간으로 먼저 가서 상자를 밀어야 하기 때문에 벽에 붙은 상자를 그냥 꺼낼 수는 없다는 규칙이 있습니다. 단순한 규칙의 이 게임이 당시에는 꽤 흥행했기에, 다양한 아류작들이 다양한 플랫폼으로 출시됐고, 꽤 마니아 층도 있어서, 일반 유저들이 이 퍼즐 맵을 만드는 사람들도 있게 됩니다. 저는 아마 애플IIe에서 해봤던 거 같아요.

일본의 소프트웨어 업체인 ‘씽킹 래빗(Thinking Rabbit)’에서 제작해 1982년에 처음 낸 퍼즐 게임으로, 개발자는 동사의 사장이었던 이마바야시 히로유키(今林宏行). 해외에서도 상당한 지명도가 있어 타이틀인 ‘소코반’은 영어로도 따로 번역하지 않고 ‘SOKOBAN’으로 그대로 쓰며, 한국에도 이 이름으로 흔히 알려져 있다. 원래는 일본어 ‘倉庫番’(そうこばん)인데, 이는 창고지기라는 뜻이다. — 나무위키

처음엔 Rust로 개발하다

마침, 제가 최근 몇 년 러스트로 개발하면서 강의도 제작해서 판매하고 있을 정도였기에, 처음 시작은 러스트로 했습니다. 러스트 기반의 게임 엔진인 bevy를 선택해서 개발하기 시작했죠. bevy로도 iOS나 안드로이드를 타겟으로 배포할 수 있다기에 무난한 선택이었습니다. 어차피 제가 Unity 같은 전문 게임제작 도구를 쓸 줄 아는 상황이 아닌지라 바닥부터 하면 되고, 러스트로 개발하기에 큰 부담은 없는 상황이었으니까요. 암튼 그렇게, 지인이 준 이미지 애셋 일부를 활용해서 웹에서 실행할 수 있을 정도로 구현했습니다. 이때만 하더라도, 깃허브 코파일럿이 보조적으로 코딩을 도와주던 정도였는데, 그 사이에 클로드 코드를 중심으로 세상이 확 변해버렸습니다.

짤막 Rust 강의 홍보

https://inf.run/LPYW

인프런 러스트 강의 30% 할인 쿠폰: 17514-f2f5f26f75f4

웹어셈블리 버전 로딩타임

https://sokobot.hatemogi.com

그렇게 프로토타입을 웹에 배포해 봤습니다. 모바일에서는 너무 느려서 로딩조차 어려운 수준이었고, 데스크톱에서는 일단 플레이는 가능하게 만들었어요. 초기 로딩 시간이 길어서 아쉬웠지만, 일단 로딩되면 쾌적한 속도가 나쁘지 않았어요. 게임 제작자 지인 H가 처음에 전달해준 애셋을 입혀서 만들었습니다.

그럭저럭 프로토타입으로써는 괜찮다는 느낌이 있었지만, 웹 버전으로는 조금 아쉬운 느낌이 있었습니다. 이제 본판 모바일 버전은 뭐로 만들지 고민이 시작됐습니다.

모바일 버전은 뭘로 만들까?

아래의 후보로 고민해 봤습니다.

1. bevy엔진으로 아이폰 모바일 버전 구현 도전
2. Unity/Unreal 엔진을 배워서 도전
3. iOS 네이티브 버전으로 SpriteKit 활용

1번이나 2번으로 하게 되면, 아마 안드로이드 버전도 큰 어려움 없이 구현할 수 있을 거라는 기대가 들었죠. bevy엔진은 러스트 개발자로서 꽤 매력적인 선택이긴 하지만, 아이폰 모바일 버전 구현에서 마주치게 될 의외의 허들들이 걱정되었습니다. 아마 어떻게 어떻게 해결을 할 수야 있겠지만, 분명 복병들이 곳곳에 있겠죠.

2번의 경우에는, 대부분의 게임 개발자들이 활용하는 검증된 플랫폼이니 게임개발을 계속 하려한다면 이참에 입문하는 것도 나쁘지 않은 선택같았습니다. 제 경우에는 2D게임이 주요목표이니 언리얼 엔진보다는 유니티가 더 나을 거라는 챗GPT의 추천이 있었습니다.

3번은, 사실 흔히 하기 어려운 선택인 거 같습니다. 모바일 게임을 개발하는 사람들이 안드로이드 플랫폼을 포기하기가 쉽지 않은데, 아이폰 전용의 프레임워크를 쓴다? 게다가 그마저도 자료가 많지 않다? 어려운 선택이죠.

스프라이트킷

스프라이트킷은 애플의 장치들에서 2차원 그림, 파티클, 텍스트, 이미지, 비디오 등을 그릴 때 쓰는 일반 용도의 프레임워크입니다. 일반 용도라 함은, 꼭 게임이 아니어도 된다는 얘기인데, 그러면서도 물리엔진도 들어있는 거 보면, 게임을 겨냥한 프레임워크이긴 한 거 같습니다.

SpriteKit is a general-purpose framework for drawing shapes, particles, text, images, and video in two dimensions. It leverages Metal to achieve high-performance rendering, while offering a simple programming interface to make it easy to create games and other graphics-intensive apps. Using a rich set of animations and physics behaviors, you can quickly add life to your visual elements and gracefully transition between screens.

아무튼, 제가 만들고자 하는 2차원 퍼즐 게임 같은 경우에, 이 스프라이트킷이 꽤 적절하게 활용할 수 있겠다는 기대가 들었습니다. 아쉬운 건 안드로이드 플랫폼에는 별도로 새로 개발해야 한다는 점인데, 그건 나중에 고민해 보기로 합니다. 일단 전 안드로이드 장비가 없을뿐더러 당장 구매할 생각도 없거든요. 오래전에 비슷한 이유로 샤오미 안드로이드 폰을 샀었는데, 괜히 돈만 낭비했던 경험이 있습니다.

이번 개발의 최우선 목표는, “최대한 간단하게 개발해서 공개한다”는 점이었으므로, 가장 단순한 프레임워크나 개발환경을 선택하는 것이 중요했습니다. 그런 목표 아래에서는 오로지 아이폰만을 목표로 하는 것도 좋은 선택이었습니다.

여기서 흔하게 빠지게 되는 함정이, “유니티를 써서 개발하면, 이미 많은 사람들이 쓰고 있는 강력한 게임엔진을 배우며 쓸 수도 있고, 멀티 플랫폼 환경 배포도 쉬우니 더 나은 선택이 아닐까?”입니다. 그게 맞을 수도 있습니다. 하지만, 그 강력함을 누리기 위해서 배워야 할 점도 많겠죠. 스프라이트킷은 너무나 단순하기 때문에, 지금 제수준에서는 오히려 나은 선택일 수도 있겠다 싶었습니다.

“뭐가 더 간단해?”

라는 질문에, 스프라이트킷이라는 결론이 쉽게 도드라졌습니다. 이런 결정에 있어서, 뭐가 맞고 틀리고를 고민하기 시작하면, 결국 맞는(?) 선택은 유니티를 쓰는 게 될 거고, 그러면 전 또 유니티를 공부하다가 세월이 다 갈게 불보듯 뻔했습니다. 유니티를 써본 사람들에게는 유니티가 더 간단한 프레임워크일지도 몰라요. 그저 뉴비 입장에서 첫인상을 놓고 볼 때 스프라이트킷이냐 유니티냐를 놓고 따졌을 때, 느낌으로 스프라이트킷을 쓰기로 결정합니다.

첫 출시

중간과정 일단 생략하고, 앱 출시 소식부터 전합니다.

• 애플 앱스토어 링크

• 데모 유튜브 영상

현재 버전 기준, 155판까지 출시되어 있는데, 꽤 재미있습니다. 오프라인에서도 플레이 가능하기 때문에, 비행기 같은 데서도 재밌게 즐기실 수 있어요. 머리쓰는 퍼즐 게임 좋아하시면 꽤 재밌을 거예요. 첫판부터 꽤 어렵기 때문에 만만하게 보시면 안 되고요. ㅎ

다음 이야기

다음에는, 스프라이트킷의 간단한 구조에 대해서 이야기해 볼까 합니다. 이 글에 좋아요를 눌러주시면 다음 글이 빨리 올라옵니다. 핫핫. 여기까지 읽어주셔서 감사합니다.

첫 게임 앱을 출시하며 배운 점 — Elephant 개발기 (1) was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

그리고, “제주-서울 출퇴근 생활은 의외로 할 만하다. 단, 서울에 반드시 고정 거점을 마련하자” 정도의 배운 점을 공유해 드리겠습니다. 제주에서의 개발자 처우는 한계가 있기 때문에, 오가는 항공권이나 숙박비를 빼더라도 서울에서 근무하는 게 경제적으로 나은 선택일 가능성이 높습니다. 실험적으로 매주 주중에 가족들과 떨어져 있는 생활을 해보았는데, 아이가 이제 꽤 커서인지 그럭저럭 할만하긴 했습니다. 비용적인 계산으로 고정 거점을 마련하지는 않고, 용인 부모님 댁에 들르거나 저렴한 숙소를 이용하고는 했는데, 이건 그다지 좋은 선택은 아니었던 거 같습니다. 차라리 돈을 좀 더 쓰더라도 원룸이라도 하나 구하는 게 낫겠다 싶습니다.

암튼 그렇게 AI 업계에 숟가락 살짝 얹어봤고, Rust로 개발해 보고, 결국 파이썬도 잘 활용해 보는 경험 잘 쌓았습니다. 특히 PostgreSQL의 벡터DB를 써볼 기회가 있어서 즐거웠네요. 임베딩 벡터 거리 계산이 너무 잘 돼서, 왜 별도의 벡터 DB를 써야 하나 의구심이 생길 정도였습니다. 뭐, 제가 잘 모르는 그런 것들이 있겠죠. 파이썬 웹 개발 환경도 꽤 실용적인 측면을 잘 배워봤습니다. 스타트업 환경에서 특히 좋은 거 같아요.

좀 쉬다가 재취업을 알아보려고 했는데, 여차저차하다 보니 좀 다른 길을 걸어볼까 하는 생각이 들었습니다. 적어도 올 한 해는 독립 개발자 생활을 해보려고 해요. 요새는 워낙 혼자서도 AI의 도움으로 많은 일을 할 수 있는 시대이니 이 시류를 잘 타봐도 좋겠다 싶습니다. 문제는, 누구나 다 많은 일을 잘할 수 있으니, 그중 나의 경쟁력이 뭐가 있겠나 싶은 걱정이 든다는 점인데요. 뭐 걱정도 제게만 있는 건 아니니까요.

암튼, 잘 지내봅시다.

업무용 프로그래밍 언어 활용 경험

꽤 다양한 언어를 업무용 언어로 활용해 왔습니다. 무난하게는 자바나 코틀린 같은 언어를 썼었고, 특이하게는, 클로저, 스칼라, 그리고 심지어 하스켈까지 업무용으로 활용하며 월급을 받았습니다.

자바는 대중적으로 성공한 언어이고, 백엔드 개발자로서 가장 기대소득이 높은 언어이지만, 언어적으로 이제는 제 성향과는 잘 맞지 않아서 괴롭고, 코틀린은 어차피 스프링 판이라 크게 다를 것 없이 답답합니다. 자바도 사실 자바라서 두드러기가 일어나는 게 아니라, 모든 것을 스프링 판에서 하려는 문화가 저와 안 맞는 거 같습니다. 그래, 뭐 EJB보다는 낫지 뭐. CORBA 시절도 있었는데, 스프링 정도야 가볍지 뭐.

그렇다고 나머지 함수형 프로그래밍 언어들은 대단히 우아하지만, 대중성이 떨어져서 불편한 점을 무시할 수 없습니다. 업무 활용에 있어서 실용성은 둘째치고 채용이나 구직은 물론, 학습 차원에서도 아쉬운 면들이 있죠.

한편, Go 언어는 대중적으로도 성공했고, 그 가벼운 환경이 꽤 매력적입니다만, 언어 수준이 좀 떨어집니다. GC가 있는 현대판 C언어 정도라고 봅니다. 그래도 Go 언어 정도면, 자바 환경에서 일어나는 두드러기 없이도 그럭저럭 일해볼 수 있겠다 마음먹던 차에, 금상첨화 Rust로 기회가 찾아왔습니다.

Rust나 Go언어나 고성능 가벼운 정적 바이너리를 생성해 낸다는 점에서 똑같이 매력적입니다만, 언어 수준에 있어서 Rust가 훨씬 매력적이더라고요. 비슷한 타깃을 염두한 언어 생태계라서 둘이 비교되기도 합니다만, 솔직히 러스트 사용자들 입장에서는 Go랑 비교된다는 것 자체가 이해되지 않을지도 모릅니다.

이직한 회사에서 Rust 활용

지난 4월에 새로운 회사로 이직했고, Rust를 주 프로그래밍 언어로 쓰게 되었습니다. 평범한 흐름은 Go 언어를 주로 쓰게 될 만한 상황이었고, 어쩌면 우겨서(?) 러스트도 일부 활용가능하겠다 정도의 기대였는데, 뜻밖에도 자연스럽게(?) 러스트를 메인으로 쓸 수 있게 되었습니다.

하드웨어 전문가가 많은 인력 구성인데, 이분들은 C++를 많이 쓰시는 것 같고, Rust에 대해 꽤 열려있는 분위기입니다. 게다가 업계(?)가 Rust를 꽤 공격적으로 쓰다 보니, 오히려 환영받는 느낌까지도 있습니다. 원래 일하던 일반적인 소프트웨어 백엔드 개발의 입장에서 Rust는 여전히 주류와는 거리가 멉니다만, LLM 업계로 넘어와 보니 Rust가 주류인 상황이라 놀랍습니다.

이직한 회사에는 현재 60여 명이 일하고 있고, 그 중 엔지니어가 50여 명인 상황입니다. 회사에서 어떤 언어를 쓰시나 기웃거려 보면, Rust, C++, Python, Verilog가 메인인 것 같습니다. (Verilog는 완전 하드웨어 쪽 분들이 쓰는 언어인가 봅니다. 학창 시절 전자회로 수업시간에 들어는 본 것 같습니다.)

업무 관련 미팅으로, 이쪽 업계에서 잘 나가는 퓨리오사 분들을 만날 일이 있었는데, 듣자 하니 퓨리오사에서는 Rust를 주로 쓰고 있다고 합니다. 대단히 만족하며 활용하고 있다고 합니다.

이 분야에서 세계적으로 잘 나가는 허깅페이스(huggingface)라는 회사에서도 러스트로 많은 것을 만들어 공개하고 있어서, 기웃거리는 재미가 쏠쏠합니다. 파이썬에서 쓸 수 있는 라이브러리들도 내부적으로는 러스트로 개발되어 있는 구성이 매력적입니다.

Rust로 업무를 하며 느낀 점

실무로 써보니 역시 빠르고 가볍고 안전한 프로그래밍 언어입니다. 간단한 마이크로서비스를 구성해서, AWS Lambda에 서버리스(Serverless)로 올려놓으면 빠르게 응답하고, 비용도 저렴하고, 게다가 기분(!)이 좋습니다.

실무 프로그래밍을 할 기간이 10년쯤 늘어난 것 같습니다. 20여년 넘게 실무를 하다보니 이제 업무 개발은 좀 지겨워지는 것 같았는데, Rust라면 여전히 실무 프로그래밍을 계속해도 되겠다는 생각이 드네요. 이상적으로는 본격 함수형 프로그래밍이 더 우아하지만, 실용적 측면에서는 아무래도 한계가 명백하다보니 계속하기는 쉽지 않겠다는 느낌이었는데, Rust는 그런 면에서도 만족스럽습니다.

단점은, 언어가 좀 어렵습니다. 독자적인 메모리 모델과 라이프타임 시스템이 있어서, 처음에는 이해하기 어려운 부분이 많습니다. 그래도, 이해하고 나면 그만큼 안전한 프로그래밍을 할 수 있다는 장점이 있습니다. 러스트는 언어 자체가 안전하게 설계되어 있어서, 프로그래머가 실수를 하더라도 컴파일러가 잡아주는 경우가 많습니다. 이런 면에서는, 러스트를 배우는 것이 프로그래머로서의 성장에 도움이 될 것 같습니다.

Rust를 배우는 방법

공식 홈에 있는 문서를 차근히 보는 것도 좋겠고, 시중에 나와있는 책을 사서 보는 것도 좋겠습니다. 한국어로 번역된 책도 꽤 많아서, 서점에 가서 쓱 살펴보고 마음에 드는 책으로 두어 권 사다가 읽으시면 잘 배우실 수 있습니다.

강의를 들으며 배우시는 것을 좋아하시는 분들은 인프런에 있는 제 강의를 구매하셔도 좋겠습니다. 제 강의는 러스트를 처음 접하는 분들을 위한 강의로, 러스트의 기본적인 문법과 개념을 설명하고 있습니다. 러스트를 처음 접하는 분들에게 좋은 강의입니다.

인프런 러스트 강의 30% 할인 쿠폰: 17514-f2f5f26f75f4

중급 과정 강의도 준비 중이니, 그것도 기대해 주세요.

마무리

오랜만에 근황 공유겸 간략한 글을 적으려 했는데 적다 보니 강의 광고글이 되어버렸네요. 조만간 LLM 업계 뉴비로서 배우고 있는 것들을 공유하는 글을 적어보겠습니다.

Rust를 업무용 언어로 쓰다 was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

지난 글에 호응이 과분하여, 더 용기를 내어 같은 주제의 글을 쓰기로 했습니다. 마침, 지난 글을 올린 즈음에, 가까운 주변 개발자 한 분의 하소연을 듣게 되었는데, 그 불편한 심리 상태의 원인이 꽤 공통적이라는 점에서 다음 주제가 바로 떠올랐어요. 불편한 심리 상태에 빠져있는 당장의 상황에서는 이런 의견을 드려도 들리지 않기 때문에 바로 전달드리기는 어려웠습니다. 아니, 사실 이런 의견은 누구도 듣기 싫어할 것 같습니다. 이렇게 글로 적어뒀는데, 무심히 읽게 되어 공감이 드는 부분이 있다면 다행인 정도이겠습니다.

내가 맞다는 환상

어쩌면 본능의 영역인 거 같기도 하고, 아니면 학창 시절 시험 문제에 정답을 적어내야 하는 교육 과정에 따른 악습인 것 같기도 합니다. 어떤 원인인지는 모르겠지만, 우리 대부분은 “내가 맞다”라는 환상에 사로잡혀 있는 것 같습니다. 때로는, 내가 틀린 걸 쿨하게 인정하고 넘어가기도 하지만, 이건 미처 내가 관심 갖지 않았던 무지한 영역에서일 뿐이고, 잘 안다고 생각하는 자신 있는 부분에서는 틀린 걸 인정할 수 없습니다. 틀린 걸 인정하지 못하는 것은 물론이고, 남이 조금이라도 틀린 표현을 하면 바로 지적을 해서 바로잡아주고 싶어 하지요. 내가 자신 있는 부분인데 날 틀렸다고 지적한다? 그럼 맞서 싸워서 내가 맞고 남이 틀리다는 걸 인정하게끔 하려고 합니다. 생판 모르는 사람과도 말이죠.

시험을 볼 때나, 일을 할 때나 어떤 중요한 부분에 있어서는 이런 자세가 중요할지도 모르겠습니다. 하지만, 나머지 일상 대부분에서는 이 맞고 틀리고가 그다지 중요하지 않습니다. 이것도 맞고 저것도 맞을 수도 있고, 취향의 차이일 뿐, 맞고 틀리고의 문제가 아닌 경우도 많습니다.

“내가 맞다”는 환상은, “남이 틀리다”라는 환상으로 이어지고, 반대로 “남이 맞다”면 “내가 틀리는” 고통으로 이어지기도 하는데요, 왜 굳이 내가 꼭 맞아야 합니까? 틀린 지식을 갖고 있으면 죽어나가는 생존의 문제에 놓여있기라도 한 것처럼요.

내가 틀릴 수도 있습니다

겸손한 마음으로 “내가 틀릴 수도 있다”라고 표현하는 수준을 뛰어 넘어서, “틀려도 된다”라는 용기를 내야 합니다. 내가 틀릴 수도 있다는 가능성을 열어두면, 다른 의견에 대해 열리고 배우기 편해지고, 마음이 불편한 지점도 대폭 사라지며, 싸울 일도 줄어듭니다.

내가 틀려도 된다면, 상대 역시 틀려도 되며, 설령 상대가 명백히 틀리다고 할지라도 인정할 수 있습니다. 나에게도 관대하고, 타인에게도 관대해지면 되는 거죠. 틀린 걸 알게 됐을 때, 겸허히 배우면 됩니다. 굳이 정정할 필요가 없다면 안 해도 됩니다. 틀려도 되는 거니까요.

이렇듯 “틀려도 된다”라는 생각에서 큰 해방감이 이어집니다. 개발자가 뭐 평생 시험을 보는 상태에 있는 건 아니잖아요. 물론 때로는 맞고 틀리는 문제가 상당히 중요한 걸 무시하자는 게 아닙니다. 그렇지 않은 영역에서 쓸데없는 고민을 부릴 필요가 없다는 점을 말씀드리는 거예요.

지금, 제 의견이 어떤 점에서 틀렸는지를 지적하고 싶으신가요? 이미 그것이 “당신이 맞고”, “제가 틀리기” 때문에 그런 생각이 드는 겁니다. 이미 “내게 맞는 의견이 있는데, 저 사람이 날 틀렸다고 말하네?”라는 흐름인 겁니다.

전 지금 제 글의 내용이 틀려도 되고, 당신의 내용이 맞다고 생각합니다. 이 자체로 너무 편안해요.

각자의 세상에서

우리 모두 한 세상에서 살고 있지만, 다 나름의 관점에서 세상을 바라봅니다. 사실상 각자의 세계가 너무 다른 상태인 거죠. 이 세상과 세상이 만나서 얘기하다 보면, 세계관이 달라서 빚어지는 충돌들이 있습니다. 긍정적 충돌일 때도 있고 소모적인 부정적 충돌일 때도 있습니다.

각자 내 세계와 그들의 세계가 다름을 인정하고, 서로의 세계를 일치시키려는 불필요한 시도를 포기할 때에 엄청난 에너지가 절약되는 것 같습니다.

모두가 사랑으로 하나의 세상

위대한 스승들은 이 세상이 사랑으로 가득 찬 하나의 세상이라고 하더군요. 언젠가 깨닫게 된다면 그런 통합의 세상에 눈을 뜰지도 모르겠지만, 아직 현실 세계에서 그저 조금 마음 편한 자세를 유지하는 정도로는 각자의 세상을 인정하고 내 세상에서는 이게 맞고, 당신 세상에서는 그게 맞다, 그리고 그걸 꼭 일치시킬 필요는 없다는 점만으로도 충분한 효과가 있다고 생각해요.

그래서 어쩌라고? (2)

내 의견이 맞다는 주장을 하고 싶거나, 타인의 의견이 틀렸다고 말하고 싶은 순간에, 해당 의견을 말하지 않습니다. 그 의견을 말하고 싶어 하는 본인 스스로를 바라보고 인식합니다. 이 의견을 표출해서 내가 얻는 이득은 무언지 따져봅니다. 과연 내가 맞아야 하는지 고민해 보고, 맞다고 할지라도 상대방이 틀린 걸 인정함으로써 얻게 되는 공통의 이익은 무엇인지 따져봅니다. 그 사이 잠깐의 호흡을 하는 것만으로도 큰 이익이 체감될 것입니다.

[이전 편] 행복한 개발자가 되는 길 (1) — Breathwork

행복한 개발자가 되는 법 (2) — I may be wrong was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

이건 제가 감히 명쾌히 다룰 수 없는 주제이겠습니다만, 요새 주된 관심사이다 보니 한 번쯤 글로 적어보면 좋겠다는 생각이 들었습니다. 저 스스로 정리해보고 모종의 다짐을 하는 목적이 크고, 어쩌면 누군가에게도 공감이 되는 내용이 있을 수 있겠다는 기대를 (아주 조금) 해봅니다.

행복을 추구하고, 불행을 걱정하기

너무 당연하게도, 모든 사람이 공통적으로 행복을 바라고 고통을 피합니다. 뭘 이루고자 한다거나 어떤 행동을 취한다거나 제자리에 앉아서 걱정을 한다거나 하는 행동의 배경에는 행복을 좇거나, 두려움을 떨치려는 의도가 있는 거죠.

행복하고자 하는 동기는, 가볍게는 지금 보다 더 행복해지고 싶다거나, 아니면 지금은 불행하지만 나중에는 행복해지고 싶다는 바람이 있습니다. 어느 쪽이든 지금은 충분히 행복하지 않다는 생각인 거죠. 예를 들어, 지금은 내가 신입 개발자지만, 열심히 공부하고 경험을 쌓아서 유능한 개발자가 되면 행복할 것 같다고 생각한다거나, 지금은 연약한 몸이지만, 운동으로 튼튼한 몸을 만들면 행복해 질 거라거나, 지금은 취준생이지만, 취업에 성공하면 행복할 거라는 기대 같은 것들이 있겠죠.

한편, 두려움의 배경에는, 지금은 그럭저럭 괜찮지만 자칫하면 불행해질 수도 있다는 걱정이 있습니다. 아니면 지금도 불행하지만, 더 불행해질 수 있다거나, 아니면 지금은 행복하지만 이 행복을 유지하려면 무언가를 열심히 해야 한다는 생각이 드는 것이 기본적입니다.

그렇게 되면 정말 행복한가?

개발자로 취업하면 행복한가요? 취준생 입장에서는 그렇게 기대하겠지만, 안타깝게도 막상 취업하면 이 회사가 괜찮은 건지 내 커리어는 어떻게 될 건지, 다음 직장은 어디로 노려야 하는지, 연봉이 적으면 적은 대로 많으면 많은 대로 또 다른 문제를 일으킵니다.

대기업에 입사한다거나, 네카라쿠배 취업해서 억대연봉받으면 행복할 것 같고, 아예 미국 FAANG으로 해외취업에 성공해서 해외파 개발자 인증을 받으면 행복할 것 같습니다. 내가 그렇게 된다는 생각만으로도 입가가 올라가고 행복할 것 같은 기대감이 일어납니다만, 정작 그런 입장이 현실인 사람들이 스스로 행복하다고 말하거나, 행복한 모습이 느껴지지는 않는다는 점이 흥미롭습니다. 그들의 조건은 당연한 것이 되고, 또 다른 불만이 그 자리를 대체합니다.

숨쉬기 운동으로 시작한, 사소하지만 신기한 경험

작년 말 즈음부터, 숨쉬기 운동(breathwork)를 기반으로 명상을 하고 있습니다. 숨쉬기 운동은 ‘윔 호프 호흡법’ 같은 숨쉬기 방법을 가이드에 맞춰 따라하는 운동입니다. 유튜브에 ‘breathwork’로 검색하면 수많은 가이드 영상을 찾을 수 있습니다. 대략 15분 정도 따라 하기에 적당해요. (사람에 따라서는 안맞을 수도 있다고 하니, 처음에는 가벼이 실험적으로 접근해 보시는 정도가 좋을 것 같습니다.)

명상이 여러모로 좋다는 것은 익히 들어왔지만, 꾸준히 하기 힘들었는데, 숨쉬기 운동을 하고 나면, 명상 집중도가 높아져서 숨쉬기 운동 후에 명상을 이어서 할 수 있고, 명상이 잘 되고 나면 그 효과가 체감되어서 매일 지속적인 명상을 할 수 있게 됐습니다. 예전엔 명상이라면 5분도 하기 힘들었는데, 요즈음은 하루 서너 번 20분~40분씩 할 수 있어서 총 한두 시간씩 할애하고 있는 것 같습니다. 억지로 하려면 안되고, 효과가 체감되면서부터 좋아졌습니다. 사소하게는 시야가 밝아지고 머리가 맑아지는 체감이 즐겁습니다.

두어 달 밖에 안 됐는데, 몇 가지 사소하지만 신기한 체험을 몇 가지 경험했습니다. 공개적으로 적기에는 애매한 것들이지만, 그중에 하나는, ‘진정한 자아는 기본적으로 무한히 행복한 상태이다’라는 걸 아주 찰나의 순간에 느껴본 것 같다는 점이 있습니다. 그렇게 긴 순간도 아니었고, 명확하게 설명할 수 없는 경험이라서 확실하게 기술할 수 없어서 아쉽습니다.

암튼, 다양한 명상 서적이나 종교에서 이야기하는 인간의 기본은 행복한 상태인데 너 스스로가 고통을 감싸 쥐고 있다는 점을 더 경험으로 깨닫게 되면 좋겠다는 기대와 함께, 이런 생각이 들었습니다. ‘어쩌면 어떤 경험으로 더 잘 알게 될 수도 있겠지만, 일단 그 사람들이 얘기하는 걸 무작정 믿어본다면 어떨까?’

모두가 본디 평안한 상태라면

만약 그 참자아(true self)가 본디 더 할 것 없는 평안한 상태라면 ‘행복 추구’가 무의미해집니다. 지금 이미 덧붙일 수 없는 행복 상태인데 뭘 애써 더해서 행복을 추구하나요. 이미 모든 것을 이뤘으니, 더 이뤄야 할 무언가가 없다는 얘기인 거죠. 본능적 에고는, 지금 이럴 때가 아니라며 이런저런 걸 해야 하고, 그러려면 또 그에 앞서서 뭐뭐뭐를 해야 한다고 압박하고 들겠지만, 사실 그럴 필요가 전혀 없다는 얘기인 거죠.

그렇다고 현실적으로 아무것도 안 해도 되니까 가만있어라, 이런 뜻은 아닐 테고(그래도 상관은 없지만) 정말 무언가 하고 싶거나 해야 하니까 하는 거지, 미래의 행복을 위해서 억지로 해야 하는 상황이 아니게 된다는 뜻으로 이해해 보았습니다. 그런데 이게 참 편안해져요. 내가 뭔가 해야 했어야 하는 일들이 되게 많았는데, 해도 되지만 안 해도 된다는 사실만으로도 해방감이 느껴진달까요. 정말 꼭 해야 하는 일이 아니었던 거죠. 그중에 꼭 해야 하는 일들은 하고, 하고 싶은 건 하되, ‘막연히 행복해지기 위해 하려고 했던 별 쓸데없는 일들’을 버려버리는 겁니다.

개발자 뿐 아니라

이 관심사가 새삼 흥미로운 게, 삶의 모든 분야에서 다양하게 내가 뭘 (쓸데없이) 바라고 있었다는 점을 인식하게 된다는 점입니다. ‘쓸데없이 바라고 있었다’는 사실조차 인식하지 못했어요. 아까 잠깐 언급한 신기한 찰나에서 그 사실이 잠시 인식되자, 아 그게 무거운 마음이었다는 생각이 들고, 다시 그 찰나에서 빠져나오자 무거운 마음 상태가 기본이 되었습니다.

암튼, 행복해지려면 돈을 얼만큼 벌어야 하고, 건강은 어떻게 되어야 하고, 내 몸무게는 어떻게 되어야 하며, 아이 공부는 어떻게 했으면 좋겠고, 이런 지극히 정상적인 고민들의 관점이 대폭 흔들리는 상황입니다.

스스로는 어떻게 바뀌어갈지 흥미로운 상황입니다. 이미 뭔가 많이 바뀐 것 같아서 재밌고요. 그게 뭔지 모르겠습니다만 말이죠. 헛헛.

그래서 뭘 하라는 거야?

굳이 말해보자면, 꼭 그래야 하는 것은 아니지만 “숨쉬기 운동” 경험 추천드려 봅니다! 이미 명상이 잘 되시는 분들은 불필요할 것 같지만, 평소 명상에 관심이 있었는데 잡생각이 많이 끼어들어서 집중하기 힘들었던 분들에게 좋다고 생각해요.

[다음편] 행복한 개발자가 되는 길 (2) — I may be wrong

행복한 개발자가 되는 길 (1) — Breathwork was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

충분한 시간이 필요합니다

개발자하기로 마음 먹었으면 하루 빨리 실력있는 개발자가 되고 싶은 게 당연합니다. 달리기도 시작할 때는 꾸준히 운동하는 것만이 목표였지만, 어느새 잘뛰고 싶어지더라구요. 하지만 달리기라는 게 하루아침에 잘 뛰어지지가 않습니다. 충분한 기간을 두고 조금씩 늘려가야지, 급한 마음에 서둘러 마일리지를 늘리다가는 부상을 입기 십상입니다. 마음만 급하고 스트레스만 받고, 정작 실력은 늘지 않는 문제에 빠지는 거죠. 뛰기 시작해서 3개월만에 마라톤을 뛰고 싶을 수도 있지만, 그건 무리한 생각입니다. 되는 사람도 있겠지만, 대부분의 사람들은 그러다가는 부상을 입고 말 거예요.

개발자도 그렇습니다. 부트캠프 나오고 몇 개월만에 개발자 되고, 2년차에는 수퍼 주니어가 되고 싶은 게 기본입니다만, 그게 그렇게 짧은 시간에 되는 게 아닙니다. 꾸준히, 매일매일, 매주매주 마일리지를 쌓아나가다보면 어느새 실력있는 개발자가 되는 게 기본 루트일 것 같습니다.

초보 시절에는 초보임을 인정하고 급하지 않게 꾸준히 훈련하는 것이 중요하겠습니다.

내가 직접 해야 합니다

유튜브에 워낙 고품질의 정보가 많기 때문에 달리기도 배울만한 채널이 많습니다. 수많은 달리기 유튜브 채널들을 보며 어떻게 훈련해야 하는지, 달리기 자세는 어떻게 해야 하는지, 신발은 어떤 걸 신으면 좋은지 수두룩한 정보를 구할 수 있습니다. 그런 유익한 정보도 중요하지만, 정작 가장 중요한 것은, 나가서 뛰는 행위 자체입니다. 그 모든 걸 압도하는 중요한 부분이 본인이 달리는 거리입니다.

개발도 마찬가지입니다. 개발서적을 학습하고, 온라인 강의를 수강하고, 질문과 답변으로 학습하고 이런 일들이 꽤 도움이 되지만, 정말 정작 중요한 것은 내가 직접 개발해보는 행위입니다. 개발하는 행위 자체를 달리기 마일리지라고 치고 꾸준히 매일매일 쌓아가야 합니다. 꾸준히 하면서, 보조적으로 서적을 보며 수강도 하는 것이 맞겠습니다. 만날 책이나 강의만 보고 있는 것은, 유튜브에서 달리기 영상 보면서 끄덕끄덕하면서 정작 나가서 뛰지는 않는 행위나 마찬가지입니다. 말짱 꽝이죠.

훌륭한 다수의 의견이 내게는 중요치 않을 수 있습니다

나보다 나아보이는 다수의 개발자들이 이렇다저렇다 좋은 정보들을 줄 때가 많은데, 정작 그 정보들이 내게는 유효하지 않을 수도 있습니다.

달리기로 예를들면, 저같은 초보들이 흔히 빠지는 함정이, 신발은 뭘 신어야 하는지, 케이던스는 얼마로 뛰어야 좋은지, 발 착지법은 어떻게 가져가야 하는지, 물은 얼마마다 마셔야하는지, 팔동작은 어떻게 흔들어야 하는지, 별 사소한 팁들이 많습니다. 게다가 친절하게도 이 모든 정보들을 시시콜콜 알려주는 사람들이 많아요.

그런데, 열심히 정보를 취합하다보면, 어쩌면 저 정보들의 의미없겠다 싶을 때가 있습니다. 예를들어 케이던스를 놓고 보자면, 180정도가 가장 효율적이라고 하는데, 잘 뛰는 선수들이 180을 내는 거지, 내가 뛰는 속도에서 내 신체에서 과연 180이 최적인가는 의문이 있습니다. 그러니까, 선수급이 마라톤을 2시간 초반에 뛰는 속도에서 최적인건데, 내가 2시간대에 마라톤을 뛸 수 있을리 만무합니다. 내가 그런 부차적 지표에 기준을 삼아서 노력하는 것은 무의미할 수도 있겠다 싶습니다.

그런데 어설픈 상식수준에서는 그게 그럴싸해 보이잖아요? 엘리트 선수들 보면 보통 180케이던스를 유지하더라. 그리고 실험한 결과를 보면 케이던스가 180근처인 게 가장 효과적이더라라는 결과들도 있겠죠. 근데 그게 그렇다고 억지로 케이던스를 180에 맞추는 게, 초보인 내 입장에서 달리기 마일리지보다 더 중요하냐?는 건 의심해봐야 하겠습니다.

개발자 입장에서, 뭐는 이렇게 해야하고 저건 이렇게 해야 한다는 주장들을 접할 때가 많은데요, 은근 빈번하게 별 쓸데 없는 고민에 시간 낭비하고 있는 경우가 많습니다. 한번쯤 정말 도움이 되는 얘기인가 고민해 볼 필요가 있다고 생각해요.

달리기만 할 수는 없습니다

하루라도 빨리 좋은 개발자가 되기위해, 잠 줄여가며 노력하고 싶을 때도 있습니다. 하지만, 이게 장기전이기 때문에 단거리 달리기 하듯 계속 달릴 수는 없어요. 게다가 달리기 실력이 느는 것은 훈련시간 자체가 아니라, 훈련 후에 잘먹고 잘 쉴 때, 특히 잘 때 늡니다. 잘 자야 한다는 얘기예요. 잘 시간 줄여서 달리는 건, 잘 몰라서 하는 바보 같은 일이죠.

개발도, 너무 개발만 몰입해서는 개발실력이 늘리 없습니다. 잘 자는 건 당연하고, 개발 외의 공부들도 병행해 줘야 합니다. 잠 줄여서 개발 공부한다? 이것도 어리석은 일입니다. 공부했으면 잘 자야 머리속에서 정리가 되는 거죠.

재미가 있으면 훨씬 편합니다

처음에는 작심삼일을 여러번 하겠다고 달리기를 이악물고 시작했습니다. 의지박약인 내가 꾸준히 달리리면 정신 바짝차리고 열심히 해야 하는 거죠. 아무리 강한 의지력을 발휘한다고 해도, 사람인 이상 한계가 있습니다. 의지력만으로 1주일에 60K를 뛴다? 불가능한 일이라고 보겠습니다. 그럼 어떻게 이 지경(?)이 됐냐? 달리기 자체가 재밌어졌기 때문입니다. 재밌으면 지속하기가 훨씬 편합니다. 달리기가 재밌을 줄은 몰랐습니다.

남들은 개발을 어떻게 시작하게 됐는지는 몰라도, 적어도 제가 보기에 대단히 재밌는 활동입니다. 이 재미를 찾지 못하면 꾸준히 하기 너무 힘들지 않겠어요? 달리기는 하다 말면 그만이지만, 직업 개발자가 되기로 했다면 내 커리어 수십년 동안 해야 하는데, 이걸 이 악물고 꾸준히 열심히 한다? 너무 어려운 길이죠. 재미를 붙여서 하는 게 맞겠습니다. 재미가 있으면 누가 시키지 않아도 열심히 하겠죠.

그러니 그냥 막무가내로 열심히만 할 게 아니라, 재밌게 하는 방법을 고민해봐야 하겠습니다. 흔한 자료들은 “재미”에는 큰 중심을 두지 않기 때문에, 아쉽게도 각자 스스로 재미 포인트를 찾아야 하는 상황인 것 같습니다. 억지로 열심히 해서 잘하는 사람들도 많겠지만, 나도 꼭 그래야 하는 건 아닙니다. 재밌게해서 잘해도 되는 거, 아니 더 좋은 거잖아요.

확실한 것은, 재미있는 것은 맞습니다. 그러니까 제가 이렇게 오랫동안 하고 있는 거겠죠. 정확히 말하자면, 재미 없으면 안하는 것이 맞겠습니다. 왜 힘들게 재미 없는 걸 계속 공부하며 노력을 해야 하나요? (늘 재밌는 건 아니지만, 꾸준히 할만큼 재밌는 포인트는 반드시 있어야 합니다)

비교는 정신건강에 해롭습니다

달리기는 기록이 정확히 드러나기 때문에 남들과 비교하기 쉽습니다. 나는 어느 정도 속도로 얼마나 뛸 수 있는데, 저 사람은 어떻지? 내가 더 잘 뛰나? 저 사람이 더 잘 뛰나? 이런 비교는 내 달리기 본연의 목적과 다를 수 있습니다. 더 빠르고 느리고를 기준으로 삼으면 항상 누군가는 나보다 빠르기 마련이고 그럼 난 또 그 사람보다 못한 사람이 되는 논리에 빠지게 되는 거죠. 대회를 나가더라도 “완주”에 중점을 둔다면 참가자 대부분이 즐거운 결과를 누릴 수 있는데, “1등”을 노린다면, 그 1등은 행복할지 몰라도 나머지 절대 다수의 참가자들은 들러리가 되는 거 아닐까요?

개발자가 되려는데 남들보다 잘하는 개발자, 최고의 개발자가 되는 것이 목표라면, 이건 스스로를 이미 고문하는 감옥에 가두고 시작하는 꼴입니다.

달리기로 치자면, 지난 달의 나보다 잘 뛰게 되었을 때의 기쁨을 만끽한다거나, 아니면 꾸준히 뛰는 것만으로 만족할 수 있다면 지속적으로 즐겁게 달릴 수 있습니다. 애초에 달리기를 시작한 목적도 건강에 도움이 되는 활동이라는 것이기 때문에 그 목적은 대단히 초과달성하고 있는 거죠.

개발자로 치자면, 어떤 기준을 갖고 방향을 잡을지 스스로 잘 고민해보면 좋겠습니다.

꾸준함이 제일 중요합니다

달리기 실력이 느는 가장 중요한 팩터는 꾸준히 달리는 행위입니다. 어느 날 반짝 열심히 달린다거나, 어느 날 하루 오래 달린다고 해서, 갑자기 실력이 늘지 않습니다. 오랫동안 꾸준히 지속적으로 노력해야(즐겨야) 어느 순간 실력이 늡니다.

개발도 꾸준히 수련해야 합니다. 어느날 반짝 노력하거나 비기를 획득한다고 되는 게 아니니 끈기를 갖고, 재미를 붙여 오랫동안 열심히 할 마음으로 지내면 좋다고 생각해요.

내가 그리 대단치 않습니다

달리기 시작할 때는, 제가 그래도 어려서 육상 선수였는데 조금만 하면 잘 할 줄 알았습니다. 근데 뭐 당연하게도 한참 못 뛰더라구요. 오래달리기는 그야말로 마일리지가 깡패입니다. 많이 뛰면 뛴 만큼 잘하게 되어있습니다. 마일리지를 일단 채워두고 거기서 실력이 나누어지기야 하겠지만, 일단 초보된 입장에서는 오로지 달리기 마일리지만이 핵심입니다. 평소 다른 운동을 잘했건 어려서 육상선수였건 말건 이딴 건 아무런 도움이 되지 않습니다. 그저 초보된 입장에서 차근차근 쌓아 올려야 합니다.

개발도 그렇습니다. 우리가 어떤 다른 분야에서 날고 기었다 한들, 새로 시작했으면 생초보입니다. 겸손하게 난 아무것도 아니라는 시작점에서 차근히 여유롭게 나아가면 됩니다. 지나치게 기죽을 필요도 없지만, 그렇다고 강한 에고를 내세워서 좋을 것도 없겠습니다.

이상, 달리기와 개발을 좀 억지로 엮어서 팁을 적어보았습니다. 뛰어난 러너도 아니고 훌륭한 개발자도 아니면서 이렇다저렇다 적으니 부끄럽습니다만, 공감되는 부분이 있으셨으면 좋겠습니다. 어떻게 생각하시는지 댓글 남겨주시면 제게도 큰 도움이 되겠습니다.

달리기에서 배우는 괜찮은 개발자 되는 법 was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

애정하는 프로그래밍 언어 Elm을 만들고 있는, 존경스러운 Evan의 StrangeLoop2023 발표. 프로그래밍 언어의 경제적 측면을 설명해주는 영상. 너무 재밌는데, 내가 영어를 잘 못해서 더 재밌게 알아듣지 못하는게 아쉬울 지경.

암튼, 프로그래밍 언어를 놓고 선택할 때도, 그 언어의 경제적 측면을 고려해서 내 필요에 잘 맞는지 판단하는 것도 중요하다는 생각.

각 언어의 공식 홈페이지에는 좋은 말만 씌여있지만, 사실 그 언어가 어떤 돈으로 굴러가는지를 알아야 그 언어가 흘러갈 방향을 가늠하는 데도 좋다는 포인트가 특히 와 닿았습니다.

프로그래밍 언어의 경제적 측면 by Evan Czaplicki was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

내용

(목표) 무얼 왜 만들려 했나?
(수단) 뭘로 만들었나? 왜 그걸로 만들었나? 뭐가 좋았나?
(경험) Rust를 왜 써봤나? 뭐가 좋던가?
(추천) AWS Lambda, EventBridge, SNS, DynamoDB 이용후기

원하는 결과물

몇 달 전부터, 온라인에서 뭔가 팔기 시작했습니다. 아쉽게도 비공개 API를 써야 하는지라 어떤 웹사이트인지를 말씀드리기는 조심스럽습니다. 아무튼, 어떤 웹사이트에서 판매 수익이 발생하면, 그 수익을 곧바로 알고 싶더군요. 가끔씩 해당 웹사이트에 들어가서 수익금 현황 페이지를 새로고침하다가, 내가 가서 확인하는 게 아니라, 발생할 때마다 내 휴대폰으로 알림이 왔으면 좋겠다는 생각이 든 거죠.

• 판매 이벤트가 발생하면 내 휴대폰으로 알림을 받아보자.

어떻게 알림을 받을까?

가만 째려보니, 아래와 같은 구조로 개발하면 되겠다는 그림이 나왔습니다.

큰 관점에서 보면 위 그림으로 구현하면 될 것 같았고, 세부적인 내용은 AWS에서 제공하는 서비스들의 특성을 활용해서 조정해 가며 개발하기로 마음먹었습니다.

AWS Lambda 함수

AWS 람다 서비스는, 어떤 이벤트에 발생할 때, 내가 등록해 놓은 함수를 실행할 수 있는데, 함수는 다양한 언어로 작성할 수 있습니다. 자바나 파이썬, 자바스크립트는 물론이고, 다양한 언어환경을 기본으로 지원합니다. 인스턴스를 미리 하루종일 실행하는 것이 아니라, 함수를 등록해 놓으면, 이벤트에 대응해 실행한 시간만큼만 과금되는 서비스입니다. EC2나 라이트세일 같은 서비스의 인스턴스는 아무리 작은 인스턴스를 띄워도 내내 띄워두면 개인 사이드프로젝트 입장에서는 적지 않은 비용이 발생하는 부담이 있습니다만, 람다 같은 경우 사실상 거의 비용이 발생하지 않는 매력이 있습니다.

Rust 프로그래밍 언어

최근 Rust프로그래밍 언어를 조금 공부했습니다. 고성능의 저수준 프로그래밍을 할 수 있으면서, 언어 자체는 매우 고수준이라서 마음에 쏙 들었습니다. 기회가 되면 적극 활용해보고 싶다는 생각이 들었는데, 이번이 기회다 싶었습니다.

이번에는 람다 함수를 Rust언어로 작성해 보기로 마음먹었습니다. 기존에는 Scala랑 TypeScript(node.js)로 만들어서 배포해 본 경험이 있어요.

새로운 언어 적용 기회

새로운 언어를 적용하려면 새로 익혀야 할 것도 많고 시간이 오래 걸리기 마련입니다. 언어만 새로 알면 되는 게 아니라, 그 언어에서 주로 쓰는 주요 프레임워크들을 같이 공부해야 하는 시간과 노력이 꽤 필요해서, 이미 익숙한 언어와 프레임워크를 쓰는 게 더 현명한 판단일 가능성이 높습니다.

하지만, Rust를 새로 공부하기로 마음먹었으니, 이 좋은 기회를 살려야겠죠. 다행히 Rust언어 같은 경우 AWS에서 꽤 공격적으로 지원해 주려는 것으로 추측됩니다. 무려 공식 SDK가 있어요. (아직 개발자 프리뷰 버전입니다만 그게 어딘가요?!)

이번에도, 사실은 너무 오랜 시간이 걸릴 것 같으면 중도에 포기하고 그냥 스칼라로 개발하려고 했습니다만, 하고자 하는 작업이 간단했던 데다, Rust로 진행해 보니 생각보다 진척이 빨라서 무리 없이 끝까지 마무리할 수 있었습니다.

Cargo Lambda

Rust는 기본으로 포함된 cargo라는 패키지 매니저를 쓰는데, 이 cargo라는 툴의 플러그인 중에 AWS Lambda 서비스를 개발하고 배포하는데 특화된 게 있습니다.

Cargo Lambda is a subcommand for Cargo, the Rust package manager, to work with AWS Lambda.

Cargo Lambda provides tools and workflows to help you get started building Rust functions for AWS Lambda from scratch. When you’re ready to put your work in production, Cargo Lambda helps you build and deploy your functions on AWS Lambda in an efficient manner.

— https://www.cargo-lambda.info/

별다른 고민 없이 해당 플러그인에 있는 커맨드로 로컬에서 테스트해 보고, 람다함수로 배포하기도 쉬웠습니다. 새로운 언어를 쓰더라도, 실무 환경에 있는 사람들이 많이 쓰기 시작하면 문제없이 적용할 수 있게 되는 것 같습니다. Rust는 그런 면에서 충분한 합격점인 상황입니다.

AWS SDK for Rust

아직, 개발자 프리뷰상태이니 프로덕션 환경에서 쓰지 말라는 경고가 붙어있기는 합니다만, 그래도 AWS에서 공식적으로 만들어준 SDK가 있습니다. 평소 마이너 언어를 종종 쓰는 입장이다 보니, 공식 SDK의 존재가 새삼 감사하게 느껴집니다. 덕분에 Rust 환경에서 편리하게 AWS서비스에 접근할 수 있었습니다.

AWS EventBridge

이번에 처음 알게 된 서비스인데, AWS EventBridge라는 서비스가 있습니다. 이 EventBridge 서비스 안에 Scheduler라는 기능이 들어있어서, 이 기능을 통해 특정 시점이나 반복주기에 맞게 이벤트를 발행할 수 있습니다.

람다 함수 (1) — 목표 API를 폴링해서 신규 판매실적을 파악하자

이번 시스템은 간단한 람다 함수 2개로 구성했습니다. 첫 번째 함수는, 실행되면 목적 API에 접근해 JSON데이터를 읽어서 그중 새로운 판매정보를 읽는 역할을 담당하게 했어요. 위에 소개한 EventBridge에 등록해 둔 스케줄에 따라서 이 람다함수를 실행하고, 이 람다함수는 새로운 판매실적 정보를 기록하고 알림을 보낼 수 있도록 했어요.

이 첫 번째 람다함수가 매 10분마다 목표 API를 조회해서, 새 판매실적에 대해서만 SNS 토픽에 메시지로 발행하는 역할을 담당했어요. Rust로 개발하는 작업이 처음이라 조금 시간이 걸렸지만, 그래도 생각보다는 금방 결과물이 나왔습니다. 이 함수 개발에만 하루 쓴 것 같네요.

신규 데이터 확인

조회하고자 하는 비공식 API는 최근순서로 N건의 판매건수를 조회할 수 있었습니다.

[
  {"amount": 10000, "at": "2023-08-11T02:30:00Z"},
  {"amount": 11000, "at": "2023-08-10T12:00:00Z"}
]

이런 식으로 판매 실적이 담겨있었는데, 아쉽게도 PK 값으로 추정되는 건 따로 보이지는 않았습니다. 아쉬운 대로 몇 가지 고유해 보이는 값들을 조합해서 해쉬값을 만들어서 임의의 PK값을 만들어서 쓰기로 했습니다. 해당 데이터를 AWS DynamoDB 테이블에 넣어두고, 나름의 방식으로 생성한 PK값을 기준으로 기존 데이터인지 신규 데이터인지 파악하도록 합니다. 이미 기록된 판매실적이라면 무시하면 되겠죠.

AWS DynamoDB

AWS DynamoDB는 AWS가 관리해 주는 NoSQL데이터베이스인데, 이런 간단한 서비스에 활용하기에 매우 좋은 것 같습니다. 본래 목적은 대규모 트래픽에 유연하게 대처하는 데이터베이스 서비스입니다. 접근량이나 데이터 규모에 맞게 과금되는 식이라, 이처럼 작은 서비스에서 조금의 데이터만 활용하게 되면, 사실상 비용이 발생하지 않아서 더욱 매력적입니다. 아무리 작은 RDB인스턴스라도 개인 수준에서 비용은 적지가 않은데, 성능도 빠르게 쓸 수 있어서 아주 좋습니다.

AWS SNS

AWS SNS 서비스는 메시지 버스로 활용할 수 있습니다. 이벤트 메시지를 발행하면, 해당 토픽을 구독하고 있는 대상들에게 메시지가 전달됩니다. 토픽을 구독하는 대상은 다양한 종류가 올 수 있는데, 저는 Email과 Lambda실행을 연결해 두었습니다. 새로운 판매실적데이터가 특정 SNS토픽에 전달되면, 그 토픽을 구독하고 있는 이메일 주소로 해당 데이터가 메일로 발송되고, 지정한 람다함수(2)도 실행하도록 설정했습니다.

두 번째 람다함수를 개발하는 과정에는 이메일로만 구독해서, 신규 판매실적이 메시지로 잘 발행되는지를 확인하며 진행했고, 람다함수(2)의 경우 제가 이용하는 슬랙 채널에 메시지를 발행하도록 했어요.

람다함수 (2) — 신규 판매 실적을 내 휴대폰으로 알리자

두 번째 람다 함수는 이미 만든 첫번째 람다 함수를 살짝 바꾸면 됐기 때문에 금방 만들었습니다. SNS Topic에 구독하는 항목 중에 Lambda 함수를 실행할 수 있는 항목이 기본으로 있고, 특정 람다함수를 실행하면서 SNS에 전달된 메시지를 전달할 수 있습니다. 그럼 Lambda함수 입장에서는 해당 메시지를 읽어서 원하는 처리를 할 수 있게 됩니다. 어떤 서비스를 이용해서 제 휴대폰으로 메시지를 보낼까 생각해 보니, 곧바로 떠오르는 것은 카카오톡과 슬랙이었습니다. 카톡으로 메시지를 받으면 편리하겠는데, 개발자 문서를 좀 뒤져보니, 좀 시간이 걸릴 것 같습니다. 일단 예전에 연결해 봤던 슬랙을 쓰기로 합니다.

슬랙도 워낙 많이 쓰는 서비스이니까, 잘 찾아보면 SNS 토픽 구독해서 슬랙 메시지로 발행해 주는 기능이나 누군가 이미 만들어 공개해 둔 Lambda함수를 가져다 쓸 수 있을 것 같았지만, 뭐 어려운 기능은 아니니까 애써 찾느니 그냥 만들기로 합니다.

첫번째 람다함수를 좀 손봐서, 슬랙 메시지 발행하는 람다함수로 만들었어요.

전체 구조

두 파트로 나눠서 그렸던 전체 구조를 다시 그리면 아래와 같습니다.

람다 함수로 기능을 잘게 쪼개서 작은 일들만 처리하게 한 점이 제게는 재밌었습니다.

결론 및 정리

서버리스 시스템 참 편리한 것 같습니다. 이미 있는 탄탄한 서비스들에 설정만 걸어서, 내가 원하는 작업을 하되, 요금 비용과 시간 비용을 모두 절약할 수 있는 환경이라고 생각합니다.

과거 근무한 환경에서는 카프카나 별도 MQ도 쓰고 했었지만, 요새는 클라우드 환경에 이미 잘 갖춰진 메시지 버스나 큐 시스템이 있기 때문에 별도로 고민할 필요 없이 잘 쓰기만 하면 되는 상황이라 편리합니다.

러스트로 람다 함수를 만들어서 쓰는 것은 종종 더 해볼 것 같습니다. 이 글을 정리하는 동안 슬랙 알림을 한 건 받았습니다. 어쩌다 한 건 받으니까 더 자주 알고 싶어서 이런 시스템을 만들어봤나 봅니다. 사실 판매량이 많으면, 하루에 한번 총 판매액만 보면 될 텐데 말이죠.

암튼, AWS 서버리스 환경을 아직 안써보신 분들께는 한번 써보시는 것도 좋겠다고 추천드리면서 글을 마치겠습니다.

감사합니다.

AWS에 서버리스 Rust로 수익 알리미 만든 이야기 was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.

프로 개발자

프로 운동선수를 생각하면, 그 기준이 상당히 까다롭겠습니다. 프로 리그에서 현역으로 뛰고 있는 선수여야 한다거나, 아니면 프로 선수 자격증을 취득해야 한다거나 하는 명확하고 높은 기준이 있겠죠.

하지만, 제가 삼고 있는 프로 개발자의 기준은 간단합니다. 개발을 하면서 월급, 그러니까 가계소득을 챙기고 있으면 그게 프로인 거죠. 프로의 마음가짐이나 실력을 따지기 시작하면 너무 모호해지기 쉽잖아요? 어차피 프로 개발자 리그가 있지 않은 이상, 필요 주 소득원이 해당 개발 일로 발생하면 그게 프로 개발자인 겁니다. 그저 월급을 받을 수 있는 직업 개발자이면 되는 거죠. 이 기준에 따르면 실력 좋은 학생이나 예비 개발자도 프로는 아닙니다. 역으로 실력이 없더라도, 월급을 잘 받고 있다면 프로인 거죠. 간단하죠?

프로 함수형 개발자

그런 기준에서 프로 함수형 프로그래머로서 업으로 함수형 프로그래밍을 하는 호사를 누린 지 꽤 됐습니다. 클로저와 스칼라에 이어서 하스켈까지 업무로 활용하는 팔자 좋은 생활을 했습니다.

어떤 분들은 제가 덕업일치를 이루어 살고 있다고 말해주기도 하지만, 결론부터 말하자면, 이 호화로운 사치를 계속하는 게 맞는가 하는 의문이 들기 시작했습니다. (이제야?)

프로 클로저 개발을 했던 회사는 해당 프로젝트를 자바로 전환하는 일을 고심(or 진행) 중이라 합니다. 프로 스칼라 개발을 했던 팀은, 해당 프로젝트를 타 팀으로 이관하지 못해서 유지보수의 책임을 지고 있다 합니다. 하스켈로 일하고 있는 현재 회사는 현재 진행형이지만, 제 개인적으로는 하스켈의 어려운 점을 하나 둘 인정하고 있는 단계입니다.

인프콘 2023 발표 예정

함수형 프로그래밍 언어로 대표 격인 세 가지 언어를, 직업적으로 해본 경험을 주제로, 올해 8월 인프콘 콘퍼런스에서 발표하기로 했습니다. 흔히, 콘퍼런스에서 발표하는 내용은 뭔가를 이렇게 이렇게 잘했다고 공유하는 것이 보통인 것 같은데, 아쉽게도 잘했다고 자랑하기는 어려울 것 같습니다.

그렇다고 실패담이라고 하기는 아쉬우니 경험담 수준에서 최대한 밝게 다뤄보려고 합니다. 재밌는 발표가 될 수 있기를 기대합니다.

스칼라 기초 강의 제작

며칠 전, “자바 개발자를 위한 스칼라”라는 온라인 강의 영상을 만들어서, 인프런에 등록했습니다. 검수과정이 잘 끝나면, 6월 초부터는 구매가 가능할 것 같습니다. 과연 몇 분이나 구매해서 들어주실지 모르겠지만, 아마도 구매수가 많지는 않을 것 같습니다. 강의의 가치 판단은 미뤄보더라도, 일단 “스칼라”에 대한 사람들의 관심이 많지 않을 테니 구매량에 대한 고민을 크게 할 수는 없을 것 같습니다.

수요는 많지 않겠지만, 그래도 관심 있는 주제에 대해 강의를 하나 다 만들 수 있어서 스스로 기특하다 칭찬하고 있습니다. 차차 더 유용한 강의를 만들 수 있는 계단 하나 쌓은 거죠.

다음 강의 주제를 고민하던 중…

강의 제작을 더 진지하게 도전해 보려고 이런저런 고민을 해봤습니다. 첫 강의가 아직 공개되기도 전입니다만, 곧바로 다음 강의를 만들 준비를 시작했습니다.

딱 떠오른 것은 “속성 기반 테스팅”이었고, 이를 주제로 스칼라, 자바, 자바스크립트 등에서 각 언어에서 널리 쓰이는 속성 기반 테스팅 라이브러리를 소개하고 쓰는 법을 공유하는 강의를 만들면 유용하겠다는 생각이 든 거죠.

그런데 잠깐! “속성 기반 테스팅”이라는 주제 자체가 너무 생소하다는 점에서 주춤하게 되었습니다. 사람들에게 관심 있는 주제를 강의로 만들어야, 수익성이 있을 테고, 제게 수익이 중요한 상황이니, 응당 “관심 있는 주제”를 공략해야 하겠습니다. “속성 기반 테스팅”이 수익성이 있을까요? 의외로 수익성이 있을 수도 있겠지만, 아마 기본은 저조한 수준일 겁니다.

내가 하고 싶은 강의가 곧 사람들에게 관심 있는 주제라면 좋겠지만, 그렇지 않다면, 수익성은 크게 고민하지 말고, 자아만족이나 사회공헌의 느낌으로 가져가야 하겠죠. 지금 제가 거창하게 사회공헌을 논할 상황이냐? 아쉽게도 그렇지 못한 것 같습니다. 경제적 독립을 이뤄냈고, 은퇴 비슷한 걸 한 상황이라면 모르겠지만 말입니다.

BETA vs. VHS 교훈

오래전에 비디오테이프라는 매체가 있던 시절에, 소니에서 베타라는 비디오테이프 규격을 내놓았고, 경쟁 규격으로 VHS라는 게 있었다 합니다. (어릴 때 저희 집에 베타 비디오 플레이어가 있었던 것 같지만, 그걸 얘기하면 제 나이가 너무 드러나므로, 일단 은근슬쩍 넘어갑시다)

암튼, 기술적으로는 VHS보다 베타가 여러모로 앞서있었다 합니다. 그런데 여러 기술 외적 이유로 인해, 베타는 시장에서 사라지고, VHS가 비디오테이프 시장을 주름잡게 됩니다. 비디오테이프 매체라는 기준에서, 기술 스펙이 우월한 것만으로는 시장에서 승리하는 데에 충분치 못했던 거죠.

함수형 프로그래밍이 기존 명령형 프로그래밍에 비해, 기술적으로나 학술적으로나 여러모로 우월하다고 봅니다. 이 의견 자체도 논란의 여지가 있을 테지만, 관대하게 봐줘서 사실이라고 쳐도 그 기술적 우월함이, 프로그래밍 패러다임 시장에서 의미 있게 팔리는 것과는 별개일 수 있다는 겁니다.

지금 시장에서 널리 쓰이는 패러다임은 파이썬, 자바, 자바스크립트 등 주류 언어가 자리 잡고 있는 명령형 프로그래밍입니다. 함수형 프로그래밍 패러다임은, 각 주류 언어들 안에서 제한적으로 조금씩 쓰이는 수준이 기본 현실이겠습니다.

함수형 프로그래밍은 BETA의 길을 갈까?

마음으로는 아니라고 믿고 싶지만, 현실적으로는 부인하기 어렵습니다. 하스켈, 클로저 같은 언어들은, 계속 비주류의 길을 가겠죠. 하스켈은 계속 학계에서나 쓰일 것 같고, 클로저는 아주 일부의 팔자 좋은 능력자들만 계속 쓰게 될 것 같습니다. 그마저도 해외에서나 가능할 테고요.

그리고, 한 가지 더 말씀드리자면, 그 커뮤니티 사람들은 소수가 이용하는 현실에 큰 불만이 없습니다. 오히려 너무 초심자들이 많아지면, 그 무게가 너무 무거워지기도 하거든요. 쓸 사람만 쓰는 현실을 받아들이는 것 같습니다.

아무튼, 함수형 프로그래밍 언어들에 있는 좋은 접근들이 다른 주류 언어에 긍정적 영향으로 전파되기야 하겠지만, 그 자체로 주류 언어가 된다? 그런 일은 없을 겁니다. 하스켈이 주류가 된다는 말은, 에스페란토가 만국 공용어가 될 거다라는 주장과 비슷한 수준이지 않을까 합니다.

그래도 BETA처럼 아예 없어지지는 않을 겁니다. 앞으로도 소수의 비주류로 지속되며, 주류 언어에 영향을 끼치며 나아가겠죠.

적자생존

최고의 유전자들이 살아남는 게 아니라, 환경에 적합한 유전자들이 살아남는 거고, 함수형 프로그래밍은 현재 직업 개발자 환경에서 적합하다고 보기는 어렵겠습니다.

분명 탄탄한 프로그램을 짜는 데 우월하지만, 현업 개발환경은 그렇게까지 어렵게 탄탄함을 추구하지는 않습니다. 당장 (누구나) 빠르게 만들어 내는 편리함을 추구하는 게 현업의 환경이죠. 코파일럿이나 GPT 등이 빠르게 안내해 주는 코드를 복붙 하는 시대인 상황에, 힘겹게 코드 정합성을 수식 증명하듯 꼼꼼하게 하고 있는 건 시대착오적인 행동인 것 같기도 합니다.

개인 프로젝트의 영역에서는…

아마도 개인 프로젝트의 영역에서는 계속 스칼라나, Elm 같은 함수형 프로그래밍 언어들을 더 쓸 것 같습니다. 혼자 만들어도 되는 범위에 있어서는 분명 훨씬 나은 점이 도드라진다는 믿음이 있습니다.

하지만, 여러 인원이 모여서 함께 일해야 하는 환경이라면, 함수형 프로그래머를 구하는 것 자체가 어려운 일이므로, 취미나 개인 프로젝트 사이, 좀 더 넓힌다면, 뜻 맞는 몇 명이 소규모로 모여서 작고 탄탄한 프로젝트를 진행할 때는 요긴하고 감사히 쓰기야 하겠죠.

그래서 함수형 프로그래밍 경험을 후회하는가?

아마, 저는 또 비슷한 선택을 할 수 있더라도 비슷한 과정을 거치게 될 것 같습니다. 한편으로는, 그 세 가지 함수형 프로그래밍 언어를 직업적으로 활용할 수 있었던 현실에 감사하고 있습니다. 뭔가 새로운 언어를 배울 때 흔한 걸림돌 중 하나가, “어디 써먹을 일이 없어서 잘 배우기가 어렵다”는 점인데, 전 실용의 영역에서 나름 실전적으로 배울 수 있었던 거죠.

마음 한 편에서는, 그저 취미나 학습, 그리고 기호의 영역에서 순수하게(?) 공부로 접근했으면 어땠을까 하는 생각을 하기도 합니다. 직업 개발은 남들 다 쓰는 주류로 하고 말이죠. 취미로 글을 쓴다거나, 강의를 만든다거나 하는 정도는, 개인 시간에 틈틈이 진행하면 좋을 것 같습니다.

아무리 좋은 기술이라고 해도, 동료들이 쓰지 않는다면, 그 의미가 급격히 줄어드니까 말이죠. 어쩌면 그렇게 좋은 기술이 아닐지도 모르고요.

마무리

그래서, 혹시 함수형 프로그래밍 언어에 관심이 많으신 분들께 응원의 말씀을 남긴다면, “계속 취미나 지적 호기심의 영역에서 학습하는 것”도 충분이 의미가 있다 말씀드려보겠습니다.

스스로도, 계속 공부와 실험의 영역, 개인 프로젝트에서의 실용은 계속해 나아갈 테고요.

hatemogi.com 개인홈

프로 함수형 프로그래머, 괜찮나? was originally published in HappyProgrammer on Medium, where people are continuing the conversation by highlighting and responding to this story.