인프런 커뮤니티 질문&답변

안녕하세요 코딩님 고민이 많으실 것 같습니다.

강의를 끝까지 듣고 완벽하게 준비해서 시작해야 할지, 아니면 부족하더라도 지금 당장 부딪혀야 할지 망설여지는 그 마음, 개발자라면 누구나 한 번쯤 겪는 과정이기에 깊이 공감합니다. 하지만 결론부터 말씀드리면 Express Part 2나 타 강의의 완강을 기다리지 마시고 지금 당장 첫 번째 프로젝트를 시작하시는 것이 훨씬 효율적입니다. 강의는 수영을 배우기 위한 이론서와 같아서 아무리 완벽하게 이해했다고 느껴도 막상 물에 들어가면 숨 쉬는 것조차 버거운 것이 당연하며, 코딩님께서 걱정하시는 '배운 내용이 기억나지 않는 현상'은 10년 차 시니어 개발자에게도 일상적인 일이니 그 부분은 전혀 염려하지 않으셔도 됩니다. 오히려 프로젝트를 진행하며 마주치는 에러와 비효율적인 코드들이야말로 코딩님이 왜 자료구조를 공부해야 하고, 왜 특정 알고리즘이 필요한지를 뼈저리게 느끼게 해주는 가장 훌륭한 스승이 될 것입니다.

특히 첫 번째 프로젝트로 계획하신 바닐라 JS와 로우 쿼리(Raw Query)를 활용한 개발은 요즘처럼 프레임워크가 모든 것을 추상화해주는 시대에 아키텍트 관점에서 볼 때 '기본기(Fundamental)'를 다질 수 있는 가장 훌륭한 선택인데, 이는 React나 Nest.js 같은 도구들이 결국 자바스크립트와 HTTP 프로토콜, 그리고 SQL 위에서 돌아가는 것이기에 직접 DOM(Document Object Model)을 조작해보며 브라우저의 렌더링 과정인 Reflow와 Repaint가 성능에 미치는 영향을 체감해보고, ORM 없이 직접 SQL을 작성하며 인덱스(Index)가 쿼리 성능에 어떤 차이를 만드는지, 조인(Join) 연산이 데이터베이스 부하에 어떻게 작용하는지를 경험해보는 것은 훗날 대규모 트래픽을 처리할 때 남들과 차별화되는 강력한 무기가 되기 때문입니다.

더 나아가 두 번째, 세 번째 프로젝트를 진행하시면서 Docker나 RabbitMQ, Redis 같은 다양한 인프라 및 미들웨어 도구들을 필연적으로 마주하게 될 텐데, 이때 단순히 '남들이 쓰니까' 혹은 '강의에서 시키니까' 사용하는 것과 그 원리를 이해하고 쓰는 것은 천지 차이입니다. 개발을 하다 보면 "도대체 왜 Docker 컨테이너 간 통신이 안 되는 거지?" 혹은 "RabbitMQ에 쌓인 메시지가 왜 순서대로 처리되지 않지?"라는 근본적인 의문이 생기는 순간이 반드시 오는데, 이 의문을 해결하고 넘어갈 수 있느냐는 전적으로 운영체제의 네트워크 네임스페이스나 프로세스 스케줄링, 자료구조의 큐(Queue)와 같은 CS 기반 지식의 유무에 달려 있습니다. 만약 이러한 베이스가 없다면 단순히 블로그 코드를 복사해서 해결하는 '도구 사용자'에 머물게 되고, 어떤 상황에 어떤 기술을 적재적소에 배치해야 하는지 판단하는 아키텍트의 시야는 가질 수 없게 됩니다.

