Machineboy空

Excercism - Building Telemetry (out, ref)

안녕도라 — Fri, 23 Jan 2026 16:37:26 +0900

문제요약

RemoteControlCar가 있고, 이것을 사용하는 클라이언트가 있을 때 여러 정보(스폰서, 달린 거리)등을 보내줘라.

SetSponsors(), DisplaySponsors()
GetTelemetryData()
GetBatteryUsagePerMeter()

https://exercism.org/tracks/csharp/exercises/building-telemetry/

Building Telemetry in C# on Exercism

Can you solve Building Telemetry in C#? Improve your C# skills with support from our world-class team of mentors.

exercism.org

난이도

Easy

풀이 포인트

out, ref 키워드 잘 이해하고 사용하기

REVIEW

키워드가 붙었을 뿐, 파라미터라는 것은 같은데 사용이 어색해서 기록해둔다.

CODE

public class RemoteControlCar
{
    private int batteryPercentage = 100;
    private int distanceDrivenInMeters = 0;
    private string[] sponsors = new string[0];
    private int latestSerialNum = 0;

    public void Drive()
    {
        if (batteryPercentage > 0)
        {
            batteryPercentage -= 10;
            distanceDrivenInMeters += 2;
        }
    }

    public void SetSponsors(params string[] sponsors)
    {
        this.sponsors = sponsors;
    }

    public string DisplaySponsor(int sponsorNum)
    {
        return sponsors[sponsorNum];
    }

    public bool GetTelemetryData(ref int serialNum,
        out int batteryPercentage, out int distanceDrivenInMeters)
    {
        if (serialNum  < this.latestSerialNum) 
        {
            serialNum = this.latestSerialNum; 
            batteryPercentage = -1;
            distanceDrivenInMeters = -1;
            return false;
        }

        this.latestSerialNum = serialNum;
        batteryPercentage = this.batteryPercentage;
        distanceDrivenInMeters = this.distanceDrivenInMeters;
        return true;
    }

    public static RemoteControlCar Buy()
    {
        return new RemoteControlCar();
    }
}

public class TelemetryClient
{
    private RemoteControlCar car;

    public TelemetryClient(RemoteControlCar car)
    {
        this.car = car;
    }

    public string GetBatteryUsagePerMeter(int serialNum)
    {
        int battery = 0;
        int distance = 0;
        
        if(car.GetTelemetryData(ref serialNum, out battery, out distance)){
            if(distance == 0) return "no data";
            return $"usage-per-meter={(100 - battery)/distance}";
        }

       return "no data";
    }
}

[Qiita] 非エンジニアが1行もコードを書かずにAI搭載の「画像トリミングツール」を作った話

안녕도라 — Fri, 23 Jan 2026 13:43:30 +0900

AIに決めてもらうのではなく選択肢を出させて、意思決定だけ自分でするのがコツです。
「後から思いつきで機能追加」なんて、人間相手なら怒られそうな案件ですが、文句ひとつ言わずにやってくれるのがAIのいいところですね。

詰む（つむ）	結局は専門知識がないと途中で詰むんでしょ？	막혀버리다
かかる	疑ってかかったのに	덤벼들다, 달려들다, 접근하다
素人（しろうと）	完全に素人です	초보, 문외한
自己流（じこりゅう）	パッケージ管理も自己流	자기 멋대로 해버리는 느낌
丸投げ（まるなげ）	私がClaude Codeに完全丸投げして作った	어떤 일을 통째로 맡김
被写体（ひしゃたい）	被写体が真ん中に来るように自動調整されます
我慢（がまん）	使いにくいツールを我慢して使う	참고
導く（みちびく）	素人がどうやって指示を出して完成まで導いたか
ふわっと	優秀なエンジニアに、ふわっとした要望を投げて相談する
汲み取る（くみとる）	Claude Codeが意図を汲み取ってくれます。	물을 퍼올리다/파악해줍니다.
ちんぷんかんぷん	開発中に「サーバー側の構成はどうしますか？」と聞かれたのですが、正直ちんぷんかんぷんです。	횡설수설
徹底する	優秀なエンジニアに、ふわっとした要望を投げて相談するというスタイルを徹底しました。
頼る（たよる）	動作確認もデバッグも「視覚」に頼る
横着（おうちゃく）	この徹底した横着こそが、挫折せずに完成できた理由かもしれません。	철면피,뻔뻔스러움,교활
思い立つ	「これ、スマホでも使えたら最高じゃね？」と思い立ち、スマホでも使えるように、レスポンシブデザインにしてと無茶振りしてみました。	마음먹다, 결심하다,
出先（でさき）	出先でサッと画像を整えたいときに重宝しています。	밖에서 급하게 이미지 좀 손봐야 할 때 엄청 잘 쓰고 있어요.”
重宝（ちょうほう）		편리하고 도움이 되는 것, 요긴하여 자주 사용하는 것.
妄想（もうそう）	必要なのは「妄想」と「言語化」だけ	망상
阻む（はばむ）	その手前にある「環境構築」や「エラー対応」という高い壁に阻まれて、スタートラインにさえ立てませんでした。	방해하다
諦める（あきらめる）	「どうせ自分には作れない」と諦めていたアイデアがあるなら
結晶（けっしょう）	「妄想の結晶」を置いておきます。	결정

