데이터 과학자의 꿈

프로젝트 방향성

ooMia — Wed, 29 Apr 2026 16:07:27 +0900

2026 / 04 / 29

전기세만 내면서 내가 원하는 기능을 수행하는 코딩 에이전트

돈을 한 푼도 안 쓰는게 핵심 컨셉이다

최종 목표는 로컬에서 '무엇이든' 할 수 있는 시스템을 구축하는 것이다.

그 전과정을 함께할 코딩 에이전트가 있으면 좋을 것 같다고 생각했다.

매달 나가는 구독료가 아까운 것도 있지만, 크게 보면 데이터 주권이나 프라이버시와도 연관이 있다.

한국에서도 자체적으로 모델을 만들어내고 있는데, 이를 사용해보는 경험 자체로 의미가 있다고 생각했다.

자투리 시간을 이용한 솔로 빌딩으로 유의미한 결과물을 만들 수 있을지 자신은 없지만,

소프트웨어 엔지니어로서 필요한 역량들을 키울 수 있을 것 같아 기대 중이다.

틈틈이 시간을 내서 작업하고, 시행착오나 진전을 기록할 예정이다.

2026 / 04 / 30

로컬에서 inference를 수행하려면 GPU 파워와 많은 VRAM이 필요하다.

Apple silicon 프로세서로도 가능한데, 우선은 놀고 있는 GPU를 사용해보는 쪽으로 시도하려 한다.

Windows 11 (x64)

CPU 12th Gen Intel(R) Core(TM) i7-12650H(2.30 GHz)

RAM 32.0GB (4800 MT/s)

GPU NVIDIA RTX 4060 (Compute Capability 8.9)

VRAM 8GB (로 쓰고 6GB라 읽는다)

* GPU Compute Capability 7.5 이상 권장

** CUDA 12.9.x 권장 (inference 라이브러리 호환성)

ollama, vllm, Jan 순으로 엔진을 사용해보고 있다.

VS Code에 모델을 추가해서 코딩 에이전트로 사용하는 게 첫 목표!

하다보면 안정적으로 주어진 자원을 다 활용할 수 있음에 감사해진다

[클라우드 애플리케이션 아키텍처 패턴] 현대화된 소프트웨어

ooMia — Sun, 26 Apr 2026 21:01:50 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

클라우드 애플리케이션 아키텍처 패턴 / 카일 브라운, 바비 울프, 조셉 요더 저

배경

내가 웹 개발을 본격적으로 배우기 시작했을 무렵에는 이미 클라우드 기반의 워크플로가 표준이었다. 특정 플랫폼에서 자원을 할당받고, 터미널로 접속하여 웹 서버를 구동했다. 방화벽과 공유기 설정으로 로컬 서버를 개방하는 방법을 안 것은 그로부터 좀 시간이 지난 후였다. 생각해보면 클라우드 환경은 내게 '당연히 그래야만 하는 것' 정도로 받아들여졌던 것 같다. 그 이전과는 어떻게 다른지, 그래서 보다 클라우드 환경에 적합한 구조는 무엇인지 생각해본 적이 없었다. 다들 AWS 쓰니까, Docker 쓰니까, Kafka 쓰니까. 마이크로서비스나 이벤트 기반, 도메인 기반 아키텍처도 마찬가지다. 별 생각 없이 막연히 좋아보인다고만 생각했던 것 같다.

첫 인상: 친절하다

다루는 내용을 논하기 전에, 일단 기본적으로 이 책은 친절하다. 해결책을 패턴화해서 잘 정리해둔 것도 그렇고, 또 각 패턴에 대한 설명에 도식을 활용하여 구조적으로 이해하기 좋았다. 책, 논문 등을 통해 이미 유명한 내용들을 잘 정리했고, 그에 대한 인용이나 링크도 많아 깊게 파고들기 좋았다. 패턴으로 구성된 책들은 대게 사이 연결성이 부족해서 순서대로 읽는 것이 의미가 없는 경우도 있는데, 이 책은 일종의 기초-응용-심화의 느낌으로 각 장을 진행해서 책장을 차례대로 넘길 때 얻는 것이 더 많았다.

각 장 처음에는 포함된 패턴들을 구조적으로 설명하는 도식이 있다

이 책은 제품 중립적인 입장을 고수해서, 이렇게 제품명이 나오면 어김없이 링크가 붙는다.

내용: 설계 교과서

'설계 교과서'라고 표현한 이유는, 이 책이 개발이 아닌 설계에 집중하고, 저자의 개인적인 노하우보다 업계 전반에 잘 알려진 유명한 내용을 잘 종합했기 때문이다. 보통 주제를 넓게 커버하는 책들은 난해한 내용에 대해 설명이 빈약한 경우가 있는데, 적어도 나는 그런 느낌은 받지 못했다. 가령, 도메인과 관련한 내용은 보통 책 한 권의 분량으로 다룬다. 그 한 권에서도 대부분 자신의 도메인에 대한 직접적인 사례는 얻지 못하는데, 때문에 난 읽고 직접 자신의 경우에 활용할 수 있을 정도의 충분한 설명이 있는가를 중요하게 봤다. 그리고 이 책은 내 기준에는 합격했다.

단일 애플리케이션과 전체 소프트웨어의 개발: 이 책에서는 하이라이트된 주제에 집중한다

각 장에서 상세하게 설명한 내용들은 장 마지막에 도식으로 요약한다

반드시 알아야 하는 내용들로 꾹꾹 담은 이 책은 입문자부터 중급자까지 실무를 위해 직접 활용할 수 있는 수준의 풍부한 설명을 제공한다. 그러나 기본적으로 신선한 내용과는 거리가 있다는 것을 알아둘 필요가 있다. (물론 흐름을 놓친 누군가에게는 새로운 것들이겠지만) 적어도 나는 이 책을 읽으면서 IDEALS라는 개념은 새롭게 알게 되었다. 이는 객체 지향 원칙의 SOLID와 유사한 느낌으로, 2020년 발표된 마이크로서비스 설계 원칙이고, 이 책의 전반에 걸쳐 언급되는 유용한 개념이다.

마이크로서비스 설계 원칙 IDEALS

Principles for Microservice Design: Think IDEALS, Rather than SOLID

For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single resp

www.infoq.com

후기: 현대화가 낯설다면

'현대화'라는 단어. 막상 사용하고보니 좀 폭력적인 것 같다. 이러한 흐름에 동참하지 않으면 구닥다리 뒷방 노인네처럼 도태되어 버리는 건 아닌가 싶은 상상이 든다. 그러나 사실 책을 읽어보면 이 책은 변화를 절대 강제하지 않는다. 전통적인 구조부터 현대의 구조까지, 모든 것에는 주어진 환경에서 최선을 다한 이들의 서사가 녹아있다. 저자는 서로 다른 방법론 간에 우열을 가리지 않고, 진지하게 마주하며 장단점을 논한다. 전통적 구조의 서비스를 현대적으로 개편하기 위한 방법을 2개의 장에 걸쳐 제시하니, 우리 엔지니어들은 각자의 상황에 맞게 결정하면 된다. 필요하면 가져다 쓰는 것, 그 뿐이다.

70여개의 설계 패턴을 보며 느낀 것은, 객체 지향 언어의 디자인 패턴과 유사하게, 결국 정의된 역할을 어떻게 추상화하냐가 관건인 것 같다. 다만, 개발보다 설계 수준에서의 변경은 비용이 비싸다는 점이 차이인 것 같고, 때문에 이렇게 정형화된 방식을 익혀놓는 것이 더 의미있게 다가왔다. 클라우드가 바꾼 생태계의 모습이 낯선 이들에게 이 책은 앞으로의 개발 방향성을 올바르게 잡아나가는 데 큰 도움이 될 것이라 생각한다.

책 보러 가기

클라우드 애플리케이션 아키텍처 패턴

이 책은 IBM 펠로를 포함한 수십 년 경력의 아키텍처 전문가들이 정립한 70여 개의 패턴을 통해 클라우드 환경에 최적화된 애플리케이션을 설계하고 구축하는 방법을 소개한다.

www.hanbit.co.kr

[이것이 Spring AI다] Spring, 백엔드 프레임워크 아니었어?

ooMia — Mon, 30 Mar 2026 13:52:32 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

이것이 Spring AI다 / 신용권 저

배경

나는 2025년도부터 개발자들 사이에서 Spring AI에 대한 관심도가 부쩍 높아진 것을 체감했다. 아무것도 모르는 상태에서 처음 든 생각은 '파이썬이 AI 생태계를 주도하는 상황에서 Spring이 여기까지 넘본다고?' 였다. 찾아보니 대부분 개발된 모델/에이전트를 서비스 내로 포팅하는 느낌의 기능들을 가지고 있었고, 그제서야 그들의 선택을 이해할 수 있었다. 그렇게 다소 막연하게만 알고 있던 상황이었는데, 이번에 책을 받아 읽을 기회가 생겨 잠깐 훑어보니 생각보다 더 많은 기능을 지원하고 있었다.

들어가기 앞서, 내가 이해한 Spring AI의 역할을 Python을 활용한 모델 개선과 구분지어 비유를 통해 설명해보고자 한다. AI를 활용하는 단계를 크게 세 단계로 나누어 비유하면 ①수능 N등급의 학생에게 ②실무를 가르치고 ③성과를 내도록 만드는 과정이라고 생각한다. Python에서의 모델링은 더 높은 수능 등급을 가진 학생 ─ 기초 역량이 더 높은 주체로 만드는 것이다. 그러나 그래봤자 수능이고, 고졸로 취직하든 대학에서 전공을 가지든 필요한 지식을 주입해야 실무자가 될 수 있다. 또 필요한 지식을 가지고 있어도, 업무의 목표나 고객의 요구사항이 분명하지 않으면 원하는 결과물을 얻지 못한다. 이러한 맥락에서 Python은 1번과 2번, Spring은 2번과 3번 과정에 집중한다. hugging face, llama 등 오픈 소스로 모델을 활용할 수 있는 길이 열려있는 상황이 앞으로도 지속된다면, Spring AI를 잘 활용하는 것만으로도 충분히 좋은 결과를 만들어낼 수 있으리라 생각한다.

전체 아키텍처

AI 응용 서비스의 아키텍처

이 책에서는 AI를 사용하는 서비스의 개략적인 구조를 제시하는데, Web Application 계층을 포함한 중간 계층의 상호작용 양상이 복잡해지는 것을 볼 수 있다. 이러한 경향성은 여기서 내부/외부 도구라고 명명되었지만, 넓게 보면 많은 수의 마이크로서비스가 필수적인 환경으로 변화하고 있다는 느낌을 받았다. 일부 도구들은 필요에 따라 자체적으로 만들어 사용되지만, 대부분의 경우에는 벤더에서 제공하는 것을 가져다쓰고, 이런 저런 상황들을 고려하다보면 결국 웹 통신 계층에서 통합하는 것이 가장 깔끔하기 때문일지도 모른다. 더불어 소규모의 목적 지향적인 도구 또는 에이전트들을 조합하는 것이, 하나의 큰 에이전트를 학습시키는 것보다 더 효율적이라는 측면도 있을 것이다. 이러한 생각의 흐름에 따라 Spring AI에서는 이러한 흐름을 어떻게 통합하고 있을지 궁금해졌다.

Chapter 11. 도구 호출

Spring AI 도구 호출 흐름

특별한 기능이 있는 건 아니다. 프레임워크로서 쉽고 빠르게 시작할 수 있는 구조를 제공하는 것은 예외 없이 Spring AI에서도 이어진다. `@Tool` 어노테이션은 메서드를 도구로 정의하고, `@ToolParam` 어노테이션은 그 도구를 사용하기 위한 파라미터, ToolContext는 Map 타입의 객체로 민감한 데이터 등 추가 데이터를 실어보내기 위해 인자로 활용한다. 경우에 따라서는 5번 과정을 거치지 않고, 바로 6번으로 향하도록 호출 흐름을 수정할 수도 있다.

Chapter 12. MCP, 외부 도구

지금까지 다룬 내용은 내부 도구 - 우리가 코드 수준에서 직접 정의한 도구에 대한 것이었다. 따라서, 외부라고 하면 벤더 사에서 제공하거나 오픈소스로 공개된 MCP 서버를 의미하는 것이 일반적이다. 이것도 본질적으로는 내부 도구와 큰 차이가 없다. 기존의 아키텍처의 관점으로 보았을 때에는 특별한 업무를 담당하는 마이크로서비스 중 하나일 뿐이다. 물론 내부 도구와 비교하면 통신 방식과 규모에 있어 차이가 생긴다. 크게 표준 입출력(STDIO) 방식과 SSE 방식으로 나뉘는데, 현재 운영중인 서비스의 성숙도 또는 의존 MCP 서버의 규모에 따라 자연스럽게 전자에서 후자로 넘어가는 것을 고려해보면 좋을 것 같다.

새롭게 생겨난 개념에 대해 이미지를 활용하여 비유적으로 설명하는 내용들이 있다.

Chapter 13. 에이전트 개발

이 책의 내용에 의하면 에이전트를 크게 3가지 - 사용자의 지시(Prompt), 에이전트의 기억 및 맥락(Advisor), 그리고 활용 가능한 도구(Tool)로 분해하여 보고 있다. 앞서 개요에서도 명시했듯이, Spring AI는 주어진 모델을 잘 튜닝하는 것에 초점을 두고 있다. 따라서, 여기서의 `개발`은 각 에이전트에게 부여된 목표를 위해 사전에 지시를 내리고, 에이전트가 그 지시를 잘 기억하는지, 그리고 맥락에 따라 적절한 도구를 활용할 수 있는지가 성능 평가 지표가 될 것이다.

이러한 작업을 흔히 `프롬프트 엔지니어링`이라 부르는데, AI의 활용도가 점차 성숙해짐에 따라 성능을 얻기 위한 전형적인 방법들이 많이 연구되었으나, 하나의 에이전트로는 원하는 결과를 안정적으로 얻는 것이 어려운 것이 현실이다. 애초에 자연어가 규약만을 서술하기 위해 고안된 것도 아니고, 심지어 우리의 요구사항 자체도 자연어로 쓰여질 때 의미가 모호해지기 때문이다. 또한 아무리 엄밀하게 지시한다고 한들, 결국 에이전트가 기억해야 하는 맥락은 요구사항이 추가됨에 따라 지수적으로 상승할 것이며, 그에 따라 응답 속도나 컴퓨팅 자원에서 손해를 보게 될테니, 그냥 일찌감치 싱글 에이전트의 한계를 인지하는 편이 낫다.

에이전트 개요

Chapter 14. 멀티 에이전트로 협업하기

개인적으로 AI를 활용한 서비스를 고안할 때 가장 재미있는 부분이 아닌가 싶다. 오케스트레이터를 활용해서 다양한 에이전트 간의 상호작용을 거치며 응답을 생성하는 과정이다. 개인적으로는 멀티 에이전트를 잘 사용하려면 응답은 잘 분해하고 출력은 적절히 제한시켜야 하며, 응답을 생성하는 것보다 잘 평가하다고 생각하는 입장이다. LLM은 태생적으로 할루시네이션을 발생시킬 수 밖에 없는데, UX의 관점에서 이런 무가치한 답변을 그대로 내보내는 순간 고객의 신뢰도가 급감할 것이기 때문이다. 물론 서비스의 성격에 따라 예능적인 요소를 갖는 경우에는 이러한 부담이 덜하겠지만, '이 답변 잘못된 거 아니야?'라는 의심이 커지다보면, 고객 입장에서는 서비스 이용의 피로도가 자연스레 높아질 수 밖에 없다.

예를 들어, 지도 앱에서 '이 근처에 맛집은 어디야?'라고 물어본다면 에이전트는 일차적으로 이 질문이 단순 장소 검색이 아니라는 것을 인지해야 한다. 다음에는 `근처`, `맛집`이라는 키워드에 착안하여 이를 '반경 1km 이내 맛집 위치'로 바꿀 수 있어야 한다. 다음에는 그 질문을 사용자의 현재 위치 파악, 지리적 정보 기반으로 설계된 데이터베이스에 음식점 질의, 맛집 별점 및 후기 정보 평가로 작업을 분해할 수 있어야 한다. 마지막 단계에서 `맛집`이라는 매우 주관적인 키워드를 어떻게 해석할 지가 관건이 되며, 보통 이러한 하나의 관심사가 하나의 MCP 서버로서 관리된다. 리뷰 신뢰도를 AI로 평가하여 필터링하고 맛집은 단순히 별점 순으로 정의한다든지, 또는 고객을 프로파일링하고 유사도 기반 추천 알고리즘을 활용하는 등의 다양한 방법이 가능하다.

하지만 앞서 `평가`를 강조한 것처럼, 피드백 루프가 없는 AI 앱은 실속없는 수다쟁이가 되버리기 쉽다. 가장 좋은 것은 짧은 피드백 루프 - 즉, 검색 즉시 고객에게 피드백을 받는 것이지만, 사용자를 피곤하게 만든다는 점에서 바람직하지만은 않다. 결국 그 사람이 실제로 방문하기 위해 길찾기를 했는지, 지리적 정보로 실제 이동했는지, 다음에 또 검색을 했는지 등의 정보를 토대로 이전 에이전트의 응답이 적절했는지에 대한 사후 평가도 필요하다는 생각이다. 그리고 평가가 되었더라도 출력이 장황하면, 이것을 다음의 개선된 응답을 위한 데이터로 활용하기가 어렵다. 따라서, 응답에 사용된 하위 에이전트들의 응답을 제한시켜 표준화된 파라미터 A, B, C로 정의하고, 그에 대한 평가 D를 기록해두는 식의 방향성을 갖고 다음에는 더 나은 응답이 나올 수 있는 루프를 설계할 필요가 있다고 생각한다.

책에서는 멀티 에이전트와 관련된 내용들을 간단히 소개한다

후기: 새로운 시대

Spring은 현재 정부 표준이라는 점에서 대한민국 웹 개발 시장에서 경쟁력이 있는 프레임워크이다. 23년도부터는 기존 7급만 뽑던 전산 데이터직이 9급 공무원까지 확장되었으며, 이러한 경향에 따라 향후 Spring AI가 국가 표준으로 자리잡을 수도 있다. 사용자 친화적이라는 관점에서 LLM은 앞으로 고객과 맞닿은 영역에서 필수 불가결한 존재가 될 것이며, 모든 B2C 사업에 고부가가치를 창출하기 위한 핵심 아이템으로 자리잡을 것이다. Spring AI는 앞으로 더 널리 활용될 것이라 생각하며, 이러한 관점에서 책이 제공해주는 소스 코드를 기반으로 컨셉과 실제 활용 사례를 빠르게 확인해볼 수 있어 새롭게 접하는 이들을 위한 좋은 시작점이 되겠다고 느꼈다.

전자정부 표준프레임워크

책 보러 가기

https://www.hanbit.co.kr/store/books/look.php?p_code=B8856838821

www.hanbit.co.kr

[데이터 엔지니어링 디자인 패턴] 경량 ETL 실습 후기

ooMia — Tue, 3 Mar 2026 05:42:46 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

데이터 엔지니어링 디자인 패턴 / 바르토시 코니에치니 저

배경

데이터 기반의 프로젝트를 수행할 때, 보통은 이미 정제된 데이터를 잘 활용하는 것에 집중하는 경우가 많다. 데이터 수집 및 관리 영역은 마치 도시의 인프라처럼, 초기에 제대로 구축해두면 이후에는 유지/보수만 해주면 되기 때문이다. 그러나 인프라에 대한 신뢰가 깨지는 것만큼 치명적인 사건도 드물다. 이미 모든 작업들이 그 신뢰를 바탕으로 진행되어 왔다면, 최초로 발견한 데이터 품질의 문제가 어디에 또 어디에 도사리고 있을지는 아무도 알 수 없기 때문이다. 이러한 데이터 통합을 경험해보고자 직접 간단한 ETL 프로세스를 구현해봤다. 책에서 제시하는 대표 사례는 꽤 복잡하게 느껴졌기에 다소 단순화하여 접근했다.

문제: 증분 적재

내 경우 크롤링을 수행해서 필요한 데이터를 수집하는 경우가 많다. 주기적으로 작업을 수행할 때, 애초부터 중복이 발생하지 않도록 설계하지만, 작업이 실패하고 재실행하면서 불필요하게 데이터 중복이 발생하기도 한다. 이런 상황을 생각해서 안정성을 추구하다보니 작업 속도는 느려지는 것을 감수하곤 하는데, 그러다보니 각 작업이 실패했을 때는 전체 적재를 수행하기에 너무 시간이 오래 걸리는 문제가 있었다. 이러한 문제를 해결하기 위해 4개의 패턴 — 체크포인터, 증분 로더, 키 기반 멱등성, 수평 파티셔너를 활용하여 단순한 ETL 프로세스를 구현해보았다.

이 책의 패턴을 활용한 인프라의 개략적인 구조

기초 개념: ETL

ETL—meaning extract, transform, load—is a data integration process that combines, cleans and organizes data from multiple sources into a single, consistent data set for storage in a data warehouse, data lake or other target system. —IBM Data Management Guide

ETL은 다양한 원천에서 수집한 데이터를 하나의 온전한 데이터셋으로 통합하는 프로세스를 의미한다. 쉽게 말하면 API에서 DB에 데이터를 적재하는 과정이다. 이는 굉장히 기초적인 개념이지만, 본 책에서는 다루지 않는다. 대신 실무적인 관점에서 데이터 관리를 위한 다양한 디자인 패턴을 제공하는 것에 집중한다. 책은 일반적인 데이터 엔지니어링 라이프사이클의 관점에서 필요한 작업의 순서대로 패턴을 정리해주고 있다. 또한 부록으로 패턴 요약을 제공하여 한 눈에 모든 패턴을 살펴볼 수 있도록 제공한다. 이 책으로 모든 것을 해결할 수 없고, 필요한 개념이 있다면 따로 찾아 학습해야 했다.

책에서 제공하는 전체 디자인 패턴 요약

내결함성 - 체크포인터

체크포인터의 핵심 역할은 이전 데이터의 재처리를 피하는 것이다. 이번 실습에서는 크롤링 대신 공공데이터 API의 대기오염 데이터를 사용했는데, 측정소별 데이터가 매시간별로 수집되는 것을 확인했다. 그래서 시간을 기준으로 레코드를 구분했고, 물론 이런 방식은 책에서 제시하는 실무적인 방식은 아니지만, 임의롭게 단순한 JSON 파일 하나를 생성해서 어디까지 처리되었는지 기록했다.

파이프라인 실행에 성공하면 그 시간이 기록된다.

증분 적재 - 증분 로더

책에서 두 가지 구현 방식을 소개하고 있어 이를 모두 활용하려 했다. 들어오는 데이터가 각 시간별로 이미 나누어져 있어 `last_fetched_at` 를 활용하여 델타 컬럼 방식으로 수집 방식을 정의했고, 시간 분할 데이터셋 방식을 활용해서 날짜 파티션별 parquet으로 저장했다. 실습의 목적으로 두 방식 모두 활용한 것이지만, 두 방식 중 하나만 적용하는 것도 충분해보였다. 이 과정에서 자연스럽게 수평 파티셔너 패턴도 사용하게 되었다.

시간 분할된 데이터셋과 조회한 내부 레코드

데이터베이스 - 키 기반 멱등성

관측소명을 뜻하는 `stationName`, 그리고 관측 시간인 `dataTime`. 두 개의 속성을 복합키로 삼아 멱등성을 보장했다. 물론 이용하는 API 데이터셋의 특성상 과거 데이터가 수정되는 경우는 없으므로 불필요한 작업이다. 또한 제약조건을 걸어두고 데이터베이스를 사용하여 처리할 수도 있었지만, 활용해보는 것에 의의를 두고 작업을 진행했다.

transformer.py > deduplicate()

깨달음: 문제와 해결책, 그리고 패턴

이러한 작업을 특별한 기술 스택 없이 진행하면서 느낀 점은, 워크로드를 최대한 단순하게 유지하는 것이 가장 중요하다는 점이다. KISS 원칙처럼 요구사항을 단순하게 이해하고 빠르게 처리해야 한다. 왜냐하면 처음부터 다른 회사에서 사용하는 멋진 인프라를 구축하는 것은 다른 중요한 작업에 투자할 시간을 뺏고, 자칫하면 데이터셋에 대해 잘못 이해하거나 스키마가 변경되면서 기존 작업이 시간 낭비가 될수도 있기 때문이다.

그 다음 단계는 추가되는 요구사항에 따라 발생하는 문제를 식별하고, 그것에 대한 해결책을 패턴 기반으로 숙지하는 것이다. 대부분의 문제는 본 책에 명시된 패턴들을 활용하여 해결할 수 있다. 사용하는 기술 스택의 스펙을 이해하고, 적절한 수준에서 패턴을 구현하는 것만 신경쓰면 될 것 같다. 가령, 어떤 작업 요청이 정상적으로 수행되었는지 확인하기 위해 오류 관리를 논하는 3장의 체크포인트 패턴을 활용할 수도 있지만, 넓게는 데이터 품질을 논하는 9장의 AWAP 패턴 — 감사-쓰기-감사-배포 패턴을 활용하여 데이터셋 자체의 정합성을 보장하는 것으로도 문제를 해결할 수 있는 것이다.

이 책은 다양한 패턴을 수록하여 자신이 마주한 문제 상황에 대한 해결책과 그에 맞는 패턴을 찾을 수 있는 것이 가장 큰 장점이다. 아쉽다면 초보자에겐 그 패턴이 필요한가를 판단하는 것이 어려울 수 있고, 설명 수준이나 사례로 사용되는 기술 이해도 등이 중급자를 대상으로 작성되어 있다는 점이다. 바꿔 말하면 이 책의 내용은 정말 실무 메뉴얼로 사용해도 좋을만큼 실전적이다. 어느 정도의 실무 경험이 있는 데이터 엔지니어들에게 이 책을 추천한다.

[서평] 스프링 부트 개발자 온보딩 가이드

ooMia — Tue, 23 Dec 2025 10:25:42 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

스프링 부트 개발자 온보딩 가이드 / 박상현 지음 / 한빛미디어

개인 실습

예제 코드를 살펴보는데 좀 오래된 느낌을 받았다. 그래서 최신 환경으로 마이그레이션하고 린트 경고를 해결해봤다. 처음에는 하나만 하려고 했는데, 이 하위 프로젝트들은 서로 연결성이 있어서 어쩌다보니 다 하게 됐다. 좀 더 Best Practice에 가까웠으면 하는 마음에 익숙하지 않은 configTree, Docker secret 등의 기능을 사용하다보니 컨테이너화에서 잠깐 헤맸지만 모두 무사히 완료했다. 현재는 최소한의 수정만 진행했는데, Spring 7.0 환경에서 달라지는 부분들을 참고하여 추가 리팩토링을 진행할 예정이다.

GitHub - ooMia/spring-template: 책 '스프링 부트 개발자 온보딩 가이드'에서 제공하는 예제 프로젝트를

책 '스프링 부트 개발자 온보딩 가이드'에서 제공하는 예제 프로젝트를 개선한 템플릿 프로젝트 - ooMia/spring-template

github.com

1️⃣ 환경 설정

새로운 언어를 접했을 때의 기억들을 떠올려보면 프로그래밍보다 그걸 준비하는 과정에서 겪는 어려움이 더 컸다. 자주 접할 기회가 없어 익숙하지 않은 것도 있지만, 가령 시스템 경로와 관련되어 문제가 발생한다고 하면, 개인의 설정이란 결국 정답이 없는 영역이니까. 이런 건 검색해서 누군가의 설정을 똑같이 따라한다고 문제가 해결되리라는 보장도 없다. 그래서 이 책은 개발 환경을 구축하는 방법을 설명하는 것에서 시작한다. 가장 보급률이 높은 OS인 Windows 환경에서, 가장 개발 친화적인 Linux 환경에서 작업하기 위해 WSL2를 활용한다. Docker와 IntelliJ, SDKMAN을 포함하여 최대한 실무에 가까운 환경을 구축한다.

개발 환경 온보딩

2️⃣ 단계적인 확장과 코드 재사용

일반적으로 배움은 아는 것과 모르는 것을 구분하는 것에서부터 시작한다. 그리고 어떤 언어나 라이브러리, 프레임워크를 처음 사용하면 보통 아는 것보다 모르는 게 더 많다. 그래서 처음부터 너무 복잡한 프로젝트를 진행하면, 문제가 발생했을 때 원인을 식별하는 작업에 어려움을 느끼게 된다. 그래서 이전의 코드 베이스를 그대로 가져와, 내가 아는 것에서 모르는 것을 추가해나가는 구성은 초보자 친화적이다.

단계적으로 확장해나가는 방식은 실제 개발 플로우와도 연관성이 있다. 빠르게 핵심 기능을 완성하고 별도의 계층을 추가하거나 통신 방식을 변경하는 등 요구사항이 변화함에 따라 어떻게 대처해야 하는지에 대한 모습을 확인할 수 있다. 또한 목표로 하는 기능을 추가하면서 필연적으로 기존 코드의 수정/삭제가 이루어진다. 이러한 변화에 직접적인 수정이 필요한 경우 사진처럼 강조 표시를 해두었고, 단순 수정 외에도 API versioning과 deprecated 표시 등 타인과의 협업까지 고려한 것을 보며 실무를 반영하기 위해 노력했다는 인상을 받았다.

3️⃣ 친절한 설명

고민 상담소 섹션과 도식을 활용한 구조 및 순서 설명

사용하는 기술의 원리를 알아도, 어떻게 프로그래밍을 해야하는지 모르거나 프레임워크 내에서 어떻게 지원하는지 모르면 헤맬 수 밖에 없다. 이러한 관점에서 이 책은 다양한 관점과 방식으로 설명을 제공한다. 고민 상담소 섹션을 통해 향후의 고도화를 위한 실무적인 조언을 얻을 수 있고, 도식을 통해 프로젝트의 구조와 동작 순서에 대한 정보를 얻을 수 있다. 또한 예제 코드를 통해 모든 단계를 직접 수행하지 않더라도 빠르게 시작할 수 있다. 설명 주석 또한 풍성하게 제공되며, 최초에 저자가 밝힌 집필 의도처럼, 이를 통해 업무에 빠르게 적응할 수 있다.

GitHub - sean-lab/eog-springboot3-public: Engineer Onboarding Guide SpringBoot3 Sample Code

Engineer Onboarding Guide SpringBoot3 Sample Code. Contribute to sean-lab/eog-springboot3-public development by creating an account on GitHub.

github.com

이 책의 특징

‍♂️ 구현에 집중

Why는 짧고 How가 길다. 빠르게 적용하고 적응하기 위한 성격의 책이다. 기능을 구현하는 방법은 다양하지만, 일단 그 중 하나를 선택해서 그 원리와 어떻게 구현하는지 설명하는 것에 집중한다. 처음 시작하는 이들에게는 고민 없이 따라할 수 있는 시작점이지만, '그래서 내 프로젝트에 맞는 방식이 무엇인지' 고민하는 이들에게는 충분한 인사이트를 제공하지 않는다.

⚠️ 예제는 예제일 뿐이다

예제라고 실무 환경을 그대로 다 가져오면 어렵고 복잡해질 수 밖에 없다. 제공된 코드는 실무적인 느낌을 참고하는 용도로만 사용하고, 온보딩 이후에는 공식 문서 등을 살펴보며 스스로 고도화하는 능력을 갖추어야 한다.

마치며...

25년도 마지막 책은 내게 꽤나 많은 인사이트를 제공해주었다. 이를 통해 앞으로의 개발자 활동에 필요한 산출물을 만들어 볼 수 있겠다는 생각이 든다. 또 서평단 활동도 의미있게 다가온다. 깊게 정독하진 못하더라도 한 달에 한 권 책을 읽는 것이 어떻게 개인의 지평을 확장시켜주는지 체감할 수 있던 한 해였다.

[서평] 0과 1 사이 (원제: Binary Hacks Rebooted)

ooMia — Thu, 27 Nov 2025 07:12:08 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

0과 1 사이 / 가와타 아키라, 고이케 유키, 와타나베 게이치, 사에키 다카야, 아라타 미즈키 외 1명 지음 / 한빛미디어

개인 실습

이 책을 직접 실습해보지 않고 평가하는 건 저자들에 대한 예의가 아니라 생각했다.

책 일부를 정독하고, 4장 37절 리눅스 네임스페이스에 대한 내용을 실습해보며 느낀 점들을 서평으로 남겼다.

Binary Hacks Rebooted - 4.37 리눅스 네임스페이스로 프로세스 분리하기

Binary Hacks Rebooted - 4.37 리눅스 네임스페이스로 프로세스 분리하기 - README.md

gist.github.com

마크다운으로 남긴 실습 기록

1️⃣ 저수준 프로그래밍 기술

임베디드 개발자들은 어셈블리 수준에서의 조작을 해봤을 것이고, C언어를 사용해봤다면 라이브러리를 타고 들어가다 시스템 콜과 연관된 코드를 본 경험이 있을 것이다. 리눅스 자격증을 취득한 사람들이라면 OS, 커널, 파일, 프로세스 등 컴퓨터 구조와 명령어 사이의 관계에 익숙할 것이다. 보안 전공자라면 이진 파일을 다양한 방식으로 해석할 수 있다는 사실과 도구를 활용해서 디버깅/시뮬레이션을 할 수 있다는 것을 알테고, 애플리케이션 개발자들은 컨테이너와 하이퍼바이저를 이용한 오케스트레이션에 친숙할 것이다. 놀랍게도 앞서 말한 내용들 모두 이 책에서 언급되는 내용이다. 즉, 당신이 무엇을 상상하든 이 책은 그 이상을 다루고 있으리라.

실습을 진행한 4장 컨테이너 Hack 내용 일부

2️⃣ 현대 환경에 필요한 Hack

지금껏 역사는 추상화 계층을 쌓아올라가며 멋진 것을 더 쉽게 만들 수 있도록 발전해왔다. Rust와 WASM, 컨테이너화와 Unikernel 등 너무나 멋진 기술들이 문제 해결을 위해 등장했다. 이 책은 그러한 변혁을 고려하여 저수준 프로그래밍 기술을 현대 시스템의 구조적 변화와 필요에 맞춰 폭넓게 다루고 있다. 하드웨어의 연산 효율이나 컴퓨터 구조와 같은 본질은 쉽게 변하지 않지만, 그 본질이 중요해지는 맥락이 바뀌었다는 사실을 책을 읽으며 느낄 수 있었다.

이번에 알게된 Unikernel도 정말 참신한 아이디어라 생각한다. 기존에 alpine 버전이나 Dockerfile을 활용하여 간소화한 빌드를 만드는 차원이 아니라, 애플리케이션에 필요한 기능만 탑재하여 커널 수준에 최적화하는 방식이다. 빌드 크기 감소와 성능 개선은 당연하고, 공격 표면을 감소시켜 보안을 향상시킬 수 있다는 점이 핵심이라 생각한다. 이로서 특정한 이미지에 취약점이 발견되더라도, 향후에는 해당 기능이 의존하는 시스템 콜을 포함하는 기능을 이미지에서 제외하고 빌드하는 식으로 실시간 패치가 가능해질지도 모른다.

Unikernel: 등장 배경과 의의

3️⃣ 차근차근 따라할 수 있는 구성

솔직히 평소에 저수준으로 프로그래밍 할 일이 없어서, 이 책에 있는 내용 대부분은 잘 모른다. 하지만 이 책은 앞서 다룬 내용을 바탕으로 뒤의 내용을 설명하기 때문에, 처음부터 순차적으로 읽으면서 차근차근 이해를 쌓아나가기 좋게 구성되었다. 실습에 필요한 소스 코드도 레포에 정리되어있고, 시뮬레이션에 필요한 명령어 실행 방식과 결과도 중요하고 필요한 부분만 간결하게 표현해두어 읽기 편했다.

GitHub - chinium/binary-hacks-rebooted: 『Binary Hacks Rebooted』のサポートリポジトリ

『Binary Hacks Rebooted』のサポートリポジトリ. Contribute to chinium/binary-hacks-rebooted development by creating an account on GitHub.

github.com

이 책의 특징

⚠️ GNU/Linux OS에 집중한다

이 책은 대부분 GNU/linux를 기반으로 서술되어 있다. 그래서 Windows는 WSL 또는 Docker나 Podman 같은 가상화 환경을 준비할 필요가 있다. macOS는 POSIX 호환성을 갖춘 UNIX 기반의 OS이기에 비교적 접점이 많은 편이다. 하지만 x86-64와 AArch64 명령어 집합 아키텍처의 차이 등 자신이 사용하는 mac 기기가 저수준에서 어떤 차이를 갖는지 인지하고 있어야 올바른 결과를 얻을 수 있을 것이다.

‍♂️ 어렵다

평소에 자주 다루지 않는 저수준의 내용들이라 익숙하지 않음도 있겠지만, 깊이가 있어 대체적으로 좀 어렵다. 개인적으로는 읽으면 '아 그런 말이구나' 이해는 갔는데, 막상 직접 활용하고 응용하라하면 못할 것 같다.

마치며...

이 책의 저자는 모두 일본인이다. 그러고보면 일본에는 장인정신을 가진 사람들이 참 많은 것 같다. 우직하게 한 우물을 파내려가는 그들의 모습은 가치를 창출해내는 근로자의 관점에서는 다소 비효율적으로 보일 수도 있다. 오히려 그렇기에 Hacking이 더 예술적이고 아름답게 느껴지는지도 모른다. 내게도 언젠가 하나에 열중하게 되는 날이 찾아오길 바란다.

[프리코스 3주차 회고] 돌고 돌아 절차지향

ooMia — Fri, 7 Nov 2025 19:05:31 +0900

1, 2주차 미션을 수행하면서 MVC는 프리코스 미션에 대한 설명력이 부족하다는 것을 체감했다. 나는 이번 미션에서 프로그램 내부 구조를 스스로 고안해보기로 했다. 물론 말이 '스스로'지, 외부의 영향을 배제했다고 단언할 수 없다. 결국 어디서 듣고 보고 했던 것들을 짜깁기하는 수준이지만, 나는 모든 요소에 내 나름의 근거를 가지고 처음과 끝 모두 설계했다.

프레임워크

프레임워크라 하면 Spring, Next.js 등 거대한 기술의 집약체를 먼저 떠올리겠지만, 제어 역전(IoC)이라는 넓은 관점에서는 누구나 자신만의 작은 프레임워크를 만들 수 있다. 나에게 프레임워크란 관심사와 최우선 요구사항에 더욱 집중하기 위한 보조 도구일 뿐이다. 프리코스의 세 번째 문제부터는 앞선 두 문제와의 구조적 유사성에 착안하여 util 이라는 작은 패키지 속에 나만의 작업 공간을 만든 셈이다.

Spring: POJOs를 적절히 조합해서 완성된 하나의 시스템을 만들어보세요!

AppConfig

내 이야기를 하기에 앞서, 먼저 영감을 받았던 코드를 소개하려 한다. 리뷰를 하다보면 스프링 프레임워크에서 착안한 사고 방식을 흔하게 만나볼 수 있다. 그 중 하나는 보통 AppConfig라는 이름으로 작성되는 IoC 컨테이너이다. 정은님의 코드에서는 모든 핵심 컴포넌트의 인스턴스가 하나의 파일에서 정의된다. 이러한 방식의 강점은 새로운 파일을 작성하는 것으로 손쉽게 의존성 주입(DI)을 수행할 수 있다는 점이다. 생성자를 통해 주입되는 의존성이 변경되면 각 클래스의 동작이 바뀌고, 나아가 애플리케이션의 동작까지 바뀐다. 개방-폐쇄 원칙(OCP)을 준수한 멋진 디자인이다.

이러한 부분은 고민해볼 필요가 있다. 왜냐하면 실제로 변경의 필요가 나타나는 시점에 이러한 요구사항을 준수하기 위해 부랴부랴 구조를 뒤집어 엎는 것은 꽤나 어려운 일이기 때문이다. 따라서, 이러한 특성은 아키텍처의 특성을 갖는다. 즉, 프로젝트를 시작하기 전에 해당 부분의 필요성을 결정하고 들어갈 필요가 있다. 이러한 결정 비용을 on-demand 형태로 지연시킬 수 있는 것은 큰 이점이고, Spring 프레임워크에서 의존성 주입을 지원하는 이러한 필요에 의한 것일수도 있겠다는 생각이 든다.

[로또] 차정은 미션 제출합니다. by jyc0011 · Pull Request #488 · woowacourse-precourse/java-lotto-8

java-lotto-precourse 관련 함수를 묶어 클래스를 만들고, 객체들이 협력하여 하나의 큰 기능을 수행하도록 한다. 클래스와 함수에 대한 단위 테스트를 통해 의도한 대로 정확하게 작동하는 영역을 확

github.com

/util/Global

앞서 정은님이 애플리케이션 전역의 의존성을 모두 작성하셨다면, 나는 필요한 일부분만 작성했다. 아래 작성된 내용들은 프리코스의 앞선 두 문제와의 교집합에 착안하여, domain 진입 이전에 필요한 내용만 모아둔 것이다. 무엇이 바뀌고, 바뀌지 않을지 아는 것은 설계에 있어 굉장히 중요한 요소이다. 프리코스에는 명확한 안내가 없기 때문에 이러한 귀납적 접근은 내 기준에서는 최선이었다고 생각한다.

public interface Global {

    Global INSTANCE = new Global() {
    };

    Console CONSOLE = camp.nextstep.edu.missionutils.Console::readLine;

    String ERROR_PREFIX = "[ERROR] ";
    Class<? extends RuntimeException> BASE_RUNTIME_EXCEPTION = IllegalArgumentException.class;
    ExceptionHandler EXCEPTION_HANDLER = new ExceptionHandler(BASE_RUNTIME_EXCEPTION);

    char DEFAULT_DELIMITER = ',';
    Tokenizer TOKENIZER = new Tokenizer(DEFAULT_DELIMITER);

    default Console console() {
        return CONSOLE;
    }

    default ExceptionHandler exceptionHandler() {
        return EXCEPTION_HANDLER;
    }

    default Tokenizer tokenizer() {
        return TOKENIZER;
    }
}

귀납적 추론의 한계

프로그램 아키텍처

전체적인 컨셉은 단순하다.

문자열 데이터를 입력 받아 적절히 정보를 추출하고,
추출된 정보를 도메인에서 굴려 유의미한 자료를 만든 뒤,
원하는 방식의 문자열로 가공해서 출력하는 것이다.

구상한 프리코스 과제의 구조

예외 처리

모든 예외 처리는 전역 ExceptionHandler를 통해 처리된다. 이는 모든 예외가 동일한 형식으로 관리된다는 가정이 주어진 요구사항을 가장 쉽게 만족시킨다고 판단한 결과이다. 개발자는 각 패키지 내부에 BaseProblem을 구현하는 enum(또는 클래스)을 선언하는 것으로, 예외 상황을 정의하고 관리할 수 있다.

if (number < minInclusive || maxInclusive < number) {
    throw LottoProblem.NUMBER_OUT_OF_RANGE.exception();
}

+ 현재의 BaseProblem은 Global을 직접적으로 참고하면서 디미터의 법칙을 위배하고 있다.
따라서, 내부적으로 handler() 메서드를 임시로 추가하면 BaseProblem은 앞으로 이런 느낌이 될 것 같다.

public interface BaseProblem {

    String message();
    
    default ExceptionHandler handler() {
        return Global.exceptionHandler();
    }

    default RuntimeException exception() {
        return handler().exception(this);
    }

    default RuntimeException exception(Throwable cause) {
        return handler().exception(this, cause);
    }
}

출력

가장 이의가 많을 것으로 예상한 부분은 도메인 각 객체에서 출력 문자열을 Presentation에서 정의하는 부분이다. 현재의 구현은 앞으로의 요구사항이 어떻게 달라질지 모른다는 가정 하에서 그냥 코드를 단순 정리한 것에 불과하다. 이는 ViewModel 객체를 사용함으로써 고도화할 수 있다. 가령, 이와 같이 마지막 수익률 통계 계산에 필요한 정보를 제공함으로써 출력에 대한 관심사를 분리할 수 있다. 애플리케이션은 도메인을 최소한으로만 알아야 한다는 원칙이 내게 매우 중요했기에 이러한 결정을 내렸다.

public class ProfitStats {
    private final Map<Prize, Integer> prizes;
    private final long totalSpent;
    private final long totalEarned;
    
    public String prizeStats() {
        // TODO implement
    }
    
    public double profitRate() {
        // TODO implement
    }
}

public record ProfitStats(Map<Prize, Integer> prizes, long totalSpent, long totalEarned) {
	@Override
    public toString() {
    	// TODO implement
    }
}

시나리오와 매니저

도메인의 구현과 절차적인 실행. 나는 이 두 가지야말로 앞서 해결했던 프리코스의 모든 문제들을 포괄하는 핵심이라 보았다. 그래서 다른 부분들은 차후에 변경될 여지가 있겠지만, 적어도 이 구조는 변경될 일이 없을 것이다. 먼저 도메인에서는 패키지 외부에서 접근할 수 있는 인터페이스를 제공해야 하는데, 도메인의 특정한 유즈케이스를 정의하는 것은 Manager의 역할이다. 그 다음, 애플리케이션은 해당 유즈케이스를 소비하기 위한 Scenario를 구현한다. 시나리오에 특별한 것은 없고, 그냥 프로그램의 실행을 절차적으로 표현한 것이다.

+ 매니저는 다소 실험적인 도전을 감행했다. 내부적인 상태 변경을 허용한 것이다. 하지만 그런 것 치고 별다른 성과는 없었다. 왜냐하면 현재의 요구사항이 빈번한 수정을 필요로 하지 않기 때문이다. 그래서 이 부분은 개선이 필요할 것 같다.

마치며...

예비군 동원 훈련을 마치고, 오픈 미션을 하나도 시작하지 못한 상태에서 밀린 리뷰를 완료하고, 3주차 회고를 작성한다.
쓰고 보니 글에 여유가 사라진 것이 느껴진다 ☠️

내 능력을 믿고, 남들 2주 만에 하는 것을 1주 안에 해결할 수 있도록 힘내보자!

[프리코스 2주차 회고] 테스트와 리팩터링

ooMia — Wed, 29 Oct 2025 22:13:46 +0900

오늘은 사뭇 진지함이 묻어나오는 포스트가 되길 바란다.

주어진 코드를 개선해나가는 과정을 적는 것으로 2주차의 회고를 대체한다.

RacingCar

내가 그의 이름을 불러주었을 때, 그는 나에게로 와서 레이싱카가 되었다

모든 레이싱카에는 이름이 있다.

그리고 그가 치열하게 달리며 살아온 거리가 있다.

이를 코드로 표현하면 다음과 같다.

public class RacingCar {
    public final String name;
    private int distance;

    public RacingCar(String name) {
        this.name = name;
    }

    public void move() {
        int randomValue = Randoms.pickNumberInRange(0, 9);
        if (randomValue >= 4) {
            this.distance++;
        }
    }
}

인생사 새옹지마라 하였던가

나아가고 싶어도 마음대로 할 수 없는 우리의 '카'

마치 모두가 우테코에 합격할 수 없다는 것처럼 내겐 전해져 온다.

장난은 그만 치고, 그래서 제대로 굴러가는 거 맞아?

그럼요 제대로 동작합니다

@Test
void move() {
    int dice = 4;
    var racingCar = new RacingCar("mia");
    racingCar.move();
    // ... ??
}

... 아니?! 분명 제대로 동작하긴 할텐데...

테스트를 어떻게 하지?

⚠️구현에는 정답이 없습니다.

이후의 내용들은 초기 설계를 기준으로 평가된 내용이며,

지극히 주관적인 견해임을 미리 밝힙니다.

private int

현재의 설계가 어떤 결핍을 가지고 있는지 파악해보자.

첫째, 현재의 설계는 move를 실행했을 때, 그 결과에 따른 상태 변화를 확인하기 위해 private 필드를 직접 참조해야 한다.

둘째, 현재의 설계는 무작위의 값에 의존하여 그 결과가 결정된다.

⚡이 문제를 해결하기 위한 방법은?

첫째, move를 실행했을 때, 그 결과를 반환한다.

둘째, 전달한 인수를 바탕으로 move를 실행한다.

와~ 쉽네~ 그럼 이렇게 만들면 되는거 아니야?

public class RacingCar {
    public final String name;
    private int distance;

    public RacingCar(String name) {
        this.name = name;
    }

    public boolean move(int randomValue) {
        if (randomValue >= 4) {
            this.distance++;
            return true;
        }
        return false;
    }
}

@Test
void move() {
    int dice = 4;
    var racingCar = new RacingCar("mia");
    assertTrue(racingCar.move(dice));
}

다시, 현재의 설계가 어떤 결핍을 가지고 있는지 파악해보자.

기존의 설계에서 move()는 RacingCar의 고유한 행동 방식으로 파라미터 없이 잘만 동작했었다.

이제 추가적인 파라미터가 필요해졌다는 것은 곧 캡슐화에 실패했다는 뜻이다.

개발자는 캡슐화의 실패 여파로 전달되는 무작위의 값을 검증하는 불필요한 코드를 추가해야 한다.

⚡ 다시, 이 문제를 해결하기 위한 방법은?

앞선 두 조건에 마지막 조건을 추가하는 것이다.

첫째, move를 실행했을 때, 그 결과를 반환한다.

둘째, 전달한 인수를 바탕으로 move를 실행한다.

셋째, move의 파라미터를 제거한다.

⁉️ 파라미터 없이 인수를 어떻게 전달하라고

public boolean move() {
    int randomValue = Randoms.pickNumberInRange(0, 9);
    if (randomValue >= 4) {
        this.distance++;
        return true;
    }
    return false;
}

문제 상황을 정리해보자.

파라미터를 제거했기 때문에, 다시 난수값을 함수 내부에 적을 수 있었다.

만약, 당신이 가장 빠른 방식으로 이 문제를 해결하고자 한다면,

접근 제한자 package-private를 사용하는 것을 제안한다.

package-private

현재의 함수는 무작위의 값을 생성하고, 그 값을 평가해서 분기를 거친다.

우리는 이미 값을 들고 있는 것을 가정하고 있으므로 forward(int) 함수를 내장시켜본다.

이렇게 하면 손쉬운 테스트가 가능해진다.

public class RacingCar {
    public final String name;
    private int distance;

    public RacingCar(String name) {
        this.name = name;
    }

    public boolean move() {
        int randomValue = Randoms.pickNumberInRange(0, 9);
        return forward(randomValue);
    }

    boolean forward(int dice) {
        if (dice >= 4) {
            this.distance++;
            return true;
        }
        return false;
    }
}

@Test
void forward() {
    int dice = 4;
    var racingCar = new RacingCar("mia");
    assertTrue(racingCar.forward(dice));
}

다시, 현재의 설계가 어떤 결핍을 가지고 있는지 파악해보자.

기존의 설계에서 move()는 하나의 독립적인 함수로 잘만 동작했었다.

이제 추가적인 파생 함수가 필요해졌다는 것은 이론적으로는 파생 함수의 파생 함수도 필요할 수 있다는 뜻이다.

더 이상 문제가 없다면 상관없지만, 이 방법은 근본적으로는 함수의 파생을 막을 수 없는 해결 방식이다.

⚡ 다시, 이 문제를 해결하기 위한 방법은?

앞선 세 조건에 마지막 조건을 추가하는 것이다.

첫째, move를 실행했을 때, 그 결과를 반환한다.

둘째, 전달한 인수를 바탕으로 move를 실행한다.

셋째, move의 파라미터를 제거한다.

넷째, 별도의 내장 함수에서 난수 값을 가져온다.

⁉️ 그런다고 뭐가 달라져?

달라진다. 달라지는 것은

외부 클래스의 정적 메서드를 통해 들어오던 통제할 수 없던 값을

클래스라는 우리의 제어권 안으로 들여오는 것이다.

protected pickRandom() 함수를 작성하고,
테스트에서는 이 클래스를 상속하여 메서드를 오버라이딩한다.

public boolean move() {
    int randomValue = pickRandom();
    return forward(randomValue);
}

protected int pickRandom() {
    return Randoms.pickNumberInRange(0, 9);
}

static class StubRacingCar extends RacingCar {
    public StubRacingCar(String name) {
        super(name);
    }

    @Override
    protected int pickRandom() {
        return 4;
    }
}

@Test
void move() {
    var racingCar = new StubRacingCar("mia");
    assertTrue(racingCar.move());
}

⁉️ 그럼 모든 값에 대해 매번 상속해야 해?

좀 더 개방된 사고를 해보자.

이제 우리의 제어권에 온 테스트 클래스는 마음대로 사용하면 된다.

(사실 여기서도 기준이 더 있지만, 글이 너무 길어져서 멈추려고 한다.)

class RacingCarTest {

    static class StubRacingCar extends RacingCar {
        public String name = "name";
        public int random = 4;

        public StubRacingCar() {
            super("name");
        }

        @Override
        protected int pickRandom() {
            return random;
        }
    }
    
    private final StubRacingCar racingCar = new StubRacingCar();

    @Test
    void moveSuccess() {
        racingCar.random = 4;
        assertTrue(racingCar.move());
    }

    @Test
    void moveFail() {
        racingCar.random = 3;
        assertFalse(racingCar.move());
    }
}

⁉️ 특정한 거리에 도달한 상태에 대한 테스트는?

축하한다. 다시 처음으로 돌아왔다.

처음 우리의 문제는 void move() 의 동작 성공을

private int distance 필드에 대한 명시적인 확인 대신,

boolean forward(int) 를 통한 간접적 확인으로 대체했다.

그렇게 문제를 피했지만, 언젠가는 특정한 거리에 있는 것이 중요해질 수 있다.

3에서 4로 성공적으로 이동하는 것이 보고 싶나?

그렇다면...

짜잔 ✨접근 제한을 package-private 또는 protected로 느슨하게 풀어주면 됩니다~

(농담 반 진담 반)

지금까지 이게 무슨 X고생임? 그럴거면 처음부터 풀든가

이거 다 뻘소리 아닌가요?

현재의 포스트에서는 외부 라이브러리를 통해 무작위 난수를 받아 움직이는 것의 어려움과, 마지막에서는 이를 어떻게 확인할 것이냐의 총 2가지 문제를 다루고 있다. 난수는 별도의 클래스를 통해 의존성을 주입받고, 테스트에서는 해당 의존성을 재정의하거나 유사 인터페이스를 구현하는 것으로 해결할 수 있다. 이는 단순히 int 형식의 파라미터를 받는 해당 글의 내용과는 다른 이야기이다. 해당 글에서는 단순히 책임을 상위 호출자에게 전가한 것에 불과하다고 생각해서 좋은 해결책이라 생각하지 않는다. 또는 Stub, Mock 등의 Test double을 작성하는 식으로 해결할 수 있다.

이렇게 해결할 수 있지만, 어떤 방식을 선택하든 작성해야 할 코드의 양과 복잡도가 증가한다. 또 중간에 구조 변경이 발생하면, 해당 테스트가 무의미해질 수도 있다. 그래서 그러한 결정을 지연할 수 있는 방법, 그리고 코드와 최대한 결합시킨 상태에서 가장 쉽게 접근할 수 있는 방법들부터 논하고 싶었다.

테스트를 위해 접근 제어자를 바꾸지 마시오

또한 이러한 부분들은 피드백을 통해 제재를 받았는데, **결과적으로 최대한 캡슐화를 지향하자**는 말은 누구나 할 수 있다. 이것이 분명 베스트 프랙티스는 아니지만, 막상 TDD를 기반으로 플로우를 이어나갈 때 현재의 테스트 문제를 지연시키면서, 구현의 유효성을 확보할 수 있는 한시적으로 효율적인 방법이라는 데에는 변함이 없다. 현재의 상황에 대한 문제를 인식하고, 리팩토링 과정에서 고치는 것이 우리의 다음 스텝이 되어야 한다.

개발에 정답은 [업ː따]

개발에 정답은 없다.

최우선 과제와 기한, 그리고 우리의 상황만 있을 뿐이다.

그 가치를 달성하기 위한 최적의 방법을 선택하는 것.

가능하면 넓은 가능성 속에서 더 좋은 선택을 하기 위해 우리는 배우는 것이고,

그 선택이 무엇이든 당신이 가치를 만들 수 있다면 그 선택은 옳다

2주차 회고는 이렇게 마무리 짓도록 하겠습니다.
읽어주셔서 감사합니다!

[서평] 헤드퍼스트 소프트웨어 아키텍처

ooMia — Mon, 27 Oct 2025 03:55:20 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

헤드퍼스트 소프트웨어 아키텍처 / 라주 간디, 마크 리처드, 닐 포드 지음 / 한빛미디어

검색엔진과 LLM을 활용하면 무서울 것이 없는 세상이다.

소프트웨어 아키텍트에 대한 내용도 마찬가지.

인터넷에 이미 있는 내용, 책으로 사서 보면 뭐하나?

...

싶은 사람들이라면 주목!

1️⃣ 미친 몰입감

표현이 과해 보이나? 적어도 이 책에는 그렇게 표현해도 충분하다. 근래 읽었던 책 중에 가장 큰 충격을 받았다. 왜냐하면, 여태 내가 생각했던 기술 서적의 틀을 완전히 벗어났기 때문이다. 나는 형식에 맞춰 통일된 형태로 정보를 전달해야, 독자가 이를 구조화하여 원활하게 받아들일 수 있을 것으로 생각해왔다. 그러나 책의 서론 '이 책을 읽는 방법'에서는 색다른 관점을 제시한다.
독자의 학습을 위한 것이라면 '무엇이든' 하겠다고.

다음 페이지에는 이 책의 특징이 명시되어 있다. 다양한 특징이 있지만, 내가 인상 깊게 본 것은 책에 삽화가 정말 많다는 것. 또 페이지의 구성이 마치 캔버스처럼 다채롭고, 충분히 일반 텍스트로 표현할 수 있는 내용도 삽화와 손글씨로 표현했다. 요약하자면 지루할 틈이 없다는 것이다. 다음 페이지를 펼치면 매번 새로운 자극이 기다린다.

이 책은 자유로워 보이는 표현 방식과는 달리 책의 구성과 짜임새도 굉장히 탄탄하다. 보면 순서대로 읽는 것을 권장하는데, 분명한 학습 로드맵이 있고, 이를 따라가면서 자연스럽게 내용을 쌓아나가는 방식으로 이해하면 된다. 난잡해 보이는 페이지와는 달리 굉장히 잘 정리되어 있다는 것을 알 수 있다.

서론 '이 책을 읽는 방법'

2️⃣ 지루할 틈 없는 다양한 표현 방식

자, 미리 주의하지만, 이 책에 무언가 특별한 지식을 기대해선 안 된다. 오히려 지식만 놓고 보았을 때는, 웹이나 AI를 활용하는 것이 낫다. 하지만 이 책의 강점은 정~~~말 다양한 방식으로 필요한 내용을 반복해서 전달하고 있다는 것이다. 책을 읽으면서 어떤 표현 방식을 사용하는지 조사해서 정리해보았다.

비유
스스로 사고해보기 (연습 문제, 크로스 퍼즐)
질문과 응답
도식화 (이건 너무 다양해서 요약 못 함)
사람과 말풍선으로 메시지 전달
가상의 실무 사례
화살표 형식의 정보 보충 노트
등급 나누기, 점수로 평가하기, 스펙트럼에 표현하기
개념 간 가상의 대화, 개념의 비교
구조화 (구성요소 분해 등)

(내가 미처 발견하지 못한 다양한 방식이 더 있을 수도 있다.)

중요한 것은 이렇게 하면서도 학습의 목적을 소홀히 하지 않는다는 점이다. 학습자는 앞뒤를 뒤적거릴 필요 없이, 한 장씩 차례로 넘기며 순간의 안내들에 집중하면 된다. 또한, 스스로 사고해보는 시간이 많이 주어지고, 모범 답안을 제공해주어 즉각적인 피드백을 가능하게 한다. 이 정답의 디테일도 대단한 것이, 애매하다 싶은 것들은 애매하다고 적혀있고, 독자의 예상과는 다른 정답을 적절한 이유와 함께 제공함으로써 또 다른 방식으로 자극을 주기도 한다는 점이다. (단순히 "우린 정답, 정답과 다르면 넌 틀렸어!" 스타일이 아니라는 것이다.)

도식을 활용한 다양한 표현으로 개념을 반복하여 학습하게 된다

이 책의 관심사가 아닌 것

‍♂️ 복잡한 이론은 다루지 않는다

앞서도 말했지만, 기본적인 내용을 효과적으로 학습하고자 하는 이들을 위한 책이다. 가령, EDA에서 문제 상황이 발생한 케이스를 예시로 비동기 방식의 장단점이 드러나는 상황은 제시하지만, 그래서 보통 어떻게 해결한다는 등의 자세한 설명은 없다.

‍♂️ 특정 기술의 활용 같은 내용은 없다

Kafka나 k8s와 같은 시스템 아키텍처 수준에서 유용하게 활용되는 기술뿐만 아니라, 그냥 특정 기술에 대한 언급이 아예 없다.

‍♂️ 일부 콘텐츠는 영어를 기준으로 제작되었다

크로스 퍼즐 같은 교육 콘텐츠는 영어를 기준으로 제작되었다. 학습한 내용을 영어로 모른다면 맞추기 어려울 수도 있다.

마치며...

이 책을 통해 "목적에 따라 적절하게 표현하는 것"이 중요하다는 점을 깨달았다. 만약 이 책이 더 어렵고 복잡한 내용을 다루었다면, 직접적인 연관이 없는 삽화로 페이지를 채우는 것은 불필요한 낭비였을 것이다. 그러나 독자를 끊임없이 자극하며 학습의 선순환이 이루어지도록 잘 설계했기에, 가벼운 마음으로 끝까지 읽을 수 있는 좋은 책이 되었다고 생각한다. 백엔드 개발자 분들에게 강력히 추천하는 바이다.

[프리코스 1주차 회고] 아 쓰var지 말라고

ooMia — Thu, 23 Oct 2025 21:40:14 +0900

타입을 지정하지 않고 변수로 var를 사용한 이유가 궁금합니다☺️
폴더를 나눠서 정리하는 연습을 하면 좋을 것 같습니다
주석이 없으면 이해가 안되는 코드가 좋은 코드라고 말할 수 있을까요?!!
... ［ 코드 리뷰어들의 질문 中］

열띤 이야기

" 무엇이 더 나은 방식일까? "

코드 리뷰는 단순히 내가 아는 것에 머물지 않겠다는 다짐이고,
내 세계가 또 다른 세계들과 충돌하는 시간이다.

내 스스로 생각해봤던 의문에 대한 질문도 있었지만, 전혀 예상치 못했던 질문도 받았다.
사고를 확장시키는데 이번 리뷰가 정말 큰 도움이 되었다.

어떤 이야기들이 오고 갔는지, 흥미로운 것들 위주로 다뤄보도록 한다.

김민우님의 PR

나는 내 코드보다 민우님이 PR을 먼저 소개하고 싶다. 나는 막연하게 '좋고 유익한 대화가 오고 갔으면 좋겠다' 싶었는데, 이 PR에서는 자신의 관심사와 함께 논하고 싶은 주제를 먼저 소개한다. 이러한 소통 방식에는 '능동적으로 개방적이다'라는 표현이 적절할 것 같다. 남이 와서 건드려야 그제서야 속에 담아왔던 기억들을 찾아가며 이야기를 꺼내는 '수동적으로 개방적'인 나에 비해, 자신이 무엇이 궁금하고 관심이 있는지, 어떤 고민을 해봤는지 등을 먼저 정리해서 꺼내놓는 적극성이 대단하다고 느껴졌다.

민우님의 이번 주차 미션에서 고민한 지점들
1. Service Layer는 정말 필요한가? (애플리케이션 구조)
2. TDD와 예외 케이스의 딜레마
3. 기술 선택의 트레이드오프 (정규표현식 vs split/substring)
4. TDD가 강제하는 Commit Log 단위
5. 기능 목록 작성 관점 (구현 vs. 사용자)

[문자열 덧셈 계산기] 김민우 미션 제출합니다. by minuuu0 · Pull Request #742 · woowacourse-precourse/java-cal

Class Diagram 이번 주차 미션에서 고민한 지점들 (함께 토론하고 싶습니다!) 안녕하세요! 이번 과제를 진행하며 '왜?'라는 질문을 스스로 끊임없이 던져보려 노력했습니다. 이전에는 관행을 따랐다

github.com

내 코드의 문제점

~~이제 비루한 내 PR로 돌아와서,~~

내가 생각하는 내 코드의 문제점은 너무 내 자신에게 매몰되어 있었다는 것이다.
내가 틀렸다, 잘못됐다기보단 '무엇이 좋은가'에 대한 가치 판단이 너무 내 기준으로만 이루어졌다는 뜻이다.

물론, 2주차도 계획했던 것처럼 계속 반복해서 다양한 방식으로 타임어택에 도전할 것이다.

(지금 내게 가장 필요한 것은 설계와 추상화의 정도에 따른 TDD 완수 가능성을 감각적으로 가늠하는 것이다.)

하지만 그런 내 도전이, PR에 올라 '좋은 코드란 무엇인가'를 논하는 자리의 흥을 깨서는 안 된다는 것이다.

너무 모호한 것 같으면 하나씩 사례를 뒤져보자.

1. 논란의 중심: var

당연히 이 var는 아니다

지금부터 AI가 생성한 간단한 만담을 즐겨보자.

var 만능주의자 “타입이 줄면 로직이 드러나. 우리는 코드를 읽는 게 아니야. 로직을 이해하는거지.”
var 불신주의자 “눈이 있으면 로직도 보인다. 구조 파악을 위해 둘 다 있어야 한다.”

장면 1: 짧음은 미덕이다

만능주의자:
이봐, 이거 좀 봐봐!

어때? 쓸데없는 타입 선언이 사라지니까 로직이 한눈에 들어오지?
“그룹별로 사용자 묶기” — 그게 코드의 의도잖아.

불신주의자:

의도는 알지. 하지만 타입은 사라졌잖아.
나중에 findAll()의 리턴 타입이 Set<User>로 바뀌면?
var는 그대로 지나치고, 버그는 조용히 들어올 거야.

** 리턴 타입이 Set<User>가 되면 users의 순서가 변동되면서, 결과 배열의 User 순서도 달라집니다.

장면 2: var의 어두운 면

만능주의자:

그런 건 IDE 툴팁으로 보면 되잖아. 2025년에 아직도 종이 보고 디버깅하냐?

코드는 읽는 사람이 로직을 따라가면 돼.

불신주의자:

아니, IDE에 목숨 걸면 안 돼.
로직을 따라가려면 구조를 알아야지.

이건 로직이 아니라 안개야.
타입이 없으면 흐름도 없다고.

만능주의자:

아, 이건 좀... 근데 그건 var 문제라기보단 작명 센스 부족이지.
그리고 로직이 눈에 띈다는 건 여전히 사실이야.
그러니 중요한 건 ‘언제 써야 하느냐’지.

장면 3: 타입 신앙 논쟁

불신주의자:

나는 이렇게 써.

타입이 명시돼 있으니 코드의 구조가 명확하지.

코드만 봐도 문서야. 이게 바로 클린 코드 아닐까?

만능주의자:

중요한 건 “유저를 그룹으로 묶는다”는 논리지, 데이터 구조가 아니야.
나라면 이렇게 쓰겠어.

일단 이 정도면 누구나 타입을 유추할 수 있잖아?
불필요한 정보가 숨겨지면서 개발자는 논리의 흐름에만 집중할 수 있지.
읽히는 순서가 사고의 순서와 일치하는 게 var의 진짜 가치야.

불신주의자:

그건 유추가 아니라 추리야. 개발자는 셜록 홈즈가 아니라고.

장면 4: 회의실의 결론

팀 리드:

두 분, 둘 다 그만 싸워요.

var는 불필요한 타입을 숨기는 도구입니다.
우리가 내릴 결론은 이겁니다:

API, 공개 메서드, 테스트 코드에서는 명시적 타입 유지
불필요하게 중복 표기된 타입은 var 사용
이외에는 로직이 더 명확해진다고 생각할 때만 var 사용

만능주의자: 즉, " 로직이 더 잘 보일 때만 var "

불신주의자: " 타입이 안 보이면 망할 때는 var 금지."

** 초기에 너무 불신주의자만 유리하게 나왔길래, 로직의 중요성을 좀 더 강조하도록 개입했다.

*** 이외에도 부자연스러운 표현들을 수정했다.

var를 사용할 지, 하지 않을지는 여러분의 선택이다.

나는 사용해보면서 여러 시행착오를 겪어보며 나름의 기준을 정하려 했다.

아쉬운 점은 너무 무분별하게 사용한 나머지 '미아 핑'이 많이 찍혔다는 것... ⁉️ ❓ ❔⁉️

2. 패키지 분리와 애플리케이션 계층 구조

리뷰 답변 일부분

무슨 말인가 하면, 지금 짠 코드들은 다른 어딘가에 이식할 수 있는 범용성 있는 코드가 아니라는 뜻이다.

범용성 있는 코드는 Java API를 생각하면 된다.

물론 규모가 커지면 나누는 게 자연스럽다. 단지 현재의 수준에서는 그렇지 않아도 된다고 판단했을 뿐.

" 아니, 의도가 어떻든 그렇게 한 패키지에 다 몰아넣어놓고 관리하면, 당신 빼고 누가 알아먹어 ?! "
" 남들 다 이렇게 저렇게 하는데, 너님은 왜 그렇게 안 함? "

라고 하면 할 말이 없다. 진짜 없다.

그래서 세워둔 기준: 팀플에서 팀의 결정사항이면 무조건 따른다.

근데 아직 아니잖아? 그러니까 이 정도의 요구사항에서는 과하다고 생각한 내 판단이 맞음. ㅅㄱ

** 말은 이렇게 했지만, 리팩토링한 소스는 별도의 도메인 패키지로 분리했고, 추가로 내가 왜 하나의 패키지로 두려고 했는지 보여주기 위해, 인터페이스와 package-private 클래스로 수정해두었다. 궁금하다면 아래 링크 참고.

refactor: rename and move to `core` package · ooMia/java-calculator-8@ee837e3

Signed-off-by: Hyeon-hak Kim <hyeonhak.kim.dev@gmail.com>

github.com

마치며...

KPT, CSS, TIL, AAR, 4L, 5F 등 목적에 맞는 글쓰기 방법을 선택하는 분들의 '전략 패턴' 같은 모습을 보며
' 아, 시간 관리는 저렇게 하는거구나. ' 싶었다.

오늘부터는 코드 뿐만 아니라 내 삶에서 시간을 할애하는 것에도 기준과 제한을 두어 효율적으로 생활해야겠다!

[프리코스 1주차 회고] 너의 해석은?

ooMia — Tue, 21 Oct 2025 08:36:04 +0900

도전

이번 주 나의 도전은 두 가지로 요약할 수 있다.

문제 해결 중 AI 도움 받지 않기
우아한 코드 & 구현 속도⚡그 사이에서 적절한 균형 잡기

그걸 위해 나만의 체크 리스트를 만들고, 매일 코드를 초기화하며 재시도를 반복했다. 다 합치면 총 6번이다.

2주차까지는 이 방법을 그대로 가져갈 것 같다. 지금 내게 필요한 건 많은 시도와 반복 경험이다.

적어도 내가 하고 있는 이 짓이 지겨워질 때까지 같은 방식으로 작업을 반복해야 한다고 믿는다.

GitHub - ooMia/java-calculator-8: java-calculator-8

java-calculator-8. Contribute to ooMia/java-calculator-8 development by creating an account on GitHub.

github.com

경험칙(오타 아닙니다)을 쌓아나가는 과정이고, 지금 나는 괜찮게 잘하고 있다.

때가 되면 좀 더 깊은 내용으로 회고를 진행할 수 있을 것 같다.

Gist를 노트 삼아 관리하고 있으니 필요하면 참고하시길!

1주차 미션: 간단한(?) 요구사항

구분자와 양수로 구성된 문자열에서 숫자를 추출하여 더하는 계산기를 구현한다.

와.. 이렇게 간단할수가?

문자열에서 특정한 방식으로 숫자를 모두 추출한 뒤로는, 그냥 반복해서 더하는 것이 전부다.

즉, 주어진 규칙에 따라 숫자를 모두 추출하면 90% 완성하는 것이다.

심지어 규칙도 간단하다.

쉼표 또는 콜론을 구분자로 가지는 문자열을 전달하는 경우 구분자를 기준으로 분리한 각 숫자의 합을 반환한다.
앞의 기본 구분자(쉼표, 콜론) 외에 커스텀 구분자를 지정할 수 있다. 커스텀 구분자는 문자열 앞부분의 "//"와 "\n" 사이에 위치하는 문자를 커스텀 구분자로 사용한다.

기본 구분자든, 커스텀 구분자든, 아무튼 구분된 숫자들 파싱하면 되는거잖아!
( 뚝딱뚝딱 구현 중 )

그렇게 첫 번째 구현을 3시간 만에 마친 후, 잘 완성했나 요구사항을 검토해보는데,

웬걸, 눈에 밟히는 게 한 두 개가 아니었다 ⁉️

1. 문자를 커스텀 구분자로 사용한다.

나는 이 '문자'라는 표현을 문자열과 구분되는 단어로 보았다.
'열'이 있냐 없냐 그런 얘기를 하는 건 아니고

보통 char는 문자, String은 문자열로 표현하니까.

자연스레 Character 클래스에 눈이 갔는데, 신기하게 이 친구의 생성자는 deprecated 되어 있었다.
ASCII는 이제 '문자'를 대표하기엔 너무 구식이 되어버렸다는 의미일 것이다.

Character의 생성자는 사용하지 않는다.

그래서 자연스럽게 유니코드로 문자의 개념을 확장시켜 생각했다.
Character.toString( int codePoint )를 사용하면 정수의 값에 대응되는 유니코드 문자를 얻을 수 있다.

이는 Java 8 문서에는 없지만, 21에는 존재한다. LLM으로 검색해보니 Java 11부터 바뀌었다고 한다.

** 이제 프로젝트를 진행 전에 JDK 버전의 API 지원 여부부터 확인해야겠지?

2. 문자열 앞부분의 "//"와 "\n" 사이에 위치하는 문자

대체 앞부분이 어디죠? 아니, 실제로 앞뒤를 구분 못하는 건 아닌데요...

일단 "\n"이 라인 피드로 활용되는 1 byte ASCII 문자가 아니라,
두 문자가 조합된 문자열이라는 것은 테스트 케이스를 참조하여 알 수 있었다.
그래서 문자열 리터럴의 규칙에 따르면 정확히는 "\\n"이 된다.

커스텀 구분자가 세미콜론이라 해보자.

그럼 "//;\\n"이 커스텀 구분자의 정의부가 될 것이다.

그리고 정답이 있는 건 아니겠지만,
나는 커스텀 구분자가 사용되기 전에 정의부가 먼저 나와야 한다고 생각했다.

대충 이런 느낌으로 조건을 하나씩 따져가며 테스트를 작성했던 것 같다.

충격의 OOP ⚡

이렇듯 단순해보였던 문제 속에도 모호함이 숨어있었고,
좋은 코드를 만들기 위한 노력의 일환으로 그 모호함을 추상화하고자 했다.

당시에는 OOP 없이는 좋은 코드가 될 수 없다고 생각했던 것 같다.

번뜩 떠오른 아이디어 중 하나는 Token 인터페이스를 만들고,
모든 토큰이 Token reduce( Token operand )를 구현하여 유기적으로 동작하도록 만드는 것이었다.

하지만 객체에게 독립성을 부여하면 관리의 책임도 크게 돌아온다.

모두 설명하기엔 좀 길고, 총 세 번 시도해봤는데 다소 작위적으로 구현되는 느낌이 있어서 그만 뒀다.

그리고 OOP 또한 유지보수를 위한 도구로 인식해야겠다는 경험을 하나 얻었다.

마치며...

이 밖에도 다양한 부분들을 고민했다. 객체지향적 설계/구현을 위한 고민과 시도, String을 순회하는 다양한 방법, 요구사항에서 어떤 정보가 필요한지, 또 그 정보를 어떻게 빠르고 효율적으로 정리할 지, 모호한 요구사항에 대처하는 마인드셋과 추상적인 설계에 대한 개념 증명 방식 등... 앞서 말했듯 스스로 경험을 통해 나만의 정답을 쌓아나가는 중이다.

1주차가 종료되었으니, 이제 다른 참가자들과 교류하면서 내 정답을 의심해볼 차례다.

다양한 분들의 코드에서 각자만의 이야기가 담겨있을 것 같아 벌써 설렌다!

[서평] 스프링 6 레시피 (5판)

ooMia — Sun, 28 Sep 2025 06:43:42 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

스프링 6 레시피 (5판) / 마틴 데이넘, 다니엘 루비오, 조시 롱 지음 / 한빛미디어

1️⃣ 풍성한 예제 코드

책 소개를 읽으며 예제 코드가 있다는 것을 확인하고 정말 반가웠다. 최근 리뷰했던 실습 서적들에서 비교적 예제가 부실하다고 느꼈기 때문. 심지어 유용한 정보가 많은 Baeldung의 컨텐츠들도 온전하게 동작하는 예제를 제공해주진 않으니까. 물론 누군가는 소스 파일 하나 또는 일부만 보더라도 "아, 이거 이렇게 하면 되겠네." 알 수도 있겠지만, 적어도 이 책을 필요로 하는 이들 중에는 분명 그렇지 않은 사람들이 더 많을거라 생각한다. 실행 가능한 형태로 예제가 제공된다는 점은 이 책의 가장 큰 강점이라 생각한다.

GitHub - LENATeam/spring6-recipe

Contribute to LENATeam/spring6-recipe development by creating an account on GitHub.

github.com

2️⃣ 레시피 북과 가이드 북, 그 사이 어딘가

이 책의 부제에서 '137가지 문제 해결 기법'이라 소개하듯, 이 책은 원하는 내용을 찾아 적용하기 쉽도록 구성을 해두었다. 앞서 언급한 실행 가능한 예제까지 활용한다면 책에서 전부 다루지 못한 부분도 충분히 이해할 수 있으리라 생각한다. 그렇다면 이 책은 레시피 북인가? 꼭 그렇지만은 않다.

책을 읽다보면 이전 장의 내용을 언급하거나, 앞선 레시피의 내용을 확장하는 식으로 전개되는 부분들이 있다. 이는 WAS를 개발해나가는 관점에서는 굉장히 자연스러운 흐름이다. 각 장의 순서도 애플리케이션의 성숙도를 고려하여 배치되었다는 인상을 받았다. 즉, 이 책은 필요한 내용만 골라 읽어도 좋지만, 순서대로 읽어도 좋다.

3️⃣ 기초에서 시작하는 문제 해결

이 책의 가장 큰 장점은 주어진 문제를 가장 기본적인 방법을 통해 해결하는 것에서부터 시작한다는 것이다. 최근 바이브 코딩이 유행하면서 그저 동작하는 것에 만족하는 경향이 이전보다는 늘었다고 생각한다. 이럴 때야말로 기초를 다지는 것이 필요하다. 이미 많은 경험을 가진 개발자라면 다시 돌아보면서 놓쳤던 기본기를 점검할 수 있고, 경험이 적다면 다양한 애너테이션이 가리고 있는 수많은 추상화 뒤에 가려진 기초를 확인할 수 있는 기회가 될 것이다.

‍♂️ 기술 스택, 설치는 재량껏

온전히 동작하는 예제 소스가 제공되는 것은 맞지만, 당연히 추가적인 기술 스택이 활용되었다면 설치가 필요하다. 가령, 데이터베이스를 활용하는 예제에서 인-메모리 DB가 아니라면, postgresql, mysql 등 제공사의 안내에 따라 제품을 설치해야 한다. 보통 docker를 활용하는 것이 편한데, 익숙하지 않다면 로컬로 설치하더라도 상관없다. 이러한 부분을 어떻게 해결할 지는 책의 관심사 밖이다.

‍♂️ ORM은 자세히 다루지 않는다

국내에서는 Spring 선구자들의 영향으로 영속성 계층에서 ORM의 사용이 거의 보편화되어 있다. 물론 이 책에서도 Hibernate, JPA에 대한 언급이 있지만, 가볍게만 다루고 넘어간다. 따라서, 6장 데이터 액세스 그리고 7장 스프링 트랜잭션 관리는 JDBCTemplate 사용을 가정하고 설명하는 부분들이 있다. 필요한 내용의 결을 파악하고 이해하여 문제를 해결할 수 있다면 상관없지만, 가령 JPA를 활용하는 환경에서 직접적인 해결책을 구하고 있다면 전문 서적을 참고하는 편이 더 나을 수 있다.

‍♂️ 최신 버전 Spring 7은 다루지 않는다

책은 책이다. 책 제목이 Spring 6이기도 하고, 요즘처럼 변화도 빠르고, 정보의 공유/확산이 빠른 시대에 책을 통해 최신 정보를 접할 수는 없다. 그렇다보니 9월 16일 등장한 따끈따근한 JDK 25와 함께 Spring의 새로운 메이저 버전 Spring 7.x을 어떻게 하면 잘 활용할 수 있는지에 대한 부분은 당연히 논외이다. 이 부분도 신경쓸 필요가 있는 이유는 이 책에서 현재는 deprecated된 기능을 사용하고 있기도 하기 때문이다. 대표적으로 5장 스프링 시큐리티의 패스워드 인코더는 다음 메이저 버전에서 새롭게 개편될 예정이다. 그래도 이런 경우가 많지는 않으니 결정에 참고 정도만 하면 될 것 같다.

마치며...

이 책은 앞으로도 시간이 나면 계속 펼쳐보게 될 것 같다. 필요한 내용을 찾아서, 이 책으로 감을 잡고, 공식 문서 등을 참고해서 좀 더 발전시키는 느낌으로 활용하기 좋아보인다. 노트로 전달된 꿀팁이나 역자분들의 각주도 내용 이해에 큰 도움이 되었다. 소스 전문이 제공되는 점은 정보 손실이 없다는 점에서는 좋지만, 너무 길어지는 경우에는 중요한 부분을 강조해서 보여주면 가독성이 좀 더 좋았을 것 같다는 생각도 들었다. 그래도 전체적으로 재밌게 잘 읽었고, 입문자부터 중급자까지 활용하기 좋은 책이라 생각한다!

[서평] 개발자를 위한 IT 영어 온보딩 가이드

ooMia — Mon, 28 Jul 2025 19:01:32 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

개발자를 위한 IT 영어 온보딩 가이드 / 장진호 지음 / 한빛미디어

‍ 넓고 가볍게 다루는 개발자 영어

개발을 하다보면 프로그래밍 외에도 영어를 마주하게 되는 순간들이 있다. 이 책은 그 순간들에 당황하지 않도록, 그리고 나아가 외국인 개발자들과 원활하게 소통할 수 있도록 돕는 교양 서적이다. 컴퓨터 공학을 전공하지 않았다면 참고할만한 다양한 IT 용어들도 함께 학습할 수 있다. 개발자보단 개발자들과 소통해야 하는 분들이 참고하시면 좋을만한 내용의 책이다.

콩글리쉬

1. 콩글리쉬

콩글리쉬는 분명 영어의 잘못된 사용인데, 익숙해지면 잘못된 줄 모르고 사용하게 되는 경우가 있다. 판교어처럼 사용하는 것은 소통이라는 큰 맥락에서 괜찮을지는 몰라도, 결국 외국인에게는 의미가 전달되지 않을 수 있다는 점에 유의해야 한다. 이러한 관점에서 무엇이 콩글리쉬인지 인지하는 것은 유익하다.

전치사 on의 활용

커밋 메시지 관련 용어

2. 전치사 활용

영어 주석이나 문서를 작성할 때, 멈칫하게 되는 시점 중 하나는 전치사를 사용할 때다. 전치사 사용에 나름의 규칙이 있다고는 하지만, 문법 같은 느낌은 아니니까... 요즘 LLM과 검색엔진을 혼용하면 대부분의 일반적인 정보는 쉽게 확인할 수 있지만, 책에서는 on, in, at, to의 활용을 깔끔하게 확인할 수 있어서 좋았다.

3. 커밋 메시지

커밋 메시지를 작성할 때에도 잠깐 멈칫한다. 수행한 작업을 짧게 요약하는 것이 애매한 경우가 있기 때문이다. 이를 위해 책에서는 보편적으로 사용하는 메시지 타입을 제공하고, subject에 사용할 수 있는 25개 정도의 동사들을 정리하여 소개한다. 물론 이걸로 모든 상황을 커버할 수는 없지만, 간단히 참고하기는 좋다.

마치며...

물론 포스트에 명시한 내용 외에도 '글로벌 기업 취업 준비 노하우'라든지, '영문 비즈니스 이메일 작성법'이라든지, 외국계 회사에서 근무하기 위해 필요한 내용들도 포함하고 있다. 분명 IT 영어라는 넓은 범주에서는 납득할 수 있는 내용이지만, 사실 이 책을 펼치기 전에 기대했던 부분은 유사한 의미를 가진 단어의 뉘앙스 차이라든지, 인사이트를 얻을 수 있는 다양한 용어 소개 같은 부분이었다. 가령, @는 at sign 외에도 ampersat이라 칭한다는 것은 이 책을 통해 처음 알았다. 하지만 그 양이 너무 적어서 아쉬웠다.

공식 문서를 읽다가 단어를 모른다고 갑자기 이 책을 펼칠 일은 당연히 없을 것이다. 그래서 책은 지평을 넓혀주는 역할을 해야한다고 믿는데, 확실히 이 책은 얕지만 광범위한 영역을 다루면서 독자의 지평을 넓히는데 도움을 주고 있다. 영어가 어려운 개발자 또는 개발자들과 소통해야 하는 직무라면 한 번쯤 읽어봐도 좋을 것 같은 책이다.

9 - 실전 배포하기 (마지막 가이드)

ooMia — Tue, 1 Jul 2025 00:30:27 +0900

Overview

이번 시간에는 온체인 상호작용을 포함시키고, 본격적으로 프로젝트의 규모를 키우기 위한 구조적 개선을 설명합니다. case5-onchain-sepolia 브랜치에는 많은 작은 변화들이 있지만, 이번 포스트에서는 큰 변화 세 가지만 설명합니다.

모노레포 구조로 전환했습니다.
스마트 컨트랙트를 실체 체인에 배포합니다.
작업 결과를 GitHub Pages로 배포합니다.

이 결과로 여러분들은 다음과 유사한 페이지 결과를 GitHub Pages로 배포하는 결과를 얻게 됩니다. 물론 더 다양한 상호작용을 위해서는 AWS, Vercel 같은 PaaS를 사용해볼 수 있겠지만, 본 시리즈에서는 정적인 사이트 안에서 구현 가능한 수준만 다루고자 합니다. (SWR 등의 라이브러리까지 활용하면 정적 사이트에서도 충분히 많은 걸 할 수 있어요!)

https://oomia.github.io/hands-on-dapp/

1. 모노레포 프로젝트

프로젝트의 구조적 변화는 실제 기능과는 전혀 관계 없습니다. 하지만 여러분들이 새롭게 바뀐 프로젝트의 구조를 이해하고 적응하기 위해서는 설명이 필요합니다. 모노레포(mono-repo)라는 하나의 레포를 사용하는 패턴입니다. 그림과 같이 여러 개의 작은 프로젝트를 하나의 레포에서 관리하는 것이죠. 언제 이런 패턴이 유용할까요? 개인적으로는 하나의 프로젝트가 서로 다른 다수의 프레임워크를 동시에 다루어야 하는 경우에 매우 적합하다고 생각합니다.

https://medium.com/@magenta2127/monorepo-vs-multi-repo-vs-monolith-7c4a5f476009

이전에 다룬 것처럼 프레임워크는 일련의 사용 방법을 사용자에게 강제하지만 대신에 편의성을 제공합니다. 예를 들어, 우리가 사용하고 있는 foundry는 기본적으로 시스템에 설치되어 동작하기 때문에, 도구를 사용할 때 터미널의 현재 경로가 명령의 결과에 큰 영향을 미칩니다. 만약 프로젝트 밖에서 명령을 호출하는 상황이 생긴다면 매우 불편하겠죠? 또 다른 장점은 개별 프로젝트의 기능을 독립적으로 선언하고 관리하기 쉽다는 점입니다. 이러한 점들은 개선 후의 package.json 파일을 보면 더 체감이 되리라 생각합니다.

개선 후의 package.json

알아둘 것은 2가지, pnpm run -r과 pnpm run --filter 구문입니다. -r은 상위 워크스페이스에서 모든 하위 워크스페이스에 재귀적으로 명령을 전파하기 위한 옵션입니다. 이와 달리 --filter 옵션은 특정 패턴에 맞는 워크스페이스에 대해서만 명령을 전파합니다. 이를 통해 별도의 경로 변경 또는 명령어를 전역에 고유하도록 설정하지 않아도 되고, 개별 워크스페이스는 내부적으로 필요한 명령만 정의하고, 필요한 상호 작용이 있다면 필터를 걸어 손쉽게 훅도 설정할 수 있습니다.

root : pnpm build

* 물론 기존의 패키지 매니저를 기반으로 모노레포 구조를 만들었지만, 최근에는 모노레포 전용 도구들도 많이 나오고 있는 추세입니다. Vercel의 Turborepo가 대표적인 JS/TS 기반 모노레토 도구이고, 그 밖에도 다양한 도구들이 있으니 참고하시면 좋을 것 같아요.

2. 온체인 컨트랙트 배포

이전까지는 항상 로컬 Anvil에 배포하고 그 결과를 받아오는 구조였다면, 이제는 NEXT_PHASE 환경 변수를 활용해서 개발 환경에서는 Anvil을 사용하고, 운영 환경에서는 Sepolia Testnet을 사용하게 됩니다. 참고로 NEXT_PHASE는 직접 설정해주지 않더라도, next 프레임워크에서 자동으로 설정해주는 변수이고, next/constants 모듈을 참조하면 보다 더 자세한 내용을 확인할 수 있습니다. 소스를 보니 foundry의 환경변수를 참조하고 있네요. 정확히 어떤 값들이 필요한지 확인해봅시다.

front/src/app/api/config/[slug]/environment.ts

/foundry/.env

PRIVATE_KEY는 EOA의 개인 키를 의미합니다. SEPOLIA_RPC_URL은 사용하고자 하는 sepolia test network의 RPC URL을 의미하고, ETHERSCAN_API_KEY는 etherscan의 API를 활용하기 위해 발급된 API 키입니다. 이렇게만 설명하니 동어 반복처럼 느껴지나요? 그럼 각 요소의 값을 어떻게 생성할 수 있는지 간단히 알아보겠습니다.

2-A. PRIVATE_KEY

MetaMask 시작하기 | MetaMask Help Center

The basics you need to set up MetaMask.

support.metamask.io

How to export an account's private key | MetaMask Help Center

Want to import your MetaMask wallet into a different wallet? Here's how to do it safely.

support.metamask.io

Metamask는 가장 범용적으로 사용되는 암호화폐 지갑 앱입니다. 첫 번째 링크를 참조하거나 인터넷에 검색해보면 쉽게 계정을 생성할 수 있어요. 그리고 개인키는 두 번째 링크에서 설명하는 방식으로 얻을 수 있습니다. 하지만 본질적으로는 계정 자체가 어떤 앱에 종속되는 형태는 아닙니다. 적합한 mnemonic만 있다면 BIP(Bitcoin Improvement Proposal): BIP-39, BIP-32, BIP-44에 따라 누구든 로컬에서 계정을 생성할 수 있습니다. 그런 이유로 아래 코드를 참고하시면 좋을 것 같아요. 혹시라도 본인 계정이 결과로 나오지 않는다면, AddressIndex를 1씩 증가시켜보면 됩니다. 물론 여기서 자세히 다루지는 않을테니 이런 내용이 있다는 것만 알고 계시면 될 것 같아요.

mnemonic

코드 전문

from bip_utils import Bip39SeedGenerator, Bip44, Bip44Coins, Bip44Changes
from bip_utils.utils.mnemonic import Mnemonic
from eth_utils import to_checksum_address, keccak

# 1. 니모닉 입력
raw_mnemonic = "turkey deposit bench narrow moon world flat display size measure wealth august"
mnemonic: Mnemonic = Mnemonic(raw_mnemonic.split())

# 2. 시드 생성
seed_bytes = Bip39SeedGenerator(mnemonic).Generate()

# 3. BIP44 이더리움 경로 설정: m/44'/60'/0'/0/0
bip44_wallet = Bip44.FromSeed(seed_bytes, Bip44Coins.ETHEREUM)
bip44_addr = bip44_wallet.Purpose().Coin().Account(0).Change(Bip44Changes.CHAIN_EXT).AddressIndex(0)

# 4. 개인키와 공개키 얻기
private_key = bip44_addr.PrivateKey().Raw().ToHex()
public_key_bytes = bip44_addr.PublicKey().RawUncompressed().ToBytes()[1:]  # remove 0x04 prefix

# 5. 이더리움 주소 생성 (Keccak-256(public_key) 후 마지막 20바이트)
eth_address = to_checksum_address(keccak(public_key_bytes)[-20:])

if __name__ == '__main__':
    print("  Private Key:", private_key)
    print("  Ethereum Address:", eth_address)

2-B. SEPOLIA_RPC_URL

RPC의 개념은 이전에 3번째 시리즈에서 잠시 소개한 적이 있으니 넘어가겠습니다.

3 - 스마트 컨트랙트 개발 환경 셋업

RPC url을 얻는 방법도 다양합니다. 제가 예시로 공개한 url은 infura를 통해 개인적으로 발급받은 것이고, 굳이 그럴 필요 없이 이전에 소개한 ChainList에 공개된, 체인 ID가 11155111이고, https 프로토콜을 사용하는 어떤 url도 가능합니다. (https://1rpc.io/sepolia)

참고로 Sepolia testnet에 트랜잭션을 전송하려면 gas 비용이 필요합니다. 이는 일종의 수수료 개념인데요, 이 역시도 faucet을 통해 제공받는 다양한 경로가 있습니다. (구글에 sepolia faucet 검색)

2-C. ETHERSCAN_API_KEY

etherscan은 가장 널리 활용되는 Block Explorer입니다. 최근에는 오픈소스인 blockscout 쪽도 꽤나 인기있지만, 일단은 etherscan을 사용하고자 합니다. API_KEY가 필요한 것은 이 익스플로러에 컨트랙트 코드를 인증하기 위함입니다. 인증된 컨트랙트는 다음과 같이 소스 코드가 보이게 됩니다. 인증되지 않은 경우, 바이트코드 형태로 보여서 별도의 디컴파일러 사용 없이는 보기가 불편하거든요.

인증된 컨트랙트와 그렇지 않은 경우

발급받는 방법은 간단합니다. 로그인 후 https://etherscan.io/apidashboard의 API Keys에서 발급받을 수 있습니다.

https://etherscan.io/apidashboard

2-D. 스마트 컨트랙트 배포

환경변수가 잘 설정되어 있다면, 기존 배포 명령에 체인만 명시하는 것으로 손쉬운 배포가 가능합니다.

~/foundry/package.json

-f (--fork-url)옵션은 기본적으로 전체 RPC url을 모두 명시해야 하지만, foundry.toml 파일에 rpc_endpoints를 명시했다면 이처럼 alias를 활용해서 명령을 간소화 할 수 있습니다. 자세한 내용은 다음 링크를 참조하세요

~/foundry/foundry.toml

3. GitHub Pages 배포

Next.js에서 작성된 front에서의 작업물은 기본적으로 SSR 방식으로 제공되지만, 설정에 따라 CSR, SSG도 가능합니다. 그 중 우리는 Static Site Generator 방식을 활용해서 정적 페이지를 만들고, 그 결과를 GitHub Pages로 배포해봅시다. 가장 중요한 설정은 다음 파일에 있습니다. 이 중 nextConfig.output = "export" 설정을 해야만 front/out 폴더에 정적 페이지 형태로 결과가 남습니다. start:ci (CI=true pnpm build && pnpm dlx serve@latest out) 명령을 통해 예상 결과물을 살펴볼 수 있도록 제공해두었으니 참고하세요!

~/front/next.config.mjs

Pages로 배포하기 위해선 포크한 레포에서 'GitHub Actions로 배포' 설정을 해주어야 합니다. 이후에는 .github/workflows/deploy.yaml에 명시된 배포 워크플로우를 트리거하면 끝입니다. actions/configure-pages@v5를 통해 baseUrl을 설정하는 디테일이나 캐싱 등 GitHub Actions 활용과 관련한 내용은 자세히 다루지 않겠습니다.

Repository > Pages > GitHub Actions 설정 그리고 Actions 탭에서 Deploy 워크플로우 실행

마치며

이번 시간을 끝으로 DApp에 필요한 정말 기본적인 요소들을 다루었습니다. 사실 DApp이라고 하면 온체인 데이터 및 컨트랙트 간의 상호작용이 더 필요한 것이 사실입니다. 하지만 이 시리즈의 시작 자체는 아무것도 모르는 분들을 위한 가이드 목적으로 시작했기 때문에 다소 제약이 많았던 것이 사실입니다. 실제 DApp과 관련된 다양한 기능 구현은 https://speedrunethereum.com/을 활용하여 연습해보시는 것을 추천드립니다. 다음 시리즈부터는 보다 DApp스러운 기능 또는 그러한 작업을 원활하게 수행하기 위한 템플릿 성격의 기능들을 추가해볼 예정입니다.

[서평] 자바 최적화

ooMia — Thu, 26 Jun 2025 03:38:25 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

시작하기 전에...

이 책을 어떻게 리뷰하면 좋을까?

이 책에 담긴 내용이 너무나 소중해서 어떻게 다루어야할지 고민을 정말 많이 했다. G1 / Shenandoah / ZGC / Balanced 등 고급 GC의 원리와 활용 방법을 바로 다루자니 비교적 마이너한 분야라 처음 접하시는 분들이 읽기에는 피로도가 높을 것 같았고, 반대로 애플리케이션 관측성과 클라우드 배포를 실습하자니 제품 활용에 대한 내용이 많아 이 책의 진가를 보여줄 수 없을 것 같았다. 그래서 고민 끝에 Java 성능 향상을 위해 하드웨어에 대한 기계적 공감이 얼마나 중요한지를 핵심 주제로 정했다. 물론 글의 흐름에도 신경썼다. 하드웨어에 대한 내용은 동시성에 대한 상세 내용 자체는 7장에서 30페이지 이하로 짧게 작성되었지만, 나는 이 짧은 내용조차 책 전반에 걸쳐 얼마나 깊이 있게 이해할 수 있는지를 전달하고 싶었다. 따라서, 7장에만 국한되지 않고 필요하다면 이전/이후 장의 내용들을 유기적으로 짜깁기하여 저자의 의도가 파편화되지 않도록 보충했다. 각 문단 끝에 이모지를 활용하여 작성 의도를 요약하였으니, 모든 내용을 읽기 어렵다면 이 부분만 가볍게 체크하고 넘어가면 된다.

자바 최적화 / 벤저민 에번스, 제임스 고프 지음 / 한빛미디어

1. 당신이 하드웨어에 관심을 가져야 하는 이유

트랜지스터는 더 이상 작아질 수 없는 한계에 도달했으며, 결국 물리학의 법칙이 장애물로 작용합니다. 현재 트랜지스터는 원자 단위로 측정할 수 있을 정도로 작아졌고, 상용화된 가장 작은 트랜지스터의 너비는 3nm에 불과합니다. 이는 인간 DNA 한 가닥(약 2.5nm)보다 약간 더 넓은 수준입니다.
2021년, IBM은 2nm 칩을 성공적으로 개발했다고 발표했지만, 이제 이러한 발전은 비용이 과도하게 증가하고 진행 속도가 매우 느려졌습니다. 따라서 안정적인 성능 향상이 가능할지 의문이 제기되고 있습니다. 또한, 현재 재료 물리학의 한계를 고려하면 원자보다 얇은 전선을 만들 수는 없습니다.
─ Audrey Woods, 'The Death of Moore’s Law'

지난 수십년 간, 소프트웨어 성능은 하드웨어의 발전이 가져다주는 혜택 아래에서 쉽게 개선되어 왔다. 흔히 말하는 스케일 업(scale-up)을 통해 서버의 스펙을 높이면 처리량도 그에 비례하여 올라갔다. 그러나 어느 순간부터 스케일 업은 한계를 마주하게 된다. 하드웨어의 양적 개선만으로는 다양한 병목을 해결할 수 없었고, 하드웨어의 발전도 예전 같지 않았기 때문. 물론 예나 지금이나 한결 같이 개선의 한계를 토로했음에도 기술은 끊임없이 발전해왔다. 그러나 그 속도는 예전 같지 않음에 동의하지 않을 사람은 없다. 반도체 집적회로의 성능이 24개월마다 2배로 증가한다는 무어의 법칙(Moore's law)도, 이제는 무어의 제2법칙에서 48개월로 늘어났다.

따라서 현대 컴퓨터에서는 자연스럽게 한정된 시스템 자원을 효율적으로 활용하기 위한 고도화가 진행되었다. 예전에는 단순 스케일 업으로 향상되었던 하드웨어 성능도, 이젠 기술적/경제적 이유로 인해 구조적 개선이 불가피하다는 뜻이다. 그렇다면 소프트웨어는 어떨까? 소프트웨어 프레임워크도 이에 발맞춰 개선하다보니 복잡성이 증가했다. 정리하자면 결과적으로 컴퓨팅 성능 자체는 분명 향상되었지만, 소프트웨어 엔지니어가 이 혜택을 모두 누리기 위해 알아야 할 지식과 수행해야 할 작업들이 예전에 비해 점점 더 복잡해지고 있다는 것이다.

단순 스케일 업 기반의 성능 향상은 한계에 도달했다. 이제 소프트웨어 엔지니어들은 현대 하드웨어의 개선 방향성과 이를 기반으로 최적화된 언어 및 프레임워크의 동작을 이해해야만 최고 수준의 성능 최적화에 도달할 수 있다.

The Death of Moore’s Law: What it means and what might fill the gap going forward
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software

2. 지금 당장 하드웨어를 활용해야 하는 이유

JVM (Java Virtual Machine)

당신이 자바 가상 머신(JVM)을 활용하는 소프트웨어*를 개발하고 있다면, JVM이 멀티 코어 프로세서에 최적화된 방식으로 동작한다는 사실을 명심해야 한다. JIT 컴파일러(Just-in-time Compiler), 그리고 프로덕션 환경에서 사용하는 현대의 GC(Garbage Collection) 모두 해당된다. 당신이 작성한 애플리케이션이 싱글 스레드에 Blocking 방식으로 동작하든, 멀티 스레드에 Non-blocking 방식으로 동작하든 상관 없다. 현대의 자바 실행 환경은 멀티 코어 환경에 최적화됐다. 그럼에도 2022년 Relic의 조사에 따르면, 자바 애플리케이션의 70% 이상이 컨테이너 환경에 배포되고 있었으며, 그 중 약 절반은 1 vCPU 이하로 제한된 상태에서 실행되고 있었다.

Relic - 2022 State of the Java Ecosystem

이것은 결코 사소하지 않다. 레드햇과 마이크로소프트의 연구 결과에 따르면, 자바 애플리케이션을 컨테이너화할 때 다수의 단일 코어 컨테이너보다 소수의 멀티 코어 컨테이너에서 실행하는 것이 일반적으로 더 유리한 것으로 나타났다. 이러한 싱글 코어 제약은 JVM이 Serial 또는 SerialOld 컬렉터를 선택하도록 만들고 GC가 직렬로 실행되도록 만들어, 일시 정지 시간이 길어지고 처리량이 줄어들며 애플리케이션이 더 빈번하게 중단되는 문제를 야기한다. 그래도 이듬해 23년 Relic의 조사 결과에서는 이런 케이스가 5%p 가량 감소했다.

Java 11과 17에서 CPU 2개 이상, 메모리 2GB 이상이 아니라면 Serial GC가 선택된다

기본적인 GC 최적화도 제대로 이루어지지 않고 있는 것이 현실이다. 복잡한 튜닝 없이 기본 원칙을 지키는 것만으로 애플리케이션 성능이 배가 된다면... 하지 않을 이유가?

* Java로 언어를 특정하지 않은 이유는 JVM은 유효한 클래스 파일을 생성할 수 있는 모든 언어에 호환되기 때문이다. 일례로 Kotlin, Groovy, Scala, Clojure 등이 생성하는 바이트코드는 모두 JVM 위에서 실행 가능하다.

2022 State of the Java Ecosystem / 2023 State of the Java Ecosystem

Best practices for Java in single-core containers

앞선 멀티 코어 프로세서 사례를 통해 성능 최적화를 하드웨어 영역에서 바라보는 것이 왜 중요한지, 실증적인 문제 인식은 충분히 되었을거라 믿는다. 물론 전력 효율이나 메모리 최소화 등의 특수한 경우에는 싱글 코어 환경이 적합할 수도 있지만, 우리는 지금 일반적인 얘기를 하고 있다. 문제는 단순히 안티 패턴을 교정하는 수준이 아니라, 성능 최적화를 위한 파인 튜닝이 필요할 때다. 안타깝게도 이를 위한 은탄환은 없다. 따라서, 다음 단계는 런타임동안 JVM이 어떻게 동작하는지 이해하고, 가설을 세운 뒤 이를 검증하는 것이다. 이러한 관점에서 JIT 컴파일러와 GC는 학습을 위한 좋은 출발점이다. C1, C2 계층적 컴파일, 메서드 캐시와 코드 캐시, 분기 예측과 추측 실행, AOT 컴파일과 PGO 등 처리 속도 관점에서 학습하고, 클래식 GC부터 G1, 섀넌도어의 구조와 동작 방식 등 런타임 상태 분석 관점에서 학습해볼 수 있다.

JVM 이해를 돕는 다양한 도식들

3. 자바 메모리 모델이 중요한 이유

'갑자기 메모리?' 라고 생각했다면 주목. 앞선 두 문단에 걸쳐 나는 하드웨어 자체의 발전 속도에는 제동이 걸렸으니, 이제는 보다 자원을 똑똑하게 활용해야 할 때라는 메세지를 전달하고 싶었다. 이러한 관점에서 동시성 프로그래밍을 활용하는 것이야말로 시스템 자원을 똑똑하게 활용하는 방법 중 하나라는 데에 이의를 가진 독자는 없을거라 생각한다. 또한 이 글 전반에 걸쳐 강조하고 싶은 내용은 코드 레벨 외에도 JVM의 동작을 이해하는 것으로 가능한 최적화가 있다는 사실이다. 중요하게 생각하는 동시성 프로그래밍과 JVM, 둘 사이의 교집합으로 JMM이 존재하기에 강조하고자 했으며, 이를 보다 깊이있게 전달하기 위해 컴퓨터 구조가 어떻게 개선되어 왔는지부터 간단히 짚고 넘어가도록 하겠다.

CPU 발전과 캐시의 도입

CPU는 계속 발전해왔다. 무어의 법칙 아래 트랜지스터 수는 기하급수적으로 증가했고, 클럭 속도도 따라서 상승했다. 문제는 데이터였다. 데이터가 다음 클럭에 바로 로드되지 않아(hazard) CPU가 정지(stall)하는 상황이 빈번해졌다.* 정리하자면 메모리에 병목이 걸려 전체 성능이 메모리 성능 수준에 머물게 되는 것이다.

연도별 프로세서-메모리 성능. 차이가 커질수록 데이터 로드 지연에 따른 연산 효율은 감소한다.

이러한 현상은 '폰 노이만 병목'으로도 불리며, 폰 노이만 컴퓨터 구조에서 명령어와 데이터가 동일한 버스를 공유하기 때문에 발생한다. CPU 캐시는 이를 완화하기 위한 방법 중 하나로 도입되었다. 핵심 컨셉은 자주 접근하는 메모리의 위치와 값을 근처에 복사해두고 사용해서 최대한 주 메모리 참조 횟수를 줄이는 것. 프로세서 아키텍처에 따라 캐시의 수와 구성에 다소 차이가 있지만, 일반적으로 L1과 L2는 각 코어 내부에, L3는 여러 코어가 공유하도록 구성되어 있다. 이 결과로 소프트웨어의 성능은 참조 데이터의 지역성 수준 정도로 이전보다 수십 배 빨라질 수 있게 되었다.

* 물론 단순 대기(stall) 외에도 이러한 비효율을 방지하기 위한 다양한 개선책─operand forwarding, scoreboarding, Tomasulo algorithm이 존재한다. 하지만 여기서는 캐싱을 통한 구조적 개선만 다룬다.

캐시가 만든 새로운 문제들

그렇게 문제가 사라졌다면 좋았겠지만, 안타깝게도 멀티 코어 시스템에서는 또 다른 문제들이 발생했다. 각 CPU 코어가 데이터를 캐시에 저장하고 독립적으로 처리하다 보니, 동일한 메모리 위치에 대해 서로 다른 값을 갖는 상황이 발생했다. 이미 로드한 값을 주 메모리 참조 없이 재사용하는 것이 성능 향상의 핵심이라면, 다른 프로세서에서 주 메모리 값을 수정해야 한다면 어떻게 처리해야 할까? Write-through? Write-back? MESI 프로토콜은 또 뭐지? 또 여러 CPU가 동일한 메모리 위치를 어떻게 일관되게 접근할 수 있을까? 강한 메모리 모델과 캐시 무효화 알림? 약한 메모리 모델? 분명 x86 아키텍처에서 volatile 키워드 제대로 동작했는데, 왜 ARM에서는 결과가 이상하지? Race condition? Stall? Reordering? Operand Forwarding? ... ~~소프트웨어 개발은 언제 하지?~~ 하지만 이러한 하드웨어 수준의 문제를 소프트웨어 개발자가 매번 신경 써야 한다면, 개발의 복잡도는 감당할 수 없는 수준이 된다. 이러한 문제를 해결하기 위해 하드웨어 수준의 문제들이 소프트웨어로 전파되지 않도록 고안된 추상화 계층, 자바 메모리 모델(JMM)이 등장했다.

자바 메모리 모델(JMM)

JMM은 복잡한 하드웨어 현실과 소프트웨어 세계를 격리시키기 위해 프로그래밍 모델로 추상화된 규약이다. 그러니까 JVM이 준수해야 하는 일종의 표준 계약(요구사항)인 셈이다. JSR-133을 보면 가시성(visibility), 원자성(atomicity), 순서 매기기(ordering) 등의 용어들과 synchronized, volatile, final과 같은 키워드들의 의미를 'happens-before' 관계를 중심으로 표준화했다. 실제로 문제를 해결하는 주체는 JVM 구현체이지만, 그 어떤 JVM도 JMM의 premise를 어길 수 없다는 사실은 이해하는 것은 스레드 간 공유 상태의 격리 수준을 최소화하는데 중요하다. 예를 들면, synchronized는 상호 배제와 happens-before 동시에 보장하는데, 대부분의 경우 이는 필요 이상의 과도한 오버헤드를 발생시킨다. 가령, boolean형 클래스 변수의 할당 연산을 동기화한다면 가시성만 보장하는 volatile의 사용을 고려해볼 수 있다. 즉, JMM에 대한 이해는 정확성과 성능 사이의 균형점을 찾기 위한 기초 지식이다. JVM 구현체는 하드웨어와의 접점에서 JMM을 준수하도록 설계되어 있고, 개발자는 이를 활용하여 정교한 동시성 설계와 최적화를 구현할 수 있다.

JSR-133: JMM은 주어진 프로그램의 실행 트레이스가 해당 프로그램 기준에서 '적법'한지 판별한다.

하드웨어의 구조적 특징이 동시성 프로그래밍에서 어떤 문제를 야기할 수 있는지 이해해야 한다. JMM이 도입된 이유에 공감하고, 'happens-before' 기반의 premise를 이해한다면 보다 깊이 있는 최적화가 가능해진다.

JSR-133: JavaTM Memory Model and Thread Specification

The JSR-133 Cookbook for Compiler Writers

Close Encounters of The Java Memory Model Kind

4. 마치며...

현대의 자바 개발자들은 거대한 추상화의 혜택 위에 있다. 너무 익숙해져서 그 사실을 간과하고 있는 걸지도 모른다. 분명 성능 최적화는 첨단의 영역이지만, 그 내공은 컴퓨터 과학의 기본기에서 나온다는 것을 잊어서는 안 되겠다. 또 하드웨어를 포함한 소프트웨어의 실행 환경을 이해하는 것이 개발자에게 얼마나 큰 지평을 열어주는지 새삼 체감하게 된 시간이었다.

이렇듯 담고 있는 내용도 좋았지만, 이 책의 구성과 표현도 흥미로웠다. Java가 어떤 문제를 어떻게 해결해왔는지, 그 흐름을 쉽게 따라갈 수 있도록 도와준다. 서로 다른 영역의 내용들이 '성능 최적화'라는 주제를 중심으로 유기적으로 연결되어 있었고, 서사에 부여된 연역적인 연속성이 흥미를 돋워 처음 읽었을 때와 반복해서 읽었을 때의 느낌이 달라 정말 재밌었다.

이외에는 책이 컬러로 인쇄되어 코드를 포함하여 책의 가독성이 매우 좋고, 각주로 포함된 링크도 많아 깊게 파고들기 수월했다. 이 책의 단점은 가끔 오역인 것 같은 부분이 있다는 점 ─ 가령, CPU에서 다음 클럭에 데이터가 로드되지 않았으면 stall 상태가 되는데, 이를 유휴 상태로 표현하는 것은 적절하지 않은 것 같다. ─ 그리고 잘 읽다보면 책에 오타가 꽤 많고, 어떤 링크들은 접속할 수 없다는 점이다.

마지막으로 다시 한 번 강조하지만 이 책이 내용은 어려워도, 신기하게 정말 쉽게 읽힌다. 경력 관계 없이 자바 개발자라면 반드시 읽는 것을 추천한다.

* 이 책 외에도 다음과 같은 레드햇 자료들을 참고하면 더 많은 인사이트를 얻을 수 있다.

All things Java | Red Hat Developer

Create Java applications for anything and everything with Red Hat’s runtimes and frameworks

developers.redhat.com

Enterprise Java | Red Hat Developer

Skip the noise that can come with developing apps

developers.redhat.com

업사이드 2기 성과 공유회 후기

ooMia — Sat, 21 Jun 2025 01:01:03 +0900

6월 12일 목요일 오후 2시, 서울 강남 빅플레이스에서 업사이드 2기 성과 공유회가 진행되었다. 평소에 2기 업사이더 분들께서 어떤 프로젝트를 진행하셨을까 정말 궁금했는데, 이번 기회로 궁금증을 해소할 수 있어서 좋았다. 처음에는 현장 사진도 간간히 찍었는데, 발표가 시작된 이후에는 경청하며 발표 내용을 필기하다보니 나중에는 사진 생각을 못하고 발표만 계속 듣게 되었다 그래서 자칫하면 텍스트만 있는, 지루한 후기가 될 수도 있었지만, 정말 감사하게도 업사이드 운영진 분들께서 고품질의 현장 스틸컷을 제공해주셨다!! 덕분에 발표가 어떠했는지에 대한 회고 외에도, 보유한 사진들을 최대한 활용해서 당시의 분위기와 열기가 어떠했는지 작성해보려 한다.

행사 시작 전

30분 일찍 행사장에 도착해서 낯익은 분들께 가벼운 인사를 건내고, 자리에서 일어나 잠시 주변을 둘러봤다. 가장 먼저 눈에 띈 것은 넓어진 공간이었다. 1기 성과공유회에 비해 2배 이상의 크기였다. 당시 행사장이 좁아서 아쉽다는 이야기들이 있었는데, 이번에는 정말 쾌적하고 좋았다. 그 다음 눈에 들어온 것은 2기 성과공유회의 슬로건 `The Final Step, The First Leap`. 꽤나 익숙한 의미의 메세지이다. 업사이드 1기를 수료하면서도 멘토님들께서 강조하셨던 `끝이 아니라 새로운 시작`의 의미라는 생각이 들었다. 행사장 뒷편에는 각 업사이더들의 간단한 소개와 팀별 주제, 그리고 다과가 준비되어 있었다. (마카롱 있는 줄 알았으면 먹었는데!!! )

업사이드 2기 성과공유회 - 행사 30분 전

행사 시작

업사이드 아카데미 2기 영상이 재생되고 난 뒤, 유미라 아나운서님의 반가운 목소리로 행사가 시작되었다. 1기 성과공유회의 진행을 맡아주셨는데, 이번에도 원활하고 멋진 진행으로 행사를 이끌어주셨다. 사진은 없지만 다양한 기업의 CISO 분들도 참석하여 자리를 빛내주셨다.

유미라 아나운서님의 진행

이후 티오리 멘토 은성님, 베로님의 편지 낭독(?) 시간이 있었다. 두 분 다 분위기를 풀어주시고자 아내 외에 써본적 없는 손편지임을 강조했지만, 그 소회가 편지에서 넘쳐 흘러 내게도 전달이 되었다. 특히 정말 열과 성을 다해 과정에 몰입했을 2기 업사이더 분들과 멘토님께는 만감이 교차하는 시간이었으리라 생각한다.

티오리 멘토님들 - Eunseong, vero

프로젝트 발표

고대하던 발표 시간이 왔다. UMA, 베어문, chain stalker, Stack Audit Flow. 각양각색 4팀의 발표가 시작되었다. 1기 때와 마찬가지로 audit 두 팀 그리고 tooling 두 팀으로 나누어져 있었다.

프로젝트 발표

1. UMA 계정 추상화

1기 때에도 계정 추상화를 기반으로 감사를 진행한 팀이 있었는데 2기에도 있었다. 그리고 공교롭게도 두 팀 모두 우수상을 수상했는데, 아마 그만큼 최근 관심도도 높고 중요한 문제이기 때문에 그렇지 않나 싶다. 이번에 filler라는 역할이 있는 것은 처음 알았는데, 찾아보니 ERC-4337이 아닌 ERC-7683 Cross Chain Intents에 존재하는 것임을 확인했다. 쉽게 말하면 정부가 프로젝트 내용을 공개하면, 기업들이 경쟁 PT를 통해 프로젝트를 수주하는 것과 비슷하다. filler들은 사용자의 의도를 만족시키는 연산을 수행하는 대신 그에 대한 보상을 얻게 되는데, Web3 생태계를 보면 대리자의 개념이 정말 많이 활용되는 것 같다. 물론 이에 따른 위협도 존재한다. UMA 팀이 소개한 위협 시나리오 중에 기억이 나는 건 공격자가 번들러의 역할을 담당하고, 유저의 연산 일부를 탈취해서 의도적으로 트랜잭션을 실패시키는 경우이다. 간단하게 음식점 비유를 들어보자.

지금 시간 오후 10:02분. 갑자기 야식이 먹고 싶어서 배달 앱을 키고 주문하는 상황이다. 이 배달 앱은 구조가 다소 독특하다. 일단 배달 요청이 들어오면 라이더들에게 공개적으로 배달 권한을 입찰한다. 이 때, 라이더가 배달을 담당하려면 주문 금액과 동일한 액수의 담보금이 필요한데, 정해진 시간 안에 배달하지 못하면 담보금이 청산되어 배달 앱에 전달된다. 따라서 각 라이더들은 자신의 위치와 배달 동선 등 여러 가지를 고려해서 신중하게 배달을 담당하게 된다.

이런 상황에서 만약 배달 앱의 관리자가 어떤 라이더에게 악의를 갖고 있다면 어떻게 될까? 사용자 A가 배달 앱으로 치킨과 족발을 주문했고, 라이더 B는 배달을 담당하기 위해 5만원을 담보로 맡겼다. 이 때, 관리자는 치킨 요리점 위치를 파악하고, 앞에 난동꾼을 배치해서 라이더가 음식을 수령하지 못하도록 방해한다. 사용자의 요청은 단순히 실패한 것이지만, 라이더는 5만원 손해, 그리고 악의적인 공격자인 배달 앱은 5만원의 이익을 보게 된다.

발표에서 소개한 UserOp Hijacking 시나리오에 따라 라이더=filler, 배달 앱=bundler에 비유했는데, 사실 Web3 환경과 실제 배달 과정은 다른 부분이 많아 다소 억지스러운 부분이 있긴 하다. 그래서 실제로는 bundler가 난동꾼이라는 실체를 사용하지 않고도, 어떻게 사용자의 요청이 실패하도록 할 수 있는지 궁금하다면 UMA 팀의 깃북 문서를 참고하길 바란다. (nonce & front-running)

AA + Cross-chain DOCS | AA + Cross-chain DOCS

Modular Smart Accounts & Cross-Chain Security Guide

aacross.gitbook.io

2. 베어문 PoL 기반 체인

기존 PoS 방식의 지분 증명 체인의 유동성 파편화 문제를 해소하기 위한 여러 시도가 있었고, BeraChain은 PoL(Proof of Liquidity) 방식의 문제 해결을 시도하고 있다. 베어문 팀은 이 체인의 구조에 대한 설명과 감사를 진행한 결과를 공유했다.

일단 내가 이해하기로는 일반 Native Token을 예치하는 것이 두 합의 매커니즘의 공통 전제이다. PoS는 그 상태에서 머물기 때문에, 예치된 ETH를 활용할 수 없으니 체인 내 유동성이 파편화되는 문제가 있지만, PoL의 경우 유동성 토큰과 거버넌스 토큰을 발급하는 것으로 합의 방식을 충족하면서도 체인 내 유동성 파편화를 완화할 수 있다. 솔직히 엄청나게 새로운 방법은 아니라 생각한다. 가장 먼저 re-staking 등 프로토콜 수준에서 파생 토큰을 발급하는 Pendle이 떠올랐는데, 이 밖에도 EigenLayer, Polkadot, UniswapX 등 다양한 프로토콜과 체인들이 이미 유사한 문제를 다양한 방식으로 해결하려 하고 있다.

기억나는 위협은 크게 두 가지인데, 하나는 0.13퍼센트의 주소가 90퍼센트 이상의 유동성을 보유하고 있어서 담합하면 거버넌스 조작이 발생할 수 있다는 것과, 가격이 오라클에 의해 관리되지 않고 토큰 비율에 의해 결정되어 가격 조작에 매우 취약하여 대량 청산을 유발할 수 있고, ERC-4626 취약점에 의해 공격자가 전체 지분을 쉽게 차지할 수 있다는 것이다. 베어문 팀은 이에 인플레이션 급등을 감지하고, 급격한 담보 가치 하락에 대응하는 서킷 브레이커 도입을 대안으로 제시했다. 솔직히 근본적인 해결책은 아니라고 생각하지만, 구조적인 문제는 해결하는 것이 어려울 수 있으니 꽤나 실용적인 방안이라고 생각이 들었다. 앞서 다룬 내용이 정확하지 않을 수 있으니 자세한 내용은 다음 깃북을 참조하길 바란다.

Introduction | BearMoon

Introduction This document identifies potential security threats in Berachain's Proof of Liquidity (PoL) system and presents practical guidelines to prevent them. The Berachain ecosystem introduces a new economic model through its PoL mechanism, but it can

bearmoon.gitbook.io

3. ChainStalker 자금 세탁 추적

꽤나 이해하기 쉬웠다. KYC 없이 운영되는 무기한 선물 거래소를 통해 불법 자금이 세탁되는 정황들이 있는데, 합리적인 가정을 통해 자금 세탁으로 추정되는 트랜잭션을 필터링하겠다는 컨셉이다. 첫 번째 가정은 동일한 거래소에서 동일 시점에 동일한 액수의 반대 포지션을 잡는다는 것이다. 솔직히 동일 거래소는 중요한 가정은 아니라 생각하지만, 당장 바로 모든 거래소의 데이터를 추적하는 것도 비현실적이라 생각해서 어느 정도 납득했다. 두 번째 가정은 높은 비율의 레버리지를 사용한다는 것이다. 돈 세탁의 액수는 규모가 크기 때문에 꽤나 합리적이라고 생각했다. 마지막으로 중앙 거래소의 출금 여부이다. 중앙 거래소 출금 여부는 단순히 해당 주소의 직접 출금 여부만을 고려했을 줄 알았는데, 다른 주소로의 송금까지 고려하여 최종 출금 여부를 파악했다고 했다. 하이퍼리퀴드가 정확히 어떻게 동작하는지는 잘 모르겠지만, 크로스체인까지 고려하면 추적하는 게 어려울텐데 대단하다. 위의 세 가정을 만족하는 트랜잭션을 추적하고 -50% 이상의 큰 손실이 발생했는지, 남아있는 별도의 포지션이 있으면 헤징으로 간주하는 등 고민을 많이 한 흔적이 보였다.

심사위원 분들께서 남겨주신 심사평도 좋았는데, 우선 bpak 멘토님은 현재 1:1로 반대 포지션을 추적하고 있지만, 사실 1:1/n * n 포지션으로도 가능하지 않냐고 질문을 하셨다. 맞는 말인게 더 나아가면 주소별 가중치를 둘 수도 있고, 여러 거래소를 사용할 수도 있을 것이고, 두 반대 포지션의 합에 작은 오차를 둘 수도 있을 것이다. 솔직히 너무 많은 경우의 수가 남아있지만, 그럼에도 한 걸음 나아갔다는 것만으로 의미가 있다고 생각한다. 다른 심사위원 분들께서도 '기준이 되는 수치를 변경할 수 있어야 도구로서의 의미가 있을 것이다', '굉장히 많은 금융 공학자들이 도전하게될 과제이다'라며 많은 관심을 보이셨다. 그 결과인지는 모르겠지만, 툴링 부문에서는 체인 스토커 팀이 우수상을 수상하게 되었다.

Perp DEX를 통한 자금 세탁 효용성 검증 | ChainStalker Docs

A Study on the Effectiveness of Money Laundering through PerpDEX - by ChainStalker™️

chainstalker.gitbook.io

4. Stack Audit Flow 스마트 컨트랙트 AI 감사

컨셉은 `LLM을 활용한 스마트 컨트랙트 감사`. 이걸 audit을 업으로 삼고 있는 일부 심사위원 분들께서는 밥줄을 위협하는 프로젝트라는 식으로 농담을 하셨던 기억이 난다. (과연 농담일까? ) 개인적으로 어떤 모델을 사용했는지, 또 어떻게 학습시키고 튜닝했는지가 제일 궁금했는데, 이런 부분이 발표에서 드러나지 않아 너무 아쉬웠다...

발표에서 고민을 많이 한 흔적은 드러났다. 이 모델의 성능을 측정하기 위해 분석할 프로토콜이 학습된 상태인지 확인했고, zellic과 같은 감사 전문 업체의 리포트와의 유사도를 비교했다고 한다. 또 대부분의 결과가 `만약 ~하다면 ~한 위협이 있다`는 식이었다고 하니, 온체인 데이터를 참조할 수 있다면 오탐율을 줄일 수 있다고 한다. 또 작업했던 프로토콜의 감사 결과가 약 100여개 였는데, 발견된 77개의 예상 위협을 검증하는데 시간이 걸렸다고 한다. 이 부분은 PoC 생성 자동화가 실현된다면 체인을 테스트넷으로 fork한 이후 테스트해보는 것으로 단축할 수 있을 것이라 한다.

여기까지 듣고, `zellic 레포트랑 유사도가 높다고? 대단한데?` 생각했는데 bpak 멘토님께서 날카로운 멘트를 몇 개 던지셨다. 일단, 사후 검증에 소요되는 시간이 길다면 도구로서의 의의가 있는지(배보다 배꼽이 크다 뭐 그런 느낌), 그리고 감사 작업에는 오탐보다 크리티컬한 위협에 대한 미탐이 더 문제가 된다는 이야기. 맞는 말이긴 하지만 나는 이 역시도 시작했다는 것 자체만으로 충분히 의의가 있다고 본다. 애초에 다양한 감사 업체에서 문제 없다고 리포트를 남긴 프로토콜도 취약점이 발견되어 피해가 생기는 경우가 있다. 설령 AI가 현재 인간에 비해 부족하더라도, 무한한 잠재력을 가진 이 분야를 굳이 도외시 할 이유는 없지 않을까? 따라서 당장 실용화는 어렵겠지만 멋진 도전이라고 생각한다

모두들 발표에 경청하는 분위기였다

발표 이후

각 팀에 대한 심사평, 그리고 수상 팀이 발표되었다. bpak 티오리 대표님의 축사도 있었고, 업사이더 2기 분들의 가슴 따뜻한 후기 나눔도 있었다. 게임 개발자에서 합류한 TamaNeko님의 후기를 듣다보니, 마치 내 얘기 같아서 몰입이 됐다. 얼마나 힘드셨나요.. 고생 많으셨어요

나는 개인적인 사정이 있어 먼저 자리를 떴지만, 행사 후에는 멘토분들과 1기 업사이더들과의 네트워킹 시간이 있었다고 한다. 끝이 아닌 새로운 시작을 준비하는 2기 업사이더 분들께는 소중한 시간이 되지 않았을까 싶다.

마치며...

문득 Toss 관계자 분의 코멘트가 생각난다. "4~5명이 모여 2개월 간 작업한 결과물이라는 것을 알고 놀랐다." 비단 업사이더들만의 작품이 아니라 멘토님들의 도움이 있었기에 가능했던 것이라 생각한다. 앞으로 얼마나 더 멋진 결과물이 탄생할지 기대가 된다. 함께하는 것의 힘을 아는 것, 그것이 업사이더니까.

2025년 1회 정보처리기사 합격 후기

ooMia — Sat, 14 Jun 2025 15:14:23 +0900

정처기 필기는 누구든 쉽게 통과하는 것으로 알고 있다. 실기는 비교적 난이도가 높은 것으로 알려져 있지만, 이 역시도 비전공자들의 지원 비율을 감안하면 전공자들에게는 결코 높은 수준은 아니라 생각한다. 물론 2025년 1회차 실기 시험은 합격률 약 15%의 역대 두 번째로 어려운 시험이었다. 하지만 계산기를 가진 개발자라면 누구나 쉽게 통과할 수 있었을거라 생각한다.

실기는 60점 이상이면 합격이다

틀린 20점 중 15점은 아마 간단한 용어 문제에서 틀린 것으로 추정하고 있다. 알면 맞추고 모르면 틀려야 하는 이런 유형의 문제들을 확실히 일주일 준비로는 모든 이론을 커버하는 것은 쉽지 않았던 것 같다. 혹자는 강의를 결제하거나 학원에 등록하여 준비하는 경우도 있겠지만, 나는 정처기를 준비하기 위해 돈을 쓰는게 아깝다고 생각해서 최대한 돈을 아꼈다.

준비 방법

기본적인 이론 정리는 이전에 중고로 구매한 시나공 실기 책과 유튜브 등에 공개된 정처기 강의들을 활용했다. 이외에 헷갈리는 개념 ㅡ 제3정규화의 이행적 종속은 식별자 외의 컬럼에만 해당된다든지의 내용은 NCS 모듈이나 영문 wiki 등의 공개된 정보를 활용했다. 책을 공부할 때는 마크다운으로 개념을 함께 정리했다. 코드 해석 외에 네트워크, 스케줄링 등 다양한 영역에서 나름의 계산이 필요한 문제들이 있는데, 문제 풀이 경험이 있는 개념들은 문제를 풀 때 사용한 방법도 함께 정리했다.

마크다운으로 정리하며 공부한 이론

SQL은 기본적인 수준에서 나올 것이라 생각해서, 스크립트를 작성해서 LLM이 생성한 문제를 반복 수행했다. 문제를 해결한 이후에 답변에 의문이 들면 OneCompiler 활용해서 테스트로 검증했는데, 간단한 문제여서 그런지 생각보다 정확도가 놀라서 깜짝 놀랐다. 비록 실제 시험에서는 정말 기본적인 내용만 나와서 큰 도움이 되지 않았지만, 다른 분야에도 적용해볼 수 있을 것 같다는 생각이 들었다.

SQL 문제 생성 스크립트 / 오답노트

뉴비티 문제은행으로 기출을 돌려 풀었다

이후에는 기출문제를 계속 돌렸다. 기출에 실질적으로 투자한 기간은 4일 정도 되는 것 같다. 4일 치고는 푼 문제가 그렇게 많지는 않은데, 뉴비티에는 기출 문제가 정확하게 복원되지 않은 경우도 있어서, 실기 책의 기출문제와 공개 배포된 예상 기출문제 등을 구해서 풀었다.

뉴비티 시험 후기 댓글

코드 결과를 추적하는 문제는 주어진 자신만의 풀이 요령을 갖는 것이 중요하다. 물론 컴퓨터는 프로그램 카운터(PC)를 기준으로 한 줄 또는 하나의 명령씩 실행하지만, 인간에게는 적합하지 않은 방법이다. 그 대신 프로그램 전역의 상태를 자료구조 또는 코드 실행 구조를 중심으로 시각화하는 방식을 추천한다. 1회를 기준으로 출제 기조가 유지된다면, 지엽적인 개념 대신 해당 프로그램의 핵심 개념과 실행 흐름 추적 능력을 평가할 가능성이 높다. 가령, Python에서 boolean 값은 파스칼 케이스로 출력된다든지의 사소한 부분보다는 Java의 this, super 등 객체지향적인 개념을 평가할 가능성이 높다. (~~정보처리기사가 정상화되고 있다~~)

마치며

정처기 커뮤니티에서는 15%의 합격률, 역대급 난이도다, 이전 취득자와 구분해야 한다 등의 다양한 의견이 있지만, 어디까지나 기본적인 소양을 증명하는 자격증 정도지 이 자격증이 실무 역량을 증명할 수는 없다고 생각한다. 그래서 개인적으로는 자격증을 취득하기 위한 준비보다는, 이 과정을 통해 다양한 이론들을 접하고 지식을 확장하는 기회로 활용했으면 한다.

학부 시절의 공부는 시험을 위한 공부였기에 실제 코드에 잘 녹여내지 못했는데, 이번에 이론을 공부하면서는 실제로 시스템을 어떻게 설계하고, 코드를 어떻게 구현하고, 프로젝트를 어떻게 관리해야할지 고민하면서 진짜 공부를 했다. 물론 내가 비교적 익숙했던 이론들을 복습하는 입장이었기 때문에 이런 여유가 가능했겠지만, 가능하면 앞으로 다른 자격증을 취득할 때에도 진짜 공부를 지향해야겠다.

업사이드 수료생 후기 및 지원 팁

ooMia — Sun, 1 Jun 2025 02:03:13 +0900

업사이드 아카데미 OT

오늘 OT는 6월 13일 한 통의 이메일로부터 시작됐다. 습도가 높은, 다소 더운 날이었지만 혹시라도 늦을까봐 1시간 일찍 출발했다.(너무 도착한 탓에 오히려 카페에서 기다렸지만 후회하지는 않

spems.tistory.com

업사이드 1기의 시작은 정확히 작년 이맘 때였다.

Web3는 당시 내게 미지의 영역이었고, 설렘 반 긴장 반으로 과정을 시작했던 기억이 난다.

지난 1년을 돌아보며 업사이드가 내게 어떤 영향을 미쳤는지 후기를 남긴다.

업사이드 수료생 후기

난 정말 운이 좋았다. 운좋게도 보안 분야의 대단한 능력자들에게 가르침을 받고, 또 함께 교육을 받을 수 있었다. 그리고 다른 유능한 사람들에 비해 내 능력이 너무 부족했다는 생각도 든다. 내가 좀 더 준비된 상태였다면 더 많은 것들을 배우고, 나누고, 또 더 좋은 결과로 수료할 수 있었을텐데 하는 후회도 남는다.

그러나 교육 기간동안 많이 성장한 것도 사실이다. 작년 그 몰입의 시간은 아직도 생생하게 기억난다. 난 어떻게든 스스로 해결하기 위해 몸부림쳤고, 고생 끝에 문제를 해결한 성공 경험들은 힘든 일정 속에서도 늘 배움의 기쁨을 느낄 수 있도록 활기를 불어넣어줬다. 내가 궁금했던 부분들을 명쾌하게 설명해주신 멘토님들께도 감사했고, 함께 의견을 주고받은 교육생들과의 대화도 좋았다. 그리고 스스로 성장하고자 노력했던 내 자신도 대견했다.

많은 성장을 경험했지만 내 커리어의 이정표는 아직 개발자를 향해 있다. 업은 재미로 결정하는 것이 아니지만, 그렇다고 내가 다른 사람들에 비해 뛰어난 역량을 가지고 있는 것도 아니었으니까. 그리고 보안을 전문으로 하는 사람이 있다면, 개발에 보안을 얹은 사람도 있을 수 있지 않은가 보안 역량을 가진 개발자. 그게 내가 올해 나아가고자 하는 방향성이다.

아, 추가로 이번에 업사이드 3기 모집이 시작되었는데, 보다 진솔한 이야기를 원하는 사람들이 있을 것 같다. 그래서 이참에 지원자들을 위한 팁을 간단히 정리해보려 한다.

업사이드 아카데미 지원 팁

1. 'Web3 사이버보안'

3기의 정체성은 위의 단어로 정의된다. Web3에 관심이 없거나, 사이버 보안에 관심이 없으면 지원을 고민해볼 필요가 있다. 왜냐하면 다른 지원자들은 이미 저 둘에 미쳐있을테니까. 이번 기회를 통해 진심으로 새롭게 도전해보고 싶다면 드림핵을 통해 스스로의 역량을 평가해보는 것을 추천한다. 최소한 비기너 수준의 문제들은 모두 해결할 수 있어야 한다. 드림핵 내에서 자체적인 강의도 제공하니 적극적으로 활용해보자.

해커들의 놀이터, Dreamhack

해킹과 보안에 대한 공부를 하고 싶은 학생, 안전한 코드를 작성하고 싶은 개발자, 보안 지식과 실력을 업그레이드 시키고 싶은 보안 전문가까지 함께 공부하고 연습하며 지식을 나누고 실력 향

dreamhack.io

2. 'Ethereum'

정규 교육 과정은 Ethereum / Solidity 중심으로 진행된다. 물론 멘토님들 중에는 Ethers.rs처럼 Rust 기반 컨트랙트 작성이 가능하신 분도 계시고, Solana 또는 XRP Ledger와 같은 다양한 블록체인 네트워크를 전문적으로 다루시는 분도 계신다. 다들 경험이 매우 풍부하시기 때문에, 왠만한 궁금증은 쉽게 해소할 수 있다. 어디까지나 교육 핵심은 Solidity라는 거. 적어도 1기는 그랬다. 이 부분은 rare-skills의 포스트와 Solidity 교육 컨텐츠를 참고하면 좋을 것 같다. 시간이 된다면 암호학도 Module 1: Foundational Math까지는 학습하는 것을 추천한다.

이외에도 https://www.rareskills.io/blog 를 참고하면 다양한 참고 자료들이 많다.

3. 서류 준비

모두 자신만의 이야기를 쓰면 되지 않을까? 내 경우에는 정말 경험한 그대로 솔직하게 작성했던 것 같다. 나는 보안과 Web3에 대한 경험이 전무한 상태였는데, 단순히 부족함을 드러내는 것에 그치지 않고, 조사를 통해 이 기술이 무엇이고, 왜 관심을 가지게 되었으며, 현재 어떤 부분에서 지식이 부족한데 남은 기간 동안 어떤 방식으로 채워나가고, 본 과정을 통해서 무엇을 달성하고 싶다고 작성했던 것 같다.

4. 실기 시험 준비

문제 난이도는 입문 수준부터 고난이도까지 모두 출제되니, 본인의 실력에 맞게 준비하는 것이 제일 좋다. 적어도 쉬운 문제는 맞추는 것이 좋으니, 1번에서 강조했던 것처럼 드림핵의 입문 단계의 문제, 그리고 드림핵 강의에서 다루는 수준까지는 모두 풀어보는 것을 추천한다. 또 드림핵에는 기본적인 문제가 다양하지 않으니, Web3 분야 문제의 대비를 위해 ethernaut , node guardians 그리고 드림핵 순서로 문제를 풀어보는 것을 추천한다. 1기 실기의 Web3 문제는 드림핵의 출제 형식과 동일하게 출제되었으니, 문제 풀이 플로우에 익숙해지기 위한 수준으로 연습하면 충분하다고 생각한다.

5. 면접 준비

면접의 시작은 간단한 자기소개, 그리고 이후에는 초기에 작성했던 지원서의 내용을 바탕으로 면접관 분들이 궁금한 점을 그 자리에서 질문하며 시작된 것으로 기억한다. 따라서, 지원서 제출 전에 자신의 지원서 내용을 미리 저장해두는 편이 좋다고 본다. 이후에는 실기 시험에서 해결한 문제를 보며 어떻게 해결했는지 설명하거나, 또는 컴퓨터 과학 개념 질문으로 기술 면접을 진행할 수 있다. 내 경우에는 당시 3:3 면접이었고 면접 분위기는 매우 좋았다. 대답에 부족한 점이 있는 경우에는 힌트 형태의 질문도 해주셨는데, 정해진 정답을 맞추는지 확인하기보단 지원자의 사고력을 평가하는 느낌을 받았다.

6. 공격적 보안(Offensive Security)

업사이드 아카데미는 공격적 보안의 관점에서 접근한다. 기존 해킹 사례 중 일부를 실제로 반복해보고, 해킹에 활용되는 요소가 다르게 바뀐 상황에서도 수행해보고, 또 목표 자산을 최대한 탈취하는 것을 목표로 삼기도 한다. 이 부분은 모의 해킹과 비슷하다. 해킹이 발생하면 네트워크의 트랜잭션 기록을 토대로 PoC 코드를 작성하게 되는데, DeFiHackLabs 레포에 이미 다양한 사례들이 있으니 참고하자.

7. 스마트 컨트랙트 감사(Smart Contract Audit)

일정 수준 보안 지식이 쌓였다고 생각하면, 스마트 컨트랙트 감사를 진행하여 보고서를 작성해보는 연습을 하면 큰 도움이 될 것이다. 식별한 위험 요소를 어느 정도로 확신할 수 있는지, 또 이 위험은 얼마나 심각한지를 구분해보고, 자신만의 보고서 템플릿을 만들어보거나, 위협 모델링 등 보안 프레임워크에 대한 학습을 진행하면서 감사 절차 및 계획에 대한 청사진을 준비해보는 연습도 좋다.

마치며...

이전에 참고했던 자료들이라 최신 트렌드를 따라가는 데에는 적합하지 않을 수 있어요. 그래도 이번 과정을 통해 새로운 도전을 시작하시는 분들께는 도움이 되리라 생각합니다! 감사하게도 2기 교육생분들도 블로그가 도움이 되었다고 말씀해주셨어요. 3기를 준비하는 지원자분들께도 이런 작은 팁들이 앞으로의 방향성에 도움이 되었으면 하고, 보다 더 빠르고 높이 성장하시길 바라겠습니다

[서평] 멀티패러다임 프로그래밍

ooMia — Sat, 31 May 2025 23:48:41 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

멀티패러다임 프로그래밍 / 유인동 지음 / 한빛미디어

함수형 프로그래밍에 대한 인식을 바꾼 책

평소에 함수형 프로그래밍을 적극적으로 사용하는 편은 아니다. 보통 Java Collection 클래스에 대한 후처리가 필요할 때 사용하는데, 예를 들어, 응답으로 객체 배열이 들어왔을 때, 유효한 객체만 응답으로 받기 위해 filter를 사용하거나, 일괄적인 변경이 필요할 때 map을 사용하는 수준이다. 이번에 책을 읽고 난 뒤에는 생각이 바뀌었다.

우선은 비동기 처리의 필요성이다. 많은 시간이 소요되는 어떤 작업이 있다. 이 작업은 CPU 집약적이지 않고, 네트워크 통신 또는 파일 처리 등의 이유로 지연이 생기기 때문에 느리다. 이런 작업들은 동기적으로 진행하면 비효율적이다. 마치 음식점에서 여러 음식을 주문할 때, 한 음식이 조리되어 식탁에 올려졌을 때 비로소 다음 음식을 주문하는 것과 동일하다. 처음에 한 번에 주문하고 나오는대로 맛있게 먹으면 될텐데 말이다.

async function orderFoodAsync() {
  console.log("음식점 도착 - 한번에 모든 음식 주문");

  // 모든 음식을 동시에 주문
  const steakPromise = cookFood("스테이크");
  const pastaPromise = cookFood("파스타");
  const saladPromise = cookFood("샐러드");

  steakPromise.then((food) => console.log("잘라먹기:", food));
  pastaPromise.then((food) => console.log("말아먹기:", food));
  saladPromise.then((food) => console.log("찍어먹기:", food));

  await Promise.all([steakPromise, pastaPromise, saladPromise]);
}

그 다음은 일급 함수의 역할이다. 일급 함수는 함수를 인자로 전달받을 수 있기 때문에, 매우 유연한 처리가 가능하다. 예를 들어, 음식점에서는 주문 받은 메뉴에 따라 조리법과 플레이팅 방식이 다르다. 하지만 요리를 조리하고, 접시에 올려서, 서빙한다는 순서는 동일하다. 일급 함수는 메뉴에 따라 다른 동작을 수행하는 함수를 전달받고, 일정한 순서에 따라 서빙까지의 절차를 일관되게 표현할 수 있다.

// 일급 함수를 활용한 일관된 서비스 로직
function order(dishName, ingredients, cookingFunction, platingFunction) {
  console.log(`--- ${dishName} 요리 시작 ---`);
  const cookedDish = cookingFunction(ingredients); // 1. 조리
  const platedDish = platingFunction(cookedDish); // 2. 플레이팅
  return platedDish; // 3. 서빙
}

그 다음은 순수 함수다. 순수 함수는 비동기 처리에 유용하게 활용할 수 있다. 순수 함수는 부수 효과(side-effect)를 발생시키지 않고, 동일한 입력에 항상 동일한 결과를 반환한다. 이러한 특징으로 인해 thread-safe한 상태를 유지하고, 예측 가능성 뿐만 아니라 성능 최적화를 위해 활용된다. 마치 학교 게시판에 공모전 정보가 게시되었을 때, 내가 필요하다고 포스터를 가져가는게 아니라 카메라로 QR만 찍어서 지원 사이트에 방문하는 것과 같다.

마지막으로 함수형 프로그래밍은 이러한 요소들을 잘 버무린 비빔밥이라고 비유하고 싶다. 그 안에는 나열된 일련의 자료들을 효율적으로 처리하기 위한 고민들이 담겨져 있다. Iterator 패턴을 활용한 범용성, 지연 평가를 통한 메모리 효율성, 일급 함수를 활용한 확장성, 순수 함수를 활용한 병렬 처리 안정성까지. 그러니 저자가 IP, OOP, FP의 관계를 강조하는 것도 이해가 간다.

LLM의 도움을 받아 generator와 음식점 예시를 작성해보았다. Generator, 고차함수, 지연 실행, Promise와 비동기 처리 등 다양한 요소를 자연스럽게 반영하려 했지만, 코드가 어쩔 수 없이 굉장히 작위적이라는 건 부정할 수 없을 것 같다. 그래도 이런 개념을 활용해보았다는데 의의를 두고 싶다!

fp_practice

fp_practice. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

async function runRestaurant() {
  const dishes = [
    {
      name: "스테이크",
      ingredients: "등심",
      cookFn: Recipes.cookSteak,
      plateFn: Platings.fancy,
    },
    {
      name: "스테이크",
      ingredients: "등심",
      cookFn: Recipes.cookSteak,
      plateFn: Platings.fancy,
    },
    {
      name: "파스타",
      ingredients: "뇨끼",
      cookFn: Recipes.cookPasta,
      plateFn: Platings.fancy,
    },
    {
      name: "샐러드",
      ingredients: "채소",
      cookFn: Recipes.cookSalad,
      plateFn: Platings.simple,
    },
  ];

  console.log(`  총 주문 개수: ${dishes.length}개`);

  // Generator를 통한 lazy evaluation과 iteration
  const pipeline = cookingPipeline(dishes);
  const cookingTasks = [];

  // 각 조리 작업을 지연 평가로 수집
  for (const cookingTask of pipeline) {
    cookingTasks.push(cookingTask()); // 실제 실행은 여기서!
  }

  // 모든 조리 작업을 병렬로 실행
  await Promise.all(cookingTasks);

  console.log("  모든 음식이 서빙되었습니다. 맛있게 드세요!");
  console.log("  계산을 진행하고 퇴장합니다");

  return "서비스 완료";
}

심도 있는 고찰과 이론과 실무를 넘나드는 꿀팁

몇 가지 내용만 간단히 소개하자면, 먼저 비동기 에러 핸들링에 대한 팁이 도움이 됐다. 순수 함수는 부수 효과를 가지지 않는 것이 핵심이므로 발생한 에러는 상위 호출자에게 위임하는 것이 좋고, 에러 핸들링 코드는 네트워크 요청, 파일 입출력, 데이터베이스 쿼리와 같이 부수 효과 발생 코드 근처에 작성하는 것이 좋다. 리스트 프로세싱 패턴화도 도움이 되었다. 변형-누적 패턴(map-reduce), 중첩-변형 패턴(nested-map) 등 자연스럽게 사용하지만 이렇게 정리해보니 필요할 때 어떤 패턴을 사용해야할지 정리할 수 있어서 좋은 것 같다. 그리고 리스트 프로세싱 함수 유형별 개념 정리도 패턴화와 연계해서 매우 유용하게 사용 가능하다. 지연 중간 연산에는 map, filter, zip, 터미널 연산에는 find, every, some, reduce 등 특정한 패턴을 사용하고자 할 때, 함수의 목록을 바로 참고할 수 있다. 이 부분은 저자의 GitHub 소스의 예제를 참고하면 더 많은 것을 배울 수 있다.

GitHub - marpple/multi-paradigm-programming: Multi-Paradigm Programming: Combining Object-Oriented, Functional, and Imperative A

Multi-Paradigm Programming: Combining Object-Oriented, Functional, and Imperative Approaches for Software Development and Design - marpple/multi-paradigm-programming

github.com

⚠️ 프론트엔드 예시와 FxTs 라이브러리 사용

물론 백엔드 개발자도 참고할만한 내용이 있지만, 기본적으로 타입스크립트를 사용하는 프론트엔드 개발자가 얻어가는 것이 가장 많은 책이다. 그리고 일부 예시로 FxTs 라이브러리를 활용하는 경우가 나온다. 따라서, Native JavaScript만으로 모든 것을 설명하지는 않는 점을 알아두면 좋다.

마치며

솔직히 후반부는 내용이 잘 읽히지 않았다. 변명하자면 코드가 여러 곳에 산재되어 있어서, 나처럼 프론트엔드 경험이 부족하다면 진득하게 정독해야만 제대로 이해할 수 있을 것 같다. 그리고 책이 확실히 깊이가 있다. 읽으면 읽을수록 놓쳤던 내용들이 보여서 신기했다. 언젠가는 이 책에 있는 내용들을 모두 이해할 수 있는 날이 왔으면 좋겠다

업사이드 아카데미 3기 모집

ooMia — Thu, 29 May 2025 14:06:21 +0900

어라? 일일 평균 조회수 30회 정도였던 내 블로그에 이런 조회수가?

아아 돌아온 것인가... 그 시즌

바로 업사이드 아카데미 3기 모집 시즌!! (두둥)

업사이드 아카데미 3기 모집

현재 지원 기한까지 약 한 달이라는 시간이 남아있다. 업사이드 아카데미는 최고 수준의 몰입을 지원하고, 또 요구하기 때문에 본인의 목표와 열정에 맞게 현명한 선택이 필요하다.

이번 포스팅을 통해 2기와 동일한 점은 무엇인지, 또 3기에서 바뀌는 점은 무엇인지 알아보고,
내가 업사이드 아카데미에 지원해도 괜찮을까 하는 고민들을 모두 해결해보자!!

업사이드 아카데미 ?

업사이드 아카데미는 국내 최초이자 국내에 유일한 Web3 사이버보안 교육 과정이다.
심지어 Web3 뿐만 아니라 Web2 영역에서도 뛰어난 역량을 가진 전문가 분들께 배울 수 있다.
멘토님들의 실력을 한 마디로 정리하자면 'DEFCON 우승'

심지어 3기부터는 Web2 영역에 대한 교육과정도 대폭 강화된다.*

...지원하지 않을 이유가?

* 참조 - 두나무, 보안 인재 양성 '업사이드 아카데미' 3기 모집

** 참고 - 업사이드 아카데미 2기 모집

그것 뿐인가요?

당연히 아니죠!!!

아카데미 1기 수료생으로서 가장 좋았던 점은 '완전한 몰입을 위한 전적인 지원'이다.

자유로운 질문이 가능한 오픈 채널
필요하다면 1:1 멘토링
프로젝트 기간 중 전담 멘토 배정
20명 소수 정예
경쟁보단 협동. 즐겁게 배울 수 있는 교육 시스템
최신 맥북프로
1인당 월 100만원 학습 지원금, 팀당 월 25만원 활동비
개인별 스터디 공간, 스낵바
대학교 학점 연계 * **

* 정보보안 전공자 한정. 고려대, 경기대, 아주대, 숭실대, 세종대 지원. 최소 9학점 최대 12학점 인정. 과정 합격 후 학과사무실에 문의
** 대학교와 학점 연계된 최초의 민간 교육 과정. UDC도 그렇고, 이쯤되면 두나무는 국내 Web3 분야의 퍼스트 무버로 인정해줘야한다

추가로 3기부터는 과정을 수료한 이후, 후속 연계 지원이 이전보다 더 강화된다.

후속 프로젝트 및 연구 지원 - 과정 수료 후에도 지속적인 프로젝트와 연구를 위한 전담 멘토배정, 학습공간 및 연구비 지원
업사이더 Alumni Community - 연말 커뮤니티 데이를 통해 구성원 간 소속감과 연대감을 강화하고 스마트보안 업계의 생태계 조성
UDC 및 닷핵컨퍼런스 참가

여러 장점이 많지만, 수료생의 입장에서 강조하고 싶은 부분은 업사이드 아카데미의 교육 시스템이다.

‍ 업사이드 아카데미의 교육

학생 시절에 게임 핵의 원리에 대해 궁금했던 적이 있었고, 대학 진학 이후, 그것이 어떻게 동작할 수 있었는지 알게 되었을 때 배움의 기쁨을 느꼈습니다. 배움의 기쁨을 누군가 만들어주는 것은 어렵다고 생각합니다. 다만, 교육생들이 그 배움의 목마름을 지니고 왔을 때, 오아시스와 같은 역할을 해주는 것이 아카데미의 역할이라고 생각합니다.

⎯ Theori 대표 박세준, 2024.11, 1기 성과공유회 QnA

교육 철학을 생각하면 박세준 대표님의 강연이 생각난다. 이외에도 혼자 성장하는 것은 제한적이니, 자신과 수준이 맞는 사람들과 팀을 이루어 성장하라는 부분도 감명깊게 들었다.

업사이드 아카데미의 교육은 전통적인 줄 세우기 방식과는 사뭇 느낌이 다르다. 이전에 하지 못했던 것을 할 수 있게 되었는지, 개인의 성장에 초점을 맞추어 교육 성과를 점검한다. 제한적인 베네핏에 대한 경쟁도 물론 존재한다. 하지만 개개인의 역량을 고려하여 팀을 구성하고, 어디까지나 팀으로서의 경쟁한다.

업사이드 성과 공유회 후기

성과 공유회는 지난 한 달 간 진행한 프로젝트의 결과물을 모두가 모인 자리에서 함께 나누는 자리이다. 그리고 이 발표의 결과로 각 분야의 팀들 중 우수 팀은 UDC 발표 기회를 얻게 된다. 아쉽

spems.tistory.com

가장 강조하고 싶은 부분은 멘토님들의 열정과 태도이다.

잠깐 내 이야기를 하자면, 나는 Web3에 대한 지식이 부족한 상태에서 교육을 시작했다. 그러다보니 이해가 안 가고 궁금한 부분들이 너무나 많았다. Web3 관련 자료를 찾아도 내가 원하는 내용은 안 보이고... 진짜 답답했다 답답한 마음에 오픈 채널에 질문 폭탄을 쏟아내었음에도 불구하고, 정말 모든 멘토님들이 너무나도 친절하고 자세하게 답변해주셨다! (여러분들도 하루 빨리 합류하셔서 이 감동의 쓰나미를 맛보시길...) 답변을 통해 물론 지식도 전달받았지만, 그 외에 질문에 대한 답을 찾아가는 방식도 참고할 수 있어서 이후 스스로 검색할 때 큰 도움이 되었다.

그 다음에는 Web3 학습의 어려움이다.

25년 1월 비트코인의 가격이 최고점을 갱신하고, 올해 미국 트럼프 정부가 출범하면서 암호화폐 투자에 대한 관심은 커졌지만, Web3 분야에서의 실질적인 활동은 아직까지 접근성이 떨어지는 것이 현실이다.

일차적으로 커뮤니티를 중심으로 유기적으로 변화하는 Web3 개념은 스스로 올바르게 이해했다고 확신하는 것이 어렵다. 분산 시스템의 복잡도도 한 몫한다. 1기 지원 준비 기간에도 한 달 동안 삽질만 엄청했던 기억이 난다. ( Node? Finality? 이게 다 뭔 소리람 ‍ ~~Node.js는 아는데~~ )

그런데 교육 중에는 잘 정리된 자료를 바탕으로 강의를 들으니 빠른 개념 구조화가 가능했다. 구조화된 상태에서 질문을 하니, 보다 더 나은 질문을 할 수 있었고, 이러한 선순환이 초기 한 달 개념을 정립할 때 큰 도움이 되었다. 뿐만 아니라, 멘토님들께서도 자료의 최신성을 철저하게 검증한다. Web3를 독학하다보면 주어진 내용을 이해하고 수용하기만 하면 된다는 것이 얼마나 감사한 일인지 깨닫게 될 것이다.

지원하기로 결정했다면?

⚠️ 지원하기 전에 한 가지 주의할 점!
업사이드 아카데미는 구성원 전원의 몰입을 추구하기에, 주 7일 오전 10시부터 저녁 7시까지 오프라인 전 과정 참여가 가능해야 한다.
대학생이라면 당연하게도 휴학해야 하고, 재직 중이라면 지원할 수 없다.

업사이드 아카데미 | 지원하기

Web3 보안 분야에 관심이 있는 분은 누구나 지원이 가능합니다. 모집 대상과 일정을 확인해보세요!

upside.center

Web3 사이버보안 분야에서의 활동을 꿈꾼다면, 국내에 이보다 더 나은 온보딩 기회는 없다.

지원 기한은 6월 29일 일요일까지!

혹시라도 망설이는 지원자들이 있다면, 다양한 업사이드 행사에 참여해서 직접 궁금증을 해소해보는 것을 추천한다!

1️⃣ 2기 성과공유회

2025년 6월 12일(목) 14시 / 강남 빅플레이스
6/8(일)까지 신청 후 선정자 익일 개별 연락
지금 바로 참가하기

2️⃣ 3기 사전설명회

2025년 6월 16일(월) 19시 / 유튜브 티오리 TV 생중계
실시간 Q&A 진행
채널 바로가기

어떻게 준비하면 좋을까요?

2기 및 3기 예비 지원자들로부터의 질문에 대한 답변 및 지원 준비 팁 정리

업사이드 수료생 후기 및 지원 팁

업사이드 아카데미 OT오늘 OT는 6월 13일 한 통의 이메일로부터 시작됐다. 습도가 높은, 다소 더운 날이었지만 혹시라도 늦을까봐 1시간 일찍 출발했다.(너무 도착한 탓에 오히려 카페에서 기다렸

spems.tistory.com

[서평] 한 권으로 끝내는 만만한 자소서

ooMia — Mon, 28 Apr 2025 03:04:03 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

한 권으로 끝내는 만만한 자소서 / 취업왕 이쌤(이송민) 지음 / 한빛미디어

‍♂️ 모두를 위한 취업 준비서

이 책은 취업을 처음 준비하는 이들부터, 공고에 맞춰 서류를 수정해야 하는 취준생, 이직을 준비하는 경력직까지 모두가 얻어갈 수 있는 내용이 있는 책이다.

1️⃣ 취업이 처음이라면?

취업을 처음 준비하는 입장에서는 어디서부터 어떻게 접근해야 할 지 정말 막막하다. 인터넷에 검색하면 이것도 중요하고, 저것도 중요하다고 얘기하는데 아는 게 없으니 우선순위도 스스로 판단하기 애매하다. 본 책에서는 `지피지기면 백전백승`이라는 고사성어를 핵심 주제로, 나(지원자)를 알고 너(회사)를 아는 것이 중요하다고 강조한다. 그리고 방향성을 피상적으로만 제시하지 않고, 인생 타임라인, SWOT 분석, 업에 대한 가치관 찾기, 직무 필살기 정의하기 등 구체적으로 어떻게 시작하면 좋을지 제시한다.

취업 준비 시작하기: 인생 그래프 분석 / SWOT 분석

2️⃣ 취업 준비중이라면?

그러나 대부분 한 번씩은 이력서나 자기소개서를 작성해 본 경험이 있을거라 생각한다. 이 책이 가장 중점적으로 다루고 있는 독자층도 이와 같은데, 특히 신입으로서 취업을 준비하는 이들을 위한 내용이 많다. 지피지기라는 키워드에 맞게 회사를 어떻게 분석해야 하는지 큰 그림을 그릴 수 있도록 방향을 제시한다. 그리고 좀 더 자세히 들어가 자소서에 명시된 사항을 어떻게 해석하고 작성해야 하는지도 설명한다. 지원 동기, 핵심 역량 등의 기본적인 항목부터 자유 양식 자소서까지 어떻게 작성해야할지 고민했던 가려운 부분들을 잘 긁어준다.

항목별 안내 / 자유 형식 가이드

3️⃣ 경력직 이직을 준비한다면?

이 책에서 중점적으로 다루고 있지는 않지만, 신입 지원과 달라지는 부분을 분명하게 구분한 점이 눈에 띈다. 템플렛 또한 경력자용이 따로 제공되고, 면접 관련 내용에 대해서는 간단한 영상 강의도 제공하니 필요하다면 참고하길 바란다. 이직을 결심하게 되는 이유 중 하나는 보다 나은 연봉과 처우를 받기 위함도 있을 수 있다. 이러한 이유로 신입들에게도 필요하겠지만, 연봉 협상에 대한 부분도 책 후반부에서 다루고 있으니 참고할 법하다.

경력직을 위한 컨텐츠

‍♂️ 특정한 직무/분야에 대한 취업을 논하지 않는다

당연하겠지만 이 책은 말 그대로 '모든' 취준생을 위한 책이다. 따라서, 특정 분야나 직무에 맞춘 지원 전략은 다루지 않는다. 가령, 개발 직군에 지원한다면 자신의 하드 스킬을 어떻게 정의해야 하는지, 기술 숙련도는 어떤 기준으로 명시해야 할지, 이보다 자세한 가이드가 필요하다. 이 책에서는 그런 자세한 이야기들은 다루지 않지만, 오히려 그렇기에 보다 넓은 관점에서 자신의 이력서와 자기소개서를 점검할 수 있는 계기로 활용할 수도 있다고 생각한다.

마치며

사실 이전에 개발자 기술 면접 노트를 리뷰하면서 이력서를 한 장으로 수정한 경험이 있다. 이번에는 이 책 저자가 제공하는 다양한 템플렛을 활용해서 간단하게 현황을 업데이트하기도 했다. 약 350 페이지에 달하는 적지 않은 분량이 알차게 꽉 차있고, 추가로 제공하는 자료들도 많으니 직접 구매하여 보더라도 후회하지 않을 것 같다.

템플릿 / 이력서 수정

이 책을 보면서 취준생들이 받는 감정에 이입되었다. 우리의 인생은 시험의 연속이었다. 문제를 보고, 정답을 적고, 틀리면 그 이유를 복기하고 다음에는 정답을 맞출 수 있도록 연습하는 수련의 연속이었다. 하지만 취업은 다르다. 전형에서 떨어져도 대부분의 회사는 내가 왜 떨어졌는지 정확한 이유를 제공하지 않는다. 문제를 틀렸을 때와는 달리, 반복되는 취업 실패가 더 아프게 다가오는 이유는 막막함 때문일까? 아니면 실패라는 결과가 '시장에서의 나는 사실 내가 생각했던 것보다 더 낮은 존재의 가치였음'을 증명하는 것이 불안해서일까?

저자는 이러한 감정을 이해하고 있었다.

자신의 취준 시절을 얘기하며, 그럼에도 자신의 자존감을 지키는 마인드셋이 중요하다고 말한다.

취준에 지치고 방황하고 있다면, 이 책으로 용기와 위로를 받아 다시 시작해보는 것은 어떨까?

[서평] 자바 코드의 품질을 높이는 100가지 방법

ooMia — Thu, 27 Mar 2025 17:50:19 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

자바 코드의 품질을 높이는 100가지 방법 / 타기르 발레예프 지음 / 한빛미디어

왜 이런 일이 발생했는가? 처음부터 실수를 예방할 수는 없는가? 앞으로도 비슷한 문제가 발생할 수 있는가? 팀원들이 똑같은 실수를 반복하지 않게 하려면 무엇을 해야 하는가? 결국 필자는 모든 실수에 통용되는 만병통치약은 없다는 것을 깨달았다. ⋯ 그럼에도 실수란 모름지기 반복되는 법이다. 따라서 실수는 분류할 수 있으며 각각의 유형마다 일반화된 대응책도 있다. 앞길에 존재하는 함정을 미리 아는 것만으로도 함정을 피할 준비는 이미 갖춰진 셈이다.

10년 정수가 담긴 자바 챔피언의 오류 해결 특강

세상 그 어떤 유능한 개발자도 실수할 수 있다. 그리고 그로 인해 발생한 서비스 오류는 엄청난 손실을 야기한다. 저자 타기르 발레예프는 약 15 여년간 상업용 소프트웨어 개발자로서 근무하며 여느 때처럼 오작동을 바로잡기 위해 일하고 있었다. 그러다 FindBugs(현 SpotBugs)라는 자바 정적 분석 도구를 접하게 되었고, 몇 분만에 수십 개의 실수를 지적해주는 정적 분석의 열렬한 팬이 되어버렸다. 그러나 이 도구를 적극적으로 활용하려 할 수록 오탐지와 심각하지 않은 문제를 마주하게 되었고, 결국 은탄환은 없음을 깨닫게 되었다. (No Silver Bullet)

IntelliJ IDEA의 정적 분석팀으로 10년 동안 근무하며, 그는 한계가 있음을 깨닫는 데 그치지 않고 그럼에도 문제를 줄이기 위한 방법을 고민했다. 이 책은 그의 고민이 오롯이 담긴, 살아 숨 쉬는 100종의 정수(精髓; essence)이다. 책에서는 컴파일 시점에는 알 수 없었던 '진짜' 문제만을 대상으로 이를 유형화하고 때로는 실제 프로덕션 코드로 이를 설명한다. 개발자의 의도는 무엇이었고, 문제의 원인은 무엇이고, 어떻게 문제를 해결하는지 또 실수를 예방할 수 있는지, 각 문제의 유형에 최적화된 해결책을 제시한다.

개발자의 의도와 달리, 컴파일러가 실제로 어떻게 동작하는지 설명한다.

‍♂️ 런타임 오류 패턴: 기본부터 심화까지

Java 프로그램을 작성할 때, 컴파일 오류를 해결하기 위해 그렇게 많은 시간을 쏟는 개발자는 없을 것이다. Java 컴파일러는 꽤나 엄격한 편이고 빌드 시 발생한 예외와 그 위치, 심지어는 코드 작성 시점에 IDE에 그어진 빨간 줄만 보더라도 '아차, 이걸 놓쳤었네' 하고 뚝딱 해결할 것이다. 그러니 실질적으로 개발자들을 열받게 만드는 것은 런타임 오류라는 데에는 모두 이견이 없으리라 생각한다.

기본은 자세히

비교적 우리가 익숙하게 인지하고 있는 기본적인 유형은 좀 더 자세히 다루고 있다는 느낌을 받았다. 예를 들어, 표현식을 다루는 2장에서는 연산자에 대한 내용이 많다. 우선순위의 경우 덧셈보다 곱셈이 먼저 수행되는 1 + 1 * 4 != 8 와 같은 자명한 사례 대신, 1 + 1 << 2 == 8 처럼 비트 시프트 등의 다소 이색적인 사례를 소개한다. 논리 연산의 경우는 어떨까? 논리 합 또는 곱에 &&, || 연산자를 사용하는 것은 자명한데, 이러한 단락 연산자(short-circuit operator)는 비단락 연산자 &, |와 어떻게 다르고 그래서 어떻게 문제가 생길 수 있는지, 또 복합 할당 연산으로 활용될 때는 어떤 점을 조심해야 하는지 보다 심도있는 내용을 다룬다. 이 책에서 기본이란 이런 느낌이다.

실수 2-7 비단락 논리 연산자 사용

한 가지 예시를 살펴보자. 나는 다음 코드를 보며 고개를 갸우뚱했다.
"음.. 여기에 문제가 있다고?"

2.7.2 - using non-short-circuit operator / before, after

일단 개발자의 의도는 세 종류의 검사 모두 통과하는 경우에만 true를 반환하는 것이다. 그리고 이 과정을 복합 할당 연산자로서의 비단락 연산 &=으로 구현했다. 논리곱 &&이 피연산자(operand) 중 false가 발생하는 순간 다음 명령을 수행하는 것과는 달리, 비단락 연산은 피연산자 내 false가 있더라도 해당 명령을 끝까지 수행한다. 따라서 검사 로직이 복잡하다면 불필요하게 프로그램의 복잡도를 높이는 안티 패턴이기에 저자는 이를 지적한 것이다. 다음 두 코드를 통해 실행되는 횟수에 차이가 있음을 확인할 수 있다.

2.7.2 - using non-short-circuit operator / class impl, test count

심화: 이걸 문제로 보는 게 맞을까?

물론 복잡하게 중첩되어 로직에 오류를 만드는 사례도 소개한다. 해당 사례에서는 정적 분석기에서 이를 어떻게 탐지하는지 소개하고 실수 방지 가이드에 비단락 논리 연산자를 사용하지 않도록 권고한다. 앞서 소개한 사례처럼 분명하게 로직에 오류가 발생하는 경우는 아니지만, 위 코드는 분명 최적화의 관점에서는 불필요하게 복잡도를 증가시키고 있으므로 단락 논리 연산자를 사용해서 해결하는 것이 합리적으로 보인다. 그러나 내가 처음 가졌던 의문은 좀 달랐다.

'오류(error)를 만드는 것이 아니라면, 어떠한 관점에서든 이를 잘못되었다고(wrong) 할 수 있을까?'
'&를 의도적으로 사용한 로직에 대해서는 false positive 아닌가?'

다름과 틀림을 구분하고자 다소 비판적으로 바라보고 있었는데, 신기하게 저자는 이에 대해서도 의견을 남겨두었다. 책에서는 '양쪽 피연산자 평가'라는 제목으로 절의 마지막에서 이러한 내용을 다루고 있다. check라는 피연산자가 모두 의도적으로 부수 효과(side effect)를 가지고 있다면, 단락 논리 연산자 &&를 사용했을 때 첫 번째의 결과에 의해 나머지가 실행되지 않을 수 있다. 이런 경우에는 & 사용이 합당한데, 심지어 이런 경우에도 &&를 사용하도록 리팩터링하거나 명시적으로 정적 분석 억제 주석을 추가하도록 권고하고 있다.

그러니까 일반화하자면 이 책에서 나오는 '의도하지 않았던 동작의 원리'는 사실 언제든 '의도적으로' 활용될 수 있다. (부수 효과를 의도하고 비단락 논리 연산자를 사용하는 것처럼) 그리고 그 때 비록 결과가 의도한대로 정상적으로 출력되더라도, 동일한 동작을 더 분명하게 표현할 수 있는 방법이 있다면 그렇게 바꾸어 나가야 한다. 그것이 리팩터링이고 이 책에서 소개하는 자바 코드의 '품질을 높이는' 길이다. 이처럼 2장 7절 비단락 연산자 예제는 이 책에서 저자가 코드로부터 개발자의 의도를 파악하기 위해 노력하고 깊이 있게 고민했던 것을 느낄 수 있는 대목 중 하나였다.

다양한 요약 및 정리

책을 읽다보면 군더더기 없이 깔끔하게 잘 정돈되어 있다는 느낌이 든다. 각 절마다 다양한 하위 주제로 유형을 상세히 구분하고 문제 및 대응 방안을 요약 정리한다. 가령, 2장 표현식 마지막에서는 내용을 총 정리한다. 내용은 다음과 같다.

수학적 연산자의 우선순위는 마냥 직관적이지 않다. 특히 비트 연산자와 논리 연산자는 더욱 까다롭다. 우선순위가 한 눈에 보이지 않을 때는 항상 괄호를 사용하라.
덧셈 기호는 숫자와 문자열에 적용되는 방식이 다르며, 간혹 두 방식이 한 표현식에서 혼용되기도 한다. 단일 표현식에서는 덧셈과 문자열 연결 기능을 혼합하지 않는 것이 좋다. 단항 덧셈 연산자는 프로젝트 전체적으로 금지하라.
문자열을 연달아 길게 이어 붙일 때, 전체 문자열이 아닌 마지막 조각에 최종 메서드를 호출할 위험이 있다. 긴 문자열을 다룰 때는 최근 자바 버전에 도입된 텍스트 블록 구문을 사용하는 것이 좋다.
조건 표현식에서 각 분기의 표현식 타입이 서로 다를 경우, 복잡하며 비직관적인 규칙에 따라 타입이 변환된다. 결과 타입이 확실치 않을 때는 if 문을 사용하라.
Integer, Double, Boolean 등의 박싱된 타입은 가능한 한 지양하라. 묵시적 변환이 발생하며 성능 오버헤드를 일으킬 우려가 있다. 또한 실수로 null을 넣으면 NullPointerException이 발생한다.
가변 인수 메서드는 사용하기 편리하다. 그러나 가변 인수 메서드에 정확히 하나의 인수를 전달하면 모호성이 발생한다. 배열이나 컬렉션을 또 다른 배열로 래핑할 위험이 있다.
자바는 메서드 호출이나 표현식의 결과를 무시할 수 있다. 일부러 그렇게 할 때도 있지만 실수의 원인이 되는 경우도 많다. 불변 클래스는 자신을 고치지 못하므로 새로운 객체를 생성한다는 점을 기억하라. 또한 이들이 만일 예외 클래스라면 객체 생성 시 throw를 추가하라.
메서드 참조 구문을 통해 깔끔하고 간결한 함수 표현식을 만들 수 있다. 그러나 메서드나 생성자 오버로드가 있으면 컴파일러가 바인딩할 메서드를 오해할 수 있으므로 주의하라. 확실치 않을 때는 람다 구문을 사용하라.

‍♂️ Java 표준에만 집중한다

[서드 파티는 다루지 않는다] 간혹 어노테이션 패키지나 테스트 프레임워크에 대한 내용이 나오긴 하지만, 그 외 대부분 Java 표준 라이브러리에 대한 내용을 중심으로 다룬다. 따라서, Spring 프레임워크의 활용에 관심이 많다면 이 책은 적절하지 않다. 가령, 3장 프로그램 구조에서의 문제 중 일부는 프레임워크 기능을 활용하여 해결할 수도 있을 것이다.

[코드 전문이 제공되지 않는다] 직접 실행해보며 내용을 검증하려는 이들이 있다면 유감이다. 이 책에는 잘못된 코드의 패턴만을 간략히 소개하기 때문에, 실행 가능한 형태의 코드 전문을 항상 제공하지는 않는다. 이러한 이유로 나 또한 새롭게 레포를 생성하여 2장의 14개 절에 대해서는 나름대로 실습을 진행해보았다. 필요하다면 다음 레포와 사이트를 참고하자

GitHub - ooMia/100_java_mistakes: A practical project for implementing concepts from the book '100 Java Mistakes and How to Avoi

A practical project for implementing concepts from the book '100 Java Mistakes and How to Avoid Them (자바 코드의 품질을 높이는 100가지 방법)' - ooMia/100_java_mistakes

github.com

100 Java Mistakes

Practicing the concepts and exercises from the book `100 Java Mistakes and How to Avoid Them`

oomia.github.io

마치며

의심할 여지가 없는 수작이다. Java 프로그래밍에 관심 있는 그 누가 보더라도 도움이 될만한 책이라고 감히 단언할 수 있다

...라고 생각하지만, 소수의 의견도 항상 존재하는 법 해외 책 리뷰 사이트에서 4.29/5의 평점이었는데, 그 중 낮은 평점을 제시한 한 의견을 찾아보았고, 이렇게도 생각할 수 있겠구나 흥미로워 가져왔다.

goodreads.com: 그리고 chatGPT 번역

책을 쓰는 것은 대담한 도전이라고 생각한다. 원고를 제출하는 순간, 저자는 낯선 사람들이 몇 시간 동안 읽을 가치가 있는 글을 썼다고 주장하는 셈이니까. 하지만 이 책에서는 내가 기대했던 우아함과 '아하!' 하는 깨달음이 부족하다고 느꼈다. 마치 전형적인 "고전적인 엔지니어링 서적"에서 예상할 수 있는 것처럼, 다소 인공적이고 야심(또는 열정)이 부족한 느낌이었다.

...(중략)

내가 느낀 가장 큰 문제는, 저자가 단순히 소나(Sonar) 이슈 목록을 펼쳐놓고 하나씩 예제를 설명하는 것처럼 보였다는 점이다. 몇 가지 메모를 남기기는 했지만, 350페이지를 읽고 난 후에도 내가 자바나 프로그래밍 기법에 대한 사고가 기대했던 만큼 발전했다고 느끼지는 않았다.

아마 이 리뷰어는 로버트 마틴의 [클린 코드], 켄트 벡의 [테스트 주도 개발] 같은 느낌의 책을 기대하지 않았을까 싶다. 내 기억으로는 두 책 모두 일정한 형식을 가지고 잘 정돈된 느낌보다는, 서사에 맞춰 저자가 자연스럽게 자신의 이야기를 하는 느낌이었다. 두 책과 비교하자면, 이 책은 다소 실무 메뉴얼 같은 느낌이다. 나름의 정해진 템플렛이 있고, 주제에 따라 그 내용만 다르다. 개인적으로는 이렇게 잘 정돈된 책이야말로, 나중에 다시 폈을 때도 읽기 쉬워 좋은 책이라 생각하긴 한다. 사고력 증진에 대한 의견은, 아마 리뷰를 작성한 사람이 이 이슈들에 이미 충분히 익숙하기 때문이라 생각한다. 하지만 적어도 저자가 의도했던 이 책의 대상 독자 - 실무 경험이 충분하지 않은 중급 개발자에 해당된다면 큰 도움을 얻을 수 있을 것이라 생각한다.

[링크]
I believe that this book is most useful for middle-level software developers who already know the Java language but may have not enough practical programming experience. It is likely that some bug patterns described in the book may be unknown to senior software developers as well. Less experienced developers or even advanced students might also find this book interesting.

8 - Next 기반 프로젝트

ooMia — Sun, 2 Mar 2025 20:55:36 +0900

Overview

이번 시간에는 우리의 Hello, World!가 어떤 식으로 화면에 출력되는지, 프로젝트 구조의 관점에서 알아봅시다. 자세한 원리보다는 요소들의 상호작용에 집중할테니, 대강 "그렇구나~" 하고 다음에 이어질 프레임워크 위에서의 작업에 대한 감각을 익혀두는 정도면 충분합니다.

Hello, World!

최종 사용자가 마주하는 결과에서부터 차례대로 거슬러 올라가봅시다. 먼저, 새롭게 개편된 우리의 랜딩 페이지입니다. 단순히 텍스트만 있던 이전 단계보다 더 발전되었죠? 하지만 "World" 문자열은 여전히 이전과 동일하게 GET /api/name 요청을 통해 전달받습니다. 이러한 내용이 어디에 어떻게 구현되었는지 살펴봅시다.

pnpm dev ➡️ http://localhost:3000

src/app/page.tsx

가장 먼저 tsx라는 확장자가 눈에 들어옵니다. 일반적으로 우리가 사용하는 자바스크립트 확장자는 js였죠? 이제 React 라이브러리를 사용하면서 jsx 파일을 활용하게 되었습니다. JSX는 공식적으로 JavaScript XML이라 부르며, JavaScript Syntax Extension으로도 불립니다. 핵심은 이를 통해 HTML과 자바스크립트를 통합하여 관리하고, 작성한 컴포넌트의 변경을 빠르고 안정적으로 처리할 수 있게 되었다는 것입니다. 화면에 새로운 요소를 추가하고 싶다면 JSX 코드를 추가하면 됩니다. 마지막으로 TSX는 JSX에 단순히 타입스크립트 지원을 위한 확장자입니다. 일반 js 코드는 ts로, jsx 코드는 tsx로 확장자를 설정해야 타입스크립트의 강력한 타입 체크 기능을 활용할 수 있습니다. JSX에 대한 자세한 내용은 facebook.github.io/jsx를 참고하세요!

import helloWorld from "@/public/hello-world.jpeg";
import Image from "next/image";

async function Title() {
  const url = `http://localhost:3000/api/name`;
  const title = await fetch(url)
    .then((res) => res.json())
    .then((data) => data.result);

  return <div id="greeter">Hello, {title}!</div>;
}

export default async function RootPage() {
  const title = await Title();
  const banner = <Image src={helloWorld} ... />;
  return (
    <main>
      {title}
      <div>
        <div">{banner}</div>
      </div>
    </main>
  );
}

page.tsx에서 핵심만 추려낸 코드입니다.

가장 먼저 함수 Title()은 "Hello, World!"를 출력하도록 구현되었습니다. 이전 브랜치에서 구현했던 것처럼 GET /api/name 요청의 결과를 참조합니다. 한 가지 눈 여겨볼 점은 단순히 문자열을 반환하지 않고, JSX 태그를 반환하는 것을 알 수 있습니다. 그리고 태그 안에 중괄호 { }를 통해 JSX 표현식을 사용하여 값을 집어넣고 있네요.
Next.js 프레임워크에서는 app 폴더 내에 존재하는 page.tsx 파일에서 export default 키워드로 노출된 함수를 화면에 출력합니다. 따라서, RootPage()라는 함수의 내용이 우리의 화면에 나오게 되는 것이죠.

위 내용을 이해했다면 GET / 이전에 GET /api/name 요청이 왜 먼저 처리되는지 알 수 있습니다.

GET http://localhost:3000

src/app/api/name/route.ts

위에 찍힌 Anvil 로그를 보니, on-chain 데이터를 가져오는 것 같은데, 이 내용은 어디에서 처리되는 걸까요? Next.js에서는 컨벤션 기반 내부 라우팅을 지원합니다. 그래서 page.tsx 대신 route.ts를 작성하는 것으로 custom request handler를 만들 수 있습니다. getName 함수를 받아 실행하는 간단한 구조네요! 특별히 이해하기 어려운 부분은 없을거라 생각해서 넘어가겠습니다. 혹시라도 자세한 내용이 궁금하다면 공식 문서를 참고하세요!

import { getName } from "./getName";

export async function GET() {
  const name = await getName();
  return Response.json({ result: name });
}

src/module/Sum.ts

export default function sum(a: number, b: number): number {
  return a + b;
}

두 숫자를 더하는 파일 sum.ts의 함수 sum입니다. 그리고 이를 테스트하는 코드가 담긴 파일 Sum.test.ts는 다음과 같습니다. suite와 describe, 그리고 test와 it는 alias 관계이기에 둘은 정확히 같은 테스트입니다. 이전 포스트에서 문자열 "1"과 숫자 2를 더하는 바람에 12가 반환된 사례가 있었는데, 이런 테스트가 존재했다면 문제를 빠르게 식별할 수 있었겠죠? 추가로 좋은 테스트를 작성하는 방법은 많은 경험을 요구합니다. 각 단위 테스트는 modularity를 보장하기 위해 mocking 등의 수단을 활용하는데, 이에 관해서는 차후 다른 포스트에서 자세히 다루도록 하겠습니다.

import assert from "node:assert";
import { describe, it, suite, test, todo } from "node:test";
import sum from "./Sum";

suite("Sum:suite", () => {
  test("should add two numbers", () => {
    assert.strictEqual(sum(1, 2), 3);
  });
});

describe("Sum:describe", () => {
  it("should add two numbers", () => {
    assert.strictEqual(sum(1, 2), 3);
  });
});

tests/e2e/index.spec.ts

playwright 라이브러리를 활용한 엔드-투-엔드 테스트 코드입니다. css selector를 활용하여 우리가 원하는 태그를 지정하고, 내부의 문자열이 Hello, World!를 반환하도록 검사합니다.

import { expect, test } from "@playwright/test";

test.beforeEach(async ({ page }) => {
  await page.goto("/");
});

test("test", async ({ page }) => {
  const greeter = page.locator("#greeter");
  await expect(greeter).toHaveText("Hello, World!");
});

마치며

이번 시간에는 기존 작업물이 프레임워크에 어떻게 적용되었는지, Next.js 기반의 웹 애플리케이션의 구성요소와 두 종류의 테스트에 대한 기본적인 설명을 진행했습니다. 지금까지 잘 따라왔다면, 웹 애플케이션을 개발하기 위한 기본적인 요소는 모두 학습했다고 볼 수 있습니다. 정확하게 이해되지 않았더라도 괜찮습니다. 앞으로 구체적인 기능을 구현하면서 계속 반복해서 학습하다보면 자연스럽게 숙달될 것이라 생각합니다.

다음 시간부터는 본격적으로 DApp으로서의 전환에 필요한 작업들을 수행하게 됩니다. 먼저, 로컬 Anvil 서버에서 작업하는 환경을 외부 Sepolia Ethereum Testnet으로 전환할 것이고, 이 과정 중에 viem 라이브러리를 활용해서 보다 추상화된 형태로 로직을 처리할 것입니다. 동시에 GitHub Pages를 통해 외부에서 접근 가능한 형태로 애플리케이션을 배포할 것입니다. 이로서 우리의 DApp은 별도의 서버 없이 탈중앙화된 방식으로 상태 변화를 유지할 수 있게 됩니다.

7 - Next 기반 프로젝트 (개념)

ooMia — Fri, 28 Feb 2025 19:18:00 +0900

Overview

정말 간단한 DApp이라면 이전까지의 Hello, World! 수준으로 충분합니다. 그러나 보다 더 규모 있는 애플리케이션을 개발하기 위해서는 프레임워크 위에서 개발할 필요가 있습니다. 이를 통해 다양한 기능을 쉽고 빠르게 추가할 수 있습니다. 또한 기능 검수를 위해 테스트 라이브러리도 필요합니다. case4-next-ts 브랜치*에는 크게 세 가지의 변화가 있는데,

* 프레임워크를 도입한 시점에 vanilla Node 프로젝트 case3을 다루는 것은 오히려 혼란을 줄 것 같아 넘어갑니다

웹 프레임워크를 사용합니다. Next.js v15 프레임워크
단위 테스트를 수행합니다. node:test 모듈
e2e 테스트를 수행합니다. Playwright 라이브러리

이 밖에도 TypeScript의 사용이나 React와 JSX 문법, Tailwind-CSS 등 다양한 변경이 있지만, 이는 본 포스트에서는 다루지 않고, 반드시 설명이 필요한 부분만 짚고 넘어가도록 하겠습니다.

프레임워크? 모듈? 라이브러리?

본론을 진행하기 전에 Overview에서 언급한 내용을 살짝 다루고 가봅시다. 위 세 가지 용어는 의존성(dependency)에 대한 이야기입니다. 같은 의존성인데 이렇게 구분하는 이유가 무엇일까요? 먼저, 모듈에 대해 알아봅시다.

함수와 모듈

소프트웨어 개발 규모가 커지면 다양한 의미 단위가 필요해집니다. 아래 그림에서 각각의 공구는 함수, 공구 통은 모듈입니다. 일단 우리가 못을 박아야 하는 상황에 드라이버를 사용할 수는 없겠죠? 그래서 상황에 알맞은 공구를 만들고 재사용합니다. 만약 그렇게 공구의 수가 수 천개, 수만 개가 되면 어떨까요? 어지럽게 흩어져있거나, 모든 공구가 한 데 섞여 있으면 찾기 어렵겠죠? 그래서 목적과 사용처에 따라 분류를 해둡니다. 마치 유사한 상황에 사용되는 함수들을 하나의 파일에 모아서 작성하는 것처럼요. 근데 우리 집 안에서만 사용하던 공구를 친구가 빌려달라고 하면 어떨까요? 통 없이 공구만 주려고 하면 왔다 갔다 들고 다니기 어렵겠죠? 그래서 통이 필요합니다. 필요할 때 꺼내 쓰고, 필요 없으면 다시 보관하고, 빌려주기도 편하니까요.

왕초보를 위한 Python: 쉽게 풀어 쓴 기초 문법과 실습 - 5.1 모듈이란

그럼 실제로 어떻게 생겼는지 살펴봅시다. node:test 모듈은 자바스크립트 테스트 작성을 지원하는 Node.js의 내장 모듈입니다. 사실 그냥 파일인데요, 이게 모듈로 동작할 수 있는 이유는 export/import 구문으로 불러오는 것이 가능하기 때문입니다. 모듈 이름에 마우스를 hover하고, cmd + 클릭하면 참조로 이동할 수 있습니다. 현재 프로젝트에서는 22.13.5 버전 @types/node를 네이티브 노드 모듈의 타입 정의로 사용하고 있기 때문에, 타입 정의 파일(*.d.ts)로 이동했습니다. 실제 노드 내부에서 export 하고 있는 구문이 보이나요? 참고로 타입 정의는 타입스크립트와 프로젝트 사이의 인터페이스에 불과합니다. 실제 소스를 보고 싶다면 node/lib/test.js를 참조하세요!

import "node:test" module

라이브러리와 프레임워크

코드의 구조와 포함 관계만을 생각하면, 라이브러리는 공구통을 모아둔 창고이고, 프레임워크는 여러 개의 창고가 있는 공장입니다. 즉, 프레임워크가 가장 넓은 범주의 개념이라는 의미입니다. 더 중요한 것은 의존 관계입니다. 우리가 작성한 코드가 또 다른 코드를 호출하는 일반적인 관계에서 벗어나, 우리가 작성한 코드가 프레임워크가 정의한 규칙에 따라 관리되고 호출될 수 있다는 것이 핵심입니다.

TCP School: React 이해하기 - 라이브러리? 프레임워크?

가령, Next의 App Router는 (src)/app 내부에 경로에 따른 라우팅을 기본적으로 지원합니다. Node의 Native HTTP 서버에서 라우팅 경로를 명시했던 것과는 다르죠? 물론 바닐라 Node 프로젝트도 그렇게 구현 가능하지만 기본 값이 다르다는 것이 차이입니다. 그래서 편리하지만, 또 프레임워크의 규칙을 알아야 하기 때문에 학습이 필요하죠. 아래 이미지에서 차이가 느껴지시나요? 자세한 설명은 공식 문서를 참조하세요!

vanilla Node.js vs Next.js

pnpm test

현재 프로젝트는 두 가지 종류의 테스트를 진행합니다. 첫 번째는 node:http 모듈 기반의 단위 테스트, 나머지는 playwright 라이브러리 기반의 엔드-투-엔드 테스트입니다. 모종의 로직이나 상호작용에 따른 사이드 이펙트를 알맞게 구현했는지 확인할 때 단위 테스트를 활용하고, 그 결과 사용자에게 예상한 결과가 렌더링되는지 확인할 때 엔드-투-엔드 테스트를 활용하게 됩니다.

말이 어려울 수 있으니 라면을 끓이는 과정으로 예시를 들어볼까요? 조리기구가 준비되어 있는지, 버너에 불이 들어오는지, 물 양은 적절한지 등 각 과정 또는 구성요소를 점검하는 것은 단위 테스트, 그래서 기대했던대로 라면이 완성되었는지 결과를 점검하는 것은 엔드-투-엔드 테스트입니다.

"테스트 작성할 시간에 원하는 기능 하나 더 구현하는 게 낫겠다" 고 생각할 수 있습니다. 작은 규모의 애플리케이션에서는 어느 정도 맞는 말일 수 있지만, 규모가 커질수록 테스트는 중요합니다. 그 이유 중 하나는 유지 보수가 편리하기 때문입니다. 가령, 이전에 만들어둔 내부 모듈 A와 외부의 라이브러리의 함수 B를 기반으로 AB를 만들고 있다고 해봅시다.

만약에 외부 라이브러리를 업데이트하는 상황이 온다면 어떨까요? 우선, 대부분의 잘 만들어진 라이브러리는 Backward Compatibility를 최대한 유지하기 위해 노력하고, 불가피하게 버전 간 호환이 깨지는 시점의 업데이트를 Breaking Changes로 명시합니다. 따라서, 제 3자의 코드에 대한 테스트를 작성하는 것은 낭비입니다.
그럼 다시 돌아와서 우리의 관심사는 내부 모듈의 변경이 되겠네요. 만약 우리가 A와 B를 더해서 AB를 만든다고 해봅시다. 이전에는 두 값 모두 숫자로 반환되어, 예를 들어, 1 + 2 = 3의 결과가 나왔습니다. 그런데 열심히 내부 모듈을 리팩토링하다보니, 사용자에게 3 대신 12라는 결과가 반환되는 오류를 확인했습니다. 내부 모듈의 반환 타입이 정수에서 문자열로 변경된 문제였던 것이죠.
- 이 시점에 테스트 없이는 결과 출력 시점에서부터 역으로 거슬러 올라가며, 변경 사항이 개입되는 시점을 차례대로 검증해야 합니다. 매우 번거롭고 손이 가는 일인데, 심지어 변경이 자주 발생하면 그 수에 비례해서 생산성이 저하되죠.
- 심지어 확인 방법에 따라서는 버그를 찾기 어려울 수도 있습니다. 예를 들어, 콘솔 출력으로 디버깅을 하는 개발자라면, 숫자 1이나 문자열 "1"을 출력할 때, 두 경우가 모두 동일하게 출력될 수 있습니다.

다소 억지스러워 보일 수 있지만, 어쨌든 잘 정의된 테스트는 내부 모듈의 변경이 가져오는 파생 효과를 식별하고, 소프트웨어를 변화에 견고하게 만드는데 큰 도움을 줍니다. 명령 한 번이면 우리가 의도한대로 소프트웨어가 동작한다는 확신을 얻을 수 있다는 것이 가장 큰 장점이죠. TypeScript의 사용 또한 큰 연관이 있습니다. 우리가 정의한 타입 또는 인터페이스에 맞지 않는 값이 활용되었다는 사실을 빌드 이전에 알 수 있으니까요.

pnpm test

마치며

이번 시간에는 모듈, 라이브러리, 그리고 프레임워크의 개념과 테스트의 중요성에 대해 학습했습니다. 함수를 포함한.. 모듈을 포함한.. 라이브러리를 포함한.. 프레임워크! 그리고 프레임워크을 사용하면 호출의 주체가 역전되고, 내장 기능을 통해 편리한 개발이 가능하지만, 반대로 규칙을 학습할 필요가 있습니다. 또 테스트를 활용하면 변화에 견고한 소프트웨어를 작성할 수 있다는 사실을 명심합시다!

다음 시간부터는 본격적으로 프로젝트의 구성 요소를 살펴보며, 이전 우리의 Hello, World! 앱이 어떻게 변경되었는지 다루겠습니다.

[서평] 전문가를 위한 리액트

ooMia — Sun, 23 Feb 2025 11:03:51 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

전문가를 위한 리액트 / 테자스 쿠마르 지음 / 한빛미디어

이 책은 리액트의 근간이 되는 메커니즘과 고급 사용 패턴, 모범 사례를 배우고자 하는 분들을 위해 아주 상세하게 리액트를 설명합니다. 따라서 단순한 사용법을 넘어 리액트가 어떻게 동작하는지 알고 싶은 분들에게 적합합니다. 많은 리액트 서적이 최종 사용자로서 리액트를 사용하는 방법에 치중합니다. 그에 반해 이 책은 최종 사용자가 아닌 라이브러리나 프레임워크 개발자 수준으로 리액트를 이해하도록 돕습니다.

"진짜"들만 모여라 - 리액트 역사부터 프레임워크 내부 원리까지

늘 그래왔던 것처럼 책을 한 두 번 훑어보면서 느꼈다. 이 책은 진짜다! 책의 내용과 구성이 좋아서, 초급부터 고급 개념까지 차근차근 이해하며 읽을 수 있었다. 물론 React 참고서와 교육 문서도 정말 잘 만든 컨텐츠라 생각한다. 차이점은 React 컨텐츠는 최종 사용자로서 실제 개발에 유용한 느낌이고, 정보들이 링크를 통해 파편화되어 있어서 구조적으로 정돈된 느낌은 덜하다. 하지만 이 책은 전개 과정 중에 끊임없이 문제를 제기하고 해결해가며 자연스럽게 개념을 빌드업하고, 놓치는 내용이 없도록 질문을 통해 recap도 한다. 내용이 다소 무겁게 느껴질지라도 이러한 친절한 구성 덕에, 리액트를 보다 더 효율적으로 사용하고 싶어하는 초중급 개발자들에게 큰 도움이 될 것이라 생각한다.

첫 번째 장 [입문자를 위한 지식]에서는 리액트가 왜 존재하게 되었는지, 어떻게 동작하는지, 어떤 문제를 해결하려고 작성되었는지, 그리고 지금의 리액트 이전에는 다른 어떤 방식이 존재했는지, 역사적인 맥락과 해결하고자 했던 기술적 문제를 이해하는 시간을 갖는다. 이 장이 중요한 이유는 리액트를 하나의 문제 해결 도구의 관점으로서, 책을 보다 풍부한 관점에서 읽을 수 있도록 도와주기 때문이다. 저자는 역사 다큐멘터리 영상도 추천했는데, 이 80분 분량의 영상도 정말 의미있는 내용이 많으니 시청해보는 것을 추천한다.

How A Small Team of Developers Created React at Facebook

‍♂️ 하나부터 열까지, 차근차근 쌓아올리는 리액트 개념

이 책은 2장부터 7장까지의 리액트 개념과 10장까지의 프레임워크 내용을 차례대로 소개한다. 이전 장에 대한 이해를 전제로 다음 장을 전개하는 구성이므로, 각 장마다 제공하는 복습 질문에 나름 타당한 답을 낼 수 있을 때까지 반복하여 읽다보면 리액트에 대한 지식을 자연스레 쌓아나갈 수 있다는 것이 장점이다.

⭐️ 챕터별 체크 리스트

입문자를 위한 지식
- 리액트를 만들게 된 동기가 무엇인가요?
- 리액트가 MVC와 MVVM 같은 이전 패턴보다 개선된 점은 무엇인가요?
- 플럭스 아키텍처의 특징은 무엇인가요?
JSX
- JSX란 무엇이며, 장단점은 무엇인가요?
- JSX와 HTML의 차이점은 무엇인가요?
- 텍스트 문자열은 어떻게 기계어가 되나요?
- JSX 표현식이란 무엇이며 어떤 좋은 점이 있나요?
가상 DOM
- DOM이란 무엇이며, 가상 DOM과 어떻게 다른가요?
- 문서 조각이란 무엇이며, 리액트의 가상 DOM과 어떤 점에서 비슷하고 다른가요?
- DOM에서 문제가 되는 사안은 무엇인가요?
- 사용자 인터페이스를 더 빠르게 업데이트하는 데 가상 DOM이 어떻게 활용되나요?
- 리액트의 렌더링은 어떻게 작동하나요? 이로 인해 잠재되었던 어떤 문제가 발생할 수 있나요?
재조정
- 리액트의 재조정이란 무엇인가요?
- 파이버 데이터 구조의 역할은 무엇인가요?
- 왜 트리가 두 개 필요한가요?
- 애플리케이션이 업데이트되면 어떻게 되나요?
자주 묻는 질문과 유용한 패턴
- 리액트에서 메모화란 무엇이며, 컴포넌트 렌더링을 최적화하는 데 어떻게 사용할 수 있을까요?
- 리액트에서 상태 관리를 위해 useReducer를 사용하면 어떤 우세한 점이 있으며, useReducer는 useState와 어떻게 다른가요?
- React.lazy와 Suspense 컴포넌트를 사용하는 리액트 애플리케이션에서 지연 로딩을 어떻게 구현할 수 있나요?
- 리액트에서 메모화를 사용할 떄 발생할 수 있는 잠재적 문제는 무엇이며 어떻게 완화할 수 있을까요?
- 리액트에서 컴포넌트에 프롭으로 전달된 함수를 메모화하기 위해 useCallback 훅을 어떻게 사용할 수 있나요?
서버 사이드 리액트
- 리액트 애플리케이션에서 서버 사이드 렌더링을 사용할 때 유리한 주요 장점은 무엇인가요?
- 리액트에서 하이드레이션은 어떻게 작동하며 왜 중요한가요?
- 재개 가능성이란 무엇인가요? 하이드레이션보다 좋다고 주장하는 근거는 무엇인가요?
- 클라이언트 사이드 렌더링의 주요 장점과 약점은 무엇인가요?
- 리액트에서 renderToReadableStream과 renderToPipeableStream API의 주요 차이점은 무엇인가요?
리액트 동시성
- 리액트의 파이버 재조정자는 무엇이며, 복잡한 고성능 애플리케이션을 처리하는 데 어떻게 도움이 되나요?
- 리액트에서 업데이트 예약 및 지연의 개념을 설명하세요. 부하가 많은 상황에서도 원활한 사용자 경험을 유지하는 데 어떻게 도움이 되나요?
- 리액트의 렌더 레인이란 무엇이며, 업데이트 실행을 어떻게 관리하나요? 렌더 레인이 비트마스크를 사용해 여러 우선순위를 처리하는 방법을 설명하세요.
- 리액트에서 useTransition과 useDeferredValue 훅을 사용하는 목적은 무엇인가요? 각 훅이 유용한 상황을 설명하세요.
- useDeferredValue를 사용하는 것이 부적절한 상황은 어떤 상황일까요? 이 훅을 사용할 때 고려할 장단점은 무엇인가요?
프레임워크
- Next.js나 Remix 같은 리액트 프레임워크를 사용하는 주된 이유와 이때 얻는 장점은 무엇인가요?
- 리액트 프레임워크를 사용할 때 생기는 장단점이나 불리한 점에는 어떤 것이 있나요?
- 프레임워크로 해결되는 일반적인 문제에는 어떤 것이 있나요?
- 프레임워크는 이런 문제를 어떻게 해결하나요?
리액트 서버 컴포넌트
- 리액트 서버 컴포넌트의 주된 가치는 무엇인가요?
- 클라이언트 컴포넌트가 서버 컴포넌트를 가져올 수 있나요? 그렇게 답변한 이유가 무엇인가요?
- 서버 컴포넌트와 기존 클라이언트 전용 리액트 애플리케이션 사이에는 어떤 트레이드오프가 있나요?
- 모듈 참조란 무엇이며, 리액트는 재조정 과정에서 모듈 참조를 어떻게 처리하나요?
- 서버 액션은 어떤 방식으로 리액트 애플리케이션의 접근성을 향상시키나요?
리액트 대체제
- 리액트, 뷰, 스벨트, 솔리드, 앵귤러의 반응형 모델은 각각 어떻게 다른가요? 이러한 차이가 라이브러리/프레임워크의 성능과 개발 환경에 어떤 영향을 미치나요?
- 성능을 극대화하는 퀵의 고유한 접근 방식을 설명해 주세요. 지금까지 살펴본 UI 라이브러리/프레임워크의 접근 방식과 어떻게 다른가요?
- 이 장에서 설명한 각 UI 라이브러리/프레임워크의 주요 강점과 약점은 무엇인가요? 이러한 강점과 약점이 특정 프로젝트의 라이브러리/프레임워크 선택에 어떤 영향을 미칠까요?
- 리액트는 전통적인 의미의 반응형이 아닙니다. 이를 뷰 또는 스벨트 같은 라이브러리에서 볼 수 있는 '푸시 기반(push-based)' 반응형 모델과 비교해 자세히 설명하세요.
- 리액트 컴파일러란 무엇인가요? 어떻게 작동하나요? 시그널과 비교하면 어떤가요?
마치며
- 모범 사례를 재고해 보세요
- JSX의 작동 방식을 완벽하게 이해하세요
- 제약은 나쁘지 않습니다
- 선언적 추상화로 강력한 기능을 사용합니다
- 강력한 기능을 활용하면 더 유연하고 유지 보수가 용이한 애플리케이션을 구축할 수 있습니다
- 강력한 기능을 자체 프로젝트에 활용합니다
- 사용자 경험이 개선됩니다
- 여러분도 충분히 이해할 수 있습니다
- 사용자에게 훨씬 적은 코드를 배포하세요
- 프레임워크에서 얻은 영감을 여러분의 프로젝트에 적용할 수 있습니다

‍♂️ 다양한 API 활용은 리액트 학습 문서를 참고하자

리액트에는 다양한 훅과 API가 존재한다. 하지만 모든 내용을 다룰 수는 없어, 핵심적인 부분만 다룬다. 따라서, 리액트에 대한 이해보다 리액트의 활용에 관심이 있다면, 앞서 언급한 학습 문서나 개발 문서가 더 큰 도움이 될 것이다. 추가적으로 최근 업데이트된 React 19의 변경 및 개선 사항에 대해서도 다루지 않는다.

마치며...

요즘 대부분의 웹 프론트는 프레임워크는 달라도, 대부분 React를 기반으로 개발된다. 따라서, 프론트엔드 개발자를 희망한다면 이 책을 읽어볼 것을 강력히 추천한다! 실습 소스를 찾아 링크를 첨부하려 했는데 아쉽게도 찾지 못했다. 그래서 혹시라도 본 책의 내용을 직접 실습해보고 싶은 이들을 위해 전문가를 위한 리액트 - 계획을 시작으로 아래 GitHub 레포에서의 실습을 진행 중에 있다. 참고하시길!

GitHub - ooMia/fluent-react: Designed for practicing the concepts and exercises from the book 'Fluent React (전문가를 위한

Designed for practicing the concepts and exercises from the book 'Fluent React (전문가를 위한 리액트)' - ooMia/fluent-react

github.com

Fluent React

Practicing the concepts and exercises from the book 'Fluent React'

oomia.github.io

6 - Foundry 기반 프로젝트

ooMia — Fri, 21 Feb 2025 00:19:15 +0900

Overview

5 - 스마트 컨트랙트 함수 호출

Overview 4 - 스마트 컨트랙트 개발 및 배포Overview 3 - 스마트 컨트랙트 개발 환경 셋업Overview 2 - DApp 개발 환경 셋업Overview DApp 만들기: 기본 개발 환경 셋업Overview DApp은 어떻게 만들 수 있을까요?O

spems.tistory.com

이전 시간까지는 최소한의 의존성만으로 DApp을 개발하기까지의 간단한 개발 Flow를 다루었습니다. Hello, World 프로젝트를 빌드하기까지 다양한 준비 작업들이 필요했지만, 한 번 준비가 끝난 이후부터는 번거로운 작업은 줄어듭니다. 그래서 이번 시간부터는 좀 더 기능이 많고, 큰 규모의 DApp을 만들기까지의 과정을 다룰 것입니다. 그 첫 번째 시간으로, Foundry 프레임워크를 프로젝트 안에 내장시키고, 스마트 컨트랙트에 대한 자동 배포 및 테스트를 진행하는 방법에 대해 알아봅시다.

case2-setup-foundry

본 포스트에서는 프로젝트가 설정된 상태에서, 각 설정을 이해하고 활용하기 위한 설명에 집중합니다. 이해한 내용을 바탕으로 자신의 필요에 따라 구조 또는 설정을 변경할 수 있다면 충분합니다.

두 번째 프로젝트를 위해 git checkout origin/case2-setup-foundry 명령으로 브랜치를 변경합시다. 직접 Forge 프로젝트를 생성하는 방법은 해당 공식 문서 - forge/#getting-started 를 참조하면 됩니다. 프로젝트 셋업을 희망하는 디렉토리 이름으로 forge init <DIR_NAME>를 실행하세요. ⚠️ 주의사항: 혹시라도 이미 초기화된 Git 저장소에 셋업을 진행하려면, 워크트리에 반영되지 않은 변경 사항이 없어야 합니다. 변경 사항을 모두 커밋하거나, git stash를 통해 임시 보관해두세요.

프로젝트 폴더 구조

원래 우리의 Hello, World 프로젝트는 src 내부에 node와 sol 폴더로 구분된 파일들을 활용했습니다. 이제 별도의 프레임워크를 내장시키면서 최상위 레벨의 foundry 폴더에 스마트 컨트랙트 개발과 관련된 모든 내용이 담깁니다. 또한 이를 하위 workspace로 선언하여, 관련 스크립트 명령들도 우리의 기존 웹 애플리케이션 프로젝트와의 작업 편의성을 위해, 명령들을 수행하게 됩니다.

지금부터 foundry 폴더를 톺아보며, 각 요소가 어떤 역할을 수행하는지 하나씩 살펴봅시다.

/Users/mia/hands-on-dapp
├── LICENSE
├── README.md
├── foundry
│   ├── README.md
│   ├── foundry.toml
│   ├── lib
│   │   └── forge-std
│   ├── package-lock.json
│   ├── package.json
│   ├── script
│   │   └── HelloWorld.s.sol
│   ├── src
│   │   └── HelloWorld.sol
│   └── test
│       └── HelloWorld.t.sol
├── node_modules
│   ├── (dependencies...)
│   └── foundry -> ../foundry
├── package-lock.json
├── package.json
└── src
    ├── index.html
    └── index.js

src 폴더

src 폴더는 우리가 작성한 컨트랙트 소스가 존재하는 곳입니다. 일반적으로 컨트랙트 이름을 파일명으로 하여, 한 파일에 하나의 컨트랙트를 작성하는 것이 권고됩니다. HelloWorld.sol 파일 내용을 살펴봅시다. 이전 컨트랙트와 비교했을 떄 달라진 점은 각각의 계정이 자신만의 이름을 설정할 수 있도록 setter/getter가 존재한다는 것입니다. 등록하지 않은 상태에서 조회하려고 하면 오류가 발생합니다. setter는 names라는 이름의 스토리지를 수정하기 때문에, 이벤트를 emit하여 변경 사항을 전파합니다. 이러한 기능을 어떻게 구현했는지 이해하기 위해서는 Solditiy 언어에 대한 이해가 필요합니다. 다만, 본 포스트에서는 우선 컨셉을 소개하는 것에 집중하므로 자세히 다루지 않습니다. 궁금하다면 우선은 공식 문서를 참고하세요! 구현 방법에 대해서는 나중에 자세히 다루도록 하겠습니다.

src/HelloWorld.sol

test 폴더

성공적으로 기능을 구현했음을 확인하는 방법 중 하나는 그냥 실제 서비스를 이용하는 것입니다. 우리의 경우에는 화면에 Hello, World!가 정상적으로 출력되는지, 브라우저로 서빙중인 웹 페이지에 접근해보는 것이겠죠? 다만, 이 방법은 소스 작성, 빌드, 배포 등 모든 작업을 다 진행한 뒤에 이루어지므로, 혹시라도 기능이 잘못 구현되거나 변경이 필요할 때, 그 모든 작업을 다시 수행해야 한다는 매우 큰 단점이 있습니다. 따라서, 우리는 소스를 작성하는 시점과 최대한 가까운 시점에 이러한 기능의 동작을 확인할 필요가 있습니다. 이 때 테스트를 활용한다면 개발 효율 및 소요 시간을 줄여 생산성을 높일 수 있습니다.

우리가 src에 작성한 소스가 예상한대로 동작하는지 확인하기 위해, 다양한 메서드를 활용할 수 있습니다. 역시나 구체적인 구현 방법에 대해서는 여기서 다루지 않습니다. 우선 Foundry에서 제공하는 Tests/CheatCodes를 참고하고, 나중에 좀 더 자세히 다루도록 하겠습니다.

test/HelloWorld.t.sol

script 폴더

이전에 작성했던 build.sh 파일의 내용을 기억하시나요? 프레임워크를 활용하여, 여러 번의 트랜잭션이 필요한 작업을 하나의 트랜잭션 스코프 안에 묶어 처리할 수 있습니다. 다음 스크립트는 L#11-18 vm.startBroadcast / vm.stopBroadcast 스코프 안에서 컨트랙트를 생성하고, 이후 배포자의 계정의 이름을 "World"로 설정합니다. 또한, getName을 호출하고, 우리의 설정 값과 동일한지 확인합니다. 만약 값이 다르다면 트랜잭션 내 모든 요청이 취소됩니다. ⚠️ 이 과정 중에 환경변수가 정의된 .env 파일을 참조하여, 배포에 활용할 개인키를 불러옵니다. 오류가 발생한다면 .env example 파일이 .env로 이름이 변경되어 있는지 확인해보세요!

script/HelloWorld.s.sol

이외에도 foundry.toml 설정, 외부 lib 설치로 다양한 설정 및 기능 확장이 가능합니다. 이번 프로젝트에서는 특별히 참고할만한 내용이 없으므로, 다음에 좀 더 자세히 다루도록 하겠습니다.

mono-repo

하나의 레포에서 다양한 프레임워크를 사용한다면, 이를 모두 연결하여 관리하는 것이 더욱 편리합니다. 이를 위해 Foundry 프로젝트에 package.json 파일을 생성하고, 이를 하위 workspace로 선언했습니다. forge의 다양한 명령은 현재 디렉토리 위치를 기반으로 실행되기 때문에, 이렇게 하지 않으면 옵션을 통해 명시적으로 설정해야 하는 경우가 많아져 DX를 해치게 됩니다.

package.json 그리고 foundry/package.json

이렇게 workspace 설정을 하면, 우리가 이전에 solc를 하위 모듈로 설치한 것처럼, 우리의 foundry 폴더 내용 또한 하위 모듈로 설정됩니다. 직접 확인해보고 싶다면 npm install 설치 후, node_modules 폴더에서 foundry 폴더를 찾아보세요!

마치며

이번 시간에는 foundry 프로젝트를 mono-repo 스타일로 내장시키는 방법에 대해 알아보았습니다. 앞으로 Solidity 개발에 대한 부분을 자주 다루게 될텐데, Visual Studio Code 확장으로 (1 JuanBlanco.solidity) 또는 (2 NomicFoundation.hardhat-solidity)를 설치하는 것을 추천드립니다. IDE 내 자동 정렬과 syntax 하이라이트 기능을 제공하니, 앞으로의 개발에 도움이 될 것이라 생각해요!

이번에 스마트 컨트랙트의 테스트를 수행해보았으니, 이제 웹 애플리케이션의 테스트도 해봐야겠죠? 다음 시간에는 playwright를 활용해서 페이지에 Hello, World가 정상 출력되는 것을 확인해보고, 스마트 컨트랙트 배포 과정과 연결하여 엔드투엔드(e2e) 테스트까지 작성해보도록 하겠습니다

5 - 스마트 컨트랙트 함수 호출

ooMia — Tue, 18 Feb 2025 19:27:58 +0900

Overview

4 - 스마트 컨트랙트 개발 및 배포

Overview 3 - 스마트 컨트랙트 개발 환경 셋업Overview 2 - DApp 개발 환경 셋업Overview DApp 만들기: 기본 개발 환경 셋업Overview DApp은 어떻게 만들 수 있을까요?OverviewDApp은 기존 Web 2.0의 중앙 집중식 구

spems.tistory.com

이전 시간에는 로컬 체인을 구동시키고, 스마트 컨트랙트를 작성하여 배포해봤습니다. 이번 시간에는 웹 서버를 가동시키고, 클라이언트에서 스마트 컨트랙트의 함수를 호출해서, 그 결과를 화면에 출력하는 작업에 대해 알아봅시다. 들어가기 앞서, 이 프로젝트는 의존성을 최대한 제거하여 동작 원리를 보여주는 것에 목적이 있습니다. 따라서, 지금 당장 이해가 가지 않는 부분이 있더라도 그냥 '그렇구나'하고 읽고 넘어가도 괜찮습니다. 단, 이전 시간에 실습했던 부분에서 이어지기 때문에, 1. Anvil이 동작 중인지 2. 스마트 컨트랙트를 배포했는지 확인하고 진행합시다.

실행 결과: 실제로는 좌측 상단에 위치

프로젝트 실행 순서 후반부

src/node/index.js

이번 프로젝트에서 서버의 역할은 단순히 사용자가 localhost:3000에 접근했을 떄, 클라이언트에게 HTML 파일을 반환하는 것입니다. node의 내장 모듈을 사용해서 요청 URL에 대한 라우트를 처리합니다. 알아두어야 할 점은 현재 모든 로직이 HTML 파일 내에 스크립트로 작성되어 있다는 것입니다.

/src/node/index.js

src/node/index.html

/src/node/index.html

L#4-55 <script type="module"> ... </script>
핵심 로직이 정의된 스크립트 스코프입니다.
L#5 import { AbiCoder } from ".../ethers.min.js"
서버 내부 결과 "World"가 비트 형식으로 반환되는데, 이를 문자열로 변환하기 위한 유틸 클래스입니다. CDN에서 가져오면 `ethers.js` 패키지를 설치하지 않고도 소스를 사용할 수 있습니다.
L#7-22 async function fetchJsonRpc( method, params ) { ... }
앞으로 HTTP 요청을 보낼 때 사용할 함수입니다. 8545번 포트에서 가동 중인 Anvil의 주소로 JSON-RPC spec에 따라 POST 요청을 전달합니다. 우리는 어떤 함수를, 어떤 파라미터와 함께 호출할지만 신경쓰면 됩니다.
L#25-29 eth_getBlockByNumber 로 첫 번째 블록의 첫 번째 트랜잭션의 해시 값을 가져옵니다.
이를 통해 우리가 스마트 컨트랙트를 배포한 트랜잭션을 참조할 수 있습니다.
L#31-34 eth_getTransactionReceipt 로 해당 트랜잭션 상세에서 배포된 컨트랙트의 주소를 가져옵니다.
이를 통해 컨트랙트의 함수를 호출할 수 있습니다.
L#36-41 eth_call 로 컨트랙트의 함수를 호출합니다. 함수 호출 시의 특이점은 함수의 명세를 Request Body로 전달해야 한다는 것입니다. cast sig "getName()" 을 실행해서 얻을 수 있는 값 0x17d7de7c는 SHA-3 keccak256 방식의 해싱 결과의 최상위 4 바이트를 취한 값입니다. 추가로 파라미터로 전달할 값이 없기 때문에, 이렇게 4 바이트만 전달하면 함수 호출이 가능합니다.
L#42 const name = new AbiCoder().decode(["string"], resultBytes)[0];
함수 호출 결과는 비트 형태로 전달됩니다. 앞서 2번째 단계에서 가져온 ether.js의 AbiCoder를 활용합니다. decode 메서드는 아래 이미지와 같이 전달된 비트에 대해 UTF-8 디코딩을 수행합니다.
L#43 document.getElementById("greeter").textContent = `Hello, ${name}!`;
스크립트가 비동기적으로 모두 실행되면, DOM을 직접 수정하여 사용자에게 Hello, World!를 출력합니다.

7: getName() 호출 결과: 32 Bytes 오프셋에 존재하는 5 Bytes 문자열 World (576f726c64, UTF-8)

L#45-51 브라우저 환경에서 F12 개발자 모드 > 콘솔을 열면, 요청 정보를 확인할 수 있습니다

마치며

지금까지 가장 기본적인 Hello, World!를 출력하는 DApp을 실습해보았습니다. 다소 번거롭지만 직접 HTTP 요청을 보내는 방식을 사용한 것은 이후 라이브러리를 활용해서 추상화되는 부분을 자연스럽게 다루기 위함이었습니다. 이후 과정부터는 좀 더 고도화된 개발 환경에서 풍부한 기능을 가진 DApp을 다룰 것이므로, 좀 더 직관적인 개발이 가능하니 기대해주세요! ☺️

향후 계획은 다음과 같습니다.

foundry 프로젝트 빌드업
hello.sol 기능 확장: 유저별 닉네임 등록 및 반환
forge test
forge script 기능으로 배포 시 자동 닉네임 등록
web3.js 활용, 고정된 계정으로 배포한 컨트랙트 주소 가져오기
jest: unit test/e2e test

4 - 스마트 컨트랙트 개발 및 배포

ooMia — Mon, 10 Feb 2025 22:16:26 +0900

Overview

3 - 스마트 컨트랙트 개발 환경 셋업

Overview 2 - DApp 개발 환경 셋업Overview DApp 만들기: 기본 개발 환경 셋업Overview DApp은 어떻게 만들 수 있을까요?OverviewDApp은 기존 Web 2.0의 중앙 집중식 구조에서 벗어나, 블록체인 기반의 탈중앙화

spems.tistory.com

이전 시간에는 DApp의 핵심이 되는 스마트 컨트랙트를 빌드하고 배포하기 위한 준비 작업을 진행했습니다. 이번 시간에는 스마트 컨트랙트를 작성하고, 빌드하고, 배포하는 작업을 이해해보겠습니다. 우리가 이번 포스트에서 다룰 내용은 빨간 테두리로 표시하였으니 참고하세요!

스마트 컨트랙트 작성

src/sol/hello.sol

SPDX-License-Identifier는 코드의 라이선스를 의미합니다.
이후 pragma solidity로 Solidity 컴파일러 버전을 지정합니다. 이 코드는 정확히 solc 0.8.28 버전에서 컴파일되어야 합니다만, semver 버저닝을 사용하여 호환 규칙을 정의할 수 있습니다.
contract는 class와 비슷하게 캡슐화된 형태로 함수와 변수를 포함하게 됩니다. 여기서는 HelloWorld라는 이름의 스마트 계약이 정의되어 있네요니다.
이후 function 키워드를 시작으로 getName이라는 이름의 함수를 정의합니다. public으로 선언되어 있어 외부 및 내부에서 호출할 수 있으며, pure로 선언되어 있어 블록체인의 상태를 읽거나 변경하지 않습니다. 또한 메모리 위치에서 문자열 "World"를 반환합니다.

스마트 컨트랙트 빌드 및 배포

src/sol/build.sh L#1-14

!/bin/sh는 스크립트가 sh 셸에서 실행되어야 함을 명시합니다.
export 명령을 통해 9번째 Anvil 관리자 계정의 개인 키를 환경 변수 PRIVATE_KEY에 설정합니다.
개인 키가 있어야만 계정 권한이 필요한 작업 - 예를 들어, 스마트 컨트랙트 배포 작업을 진행할 수 있습니다.
또한, 일정 수준 이상의 자산이 있어야만
다음 export TARGET 명령을 통해 배포된 스마트 컨트랙트의 주소를 TARGET에 저장합니다.
1. forge create 명령은 스마트 컨트랙트 배포를 위한 foundry 도구 forge의 하위 명령어입니다.
  어떤 파일에서 어떤 컨트랙트를 배포할 지 명시해야 하고, 이 부분은 find src 명령과 콜론 :으로 전달합니다.
2. -r localhost:8545로 로컬에 실행 중인 Anvil의 RPC URL을 전달합니다.
3. --private-key $PRIVATE_KEY로 배포에 사용할 개인 키를 지정합니다.
  이를 통해 9번째 Anvil 관리자 계정이 스마트 컨트랙트를 배포하게 됩니다.
4. --broadcast는 배포 트랜잭션을 브로드캐스트합니다.
  이 옵션을 사용하지 않으면 빌드 후 어떻게 전파될 것인지 정보가 로컬에 저장된 상태로 명령이 종료됩니다. 배포를 확정한 상황에서 이를 네트워크의 다른 노드로 전파하기 위해 사용됩니다. 로컬에는 메타 데이터와 컨트랙트의 바이트 코드가 저장됩니다. 기회가 되면 좀 더 자세히 다루도록 하겠습니다.
5. grep과 sed 명령어는 배포된 계약의 주소를 추출하여 TARGET 변수에 저장합니다.

++ 스마트 컨트랙트 함수 호출

src/sol/build.sh L#16-18

다음 DEBUG 주석이 붙은 부분은 빌드와는 관련이 없고, foundry 도구 cast의 명령을 활용하여 배포된 계약의 getName 함수를 호출하는 확인용 명령입니다. \x1b[32m과 \x1b[0m는 출력 텍스트를 녹색으로 설정하고, 이후 기본 색상으로 되돌립니다. cast call $TARGET "getName()(string)"는 TARGET 주소의 계약에서 getName 함수를 호출합니다. 뒤에 따라오는 (string)은 해당 함수의 결과을 string 형태로 반환하도록 만듭니다. 아래 로그를 확인해보면 정상적으로 "World"가 반환되는 것을 확인할 수 있습니다.

빌드 스크립트를 실행했을 때, 터미널에 출력되는 로그는 아래와 같습니다. 이를 통해 TARGET 변수에는 0x700b6A60ce7EaaEA56F065753d8dcB9653dbAD35 값이 저장될 것이라고 예상할 수 있습니다.

0x와 같은 표현은 16진수를 표현할 때 사용하는 접두사입니다. 우리가 일상에서 10을 기준으로 자리수를 늘려 사용하는 십진수와 같은 원리로, 16진수는 0~9 그리고 A(10)부터 F(15)를 사용해서 16을 기준으로 자리수를 늘리는 수 체계입니다. 이러한 수 체계는 비트를 최소 저장 단위로 사용하는 컴퓨터 체계에서, 애매한 10진수보다 정확히 4비트씩 나누어 수를 저장할 수 있다는 장점이 있습니다. 참고로 3비트씩 끊어 접두사 0을 붙이고 8진수로 취급하기도 합니다.

❯ npm run start

> prestart
> anvil --allow-origin 'http://localhost:3000' & npm run build



                             _   _
                            (_) | |
      __ _   _ __   __   __  _  | |
     / _` | | '_ \  \ \ / / | | | |
    | (_| | | | | |  \ V /  | | | |
     \__,_| |_| |_|   \_/   |_| |_|

    0.3.0 (5a8bd89 2024-12-20T08:45:53.195623000Z)
    https://github.com/foundry-rs/foundry

Available Accounts
==================

...
(9) 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 (10000.000000000000000000 ETH)

Private Keys
==================

...
(9) 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6

...

Listening on 127.0.0.1:8545

> build
> sh src/sol/build.sh

eth_chainId
eth_getTransactionCount
eth_estimateGas
eth_feeHistory
eth_sendRawTransaction
eth_blockNumber

    Transaction: 0x06127d6cd32b232f5ccbdf4a582a4e20c396e04b34a3b581d0857852a72e9a74
    Contract created: 0x700b6A60ce7EaaEA56F065753d8dcB9653dbAD35
    Gas used: 95617

    Block Number: 1
    Block Hash: 0x693eb072e1524e938dcdf12aff517690e691f75bbd39a4643ba9040a31297820
    Block Time: "Mon, 10 Feb 2025 12:26:44 +0000"

eth_getBlockByNumber
eth_getTransactionReceipt
eth_getTransactionReceipt
eth_chainId
eth_getTransactionCount
eth_call
"World"

> start
> node src/node/index.js

Server is running on http://localhost:3000

마치며

지금까지 스마트 컨트랙트를 작성하고, 빌드 및 배포하고, 함수를 호출해보는 과정을 간단히 다루었습니다! 여기서 알고 있어야 하는 점은 DApp의 본질은 체인과 스마트 컨트랙트와의 상호 작용에 의존적이지만, 그 빌드 및 배포 과정이 굳이 웹 애플리케이션과 동기적으로 이루어질 필요는 없다는 것입니다. 즉, 이미 배포된 컨트랙트를 활용하는 것도 가능합니다.

다음 시간에는 웹 애플리케이션에서의 스마트 컨트랙트 함수 호출에 대해 다룰 것입니다. 이번에 다루었던 cast call 명령은 foundry 도구를 활용한 것인데, 이러한 도구나 라이브러리 없이도 본질적으로 규악에 맞는 통신을 수행하여 얼마든지 함수를 호출할 수 있음을 알 수 있게 될 것입니다. 그럼 다음 포스트로 만나요~ ☺️

3 - 스마트 컨트랙트 개발 환경 셋업

ooMia — Mon, 10 Feb 2025 12:54:19 +0900

Overview

2 - DApp 개발 환경 셋업

Overview DApp 만들기: 기본 개발 환경 셋업Overview DApp은 어떻게 만들 수 있을까요?OverviewDApp은 기존 Web 2.0의 중앙 집중식 구조에서 벗어나, 블록체인 기반의 탈중앙화된 방식으로 동작하는 애플리

spems.tistory.com

이전 시간에는 Foundry와 Node.js를 설치하며 기본적인 DApp 개발 환경을 구축했습니다. 이번 시간에는 DApp의 핵심이 되는 스마트 컨트랙트를 빌드하고 배포하기 위한 필요한 작업에 대해 알아봅시다.

브랜치 변경

GitHub - ooMia/hands-on-dapp: 블로그 연재 중인 DApp 제작 가이드 레포

블로그 연재 중인 DApp 제작 가이드 레포. Contribute to ooMia/hands-on-dapp development by creating an account on GitHub.

github.com

이전 1 - 기본 개발 환경 셋업에서 설치한 hands-on-dapp 레포가 복사된 디렉토리로 이동합시다.

readme.md의 안내에 따라 git checkout case1-hello-world 를 실행합니다.

cd hands-on-dapp && pwd && git checkout case1-hello-world

README.md

code . 를 실행하면 현재 디렉토리에 대해 VIsual Studio Code를 실행합니다. 개발 관습 상, 프로젝트에 대한 설명을 README.md 파일에 작성하니, 습관적으로 확인합시다. 주어진 mermaid를 통한 다이어그램은 여러분이 위에 적힌 npm install && npm start 를 실행했을 떄, 프로젝트가 어떻게 동작하는지에 대한 대략적인 동작 방식을 표현하고 있습니다.

code .

++ 저와 동일한 화면이 나오지 않을 수 있습니다. 크게 세 가지 이유가 있는데,

Mermaid 문법의 미리보기는 확장 프로그램을 설치해야만 제대로 동작합니다. 필요에 따라 Markdown Preview Mermaid Support를 설치하거나, 그냥 GitHub 미리보기를 활용하더라도 무관합니다.
폰트의 차이가 있습니다. 두 문자 ->를 한 문자 →처럼 보이도록 하는, 합자 기능을 가진 폰트를 사용할 수 있습니다. Fira-code 또는 Monaspace 같은 폰트가 있겠네요.
VS Code 자체의 개인화된 설정 차이입니다. IDE의 테마라든지, 바의 위치와 구성 등 원하는대로 변경할 수 있습니다. ⌘ + ⇧ + P (cmd + Shift + P)를 누르고, ui를 입력한 뒤, 기본 설정을 열어 여러분만의 설정으로 변경해보세요!

⌘ + ⇧ + P (cmd + Shift + P)

프로젝트 준비 단계를 하나씩 진행하며 각 단계를 이해해봅시다.

package.json

node 기반 프로젝트에서 다음으로 봐야 할 것은 package.json 파일입니다. 이 파일을 통해 명령어를 정의하고, 필요한 의존성을 명시하고, 기타 다양한 메타 정보를 설정하게 됩니다. 현재로서는 깊게 들어가지 않고, 핵심적인 부분 두 가지만 짚고 넘어가겠습니다.

pre-와 post-라는 접두사의 의미와 같이, 우리가 npm start를 실행하면, prestart - start - poststart 순서로 실행됩니다. 이를 고려하여 이전 README.md의 다이어그램을 다시 한 번 살펴보세요. [참고: Life Cycle Scripts ]
Dependencies와 달리, devDependencies는 개발 시점에만 필요한 의존성을 정의합니다. 따라서, 우리의 Hello, World! DApp은 native Node 서버임을 알 수 있습니다.

package.json

npm install

명령을 실행하면 앞서 개발 의존성으로 명시된 0.8.28 버전의 solc 패키지가 설치됩니다. 그리고 package-lock.json 파일과 node_modules 폴더가 생성되는데, package-lock.json은 의존성 패키지 트리를 정의하는데 사용되고, 모든 의존성은 node_modules 폴더 내에 로컬로 다운로드됩니다. 쉽게 말하면, 우리가 라면을 끓이는 프로젝트를 할 떄, 라면과 조리도구를 의존성에 명시하고 구매하면, 각각 라면은 건더기/스프/면, 조리도구는 냄비/젓가락/버너라는 하위 의존성까지 자동적으로 구매하는 것과 동일한 느낌입니다.

아래 이미지의 node_modules 내 폴더 이름을 살펴보면, 우리는 solc만 다운로드 받은 줄 알았는데, 다른 패키지들도 설치된 것을 볼 수 있습니다. 이들 중 대다수는 solc의 의존성으로 명시되어 있고, os-tmpdir 패키지만 tmp 패키지에 대한 의존성으로서 설치된 것을 알 수 있습니다. 우리가 설치한 solc는 Solidity 파일의 컴파일을 도와주는 역할을 맡고 있습니다. 자세한 내용은 다음 포스트에서 다루도록 할게요! 궁금하다면 installing-solidity 참고!

solc 0.8.28 그리고 하위 의존 패키지들

npm start (prestart - start - poststart)

npm start는 Node 기반 프로젝트에서 관습적으로 실행을 의미하는 명령어입니다. 단, Script 생명 주기에 따라 prestart가 먼저 실행되겠네요. 이를 통해 anvil이 실행되고, build 명령이 수행됩니다.

npm run prestart

anvil --allow-origin 'http://localhost:3000'

Anvil은 우리가 이전 포스트에서 설치했던 Foundry의 일부입니다. DApp 개발 목적으로 활용되는 이더리움 로컬 노드인데요, 헷갈리지 않아야 하는 부분은 '노드'의 의미가 다르다는 것입니다. 마치, Java와 JavaScript의 차이처럼 이름만 비슷할 뿐 컨셉은 완전 다른데요, Node.js가 브라우저 없이도 JavaScript를 실행할 수 있도록 돕는 런타임이라면, 이더리움 노드는 이더리움 클라이언트 소프트웨어를 실행하는 이더리움 블록체인 네트워크를 구성하는 서버 개체입니다.

좀 더 상세히 들어가면, 블록체인은 독립된 개체들 간의 검증, 합의 그리고 합의 결과의 승인으로 데이터의 무결성을 준수합니다. 이 떄, 어떻게 검증하고, 합의하고, 결과를 받아들일 것인지 이더리움 클라이언트에 정의했습니다. 즉, 이더리움 클라이언트는 프로토콜(Protocol)이고, 이더리움 노드는 해당 프로토콜로 통신 가능한 개별 서버와 유사합니다. 그래서 핵심은 뭐다? 이게 Anvil이라는 서버에 살고 있는 무언가가 결국 Web2와 Web3의 차이를 만든다는 점! 궁금증이 해소되지 않는다면 what-are-nodes-and-clients를 참조하시고, 더 자세한 내용은 이론이 필요한 단계 - 예를 들어, 스마트 컨트랙트 보안 파트에서 다루도록 하겠습니다.

블록체인의 노드들은 기본적으로 표준화된 형태의 JSON-RPC API를 제공합니다. 해당 용어는 세 가지 부분으로 나누어 이해할 수 있어요. JavaScript Object Notation(JSON)은 말 그대로 JavaScript 내에서 Object를 정의할 때 사용하는 문법 또는 표준 형식을 의미하고, 중괄호 { } 안에 키와 값을 콜론 :으로 나누어 재귀적으로 할당할 수 있습니다. 참고 JSON으로 작업하기 일반적으로 Application Programming Interface(API)는 서로 다른 소프트웨어 간의 기능 호출을 위한 창구가 되는데, 앞에 Remote Procedure Call(RPC)이 붙으면 컴퓨터 B에서 컴퓨터 A의 프로세스에 대한 기능 호출이 가능하다는 의미로 확장돼요. 즉, 서로 다른 컴퓨터 간 기능 호출이 가능하다는 것이죠. 세 개를 합치면, 다른 소프트웨어 및 컴퓨터에서 내 컴퓨터의 소프트웨어의 기능을 실행할 수 있는 JSON 형태의 소통 창구 정도로 표현할 수 있겠네요.

다만, 모르는 컴퓨터가 내 IP를 알아내서 갑자기 기능을 실행해선 안 되겠죠? 그래서 브라우저는 Same-origin Policy(SOP)에 기반해서 악의적인 사이트로부터의 스크립트 실행을 막습니다. 호스트가 같아도, 포트가 다르면 다른 출처로 취급되기 떄문에, 우리의 경우에는 3000번 포트를 허용 가능한 출처로 명시하는 것이 바람직합니다. 자세한 내용은 동일 출처 정책을 참고하세요! 정보) Anvil은 기본적으로 모든 호스트로부터의 통신을 허용하니 설정하지 않더라도 동작합니다. 그리고 사실 개발용 노드는 경제적 가치가 없기 때문에 크게 걱정하지 않아도 됩니다. 나중에 CORS 문제가 발생했을 때, 서버의 정책과 클라이언트의 요청을 확인해보세요!

클라이언트가 다른 출처로부터의 자원을 허용하기 위해서는 어떻게 해야 할까요? 단순히 클라이언트가 원한다고 되는 것이 아니고, 서버에서 알맞은 CORS 설정을 해주어야 합니다. 이러한 맥락에서, 실행한 명령어 anvil -- 뒤에 명시된 allow-origin 옵션은 Cross Origin Resource Sharing(CORS, 교차 출처 자원 공유) 방식에 따라 허용하고 싶은 호스트를 정의하기 위한 옵션이에요. remote에서 첫 번쨰 사진처럼 preflight를 전송하여 origin 서버의 정책을 확인하고, 응답 헤더를 받아 그에 맞게 동작합니다. 필요하다면 Dreamhack의 CORS 취약점 강의를 수강하는 것도 이해에 도움이 될 거에요!

좌) allow-origin 옵션 설정 후 Preflight 요청 // 우) 옵션 비활성화 상태의 기본 응답 헤더 -

마치며

지금까지 스마트 컨트랙트를 빌드하기 위해 solc를 준비하고, 배포하기 위한 노드를 실행하여 RPC-API URL(localhost:8545)을 확보했습니다! 지금은 우리가 직접 개발용 노드를 실행했지만, 나중에는 동작중인 노드의 URL만 얻으면 동일한 작업이 가능합니다. 실행 중인 다양한 이더리움 노드를 찾아볼 수 있는 사이트들이 많은데, ChainList가 대표적입니다. HTTPS 외에도 웹 소켓 프로토콜 wss도 보이죠? 빠르고 잦은 상호작용을 위한 선택이라 생각하면 될 것 같습니다.

다음 시간에는 본격적으로 스마트 컨트랙트가 무엇인지, 빌드하고, 배포하고, 함수를 호출해보도록 하겠습니다! ☺️

2 - DApp 개발 환경 셋업

ooMia — Sun, 9 Feb 2025 14:12:58 +0900

Overview

DApp 만들기: 기본 개발 환경 셋업

Overview DApp은 어떻게 만들 수 있을까요?OverviewDApp은 기존 Web 2.0의 중앙 집중식 구조에서 벗어나, 블록체인 기반의 탈중앙화된 방식으로 동작하는 애플리케이션을 의미합니다. 본 포스트에서는

spems.tistory.com

이전 시간에는 git, GitHub, VS Code를 설치하며 기본적인 개발 환경을 구축했습니다. 이번 시간에는 본격적인 DApp 개발에 앞서, 이를 위해 필요한 도구를 설치하는 작업을 수행해봅시다.

DApp 개발 환경 셋업

1. Foundry

파운드리(Foundry)는 러스트(Rust) 언어 기반 스마트 컨트랙트 개발 도구입니다.
따라서, 먼저 Rust 컴파일러와 패키지매니저를 설치합니다.
curl https://sh.rustup.rs -sSf | sh -s

이후 아래의 명령을 차례대로 실행하세요

curl -L https://foundry.paradigm.xyz | bash
source ~/.bashrc 
foundryup
which forge && forge -V

명령 curl -L https://foundry.paradigm.xyz | bash 을 실행합니다.
bash 셸을 사용하지 않는다면, bash를 이용 중인 셸 이름으로 변경하여 실행해주세요.
ex) curl -L https://foundry.paradigm.xyz | sh
스크립트가 정상적으로 실행되었다면, foundry 바이너리 위치가 PATH에 등록됩니다.
현재 터미널 세션에도 변경한 설정이 반영되도록 재시작해줍니다.
기본 셸에 따라 파일명이 변경된 상태로 안내가 진행되니, 잘 읽고 이에 맞춰 진행하면 됩니다.
ex) .bashrc .zshrc ... 등 설정 기반 재실행
foundryup 을 실행합니다.
which forge && forge -V 를 실행합니다.
forge의 위치와 버전이 출력된다면 성공!

which forge && forge -V

2. Node.js

Node.js는 Chrome V8 JavaScript 엔진을 기반으로 하는 JavaScript 런타임입니다. 쉽게 말하자면, 브라우저 없이도 JavaScript 파일을 실행할 수 있게 되는 것이죠. NPM(Node Package Manager)은 이러한 Node.js의 기본 패키지 관리자로서, JavaScript 패키지의 설치, 버전 관리 및 의존성 관리를 쉽게 할 수 있도록 도와줍니다. Node.js를 설치할 때, 자동으로 함꼐 설치되니 신경쓰지 않아도 괜찮아요. 최근에는 Node 버전 관리의 편의성을 위해 NVM(Node Version Manager)를 함께 사용합니다. 필요에 따라 원하는 버전으로 쉽게 변경할 수 있도록 도와줍니다.

다음 공식 사이트에서 발췌한 설치 방식을 따라가봅시다. 이번에도 이전과 마찬가지로 bash 셸을 사용하지 않는다면, 자신이 사용하는 셸의 이름으로 변경해주면 됩니다.

# nvm 다운로드 및 설치:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

# Node.js 다운로드 및 설치:
nvm install 22

# Node.js 버전 확인:
node -v # "v22.13.1"가 출력되어야 합니다.
nvm current # "v22.13.1"가 출력되어야 합니다.

npm 버전 확인:
npm -v # 10.9.2가 출력되어야 합니다.

Node.js — Node.js® 다운로드

Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.

nodejs.org

마치며

뭘 이렇게 많이 설치해야해? 라고 생각하실 수도 있겠지만, 아직 기본적인 것도 다 다루지 못했다는 점... 오히려 직접 모든 것을 개발하기보다, 이미 개발된 오픈소스 라이브러리를 잘 활용하는 능력 또한 중요하다는 것을 기억해둡시다!

다음 시간에는 복제한 레포에서 branch를 변경하고, 준비된 Hello, World! DApp을 로컬에서 실행해보는 실습을 진행해보겠습니다

1 - 기본 개발 환경 셋업

ooMia — Wed, 5 Feb 2025 22:20:33 +0900

Overview

DApp은 어떻게 만들 수 있을까요?

OverviewDApp은 기존 Web 2.0의 중앙 집중식 구조에서 벗어나, 블록체인 기반의 탈중앙화된 방식으로 동작하는 애플리케이션을 의미합니다. 본 포스트에서는 이론과 개념보다는, '그래서 어 떻게 만

spems.tistory.com

이전 시간에는 DApp을 만드는 간단한 과정에 대해 살펴보았습니다. 이번 시간에는 개발을 위한 최소한의 개발 환경 설치 과정을 다룹니다. 개발을 처음 시작하는 이들을 위한 가이드인 만큼, 하나부터 열까지 모두 모른다고 가정하고 진행하겠습니다.

⚠️ Notice
시간이 지남에 Breaking Changes는 발생하고, 여러분이 개발을 시작한 시점에는 예상했던 방식대로 동작하지 않을 수 있습니다. 오류가 발생하거나 사용에 불편한 점이 있다면 편하게 GitHub Issue로 남겨주세요!

개발 환경 셋업

이 가이드는 기본적으로 MacOS를 사용하는 유저를 대상으로 기획되었으며 Homebrew로 대부분의 설치를 진행합니다. 따라서, Linux 사용자는 Homebrew-on-Linux를 통해 설치하면 되고, Windows 사용자는 WSL2을 통해 일반 Linux 사용자와 동일하게 설치하시면 됩니다. 아래 링크를 참조하세요!

Windows WSL2로 Homebrew 사용하기

MacOS 사용자를 위한 패키지 매니저 Homebrew를 Windows WSL 환경을 통해 간접적으로 설치하고 이용해봅시다.

velog.io

1. Git

우리가 간직하고 싶은 순간을 사진으로 남기면 훗날 돌이켜보며 회상할 수 있는 것처럼, 개발 중에 의미있는 시점을 기록해두면 언제든 돌아갈 수 있어 유용합니다. 이러한 작업을 형상 관리 또는 Version Control로 지칭하는데, 이러한 작업을 수행하는데 Git은 전세계가 애용하는 소프트웨어입니다.

⌘ + ␣ (cmd + space) 를 눌러 spotlight 검색을 활성화합니다.
terminal 을 입력하고 실행합니다.
git -h 로 git이 설치되어 있는지 확인합니다.
도움말이 활성화되지 않는다면, brew install git 으로 설치합니다.

git -h

최초 설정

다음 링크를 참조하여 사용자 정보와 사용할 편집기를 설정합니다. 명령어 형식은 다음과 같아요.

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git config --global core.editor emacs

git config --list 명령을 실행하면 설정 내용을 모두 확인할 수 있어요. 다른 설정들도 많지만 우선 무시하셔도 됩니다.

git config --list

2. GitHub

GitHub는 Git 저장소 호스팅 서비스인데, 쉽게 말하면 Git 프로젝트 전용 구글 드라이브라 생각하면 됩니다. 우리 컴퓨터의 용량을 절약하고, 다른 이들과의 프로젝트 협업을 원활하게 만들어주죠. 개인 이메일을 통해 가입하면 됩니다.

여러분들의 빠른 시작을 위해 제가 템플릿을 만들었으니, 이걸 복사해서 사용할 계획입니다. 보통 git clone 명령을 사용하는데, 우리는 나중에는 각자 만든 DApp을 GitHub Pages를 통해 배포할테니 독립적인 레포를 만들 수 있도록 이번에는 fork 할 예정입니다.

brew install gh
CLI를 통해 작업할 수 있도록 gh 패키지를 설치합시다.
gh auth login 아래 첫 번째 이미지처럼 선택하고, 열린 브라우저 창에 터미널에 제공된 일회용 코드를 입력하면 성공!
gh repo fork oomia/hands-on-dapp --clone
공개된 저장소를 복사하면, 명령을 실행하는 현재 위치를 기준으로 'hands-on-dapp' 폴더가 생성됩니다.
cd hands-on-dapp && ls
두 번째 이미지처럼 두 개의 파일이 보인다면 성공입니다!

gh auth login

cd hands-on-dapp && ls

3. Visual Studio Code

이제 IDE를 설치하고 본격적인 작업을 시작해봅시다.

brew install --cask visual-studio-code
code .
다음과 같이 두 개의 파일이 보이면 됩니다.

code .

마치며...

이상 개발에 필요한 정말 기초적이고 간단한 환경 설치 과정을 다루었습니다. CLI 기반으로 다양한 명령어를 수행하는 작업은 귀찮지만 앞으로도 계속 진행해야하니 빨리 익숙해지면 좋을 것 같아요. 복사/붙여넣기에 팁이 있다면, Windows에서는 Win + v , MacOS에서는 Flycut 등의 유틸리티 도구를 통해 클립보드 히스토리 기반 붙여넣기가 가능합니다. 또 Windows에서는 Ctrl + ⌫ , MacOS에서는 ⌥ + ⌫ 로 단위별 지우기가 가능합니다. 이 밖에도 다양한 명령어와 단축키를 잘 익혀두면 개발이 더 빨라지겠죠?

다음 시간에는 Foundry와 Node.js를 설치하여 기본적인 DApp 개발 환경까지 준비해보도록 하겠습니다

0 - DApp은 어떻게 만들 수 있을까요?

ooMia — Tue, 4 Feb 2025 23:28:45 +0900

Overview

DApp은 기존 Web 2.0의 중앙 집중식 구조에서 벗어나, 블록체인 기반의 탈중앙화된 방식으로 동작하는 애플리케이션을 의미합니다. 본 포스트에서는 이론과 개념보다는, '그래서 어 떻게 만드는지'에 집중하고자 합니다. 우선, 가볍게 느낌만 참고하면서 따라오세요!

1. 어떤 체인 위에서 구동시킬지 선택하세요

각각의 블록체인에는 핵심적인 특징과 장단점이 존재합니다. 따라서, 실제 운영 시에는 목적에 맞는 체인을 선택하는 것이 좋지만, 여기서는 가장 보편적으로 사용되는 체인 '이더리움(Ethereum)'을 사용하겠습니다.

이더리움의 종합 안내서

이더리움은 디지털 화폐와 새로운 형태의 애플리케이션을 위한 글로벌 분산형 플랫폼입니다. 이더리움에서는 디지털 화폐를 제어하는 코드를 작성할 수 있고, 전 세계 어디서나 접속 가능한 애

ethereum.org

2. 개발 환경을 셋업하세요

좋은 DApp 개발 도구들이 잘 개발되어 있습니다. JavaScript 기반의 웹 개발 환경으로의 이식성을 생각하면 Hardhat이 개발 프레임워크로서는 더 나은 선택이 될 수 있겠지만, 여기서는 '파운드리(Foundry)'를 사용하도록 하겠습니다.

Foundry

Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust. - Foundry

github.com

소프트웨어를 개발하려면 소스 코드를 작성해야겠죠? 통합 개발 환경(IDE)을 사용하면 빠르고 쾌적한 개발이 가능합니다. Remix 또한 매우 편리하고 유용하지만, 여기서는 가장 대중적인 '비주얼 스튜디오 코드(Visual Studio Code)'를 사용하도록 할게요. 기회가 된다면 Remix 바이너리를 로컬에서 실행하여, 실제 개발에 활용하는 방법도 간단히 다루도록 하겠습니다.

Visual Studio Code - Code Editing. Redefined

Visual Studio Code redefines AI-powered coding with GitHub Copilot for building and debugging modern web and cloud applications. Visual Studio Code is free and available on your favorite platform - Linux, macOS, and Windows.

code.visualstudio.com

DApp은 지갑으로 불리는 각 계정 간의 상호작용을 기반으로 동작합니다. 회원 로그인이 필요한 서비스와 유사하다고 생각하면 됩니다. 계정을 관리하고 연결하는 가장 대표적인 방법은 브라우저 확장 '메타마스크(MetaMask)'를 사용하는 것입니다.

The Ultimate Crypto Wallet for DeFi, Web3 Apps, and NFTs | MetaMask

Secure and User-Friendly Crypto Wallet for NFTs and Digital Tokens. Dive into DeFi and Blockchain Seamlessly.

metamask.io

3. 개발 방법을 익히세요

위에 언급한 도구들 외에도, 프로그래밍 언어에 대한 숙련도가 필요합니다.

이더리움에서는 스마트 컨트랙트(Smart Contract)를 통해 신뢰할 수 있는 상호 작용이 가능합니다. 자판기에 판매원이 없는 것처럼, 계약은 제 3자의 개입 없이도 강제성을 부여하죠. 이더리움은 이러한 계약을 '솔리디티(Solidity)' 언어로 작성하고, solc로 컴파일 할 수 있도록 만들었습니다. Vyper를 사용하면 Python 기반으로 계약을 작성할 수도 있지만, 본 포스트에서는 다루지 않습니다. 또 기본적인 웹 애플리케이션 개발 능력이 필요하지만, 이 부분은 핵심에만 집중할 수 있도록 템플릿 코드를 지원할 계획입니다.

Home | Solidity Programming Language

Solidity is a statically-typed curly-braces programming language designed for developing smart contracts that run on Ethereum.

soliditylang.org

공식 문서를 참고하며 간단한 실습을 진행해봅니다. 혹시라도 무엇을 해야할지 잘 모르겠다면, rareskills와 같이 잘 준비된 학습 플랫폼 또는 roadmap.sh의 로드맵 가이드를 이용하는 것도 방법입니다. 이더리움은 스마트 컨트랙트가 모든 컴퓨터에서 실행 가능하도록 별도의 가상 머신(EVM) 위에서 연산을 수행하는데, 이런 부분이 낯설게 느껴진다면 evm.codes의 간단한 시뮬레이션 기능을 통해 익숙해져 보세요. 또한 Dreamhack은 보안과 관련된 학습과 워게임을 풀 수 있는 학습 플랫폼인데, 문제를 해결하며 성취감과 함께 동작 원리를 익혀나갈 수 있습니다. Nnode Guardians, Ethernaut에서도 다양한 문제를 찾아볼 수 있으니 참고하세요!

해커들의 놀이터, Dreamhack

dreamhack.io

4. 스마트 컨트랙트를 배포하고, 웹 애플리케이션에서 활용하세요

기본적으로 체인 사용에는 비용이 발생합니다. 돈이 없다고요? 걱정하지 마세요. 테스트용 네트워크의 자산은 Faucet을 통해 시간을 들여 무료로 얻을 수 있답니다. 여기서는 Ethereum Sepolia Testnet을 사용하도록 하겠습니다. 개발 도구를 사용하여 컨트랙트 배포부터 초기화까지, 모든 과정을 자동화 해봅시다. 제대로 수행했는지 확신이 안 선다면 Block Explorer에서 이를 확인하세요.

TESTNET Sepolia (ETH) Blockchain Explorer

Etherscan allows you to explore and search the Sepolia blockchain for transactions, addresses, tokens, prices and other activities taking place on Sepolia (ETH)

sepolia.etherscan.io

스마트 컨트랙트 활용을 보조하는 다양한 라이브러리들이 많습니다. 최근 꾸준한 업데이트와 일부 성능적인 이유로 ethers.js를 사용하는 추세가 증가하고 있다고 합니다만, 처음은 web3.js로 시작하시는 것을 추천드립니다. 제 생각에는 web3.js 문서가 더 뉴비 친화적인 것 같아요. 타입스크립트를 사용한다면 viem도 고려해볼 수 있습니다.

5. 나의 멋진 DApp을 친구들과 함께 사용해보세요

DApp 서비스 운영의 어려움 중 하나는 설계 허점을 막는 것이 어렵다는 것입니다. 친구들과 서로의 앱을 이용하며 불편함 또는 보안 이슈를 공유해보세요. 이러한 문제를 보완하기 위한 개발 패턴과 OpenZepplin 라이브러리의 활용 방법에 대해서도 알아봅시다.

OpenZeppelin | Solidity Contracts

OpenZeppelin Contracts helps you minimize risk by using battle-tested libraries of smart contracts for Ethereum and other blockchains. It includes the most used implementations of ERC standards.

www.openzeppelin.com

마치며

이상 DApp 개발에 필요한 과정과 요소를 간단하게 알아보았습니다.

사실 이것 외에도 생산성을 위한 IDE 확장이나 협업을 위한 Git 사용 등의 디테일도 중요하고, 보안 취약점을 탐지해주는 도구를 활용하는 방법을 익히는 것도 중요합니다. 그래도 우선 최소한의 지식으로 단순한 기능을 구현하는 것을 목표로 작업하려 합니다.

각 단계에 대한 자세한 가이드로 다시 만나요!

UDC 2024 Conference 후기 (2)

ooMia — Thu, 9 Jan 2025 22:00:44 +0900

UDC 2024 Conference 후기 (1)

업사이드 아카데미의 마지막 공식 일정은 Upbit Developer Conference (이하 UDC) 에서 막을 내렸다! 재밌고 신기했던 신라호텔에서의 UDC 후기, 지금 바로 시작합니다 11월 13일 수요일 (D - 1) 이 날

spems.tistory.com

이전 포스트에 이어 발표 내용에 대한 후기를 정리합니다.

1️⃣ 제타체인

ZetaChain: The First Universal Blockchain | Build Interoperable dApps with the Universal EVM

With its Universal EVM, ZetaChain is an L1 blockchain for chain abstraction. Build simple, secure, universal apps that span any chain from Ethereum and Cosmos to Bitcoin and beyond.

www.zetachain.com

발표에 대한 감상을 늘어놓기 전에, 먼저 생태계의 현 상황에 대한 간단한 설명을 해보고자 한다. 블록체인 공부 초반에는 "결국 정보 조작이 매우 어려운 공개형 데이터베이스네?"와 같이 모든 체인을 뭉뚱그려 과소평가했다. 하지만 더 깊이 공부할수록 굉장히 다양한 체인들이 존재함을 알게 되었다. 또 그 수가 너무 많아서 그들 사이에서는 돋보이기 위한 컨셉을 중요하게 여긴다는 것을 알게 되었다.

다양한 체인이 생겨난다는 것. 물론 생태계의 파이가 커진다는 관점에서는 긍정적이지만 분명 문제도 존재한다. 우선, 각 체인을 사용하는 Native Token 종류를 기준으로 나눈다고 했을 때, 서로 다른 체인 간에는 기본적으로 통신이 단절되어 있다. 즉, A 체인과 B 체인의 스마트 컨트랙트는 분리되어 있다. 스마트 컨트랙트 주소 체계가 물론 자체 서비스 운용을 위해 독자적인 체인을 사용하는 경우라면 전혀 문제가 되지 않지만, 대부분의 체인은 공개된 상태로 사용자(커뮤니티)의 참여를 전제로 한다. 따라서, 브릿징/릴레잉을 사용하는 경우가 아니라면, 보통 필요에 따라 둘 중 하나를 선택하는 경우가 더 많다.

그래서 각 체인에는 경쟁력을 갖기 위한 독특한 컨셉이 필요하다. 자체적으로 암호화 연산을 지원하는 체인이라든지, 1초 이내의 최종성(Finality)을 보장한다든지, PoSt(Proof-of-Spacetime)와 같은 합의 메커니즘을 사용한다든지, Rust 등 다양한 기존 프로그래밍 언어로 스마트 컨트랙트를 작성할 수 있도록 한다든지. 그러나 이 때문에 호환성 문제가 발생한다. 각 체인을 운영체제라 생각하면, 특정한 환경에 맞춰져 구현된 프로그램이 일반적으로 다른 환경에서 동작하지 않을 것으로 기대하는 것처럼 말이다.

ZetaChain - the first Universal Blockchain

제타체인은 마치 자바(Java)처럼 서로 다른 체인 간의 상호작용을 단일 컨트랙트로 수행할 수 있도록 지원한다. 이로서 UniSwap과 같은 서비스를 런칭한다고 가정할 때, 단일 컨트랙트로 모든 체인에 배포가 가능해진다. 간단히 말하자면 BoB - Blockchain of Blockchains이며, 이는 non-EVM 체인에는 체인 별로 모듈을 두어 호환성을 보장한 결과이다.

물론 기존에도 브릿징/릴레잉을 통해 다른 체인으로의 상호작용은 가능했지만, 제 3자에 대한 신뢰 문제 때문에 블록체인 사용 이점이 상쇄되어 버린다는 한계가 있었다. 제타체인은 외부 체인에 대한 서명은 TSS(Threshold Signature Scheme) 방식의 다중 서명 방식으로 진행하기 때문에 별도의 신뢰 없이 동작한다. 물론 이전에도 이와 유사한 크로스 체인이 있었던 것으로 기억하는데, 다양한 체인을 호환한다는 점이 이들의 경쟁력이 되었다. 현재 자산 자체는 컨트랙트 별로 관리해야 하는 상황인데, 범용 계좌 지원이 개발 중에 있다고 하니 기대해도 좋을 것 같다.

ZetaChain Whitepaper - Architecture & Strategies comparison

이러한 크로스 체인 서비스가 큰 의미를 갖는 이유는, 시가총액 규모가 가장 큰 비트코인이 활용되고 있지 못하는 현 상황을 타개할 수 있는 실마리로 작용할 수도 있기 때문이다. 이더리움이 적극적으로 활용되는 데에는 다양한 스마트 컨트랙트 간의 상호작용이 가능했다는 점이 유효했다고 생각한다. 비트코인 네트워크에는 스마트 컨트랙트 기능이 존재하지 않 으며, 현재도 단순한 수준의 Native Token 트랜잭션만 지원한다. 다만, 이는 보안 등의 이유로 자산 가치 훼손에 대한 우려를 갖는 커뮤니티의 의견을 반영한 결과일 수도 있다. 아무튼 현재로서는 다양한 이유로 암호 화폐가 현실에서 적극적으로 활용 되고 있지는 않지만, 향후 미래에 암호 화폐가 화폐로서의 기능을 동작하기 위해서는 이와 같이 활용성을 증진하는 프로젝트가 성공적으로 유지될 필요가 있다고 생각한다.

2️⃣ 영지식 증명 (Zero-knowledge Proof)

내가 처음 영지식 증명(Zero-knowledge Proof)을 알게 된 것은 업사이드 암호학 수업이었다. 이는 굉장히 신선한 아이디어로 다가왔는데, 누구나 시도할 수 있지만, 아무나 달성할 수 없는 것. 알리바바 예제로 유명한데, 이에 대한 변주가 왜 ZkP에 해당하지 않는지 설명해주시는 부분도 인상깊었다. 본 영상을 시청하시는 것을 추천드리며, 이후로는 개인적인 생각들을 적고자 한다.

먼저 알리바바가 아니라면 어떤 예제를 들 수 있을지 생각을 해봤다. 자신이 초능력자라 주장하는 사람이 있고, 모든 초능력자는 손을 대지 않고도 주사위의 값을 자신이 원하는 수로 나올 수 있도록 조종할 수 있다고 가정해보자. 그러면 증명자는 컵 아래에 주사위를 넣고, 마구 흔든 다음에, 검증자가 불러준 1~6 사이의 숫자가 나오도록 100번 반복한다. 단 한 번도 틀리지 않았다면, 로또 1등을 12번 연속으로 당첨되는 엄청난 우연이 아닌 이상, 증명자는 매우 높은 확률로 초능력자라고 볼 수 있다. 물론 한 번이라도 틀렸다면, 증명자는 초능력자가 아님을 알 수 있다.

그렇다면 영지식 증명, 이것이 어떤 의미를 가질까? 기존 공개 키 암호화는 정보에 대한 접근 권한을 분리하여 타인에게 암호화 키를 노출하지 않고도 특정한 정보를 전달할 수 있었다. 정보 전달의 목적이라면 유용한 공개 키 암호화. 하지만 인증의 영역에서는 어떨까? 내가 비밀 키를 가지고 있다는 사실을 어떻게 증명할 수 있을까? 공개 키 암호화를 사용할 때는 증명을 의미하는 데이터를 개인 키로 암호화해서 검증자에게 전달하고, 검증자는 공개 키로 복호화해서 확인하는 방식으로 전자 서명을 진행한다. 하지만 이는 어디까지나 개인 키가 개입해야 하는 부분이 있다. 이에 반해 ZkP는 개인 키가 활용된 데이터의 전달 없이도, 개인 키의 보유 여부를 확인할 수 있다는 것이 특징이다. 개인적으로는 Web3로 전환되며 개인의 데이터 소유권 개념이 생겼는데, 그와 관련하여 기술적인 필요로 대두된 것이 아닌가 생각이 든다.

그러니까 요약하자면 이들은 상위/하위 호환 관계가 아니고, 필요에 따라 적재적소로 사용해야 하는 기술이라는 것이다. 특히 ZkP는 운용 환경에 매우 민감해서, 일례로 병렬적으로 처리하는 서버에서는 정상적으로 동작하지 않는다고 한다. 그리고 기존 Web2 환경에서도 통신 오버헤드의 문제로 쓰이지 않았는데, 유독 기술에 민감한 Web3 생태계에서 과하게 주목받고 있다는 것. 오버 엔지니어링에 대한 교수님의 걱정이 이해되었다. 지금껏 부하와 느린 속도가 문제가 되었기에, 빠른 동작을 위해 하드웨어 가속기 등 최적화 연구가 이루어지고 있다고 하니 미래에는 딥러닝이 그러했던 것처럼 보다 상용화되지 않을까 기대한다.

이외에도 많은 강연들

이 밖에도 다양한 강연을 많이 들었지만, 포스팅이 너무 길어지는 것 같아서 이에 대한 내용은 그만 정리하려고 한다. 두나무 관계자분들의 강연도 정말 좋았는데, 비교적 관심이 적었던 NFT(ERC-721) 시장에 대한 좋은 이야기들과 굉장히 큰 문제로 대두되고 있는 보안 문제를 현업에서 어떻게 당면하고 있는지 조금이나마 이해할 수 있는 좋은 시간이었다.

⭐️ 마치며...

강연 자체의 내용도 좋았고, 끝나고 질문 시간을 통해 다양한 분들의 생각을 들어볼 수 있어서 좋았다. 기존에 알고 있던 내용들도 새로운 관점에서 바라볼 수 있게 되었고, 최신 트렌드를 팔로우하는 데에도 큰 도움이 되었다. 항상 인사이트를 갈구하는 개발자분들께 꼭 필요할지도...

UDC 채널을 통해 실제 컨퍼런스에 참석하지 않더라도 좋은 강연들을 모두 청강할 수 있으니 관심이 있으신 분들은 살펴보시길!!

UDC

UDC (Upbit D Conference) is an international blockchain conference held annually by Dunamu, the operator of Upbit - the most prominent digital asset exchange in Korea. The conference seeks to facilitate the growth and expansion of the Korean blockchain eco

www.youtube.com

[서평] 대규모 머신러닝 시스템 디자인 패턴

ooMia — Tue, 31 Dec 2024 11:03:32 +0900

대규모 머신러닝 시스템 디자인 패턴 / 위안 탕 지음 / 한빛미디어

거시적인 관점에서의 분산 머신러닝 파이프라인 설계 지침서

머신러닝 기술이 발전하며 모델링에 대한 책은 많았지만, 실제로 현업에서 이를 서비스로 서빙하려면 고려할 사항이 굉장히 많다. 다른 무엇보다 데이터가 차지하는 용량, 그리고 그로 인해 연산 중 메모리 자원을 효율적으로 사용해야만 하고, 이로 인해 분산 컴퓨팅은 선택이 아닌 필수가 되고 있다. 저자는 특정한 기술 스택의 활용 방법을 제시하기 보다는, 본질적으로 문제를 어떻게 해결할 수 있는가에 대한 전체적인 청사진을 제시하고 있다.

‍♂️ 실무에서 마주하는 문제에 대한 방향성 제시

이 책은 미래에 앞둔 또는 당장 마주한 성능적 결핍을 어떻게 해소할 수 있는지, 또 그 방법은 특히 어떤 상황에서 사용하면 좋은지 설명하고 있다. 시스템의 청사진을 간명하게 제시하고 있다는 점에서 머신러닝 모델링 능력은 뛰어나나, 백엔드 개발에는 경험이 부족한 연구원들이라면 이 책을 통해서 빠르게 방향성을 잡아나갈 수 있을 것이라 생각한다. 그리고 작은 규모의 데이터를 기반으로 머신러닝 서비스를 운영하던 업체가 성장하여, 보다 큰 규모의 데이터셋을 기반으로 안정적인 운영을 시도할 때 참고하면 좋을만한 책이다.

‍♂️ 구체적인 기술 활용 방법에 대해서는 다루지 않는다

하둡과 같이 주로 활용되는 스택에 대한 내용은 없고, Kubernetes/KubeFlow/ArgoCD 같이 언급된 기술에 대한 구체적인 활용 방법도 부족하다. 엄연히 굉장히 큰 관점에서 문제를 어떻게 해결할 수 있을지 인사이트를 주는 책이라고 보면 된다.

마치며...

실제로 실습을 해보며 느낀 점은, 방향성을 잡는 데에는 많은 도움이 되었지만, 실질적인 개발 경험이 부족한 사람이 이 책만을 가지고 개발하는 것은 어려울 것이라는 점이다. 그래서인지 책에서도 1년 이상의 개발 경험을 필요로 한다고 명시하고 있다. 그것만 제외하면 전체적인 흐름을 파악하는데에는 좋다. 그림도 많고 원리도 설명하기 때문이다. 제시한 방법이 어떻게 효율을 높이는지 잘 설명하고 있다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

[서평] 이것이 우분투 리눅스다

ooMia — Mon, 25 Nov 2024 20:34:22 +0900

이것이 우분투 리눅스다 / 우재남 지음 / 한빛미디어

쉽게 따라할 수 있는 Linux 기반 서버 운영 지침서

VMware라는 키워드를 보고 이 책이 다소 오래되었음을 직감했다. 요즘 가상화는 Docker를 적극적으로 사용하는 편이니까. 확인해보니 초판은 2017년이었다. 그러나 Docker를 책 마지막 챕터로 다루고 있기 때문에, 저자가 최신 변화를 지속적으로 책에 반영하고자 노력하는 것 또한 느껴졌다. 다른 입문 서적들에 비해 설명도 자세하고, 각 이미지에서 무엇에 집중해야 하는지 모두 강조해두었기에 읽기 정말 편했다.

책 전반부는 실습 환경을 구축하는 작업이다. 설치 과정이 깔끔한 방식으로 자세하게 설명되어 있음을 느꼈다. 서버를 처음 구축하는 이들도 분명 쉽게 따라할 수 있도록 하나부터 열까지 모두 상세하게 적어두었다. 그리고 중간중간 개념에 대한 부연설명을 진행하기 때문에, 책 전반부는 순차적으로 술술 읽을 수 있었다. 그렇게 챕터 3까지 빠르게 읽고 넘겼다.

그렇게 설치 과정을 넘기면, 운영에 필요한 기본적인 지식을 Part 2에서 다룬다. 컴퓨터에서 수행하는 기본적인 설정 방법이나 알아두어야 하는 기본적인 지식들을 전수한다. 읽다보면 대학교 전공 기초, 정보처리기사 필기, 리눅스 자격증 공부하는 것과 같은 느낌이 든다. 차이점은 이 책은 해당 내용들을 실제로 실습할 수 있도록 지도하고, 그 결과에 대한 해석과 설명이 친절하게 적혀져있다는 것이다.

이후부터는 서버의 목적별로 나누어 시스템 내에서의 구조 및 역할을 설명하고, 어떻게 구축할 수 있는지 설명한다. 가령, 사설 메일 서버를 만든다면 SMTP/POP3/IMAP이 무엇인지 간단히 설명하고, 인트라넷에서 각 클라이언트와 어떤 방식으로 상호작용해야 하는지 도식과 함께 설명한다. 그리고 결과적으로 서로 다른 두 클라이언트에서 다른 도메인의 이메일 주소 간 메일 송수신을 구현한다. 이 과정을 모두 잘 정돈된 이미지와 함께 A부터 Z까지 해야할 것을 전달한다. 또한 단순히 이렇게 바꾸면 됩니다ㅡ라고 하는 것이 아니고, 이것이 무엇을 의미하는지, 왜 필요한 작업인지에 대해서도 설명한다.

‍♂️ 정말 친절한 책...

읽는 내내 정말 가이드를 꼼꼼하게 자세하게 작성했다고 느꼈다. 아무것도 모르는 초등학생도, 내용 이해는 잘 모르겠지만, 실습을 따라하는 것에는 전혀 문제가 없을 정도의 수준이다. 가끔 기술 스택이 옛날 환경에 맞춰져 있는 것 아닌가 싶기도 했지만, 딱히 기술 자체가 중요한 작업은 아니기 때문에 전혀 문제가 아니다. 굳이 개선을 하자면, 이 책에서 제시하는 각 서버 구현을 Docker 이미지로 구성해봐도 괜찮겠다는 생각을 했다. 그러면 독자들이 오류를 해결하지 못하거나, 빠르게 결과물을 보고 싶을 때, 큰 도움이 될 것 같다.

‍♂️ Linux 커널 수준에서의 탐구는 다루지 않는다

맥락이 중요하긴 하겠지만 아무래도 Linux 책이라 하면, C로 작성된 Linux 커널 수준에서의 동작을 심도있게 풀어내는 책을 떠올리지 않을까? 하지만 이 책의 방향성은 Linux에 대한 깊이 있는 탐구가 아니라, Linux 환경에서의 기초적인 서버 운영에 초점이 맞추어져 있다. 따라서, 커널 단에서의 동작과 보안 취약점 탐구 등에 관심이 있다면, 이 책은 적합하지 않다.

마치며...

요즘에는 소프트웨어 수준에서 다양한 기능을 가진 서버를 구축하고는 하는데, OS 단에서의 동작 원리를 모르면 트러블슈팅이 안 되는 경우가 존재한다. 예를 들어, 예전에 WSL2 초기 설정할 때 hosts 파일을 수정해서 DNS를 명시하거나 로컬 호스트를 프록시로 사용하지 않아 인터넷 접속이 불가능했던 경험이 있다. 만약 이 책을 처음부터 끝까지 실습한다면, 에러 메시지를 읽고 어떻게 해결해야 할 지 쉽게 감을 잡을 수 있을 것 같다.

그리고 솔직히 좀 놀랐다. CLI 기반의 직접적인 서버 구축 과정은 기술 변화에 둔감해서인지, 모든 개선이 독자 UX에 맞춰진 것일까? 이 책에 얼마나 많은 시간이 갈렸을지 상상이 안 간다. 단순히 쉽게 따라할 수 있는 것을 넘어서, 깨알 정보들이 적재적소에 배치된 것을 보고 이 책을 향한 저자의 애정이 느껴졌다. 좋은 책이라 생각하고, 후배들에게 백엔드 입문서로 추천하고 싶을 정도다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

UDC 2024 Conference 후기 (1)

ooMia — Sun, 24 Nov 2024 05:39:58 +0900

업사이드 아카데미의 마지막 공식 일정은 Upbit Developer Conference (이하 UDC) 에서 막을 내렸다! 재밌고 신기했던 신라호텔에서의 UDC 후기, 지금 바로 시작합니다

11월 13일 수요일 (D - 1)

깜빡!하고 전날에 방문해버린 UDC 현장

이 날 뭔가에 홀린 듯 전날을 UDC 당일로 착각해서 현장을 방문했다. 등록 데스크에 가니, 안내원분께서 컨퍼런스는 내일이라고...!!! 그래도 기왕 온 거 한 번 구경하고 가야겠다 싶었지만, 본 회장에는 들어갈 수 없어서 별관에 마련된 발표장을 방문해보았다.

현장은 컨퍼런스 준비가 한창이었다. 음향 장비와 방송 장비 등을 세팅하는 모습이 보였다. 막상 컨퍼런스 당일에는 비도 내렸고, 방문객들을 고려하여 사진 촬영이 불가했는데, 덕분에 맑은 날씨의 별관 2층 모습을 찍을 수 있었다 :D

덕분에 맑은 날씨의 야외 공간을 찍을 수 있었다

11월 14일 목요일 (D - DAY)

이 날 아침, 업사이더 대표 발표자들은 남들보다 일찍 도착해서 리허설을 진행하고 있었다. 속속들이 다른 업사이더들도 도착했고, 앞서 소개했던 등록 데스크에서 명찰과 웰컴 기프트를 받았다. 내부에 키링부터 바람막이까지 다양한 굿즈가 많았는데, 전부 가방에 넣어버려서 기억이 안 난다

웰컴 기프트 가방

점심 식사

이후 본관에서 진행되는 세션에 참석하기 위해 착석했다. 회담이 진행 중인 순간에는 카메라 셔터음이 방해될까봐 찍지 못했다. 오전 세션이 완료된 후, 자리에 앉아있으니 종업원 분들께서 식사를 제공해주셨다! 메뉴판을 제공해주셔서 " 뭐지? 원하는 것으로 주문하는건가? " 싶었는데, 알고보니 전부 다 도시락 형태로 주셨다 UDC 마카롱도 맛있었다!!

자유 시간

맛있는 식사를 마치고, 남은 시간 동안은 자유롭게 내부 부스를 탐방하고, 원하는 세션의 발표를 들을 수 있었다. 크게 두 개의 회관으로 나뉘어 있었는데, 두 개가 서로 도보로 연결되어 있는 형태라 그냥 눈이 먼저 눈이 닿는 곳을 가기로 했다.

가장 먼저 보이는 두나무의 이력과 철학에 대한 내용 중에는 미래 인재 양성이라는 항목이 있었던 것으로 기억한다! 아마 업사이드 아카데미도 이 일환이 아닐까? 우측 TV 영상에서는 업비트가 항상 업계 최고, 최초의 자리에서 새로운 도전을 시도하고 업계를 선도하고 있음을 알리고 있었다. 실제로 이 정도 규모의 영양가 있는 국내 Web3 컨퍼런스는 UDC가 유일하다고 동의하며 부스로 향했다.

메인 홀 / 관내 지도 / 업비트 업력 및 철학

부스 탐방

이 날, 각 부스별로 스탬프를 찍을 수 있도록 이벤트가 준비되었는데, 스탬프를 8개 모으면 뽑기 상자에서 선물을 증정했다. 공고롭게도 4등에 당첨되어 UDC 후드티를 받았다! 각 부스를 방문하는 것도 재미있었는데, 이벤트에 참여하면 주는 굿즈를 모으는 재미도 있었고, 각 부스가 운영하는 서비스에 대한 설명을 듣고 질문하는 것도 재미있었다.

다양한 부스 / 수집 가능한 모든 스탬프를 모았다!!

귀여운 Pudgy Penguin 그리고 한창 지칠 때 달콤한 커피 브레이크

방문한 부스 중 기억에 남았던 건 제타체인, VIVER, 그리고 Kaiko.

VIVER는 KREAM과 같은 C2C 명품 거래 플랫폼이지만, 시계에 특화된 플랫폼이라고 한다. 이전에 발생했던 KREAM에서의 가품 발견 이슈를 말씀드리니, 워낙 뛰어난 전문가들이 검수하기 때문에 문제 없다고 답변해주셨다. 그래도 보험이 있어야 소비자들이 안심하지 않을까? 싶어서 질문했지만...

Kaiko는 금융 거래 데이터를 손쉽게 이용할 수 있는 서비스라고 한다. Web2 기반의 CEX와 Web3 기반의 DEX 데이터 모두 보유하고 있기 때문에, 금융 데이터 기반의 사업체에 도움을 주고 있다고 한다. 그래서 어차피 Web2, Web3 공개된 API를 통해 데이터에 손쉽게 접근할 수 있는데 어떤 차별점이 있는지 여쭤봤고, 파일 등 제공 형태에서의 차별점이라든지 Web3에 대한 이해가 부족한 경우가 종종 있어서 이러한 UX의 간극 해소 등이 차별점이라고 설명해주셨다.

제타체인은 이후 방문한 발표장에서 더 자세한 이야기를 들을 수 있었다.

발표에 대한 내용은 다음 포스트에서 이어집니다.

업사이드 아카데미 2기 모집

ooMia — Wed, 13 Nov 2024 19:37:52 +0900

성과 공유회 후기를 작성한 게 엊그제인데, 어제는 그 당시의 우수팀 사진과 함께 관련된 네이버 기사가 작성되었다. 성과 공유회에 대한 내용보다는, 2기 모집에 대한 홍보성 기사에 가까운데, 이 참에 업사이드 아카데미 1기는 어떠했고, 2기 지원을 결정하기까지 참고할 수 있을 만한 내용을 정리해보고자 한다.

두나무, 보안 인재 양성프로그램 '업사이드 아카데미' 2기 모집

블록체인·핀테크 전문기업 두나무가 보안인재 양성프로그램 '업사이드 아카데미 2기' 참가자를 모집한다. 업사이드 아카데미는 두나무와 사이버보안 전문기업 티오리가 운영하는 웹3 보안인재

n.news.naver.com

업사이드 아카데미 ?

업사이드 아카데미는 두나무와 티오리가 협업하여 Web3 보안 인재를 양성하는 교육 프로그램이다.

그리고 Web3 중 EVM 기반 체인에서의 스마트 컨트랙트 보안에 좀 더 집중한다.

컴퓨터와 관련된 전공을 가졌다면, 항상 보안이 중요하다는 이야기는 숱하게 들어봤을 것이다. 하지만 이 보안이라는 키워드는 비단 IT 산업에서만 사용하는 용어도 아닐 뿐더러, 입장 차이에 따라 서로 다른 방식으로 이해되고는 한다.

(개발자) 오, 보안! 중요하죠. 보안을 신경쓰며 개발하고 있어요. (.env 파일을 깃 커밋하며)
(경영자) 보안? 당연히 중요하지. 근데 우리 회사 보안 담당자는 맨날 헛돈 쓰려고 하더라니깐.
( ??? ) 아, 개인 정보 제공에 항상 선택 빼고 필수만 눌러요 (으쓱)

하하 정말 중요하게 여겨지고 있는지 사실 확신은 없지만...
아무튼 기존 Web2 분야에서 비용 효율성에 근거한 적절한 수준의 보안 정책이 구성되었다면, Web3 블록체인 분야는 웃음기 쫙 빼고 정말 보안이 중. 요. 하. 다. 긴 설명 하기 전에 데이터로 보이자면, 3년 내 억대 달러 규모의 피해만 20번 이상 발생했고, 매주 수천/만 달러의 피해가 발생하고 있다.

Rekt - Home

DeFi / Crypto - Investigative journalism & creative commentary

rekt.news

장문의 설명보다 잘 정리된 데이터가 이 중요성을 더 쉽게 알려줄 수 있을거라고 믿는다. 피해 액수가 억인데 달러다.

X의 c4lvin | ChainLight님(@SiwonHuh)

Weekly Hack Digest, November Week 2. Which rug pulls, exploits, and security breaches happened last week? Read this 2-minute weekly summary to stay in the loop. (1/7)

x.com

심지어 아직까지도 수천/수만 달러 규모의 피해는 매주 발생하고 있다. ChainLight - Weekly Hack Digest on X

이러한 기이한 현상은 보통 블록체인의 탈중앙성과 스마트 컨트랙트의 결정론적 동작으로 인해 발생한다. 비유하자면 웹 서버를 가동시키는데 코드는 모두에게 공개해야 하고, (기본적으로) 한 번 배포한 코드는 수정할 수 없는 상태와 유사하다. 블랙 해커들은 이러한 취약점을 악용하여 자금을 탈취하거나 그에 준하는 부당 이익을 취한다. 이상 탐지로 탈취가 진행되는 시점을 알람받더라도 즉각적인 대응 및 패치가 어려우니, 실시간으로 자금이 세탁되는 과정을 목도했다는 경험담도 있다. 물론 이러한 한계를 극복하기 위한 다양한 방법이 존재하는데, 여기서는 깊게 다루지 않는다. 이러한 위협 때문에 스마트 컨트랙트 기반의 서비스 운영진 입장에서는 우리의 스마트 컨트랙트가 정말로 안전한지에 대한 확신을 얻고자 다양한 보안 감사 업체에 audit을 요청한다. 이렇듯 스마트 컨트랙트 보안 감사는 체인 생태계 서비스 런칭과 불가분 관계에 놓여 있다.

하지만 이러한 필요에도 불구하고 이 분야를 처음 혼자서 시작하는 것은 어렵다. 컴퓨터와 프로그래밍에 대한 기본적인 이해가 필요하고, 용어와 개념 자체도 생소하고... 커뮤니티에 의해 운영되는 이 생태계의 특성으로 용어의 의미도 변하는데, 인터넷 찾아서 나오는 정리 글을 스스로 필터링 할 능력이 없으니 오개념을 받아들이기도 쉽다. 뭐 그 밖에도 개발 경험이 부족하면, 환경을 셋업하고, 개발 도구를 사용하는 과정 중에서도 어려움이 있다. 이해할 수 없는 결과를 내뱉는 컴파일러나 유틸리티 도구의 동작은 덤.

이와 같이, Web3 보안이 갖는 중요도와 필요에 비해 어려움이 많은 영역이다보니 진입 장벽이 높고, 특히 국내에서는 별도의 학회에 소속된 것이 아니라면 온보딩이 어렵다는 인식이 있다. 업사이드 아카데미는 밀도 높은 몰입이 가능하도록 공부에만 전념할 수 있는 환경과 지원을 제공하고, 뛰어난 멘토들의 도움 아래 소수 정예의 교육생들과 함께 성장할 수 있도록 돕는다. 아니 공부 시켜주는데 돈 주고 맥북도 준다고요?!

더 많은 내용이 궁금하다면 ?

1기는 어땠나요?

1기를 통해 무엇을 느끼고 얻었는지 말하라고 했을 때, 만약 Discord 또는 기타 학습 기록을 참조할 수 있다면, 정말 3시간 동안은 쉬지 않고 떠들 자신이 있다. 왜냐하면 매주, 매일이 스스로의 한계를 뛰어넘는 도전의 연속이었기 때문이다. 제출한 과제 보고서를 봤을 때, 머리 속에서 한 편의 단편 드라마가 재생된다 어떤 과제는 진짜 과장 안 보태고 100시간 동안 집 밖에도 안 나가고, 목/금/토/일 4일 매달려서 겨우 해결했다. ㅋㅋㅋㅋㅋ 진짜 웃음 밖에 안 나오네 헛웃음

좋다고 생각했던 부분 중 하나는 개괄적인 내용을 강의를 통해 전달받고, 어려운 과제를 스스로 해결하며 체득할 수 있도록 개인 시간이 주어졌다는 점이다. 아무것도 모르는 상태에서 강의를 들어도 절반은 휘발된다. 물론 그래서 필기를 하긴 했지만, 내 경우엔 무엇이 중요한지 스스로 판단하기 어려운 수준에서 한 필기라 노력에 비해 효과를 보진 못았다. 1기에서 교육 기간 중에는 대체로 격일로 강의와 자율 시간이 주어졌는데, 자율 시간에 센터 출석이 강제되지 않아서 몰입을 이어갈 수 있던 점이 좋았다. 프로젝트 기간 중에는 주 7일 출석이라 힘들었지만

그리고 궁금한 점이 생기면 디스코드로 바로 질문할 수 있어서 좋았다. 지금은 어디서 어떻게 검색해야 그 의문점을 해결할 수 있을지 경험이 쌓였지만, 아무것도 모를 때에는 정보 찾고 필터링 하는 것도 어렵다. 그래서 어찌저찌 찾으면 인터넷에 나오기는 하는 의문점도 멘토님들의 답변을 통해 확신을 얻곤 했다. 그리고 아쉽게도 공개하기는 어렵지만, 진짜 작은 질문도 죄송스러울 정도로 정성스럽게 답변해주신다. 그래서 최대한 핑프처럼 멍청한 질문하지 않도록 조사하는 과정을 거친다 시간 낭비하시면 안 되니까

어떤 내용을 배웠는지 나열하는 건 끝도 없고, 그래서 무엇을 경험했고 얻었는지 스스로 정리하는 시간을 가져보았다.

근 3년 내 가장 깊은 중장기 몰입(4개월)
새로운 Web3 분야에서의 비약적인 능력 성장과 심도 있는 경험 (제로 베이스 시작)
지속 가능한 형태의 프로젝트 베이스 (Herbicide Notion / GitHub)
힘이 되는 1기 업사이더들, 그리고 멘토님들과의 네트워크

우수 프로젝트로 선정된다면 여기에 UDC 컨퍼런스 발표의 기회까지! Web3 보안 커리어를 시작하고자 하는 이들에게 이보다 더 좋은 기회가 있을까? 대단한 배경이나 업적, 인맥이 없는 사람일수록 얻어가는 것이 더 많을 것 같다.

⚠️ 다만, 한 가지 진지하게 고민했으면 하는 점은 모집 요건에 따라 현재의 학업 또는 재직을 중단해야 하는 경우다. 학업은 휴학을 통해 일시적 중단이 가능하지만, 만약 재직 중이라면 커리어 전환에 대한 결심과 본 분야에 대한 면밀한 조사를 선행한 뒤에 결정하시는 것을 추천한다.

지원하기로 결정했다면?

업사이드 아카데미 1기

블록체인 기술을 기반으로 탈중앙화된 다음 세대의 Web3 산업 생태계를 육성합니다 업사이드 아카데미 1기는 Web3 산업에 필요한 보안 전문가 양성을 위한 교육을 진행한다. 선발 과정1. 이력 및

spems.tistory.com

1기를 지원했을 때와 방식 자체에 큰 차이가 있을 것 같지는 않다. 그러니 전체적인 느낌은 위의 링크를 참조하고, 지원은 공식 홈페이지에서 진행하면 된다. 다만, 지원 후 평가 전 준비 기간동안의 준비 방향성에 대한 얘기는 하고 싶은 말이 정~ 말 많다. 그래서 이 부분은 이후 시리즈 형태로 작성하려 하고, 포함될 내용은 다음과 같다.

Overview
Foundry: Cast & Forge & Chisel
Dreamhack
evm.codes
MetaMask
Block Explorer Interface & API
Markdown & Git
VS Code & CLI
기타 학습에 유용한 링크

[서평] 이펙티브 러스트

ooMia — Tue, 12 Nov 2024 18:07:44 +0900

이펙티브 러스트 / 데이비드 드라이스데일 지음 / 한빛미디어

블록체인과 관련된 개발 작업을 진행하다보면, 러스트로 작성된 도구들을 어렵지 않게 접할 수 있다. 러스트를 모르던 시점의 나는, 빠르고 안전한데 다만 배우는 게 좀 어려운언어가 존재한다고? 라며 흥미로움을 감출 수 없었다. 주변에서 어렵다, 안 된다고 하면 흥미가 생기는 것이 엔지니어들 특징 아닐까? 얼핏보면 C++처럼 생긴 언어가, 얼마나 좋길래 2012년에 태어나서 어떻게 2024년 현재, 어떻게 내 탐구의 대상이 되었는지, 이 책을 통해 조금이나마 그 궁금증을 해소하고자 한다.

본론으로 들어가기에 앞서, 필자는 러스트에 대한 지식과 경험이 부족한 초보자임을 미리 밝힙니다. 그러나 다른 언어들에 대한 다년간 경험을 토대로, 이 책이 어떻게 활용될 수 있고, 어떠한 의미를 가질 수 있는지 정리해봤습니다. 러스트를 새롭게 배우려는 개발자의 관점에서 이 책에 대한 인사이트를 얻어가실 수 있었으면 합니다.

좋은 러스트 프로그래머가 되고자 한다면 읽지 않을 이유가 없는 책

이 책은 러스트 중급자에게 가장 적합한 책이다. 중급자라 함은, 기능을 구현할 때 어떻게 구현하는 것이 더 좋을지 고민하는 단계이다. 저자는 소개에서 경험과 사례를 기반으로, 왜 일반적으로 주어진 지침이 유용한지, 예외적인 상황에는 어떻게 대처하면 좋을지 자세히 설명한다. 이 모든 과정이 추상화된 프로그래밍의 영역이 아닌, 러스트의 원리를 기반으로 진행되기 때문에, 좀 더 Rust 답게 프로그래밍하고자 하는 이들에게 큰 도움을 줄 수 있을 것 같다.

하지만 나는 입문자들 또한 이 책을 구매하는 것을 추천하고 싶다. 모든 프로그래밍 언어가 그렇듯, 개발 경험이 쌓임에 따라 기능을 구현하는 것은 누구나 가능하지만, 좋은 코드를 작성하는 것은 그렇지 못하기 때문이다. 이 책에서는 초심자가 참고하기 좋은 지침을 잘 정리해두었기 때문에, 이러한 내용을 주기적으로 복습하는 것만으로 개발 능력을 빠르게 향상시킬 수 있을 것이다. 그러니 당장 읽지는 못하더라도, 두고두고 참고하기 좋은 책이라고 생각한다.

구성: 6개의 챕터, 그리고 35개의 아이템

각 챕터는 타입, 트레이트, 기타 주요 개념, 의존성, crates 툴, 러스트 심화를 주제로 나름 '기초'부터 심화까지 전 영역을 다루고 있다. 물론 러스트 프로그래머를 대상으로 작성된 책이라, 초심자가 바로 읽는 것은 확실히 부담으로 다가왔다. 적어도 Hello, World를 출력하는 코드를 작성하는 데 관여하는 배경 지식은 숙지해야 이 책을 읽을 수 있다.

++ 한글로 작성된 입문 가이드와 다양한 레퍼런스를 담아둔 링크를 공유한다.
부족한 부분이 있을 수는 있겠지만, 적어도 아무것도 모르던 내게는 큰 도움이 되었다...

평범한 C개발자의 Rust입문기: Rust에 입문하는 C개발자를 위한 안내서

https://github.com/gurugio/my-rust-book 추후 설명 추가나 그림 추가 등의 작업은 Github에서 진행하겠습니다. 안녕하세요. C언어 …

wikidocs.net

[Rust] 입문 가이드

2021.09.20 작성 2022.04.16 보완 2023.06.07 보완 2024.02.25 보완 2024.03.30 보완 본인의 경혐을 바탕으...

blog.naver.com

다양한 아이템은 이 책이 왜 초심자에게도 유용한지 드러나는 대목이다. 각 아이템은 분명히 지킬 이유가 있는, 일련의 Best Practice를 제시한다. 이 가이드를 잘 숙지한다면 개발하는 중 이와 상충되는 상황을 마주했을 때, 저자가 이러한 규칙을 제시한 이유를 떠올려보고, 그 상황에서 최선의 선택을 행하면 된다. YAGNI (You ain't gonna need it)이나 KISS (Keep it short and simple) 원칙처럼 프로그래밍 전반에 적용되는 느낌은 아니지만, 적어도 Rust 프로그래밍을 진행하는 과정 중에는 특별한 상황이 아니라면 굳이 지키지 않을 이유가 없어보인다.

실습: 대여 규칙

type Link = Option<Rc<RefCell<Node>>>;

Rc? RefCell? 이런게 다 뭔지 싶고, 왜 필요한지 싶었다. 일반적인 C/C++의 포인터는 단순히 메모리 주소에 값을 읽고 쓰는 개발자라는 주체만 있지만, Rust에서는 값마다 소유자가 존재한다. 소유한 값을 코드의 다른 곳에 빌려줄 수 있는 대여 메커니즘이 존재하는데, 막연한 이해만 가지고 이중 연결 리스트를 구현해보다가 대여 검사기에게 숱한 지적을 당했다...

아이템 15는 전체가 대여와 관련된 내용이다. 소유자와 가변, 일반 레퍼런스의 차이를 설명하고, 불변/가변 레퍼런스의 개수 제한 개념을 독자가 온전히 이해할 수 있도록 두 사례를 비교할 수 있는 예제도 제공한다. 또한 대여 검사기의 지적에 대처하는 방법도 제시한다. 저자는 이 중 스마트 포인터 Rc와 RefCell을 활용하여 이중 연결 리스트를 구현했다. Rc를 사용하면 동일한 항목을 다수가 가리킬 수 있어서 소유권을 공유할 수 있고, RefCell은 가변 레퍼런스를 사용하지 않고도 내부 상태를 변경할 수 있도록 해준다. 개발자들의 수많은 필요 중 대다수는 이미 표준 라이브러리로 구현되어 있으므로, 직접 unchecked 연산을 작성하기 전에 표준이 존재하는지 확인하라는 책 후반부의 조언도 참고했다.

++ 고마워요 ChatGPT !!

Rust DoubleLinkedList Example

Rust DoubleLinkedList Example. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

마치며...

러스트 사용 경험이 거의 전무한 상황이라 솔직히 책을 집어들었을 때, 어디부터 어떻게 읽어야 할 지 다소 막막했다. 펼치는 곳마다 이해하기 어려운 내용들이 펼쳐져 있었는데, C++의 확장판이라 생각하고, 그 차이점에 집중해서 기초를 공부한 이후에 읽으니 이전보다는 나았던 것 같다. 다른 개발자분들도 본 서적을 중급서라고 표현하시는 이유를 이해할 것 같다. 그렇다고 책의 가치 자체를 판단하지 못할 정도는 아니다. 이 책은 언제든 참조할 수 있도록 잘 정리된 아이템을 중심으로, 예제와 edge case를 담은 좋은 책이다. Rust를 배우고자 하시는 분들은 이 기회에 초보자에서 중급자로 한 단계 성장할 수 있을 것이라 생각한다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

업사이드 1기 성과 공유회 후기

ooMia — Mon, 11 Nov 2024 19:57:01 +0900

성과 공유회는 지난 한 달 간 진행한 프로젝트의 결과물을 모두가 모인 자리에서 함께 나누는 자리이다. 그리고 이 발표의 결과로 각 분야의 팀들 중 우수 팀은 UDC 발표 기회를 얻게 된다. 아쉽게도 우리 팀은 근소한 점수 차이- 소수점(오피셜) -로 아쉽게 기회를 놓치게 되었지만, 모든 팀이 정말 멋진 결과를 만들어냈다는 사실만으로도 모두가 박수치며 즐겁게 마무리 지을 수 있는 자리였다.

++ Account Abstraction에 대한 Audit을 진행한 시추코기 팀은 버그 바운티를 통해 한화 약 1,600만원 상당의 코인을 지급받았다. ( ! )

성과 공유회는 모나코스페이스 미디어홀에서 진행되었다. "이렇게까지 해주신다고?"라는 생각이 들 정도로 정말 기억에 길이 남을 만한 발표회였다. 들어오는 공간에도 1기 멤버들의 사진과 각자의 코멘트가 남아있다. 강의를 진행해주신 두나무/티오리 멘토님들의 반가운 얼굴도 함께 있었다. 언더독스 운영진 분들은요 ??

모나코스페이스 미디어홀 입구

운영진 분들께 요청 받았을 때에는 한창 프로젝트 진행 중이라 뭔가 숙제처럼 느껴졌는데, 지금 이렇게 보니까 각자의 한 마디가 다 뜻깊고 마음이 전해지는 것 같아 참 쓰길 잘했다는 생각이 든다. 뿐만 아니라 선물로 받은 Snaps 사진첩에는 모두가 서로를 향해 작성한 롤링 페이퍼도 함께 남아있었다. 다른 사람들 것도 궁금한데... 아쉽지만 참아야겠지?

개인 코멘트 / 롤링 페이퍼

개인 인터뷰 영상이 업사이드 소개 영상으로 재생되고 있었다...!! 대기하는 동안 줄곧 재생되어서 낯뜨거웠지만, 나 이외에도 다양한 인원들의 영상 모두 포함되어서 그나마 덜 부끄러웠다. 이외에 오프닝 영상도 있었다. 4달의 처음과 마지막이 모두 담겨있고 그걸 또 엄청 역동적으로 잘 담아내셔서 감탄했는데, 녹화하지 못한 점이 아쉽다 :( 언젠가 업사이드 홍보 영상으로 풀리지 않을까?

넓은 전시회 공간과 소개 영상

먹을 것도 많이 준비되어 있었따! 그 중 옆자리 Sori 님과 공감했던 건 " 새우가 맛있네요 "
하지만 다른 것들도 맛있었다.. 너무 맛있어서 3접시나 먹고 식사를 해버렸다...

중간에 쉬는 시간과 먹을 수 있는 시간이 보장되어 있어서 긴 일정동안 지치지 않고 계속 들을 수 있었다.

무대 뒷편

정~ 말 아쉽게도 초청해주신 전문 아나운서 분의 진행과 고대하던 bpak 멘토님의 강의, 그리고 4개 팀의 발표자 ghxst, kenny, hakid29, nullorm의 강단 위 모습은 찍지 못했다. 찍을 정신이 없었다

bpak 멘토님의 강의에서는 귀중한 이야기들을 들을 수 있었다. 정말 좋아하는 것을 꾸준히, 그리고 옳은 방향으로 학습하되, 타인이 아닌 어제의 나와 비교하며 성장을 추구하고, 이해되지 않는 내용들은 끊임없이 깊게 파고 들어가며 공부하는 것이 해커의 소양이라고 하셨다.

강의 이후 bpak 멘토님께 궁금한 점을 질문드렸다.

실제로 X가 Y처럼 행동하는지에 대해 모르면 답답하다, 알고 싶어야 한다는 것이 해커의 소양이라고 하셨는데, 실제로 멘토님께는 어떤 순간이 그러하셨나요? 또 현재 업사이드 아카데미 2기 모집 중에 있는 것으로 알고 있는데, 멘티들에게 이러한 배움의 기쁨을 느낄 수 있도록 만들어주고 싶은 마음이 크실 것 같습니다. 멘티들에게 배움의 기쁨을 전파하기 위해 어떤 식으로 접근하실 계획이신가요?

이에 멘토님의 답변은 다음과 같았다. 이전에 후배들을 대상으로 멘토링을 한 경험이 있는데, 멘토님의 답변도 이해가 갔다. 실제 체감하지 못하는 필요를 주입하는 것은 정말 어려운 일이었으니까.

학생 시절에 게임 핵의 원리에 대해 궁금했던 적이 있었고, 대학 진학 이후, 그것이 어떻게 동작할 수 있었는지 알게 되었을 때 배움의 기쁨을 느꼈습니다. 배움의 기쁨을 누군가 만들어주는 것은 어렵다고 생각합니다. 다만, 교육생들이 그 배움의 목마름을 지니고 왔을 때, 오아시스와 같은 역할을 해주는 것이 아카데미의 역할이라고 생각합니다.

++ 실제로 오아시스의 비유는 하지 않으셨지만, 목마름을 채운다는 맥락에서는 동일한 의미라고 생각한다.

성과 공유회 종료 후 텅 빈 단상 / 수료증

++ 저녁 회식, 수료패, 업사이드 키캡, 보조 배터리 외에도 UDC 후드집업, 업사이드 후드집업은 원단 퀄리티가 좋아서 즐겨 입을 것 같다

지난 4개월 동안 마주한 다양한 어려움들을 헤쳐나가면서 스스로 많이 성장했음을 느낀다.

막막했던 프로젝트 기간 중 한줄기 빛이 되어주신 zer0luck 멘토님, 암호학을 가르쳐주신 vero 멘토님, 이더리움의 지평을 새롭게 열어주신 troy 멘토님, Real-world 사례를 위해 멋진 랭킹 시스템을 만들어주신 setuid0 멘토님, Web3 워게임과 dApp 개발 패턴, 그리고 보고서 작성 방식을 가르쳐 주신 reset 멘토님 그리고 시간 내서 커리어 상담도 받아주신 Juno 멘토님 ... 세상에... 너무 많아 모두 언급할 수 없는 것을 양해해주세요

함께한 팀 멤버들- entropy, sori, kenny에게도 정말 고맙고, 또 다들 굉장한 실력자들인데, 그에 비해 내 능력이 부족해서 팀 성과에 더 많은 기여를 하지 못해서 미안했다...

tommy 멘토님과 bpak 멘토님, 그리고 c4lvin 멘토님

모두 이 자리를 끝이 아닌, 새로운 시작으로 여기고 다시 열심히 정진하길 바라는 마음을 밝히셨다.

끝이 아닌, 새로운 시작.

Web3라는 새로운 지평을 열어준 업사이드 아카데미에게 무한히 감사드리며

앞으로도 꾸준히 공부하고 연구해야겠다.

[서평] AI 시대의 프로그래머

ooMia — Sat, 28 Sep 2024 19:33:42 +0900

AI 시대의 프로그래머 / 톰 타울리 지음 / 한빛미디어

[ 요약: LLM을 처음 접하는 이들을 위한 입문서 ]

LLM 모델 기반 코딩 어시스턴트의 활용이 처음인 이들을 위한 입문서

또는 모델별 프롬프트 엔지니어링 요령에 대한 지식이 없는 이들의 지침서

[ 얕아도 너무 얕다]

6장까지 다양한 LLM 모델에 대한 기본 개념

9장까지 도메인별 기본 지식

참고 정도는 할 수 있겠지만, 그게 이 책을 사야할 이유가 될 수 있을까?

만약 이 책을 내 동료에게 추천해야 한다면,LLM 모델에게 보다 좋은 답변을 얻을 수 있도록 질문하는 방법이 있다는 것에 대해 얘기할 것 같다. 3장 프롬프트 엔지니어링과 7, 8, 9장 도메인별 사고 방식에 대한 이론을 참고하면 자신만의 유용한 질문 방식을 만들 수 있을 것이다.

그러나 웹 상에는 이미 프롬프트 엔지니어링에 대해 더 깊고 유용한 지식이 이보다 더 잘 정리되어 있다. ChatGPT가 등장한 지 꽤나 많은 시간이 흘렀는데, 아직도 이 정도의 얕은 지식이 필요한 이들이 아직 있을까? 다양하게 훑는다는 관점에서 몰랐던 모델을 알게 된다면 도움은 될 것 같다.

하지만 초기에 ChatGPT가 독점하다시피 했던 시장을 최근에는 Claude 3.5 Sonet 모델이 Cursor IDE와 결합된 형태로 개발자들 사이에서 좋은 DX를 보여주고 있는 것처럼, 언제 어떻게, 어떤 모델이 앞서갈 지는 예측할 수 없는 편이 일반적이다. 따라서, 최근 동향 등은 인터넷을 통해 접하는 편이 낫다.

또한, LLM 서비스는 과금 모델의 도입이 지연되는 경우는 있어도, 아예 없는 경우는 없다. 모든 모델을 체험해보지 않고도 판단할 수 있을 정도의 정보가 있는 것도 아니고, 모든 모델을 충분히 체험할 정도의 경제적/시간적 여유가 있는 것도 아니다. 어떤 관점에서 보든지 이 책, 참 애매하다.

[ 3장. 프롬프트 엔지니어링 내용 정리 ]

1. 질문은 적게, 그리고 명확하게

2. Zero-shot || Few-shot Learning (예시를 통한 구체화)

3. 모델에게 상황 또는 역할 부여

4. 생각의 사슬: CoT 활용

5. 입력 및 출력 형식 설정

프롬프트 엔지니어링도 기존에 훨씬 더 잘 정리된 내용들이 많다.

개인적으로 참고할 수 있는 내용은 7장의 기획 부분 정도.

이것마저도 그저 기획 개념을 활용하여 일종의 가이드를 만든 것이기 때문에 특별함은 없다.

[ 부록: 참고 링크 ]

이 책의 내용과는 별도로 참고할 수 있는 웹 문서 링크를 추가한다.
~~당장 한 번만 검색해도 이 정도의 높은 품질의 자료를 찾을 수 있다.~~

GitHub - f/awesome-chatgpt-prompts: This repo includes ChatGPT prompt curation to use ChatGPT better.

This repo includes ChatGPT prompt curation to use ChatGPT better. - f/awesome-chatgpt-prompts

github.com

GitHub - promptslab/Awesome-Prompt-Engineering: This repository contains a hand-curated resources for Prompt Engineering with a

This repository contains a hand-curated resources for Prompt Engineering with a focus on Generative Pre-trained Transformer (GPT), ChatGPT, PaLM etc - GitHub - promptslab/Awesome-Prompt-Engineerin...

github.com

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

[서평] 네트워크 인프라 자동화

ooMia — Sun, 25 Aug 2024 16:37:39 +0900

네트워크 인프라 자동화 / 맷 오스왈트 외 3인 지음 / 한빛미디어

[ 요약: 모두를 위한 네트워크 인프라 자동화 입문서]

이 책으로 운영중인 네트워크 인프라를 멋지게 자동화하는 것은 어려울 수도 있다. 실무서보다는 연관 주제를 잘 정리해 둔 입문서에 가깝다. 얕지만 넓게, 그래서 어떤 이해 관계자가 접하더라도 필요한 내용을 찾을 수 있도록 방대한 분량으로 구성되었다.

[ 왜 이렇게 두꺼워? ]

책을 받아들고 가장 먼저 놀랐던 것은 이 책의 두께다. 자그마치 천 페이지의 거대한 분량. 무엇이 이 책을 이토록 두껍게 만들었는지 궁금함을 가지고 책을 읽기 시작했다.

언제나 그렇듯 먼저 목차를 둘러본다. 생각보다 역사, 배경 지식 등 관련 이론 설명이 많아보인다. 실습 중에는 실제 인프라 자동화 내용 외에도, 각각 90 페이지 분량의 Python, Go, Git에 대한 기초적인 설명을 다룬다. 처음에는 왜 굳이 넣었나 싶었지만, 저자의 대상 독자 목록을 보고 이해가 갔다.

네트워크 엔지니어, 시스템 관리자, 소프트웨어 개발자

기초의 종류가 다양한 모든 이들에게 네트워크 자동화 분야의 입문을 돕기 위함이었고, 저자의 마음이 느껴지는 대목이었다. 하지만 책은 느리고, 기술은 빠르다. 이 책이 좀 더 널리 소비되고자 한다면, 대상 독자를 좁히고, 책의 분량을 줄일 필요가 있다. 뭐, 4명의 저자가 협동한다면 얘기가 달라질 수도 있겠지만. (웃음)

[ 자동화가 필요한 이유 ]

평소처럼 속독부터 시작했다. 분량이 많아서 걱정했는데, 생각보다 시간이 오래 걸리지는 않았다.

초반 배경 설명에서 기억에 남는 내용은 다음과 같다. 각양각색 비표준 방식의 하드웨어를 CLI로 일일이 하나씩 조작하던 시절이 있었다. 물론 지금도 그런 방식으로 일을 하긴 하지만, 핵심은 확장성이다. 단순히 기기를 추가하는 scale-out 방식의 확장 뿐만 아니라, 비즈니스 요구사항의 추가에도 대응할 수 있다는 것이 핵심이다.

계속 읽으면서 AWS와 같은 IaaS 서비스 업체들이 가지는 문제 인식과 이를 개선하기 위한 효율적인 방안을 제시하는 것과 같은 느낌을 받았다. 네트워크 자동화는 정확히 그 부분을 목표로 한다. 단순한 장비 설정 초기화 작업 뿐만 아니라, 네트워크 운영의 효율성을 높이는 것이 핵심이다.

저자는 자동화의 장점을 다소 모호하게 설명하는데, 내용을 읽은 후의 내 생각은 다음과 같다.

하드웨어 추상화, 비즈니스 요구사항 컴파일, 자동화 시스템 빌드

결국 모든 것을 소프트웨어의 세계로 끌고 오기 위한 작업들이다.

하드웨어의 사양이 각기 다르니 인터페이스를 통해 상호작용하고, 모호했던 실세계의 요구사항은 명시적인 프로그래밍 언어로 구체화한다. 각각의 필요한 구성 요소들이 애플리케이션 레벨에 모였으니, 나머지 문제는 프로그래밍이 해결할 수 있다. 코드가 있으니 워크플로를 눈으로 볼 수 있다. 코드가 되었으니, 보안 감사나 개선은 물론이고, 소프트웨어 개발 수준에서 사용되는 모든 방식의 효율적인 확장이 가능해진다.

[ 알아야 하는 것들: 얕고 넓게 ]

초반에는 배경/역사, 그리고 11장까지는 주변 또는 기초가 되는 기술을 다룬다. 자동화에 대한 본격적인 이야기들은 12장이 되어서야 다룬다. 앞의 모든 내용들은 다 이 부분을 위한 준비라 하더라도 과언이 아니다. 12장에서 앤서블, 노르니르, 테라폼 세 종류의 도구에 대한 설명과 실습을 진행한다. 13장에서 DevOps에서 다루는 CI/CD 개념을 소개하고, 14장에서는 최종적으로 네트워크 자동화를 달성하기 위한 실제적인 고민과 방법들이 제시된다.

그 사이에도 참고할 만한 내용들은 있다. Linux와 Python에 대해 다루더라도, 네트워크와 연관된 내용들이 일부 포함되어 있다. 네트워크 장비와 통신하는 프로토콜ㅡ 개발자라면 익숙할 REST(ful) API에 대한 내용도 있다. 그 근간은 웹 이전에 서로 다른 시스템들 간의 통신에서 비롯되었음을 알 것이다. 실질적인 활용처에 대해 항상 의문을 가졌는데, 이런 분야에서 활용되고 있었다. 어찌되었든 대부분 알고 있거나 들어본 내용이라, 처음부터 정독하기보단, 핵심 내용을 본 후에 관련 지식이 부족함을 느끼면 돌아와서 공부하는 편이 나을 것 같다.

[ Brief Overview ]

나는 목적을 가지고 소비할 수 있는 형태의 책을 선호한다. 문제를 정의하고, 문제를 해결하는 이야기가 담긴 책. 강의에 비유한다면 교양보다는 프로젝트 실습을 선호한다. 그러나 이 책은 아쉽게도 교양에 가깝다. 여러 교수님의 특강으로 구성되는데, 다행히 내용은 이어지는 그런 느낌이랄까.

이 분야 자체가 지속적인 논의를 거치며 성숙해지고 있다는 사실에 비춰본다면, 이러한 형태가 현재로서의 최선일수도 있겠다는 생각도 든다. 향후 어떤 게임 체인저가 판도를 뒤바꿀지 모르는 상황에, 변화에 뒤쳐질 내용으로 실무서를 쓰기보단, 최대한 많은 이들이 입문할 수 있도록 돕는 것이 생태계를 위해 바람직한 방향일지도 모른다. 그렇지만 기대가 컸던터라 조금 아쉬움이 남는 그런 책이었다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

ORAKLE 2024 컨퍼런스 후기

ooMia — Sun, 11 Aug 2024 07:13:31 +0900

Intro

팜플렛과 티셔츠

업사이더 damon님의 공유로 알게 되어 컨퍼런스에 참석했다. 카이스트 블록체인 학회라 사뭇 기대했다. 예쁜 티셔츠도 받았다!! castle님이 선착순으로 받아오신 것을 보고 나도 얼른 받아왔다. (아직 입어보진 않음)

등받이 있는 좌석 의자나 방석이 있었다면 더 편하게 오래 앉아있을 수 있었을텐데, 그 부분이 좀 아쉬웠다. 그래도 다행히 2층에 업사이드 휴게실이 있었기 때문에, 음료를 마시며 들을 수는 있었다.

발표

모든 발표의 내용을 간단히 다룰 것이지만, 개인적으로는 첫 번째, 세 번째 발표에서 얻은 인사이트가 많았다. 외부 스피커분들의 발표는 홍보에 가깝다고 느꼈기에 후기에서는 다루지 않을 것이다.

#1. Development of Fully On-Chain Dark Pool

DeFi에서 고액 트랜잭션을 날리면 MEV 피라냐들에 의해 너덜너덜해진다는 것은 알고 있던 사실이다. 그리고 이를 방지하기 위해 L2 sequencer 또는 private mempool을 사용한다. 발표자분께서는 private mempool에서 운영진이 몰래 트랜잭션을 감찰하는 행위가 비일비재하게 일어나고 있다고 하셨다. 이러한 관점에서 public하게 접근할 수 있지만, secure하게 트랜잭션이 관리되는 dark pool이 대안이 될 수 있다는 것!

발표자분께서도 언급하셨지만 이미 Renegade가 성능도 좋고, fine tuning된 dark pool을 선보인 상태다. 하지만 시도 자체만으로도, 그리고 현재 프로토타입을 완성한 상태라는 사실만으로도 고무적인 성과라 생각한다.

내가 집중한 부분은 기술적인 부분이다.

정보 유출이 발생하는 기존 CLOB (Central Limit Order Book) 방식과는 달리, Dark pool은 주문이 공개되지 않고, volume matching 방식을 통해 대량 주문을 비공개로 매칭하는 탈중앙화 거래 플랫폼이다. 이를 통해 투자자들은 시장의 반응을 최소화하며 고액/대형 주식을 거래할 수 있게 된다.

Frequent Batch Auction 기법을 사용하여 주문을 한꺼번에 처리함으로써, 주문이 개별적으로 처리될 때 발생할 수 있는 시장 영향과 가격 변동성을 줄일 수 있다. 발표자분께서 논문을 통해 단일 트랜잭션의 암호화로는 privacy를 챙길 수 없음이 밝혀졌고, 결국 privacy를 위해서는 다수의 트랜잭션을 묶어 처리하는 배칭이 필수적이라는 말씀을 하셨다. 이 과정에서 noise order(허위 또는 소규모 주문)를 사용하여, 실제 거래 의도를 숨기고 시장 조작을 방지한다. 일반적인 배칭은 시간 간격이 일정하더라도 상관없겠지만, 발표자분께서는 배칭 간격을 거래량에 반응하도록 구현했고, noise도 원하는 정도에 비례하여 가스비를 청구하기 때문에 차익거래자들은 noise를 포함시키지 않을 수 있도록 구현했다고 한다.

또한, 보안 강화를 위해 FHE (Fully Homomorphic Encryption)와 같은 암호화 기술을 고려했다고 한다. 내가 이해하기로는 기존 zk는 여러 유저가 독립적으로 동시에 연산하는 것이 어렵고, mpc는 반드시 여러 노드를 거치며 연산에 선형적인 시간 복잡도가 필요하여 제약이 많다고 이해했다. 이에 비해 FHE는 특별한 상태 저장 없이 개별 노드가 독립적으로 연산할 수 있기 때문에 성능상 이점이 있는 것으로 이해했다. 이렇게 FHE를 활용하여 거래 데이터가 암호화된 상태에서도 계산(동형 연산)이 가능하게 함으로써, 데이터의 기밀성을 유지하며 거래를 처리할 수 있다.

이해가 안 되었던 부분은, 기존에 가스비 경쟁을 통해 승자가 100% 모두 가져가는 구조가, 본 체인에서는 차익거래자 수 n에 대해 MEV가 1/n이 된다고 한 부분이 의아했다. 당시에는 듣는대로 적느라 급급했는데, 물어볼걸 그랬다!!

#2. Financial Engineering, "On-chain Finance"

이 팀은 restaking, yield farming를 키워드로 삼아, Pendle에 대해 알아보는 것이 컨셉으로 보였다. Pendle의 SY(standardized yield tokens)는 일반 yield-bearing token으로 교환할 수 있고, SY는 다시 둘로 쪼개 PT(principal token) and YT(yield token)로 만들 수 있다.

YT가 제공하는 yield가 전통 금융의 interest rate와 비슷하고, staking 기간이 종료되었을 때 (유럽식) 또는 staking 기간 중 (미국식) 적정가로 claim 할 수 있다는 특성이 전통 금융의 option과 유사하다는 것을 토대로 option의 현재 가치를 역산하는 금융 공학 모델링을 적용할 수 있다.

팀이 모델링을 위해 고려한 내용은, 전부 정확히 이해할 수는 없었지만 꽤나 많았다.

staking 기간 동안 예치한 토큰을 회수할 수 없으므로 영국식 옵션이라 판단하고, 전통 금융이 인플레이션 등을 반영하여 시간 t에 대한 함수로 이자율을 정의한 모델이 여기서는 적합하지 않다고 판단하여 다소 고전적인 모델을 선택하고, 몬테카를로 알고리즘 기반으로 r = APY에 대해 독립시행을 거듭하면 정규분포를 따르는데, interest rate는 음수가 될 수 없으니 로그를 취하고... ~~발표자분께서 열심히 설명해주셨는데ㅜㅜ 내용이 너무 어렵다~~

내가 봤을 때, 핵심 키워드는 Black–Scholes model이다. 위에 첨부한 가정은 실제 환경과 맞아 떨어져보이지는 않지만, 발표자분께서는 모델링의 한계로 덮어두고 넘어가셨다. 아무튼! 이러한 모델링과 과거 데이터를 기반으로, 위에서 말한 몬테카를로 기법을 적용하여 가치 예측 모델을 Python으로 만들었고, 그 결과도 UI 형태로 제공해주셨다! ~~하루 정도만 열어둔다고 하셔서 스크린샷으로만 남겨둔다~~

(1) 괜찮은 예상 결과 / (2) 과적합

(1)은 그나마 괜찮은 느낌의 예상 결과다. 트렌드를 잘 반영하고 있다고 생각한다. 이러한 케이스들이 찾아보면 어느 정도 있다. (2)부터는 이상한 결과물들을 소개한다. 데이터는 충분해보이는데, 이상하게 과적합되어 있다. 모든 순간에 대해 99% 이상의 예상을 보여준다.

(3), (4) 정확하지 않다가 마지막에만 정확해진다.

(3) 뭐 아예 들쭉날쭉인 경우도 있고, (4) 대충 트렌드만 따라가는 경우도 있는데, 대부분이 최종 결과값을 추종하는 것을 보면 최종가에서 역산하는 방식으로 모델링을 하셨나 싶기도 하다. 만약 정확한 방식의 시계열 데이터 모델링을 진행하셨다면 실시간으로 예측이 가능할테고, 정확도가 높은 모델 한정해서는 실제로 사용해도 괜찮을 것 같다는 생각이 들었다!

청중 질문에서 1시간 단위의 데이터를 활용한 이유에 대해 물어봤고, 더 짧은 간격이었다면 좋았을 것 같다는 의도로 보인다. 답변은 API를 통해 구할 수 있는 최선이었다고 한다. 그리고 발표자분께서 느낀 점 말씀해주실 때도 데이터, 정확히는 거래량이 부족한 경우가 많아서 어려움이 있었다고 하셨다.

#3. "Open Source Contribution"

발표자분께서는 소소한 오픈 소스 기여의 의미를 청중들이 쉽게 이해할 수 있도록 '건물의 전구 하나 갈아 끼우는 것' 정도로 비유하셨지만, 적절한 비유가 아니라고 본다. 특히, geth, reth와 같이 사용하는 클라이언트의 수가 많다면 더욱 그렇다. 복제되는 제품의 파급력이 어마어마하기 때문에, 이륙 직전의 비행기를 수리하는 정도 아닐까? 비록 실제 기여한 부분이 핵심적인 내용은 아니었지만 잠재된 영향력은 크다고 생각한다.

4주의 EIP 공부 후에 10주 간 기여 활동을 시작했다고 한다.
이 팀이 참조한 EIP는 중요한 부분을 다루었을거라 생각하여, 개인 공부에 도움이 될 것 같아 찍어왔다!

개인적으로 오픈 소스 기여 활동에 큰 관심을 가지고 있어서, 어떤 방식으로 접근했고, maintainer들과 어떻게 소통하며 피드백을 반영했는지 공유하는 경험들이 흥미롭게 들렸다. cancun 업데이트에서 추가된 blob-carrying transaction에 의해 수정되는 가스비 계산식에 대한 문서 수정도 진행했다고 하는데, 정말 작은 것에서도 기여를 할 수 있음을 깨달았다. 기여를 진행하기 위해 근본적인 동작 원리에 대해서도 공부하게 될테고, 언어에 대한 이해도 높아질 것이다. 그리고 블록체인 자체가 탈중앙화 방식으로 동작하기 때문에, 생태계에 기여하는 것이야말로 핵심적인 활동이라 생각한다.

마치며...

한 달 후에 프로젝트를 진행하는데, 오픈 소스에 기여하는 것도 유익할 것 같다! 하지만 오픈 소스는 언제든 할 수 있는 반면에, Web3 audit 분야는 멘토님들과 함께 있을 때 진행하는게 더욱 유의미한 성과를 낼 수 있을 것 같아 장단점이 있다고 생각한다. ~~알아서 잘 정해주시겠지...~~

그리고 이번 컨퍼런스를 통해, 만약 발표를 하게 된다면 어떤 식으로 준비해야 할 지 감을 잡을 수 있었다. 물론 주어진 시간도 중요하겠지만, 결국 모든 청중을 이해시킬 수 없다는 것, 그러나 모두에게 임팩트있는 결과물을 보여주어야 한다는 것을 깨달았다.

업사이드 아카데미 한 달 후기

ooMia — Mon, 29 Jul 2024 03:35:44 +0900

낯선 세계에 들어와, 적응하기 위해 정신없이 시간을 보냈다.

보안도 처음이고, Web3도 처음이고.

벌써 한 달이 지나가고 있다.

지금까지의 시간을 돌이켜보면 스스로를 한계에 밀어 붙이며 끊임없이 성장하는 시간이었다.

물론 앞으로도 계속 그럴 것이고, 그래야만 한다.

아무것도 모르는 초심자가 스스로 사고하고, 자기 주도적으로 공부하려면 숱한 시행착오가 필요하다.

아카데미 시작 전의 내가 그러했다. 한 달을 준비했지만, 수박 겉핥기도 못했다. 무엇이 중요한지, 그게 왜 중요한지, 그 내용이 어떻게 활용되고 확장될 수 있는지, 그 내용을 어떻게 공부할 수 있는지 웹 상의 교육 자료도 부족하고, 실무 경험도 없기 떄문이다. 이런 맥락에서 언제나 손 내밀면 닿을 거리에 있는 좋은 동료와 멘토님들 덕에 나의 한 달은 지치지 않았다.

언제나 그렇듯 대부분의 강의는 사고를 확장시켜줄 뿐, 그 깊이를 더해주지는 못한다. (물론 일부는 깊다) 아무것도 모르던 내겐 가끔 과제가 어렵게도 느껴졌는데, 개인 학습 시간이 충분히 보장되어 있고, 센터 출석도 강제되지 않아 열심히 조사하고, 질문하며 과제를 해결할 수 있었다.

두나무의 지원, 드림핵의 인프라, 그리고 티오리의 좋은 인재분들과 좋은 동료까지..!!

내가 정말 필요할 때 도움을 구할 수 있는 조력자들이 있다는 것이 이토록 큰 힘이 될 줄 몰랐다.

이렇게 좋은 기회가 또 언제 있을까 싶은 마음에, 근 1년 중 가장 치열했던 한 달이 아니었나 싶다.

물론 어려움을 쉽게 극복하지 못한 스스로를 보며, 뛰어난 동료들과 나를 비교하며 실망한 적도 있었다.

하지만 그것도 잠시, 오히려 그런 결핍이 내 경쟁심과 호승심을 불태우고 나를 다시 일어날 수 있게 만들어준다.

그렇다고 누군가를 짓밟고 올라가고 싶지는 않다. 오히려 내 안에 있는 것을 끊임없이 내어줘도, 항상 모든 것이 넉넉한, 그런 풍성한 사람이 되고 싶다........... (외부에 공개할 수 있는 내용은 이 정도 밖에 없다.)

하지만 역시나 사람은 어렵다

[서평] 실무로 통하는 타입스크립트

ooMia — Sun, 21 Jul 2024 11:45:44 +0900

실무로 통하는 타입스크립트 / 슈테판 바움가르트너 지음 / 한빛미디어

[ 찾아쓰는 실무 메뉴얼 ]

타입스크립트가 제공하는 기능은 무언가를 빠르게 만들기보다 정확하게 만드는 것에 집중한다. 이는 차근차근 쌓아나가며 흔들리지 않는, 커다란 구조물을 만들기 위한 노력에 가깝다. 하지만 모든 타입을 정의하는 것은 비효율적이고, 그것은 타입스크립트를 잘 쓰는 방법이라 할 수 없다.

생산성과 개발 편의성 모두를 챙길 수 있다면 얼마나 좋을까?

그러한 관점에서 이 책은 직관과 현실 사이에서 적절하게 타협하는 방법을 알려준다. 타협이라는 단어가 이상하게 보일 수 있지만, 경험에서 나온 면도날이야말로 불필요한 걱정을 시원하게 잘라버린다. 모두가 더하는 방법만 가르쳐서 작업이 과하게 무거웠다면, 이제 이 책을 통해 핵심 외에는 덜어내는 방법을 배워보자!

[ 구성 ]

자주 마주하는 중요한 문제부터, 복잡하고 특수한 경우의 문제까지!

실제로 저자가 이러한 구성을 의도했는지는 확실하지 않지만, 읽는 동안 `파레토의 법칙`을 느낄 수 있었다. 실제로 개념을 무작위로 혼재시키지 않고, '빌드-업'하게 되면 이런 구조가 생길 수 밖에 없다. N회독하는 입장에서 앞부분에 집중하고, 뒷부분은 나중을 위해 쉽게 훑고 넘어갈 수 있어서 좋았다.

앞의 내용은 Major하고, 뒤의 내용은 Minor하다.

[ 형식 ]

문제 인식과 해결의 반복이 가져다주는 사고의 확장

1. 문제 상황을 제시하고,

2. 핵심 답변을 제공,

3. 이후 구체적인 내용 설명

과 같은 형식을 갖는다.

이러한 형식은 책을 문제 해결 도구로 소비하는 활용 지향적 독자들에게 적극적으로 추천하며, 특히, 전자책 형식으로 검색이 가능할 때, 더욱 빛을 발한다.

물론 처음부터 끝까지 곱씹으며 음미하는 탐구형 독자나

N회독하며 책을 빠르게 훑어나가는 속독형 독자들에게도 유용하다.

잘 정리된 두괄식 정보로 지치지 않고 책을 쉽게 읽을 수 있도록 도와준다.

[ 고찰: AI와의 비교 ]

여기서는 조금 현실적인 얘기를 해보자.

솔직한 이야기로, chatGPT 에게 책의 문제 상황과 맥락을 동일하게 입력하면, 더 많은 제안을 해온다. GitHub Copilot 또는 유사한 코드 생성 AI에게, 작성하고 있는 코드의 개선 방법을 문의하면 바로 방법을 제안한다. 또한 책은 시간이 지날수록 그 내용이 낡겠지만, AI는 꾸준히 학습해나간다.

그렇다면 이 책이 왜 의미를 갖는 것일까?

이 책의 목표에 대한 저자의 말을 인용하면,

필자의 목적은 초보자에서 전문가로 안내하는 가이드이자
책을 다 읽은 후에도 바로 사용할 수 있는 빠른 참고 자료를 제공하는 것이다.
1년에 네 번씩 릴리스되는 타입스크립트 최신 기능을 한 권의 책에 모두 담을 순 없다.
그러므로 앞으로 있을 모든 변화에 대비할 수 있도록 프로그래밍 언어의 오래 지속되는 측면에 초점을 맞췄다.

생산성에 미쳐 AI를 매우 적극적으로 활용했고, 또 하고 있는 사람으로서, AI는 당장의 해결책을 제시해주지만, 이를 통해 사고력을 기를 수는 없다. AI는 어떠한 방법이 유용하다고 제안하겠지만, 이면에 그 유용성의 근거는 학습의 결과일 뿐이다. 많은 사람들이 좋다고 했으니 당신에게도 유용할 것이다라는 전제가, 과연 거대한 시스템을 구축하고 있는 당신의 프로젝트의 방향성에도 적합한지 고민해봐야만 한다.

이 책에서는 저자의 사고 과정을 읽을 수 있다.

합리적인 판단에 이르기까지 향후 방향성을 고려하며 경우의 수를 따진다.

결코 AI가 나쁘다는 것이 아니다. 당연히 더 효율적이다. 하지만 매 순간 다양한 제안에, 스스로 무엇이 좋고 나쁨을 판단하지 못하는 수준이라면, 그래서 올바르지 못한 선택을 되돌리느라 시간을 허비하고 있다면, 이 책은 당신을 건강한 프로그래머로 양성시켜 보다 더 효과적인 선택을 하는데 큰 도움을 줄 것이다.

덧붙이자면 저자는 단순히 typescript의 기능을 소개하는 것이 아니라, 다년간 개발 경험을 토대로 실무적인 관점에서 생산성을 높이기 위한 방법을 소개한다. 기술을 다루는 책들 중 오랜만에 도구를 지배하고, 도구에 종속되지 않는 유연한 사고를 전파하는 저자를 만나서 반가웠다.

[ 내용 ]

https://www.typescriptlang.org/play/

TS Playground - An online editor for exploring TypeScript and JavaScript

The Playground lets you write TypeScript or JavaScript online in a safe and sharable way.

www.typescriptlang.org

본격적으로 TypeScript를 공부하는 학생들에게는 다음 사이트를 추천한다.

문제를 해결하며 드는 고민들을 기억해두고, 이 책의 저자와 비교해서 보면 좋다.

타입스크립트의 정체성이 곧 `타입 강제성`이기 때문에, 타입, 형식, 그리고 관리 패턴에 대한 내용이 책의 대부분을 차지한다. let과 const 키워드에 대한 사소한 차이나 리터럴 const를 활용하는 꿀팁, carrier 패턴, rest element, 제네릭 등 확장성 증대를 위한 방법, 또는 React와의 연관성을 살려 JSX props 관리 및 조드, 투슬래시 등의 라이브러리 소개도 좋았다.

[ 마치며... ]

재밌었다!

문제를 발견하고, 고민하고 있는 저자를 옆에서 지켜보는 기분이었다.

저자는 초보자들도 품고 싶어했지만, 개인적으로 초보자들에게는 추천하지 않는다.

굳이 읽겠다면, 플레이그라운드를 해결하며 읽어보시는 것을 추천하겠다!

[ 잡담 ]

번외로 10장의 제목은 `타입스크립트 및 반응`이다.

처음에는 내 눈을 의심했고, 그 다음에는 `어, 이거 리액트가 맞지 않나?` 싶었다.

하지만 내용에는 멀쩡하게 리액트라 적혀있는 것을 보면,

아마 원저자가 '리액트의 사용'을 Reaction으로 적어두었을 가능성도 있다.

(그러나 진실은 미궁 속으로...)

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

[서평] 혼자 공부하는 네트워크

ooMia — Sun, 21 Jul 2024 05:43:07 +0900

혼자 공부하는 네트워크 / 강민철 지음 / 한빛미디어

[비전공자부터 주니어 개발자까지]

키워드만 두고 보았을 때에는 매우 기초적인 내용을 다룬다.

하지만 책의 볼륨이 넉넉한 것은, 그 뼈대가 되는 키워드에 충분한 양의 살을 붙였기 때문이다.

장점

1. 비전공자의 수준에서도 이해하도록 이론의 맥락부터 자세히 설명한다.

2. 자세한 설명을 위해 다양한 도식을 활용한다.

3. 단순 컴퓨터 과학 이론을 넘어, 하드웨어 및 소프트웨어를 활용한 실습을 지원한다.

4. 혼자 공부하는 사람들을 위한 키워드 정리 노트를 제공한다.

단점

1. OSI 계층을 모두 설명하다보니, 다루는 내용의 깊이가 다소 얕다

2. 전공자 입장에서는 이미 알고 있는 내용을 장황하게 설명한다는 느낌을 받을 수도 있다.

3. HTTP/3.0 등의 최신 웹 기술에 대한 내용은 언급만 있다.

> 한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

업사이드 아카데미 OT

ooMia — Mon, 1 Jul 2024 22:15:35 +0900

오늘 OT는 6월 13일 한 통의 이메일로부터 시작됐다.

OT 공지 이메일

습도가 높은, 다소 더운 날이었지만 혹시라도 늦을까봐 1시간 일찍 출발했다.

(너무 도착한 탓에 오히려 카페에서 기다렸지만 후회하지는 않는다)

이렇게 포스팅을 할 줄 알았다면, 사진도 많이 찍는건데...

아직 보여줄 수 있는건 미림타워 별관의 네이버 지도의 로드뷰 뿐이다

화살표가 별관 입구

밖은 더웠지만, 내부는 시원했다.

오자마자 명찰과 티셔츠를 받았다.

이는 사전에 문자 및 이메일을 통해 미리 조사된 내용을 바탕으로 지급되었다.

(솔직히 기념품 같은 거 하나도 기대 안 했는데 감동 받음..)

OT 이메일에 추가 항목으로 [사전 조사] 진행

앞에는 업사이드 로고가, 뒤에는 업사이드 아카데미가 표기되어있다.

명찰(좌) // 입은 후 집에 다녀와 세탁한 티셔츠 후면 (우)

이 밖에도 다양한 선물이 많았다

이름이 기입된 스탠리 텀블러, 떡메모지, LAMY 볼펜, 노트북 커버, 바람막이 등등

하지만 물질보다 이러한 물품들이 운영진에 의해 손수 포장되었고, 편지의 이름도 손수 작성되었다는 점이 감동이었다.

( underdogs 운영진분들께서 많이 고생하셨다고 합니다 )

이름이 각인된 텀블러 (좌) // 이름을 손수 작성한 편지 (우)

이렇게 사진으로 보여줄 수 있는 물품보다 더욱 값지다고 생각하는 것은

1. 국내가 아닌 세계 최고를 꿈꾸는 아카데미의 비전

2. 엄청난 수의 멘토진 (심지어 다들 능력자...)

3. 전폭적인 지원에 부응하고자 하는 열의 가득한 19명의 업사이더들

이라 생각한다.

주 7일, 이후 나의 4개월을 모두 이곳에 쏟으며, 수료 후에 성장해있을 내 모습을 상상하니 오랜만에 가슴이 뛴다.

학력도 대단하고, 이력도 대단한 교육생들 사이에서 선한 영향력을 미치기 위해 더욱 치열하게 공부하리라 다짐하며

오늘의 기록을 마친다.

https://upside.center/

업사이드 아카데미(UPSide Academy)

두나무와 티오리가 만든 Web3 보안 전문가 양성 프로그램입니다.

upside.center

[서평] 실전 레디스

ooMia — Sat, 22 Jun 2024 20:33:19 +0900

실전 레디스 표지

[1년 전에 이 책이 있었더라면]

약 7개월 전, RDBMS의 쿼리를 최소화하기 위한 목적으로 자체 캐싱 서버 구축 프로젝트에 참여했다.
Spring 프레임워크에서 Lettuce 라이브러리를 통해 Read-Through 및 Write-Through 방식으로 구현했고, 특정 키 패턴에 대해 동적으로 TTL을 수정할 수 있도록 하는 동시에, 한정된 메모리 내 LRU 방식으로 Cache Evict 전략을 구성했다.

다 끝난 뒤에 돌이켜보면, 그다지 특별하지 않은 일반적인 패턴이라 생각하지만, 당시에는 수많은 정보의 흐름 속에 무엇이 적합한지 따져보느라 시간을 많이 소요했던 것 같다. 만약 이러한 책이 당시에 있었다면, 입문부터 다양한 응용까지 큰 도움을 받았을 것 같다.

[책의 구성]
이 책의 구성은 크게 "기초 > 실전 > 고급" 단계로 나뉜다.

| <기초> 파트를 요약하자면, 모든 내용들이 처음 입문하는 이들에게 필요한 내용과 필요한 정도의 깊이로 제공된다.
| 처음부터 끝까지 정독하는 것을 추천한다.

기초 단계에서는 각 자료형의 특징과 각 명령어에 대해 간단히 소개한다.
물론 명령어에 대한 검색 기능은 공식 사이트에서도 지원한다. 하지만 명령어 이름으로만 검색이 가능하기 때문에, 기능과 시간 복잡도를 가볍게 훑어볼 수 있는 점은 입문에 큰 도움이 된다고 생각한다.

가벼운 팁 느낌으로 키 명명법이나 각 자료형을 사용할 때의 주의사항을 소개한다. 또한 처음에는 발견하기 어려운 HyperLogLog 등의 유용한 확률적 자료구조도, 도식을 통한 간단한 설명과 함께 설명한다.
일반적인 프로그래밍 언어에서의 자료구조 및 동작과 차이가 있으므로 입문에 큰 도움이 되리라 생각한다.

RTT 및 지연 시간을 감소시키기 위한 고급 기능과 실제 웹 어플리케이션 구성 예제도 소개하는데, 응용의 깊이는 다소 얕다.
하지만 생소하다면 언제 어떤 방법을 사용하는 것이 좋은지에 대한 청사진 제공한다는 측면에서 역시 입문에 필요하다.

| <실전> 파트를 요약하자면, 운영 단계에서 필수적인 기본 내용을 담고 있다.
| 각 주제에 대한 깊이는 얕지만, 언제 무엇을 어떻게 하면 될지, 방향성을 제시한다.

실전 단계에서는 시스템 구조적으로 성능을 개선하고, 문제를 식별하는 트러블 슈팅 요령을 소개한다.
데이터 삭제 패턴, 캐시 전략과 같은 간단한 팁에서부터
redis.conf, 로깅, 모니터링, 성능 측정, 분산 및 클라우드 환경에서의 운용 등까지 다양한 주제를 가볍게 다룬다.

다소 아쉬운 점은 실습 과정이 plaintext라 가독성이 좋지 않다.
이 부분은 n회독을 수행하며 자체적으로 필기를 하면 도움이 될 것 같다.

| <고급> 파트는 RESP, SDS, ae, RAX, COW, Raft, HyperLogLog 등 Redis를 구성하는 기술 및 이론을 소개한다.
| Redis 소스 수준에서의 이야기를 다루므로 github.com/redis 를 참고하는 것도 좋을 것 같다.

책 끝에 있는 INDEX도 명령어별 활용되는 지점을 매우 자세하게 기록해두어, 특정 명령어의 다양한 용례를 확인해보기 좋다.

[총평: 레거시 캐싱 서버의 유지보수를 처음 담당하게 된 이들의 필독서]
자료형의 특장단점부터 각 명령어의 간략한 소개까지 당장 알아야 하는 내용을 통해 Redis를 빠르게 이해할 수 있다.
deprecated 명령 및 버전 별 Breaking Change에 대해서도 명시하기 때문에, 오래된 버전을 최신과 호환되도록 보수해야 하는 경우에도 도움이 될 것 같다.
내용이 많으므로 끝까지 한 번 정독하는 것보다, 필요한 내용 위주로 강조 표시하며 N회독하는 것이 좋아보인다.

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

Web3 입문 - Speed Run Ethereum

ooMia — Sat, 22 Jun 2024 19:58:39 +0900

Web3는 다소 입문 장벽이 높다고 알려져있다.

하지만 이 튜토리얼을 진행한다면 단계별로 자연스럽게 필요한 지식을 숙달할 수 있다.

Speed Run Ethereum

Learn how to build on Ethereum; the superpowers and the gotchas.

speedrunethereum.com

진행해보면 튜토리얼이 깔끔하지 않은 점도 있다.

환경에 따라 README.md 의 가이드가 충분하지 않고, 자신만의 트러블 슈팅이 필요한 경우가 있다.

특히, DEX(Decentralized Exchange)를 개발할 때 그러한 불편함을 많이 느꼈다.

1. 일차적으로 튜토리얼 제작자가 제공하는 [튜토리얼 설명 포스트]를 참고하자.

2. 포스트에는 명시되어 있지 않지만, 테스트에 존재하는 작업들이 별도로 준비되어 있음을 명심하자.

3. 그럼에도 몇몇의 오류가 해결되지 않을 수 있다. 먼저 각각의 코드 간의 관계를 정리하고, "왜?" 이렇게 작성했는지 생각해보자.

- 타입스크립트를 통해 작성된 테스트에서 어떤 방식으로 검증을 진행하는지

- 스마트 컨트랙트를 배포하는 과정에서 어떤 작업들이 진행되는지

- 컴파일러 버전에 따라 동작이 달라지는 경우가 있을지 생각해보면 좋다.

4. 마지막으로, 잘 모르겠다면 내 스마트 컨트랙트를 참고해도 괜찮다.
[Contract: 0xEEf93933b376674D6D95768fdD8cCaF75882dB4d]

이러한 난관을 스스로 극복하고 배포에 성공하는 작업의 짜릿함이 바로 개발의 원동력이 아닐까 싶다.
(++ 11/13: 지금 보면 부끄러운 수준의 코드인데 경험 없는 초보자 시절이니 귀엽게 봐주세요)

2024/07/01 현재 5개의 튜토리얼을 완료했다.

1. https://simple-nft.oomia.click/

2. https://decentralized-staking.oomia.click/

3. https://token-vendor.oomia.click/

4. https://dice-game.oomia.click/

5. https://minimum-viable-exchange.oomia.click/

DEX 튜토리얼까지 완료하면 `BuidlGuidl`에 가입할 수 있다.

해당 커뮤니티는 스폰서를 통해 받은 이더리움을, 생태계에 유익한 활동을 하는 이들에게 나눠주는 방식으로 개런티를 지급한다. 자세한 내용은 https://buidlguidl.com/ 참고!

간단한 미니 프로젝트를 진행한 기록은 velog에서 시리즈로 관리 중이다.

시리즈 | speedrun-ethereum - oomia.log

Vercel dApp 배포까지의 과정을 기록한다. https://simple-nft.oomia.click/ 5일 전

velog.io

업사이드 아카데미 1기

ooMia — Tue, 28 May 2024 08:30:43 +0900

블록체인 기술을 기반으로 탈중앙화된 다음 세대의 Web3 산업 생태계를 육성합니다

업사이드 아카데미 1기는 Web3 산업에 필요한 보안 전문가 양성을 위한 교육을 진행한다.

선발 과정

1. 이력 및 자기소개서

일반적인 이력서 및 자기소개서를 작성하면 된다.

이 내용은 이후 면접에서 활용되는데, 내부 폼에 작성하므로 제출 전에 모든 내용을 옮겨 적어두는 것을 추천한다.

2. 실기 시험

https://dreamhack.io/

해커들의 놀이터, Dreamhack

dreamhack.io

해당 사이트에서 CTF를 진행한다.

평소에 워게임 경험이 없다면, 레벨 1 문제를 풀면서 필요한 도구와 환경을 준비해두는 것이 좋다.

이번 CTF에서는 10여개의 문제가 출제되었고,

암호학 이론, 브루트 포스 어택, SQLI, 리버스 엔지니어링 등 기존 바이너리 익스플로잇 / Web2 기반의 문제와

특별히 Web3 문제가 4개 출제되었다.

문제를 해결한 과정을 면접에서 설명할 필요가 있으니,
이 역시도 문제와 과정을 기록해두며 진행하는 것을 추천한다.

3. 대면 면접

서울 플라즈마스페이스에서 진행됐고, 30분 제한을 두고 3명이 한 그룹으로 들어갔다.

간단한 자기소개 이후에, 제출한 서류를 바탕으로 교육 참여 목적을 물어보셨고,이후 실기 시험 풀이 방법 설명, 간단한 이론에 대한 질문을 진행했다.

아마 풀이한 문제 목록을 바탕으로 수준을 조절하시는 것 같다.

~~(옆옆 지원자와 난해한 용어로 이야기를 주고 받는 걸 듣고만 있었다...)~~

4. 합격 이후

https://upside.center/

커리큘럼 주제

우선, 본 프로그램은 교육 > 과제 > 프로젝트 순의 단순한 구조이다.

다만, 보안 관련 경험이 부족한 내가 따라가기 위한 방향성을 잡고자 메일로 문의했다.

질문

답변

5. 남은 한 달의 준비 기간

위의 답변에서 주어진 것처럼 드림핵 강의를 수강하고, 토이 프로젝트를 수행하려 한다.

그것을 블로그, 필요하다면 깃허브에 기록으로 남길 예정이다.

[서평] 개발자 기술 면접 노트

ooMia — Sun, 28 Apr 2024 10:23:29 +0900

책 표지

총평: 중급 개발자들의 지침서

개발 경험만 있다면, 언제 어디서나 가볍게 읽기 좋은 책

평소에 대중교통을 이용한 이동 시간을 활용하여 독서를 즐긴다. 이 책은 성인 남성의 두 손바닥을 나란히 모은 정도의 크기다. 그러니 가볍게 들고 다니며 읽기에도 좋은 정도의 크기다.

총 320 페이지로 구성되어 있는데, 다루는 주제가 많아 내용이 다소 얕다. 여기서 ‘얕다’는 표현은 필요한 내용이 키워드로 추상화되어 있다는 뜻이다. 개발 경험이 많다면 쉽고 빠르게 인사이트를 얻겠지만, 개발을 처음 시작한다면 난해하다고 느낄 수도 있다.

참조할 수 있는 다양한 간접 경험들

취업 준비생의 입장에서는 ‘내가 잘 준비하고 있는건가?’하는 의문에 불안해지기 쉽다. 경험이 부족한 탓이다. 나를 평가하는 사람의 입장을 잘 헤아리지 못하고, 경험해보지 못한 다양한 ‘카더라’들을 필터링 할 능력이 없기 때문이다.

이러한 관점에서 이 책은 독자 스스로 기준을 정하는데 큰 도움을 준다. 나를 평가하는 면접관이 어떤 면을 긍정적으로, 또는 부정적으로 보는지 귀띔해준다. 커리어에 따라 보다 집중해야 하는 부분도 강조한다. 마치, ‘너네는 이런 실수 하지마라.’는 것처럼, 나보다 먼저 취업을 준비했던 선배가 남긴 취준 회고록을 읽는 느낌이다.

주의할 점은 이 책이 전반적으로 경력 개발자의 이직에 초점이 맞추고 있다는 것이다. 물론 신입 개발자의 경우에 대해 상술하는 경우도 있다. 하지만 그 경우에도 아기새에게 모이주는 것만큼 친절하지는 않다. 독자는 파편화된 수많은 팁들 사이에서 본인에게 필요한 내용을 선별할 수 있어야 한다.

** 추가로 이 책의 내용을 바탕으로 이력서를 수정해보았다.
6장의 이력서를 한 장으로 축약했고, 상세 정보를 링크로 분리했다.
https://shorturl.at/qxHOY

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.