짧은 인턴을 마치고...

들어가며

부트캠프를 수료하고 나서, 실제 개발 현장을 경험할 수 있는 한 달간의 인턴 기회가 생겼다. 부트캠프에서는 요구사항이 명확히 주어지고 팀원들과 함께 처음부터 만들어가는 구조였다면, 실무는 달랐다. 기존 코드베이스를 파악하고, 외부 시스템과 연동하고, 직접 본 적 없는 사람들과 소통하며 결과물을 만들어야 했다. 기대했던 경험을 모두 얻진 못했지만, 그 과정에서 오히려 더 본질적인 것들을 배웠다.

---

1주차 : 낯선 코드베이스에서 맥락을 읽는 법

첫 배정 업무는 커머스 서비스의 기존 코드 분석이었다. Postman으로 API 테스트를 진행하며 전체 데이터 흐름을 파악했고, 코드 구조가 실제 서비스 로직과 어떻게 연결되어 있는지 직접 추적했다.

 

분석 과정에서 한 가지 공백을 발견했다. 카테고리 구조가 아직 정의되어 있지 않은 상태였다. 기획 없이 개발을 진행할 수 없다고 판단해, 직접 카테고리 체계를 설계하고 스프레드시트로 정리한 뒤 컨펌을 받아 진행했다. 개발자가 구현만 담당하는 게 아니라, 요구사항이 불명확한 상황에서 스스로 맥락을 정의하고 진전시켜야 할 때도 있다는 걸 처음 체감한 순간이었다.

 

코드 작업으로는 Shopify 기반의 Liquid·JS 코드를 수정해 설계한 카테고리 구조를 반영했고, 기존 코드를 리팩토링하면서 두 가지 원칙을 적용했다.

• 단일 책임 원칙 (SRP) : 하나의 메서드가 하나의 역할만 하도록 분리해, 변경 영향 범위를 좁혔다.
• 캡슐화 : 외부에 노출이 불필요한 내부 구현을 숨겨, 의존성이 불필요하게 퍼지는 것을 차단했다.

이론으로 배웠던 원칙들을 실제 코드에 적용하는 작업은 생각보다 훨씬 판단이 많이 필요한 일이었다.

2~4주차 : 외부 API 연동 백엔드 개발

중반부터는 두 개의 외부 플랫폼 API를 연동하는 백엔드 개발을 맡았다. 부트캠프에서는 외부 API를 직접 다룬 경험이 없었기 때문에, 공식 문서를 꼼꼼히 읽고 Postman으로 동작을 검증하면서 연동 방식을 파악하는 것부터 시작했다.

API 명세서 : 구현 전에 먼저 정의한다

혼자 백엔드를 담당하는 구조였기 때문에 API 명세도 직접 처음부터 작성했다. 총 29개의 API를 노션으로 상세하게 정리했고, 작성 과정에서 의식적으로 프론트엔드 관점을 먼저 고려했다.

• 어떤 데이터를 응답에 포함시켜야 하는가
• 에러 케이스는 어떤 형태로 내려줘야 하는가
• 필드명은 사용하는 쪽 입장에서 직관적인가

명세는 마지막 주까지 피드백을 받으며 수정했다. 이 과정에서 명확한 문서가 단순히 "기록"이 아니라, 협업 속도와 커뮤니케이션 비용을 직접 결정한다는 걸 체감했다.

구현한 주요 기능

API	주요 처리 내용
토큰 저장 시 유저 정보 DB 저장	외부 API 3개 호출로 사용자 정보·스토어명·활성 상품 수 조회 후 저장
스토어 목록 조회	토큰 만료일 포함 응답 처리
상품 조회	외부 API 연동 및 응답 가공

중복 제거 : ArgumentResolver + 커스텀 어노테이션 적용

구현 과정에서 기존 코드의 구조적 문제를 발견했다. 토큰 추출 로직이 컨트롤러의 모든 메서드에 동일하게 반복되고 있었다. 단순 중복인 것처럼 보이지만, 이 구조에서는 추출 방식이 바뀌면 모든 메서드를 일일이 수정해야 했다.

 