https://qiita.com/ot12/items/06015037ea758b518c6d

【Claude Code】非エンジニアが1行もコードを書かずにAI搭載の「画像トリミングツール」を作った

最近よく聞く生成AIで誰でもアプリ開発という話題。正直なところ、「そうは言っても、結局は専門知識がないと途中で詰むんでしょ？」と半信半疑でスルーしていました。ですが、年末年

qiita.com

[Qiita]Googleでの14年間で学んだ21の教訓

안녕도라 — Thu, 22 Jan 2026 13:52:24 +0900

Teaching is debugging your own mental models.
（教えることは、自分のメンタルモデルをデバッグすること）

If no one can articulate your impact when you're not in the room, your impact is effectively optional.
（あなたがいない場で誰もあなたの成果を説明できないなら、その成果は実質オプションだ）

You can edit a bad page, but you can't edit a blank one.
（悪いページは編集できるが、白紙は編集できない）

Your job isn't forever, but your network is.
（仕事は永遠ではないが、人脈は永遠だ）

The engineer who treats their career as compound interest, not lottery tickets, tends to end up much further ahead.
（キャリアを宝くじではなく複利として扱うエンジニアは、最終的にはるかに先に行く）

Stay curious, stay humble, and remember that the work is always about people.
（好奇心を持ち続け、謙虚であり続け、仕事は常に人のためにあることを忘れるな）

経験を分ける	経験を分けてくれたエンジニアたち
計る（はかる）	私自身が計り知れないほどの恩恵を受けてきたからです。	헤아릴 수 없다
咀嚼（そしゃく）	自分の言葉で咀嚼した	저작, 음미하다
執着（しゅうちゃく）	最高のエンジニアはユーザーの問題を解決することに執着する	집착
雑	完璧な設計を考え続けて何も作らないより、雑でもいいからまず作る
賢い（かしこい）	トリッキーなコードは賢く見えるかもしれない。
しばしば	「最適なツール」は、しばしば「多くの仕事で最も悪くないツール」である	종종(＝たびたび)
背負う（せおう）	最新技術はワクワクするが、導入するたびに「学習コスト」「採用難」「トラブル時の情報不足」という借金を背負う。
枯れる（かれる）	それ以外は枯れた技術で十分。
幻想（げんそう）
維持（いじ）	互換性の維持は立派なプロダクト開発。
揃う（そろう）	方向性や優先順位がチーム内で揃っていない
費やす（ついやす）	優先順位を明確にすることに多くの時間を費やす
後回し	抽象化は複雑さを「後回し」にしているだけ	뒤로 미룸, 뒷전
漏れる（もれる）	でも何かは必ず漏れる
いざ	いざという時のために、下のレイヤーも理解しておこう。	자! 막상 일을 시작하려고 분발할때 하는 말
賭ける（かける）	便利なライブラリやフレームワークは「中身を知らなくていい」という賭け。	내기, 도박
かぶり	シニアが知ったかぶりをすると、若手は質問できなくなる。	아는 척 하다
怠る（おこたる）	仕事に集中してネットワーキングを怠ると、後で困る。
築く（きずく）	関係を築いた人は、何年後かに機会を運んでくれる。
打算（ださん）	打算ではなく、好奇心と誠実さで人と繋がろう。
謙虚（けんきょ）		겸허

