컴포넌트를 이런식으로 나누면 응집도가 깨지지 않나요?
props에 이 속성들은 결합도를 높히는 것 같아요.
이 부분에서 인지 부조화가 일어나는 것 같아요

프론트엔드 개발자라면 한 번쯤은 들어봤을 이야기다.
하지만, 정작 나는 이런 말들을 정말 ‘내 것’으로 이해하고 있을까?

코드 리뷰나 아키텍처 논의 자리에서 자주 오르내리는 추상적인 개념들.
다양한 자료를 통해 접했지만 막상 실무에서는 손에 잘 안 잡히는 개념들.

이번 글에서는, 나처럼 한 번이라도 같은 생각을 해본 프론트엔드 개발자라면, 꼭 한번 참여했으면 하는 프로그램을 소개하려 한다.

파란회사스러운 컨텍(?)

어느 날 날아온 광고 문자

어느 날 토스에서 광고 문자가 한 통 왔다.
“토스 프론트엔드 개발자들의 구체적인 사고 과정과 코드 작성 방법이 궁금하지 않으신가요?”

이 문구를 보고 참을 수 있는 프론트엔드 개발자가 있을까?
나 역시 마찬가지였다. 별다른 고민 없이 바로 신청 버튼을 눌렀다.

작년에 진행된 1기에 대해 조금은 알고 있었기에, 신청을 하고 나서 곧바로 관련 자료들을 찾아보기 시작했다.
!!그런데 이번 2기는 확실히 달랐다.
작년은 주 1회 온라인 미팅, 총 4회로 진행됐다면, 이번에는 무려 2주 동안 매일 오프라인으로 진행되는 것이었다.
“2주 동안 아크플레이스에 출근하듯 갈 수 있다고?”
생각만으로도 가슴이 벅차올랐다.

두근거리는 마음으로 하루하루를 보내던 중, 인터뷰 안내 메일이 도착했다.

구성은 라이브 코딩 30분 + 이를 기반으로 한 인터뷰 1시간.
라이브 코딩이라니… 단어만 들어도 긴장감이 확 밀려왔다.
게다가 며칠 뒤 바로 진행된다고 하니, 마음이 바빠졌다.

그래도 마음을 다잡았다.
“어차피 긴장은 피할 수 없으니, 최대한 침착하게. 아쉬움 없이 보고 오자.”
그렇게 목표를 세우고 준비를 시작했다.

말하면서.. 코딩하라고요?

인터뷰는 시작부터 상상도 못한 방식으로 진행됬다.
"혼자있는 것 처럼 말하면서 코딩해주세요"

순간 당황했다.
코드를 치면서 중얼거리듯 생각을 다 꺼내야 한다니… 준비해온 건 하나도 없는데.
그냥 의식의 흐름대로, 머릿속에 떠오르는 대로 말하고 손을 움직였다.

지금 돌이켜보면, 그때 나는 문제를 풀어나간다기보다는 작은 문제 하나를 깊게, 더 깊게 파고들면서 과제를 진행했던 것 같다.
큰 그림을 설명하거나 멋있게 구조를 잡은 건 전혀 없었다.
그저 눈앞에 걸리는 부분을 붙잡고, 그걸 어떻게든 이해하려고 계속 말하면서 코드를 써 내려갔다.

망했다.
시간도 짧은데 작은 목표 하나조차 제대로 마무리하지 못하고 끝나버렸다.
라이브 코딩이 끝난 순간, 스스로도 부족하다는 걸 인정할 수밖에 없었다.

그래서일까. 오히려 마음이 편해졌다.
“어차피 떨어져도 이상할 게 없지.”
그 생각이 드니 긴장이 조금 풀렸다.
그 뒤로 이어진 인터뷰는 의외로 더 담담하고 차분하게 임할 수 있었다.

그렇게 인터뷰를 끝내고, 마음을 내려놓은 지 얼마 지나지 않아 메일 한 통이 도착했다.

“Frontend Accelerator 2기로 합류하시게 된 것을 진심으로 축하드립니다!”

그렇게 나는 2주 동안 아크플레이스에 갈 수 있는 기회를 얻게 되었다.

생각과 코드 사이의 간극을 마주하다

첫 주는 ‘한 번에 하나’를 몸에 새기는 시간이었다.
아침엔 오늘의 한 가지를 정하고, 낮엔 10분 타이머로 잘게 쪼개 집중했다.
끝나면 짧게 회고. 저녁엔 모여 공유. 리듬은 단순했지만, 효과는 생각보다 컸다.

재밌었던 건 10분의 감각이다.
짧다고 방심하면 허무하게 날아가고, 하나만 제대로 붙잡으면 꽤 멀리 간다.
결국 중요한 건 시간의 길이가 아니라 집중의 대상이었다.

회고를 반복하면서 작은 패턴들이 보이기 시작했다.

• 10분 안에 끝나지 않으면, 처음 쪼갠 기준이 애매했다.
• 결과보다 과정을 적어야 다음 10분이 달라졌다.

