> For the complete documentation index, see [llms.txt](https://riu-salze-studio.gitbook.io/cosmic-horizon/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://riu-salze-studio.gitbook.io/cosmic-horizon/kr/perspective/why-we-study.md).

# Why We Study

AI가 실행을 가속하는 시대에 왜 공부해야 하는지, 책임에 맞는 배움과 달라져야 할 역량의 증명 방식을 묻는 관측 로그.

> 관측 로그

## 현재 좌표계

* 우리는 AI보다 빨라지기 위해 공부하지 않는다.
* 공부는 기계가 만든 결과를 읽고, 방향을 정하고, 책임의 경계를 그릴 수 있는 판단 체계를 만드는 일이다.
* 시험·자격증·코딩 테스트는 과거의 증명 방식이다. 이제는 그것들이 무엇을 증명하지 못하는지부터 물어야 한다.
* AI를 활용하는 역량을 평가하려면, AI를 활용하는 실제 작업을 관측해야 한다.

## 올라탔다. 그런데 왜 공부하는가?

[Ride, Don’t Race](/cosmic-horizon/kr/perspective/ride-dont-race.md)에서 우리는 말과 경주하는 대신 말에 올라타기로 했다.

그렇다면 다음 질문이 남는다.

말이 대신 달려 주는데, 왜 나는 여전히 배워야 하는가?

AI가 코드를 작성한다. 설명하고, 비교하고, 오류를 찾아낸다. 낯선 프레임워크로 구현해 달라고 해도 금세 결과물을 내놓는다.

이쯤 되면 공부는 비용처럼 보인다.

굳이 내가 이해해야 하는가?

모르는 것을 AI에게 물으면 되지 않는가?

필요할 때마다 다시 지시하면 되지 않는가?

이 질문을 외면한 채 “그래도 공부는 중요하다”고 말하는 것은 충분한 답이 아니다.

나는 공부의 필요성을 지키기 위해 AI의 능력을 깎아내리고 싶지 않다.

오히려 AI가 더 많은 일을 맡을수록, 인간이 무엇을 공부해야 하는지 더 정확히 물어야 한다.

## 공부는 답을 저장하는 일이 아니다

공부를 머릿속에 정답을 쌓아 올리는 일로만 이해한다면, AI는 그 목적을 이미 흔들어 놓았다.

찾는 속도, 기억하는 양, 익숙한 문제를 풀어내는 속도. 그 경주로 돌아갈 이유가 없다.

그렇다고 아무것도 몰라도 된다는 뜻은 아니다.

AI의 답을 받았을 때, 나는 그것을 어디에 놓아야 하는가?

이 답이 성립하려면 어떤 전제가 필요한가?

무엇을 확인했고, 무엇을 확인하지 않았는가?

문제가 발생하면 어디서부터 거슬러 올라가야 하는가?

공부는 이 질문들을 가능하게 만드는 일이다.

나는 AI가 만든 문장을 그대로 외우기 위해 공부하지 않는다. 그 문장을 읽고, 맥락을 붙이고, 잘못된 곳을 짚어 낼 수 있는 내부의 좌표계를 만들기 위해 공부한다.

AI는 학습의 상대가 아니라 학습의 매체가 될 수 있다.

모르는 개념을 다른 각도에서 설명해 달라고 하고, 예시를 바꾸고, 반례를 시험하고, 내가 이해한 내용을 다시 검산할 수 있다.

하지만 설명을 전달받는 일과 이해를 획득하는 일은 같은 사건이 아니다.

공부는 AI가 답을 끝냈을 때가 아니라, 내가 그 답에 대해 다시 질문할 수 있을 때 진전된다.

## 개발은 번역의 일이다

개발을 단순히 코드를 생성하고 기능을 구현하는 일로만 보면, AI가 그 역할의 상당 부분을 가져간 것처럼 보일 수 있다.

하지만 실제 개발은 그보다 앞에서 시작된다.

사용자의 기대, 불편, 모호한 요청, 아직 이름 붙지 않은 필요를 읽어 내야 한다. 그리고 그것을 기계가 실행할 수 있는 구조와 제약으로 번역해야 한다.

반대로 시스템의 제약, 비용, 위험, 동작 방식을 다시 사람이 이해할 수 있는 언어로 되돌려 설명해야 한다.

그래서 개발자는 단순한 기능 구현자가 아니라, 사람의 언어와 기계의 언어 사이에서 서로의 눈높이를 맞추는 번역자에 가깝다.

공부는 이 번역을 더 정확하게 만들기 위해 필요하다. 무엇이 본래의 요구였는지, 무엇이 구현의 제약인지, 어디서 의미가 왜곡되었는지 읽어내지 못하면 AI를 써도 방향을 잃는다.

## 기술이 매체가 될 때

예를 들어, JPA가 필요한 프로젝트를 생각해 보자.

나는 데이터베이스 스키마와 비즈니스 요구사항을 알고 있다. 하지만 JPA를 깊이 다뤄 본 적은 없다.

이제 AI에게 지시할 수 있다.

“이 구조를 JPA로 구현해 줘.”

결과물이 나온다. 기능도 동작한다.

그렇다면 나는 왜 JPA를 공부해야 하는가?

여기서 기술의 위치가 달라진다.

과거에는 프레임워크의 문법을 직접 구사할 수 있어야 구현에 도달했다. 이제는 인간이 요구사항과 제약을 선언하고, AI가 그 기술의 방언으로 번역하는 경로가 열린다.

JPA는 내가 모든 문장을 손으로 써야만 하는 언어에서, 더 깊은 구조를 표현하는 매체로 이동한다.

공부의 대상도 함께 이동한다.

어노테이션을 몇 개 외웠는가보다, 연관관계와 트랜잭션 경계를 왜 그렇게 정했는가.

N+1 문제가 어느 경로에서 발생하는가.

데이터가 커졌을 때 이 설계는 무엇을 희생하는가.

이 질문에 답하려면 JPA 바깥까지 읽어야 한다. 데이터 접근, 상태 변화, 비용, 실패의 경계를 알아야 한다.

MyBatis로 구현해도, Prisma로 구현해도, raw SQL로 내려가도 질문의 뼈대는 남는다.

**기술은 바뀐다. 구조적 판단은 남는다.**

JPA를 공부한다는 것은 JPA를 AI보다 빨리 작성하는 사람이 되는 일이 아니다. JPA라는 방언으로 번역된 결과를 이해하고, 필요할 때 그 번역을 바로잡을 수 있는 사람이 되는 일이다.

## 판단도 AI에게 위임하면 되지 않는가?

여기서 질문은 한 번 더 깊어진다.

구현뿐 아니라 검토도 AI에게 맡기면 되지 않는가?

N+1을 찾아 달라고 하고, 트랜잭션을 점검해 달라고 하고, 다른 설계를 제안해 달라고 하면 된다.

실제로 그렇게 해야 할 때가 많다. 사람이 모든 코드를 혼자 작성하고, 혼자 검증해야 한다는 생각으로 돌아가려는 것은 아니다.

문제는 AI에게 얼마나 많이 맡겼는가가 아니다.

**내가 무엇을 맡겼는지, 무엇을 검증했는지, 어디까지 책임질 수 있는지 알고 있는가.**

작은 프로토타입이라면 실패한 코드를 버리고 다시 만들면 된다. 낯선 기술을 빠르게 시험해 보는 데 AI를 사용하는 것은 합리적인 전략이다.

그러나 운영 중인 시스템은 다르다.

접근 권한이 잘못 열렸을 때, 데이터가 잘못 기록되었을 때, 장애가 다른 시스템으로 번졌을 때, “AI가 그렇게 만들었다”는 말은 복구 계획이 되지 못한다.

누군가는 원인을 추적해야 한다.

누군가는 잘못된 전제를 찾아내야 한다.

누군가는 지금 멈춰야 할지, 되돌려야 할지, 계속 진행할지 결정해야 한다.

이 모든 일을 혼자 해야 한다는 뜻은 아니다. 전문가에게 넘길 수도 있고, 다른 AI에게 다시 감사(audit)를 요청할 수도 있다.

그러나 그 판단과 위임의 경계를 선언하는 일은 남는다.

공부는 그 경계를 읽기 위한 준비다.

## 공부의 깊이는 책임의 크기에 맞춰진다

그러므로 모든 기술을 끝없이 파고들 필요는 없다.

공부의 깊이는 자신이 짊어질 실패 비용에 맞춰 보정(Calibration)해야 한다.

버려도 되는 MVP와 개인정보를 다루는 운영 시스템을 같은 기준으로 다룰 수는 없다.

작은 실험에서는 모르는 기술을 AI에게 과감하게 맡기고, 결과를 보며 학습할 수 있다.

반면 장애의 폭발 반경이 큰 시스템에서는 “동작한다”는 사실만으로 검증을 끝낼 수 없다.

나는 어디까지 이해하고 있는가?

어디까지 안전하게 위임할 수 있는가?

어느 순간부터 다른 전문가의 판단이 필요한가?

실패했을 때 무엇을 복구할 수 있고, 무엇은 되돌릴 수 없는가?

**공부의 깊이는 실패 비용에 비례해야 한다.**

공부는 모든 것을 직접 할 수 있다는 선언이 아니다.

어디까지 남에게 맡겨도 되는지 아는 사람이 되기 위한 과정이다.

## 공부의 비용과 증명의 비용

여기서 현실의 문제가 하나 더 나온다.

공부의 깊이가 책임의 크기에 따라 달라진다면, 그 공부에 필요한 시간과 비용은 누가 부담하는가?

나는 실제 시스템을 책임지기 위해 공부한다.

그런데 채용의 문 앞에서는 내가 그 책임을 감당할 수 있음을, 누군가 읽을 수 있는 형태로 다시 증명해야 한다.

공부에 드는 비용과 증명에 드는 비용이 따로 생긴다.

익숙한 평가 기준에 맞추기 위해 다시 암기하고, 다시 문제를 풀고, 다시 제한 시간에 익숙해지는 일.

실제로 일하는 방식이 바뀌었는데, 그 일을 증명하는 방식은 따라오지 못한 데서 발생하는 비용이다.

나는 이 간극을 개인의 노력 부족이라는 말로 덮고 싶지 않다.

먼저 질문해야 할 쪽은, 사람을 평가하는 방식이다.

## 속도로 증명하던 시대는 끝났다

그런데 이상한 일이 남는다.

우리는 말에 올라탔다. 일하는 방식도 바뀌었다. 하지만 사람을 평가하는 질문은 여전히 말에서 내려와 달려 보라고 요구한다.

시험.

자격증.

코딩 테스트.

이것들은 AI가 일상적인 작업의 실행 계층에 들어오기 전부터 사용해 온 증명 방식이다.

정해진 범위를 기억하는가. 제한된 시간 안에 답을 찾아내는가. 익숙한 문제를 혼자 풀어내는가.

그 질문으로 측정할 수 있는 것이 전혀 없다는 뜻은 아니다.

다만 **그 답을 잘한다고 해서 AI보다 빠르게 일할 수 있다는 뜻은 아니다. AI를 올바른 방향으로 이끌 수 있다는 뜻도 아니다.**

자격증은 특정 기준선을 통과했다는 기록이다.

시험은 정해진 조건에서 지식과 문제 해결의 일부를 보여 준다.

코딩 테스트는 제한된 문제 안에서 사고를 전개하는 모습을 드러낼 수 있다.

이제 나는 이 신호들을 역량의 최종 증명으로 읽지 않는다.

AI에게 지시할 때 필요한 기본 어휘와 개념을 갖추었을지 모른다는, 작은 보정값으로 읽는다.

기본기가 전혀 없으면 잘못된 지시를 알아채기도 어렵다. 그러나 기본기를 시험으로 증명했다고 해서 실제 작업에서 방향을 잡고, 결과를 검산하고, 끝까지 책임질 수 있는 것은 아니다.

그 차이는 더 이상 부수적인 문제가 아니다.

**이것만으로 채용을 결정짓는 시대는 갔다.**

제도가 아직 남아 있다는 사실은, 그 제도가 지금의 일을 충분히 설명한다는 증거가 아니다.

새로운 방식으로 일하는 사람에게 오래된 방식으로만 자신의 가치를 증명하라고 요구한다면, 우리는 정작 관측해야 할 역량을 놓친다.

## 이제 무엇을 평가해야 하는가

AI를 활용하는 개발자를 알고 싶다면, AI를 활용하는 작업을 보아야 한다.

모호한 요구사항을 받았을 때, 무엇을 만들지 정하기 전에 사용자의 실제 필요를 어디까지 확인하는가?

사용자의 언어를 기계가 실행할 수 있는 구조와 제약으로 얼마나 정확히 번역하는가?

시스템의 한계와 위험을 다시 사람이 이해할 수 있는 말로 설명할 수 있는가?

AI에게 어떤 맥락과 제약을 전달하는가?

생성된 결과물에서 무엇을 의심하고, 무엇을 직접 검증하는가?

오류가 발생했을 때 지시를 어떻게 수정하는가?

그 판단과 변경의 이유를 다음 사람이 따라갈 수 있도록 남기는가?

그리고 마지막에, 자신이 만든 시스템을 설명하고 책임질 수 있는가?

정답을 내는 데 걸린 시간만 재는 대신, 문제를 정의한 순간부터 결과를 검증하고 인계하는 순간까지 관측할 수 있어야 한다.

셰프의 실력을 보면서 주방을 치우고 칼질 속도만 재지는 않는다. 재료와 불, 도구와 사람을 어떻게 다뤄 한 접시를 완성하는지 본다. 그렇다면 개발자에게는 왜 도구를 활용해 자신의 역량을 넓히는 과정마저 평가에서 제외하라고 하는가?

AI 사용을 금지한 채 AI 활용 개발자를 선발할 수는 없다.

도구를 허용하고, 실제로 다룰 만한 문제를 주고, 작업의 흔적을 보자.

완성된 코드만이 아니라 지시, 선택, 수정, 테스트, 실패, 복구의 경로를 함께 보자.

이력서에 적힌 기술 이름이 아니라, 그 기술을 써서 어떤 책임을 감당했는지 물어보자.

이것이 내가 생각하는 새로운 평가의 출발점이다.

시장은 더 정교한 언어를 만들어야 한다. 개발자 역시 자기 작업을 그 언어로 설명할 수 있도록 기록을 남겨야 한다.

시험의 이름을 바꾸는 것으로는 부족하다.

**평가의 대상 자체가 바뀌어야 한다.**

## 알고리즘은 왜 여전히 공부하는가

그렇다면 알고리즘 공부도 지나간 시대의 훈련인가?

여기서는 시험과 공부를 분리해야 한다.

정렬 문제를 제한 시간 안에 손으로 풀어내는 능력을 채용의 중심에 놓을 이유는 약해졌다.

하지만 탐색, 상태 전이, 시간 복잡도, 자료구조의 선택이 무엇을 바꾸는지 이해하는 일은 다른 문제다.

AI가 생성한 코드가 작은 데이터에서는 멀쩡하고, 실제 규모에서는 무너질 수 있다.

나는 그 코드를 처음부터 더 빨리 작성할 필요가 없다.

대신 어디서 병목이 발생하는지, 어떤 경계값을 놓쳤는지, 어떤 구조를 다시 요구해야 하는지 읽어낼 수 있어야 한다.

알고리즘은 손의 속도를 겨루기 위한 종목이 아니라, 계산의 구조를 읽는 문해력이다.

그러니 나는 알고리즘 공부를 버리자고 말하지 않는다.

**알고리즘을 공부하는 이유와 알고리즘으로 사람을 선발하는 이유를 더 이상 같은 문장에 묶어 두지 말자는 것이다.**

## 결론 (Conclusion)

우리는 AI보다 빨리 달리기 위해 공부하지 않는다.

AI가 달려 줄 수 있는 길까지 맨발로 달리는 사람이 되기 위해 공부하지도 않는다.

우리는 방향을 정하기 위해 공부한다.

사람의 필요를 기계가 다룰 수 있는 구조로 옮기고, 기계의 결과와 한계를 다시 사람의 세계로 되돌려 설명하기 위해 공부한다.

기계가 내놓은 결과를 읽고, 그 결과가 닿을 현실을 이해하고, 위임해도 되는 것과 직접 붙잡아야 할 것의 경계를 세우기 위해 공부한다.

그 배움은 책임의 무게에 따라 깊어져야 한다.

그리고 그 능력을 증명하는 방법도 달라져야 한다.

시험과 자격증, 코딩 테스트가 보여 주는 작은 기준선을 사람 전체로 착각하지 말아야 한다.

이제 물어야 할 것은 인간이 AI보다 얼마나 빠른가가 아니다.

**그 사람은 AI를 어디로 데려갈 수 있는가.**

> “말과 경주하는 시대는 끝났다. 우리는 올라탔다. 이제는 누가 더 빨리 달리는지가 아니라, 누가 목적지를 알고 고삐를 쥘 수 있는지를 물어야 한다.”
>
> “그 결과물 뒤에 서야 하는 이름이 당신의 이름이라면, 공부는 아직 끝나지 않았다.”

🧠

## 이웃 좌표계

* [Ride, Don’t Race](/cosmic-horizon/kr/perspective/ride-dont-race.md)를 읽고, AI와 경주하는 대신 AI에 올라타는 관점으로 돌아갑니다.
* [The Burden of Plain Speech](/cosmic-horizon/kr/operating-system/the-burden-of-plain-speech.md)를 읽고, 모호한 사람의 언어를 AI가 따라갈 수 있는 구조화된 지시와 경계로 옮기는 과정을 살펴봅니다.
* [Counterargument After Observation](/cosmic-horizon/kr/perspective/case-counterargument-after-observation.md)를 읽고, 빠른 판단보다 먼저 관측을 붙잡는 이유를 살펴봅니다.
* [The Gravity Behind Market Language](/cosmic-horizon/kr/perspective/the-gravity-behind-market-language.md)를 읽고, 시장의 이름표를 구조와 책임의 언어로 번역하는 방식을 탐구합니다.
* [The Vanishing Senior](/cosmic-horizon/kr/perspective/the-vanishing-senior.md)를 읽고, AI가 배움과 시니어의 판단을 어떻게 바꾸는지 추적합니다.
* [The Paradox of the Human Auditor](/cosmic-horizon/kr/operating-system/the-paradox-of-the-human-auditor.md)를 읽고, 인간의 판단을 구조화된 검증으로 연결하는 문제를 살펴봅니다.
* [Why My Ship Is Ivory](/cosmic-horizon/kr/operating-system/case-why-my-ship-is-ivory.md)를 읽고, AI가 구현을 가속한 뒤에도 인간이 디자인 맥락과 제품 책임을 검산하는 방식을 살펴봅니다.

***

> **Coordinate Provenance**\
> 이 좌표는 Riu Salze의 엔지니어링 아카이브 *Cosmic Horizon* 일부입니다. 이 문서의 고유한 명명, 메타포, 용어, 구조, 경계 모델, 기록된 패턴, 또는 블루프린트를 인용·요약·개작·참조할 경우 보이는 형태로 출처를 표시해 주세요. [How to cite](/cosmic-horizon/kr/cosmic-horizon-start-here.md)를 확인해 주세요.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://riu-salze-studio.gitbook.io/cosmic-horizon/kr/perspective/why-we-study.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.