https://qiita.com/Sakai_path/items/8ae1e34e012a53aa8d1b

「Googleでの14年間で学んだ21の教訓」を個人的な解釈でまとめてみた - Qiita

はじめに Googleで長年 Chrome に携わり、現在は Google Cloud AI でディレクターを務める Addy Osmani（アディ・オスマニ）氏が、14年間の経験から学んだ教訓をまとめた『21 Lessons From 14 Years at Goo...

qiita.com

[Kata] Crack the PIN

안녕도라 — Tue, 6 Jan 2026 13:47:02 +0900

문제요약

주어진 MD5 해시값과 일치하는 값을 생성하는 5자리 PIN을 출력하라!

입력: MD5 해시값
출력: 5자리 PIN

* 해시 : 사과(입력) → 믹서기에 갈기(해시 함수) → 사과주스(해시 값)

* MD5 : 해시 함수의 한 종류

* PIN : 보통 4~6자리의 짧은 숫자 비밀번호

https://www.codewars.com/kata/5efae11e2d12df00331f91a6/train/csharp

Codewars - Achieve mastery through coding practice and developer mentorship

A coding practice website for all programming levels – Join a community of over 3 million developers and improve your coding skills in over 55 programming languages!

www.codewars.com

난이도

6 kyu

풀이 포인트

브루트포스

00000 ~ 99999까지의 경우의 수와 모두 비교

REVIEW

해시 값과 해시 함수의 개념이 헷갈렸다.

CODE

using System.Security.Cryptography;
using System.Text;
using System;

public class CodeWars {
  public static string crack(string hash) {
    
    using(MD5 md5 = MD5.Create()){
      for(int i = 0; i <= 99999; i++){
        string pin = i.ToString("D5");
        byte[] inputBytes = Encoding.ASCII.GetBytes(pin);
        byte[] hashBytes = md5.ComputeHash(inputBytes);
        
        string md5Hash = BitConverter.ToString(hashBytes).Replace("-","").ToLower();
        
        if(md5Hash == hash) return pin;
      }
    }
    
    
    return "";
  }
}

클린아키텍처 15장 아키텍처란?

안녕도라 — Wed, 10 Dec 2025 13:40:17 +0900

소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다. 그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어진다.

이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.

아키텍처가 시스템 운영에 미치는 영향은 개발, 배포, 유지보수에 미치는 영향보다는 덜 극적이다. 운영에서 겪는 대다수의 어려움은 소프트웨어 아키텍처에는 극적인 영향을 주지 않고도 안순히 하드웨어를 더 투입해서 해결할 수 있따. 실제로 우리는 이러한 일이 벌어지는 경우를 계속해서 목격해왔다. 소프트웨어 시스템의 아키텍처가 비효율적이라면 단순히 스토리지와 서버를 추가하는 것만으로 제대로 동작하도록 만들 수 있을 때가 많다. 하드웨어은 값싸고 인력은 비싸다는 말이 뜻하는 바는 운영을 방해하는 아키텍처가 개발, 배포,유지보수를 방해하는 아키텍처보다는 비용이 덜 든다는 뜻이다.

그러허더라도 시스템을 운영할 때 아키텍처가 맡는 또 다른 역할이 있따. 좋은 소프트웨어 아키텍처는 시스템을 운영하는 데 필요한 요구도 알려준다.

선택사항 열어 두기

소프트웨어는 두 종류의 가치, 즉 행위적 가치와 구조적 가치를 지닌다. 이 중에서 두 번쨰 가치가 더 중요한데, 소프트웨어를 soft하게 만드는 것은 바로 이 구조적 가치이기 떄문이다.

소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어 두는 것이다. 그렇다면 열어 둬야 할 선택사항이란 무엇일까? 그것은 바로 중요치 않은 세부사항(detail)이다.

모든 소프트웨어 시스템의 두 가지 구성요소

정책(policy): 모든 업무 규칙과 업무 절차를 구체화
세부사항(detail): 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소. (입출력장치, 데이터베이스, 웹 시스템, 서버, 프레임 워크, 통신 프로토콜 등)

