참여 계기
모의고사 1회에서 인터페이스 우선 설계, 추상화 레벨, 전역 상태 기준 등 실질적인 인사이트를 얻었어서, 2회에도 자연스럽게 신청하게 되었습니다. 특히 이번에는 저번에 강의해주신 한재엽님과 더불어 문동욱님의 이야기를 직접 들을 수 있다는 점이 더욱 기대되었습니다.
배운 내용
인터페이스 우선 설계
코드를 먼저 읽으면 기존 구조를 따라가느라 어느새 그 구조를 합리화하게 됩니다. 반면 UI를 먼저 보고 "이 화면을 가장 예측하기 쉽게 표현하는 인터페이스가 무엇인가"를 먼저 고민하면, 코드를 작성하기 전에 더 나은 구조를 상상할 수 있습니다.
상태를 어디에 어떻게 둘지는 구현의 영역입니다. 먼저 UI와 1:1로 매핑되는 인터페이스를 설계하고, 특정 기능을 수정하고 싶을 때 수정 위치가 바로 보이는 구조를 만드는 것이 목표입니다.
AI가 생각한 인터페이스대로 코드를 작성해주는 시대인 만큼, 이상적인 인터페이스를 설계하는 역량이 점점 더 중요해지고 있습니다.
저번 모의고사에서도 같은 내용을 배웠지만, 이번 모의고사를 진행하면서 이러한 부분이 잘 반영되지 않았던 것 같습니다.
이유를 생각해보니 이번 모의고사에는 구현이 모두 이루어져있고, 방대한 코드가 페이지 컴포넌트에 다 작성되어있어 이것을 먼저 읽고 이해하려고 한 게 원인이었던 것 같습니다.
이제부터라도 UI를 보고 적합한 인터페이스를 먼저 설계하는 연습을 해봐야겠다고 생각했습니다.
예측 가능한 코드
우리는 코드를 읽는 것이 아니라 예측합니다. 뇌의 RAM은 작아서 모든 정보를 즉시 소화하지 못하고, 경험에서 쌓인 패턴을 기반으로 "이거 다음엔 이게 나올것이다"라고 예측하며 읽습니다. 예측이 빗나가는 순간 코드는 이해하기 어려워지고, 잘못 사용될 가능성도 높아집니다.
500줄짜리 HTML은 위에서 아래로 읽으며 UI가 그려지지만, JS는 길어질수록 눈과 머리의 매핑이 끊깁니다. 예측 가능한 코드가 곧 이해하기 쉬운 코드입니다.
추상화 레벨
과한 추상화는 중요한 정보를 내부에 숨기고 코드를 오히려 복잡하게 만듭니다. 페이지 컴포넌트를 지나치게 정리하면 깔끔해 보여도 UI와의 매핑이 끊깁니다. 컴포넌트가 많아졌을 때 비로소 책임에 맞게 나누면 됩니다. 무조건 추상화하거나 무조건 드러내는 것, 모두 지양해야 합니다.
근거 있는 의사결정
정답인 코드는 없습니다. 다만 내가 내린 의사결정을 논리적으로 설명할 수 있어야 합니다. 리액트를 쓰는 이유가 "팀 컨벤션이라서"라면, 리액트를 왜 쓰는지 한 번도 생각해보지 않은 것입니다. AI로 생산성이 좋아졌다고 말하려면 생산성이 무엇인지부터 설명할 수 있어야 합니다.
코드를 사용하거나 도구를 선택하면서 이름을 정하면서까지도 근거를 생각해보자고 다짐하게 되었습니다.
마무리
이번 모의고사를 통해 "코드를 잘 짠다"는 것이 결국 읽는 사람이 예측하기 쉬운 코드를 짜는 것이라는 점을 다시 한번 깊이 새겼습니다. 폴더 구조나 패턴보다 코드의 흐름과 예측 가능성이 훨씬 더 중요합니다.
좋은 인사이트를 공유해주신 한재엽님, 문동욱님과 오종택님께 감사드리며, 배운 내용을 다시 새겨서 지난 모의고사부터 다시 풀어보는 시간을 가져보려고 합니다.
