학생에서 개발자로: 로또 구현부터 레거시 개선까지, 서버의 흐름을 배우다 (새 탭에서 열림)
서버 개발은 복잡해 보이지만, 설계 이유를 질문하고 검증하는 과정을 거치면 막연함을 줄일 수 있다는 것이 글의 핵심 주장입니다. 카카오의 기술 온보딩은 TDD·객체지향 구현, 레거시 인수 테스트, 리팩터링을 단계적으로 수행하며 유지보수 가능한 구조와 안전한 변경 능력을 길렀습니다. 결국 좋은 개발자는 코드를 작성하는 데 그치지 않고, 설계·테스트·협업·AI 활용의 기준을 스스로 세우는 사람이라는 결론입니다. ## 기술 온보딩의 목표와 구성 - 온보딩은 총 3단계로 진행되었습니다. 1. TDD와 OOP 기반 기능 구현 2. 레거시 코드에 대한 인수 테스트 작성 3. 테스트로 보호된 레거시 코드 리팩터링 - 정답을 전달하기보다 다음과 같은 질문을 반복하며 설계의 근거를 고민하게 했습니다. - 왜 이렇게 설계했는가? - 이 책임은 정말 해당 객체가 가져야 하는가? - 이 테스트는 무엇을 보호하는가? - 목표는 유지보수 가능한 구조 설계, 레거시 분석 및 안전한 개선, 협업과 AI를 포함한 책임 있는 개발 역량을 기르는 것이었습니다. - 서버뿐 아니라 FE, Android, iOS 직군도 참여했으며, 기술 스택과 관계없이 좋은 엔지니어링의 기준은 공유될 수 있다는 점을 강조했습니다. ## 질문과 협업으로 서버 개발의 막연함 줄이기 - 트래픽, 동시성, 확장성, 데이터베이스 설계처럼 추상적으로 느껴지는 주제를 실제 구현과 리뷰를 통해 구체화했습니다. - 매일 데일리 미팅에서 트러블슈팅을 공유하고, 페어 프로그래밍으로 설계를 논의하며, PR 리뷰에서 구현 이유를 설명했습니다. - 이를 통해 개발은 개인의 코딩 능력만으로 완성되는 일이 아니라는 점을 체감했습니다. - 코드의 동작 여부보다 스스로 설계를 설명하고 변경의 영향을 예측하는 능력을 중요하게 다뤘습니다. ## 로또 게임 구현: TDD와 객체지향 설계 - 첫 번째 미션은 로또 가격, 자동·수동 발급, 당첨 통계를 구현하는 과제였습니다. - 다음과 같은 제약 조건이 설계 개선을 유도했습니다. - 들여쓰기 깊이 1단계 유지 - 메서드 10라인 이하 - 원시값 포장과 일급 컬렉션 사용 - `else` 사용을 줄이고 Early Return 활용 - TDD 방식으로 테스트를 먼저 작성해 요구사항과 설계를 점검했습니다. ### 랜덤 로직의 테스트 가능성 확보 - 랜덤 번호 생성은 실행마다 결과가 달라 테스트가 어려웠습니다. - 이를 해결하기 위해: - 번호 생성 전략을 인터페이스로 추상화하고 - 생성 전략을 외부에서 주입받으며 - 테스트 전용 Generator를 별도로 구현했습니다. - 그 결과 테스트에서 생성 값을 통제할 수 있었고, 구현체에 대한 결합도도 낮아졌습니다. - TDD는 단순히 테스트를 추가하는 방식이 아니라, 테스트 가능한 구조를 설계하게 만드는 도구로 작용했습니다. ### 값 객체와 캐싱에 대한 고민 - 같은 값을 가진 객체를 매번 새로 생성할지, 재사용할지 고민하며 객체의 정체성과 값의 동일성을 구분했습니다. - 1부터 45까지의 로또 번호처럼 값의 범위가 제한된 경우 캐싱 전략을 검토할 수 있었습니다. - 이 미션을 통해 기능 구현보다 객체의 책임, 생성 방식, 재사용 가능성 등 설계 기준을 고민하게 되었습니다. ## 인수 테스트: 레거시를 안전하게 이해하기 - 두 번째 미션에서는 실제 서비스 수준의 레거시 코드를 바로 수정하지 않고, 먼저 인수 테스트를 작성했습니다. - 테스트가 보호해야 할 대상은 다음과 같았습니다. - 사용자의 행동 - 시스템의 반환 결과 - 외부에서 관찰 가능한 상태 변화 - 단순히 성공 여부만 확인하는 것이 아니라, 결과가 정확한지 검증하는 Strong Assertion 전략을 적용했습니다. - Cucumber 기반 BDD를 사용해 비개발자도 이해할 수 있는 시나리오 형태로 테스트를 구성했습니다. - 테스트를 개발자만의 코드가 아니라 팀 전체가 공유하는 실행 가능한 명세로 바라보았습니다. ### 운영 환경과 테스트 환경 맞추기 - “내 컴퓨터에서는 동작한다”는 문제를 줄이기 위해 Production Parity를 적용했습니다. - 구체적으로: - H2 대신 운영과 같은 PostgreSQL 사용 - Docker 기반으로 실행 환경 통일 - Gradle Task를 이용한 테스트 자동화 - 환경 차이로 인한 테스트 결과의 불일치를 줄이고, 누구나 동일한 조건에서 테스트를 실행할 수 있게 했습니다. ### 테스트 데이터 격리 - 테스트 간 데이터 의존성을 제거하기 위해 다음 전략을 사용했습니다. - 외래 키 관계를 고려한 역순 삭제 - `TRUNCATE ... CASCADE` - 공통 Cleanup 유틸리티 작성 - 모든 테스트가 초기화된 동일한 상태에서 시작하도록 보장해 테스트의 재현성과 안정성을 높였습니다. - 중요한 것은 특정 도구를 사용하는 것보다 상황에 맞는 데이터 격리 방법을 선택하는 판단 기준이라고 설명합니다. ## 레거시 리팩터링: 구조와 동작의 분리 - 세 번째 미션의 핵심은 레거시 코드를 단순히 “클린 코드”로 바꾸는 것이 아니라, 안전한 변경의 기준을 세우는 것이었습니다. - 가장 중요한 원칙은 구조 변경과 동작 변경을 분리하는 것입니다. - 구조를 개선할 때는 기존 동작을 유지 - 동작을 변경할 때는 구조 개선과 섞지 않기 - 이렇게 변경 목적을 분리하면 코드 리뷰와 테스트를 통해 변경 범위를 명확히 검증할 수 있습니다. - 의도하지 않은 동작 변화가 발생하면 리뷰에서 이를 찾아내고, 변경을 통제하는 능력을 기를 수 있었습니다. ## AI와 협업할 때의 검증 범위 - 리팩터링 과정에서 AI를 활용해 넓은 범위의 코드 개선을 빠르게 시도했습니다. - 그러나 AI에게 한 번에 큰 범위의 변경을 요청하면 수정량이 커져 검증이 어려워지는 문제가 발생했습니다. - 따라서 AI의 제안을 그대로 수용하기보다 변경 범위를 작게 나누고, 각 변경을 테스트와 리뷰로 확인하는 방식이 필요하다는 교훈을 얻었습니다. - AI는 개발자를 대신하는 도구가 아니라, 개발자가 책임 있게 검토하고 통제해야 하는 협업 도구로 다뤄졌습니다. 실무에서는 기능 구현 전에 책임과 설계 이유를 설명할 수 있는지 확인하고, 레거시 코드는 먼저 외부 동작을 보호하는 테스트를 마련하는 것이 좋습니다. 이후 구조 변경과 동작 변경을 분리해 작은 단위로 개선하며, AI를 사용할 때도 변경 범위를 제한하고 반드시 테스트와 리뷰로 검증하는 접근이 안전합니다.