아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 데 있다. 이를 통해 세부사항을 결정하는 일은 미루거나 연기할 수 있게 된다.

예) 정말 신중한 아키텍트라면, 고수준의 정책을 데이터베이스가 관계형인지, 분산형인지, 계층형인지, 아니면 평범한 플랫 파일인지와는 관련이 없도록 만들어야 한다.

세부사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기할 수 있다.

장치 독립성

의뢰인
- 고객의 이름과 주소를 포함하는 단위 레코드가 기록된 자기 테이프
- 이름과 주소가 빠져있는 문구
광고회사
- 이름과 주소를 편지 양식의 정확한 위치에 인쇄하도록 프로그램 작성
- 라인프린터 대신 자기 테이프를 사용하도록 운영체제에게 지시
- 그리고는 오프라인 프린터 다섯대의 테이프 드라이브에 끼워넣었다.

라인프린터 대신 자기 테이프를 사용하도록 운영체제에게 지시하더라도 프로그램 자체는 전혀 문제가 되지 않았는데, 운영체제의 입출력 추상화를 사용해서 작성되었기 때문이었다.

장치 독립성이 지닌 가치는 굉장했다. 어떤 장치를 사용할지 전혀 모른채, 그리고 고려하지 않고도 프로그램을 작성할 수 있었다.

물리적 주소 할당

디스크

실린더
헤드: 여러 개의 플래터를 읽는 바늘
섹터: 작은 저장단위

기존 방식	노련한 프로그래머
(실린더 번호, 헤드 번호, 섹터 번호) 3차원 좌표로 지정 후 이 번호를 하드코딩	디스크를 0~N까지 이어진 긴 배열로 보고 상대 주소를 할당하자!
새 디스크를 사용할 경우, 모든 데이터 주소를 변환하는 주소를 짜야 한다.	1230번째 섹터를 주세요! 하면 변환하여 실린더 22번, 헤드 2번 섹터 19번 이런식으로 변환
	상위 로직은 디스크의 구조를 전혀 모르며, 물리 구조가 바뀌어도 변환 루틴만 수정하면 된다.

클린 아키텍처 7~8강

안녕도라 — Thu, 4 Dec 2025 15:13:52 +0900

SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는 데 있다.

변경에 유연하다.
이해하기 쉽다
많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다.

SRP(Single Responsibility Principle) : 단일 책임 원칙
OPC(Open-Closed Principle) : 개방폐쇄원칙
LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
DIP(Dependency Inversion Principle) : 의존성 역전의 원칙

SRP(Single Responsibility Principle) : 단일 책임 원칙

하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.

[A] calculatePay() : 회계팀에서 기능 정의
[B] reportHours() : 인사팀에서 기능 정의
[C] save() : 데이터베이스 관리자가 기능 정의

위반 징후 1: 우발적 중복

A와 B가 같은 regularHours라는 함수를 호출한다고 할 때, 그 함수를 B에 맞게 고쳐버리면 A에도 영향이 간다.

서로 다른 액터가 의존하는 코드를 서로 분리하라!

위반 징후 2: 병합

많은 사람이 서로 다른 목적으로 동일한 소스 파일을 변경하는 경우,

충돌이 일어나고 이로인한 병합은 안전하지 않음

OPC(Open-Closed Principle) : 개방폐쇄원칙

소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀있어야 한다.

클린 아키텍쳐 4~6장

안녕도라 — Wed, 3 Dec 2025 14:00:59 +0900

4장. 구조적 프로그래밍

발췌

이러한 제어 구조는 뵘과 야코피니가 데이크스트라보다 2년 앞서 발견했는데, 이 두 명은 모든 프로그램을 순차(sequence), 분기(selection), 반복(iteration)이라는 세 가지 구조만으로 표현할 수 있다는 사실을 증명했다. 이 발견은 실로 놀라웠다. 즉 , 모듈을 증명 가능하게 하는 바로 그 제어 구조가 모든 프로그램을 만들 수 있는 제어 구조의 최소 집합과 동일하다는 사실이었다.

