Geongyu

우테코 3, 4주차 회고

송곳 원정대

우테코에서 이번에 처음으로 시도된 활동, 이름부터 인상적인 "송곳 원정대". 말 그대로 하나의 개념을 깊게 파고들어 끝까지 뚫어보자는 취지의 프로그램이었다. 나는 그중에서도 함수형을 주제로 한 "함수형 원정대"에 참여하게 되었다.

우리는 『쏙쏙 들어오는 함수형 코딩』이라는 책을 기반으로 학습을 진행했다. 활동 초반에는 정해진 분량을 각자 읽어오고, 이후 모여서 자신이 이해한 내용을 서로에게 설명하는 시간을 가졌다.

우리는 대략 9장까지의 범위를 읽고 공유했다.

하지만 단순히 책을 읽는 것만으로는 함수형을 공부하기에 충분하지 않다고 느꼈다. 개념을 아는 것과 실제로 적용하는 것은 전혀 다른 영역이다. 그래서 배운 내용을 직접 코드에 녹여볼 수 있는 시간이 필요하다고 생각했고, 나는 원정대에 페어 프로그래밍을 제안했다.

다행히 제안이 받아들여졌다. 우리는 페어로 냄새나는 코드를, 공부하면서 배운 함수형 사고를 직접 적용해보면서 리팩토링해보는 시간을 가지게 되었다.

https://github.com/woowacourse-study/2026-fp-deep-dive

이후에는 다른 페어들의 PR을 읽으며 리뷰를 남겼다. 각자의 사고방식과 설계 기준들을 엿볼 수 있는 시간이었다.

그 과정에서 자연스럽게 의견이 충돌하는 지점들도 생겼고, 몇몇 주제에 대해서는 대면으로 깊이 있는 토론을 진행하기도 했다.

논의1 : throw를 사용하면 액션인걸까?

한 크루가 "throw를 사용하는 방식이 과연 올바른지", 그리고 "굳이 throw를 사용함으로써 액션으로 만드는 것은 아닐지"에 대한 고민을 공유했다.

처음에 나는 throw를 사용하더라도 계산으로 볼 수 있지 않을까 생각했다.

계산은 호출 시점과 횟수에 상관없이 동일한 입력에 대해 항상 동일한 결과를 반환하는 함수라고 정의된다. 그렇다면 throw 역시 동일한 입력에 대해 동일하게 발생한다면, 계산으로 볼 수도 있지 않을까 싶었다.

하지만 논의를 이어가며, throw 자체가 프로그램의 흐름을 바꾸고 외부에 영향을 주는 방식이라는 점에서 액션으로 보는 것이 더 타당하다는 의견에 공감하게 되었다.

결국, 실패를 표현해야 한다면 throw보다는 명시적으로 값을 반환하는 방식이 더 함수형적인 접근이라는 결론에 도달했다.

논의 2 : 변하지 않는 상수값을 인자가 아닌 암묵적 입력으로 받으면 액션인걸까?

또 다른 논의는 "절대 변하지 않도록 안전장치를 한 상수값까지 굳이 인자로 받아야 할까?"라는 질문에서 시작되었다.

const나 Object.freeze 등을 통해 변경되지 않도록 보장된 값이라면, 호출 시점과 횟수에 상관없이 동일한 결과를 반환할 수 있다. 그래서 나는 이런 경우라면 계산으로 볼 수도 있지 않을까 생각했다. 또한 공통적으로 사용하는 상수라면 어느 정도의 암묵적 입력은 허용해도 괜찮지 않을까라는 생각도 들었다.

하지만 이 의견은 바로 반박을 받았다.

"암묵적 입력과 출력은 원칙적으로 없어야 한다. 지금은 상수라고 해도, 미래에도 절대 변하지 않는다고 보장할 수 있는가? 비즈니스 요구사항은 언제든 바뀔 수 있고, 그 순간 이 함수의 순수성은 깨진다."

이 말을 듣는 순간 설득될 수밖에 없었다. 책에서 강조하던 내용과 정확히 일치했고, 논리적으로도 완전히 납득이 되었기 때문이다.

위의 두 가지 논점에 대해서 토론하는 시간을 가지면서 정말 많은 사고의 변경과 확장을 할 수 있었다.

원래 개발과 관련해서 개인적으로 정말 고집이 세고 개인 주장이 강한 편인데, 2개의 논점에 대해서는 바로 순응할 수 밖에 없었다. 그러면서 뭔가 그동안 내가 올바르다고 믿어왔던 관점들이 이번 함수형 공부를 하면서 많이 무너진 느낌을 받았다. (무너졌다기 보다는 조금 더 유연하고 올바른 방향으로 가고 있는 것일 거다)

사실 이 또한 혼자서 함수형 공부를 했다면 절대로 이런 관점을 가지지 못했을거다. 함께 공부하고 나아가는 열정있는 사람과 함께했기에 가능했다. 아마 코치님들도 이러한 점을 노리고 함께 공부하는 기회를 만드신 것이 아닐까 싶었다.

