# 서론
## 함수형 프로그래밍.
함수형 프로그래밍. 우테코 레벨1동안 나와 끈질기게 함께 한 키워드이다.
이번 우테코 8기에는 ‘송곳 원정대’라는 활동이 있다.
크루들은 원정대를 새로 만들 수도 있었고, 코치가 사전에 만든 원정대를 선택할 수도 있었다.
나는 레벨1에선 프로그래밍의 기초를 다지는 원정대가 좋을 것 같다고 생각했고,
웹 프로그래밍의 기초가 되는 ‘함수형 프로그래밍’를 깊게 공부해보기 위해 유일하게 원정대를 직접 개설하게 되었다.
## 함수형 프로그래밍..?
함수형 프로그래밍?
함수도 알고 프로그래밍도 알지만 함수형 프로그래밍은 뭘까.
간단하게 생각하면 말 그대로 함수들을 잘 조합하여 프로그래밍 하는 방식을 의미한다.
자세한 정의를 알고 싶어, AI에게 정의를 물어보았다.
함수형 프로그래밍(Functional Programming)은 부수 효과(Side Effect)를 제거하고 순수 함수를 조합하여 상태 변경 없이 데이터 계산을 처리하는 선언형 프로그래밍 패러다임입니다.
생각보다 다양한 개념이 쏟아져 나왔다.
부수 효과, 순수 함수, 상태 변경, 선언형 프로그래밍…
역시 나는 함수형 프로그래밍에 대해 반밖에 모르고 있었다.
새로 배울 키워드가 많아보여 좋은 주제라고 생각함과 동시에 레스, 유월, 루멘, 도넛, 클라우디가 원정대원으로 참여해 같이 함수형 프로그래밍 원정대를 시작하게 되었다.
## 원정대에서 스터디까지의 여정
나는 가장 먼저 원정대에서 기준이 될 교재(서적)을 찾고 싶었다.
우테코 라이브러리에 마침 ‘쏙쏙 들어오는 함수형 코딩’이라는 책이 있었고, 목차와 내용을 훑어보니 정말 중요한 키워드들을 자세한 예시와 함께 잘 설명하고 있었다.
그렇게 레벨1동안 우리는 액션/계산/데이터, 불변성, 계층형 설계 등의 내용이 포함된 파트1을 진행했다.
그 과정에서 우린 생각보다 다양한 내용을 깊게 공부할 수 있었다.
각자 책을 읽고 본인이 얻은 내용을 공유하는 ‘끄적이기 공유회’부터,
둘이 짝을 지어 함수형 프로그래밍 원칙에 따라 리팩토링 해보는 ‘페어 프로그래밍’,
그리고 원정대 활동 내용 발표회인 ‘테크 살롱’까지 성공적으로 끝낼 수 있었다.
사실 공식적인 원정대 활동은 3월 9일부터 3월 20일까지였고, 원정대가 끝난 뒤에도 고맙게도 원정대원들이 이어서 남은 부분도 같이 공부하고 싶다는 의사를 밝혀주어 스터디로 전환 후 레벨1 마지막까지 스터디 활동을 지속했다.
# 본론
함수형 프로그래밍 원정대(스터디)를 하며 내게 도움이 되고 인상 깊었던 활동은 크게 4가지였다.
- 하드 스킬 그 자체
- 끄적이기 공유회
- 페어 프로그래밍
- 테크 살롱
이것들을 중점으로 회고를 진행해보려고 한다.
## 1. 하드 스킬 그 자체
### 1. 액션, 계산, 데이터
가장 먼저 부딪힌 건 코드를 바라보는 세 가지 관점이다.
책에서는 코드를 액션, 계산, 데이터로 명확히 분류한다.
간단하게 생각하면, 실행 시점이나 횟수에 따라 결과가 달라지며 부수 효과를 발생시키는 놈들은 모두 액션이다.
이 액션은 주변 코드까지 액션으로 오염시키는 전염성이 있다.
반면 계산은 언제나 똑같은 입력값으로 똑같은 출력값을 만드는 순수 함수이고, 데이터는 그저 이벤트에 대한 단순한 사실이다.
결국 함수형 사고의 첫걸음은 복잡하게 엉킨 액션 속에서 언제 실행해도 안전한 '계산'과 정적인 '데이터'를 잘 발라내어 분리해내는 것이다.
### 2. 암묵적 입출력
함수를 작성할 때 놓치기 쉬운 것이 바로 암묵적 입출력이다.
프로그래밍의 세계에서 명시적인 인자나 리턴값이 아닌 전역 변수를 읽거나 쓰는 등 모든 외부와의 상호작용이 이에 해당한다.
함수에 암묵적 입출력이 하나라도 섞이는 순간 그 함수는 액션이 되어버린다.
따라서 우리는 암묵적 입력을 명시적 '인자'로, 암묵적 출력을 명시적 '리턴값'으로 끄집어내어 액션을 통제 가능한 계산으로 탈바꿈시켜야 한다.
암묵적 입출력을 줄일수록 코드는 테스트와 재사용이 훨씬 쉬워진다.
### 3. 불변성에 관하여: 카피-온-라이트와 방어적 복사
상태 변경으로 인한 버그를 막으려면 불변성을 어떻게 유지할 수 있을까?
책을 읽어보며 나만의 언어로 명확히 두 가지 원칙을 구분할 수 있었다.
먼저, 카피-온-라이트는 통제할 수 있는 안전지대 내에서 데이터를 변경할 때 사용하는 얕은 복사 기술이다.
- 복사본을 만들고,
- 복사본을 변경하고,
- 복사본을 리턴하는 3단계를 거친다.
이 과정을 거치면 원본 데이터의 불변성이 지켜지며, 데이터를 수정하는 '쓰기' 동작을 안전한 '읽기' 동작으로 영리하게 바꿀 수 있다.
반면, 레거시 코드나 외부 라이브러리처럼 신뢰할 수 없는 코드와 데이터를 주고받을 때는 방어적 복사를 사용해야 한다.
안전지대로 데이터가 들어오거나 나갈 때마다 깊은 복사를 수행하여 외부의 오염으로부터 데이터를 완벽히 보호하는 방식이다.
### 4. 계층형 설계
코드를 무작정 쪼갠다고 끝이 아니었다.
계층형 설계는 분리한 계산과 데이터들을 추상화 수준에 맞춰 층층이 쌓아 올리는 작업이다.
비슷한 추상화 계층에 있는 함수들끼리 서로 호출하도록 만드는 '직접 구현' 패턴을 적용하고, 세부 구현을 완벽히 감추어 다른 팀이 구체적인 데이터 구조를 몰라도 개발할 수 있도록 '추상화 벽'을 세우는 것이 핵심이다.
호출 그래프를 그려보면 시각적으로 더 명확해지는데, 위쪽에 있는 코드는 비즈니스 규칙처럼 자주 바뀌기 쉬운 코드고, 아래쪽은 에 있는 코드는 시간이 지나도 재사용과 테스트 가치를 지니는 코드라는 점을 이용해 소프트웨어를 단단하게 배치할 수 있다.
## 2. 끄적이기 공유회
끄적이기 공유회. 거창해보인다면,, 의도된 것이다. 사실 원정대 기간동안 공유회라는 용어는 쓰지 않았지만,, 한 번 붙여보았다.
### 끄적이기를 하게 된 이유
나는 책을 읽고 단순히 요약본을 만들어오는 스터디는 하고 싶지 않았다.
그래서 정해진 분량을 읽고 완벽하게 정리된 글이 아닌, 날것의 생각과 질문들을 자유롭게 적어오는 '끄적이기'라는 방식을 도입했다.
단순한 개념 나열보다는 "그래서 이 개념을 우리 코드에 어떻게 적용할 수 있을까?", "책에서는 이렇게 말하지만 과연 이게 최선일까?"와 같이 책을 읽고 개념을 공부하며 생기는 궁금증을 적도록 크루들에게 유도했던 것 같다.
### 끄적이기 방식이 정말 통했을까?
끄적이기를 공유하는 시간은 단순히 지식을 확인하는 자리가 아니라, 서로 다른 시각을 확인하는 시간이었다.
책의 같은 파트를 읽고도 크루들이 주목한 포인트와 고민의 방향은 달랐고, 우리는 실시간으로 생각을 공유하고 검증해보며 깊게 파고 들었다.
예를 들면 레스는 8장에서 "데이터를 매번 복사하면 메모리 낭비가 심하지 않을까?" 라는 의문을 제기했는데, 이에 대해 우린 얕은 복사와 구조적 공유, JS에서 데이터를 탐색하는 방법 등에 대해서 다같이 공부해보며 정답을 찾아가기도 했다.
이 외에도
- "테스트가 용이한 계산(순수 함수)을 최대한 많이 만들어야 한다? 로직 설계 시 액션과 계산을 어떻게 영리하게 분리할 수 있을까?" -루멘
- "함수형 프로그래밍에서 지향하는 바가 무결성이라면, 왜 굳이 액션을 만들어야 할까? 액션이 없다면 소프트웨어는 외부와 소통할 수 없기에, 결국 액션을 통제 가능하게 만드는 것이 핵심일 것이다." -클라우디
- "모든 암묵적 입출력을 명시적으로 바꿔야 할까? 때로는 과도한 명시적 입출력이 코드의 가독성을 해칠 수 있다." -도넛 등.
우리는 각자 책으로 공부하며 생긴 궁금증과 인상 깊었던 점을 공유했다. 이처럼 끄적이기는 정답을 찾는 과정이라기 보다는, 토론하는 장에 가까웠다.
### "방어적 복사 vs 카피-온-라이트"
내 경험도 공유해보고자 한다. 책의 7장을 읽으면서 남겼던 내 끄적이기 노트에는 이런 질문이 적혀있다.
"방어적 복사랑 카피-온-라이트랑 비슷한 거 같은데.. 차이점이 뭘까?"
처음에는 두 개념이 그저 똑같이 '불변성을 유지하기 위해 데이터를 복사하는 행위' 정도로만 느껴졌다. 하지만 이 질문을 시작으로 책을 다시 읽어보고 AI에게 질문하며, 나만의 언어로 두 개념의 차이를 정의할 수 있었다.
결론적으로 방어적 복사는 "남을 못 믿어서 (외부 코드의 오염을 막기 위해) 미리 만드는 깊은 복사가 적용된 사본"이었고, 카피-온-라이트는 "수정할 일이 생길 때만 불변성을 지키며 (구조적 공유를 통해) 똑똑하게 자원을 아끼는 얕은 복사 기술"이었다.
즉, 전자는 시스템의 '경계'에서, 후자는 내부 '로직'에서 쓰인다는 명확한 기준이 선 것이다.
실제 끄적이기 공유회 때 해당 내용을 공유하며, 다른 크루들도 같은 지점에서 의문을 느꼈고 각자의 의견을 공유하며 개념을 정립해가는 과정이 인상 깊었다.
끄적이기 공유회는 겉에서 봤을 땐 아무 소득도 없는 단순히 모여서 이야기하는 활동처럼 보일 순 있어도, 몇 주 간의 끄적이기 공유회를 돌아봤을 땐 결국 우린 불확실한 것을 확실하게 알 수 있었고, 궁금한 점을 모두 해소할 수 있었다고 생각한다.
## 3. 페어 프로그래밍
우리는 활동 초반 회의에서 앞으로의 활동 방향성을 정해가는 중, 직접 페어 프로그래밍을 해보자는 의견이 나왔다.
즉 PART1의 핵심이었던 ‘액션/계산/데이터’를 분리하는 리팩토링을 직접 실습으로, 그것도 페어로 해보는 것이었다.
그렇게 우리는 ‘유월’이 AI와 함께 만들어준 일명 ‘냄새 나는 코드’를 가지고 리팩토링을 하기로 했고, 유일하게 본미션 외에 페어 프로그래밍을 병행한 원정대가 되었다.
책으로 '액션, 계산, 데이터'의 개념을 읽을 때는 분리가 참 쉬워 보였다.
그냥 "부수 효과가 없게 순수 함수로 빼면 되잖아?"라고 생각했다.
하지만 막상 ‘냄새 나는 코드’를 직접 분리하려니 어디부터 어디까지 분리할 것이고, 어떤 기준으로 분리할 것인지에 대한 얘기가 많이 오갔다.
특히 페어 프로그래밍 후 각 페어의 PR에 남긴 코멘트들을 종합해보니 공유되는 논쟁 거리가 몇 가지 나왔었다.
그 중 가장 의견이 많았던 throw 논쟁에 대해 간단하게 소개하고자 한다.
### 에러를 던지는 행위(throw)는 '액션'인가, '계산'인가?
"잘못된 값이 들어왔을 때 throw new Error()로 에러를 던지면, 이건 외부의 흐름을 제어하는 부수 효과(액션)일까?"
이에 대해 우리 원정대 안에서도 반반 갈렸던 것 같다.
"계산은 언제나 예측 가능한 값만을 반환해야 하므로, 프로그램의 흐름을 강제로 끊어버리는 throw는 명백한 액션이다."
"잘못된 입력에 대해 에러 객체를 반환하거나 발생시키는 것도 일종의 결정된 출력이므로 계산의 영역으로 볼 수 있다."
결국 우리는 AI도 사용해보고 열띤 토론도 했다.
결론적으로 우리 원정대는 순수 함수(계산)의 예측 가능성을 극대화하기 위해, 하위 계층 내부에서 무작정 에러를 던지기보다는 상위(액션 계층)에서 에러를 catch하여 제어하거나, 계산 계층은 최대한 예측 가능하게 소통하도록 설계하는 방향이 올바르다고 생각했다.
이 외에도 여러 논쟁이 있었고, 우리는 페어 프로그래밍을 진행하며 나눴던 의견들을 기반으로 열심히 토론했다.
그렇게 페어 프로그래밍 경험은 우테코 레벨1 통틀어서 가장 기억에 남았던 활동 중에 하나로 남았다.
## 4. 테크 살롱
원정대의 종착점은 테크 살롱이었다. 다만 돌아봤을 때 이 테크 살롱은 여러 관점에서 문제가 많았던 것 같다.
처음에 테크 살롱이 기획된 의도는 다음과 같았다.
### 뭔가 잘못 됐다.
하지만 스케일이 커져, 프론트와 백엔드 모두에게 발표를 해야했고 많은 원정대들은 그때 방향성을 완전히 수정하거나 배경 지식 설명에 시간을 많이 투자했던 것 같다.
우리도 백엔드에게도 공유해야한다는 사실을 듣고는 최대한 JS 코드를 빼고, 이미지나 도식화로 많이 설명하려 했다.
그리고 생각보다 다들 열정이 넘쳐서 원정대 총 기간이 2주도 안 되는데 그 기간동안 절반은 테크 살롱 준비를 하는데 썼다.
배보다 배꼽이 더 커진 느낌이었다.
다들 송곳을 다 만들기도 전에 공유를 하는 분위기였다.
하지만 다행히 우리는 분량을 잘 조절했고, 결과적으로 테크 살롱은 성공적이었던 것 같다.
### 피드백의 중요성
테크 살롱을 준비하며 겪었던 경험 중 인상 깊었던 경험이 있다.
테크 살롱 내용 중 ‘계층형 설계’를 설명해야 하는 부분이 있었다.
예제 코드를 계층에 따라 분리해야하는데 우리가 계속 분리하면서도 명확한 기준이 없어 계층을 정확하게 나누기가 애매해졌다.
그리고 원정대원끼리도 의견이 계속 충돌하여 어떻게 해야할지 감을 잘 못 잡고 있었다.
그때 나는 제삼자의 시선에서 이 문제를 바라볼 필요가 있다고 생각해 냅다 회의실을 뛰쳐 나가서 밖에 있는 백엔드 크루를 섭외했다. (이때 시간이 밤 9시였다.)
나, 유월, 루멘, 도넛은 백엔드 크루에게 테크 살롱 간이 시연을 했고 백엔드 관점에서의 피드백에서 정말 많은 것들을 얻을 수 있었다.
우리가 생각보다 깊은 내용을 발표하려고 했던 것, 계층을 너무 교과서 정석대로 상세하게 나누려했던 것 등 여러 개선점을 고칠 수 있었다.
이어서는 프론트 크루도 섭외 해 같은 방식으로 피드백을 요청했고, 그 과정에서도 우리가 설명적으로 어디가 부족했는지 메꿀 수 있는 시간이었다.
# 결론
짧다면 짧고 길다면 긴 6주간의 원정대와 이어진 스터디를 마무리하며, 내가 얻은 것은 단순히 액션/계산, 계층형 설계와 같은 파편적인 지식만이 아니었다.
먼저, 코드를 바라보는 새로운 시야를 얻었다.
이전에는 요구사항을 마주하면 무작정 타이핑부터 시작했다면, 이제는 코드를 짜기 전에 잠시 멈춰 스스로에게 묻는다.
'이건 액션인가? 이 부분은 계산으로 덜어낼 수 없을까? 보이지 않는 암묵적 입력에 의존하고 있지는 않은가?'
아직 완벽한 순수 함수형 코드를 구사하진 못하더라도, 액션과 계산을 분리하려는 의식적인 노력 자체가 내 코드를 훨씬 더 견고하고 테스트하기 쉽게 만들어준다는 사실을 뼈저리게 체감했다.
둘째, '함께 자라기'의 진정한 가치를 배웠다.
혼자 책상에 앉아 책만 읽었다면, 방어적 복사와 카피-온-라이트의 차이를 글로만 외우고 넘어갔을 것이다.
굳이 레포지토리를 파서 페어 프로그래밍을 진행하며 throw의 정체성을 두고 열띤 토론을 벌일 일도, 테크 살롱을 준비하다 막혀서 밤 11시에 '왔다감'을 찍지도 않았을 것이다.
흩어져 있던 지식이 '끄적이기'와 PR 리뷰를 통해 내재화되고, 타인에게 설명하고 피드백을 받는 과정에서 단단하게 성장하는 경험은 우테코 레벨 1에서 얻은 가장 값진 수확이었다.
마지막으로, 심리적 안전감이 높은 크루들을 얻었다.
다소 막연했을 수 있는 나의 원정대에 흔쾌히 합류해 주고, 원정대 기간이 끝난 후에도 자발적으로 스터디를 이어가며 매주 치열하게 고민을 나눠준 레스, 유월, 루멘, 도넛, 클라우디에게 진심으로 고마움을 전하고 싶다.
'우아한테크코스 > 원정대 | 스터디' 카테고리의 다른 글
| [Tech Deep Dive] Chrome Extension, 어디까지 가능한가? (0) | 2026.05.02 |
|---|---|
| [디버깅 원정대] 4. lodash 디버깅톤과 원정대를 마치며 (0) | 2026.04.24 |
| [디버깅 원정대] 3. is.js를 파악한 두 가지 방법 (0) | 2026.04.24 |
| [디버깅 원정대] 2. ms 파헤치기 (0) | 2026.04.22 |
| [디버깅 원정대] 1. 디버깅 원정대 첫걸음 (1) | 2026.04.22 |