수정 방식보다 구조를 바꾸는 게 맞다고 판단해, Spring MVC의 ArgumentResolver를 활용하는 방향으로 개선했다. 컨트롤러 메서드 파라미터에 @EbayToken 어노테이션만 붙이면 토큰 추출이 자동으로 처리되도록 하고, 이 ArgumentResolver를 Spring MVC에 등록해 모든 컨트롤러에서 재사용할 수 있게 했다.

// 개선 전: 토큰 추출 로직이 모든 메서드에 반복
String token = request.getHeader("Authorization").replace("Bearer ", "");

// 개선 후: 어노테이션만 붙이면 Spring MVC가 자동으로 처리
public ResponseEntity<?> getItems(@EbayToken String token) { ... }

 

변경 이후에는 토큰 처리 로직이 한 곳에서만 관리되기 때문에, 이후 수정이 생기더라도 ArgumentResolver 하나만 고치면 된다.

외부 클라이언트 소통

혼자 백엔드를 담당하다 보니, 직접 외부 클라이언트와 소통할 일도 생겼다. 계정 인증 이슈나 API 계정 발급 요청 등을 전화·메시지·메일로 처리했다. 업무 맥락에서 외부와 소통하는 것이 처음이라 처음에는 어색했지만, 기술적인 상황을 상대방이 이해할 수 있는 언어로 전달하는 연습이 됐다.

돌아보며 : 한 달이 남긴 것

기대했던 것과 달랐던 점, 그래서 배운 것

코드 리뷰와 함께하는 협업을 기대했지만, 구조상 혼자 판단해야 하는 상황이 많았다. 처음에는 답답했지만, 오히려 그 과정이 스스로 기준을 세우는 연습이 됐다. '이 코드가 좋은가?'를 스스로 판단해야 했기 때문에, 단순 구현보다 설계 이유를 더 깊이 고민하게 됐다.

프론트엔드와 처음 협업하면서 인증 토큰 처리를 내부에서 해줬어야 하는 부분을 초기에 놓쳤다. 경험 부족에서 비롯된 실수였지만, 이후 API를 설계할 때 "호출하는 쪽이 신경 써야 하는 것을 최소화하자"는 원칙을 의식적으로 적용하게 된 계기가 됐다.

실무에서 다시 확인한 것들

외부 API 연동은 문서 읽기에서 시작된다. 잘 모르는 시스템을 다룰 때 가장 먼저 해야 할 일은 공식 문서를 제대로 읽고, 직접 요청을 날려보며 동작을 확인하는 것이다. 이 순서가 익숙해지면 어떤 외부 시스템이든 처음의 막막함이 줄어든다.

문서화는 커뮤니케이션 비용을 결정한다. 명세가 명확할수록 질문이 줄고, 구현 속도가 빨라진다. 29개의 API 명세를 작성하면서 좋은 문서는 팀의 맥락을 공유하는 가장 효율적인 방법이라는 걸 느꼈다.

리팩토링은 코드를 고치는 게 아니라 구조를 바꾸는 것이다. 단순히 중복을 제거하는 것을 넘어, 변경이 생겼을 때 영향 범위를 최소화하는 구조를 고민하는 것이 진짜 리팩토링이라는 걸 실제 코드를 통해 배웠다.

마치며

한 달은 짧았다. 그렇지만 실제 서비스 코드를 분석하고, 외부 API를 직접 연동하고, 프론트엔드와 명세를 주고받으며 다듬어가는 경험은 부트캠프와는 결이 달랐다.

 

가장 크게 남은 질문은 이것이다. "내가 짠 코드는 유지보수하기 좋은 코드인가?" 혼자 작성하고 검증받지 못한 코드를 보면서, 코드 리뷰가 단순한 오류 수정이 아니라 더 나은 설계를 함께 만드는 과정이라는 걸 더 절실하게 이해하게 됐다. 다음에는 그 부분을 적극적으로 만들어가고 싶다.