데이크 스트라는 편집자에게 편지를 썼고, 편지의 제목은 "goto문의 해로움(Go To Statement Considered Harmful)"이었다.

구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게 되었고, 이는 결국 모듈을 기능적으로 분해할 수 있음을 뜻했다. 즉, 거대한 문제 기술서를 받더라도 문제를 고수준의 기능들로 분해할 수 있었다. 그리고 이들 각 기능은 다시 저수준의 함수들로 분해할 수 있고, 이러한 분해 과정을 끝없이 반복할 수 있다.

과학은 근본적으로 수학과는 다른데, 과학 이론과 법칙은 그 올바름을 절대 증명할 수 없기 때문이다. 과학은 서술된 내용이 사실임을 증명하는 방식이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다. 각고의 노력으로도 반례를 들 수 없는 서술이 있다면 목표에 부합할 만큼은 참이라고 본다.

소프트웨어 개발이 수학적인 구조를 다루는 듯 보이더라도, 소프트웨어 개발은 수학적인 시도가 아니라는 사실이다. 오히려 소프트웨어는 과학과 같다.최선을 다하더라도 올바르지 않음을 증명하는 데 실패함으로써 올바름을 보여주기 때문이다.

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다. 그러고 나서 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다. 이처럼 거짓임을 증명하려는 테스트가 실패한다면, 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 된다.

구조적 프로그래밍이 오늘날까지 가치 있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어낼 수 있는 바로 이 능력 때문이다. 또한 흔히 현대적 언어가 아무런 제약없는 goto문장은 지원하지 않는 이유이기도 하다. 뿐만 아니라 아키텍처 관점에서는 기능적 분해를 최고의 실천법 중 하나로 여기는 이유이기도 하다.

paraphrasing

모듈화하여 작은 단위로 나누고(기능을 구조적으로 나눌 수 있게 구성하고), 흐름을 예측할 수 없는 goto문을 지양해라!
쉽게 테스트하고, 쉽게 반증할 수 있도록

5장. 객체 지향 프로그래밍

발췌

좋은 아키텍처를 만드는 일은 객체 지향 설계 원칙을 이해하고 응용하는 데서 출발한다. 그렇다면 대체 객체 지향이란 무엇인가?

이 질문에 흔히 "실제 세계를 모델링하는 새로운 방법"이라고들 답한다. 이는 기껏해야 얼버무리는 수준에 지나지 않는다. 도대체 "실제 세계를 모델링한다"라는 말이 무엇을 의미하며, 왜 우리는 그 방향을추구해야 하는가? 이 답변이 전달하려는 의도는 객체 지향은 현실 세계와 의미적으로 가깝기 때문에 객체를 사용하면 소프트웨어를 좀 더 쉽게 이해할 수 있다는 데 있는 듯 하다. 하지만 이 의도조차 불분명하며, 그 정의가 너무 모호하다. 다시 말해 이 답변도 객체 지향이 무엇인지를 설명해주지 않는다.

캡슐화(Encapsulation)

헤더: 데이터 구조와 함수 선언
구현체: 이들을 구현

C	C++	C#, Java

완벽한 캡슐화 데이터 구조와 함수를 헤더 파일에 선언하고, 구현 파일에서 이들을 구현했다. 그리고 구현파일에 작성된 항목에 대해서는 어떠한 방법으로도 접근할 수 없었다.	c++의 컴파일러는 클래스의 인스턴스 크기를 알 수 있어야 해서, 헤더 파일을 사용하는 측에서 멤버 변수 x,y를 알게 된다.	헤더 파일이 사라짐. 헤더와 구현체를 분리하는 방식을 버렸다.

객체 지향 프로그래밍은 프로그래머가 충분히 올바르게 행동함으로써 캡슐화된 데이터를 우회해서 사용하지 않을 거라는 믿음을 기반으로 한다. 하지만 객체 지향을 제공한다고 주창한 언어들이 실제로는 C언어에서 누렸던 완벽한 캡슐화를 약화 시켜 온 것은 틀림없다.

상속(Inheritance)

