🧐 참여 계기

토스에서 처음으로 Frontend Fundamentals 모의고사가 개최됐다. 실제 채용 과정에서 출제된 과제를 직접 풀어보고, 이어서 해설 강의까지 들을 수 있는 흔치 않은 기회였다.

얼마 전 토스의 과제를 풀어본 경험이 있었기에 해설이 더욱 궁금했다. 과제를 제출한 뒤 개인적으로 리팩토링까지 해봤지만, “이 문제는 어떤 방식으로 해결하는 게 가장 좋았을까?” 하는 고민은 쉽게 풀리지 않아 계속 마음에 남아 있었다.

그런 만큼 해설 강의를 통해 그 의문들이 해소되길 바라는 기대가 컸고, 채용 과제의 해설을 공식적으로 들을 수 있는 경우는 거의 없기 때문에 모집 공고를 보는 순간 참여하고 싶다는 생각이 들었다.

프로그램에 대해서는 Frontend Fundamentals 모의고사 (25.11)에서 자세히 확인할 수 있다.

👩‍💻 과제 풀이 과정에서 느낀점

풀이 과정

과제를 받아보니 얼마 전 제출했던 토스 채용 과제와 동일했다.

이전에 리팩토링을 했을 때는 과제를 제출했을 때 아쉬웠던 점을 보완하는 데 집중했다면, 이번 풀이에서는 근본적인 요구사항에 대해 더 깊이 고민하면서 작성하니 이전과는 또 다른 코드가 나와서 비교해보는 재미가 있었다.

과제를 풀면서 고민했던 것들은 주로 이런 것들이었다.

• 컴포넌트 간에 공유해야 하는 상태를 어떻게 관리할까?
• 코드를 어떤 기준으로 분리해야 할까?
• 지금 구조가 좋지 않다면 그건 이유가 뭘까?
• 이 코드가 확장성이 있을까?
• 코드를 어디에 위치시킬까?

이런 고민들을 하나씩 해결해가면서 코드를 작성했고, 그 과정에서 나름의 답을 내놓게 되었다.

좋은 코드라는 추상적인 기준보다는 나쁜 코드가 항상 더 명확하게 보이는 것 같여서 완벽한 정답을 찾기보다는, 문제가 될 수 있는 것들을 피하는 방향으로 코드를 작성해봤다. 중복된 로직, 파악하기 어려운 코드, 테스트하기 어려운 구조 같은 것들을 고려해봤다.

다양한 관점으로 배우기

과제를 제출하고 다른 분들의 PR과 Discussion을 훑어 보았다. 풀이가 굉장히 다양했는데 좋은 코드를 작성하기 위한 기준은 다들 비슷하지만, 그 목적을 달성하기 위한 방식이 정말 다르기 때문인 것 같다.

코드에서 각자 다른 해답을 가지고 있다는 것이 확연히 드러났고, PR 마다 깨달음을 얻는 것들이 하나씩 있어서 보는 재미가 있었다.

나와 다르게 작성한 코드를 보고 어떤 방식으로 문제를 해결하는 게 더 좋을지에 대해서 고민하면서 내가 작성한 코드를 개선해보기도 했다.

리뷰를 달아주신 분도 계셔서 내가 작성한 코드에 대해 한번 더 생각할 수 있는 좋은 기회가 되었다.

관성적으로 "이렇게 하면 이런 부분이 개선이 될 거야"라고 생각했던 것들도 남에게 설명해야 할 때는 보다 더 객관적으로 혹은 논리적으로 타당한가에 대해서 점검하게 된다.

그럴 땐 나의 코드를 나의 의견의 반대의 시점에서, 비판적인 시각에서 볼 수 있게 되어서 다른 시야가 열리는 것 같아 좋은 것 같다.

🪄 해설을 듣고 느낀점

해설 방송에서는 토스 프론트 챕터의 재엽님과 종택님이 라이브 코딩을 진행하셨다. 요구사항을 어떻게 분석하고, 어떻게 문제를 정의하고, 어떤 절차로 문제를 해결해나가는지 직접 볼 수 있었다.

많은 것을 배웠지만 개인적으로 정리해보고 싶은 느낀점에 대해서 몇 가지 얘기해보려고 한다.

길 잃지 않기

라이브 코딩 중에 문제에 해결해나가시는 방식을 보면서 배운 점이 많았다.

그동안에는 요구사항을 보면 구현을 빠르게 해야겠다는 생각에 사로 잡혀서 나무를 마구 심고 나서 숲이 어떻게 만들어졌나 볼 때가 많았던 것 같다.

