3개월 백엔드 인턴십 회고: 원칙을 현실에 적용하며 일하는 기준을 배웠다 @엔키화이트햇
3개월 백엔드 인턴십 회고: 원칙을 현실에 적용하며 일하는 기준을 배웠다 @엔키화이트햇
엔키화이트햇에서 3개월간 백엔드 인턴으로 일하면서, 기술 자체보다 더 크게 남은 건 “조직이 의사결정을 내리는 방식”과 “그 안에서 내가 할 수 있는 선택의 범위”였다. 대학교에서 배운 소프트웨어 공학의 원칙들은 틀리지 않았다. 다만 현장에서는 그 원칙이 그대로 적용되는지보다, 현재 상황에서 어떤 형태로 변환되어야 하는지가 더 중요한 문제였다.
이 글은 ‘무엇을 배웠다’의 나열보다, 현실적인 조직 안에서 원칙을 적용하려고 시도했던 과정에서 내가 어떤 기준으로 판단하고 행동했는지를 정리한 회고다.
목차
- 인턴을 시작하며 가졌던 기대와 목표
- 3개월 동안 수행한 주요 업무
- 이론적으로 중요하다고 생각했던 소프트웨어 공학론적 원칙
- 실제 조직 환경의 특성
- 현실 속에서 이상을 적용하려 한 방식
- 주니어로서 선택한 전략과 협업 방식
- 아쉬웠던 점과 한계 인식
- 다음 단계에서의 목표와 기준
- 마무리하며
인턴을 시작하며 가졌던 기대와 목표
인턴십을 시작할 때의 목표는 “기술 역량을 빠르게 성장시키자”에 가깝지 않았다. 오히려 아래 두 가지가 더 궁금했다.
- 조직은 어떤 기준으로 우선순위를 정하는가
- 그 기준이 산출물(변경/기능)을 어떤 형태로 만들게 하는가
소프트웨어 공학에서 배우는 이상적인 원칙들(요구사항 명확화, 문서화, 설계 기반 개발 등)은 ‘맞는 말’에 가깝다. 하지만 현실에서는 그 원칙이 항상 같은 해상도로 구현되지 않는 이유가 존재한다.
그래서 이번 인턴십의 목표는 결과물만 보는 것이 아니라, 결과가 나오기까지의 과정에서 반복되는 판단 패턴을 관찰하고 내 기준을 세우는 것이었다. 특히 변화가 동시에 들어오는 리듬(주간 스프린트, 데일리 스크럼)에서, 인턴도 주체적으로 할 수 있는 기여가 무엇인지 찾고 싶었다.
3개월 동안 수행한 주요 업무
3개월 동안 나는 백엔드 애플리케이션에서 특정 도메인 기능을 e2e로 개발하는 역할을 부여받았다.
기술 스택은 Nest.js, PostgreSQL, MikroORM이었고, 한 도메인 내부에서 아래 레이어를 전반적으로 구현했다.
- Controller
- Application(트랜잭션 처리, facade, orchestration)
- Domain
- Entity
- Repository
기술적으로 “완전히 새로운 것”을 많이 배웠다기보다, 더 크게 배운 건 협업 방식이었다. 백엔드 파트 내부 협업뿐 아니라, 개발 팀 내부의 합의 과정과 기획/콘텐츠/사업개발/디자인 등 역할군과의 협업에서, 서로 다른 언어를 맞추며 진행하는 감각이 쌓였다.
이론적으로 중요하다고 생각했던 소프트웨어 공학론적 원칙
인턴십 이전부터 중요하다고 생각했던 소프트웨어 공학론적 원칙은 크게 세 가지였다.
- 요구사항의 명확화: 모호함을 그대로 두면 구현의 비용이 뒤에서 폭발한다.
- 설계와 합의: 코드가 아니라 “의도”가 합의되어야 유지보수가 가능해진다.
- 기록(문서화)의 최소 단위: 모든 것을 기록하는 게 아니라, 나중에 다시 판단을 복원할 수 있을 만큼은 남겨야 한다.
다만 현장에서는 위 원칙이 “해야 한다/하지 말아야 한다”의 규칙이 아니라, 상황에 따라 강도를 조절해야 하는 도구에 가까웠다.
실제 조직 환경의 특성
현장에서는 일정과 우선순위, 그리고 팀 내부의 합의가 최우선 기준으로 작동했다.
- 요구사항이 완전히 정리된 상태에서 개발이 시작되지 않는 경우가 많았다.
- 문서화를 충분히 하기보다, 짧은 대화로 빠르게 정렬한 뒤 구현으로 넘어가는 편이 잦았다.
- 시스템 품질을 올리는 방향의 개선도 “옳음”만으로 진행되지 않고, 비용/리스크/시기 판단이 함께 움직였다.
특히 납기가 있는 신규 프로젝트에서는 기획/디자인/개발이 동시에 진행되며 변경이 겹치는 순간이 많았고, 그 자체가 쉽지 않았다. 그 환경에서 팀은 주간 스프린트로 계획을 세우고, 데일리 스크럼으로 매일 변경을 정렬하며 현실적으로 전진했다.
이 점이 불편하게 느껴졌던 순간도 있었지만, 시간이 지나면서 ‘이상이 무시된다’기보다, 조직이 선택한 현실적인 운영 방식이라는 해석이 더 정확하다는 걸 알게 됐다. 즉, 문제는 이상과 현실이 싸우는 게 아니라, 현실의 제약을 이해하지 못한 채 이상을 그대로 들이밀 때 발생했다.
다만 이런 접근이 이론적으로 항상 옳다고 생각하는 건 아니다. 특히 설계를 충분히 가다듬지 못한 채 진행하면, 뒤에서 비용이 커질 수 있다는 전제는 여전히 유효하다고 느꼈다. 그럼에도 납기와 변경이 겹치는 환경에서는 “짧은 주기의 합의와 피드백”이 장기적으로 더 좋은 방향으로 수렴할 수 있고, 그 흐름에 맞춰 팀이 계속 움직일 수 있게 만드는 일이 중요하다는 것도 함께 배웠다.
현실 속에서 이상을 적용하려 한 방식
내가 선택한 방법은 “원칙을 전면 도입하자”가 아니라, 현재 팀이 부담 없이 수용 가능한 형태로 원칙을 조금씩 도입하는 것이었다.
예를 들어, 문서화에 대해 나는 처음에는 “요구사항과 설계를 제대로 남겨야 한다”는 이상을 크게 가지고 있었다. 하지만 실제로는 아래 같은 형태가 더 현실적이었다.
- 긴 문서 대신, PR 본문에 “변경의 의도/영향 범위/롤백 방법”을 짧게 남기기
- 구조 변경이 큰 작업은, UML 대신 “핵심 흐름 다이어그램 1장” 또는 bullet 기반 흐름 정리로 공유하기
- 팀이 이미 쓰는 템플릿/규칙이 있다면 그 안에서 개선하기
여기서 중요한 건, 내가 옳다고 생각하는 방법을 증명하는 게 아니라 팀이 다음에도 같은 수준으로 반복할 수 있는 방식을 만드는 것이었다.
동시에, 동시 변경이 잦은 환경에서는 “문서화의 의지”보다 “문서화가 자동으로 굴러가게 만드는 장치”가 더 중요하다고 느꼈다. 그래서 MD(MDC, MDX 등) 기반의 프롬프트 템플릿을 컨벤션으로 합의하고, 생성형 LLM을 활용해 문서 초안을 빠르게 만드는 방식을 제안해 적용했다.
- 템플릿에는 “목적/배경, 결정 사항, 영향 범위, 검증/롤백, 미해결 질문” 같은 최소 항목만 포함
- LLM이 초안을 만들고, 작성자/리뷰어가 사실 관계와 표현을 검수해 확정
- 문서도 버전 관리의 대상(Git)으로 두고, 변경 이력 자체가 다음 합의의 근거가 되게 함
모의 사례: 동시 변경 속에서 “합의와 기록”으로 위험을 관리하기
아래는 실제 회사/서비스와 무관한 mock 사례다. 스프린트 중간에 변경이 동시에 들어오는 상황을 설명하기 위해 만든 예시다.
상황을 이렇게 가정해보자.
- 스프린트 중간에 요구사항이 바뀌고, 디자인도 함께 바뀌며, 개발은 병렬로 여러 작업이 진행되는 상태
- 이 상태에서 산출물을 계속 쌓으려면, “무엇이 최신인지/무엇이 결정됐는지/무엇이 아직 미정인지”를 빠르게 맞춰야 함
이 때 내가 우선순위를 둔 건, 복잡한 문서를 만드는 게 아니라 팀이 반복 가능한 최소 단위로 합의와 기록을 남기는 일이었다.
- 성공 기준을 먼저 한 문장으로 합의하기
- “이번 주에 무엇이 성공인지”를 한 문장으로 맞추고, 아직 합의되지 않은 부분은 질문 목록으로 분리
- 변경을 작은 단위로 쪼개 위험을 분산하기
- 한 번의 큰 변경보다, 리뷰/충돌/롤백이 가능한 크기로 나눠 작업 단위를 관리
- 기록을 ‘최신 상태에 맞춰 움직이는 형태’로 만들기
- 합의한 MD 기반 프롬프트 템플릿으로 LLM이 초안을 빠르게 만들고, 사람이 사실 검증 후 확정
- 문서 변경도 버전 관리로 추적해 “무엇이 언제 왜 바뀌었는지”가 다음 합의를 돕게 함
이 경험을 통해, 좋은 산출물은 깔끔한 구조만으로 결정되지 않는다는 걸 배웠다. 좋은 산출물은 조직의 제약(일정/리스크/합의)을 고려해도 팀이 지속적으로 쌓아갈 수 있는 형태여야 했다.
주니어로서 선택한 전략과 협업 방식
인턴으로서 가장 크게 신경 쓴 건, “의견을 내는 것”과 “팀의 신뢰를 해치지 않는 것” 사이의 균형이었다.
내가 가진 권한과 영향력의 범위를 인식하면, 협업 전략도 달라진다.
- 내가 바꿀 수 있는 것은 “시스템 전반의 구조, 설계”보다 “대화에서의 불확실성 제거”인 경우가 많았다.
- 제안은 ‘정답 제시’보다 ‘선택지 + 트레이드오프’ 형태가 수용성이 높았다.
- 일정/우선순위로 보류되는 상황은 자연스러운 일로 받아들이되, 기록을 남겨 다음 논의를 쉽게 만들었다.
코드 리뷰에서도 같은 태도를 유지했다.
- 방어적으로 설명하기보다, 의도를 먼저 공유하고 피드백을 받기
- “왜 이렇게 했는지”를 말하는 것만큼 “대안이 무엇인지”를 함께 제시하기
- 내 PR을 빨리 머지하는 것보다, 팀의 기준을 이해하고 맞추는 것을 우선하기
아쉬웠던 점과 한계 인식
아쉬움이 없는 건 아니다.
- 더 구조적으로 개선할 수 있었던 부분을 ‘다음’으로 미룬 채 끝난 작업이 있었다.
- 내가 제안한 방식이 완전히 정착되기 전에 인턴십이 끝나, 개선의 지속성을 확인하기 어려웠다.
하지만 동시에 인턴이라는 역할에서 감당할 수 있는 영향력의 한계를 명확히 배웠다. 조직의 변화는 옳은 주장만으로 일어나지 않고, 타이밍·합의·비용 구조와 함께 움직인다. 그래서 이번 회고의 결론은 “더 세게 주장했어야 했다”가 아니라, “주어진 역할에서 더 효과적인 방식으로 움직였는가”로 바뀌었다.
다음 단계에서의 목표와 기준
다음 단계에서 내가 갖고 싶은 목표는 기술 스택 자체보다, 판단 기준을 더 정교하게 만드는 것이다.
- 요구사항이 모호하면, 구현 전에 ‘성공 기준’을 먼저 합의한다
- 개선은 ‘완벽한 도입’보다 ‘반복 가능한 최소 단위’로 제안한다
- 설계/문서화는 분량이 아니라 “나중에 판단을 복원할 수 있는 기록”을 목표로 한다
- 협업에서는 정답을 밀기보다, 트레이드오프를 공유하고 팀의 선택을 돕는다
- 변경은 항상 롤백·관측 가능성을 포함해 “안전한 작업”으로 만든다
마무리하며
3개월 동안 엔키화이트햇에서 일하며, "원칙"은 정답이 아니라 상황에 맞게 형태를 바꿔 쓰는 도구라는 걸 배웠다. 납기와 동시 변경 속에서도 설계·합의·기록을 포기하지 않되, 팀이 반복할 수 있는 최소 단위로 바꾸는 일이 가장 중요했다. 앞으로는 기능을 끝까지 완결하는 힘에 더해, 변화가 빠른 환경에서도 안전하게 결정하고 전달하는 협업 방식을 계속 다듬어가려 한다. 이번 인턴십은 내가 "어떻게 일할 것인가"에 대한 기준을 한 단계 더 또렷하게 만들어 준 시간이었다.