단순한 시간 관리가 아니라, 집중 → 실행 → 회고 → 조정의 루프를 하루에 여러 번 돌리며,
“무엇을 해야 할지 몰라서 멍해지는 시간”이 점점 줄었다.
작은 단위에서 성장을 설계하는 법을, 몸으로 배웠다.

행동 패턴을 훈련하다

왜 행동 패턴일까

둘째 주의 키워드는 한마디로 “생각을 행동으로”이었다.
첫 주의 리듬을 바탕으로, 이제는 그 리듬으로 문제를 바라보는 틀을 만들었다.
코드가 잘 안 풀릴 때 스스로에게 물었다.

• 이건 화면에서 처리할 일인가, 아니면 정책/규칙 레이어로 분리해야 하나?
• 모듈화가 필요한 순간은 중복 때문이 아니라 책임 경계가 흐릴 때 아닌가?
• “깔끔해서요” 대신 왜 더 나은지 설명할 수 있는가?

리듬만 좋아도 손이 덜 헤맨다. 하지만 “왜 이렇게 해야 하는가”를 말로 설명하지 못하면 다시 제자리다. 그래서 둘째 주는, 감(感)으로 하던 판단을 패턴과 기준의 언어로 바꾸는 훈련에 집중했다.

• 모듈화는 중복 때문이 아니라 책임 경계가 흐릴 때
• 상태의 위치는 편한 곳이 아니라 데이터의 수명/변경 주기
• “깔끔해서요” 대신 왜 더 안전하고 이해 가능한지를 말할 수 있게

시행착오를 통해 배우는 패턴

낮엔 10분 사이클로 실전 적용, 저녁엔 서로의 코드를 펼쳐놓고 말로 풀었다.
흘러갈 깨달음에 이름이 붙고, 다음 날 바로 써먹을 공용 패턴북으로 쌓였다.

가장 크게 남은 건 요구사항 단위로 계층을 나누는 기준이다.
예전엔 UI·API·로직이 뒤엉켜 “그냥 기능 구현”처럼 보였는데,
이제는 “이건 화면에서, 저건 정책/규칙 레이어에서”라고 경계가 보인다.
경계가 생기니 앞으로의 혼란을 예측하고 막는 수단(분리·명명·검증)을 고를 수 있게 됐다.
코드는 단순히 돌아가는 것을 넘어 혼란을 줄이고 사고를 정리하는 도구로 바뀌었다.

결국 남은 것

둘째 주를 지나며 얻은 건 새로운 문법이나 기술 스택이 아니었다.
대신, 시행착오 → 신호 포착 → 패턴 언어화 → 패턴북 축적이라는 흐름 자체를 몸에 새겼다.

앞으로도 코드를 짜다 보면 또다시 길을 잃을 것이다.
하지만 이제는 최소한, 길을 잃었다는 신호를 알아차릴 언어와 습관을 손에 넣었다.
그리고 이게야말로 두 주 동안 가장 값진 배움이었다.

코드를 넘어, 사고를 훈련하다

손보다 시선이 먼저 움직이게 된 게 이번의 수확이다.
문제를 보면 잠깐 멈추고 묻는다.

이건 화면 상태인가, 바뀔 수 있는 규칙인가?

반복될 패턴이라면, 지금 언어로 만들 수 있는가?

이 질문 몇 개로 접근이 달라졌다.
조건문으로 덮던 문제는 규칙 분리가 먼저 떠오르고,
중복을 봐도 “리팩토링”이 아니라 내가 놓친 신호로 보인다.

사고의 전환이 만든 변화

재미있는 건, 사고가 바뀌니 행동도 달라졌다는 거다.
예전 같으면 조건문 몇 개로 퉁 쳤을 문제를, 이제는 “이건 규칙으로 빼야지”라는 생각부터 떠올랐다.
중복된 코드를 보더라도 “리팩토링 해야겠다”가 아니라, “아, 이건 내가 놓친 신호구나” 하고 받아들이게 됐다.

하루 회고에서 쌓인 메모들이 어느새 팀의 언어로 확장되는 걸 보면서,
“아, 코드는 단순히 실행되는 결과물이 아니라 사고를 정리하는 도구구나” 하는 걸 실감했다.

결국 이번 경험은 새로운 기술 스택을 배운 게 아니라, 문제를 대하는 태도를 바꾼 훈련이었다.
이제는 복잡한 문제를 만나도, 괜히 머리 싸매지 않고 더 단순하고 직관적인 길을 찾을 수 있을 것 같다.

앞으로의 개발은 분명 지금보다 훨씬 복잡해질 거다.
하지만 그럴수록 화려한 테크닉보다, 이렇게 몸에 밴 사고의 프레임이 더 큰 무기가 될 거라는 확신이 생겼다.

마치며

프론트엔드 개발자가 항상 가지던 의문들.
누가 정답을 건네주진 않지만, 리듬과 언어, 기준을 손에 넣으면 스스로 납득 가능한 답을 만들 수 있다.
비슷한 고민이 있다면, 기회가 올 때 꼭 참여해보길.
물음표가 작업과 결정 속에서 조용히 느낌표로 바뀌는 순간을 볼 수 있다.