NamedPoint ⊃ Point : NamedPoint데이터 구조가 마치 Point 데이터 구조로부터 파생된 구조인 것처럼 동작한다. 눈속임처럼 보이는 이 방식은 객체 지향이 출현하기 이전부터 프로그래머가 흔히 사용하던 기법이었다.
NamedPoint인자를 Point로 타입을 강제로 변환한 점도 확인할 수 있다. 진짜 객체 지향 언어에서는 이러한 업캐스팅이 암묵적으로 이뤄진다.

다형성(Polymorphism)

getchar()함수는 STDIN에서 문자를 읽는다. 그러면 STDIN은 어떤 장치인가? putchar()함수는 STDOUT으로 문자를 쓴다. 그런데 STDOUT은 또 어떤 장치인가? 이러한 함수는 다형적이다. 즉 행위가 STDIN과 STDOUT의 타입에 의존한다.

getchar()입력	키보드	키보드의 입력값을 읽음
getchar()입력	파일	파일의 내용을 읽음
putchar()출력	터미널	화면에 글자 출력
putchar()출력	파일	파일으로 글자 출력

즉 코드 자체가 바뀌지 않는데 동작이 바뀌는 것 = 다형성

즉 함수를 가리키는 포인터만 바꾸면 동작이 달라진다 = 다형성

새로운 입출력 장치가 생긴다면 프로그램에는 어떤 변화가 생기는가? 아무런 병경도 필요치 않다. 심지어 복사 프로그램을 다시 컴파일할 필요조차 없다. 왜냐고? 복사 프로그램의 소스 코드는 입출력 드라이버의 소스 코드에 의존하지 않기 때문이다.

의존성 독립(Dependency inversion)

제어 흐름: 프로그램이 실행될 때 메서드가 호출되는 순서
소스 코드 의존성: 코드가 다른 모듈의 정의를 참조

제어흐름은 세스템의 행위에 따라 셜정되며, 소스 코드 의존성은 제어흐름에 따라 결정된다.

하지만 다형성이 끼어들면 특별한 일이 일어난다.

객체 지향 언어로 개발된 시스템을 다루는 호프트웨어 아키텍트는 시스템의 소스 코드 의존성 전부에 대해 방향을 결정할 수 있는 절대적인 권한을 갖는다. 즉 소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한되지 않는다.

이렇게 하면 , 업무 규칙이 데이터베이스와 UI에 의존하는 대신에 시스템의 소스 모드 의존성을 반대로 배치하여 데이터 베이스와 UI가 업무 규칙에 의존하게 만들 수 있다.

소프트웨어 아키텍트 관점에서 객체 지향이란 다형성을 이용하여 전체 시스템의 모든 소스 코드 의존성에 대한 절대적인 제어 권한을 획득할 수 있는 능력이다.

6장. 함수형 프로그래밍

Java	Closure
가변 변수 사용 : 프로그램 중에 상태가 변할 수 있다. 예 ) 반복문에서의 i같은 것	가변 변수 X x와 같은 변수가 한 번 초기화되면 절대로 변하지 않는다.

함수형 언어에서 변수는 변경되지 않는다.

아키텍처를 고려할 때, 왜 변수의 가변성을 염려하는가? 경합조건, 교착상태(deadlock)조건, 동시 업데이트 문제가 모두 가변 변수로 인해 발생하기 때문이다. 하지만 자원이 무한대가 아니라 불변성은 실현 가능하겠지만 일종의 타협을 해야 한다.

가변 컴포넌트와 불변 컴포넌트로 분리하는 일이다. 불변 컴포넌트에서는 순수하게 함수형 방식으로만 작업이 처리되며, 어떤 가변 변수도 사용되지 않는다.

이제 프로세서가 초당 수십억 개의 명령을 수행하고 RAM용량은 수십억 바이트인 시대가 되었다. 더 많은 메모리를 확보할수록, 기계가 더 빨라질수록, 필요한 가변 상태는 더 적어진다.

저장 공간과 처리 능력이 충분하면 애플리케이션이 완전한 불변성을 갖도록 만들 수 있고 따라서 완전한 함수형으로 만들 수 있다.

1946년 앨런 튜링이 전자식 컴퓨터에서 실행할 거의 최초의 코드를 작성할 때 사용한 소프트웨어 규칙과 지금의 소프트웨어 규칙은 조금도 다르지 않다. 도구는 달라졌고 하드웨어도 변했지만, 소프트웨어의 핵심은 여전히 그대로다. 소프트웨어, 즉 컴퓨터 프로그램은 순차(sequence), 분기(selection), 반복(iteration), 참조(indirection)로 구성된다.

