“간단하게 설명할 수 없다면 모르는 것이다.”

주의! : 개인 의견 + 개인 학습 방법에 대한 글 입니다.

SSAFY 과정을 거치고, 인턴도 해보며 여러가지 기술을 공부하며 늘 마음에 걸렸던 “어떻게 공부할까”

언어는 배운걸 바로 사람들과 대화하며 써보기도 하고, 요즘은 AI랑도 떠들면서 실전 적용을 어느정도 해볼 수 있었다.

하지만 개발은 학습은 학습, 개발은 개발 따로 공부하는 기분이 좀 들었다. (CS / 알고리즘 / 실제 FE/BE 구현 등등)

또한 새로운 기술을 배울 때마다 왜? 라고 물어보기는 하지만, 실제 개발로 들어가면 동작하는 코드로 구현하는데 급급하다보니 질문을 잊기도 했다.

이런 문제를 해결할 겸 마침 비슷한 상황인 경우를 보아서, 언어 학습 시절과 약간 TDD에서 영감을 받은 학습 자체를 명세화 하는 공부(개발) 방법을 기획해보았다.

1. SLD (Specification-Led Development)

SLD는 명세-학습 주도 개발(Specification-Led Development)의 약자이며, 다음과 같은 재귀적인 순환이 핵심이다.

[!INFO] SLD의 기반 철학 > 학습을 명세로, 명세를 코드로, 코드를 다시 학습으로 환원하는 재귀적 개발 방법론

명세, 즉 ‘무엇을 구현할 것인가’는 최종 목표뿐만 아니라 ‘무엇을 알아야 하는가’라는 지식적 질문을 동시에 품는다.

개발은 이 질문에 대해 탐구한 후, 이해를 바탕으로 진행한다.

SLD 개발 과정: 지식 연마의 7단계 순환

SLD는 단순 코딩이 아닌, 지식의 깊이를 조절하며 개발을 진행하는 7단계 구조를 따릅니다.

이 과정을 TDD의 ‘Red-Green-Refactor’처럼 ‘질문-학습-재고’의 반복 루프로 생각하면 편하다.

명세 → 질문 → 학습 → 메타 질문 → 재학습 → 재고(Reflection) → 개발 → 명세(갱신)

단계 목표 역할
명세 구현 기능 기술 목표를 설정하고, 지식적 질문을 촉발하는 주체
질문/학습 지식적 의문 명시 및 수행 명세의 하위 노드로 구조화된 지식 기록
메타 질문 “이 기술이 왜, 어떻게 생겨났을까?” 근원적 탐구. 깊은 이해를 통해 재명세의 기회를 발견
재고 명세의 적절성 점검 학습 내용을 바탕으로 명세의 누락/불필요성 점검 및 개선
개발 기능 구현 및 테스트 학습 결과를 코드로 증명
명세(갱신) 학습/개발 결과 반영 시스템의 지식 베이스 업데이트

SLD의 핵심 원칙: 깊이와 균형

SLD의 성공은 기능 구현(개발) 과 근원적 탐구(학습) 사이의 최적 균형점을 찾는 데 달려 있다.

원칙 1. 학습은 명세를 구조화하는 재귀적 기록이다.

SLD를 진행할 땐 트리 구조를 사용한다.

마치 React의 컴포넌트처럼, 명세 노드 아래 학습 노드를 계층적으로 연결하여 유기적으로 배치될 수 있도록.


명세: "NestJS OAuth2 구현" (Depth 0)
  자식:
    - 학습: "OAuth2 프로토콜 이해" (Depth 1)
      자식:
        - 메타질문: "OAuth2의 근본적 목적은 무엇인가?" (Depth 2)

이 깊은 학습(Depth 5 내외)은 기술의 원리를 파헤치는 데 중요하지만, 개발 프로세스를 마비시켜서는 안된다!!

원칙 2. 구현과 탐구는 최적의 균형점을 가진다.

제일 어려운 부분

기술의 근원적 본질에 대한 탐구는 새로운 명세나 별도의 학습 영역으로 분리하여, 현재 명세의 구현을 지연시키지 않도록 통제한다. (최대 깊이 5 설정의 이유입니다.)

원칙 3. 학습의 완성은 설명과 공유에 있다.

“기록하고, 설명하고, 공유하며 학습은 증거가 되며, 증거를 통해 검증된다.”

학습 기록은 단순히 개인의 노트를 넘어, 공유 가능한 지식 증거가 되어야 한다고 생각한다.

이는 결국 코드의 품질과 설계의 견고함으로 이어질 것이다.

아무래도, 블로그 포스팅도 해당 공유 과정의 일환이라고 볼 수 있겠다.

개념 이후, 실제 실천을 위한 개발

Rust를 활용한 CLI 로 우선 간단하게 사용할 수 있는 SLD 툴을 만들어보고 싶었다.

CLI 를 좋아하기도 하지만, 변경이 많이 들어가는 부분이 꽤 있다고 생각했기 때문에, 우선 컴퓨터를 활용한 저장을 먼저 진행할 수 있도록. (질문을 까먹지 않기 위함도 있다.)

  1. 왜 Rust로 CLI/TUI를 개발했는가?

프론트엔드 스택(React, Vue)과 백엔드(Node.js)를 모두 다루지만, SLD 도구를 위해 Rust를 선택했다.

스페인어 전공 출신으로 ‘왜’라는 질문을 좋아하는 나에게, 새로운 학습의 동기부여가 될 겸, Rust가 CLI에 좋다는 내용도 봤기 때문이다.

추가적인 이유로는

Rust 선택 이유 SLD 철학과의 연관성
성능 및 안전성 명세가 정확하다면, 코드는 오류 없이 빠르게 작동해야 한다. Rust의 메모리 안정성은 SLD의 치밀한 기록(명세) 철학을 코드로 옮기는 데 적합했다.
CLI/TUI의 역할 SLD는 개발의 흐름을 방해하지 않아야 한다. TUI(Terminal User Interface)는 IDE나 브라우저를 벗어나지 않고 명세와 학습을 빠르게 기록하고 관리할 수 있게 해준다.
도전과 성장 솔직히 말해서, 가장 어려운 기술에 도전하여 시스템 툴을 만들고 싶다. 비전공자도 Rust와 시스템 도구를 다룰 수 있음을 스스로에게 증명하고 싶었다.

마무리하며

  • 예전에 스페인어를 공부하며, 문법을 배우고 실제로 어떻게 사용해야 할까 하고 예문을 구성한 느낌에서 영감을 받았다.
  • 결국 같은 지식인 만큼, “왜” 를 따라가다 보면 더 자세히 이해할 수 있고, 이해를 바탕으로 새로운 질문을 던진다면
  • 대신 개발은 실제로 무언가를 구현하는 만큼 구현, 즉 개발에 대해 소홀히 하고싶지 않았다.
  • 해당 방법을 적용하며 학습해보고, 괜찮은 학습방법인지 평가해보려고 한다.

2부에서는 이 SLD 방법론을 Rust의 ratatui와 crossterm 라이브러리를 사용해 어떻게 TUI CLI로 구현했는지, 그리고 그 과정에서 겪었던 내용을 공유하고자 한다.