이후 학습 활동이 마무리된 뒤 남은 일주일은 대부분 공유회 준비에 집중했다. 시간이 날 때마다 모여서 어떻게 하면 더 효과적으로 전달할 수 있을지 고민하고, 여러 번 회의를 거듭했다.

이번 공유회의 특징은 단순한 "전달"이 아니라 "전이"에 있었다. 듣는 사람이 수동적으로 받아들이는 것이 아니라, 직접 참여하고 체험하면서 개념이 자연스럽게 자신의 것으로 넘어가도록 만드는 것이 목표였다.

그래서 우리는 최대한 참여형으로 진행할 수 있도록 발표를 기획했다.

공유회 준비 : 실습 자료 만들기

실습 자료 링크 : https://github.com/geongyu09/functional-expedition-codlab 배포 링크 : https://functional-expedition-codlab.vercel.app/

이번 공유회를 준비하면서, 나는 실습 자료를 직접 만들어보기로 했다. 시간상 실습 자료를 직접 개발할 수는 없어 AI를 활용해서 만들게 되었다. 제작에는 대략 이틀 정도가 걸렸고, 직접 코드를 만지지 않고 완성할 수 있었다. (문구를 수정하거나 상수 값을 조정하는 정도만 손봤다.)

개발에는 Pencil, Claude Code, Gemini CLI, 그리고 React Grab을 활용했다.

처음에는 Pencil을 사용해 프롬프트로 내가 구상한 아이디어를 전달했다. 간단한 설명만 입력해도 이를 기반으로 꽤 그럴듯한 UI를 만들어주었는데, 이 결과물은 .pen 파일로 저장된다. 이 파일은 JSON 형식이라 CLI 기반 AI들이 읽고 처리하기에 적합했다.

이후 Claude Code를 활용해 .pen 파일의 node id를 기준으로 각 요소의 동작 요구사항을 작성하고, 이를 바탕으로 기능 구현을 진행했다.

중간중간 UI가 의도와 다르게 나오거나, 요구사항이 정확히 반영되지 않은 부분들도 있었다. 또는 단순히 더 개선하고 싶은 지점들도 있었다. 이런 경우에는 React Grab을 통해 특정 영역을 선택한 뒤, Gemini CLI나 Claude Code에게 수정 요청을 전달하는 방식으로 작업을 이어갔다. (참고로 Claude와 Gemini를 함께 사용한 이유는… 토큰 제한 때문이었다. 둘 다 Pro인데도 부족했다.)

이 과정을 거치면서 몇 가지 느낀점이 있었다.

우선, 프론트엔드에 대한 깊은 지식이 없어도 어느 정도 수준의 프로토타입은 누구나 만들 수 있는 시대가 왔다는 것을 체감했다.

이번에 처음으로 직접 개발하지 않고 99% AI만 사용하여 만들어보았다. 내가 직접 개발했었다면 개발 과정 속에서 한두 개쯤은 생겼을 법한 버그들이 거의 없이 한 번에 제대로 동작하는 결과물이 나온다는 점이었다. 이 부분에서는 솔직히 감탄할 수밖에 없었다.

이제는 진짜 코드를 치지 않아도 그럴싸한 결과물을 만드는 단계이구나를 체감할 수 있었다.

다만, 예상치 못한 결과물이 나오는 경우도 있었다.

돌이켜보면 이는 AI의 문제가 아니라 내가 요구사항을 충분히 구체적으로 전달하지 않았기 때문이었다. AI에게는 '해석의 여지'를 주지 않는 것이 중요하다는 것을 느꼈다. 내가 원하는 것을 정확하게 요구할 수 있는 능력이 정말 중요해질 것 같다.

물론 그렇다고 해서 개발 지식이 필요 없는 것은 아니었다.

오히려 React나 코드 구조에 대한 이해도가 높을수록, AI를 훨씬 더 잘 활용할 수 있다는 생각이 들었다.

예를 들어, 자잘한 변경이 있다면 직접 코드단을 만지는 것이 AI를 사용하는 것 보다 생산적이다는 점이다.

토큰은 결국 비용이다. 사소한 수정까지 AI에게 요청하는 것은 비효율적일 수 있다. 간단한 변경은 직접 에디터에서 수정하는 것이 훨씬 빠르고 비용도 적게 든다.

또한 환경 설정과 관련된 문제에서는 AI가 기대만큼의 도움을 주지 못하기도 했다.

실제로 bun + vite 환경에서 개발을 진행하던 중 bun dev 실행이 멈추는 문제가 발생했는데, AI는 몇 시간 동안이나 해결 방법을 찾지 못했다. 결국 직접 내가 개입하여 lock 파일과 node_modules를 삭제하고 재설치하는 방식으로 간단하게 해결할 수 있었다.

이 경험을 통해 AI가 모든 것을 알고 있는 것은 아니며, 특히 실무적인 노하우나 경험 기반 해결에는 아직 한계가 있다는 점을 느꼈다.