클린 아키텍쳐 1~3장

안녕도라 — Tue, 2 Dec 2025 20:07:00 +0900

1장 설계와 아키텍처란?

제이슨 고먼의 실험

정수를 로마 숫자로 변환하는 프로그램

사전에 정의한 일련의 인수테스트를 프로그램이 통과하면 개발이 완료된 것으로 봤다.

1일차,3일차, 5일차에 TDD(테스트 주도개발)을 적용하고,

2일차,4일차, 6일차에는 TDD없이 개발했다.

TDD를 적용한 날이

적용하지 않은 날보다 대략 10% 빠르게 작업이 완성되었다.

빨리 가는 유일한 방법은 제대로 가는 것이다.

2장 두 가지 가치에 대한 이야기

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 부드러워야(soft) 한다. 다시 말해 변경하기 쉬워야 한다. 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위에 비례해야 하며 변경사항의 형태(shape)와는 관련이 없어야 한다.

기능인가 아니면 아키텍처인가? 둘 중 어느 것의 가치가 더 높은가? 소프트웨어 시스템이 동작하도록 만드는 것이 중요한가? 아니면 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요한가?

동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있다. 따라서 이러한 프로그램은 앞으로도 계속 유용한 채로 남는다.

수정이 현실적으로 불가능한 시스템은 존재하기 마련인데, 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우다.

긴급 O, 중요 O	긴급 X, 중요 O
긴급 O, 중요 X	긴급 X, 중요 X

소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.

소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.

따라서 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다.

아키텍트는 이러한 특성과 기능을 개발하기 쉽고 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다. 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.

3장 패러다임 개요

패러다임이란 프로그래밍을 하는 방법으로, 대체로 언어에는 독립적이다. 패러다임은 어떤 프로그래밍 구조를 사용할지, 그리고 언제 이 구조를 사용해야 하는지를 결정한다. 현재까지 이러한 패러다임에는 세가지 종류가 있다.

구조적 프로그래밍(Structured Programming)
객체 지향 프로그래밍(Object-Oriented Programming)
함수형 프로그래밍(Fuctional Programming)

게임 콘텐츠의 제작 원리 2-7. 뷰공간

안녕도라 — Thu, 27 Nov 2025 16:23:54 +0900

1. 카메라

월드 공간 = 물체를 배치하기 위한 공간
뷰 공간 = 월드 공간의 일부를 화면에 보여주기 위해 월드 공간을 재배치한 공간

2. 뷰 공간

카메라를 원점으로 월드 공간을 재배치한 공간을 의미

다음과 같이 카메라가(-10,-10)에 있을 때 카메라를 원점으로 하는 물체의 위치는 (20,20)이 된다.

3. 뷰 행렬의 계산

메시 데이터의 한 점이 화면에 나타나기 까지는 다음의 변환 과정을 거친다.

다음과 같은 로직으로 씬에 속한 최종 게임 오브젝트를 렌더링 한다.

카메라로부터 뷰 행렬(V)를 구해 계산한다
씬에 속한 모든 게임 오브젝트를 순차적으로 순회한다
- 게임 오브젝트의 모델링 행렬(M)을 계산한다
- 뷰 행렬과 모델링 행렬을 곱한 결과를 최종 행렬로 저장한다
- 최종 행렬과 메시의 정점을 모두 곱한다.
- 변환된 정점으로부터 삼각형을 생성하고 이들을 각각 칠한다.

게임 콘텐츠의 제작 원리 2-6. 게임 엔진

안녕도라 — Thu, 27 Nov 2025 15:21:03 +0900

1. Local Space & World Space

Local Space

원점(0,0,1)을 중심으로 각 점의 상대적인 위치를 지정한다.

World Space

하지만 게임은 하나의 물체가 아닌 하나의 공간에 여러 물체를 배치하고, 주인공이 움직이면서 공간을 탐험해야 한다. 이를 위해서 각 물체를 구분할 수 있는 개별 공간이 필요하다.