이후 Next.js와 Nest.js, 그리고 AWS 인프라를 본격적으로 도입하실 때에도 단순히 최신 기술을 사용했다는 것에 만족하지 마시고 시스템 아키텍처 관점에서 깊이 있는 고민을 병행하셔야 하는데, 예를 들어 대규모 트래픽을 가정했을 때 Node.js의 싱글 스레드 이벤트 루프(Event Loop) 모델이 CPU 집약적인 작업에서 어떤 취약점을 가지는지 이해하고 이를 해결하기 위해 워커 스레드(Worker Threads)나 메시지 큐(Message Queue) 같은 아키텍처 패턴을 도입해보거나, 여러 사용자가 동시에 재고를 차감하는 동시성 이슈(Concurrency Issue)가 발생했을 때 데이터베이스의 트랜잭션 격리 수준(Isolation Level)이나 비관적/낙관적 락(Lock)을 활용해 데이터의 무결성을 보장하는 방법 등을 고민해보는 것이 진짜 실력입니다. 이때 Sentry나 Datadog 같은 모니터링 툴 또한 단순히 에러 로그를 수집하는 것을 넘어, 메모리 릭(Memory Leak)이나 슬로우 쿼리(Slow Query)를 추적하여 운영체제 레벨의 리소스 관리와 네트워크 TCP/IP 핸드셰이크 과정에서의 지연 시간을 최적화하는 데 활용되어야 합니다.

결국 이 모든 과정에서 가장 근본이 되는 것은 자료구조, 알고리즘, 운영체제, 네트워크와 같은 CS 기초 체력이며, 이는 단순히 코딩 테스트를 통과하기 위한 암기식 공부가 아니라 "왜 이 상황에서 배열(Array) 대신 해시 테이블(Hash Table)을 사용하여 데이터 조회 성능을 O(n)에서 O(1)로 최적화했는가?", "왜 프로세스(Process) 대신 스레드(Thread)를 사용하여 컨텍스트 스위칭(Context Switching) 비용을 줄였는가?"와 같은 기술적인 의사결정의 근거를 마련하기 위함입니다. 프레임워크나 라이브러리는 3년, 5년이 지나면 바뀌거나 사라질 수 있지만 이러한 컴퓨터 과학의 원리는 변하지 않으며 시니어 개발자가 되었을 때 시스템의 안정성과 확장성을 담보하는 가장 강력한 무기가 됩니다.

마지막으로 최근의 개발 환경에서 빼놓을 수 없는 AI 활용 역량 또한 결국 이러한 근본적인 시야가 갖춰졌을 때 비로소 빛을 발하게 됩니다. 지금은 AI를 통해 어떤 제품이든 순식간에 뚝딱 만들어낼 수 있는 시대이지만, 그렇게 생성된 코드의 품질을 관리하고 전체적인 아키텍처의 흐름 속에 자연스럽게 녹여내는 역량은 오직 시스템의 전반적인 메커니즘을 꿰뚫어 볼 수 있는 사람만이 가능합니다. AI가 짜준 코드가 왜 성능 병목을 일으키는지, 혹은 보안상 어떤 허점이 있는지 판단하지 못한 채 결과물만 내놓는다면 그것은 모래 위에 성을 쌓는 것과 같으므로, AI를 단순히 코드를 대신 써주는 도구가 아니라 자신의 설계 철학을 실현하는 강력한 보조 수단으로 다루기 위해서라도 더욱 근본적인 학습에 집중하시기를 권장합니다.

그러니 코딩님, 지금 당장 완벽한 코드를 짜지 못할까 봐, 혹은 보안에 취약한 코드를 만들까 봐 느끼는 부담감 때문에 강의 수강으로 준비 시간을 늘리기보다는, 과감하게 첫 번째 프로젝트의 첫 줄을 작성해 보시기를 권장합니다. 처음에는 스파게티 코드와 N+1 문제로 가득 찬 쿼리, 보안에 취약한 인증 로직을 작성하게 될지라도, 그것이 시스템에 어떤 악영향을 미치는지 직접 겪어보고 깨져보는 경험이 없다면 리팩토링의 필요성도, 클린 아키텍처의 가치도 결코 깨달을 수 없기 때문입니다. 현업에서 인정받는 개발자는 처음부터 완벽한 코드를 짜는 사람이 아니라, 엉망인 코드에서 출발했더라도 탄탄한 CS 지식과 AI 활용 능력을 바탕으로 병목을 찾아내고, 논리적인 근거를 가지고 코드를 개선해 나가며 결국에는 견고한 시스템을 만들어내는 사람이라는 점을 꼭 기억해 주셨으면 합니다.

참고해주세요!