또 하나 인상 깊었던 점은 요구사항을 작성하는 능력의 중요성이었다.

만약 프론트엔드에 대한 기본적인 이해가 전혀 없었다면, 요구사항 자체를 제대로 작성하지 못했을 것 같다.

실제로 실습 자료는 단계별로 이전에 작업한 코드를 다음 단계에서 다시 수정해보는 형식이었다. 그러다보니 상수들이 여러 곳에서 함께 사용되고 있었다.

이때 단순히 특정 한 부분만 보고 수정을 요청하면, 다른 영역까지 함께 변경되는 사이드 이펙트가 발생할 수도 있었을 것이다. 하지만 코드를 읽을 수 있는 사람이었다면, 이러한 사이드이팩트까지 고려해서 올바른 프롬프트를 작성할 수 있을 것이다. 너무 고수준의 프롬프트가 아닌 코드 레벨과 같은 저수준에서 수정해야할 부분을 정확히 파악하여 요구했을것이다.

2주간의 원정대 활동을 마치면서 느낀점

무엇보다도 가장 크게 느낀 점은, 정말 열정적인 사람들과 함께했다는 것이다.

우리는 거의 모든 회의를 함께 진행했다.

단순히 방향만 맞추는 수준이 아니라, 사용하는 단어 하나, 말투 하나까지도 집요하고 세세하게 고민했다. 때로는 의견이 부딪히며 치열하게 논쟁하기도 했지만, 그 과정 덕분에 결과물의 완성도는 점점 높아졌다.

돌이켜보면, 이렇게까지 팀원 전원이 깊게 관여해서 하나의 결과물을 만들어본 경험은 처음이었다.

이전의 팀 프로젝트들은 보통 역할을 나누고, 각자 맡은 부분을 개발한 뒤 마지막에 맞추는 방식이었다.

하지만 이번에는 모두가 하나의 결과물에 대해 전 과정에서 끝까지 책임을 지고, 함께 고민하며 만들어가는 방식이었다.

아마도 모두가 "정말 완벽한 공유회를 만들어보자"는 공감대가 있었기 때문에 가능했다고 생각한다.

이런 팀 활동이 나에겐 정말 값진 경험이었다.

단순히 결과물 하나를 만든 것이 아니라, 좋은 팀플이란 무엇인지, 그리고 그 안에서 나는 어떤 역할을 해야 하는지를 배울 수 있었다.

모든 현업이 동일하지는 않겠지만, 내가 현업 개발자가 되어 작은 팀 단위에서 하나의 서비스를 만들어 나가는 경험을 하게 될 수 있다는 생각을 한다. 그때를 대비해 좋은 기준과 경험을 얻었다는 점에서 이번 경험은 더 의미 있었다.

한편으로는, 정말 바빴다.

아직 적응 단계라고 생각했는데, 가용 시간의 대부분을 원정대 활동에 쏟아부었다.

아침 일찍 등교해서 회의를 하고, 밤 11시가 다 되어 캠퍼스를 나서는 날들이 이어졌다. (캠퍼스는 08시부터 23시까지만 이용 가능하다) 수면도 충분히 챙기지 못한 날들이 많았다.

결국 금요일 일정이 끝난 뒤에는 바로 집으로 돌아가서 아무것도 하지 못하고 쉬었다.

지금 1단계 초반이 이렇게나 바쁘면 앞으로의 2, 3, 4단계는 도대체 얼마나 바쁜 걸까…?

조금은 두렵기도 하지만, 동시에 그만큼 더 성장할 수 있을 것 같다는 기대도 든다.

마무리

벌써 우테코에서 한 달이라는 시간이 지났다.

돌이켜보면, 짧은 기간이었지만 정말 많은 성장을 할 수 있었던 시간이었다.

하드 스킬 측면에서도 분명 큰 성과가 있었다.

TDD와 테스트 코드에 대한 이해, 더 나은 코드를 작성하기 위한 다양한 설계 방식, 그리고 함수형 사고까지.. 개발자로서 한 단계 더 나아갈 수 있는 기반을 다졌다고 느낀다.

하지만 그보다 더 크게 남은 것은 소프트 스킬의 성장이다.

낯선 사람들과 자연스럽게 대화하는 방법, 학습한 내용을 되돌아보며 정리하는 회고의 습관, 페어 프로그래밍을 하며 내 생각을 더 명확히 다듬고 설득하는 능력, 회의에 주도적으로 참여하는 태도, 그리고 다른 사람에게 내용을 전달하는 발표 능력까지.

이 모든 변화는 단순히 지식을 쌓는 것을 넘어, 함께 일하는 사람으로서의 나를 성장시켜준 경험이었다.

앞으로 남아 있는 과정들 속에서 또 어떤 경험을 하게 될지, 그리고 그 과정 속에서 내가 얼마나 더 성장하게 될지 기대된다.