의식적으로 그러지 않아야겠다 생각하지만, 시간 제한이 있으면 당장 돌아가는 코드를 만들기 위해 바빠졌다. 그치만 경험했듯 그렇게 만들어진 숲은 대규모 공사란 큰 비용을 들여 다시 나무들을 재배치를 해야한다.

이렇게 방향을 잃지 않기 위해서 먼저 구현의 결과물을 구상해보고 출발하는 것이 길을 잃지 않게 도움을 주는 방법임을 알게 됐다.

컴포넌트나 훅의 인터페이스를 어떻게 설계할지 먼저 고민을 하게 되면 what에 집중할 수도 있고, 그러면 자연스레 선언적인 코드를 작성할 수도 있게 될 것 같다.

그동안 내가 했던 절차로 인터페이스를 설계하면 목적을 쉽게 이해하기 어려운 코드가 작성되기 쉬워지는 것 같다.

어떻게 잘 분리할 것인가

많은 고민이 분리라는 문제에서 시작되는 것 같다.

컴포넌트가 점점 커지면서 분리를 할 것인가 말 것인가에 대해 고민해야 하고, 컴포넌트를 분리하기 시작하니 컴포넌트 간에 상태를 공유하는 방법에 대해 고민해야 한다.

또 이렇게 분리한 컴포넌트를 어디에 둘 것인가에 대한 고민도 필요하다. 이에 대해 생각하면서 분리라는 비용이 적지 않구나를 생각하게 됐다.

그렇기에 잘 분리하는 것이 중요한 것 같다 생각하는데, 해설을 통해서 이 잘을 어떻게 하면 달성할 것인가에 대한 방법을 알아갈 수 있어서 좋았다.

어떤 부분을 추상화 할 것인지, 분리한 컴포넌트를 파일에서 분리할지 말지, 인터페이스를 어떻게 설계할지 다양한 문제들에 있어 어떤 방식을 채택할 것인가에 대한 기준을 얻을 수 있었다.

미래의 재사용성에 집중해서 그동안 분리를 쉽게, 많이 했었는데 그 결정이 문제를 더 복잡하게 만들었던 것 같다.

책임 단위로 추상화하면 재사용은 따라오는 것이라는 말을 해주셨듯 관성적으로 "이건 재사용될 거야 추상화해야지"라는 이유로 잘못된 추상화를 하지 않도록 주의해야 할 것 같다.

읽기 쉬운 코드를 작성하는 방법

해설 코드를 보면서 이해하기 쉽다는 감상을 많이 받았다.

요구사항이 많지 않은 모바일 화면이긴 했지만, 코드와 UI가 쉽게 매칭되어서 컴포넌트의 구조가 분명하게 눈에 보였다.

코드만 보더라도 어떤 UI인지 쉽게 예측이 가능했다.

요구사항이 간단하기에 가능하지 않을까라는 생각도 해볼 수 있지만 추상화 레벨이 들쑥날쑥 하거나, 컴포넌트의 이름이 역할을 분명히 전달하지 않는다거나, 해당 컴포넌트가 알지 않아도 되는 코드가 복잡하게 섞여 있다거나, 응집도가 떨어진다면 이해하기 쉽지 않은 컴포넌트가 만들어지는 것 같다.

코드를 보고 다양한 사람들이 이해하기 쉬운 코드일 수록 간단 명료하고 친절해야 한다는 것을 다시 한번 더 느꼈다. 그러기 위해서는 누구나 이해할 수 있는 보편적인 방식을 사용하는 것이 중요하다는 것을 알 수 있었다.

🚪 마무리

개발을 하면서 시야를 넓히는 일이 참 중요한 것 같다는 생각이 많이 든다.

목표한 구현을 완성하고, 좋은 성능을 낸다는 것은 쉽게 달성 여부를 검증할 수 있지만, 코드의 품질이라는 것은 그렇지 않기 때문에 코드를 작성하면서 내가 좋지 않은 코드를 생산하고 있다는 것을 느끼기가 어렵다.

그래서 이런 활동을 통해 다른 사람들의 코드를 많이 읽어보고, 의견을 듣고 말하는 과정이 많이 필요한 것 같다. 그렇지 않다보면 어느 순간 기술 부채를 늘려가고 있는 자신을 발견하게 된다.

이번 활동을 통해 그동안 작성해왔던 나의 코드가 불만족스럽게 느껴지는 것을 보면 조금 더 시야가 확장된 것이 아닐까 생각해본다.

며칠되지 않은 짧은 기간에 많은 것을 배울 수 있는 밀도 있던 시간이었다. 해설을 통해 배운 것들을 내 코드에 적용해보면서 다시 리팩토링을 하면 더 좋은 경험이 될 것 같다.