게임 공간

world space 바탕으로 local space가 선형 변환되어 이동, 회전, 크기에 대한 값을 가지고 배치되어 있다.

하나의 물체가 로컬 공간을 가진다면, 그게 월드 공간 위에 펼쳐진다 느낌?

월드 공간에 배치된 로컬 공간은 모든 물체의 고유한 위치를 식별해주는 고유한 값(크기, 회전, 위치의 세가지가 사용

)되며, 이는 앞서 언급한 세 가지의 아핀 변환을 의미한다.

트랜스폼 행렬

세 가지 아핀 변환을 크기(S), 회전(R), 이동(T)라고 했을 때, 변환을 순서대로 적용한 결과는 다음의 경우의 수

S · R · T
S · T · R
T · S · R
T · R · S
R · T · S
R · S · T

이동변환 (T)를 중간에 적용하게 된다면 최종 결과로 나타난 위치는 사용자 입장에서 식별하기 어려워진다. 따라서 이동 변환은 가장 마지막에 적용하는 것이 편리하다.

그래서 우리가 고려해야 할 변환은 아래 두 가지로 나뉘게 된다.

* 행렬은 오른쪽에서부터 왼쪽으로 진행

T · S · R
T · R · S

따라서 다음과 같은 형태로 변환 순서가 결정되며 이를 모델링 행렬이라고 한다

M = TRS (크기 → 회전 → 이동)

트랜스폼의 관리

트랜스폼 변환에 관련있는 세 가지 데이터

크기(Vector2)
회전(각)
이동(Vector2)

실제 작업자가 공간에 물체를 배치할 때에는 위의 데이터를 지정하는 방식으로 사용하고, 게임 엔진들도 트랜스폼을 지정하도록 UI를 제공한다.

2. 게임 렌더링의 진행 과정

게임이 원활하게 동작하기 위해서는 게임의 월드 공간에 배치된 다수의 물체를 효율적이고 체계적으로 관리할 체계가 필요하다.

Scene : 개발 단계에서 스테이지를 관리하기 위한 객체
Transform: Scene에 속한 각 물체는 월드 공간 기준으로 어디에 배치되어 있는지
Game Object : 트랜스폼을 물체 단위로 관리

매 프레임마다 씬에 속한 게임 오브젝트의 최종 트랜스폼 정보가 확정되어야 로컬 공간에 있는 메시 정보로부터 점을 변환해 최종 삼각형이 그려진다.

따라서 게임의 진행은 게임 오브젝트의 최종 트랜스폼을 확정하는 단계와 최종 트랜스폼으로부터 행렬을 생성한 후, 메시의 정점을 곱해 변환하는 작업의 두 단계로 나누어진다.

게임 로직: 게임 오브젝트의 트랜스폼을 확정하는 작업. 실제 렌더링 관련 작업은 발생하지 않음
렌더링 로직: 로컬 공간을 기준으로 저장된 메시의 정점 정보를 월드 공간 기준으로 재배치하고 각 삼각형을 그리는 작업. 메시의 삼각형 위치를 확정하고 렌더링 관련된 작업을 진행함

3. 게임 리소스의 관리

게임에는 씬 뿐만 아니라 게임에 사용되는 데이터를 관리하기 위한 체계적이고 효율적인 관리시스템이 필요하다.

게임에 사용되는 데이터를 게임 리소스(Resource)혹은 게임 에셋(Asset)라고 한다.

게임 리소스는 씬과 별개로 구성되어야 하는데, 게임 오브젝트마다 동일한 메시 정보는 중복해서 사용되는 일이 많기 때문이다. 예를 들어 100개의 동일한 몬스터가 스테이지의 곳곳에 배치된다면 몬스터에 대한 메시 정보를 100개로 복제해 관리하기 보다 하나의 몬스터 메시를 100개의 게임 오브젝트가 공유해서 사용하는 편이 보다 효율적이기 떄문이다.

따라서 게임 리소스마다 고유의 키를 부여하고, 게임 오브젝트는 부여된 키를 가지고 접근하는 형태로 관리되는 것이 일반적이다. 이러한 게임 에셋의 정보를 저장한 저장소를 리소스 리파지토리라고 한다.