인턴 6개월, 일하는 방식의 변화

들어가며

안녕하세요, 힐링페이퍼에서 미용의료 병원향 SaaS 제품인 KOS의 백엔드를 개발하고 있는 이진우(Eden)입니다.

저는 6개월의 인턴 기간을 거쳐 지난 4월 정규직으로 합류했는데요. 저 역시 입사 전 "이 팀에서 얼마나 성장할 수 있을까?", "어떤 동료들과 일하게 될까?" 같은 고민을 오래 했습니다. 비슷한 고민으로 채용 공고를 들여다보고 계신 분들께 조금이나마 도움이 되길 바라며 이 글을 씁니다.

이 글에서는 "제가 무엇을 만들었는가"에 대한 이야기가 아닌, KOS 팀에서 일하면서 제 일하는 방식이 어떻게 바뀌었는지, 그리고 그 변화를 팀이 어떻게 이끌어냈는지에 대한 내용을 다루고자 합니다. 일하는 과정에서 오갔던 질문과 설계 논의에서 배운 것들에 초점을 맞췄습니다.

입사 전, 그리고 인턴 초기

채용 공고에서 제 시선을 사로잡은 문구가 있었습니다.

"KOS팀과 6개월에서 1년 정도를 함께하면서 그 어떤 조직보다 밀도 높은 경험을 하실 거라 믿기 때문입니다."

그때의 저는 뭔가 부족하다는 건 알았지만, 정작 그게 뭔지는 몰랐습니다. 그걸 알려면 직접 부딪혀보는 수밖에 없다고 생각했고요. 그래서 제가 찾던 것은, 빠르게 시행착오를 겪고 그만큼 빠르게 배울 수 있는 환경, 곧 가파른 성장 곡선을 그릴 수 있는 '밀도 높은 경험'이었습니다. 그렇게 입사 전 스스로 목표 하나를 세웠습니다. "이 6개월이 지나면, 나는 분명히 성장해 있어야 한다.”

기대만큼 걱정도 컸고, 그 걱정은 시작과 동시에 현실이 됐는데요. 미용의료 시장과 병원 운영에 대한 이해가 전무했고, 파악해야 할 맥락이 매우 많았습니다. 태스크 하나를 완료하는 데에도 예상보다 오래 걸렸고, 일정을 다시 조정하는 일도 있었습니다. '내원객이 병원을 방문한 순간부터 귀가할 때까지의 여정이 어떻게 이어지는가' 같은 도메인 지식부터, 여러 서비스가 계약을 통해 서로를 호출하는 흐름까지, 익혀야 할 낯선 개념이 겹겹이 쌓여 있었습니다. 하루하루가 벅찼고, '내가 지금 잘 하고 있는 걸까' 하는 불안도 자주 따라왔습니다.

힘들었지만, 돌이켜보면 제가 찾던 '밀도 높은 경험'을 할 수 있는 환경이었습니다. 부족한 점을 명확히 파악하고, 빠르게 시도하고, 피드백을 받고, 다시 개선하는 사이클을 반복할 수 있었으니까요. 지금부터는 그 과정을 거치며 제 일하는 방식이 실제로 어떻게 바뀌어 갔는지, 네 가지 이야기로 풀어보려 합니다.

1. 혼자 코드로 답하기보다, 팀과 함께 답을 맞춰가는 법을 배우다

인턴 초기의 저는 설계를 혼자 결론 내고 코드부터 쓰는 습관이 있었습니다. 마음 한켠에 '개발자는 코드로 말한다'는 생각이 있었거든요. 일단 동작하는 코드로 보여주고, 이야기를 나누는 편이 더 개발자스럽다고 생각했고, 그래서 나름의 확신이 서면 팀과 맞춰보는 단계를 건너뛰고 구현부터 들어가곤 했습니다.

한번은 일본 병원을 위한 내원객 검색 기능을 맡았습니다. 내원객 이름을 표기뿐 아니라 '발음'으로도 찾을 수 있게 하는 기능이었습니다. 일본어 이름은 같은 표기라도 읽는 법이 여러 가지인 데다, 정작 찾는 사람은 그 이름을 어떻게 읽는지 모르거나 한자를 일일이 떠올려 입력하기 번거로워하는 경우가 많습니다. 그래서 표기 검색만으로는 놓치는 사람이 생겨, 익숙한 발음으로도 찾을 수 있어야 했죠. 이를 위해 이름의 발음을 일정한 규칙으로 표준화한 '검색용 값'을 따로 만들어 저장하고, 그 값으로도 매칭되게 했습니다.

고민은 그 값을 어디에 둘지였습니다. 저는 그 값을 자연스럽게 도메인 모델의 속성으로 넣고, 그에 맞춰 저장소(Repository) 인터페이스까지 확장했습니다. 이때 저는 도메인 모델과 데이터 모델의 경계를 명확히 인지하지 못했습니다. 이 값 역시 결국 '내원객'에 관한 정보이니 도메인 지식의 일부이고, 그러니 도메인 모델이 당연히 알고 있어야 한다고 생각했죠. 그렇게 나름의 근거가 있다 믿었기에, 팀과 방향을 맞춰보기 전에 곧장 PR부터 올렸습니다.

"이 검색용 필드를 도메인 모델이 알아야 할 이유가 있을까요? 저장, 수정, 조회 모두 데이터 접근 계층에서만 관리하는 방향은 어떻게 생각하세요?"

처음엔 이 질문을 단순히 '코드를 어디에 두느냐'를 묻는 거라고 생각했습니다. 그런데 리뷰를 주고받다 보니, 질문의 본질은 달랐습니다. 이 필드가 정말 도메인 모델이 알아야 할 정보인지, 아니면 검색을 위한 데이터 계층의 관심사일 뿐인지를 묻고 있었죠. 생각해보면 검색하려고 저장하는 값을 굳이 도메인 모델이 알게 할 이유는 없었습니다. 게다가 이건 도메인 모델의 생김새를 바꾸는 판단이라, 저 혼자 결론 내릴 문제도 아니었고요. 그때의 저는 이런 판단마저 팀과 맞춰보기 전에 혼자 내리곤 했었습니다.

이 경험은 '개발자는 코드로 말한다'던 제 생각을 다시 돌아보게 했습니다. 그때 제가 얻은 건 '혼자 정하지 말자'는 깨달음만이 아니었습니다. 어떤 데이터가 도메인에 속하고 어떤 건 데이터 계층에서 다루면 되는지, 팀이 제품을 바라보는 시각까지 곁에서 배웠습니다. 도메인 모델은 개발자가 코드로 혼자 완성하는 게 아니라, 그 도메인을 함께 다루는 사람들과 언어를 맞춰가며 다듬는 작업이었습니다.

그래서 저는 습관을 바꿨습니다. 코드를 쓰기 전에 "이 방향이 맞을까요?"를 먼저 묻고, 작업에 대한 설계를 팀과 공유해 피드백을 받은 뒤에 구현에 들어갑니다.

돌아보면 리뷰가 느렸던 진짜 이유는, PR 전에 맞췄어야 할 방향을 리뷰에서야 뒤늦게 맞추고 있었기 때문입니다. 방향도 없이 코드부터 올리니, PR은 세부를 다듬는 자리가 아니라 설계를 원점에서 다시 논의하는 자리가 됐고, 크게 갈아엎고 다시 올리기를 몇 번씩 반복해야 했습니다.

KOS 팀의 코드 리뷰는 "코드가 잘 동작하는가"를 넘어 “왜 그렇게 설계했는가”를 함께 고민하는 자리입니다. 개발 지식을 습득하는 데는 강의나 스터디, 책 등 여러 가지 방법이 있겠지만, 저에게 가장 효과적이었던 건 팀원들의 리뷰 코멘트 하나하나였습니다.

2. "안다"는 착각에서 벗어나, "왜"를 이해하는 단계로

두 번째는 솔직히 꺼내기 조금 부끄러운 기억인데요. 저는 팀원이 정리해둔 설계를 읽고, 이대로 만들 수 있겠고 전체적인 구조도 그럴듯해 보이면 곧장 구현에 들어가곤 했습니다.

그러다 병원이 예약을 생성하는 규칙을 만드는 에픽을 맡게 되었습니다. 병원에서 예약 하나를 만드는 건 생각보다 훨씬 복잡합니다. 내원객에게 '이 시간에 예약이 가능해요'라고 보여주려면, 그 시간에 의사/장비/시술실 같은 한정된 자원이 모두 비어 있어야 합니다. 게다가 어떤 병원은 상담/시술/관리를 정해진 순서로 보고 싶어하고, 다른 병원은 그것들을 같은 시간에 한꺼번에 보고 싶어합니다. 초진인지 재진인지, 상담이 필요한지에 따라 필요한 자원도 달라지고요. 이렇게 병원마다 제각각인 예약 방식을 표현할 수 있어야 했는데, 조건들이 많아지면서 고려해야 할 정책도 많았습니다.

이렇게 고려할 게 많은 에픽이다 보니, 곧장 구현에 들어가기보다 먼저 엔지니어들과 설계를 공유하는 자리를 가졌습니다. 그런데 그 자리에서 제가 에픽에 대한 이해가 부족했다는 것을 깨달았습니다. "이건 왜 이렇게 하기로 한 거예요?", "다른 방식은 안 되나요?" 같은 질문이 들어왔는데, 답을 제대로 못 했습니다. 제가 할 수 있었던 말은 이 에픽이 "자원을 첨예하게 관리하기 위한 것이다" 정도의 모호하고 추상적인 문장이었습니다.

당시의 저는 그 설계를 '읽기'만 했지 '이해'한 게 아니었다고 생각합니다. 무엇을 만드는지(What)는 알았지만, 왜 그렇게 만드는지(Why)는 몰랐기 때문입니다. What은 만들고자 하는 대상을 알려줄 뿐, 그걸 구현하며 부딪히는 크고 작은 선택까지 정해주진 않습니다. 그 선택의 기준이 바로 Why이고, 우리가 같은 문제를 풀고 있는지도 여기서 갈립니다. Why가 흐릿하다면 애매한 대목마다 각자 나름의 이유를 채워 넣게 되고, 결국 저마다 조금씩 다른 문제를 풀게 됩니다. 겉으로는 같은 걸 만드는 것 같아도 저마다 그리는 그림이 다르니, 그 뒤로 아무리 이야기를 나눠도 논의가 겉돌 수밖에 없었습니다.

그렇게 한 번 막히고 나서, 저는 에픽을 시작할 때 스스로 먼저 답해볼 질문들을 정리해보았습니다.

1. 이 문제를 왜 풀어야 하는가?
2. 지금은 왜 이 문제를 해결할 수 없는가?
3. 이 문제를 위해 우리가 내린 해결책은 무엇인가?
4. 그 해결책으로 문제를 어떻게 해결할 수 있는가?

특히 앞의 두 가지, '이 문제를 왜 풀어야 하는가?'와 '지금은 왜 이 문제를 해결할 수 없는가?'는 코드를 작성하기 전에, 반드시 팀원들과 같은 답을 갖고 있어야 하는 질문이라고 생각합니다. 제가 내린 답이 팀원과 다르면, 아직 방향이 맞지 않았다는 뜻이었습니다.

그 뒤로 습관이 하나 생겼습니다. 에픽을 받으면 "이 기능이 없으면 대체 무슨 일이 벌어질까?"를 딱 한 문장으로 먼저 써보는 겁니다. 이 문장이 안 써지면, 아직 제가 Why를 모른다는 뜻이었습니다. 팀원에게 물을 때도 막연히 "이거 왜 해요?"가 아니라, 제 나름대로 먼저 답을 정리해보고 "제가 이렇게 이해했는데, 맞을까요?"로 묻게 됐습니다.

여기에 팀원에게 배운 'XY Problem'이 힘을 보탰습니다. 누가 "Y를 어떻게 하죠?"라고 물을 때, 정작 풀어야 할 진짜 문제는 그 뒤에 숨은 X인 경우가 많다는 이야기입니다. 해결책(Y)을 미리 정해두고 방법만 물으면, X를 곧장 푸는 더 나은 길을 놓치기 쉽습니다. 그래서 질문을 꺼내기 전에 "내가 지금 표면(Y)을 묻고 있나, 본질(X)을 묻고 있나"를 한 번 더 생각하게 됐습니다. 이 관점은 코드 리뷰만이 아니라 제품 기획이든 기술 결정이든, 거의 모든 자리에서 통했습니다.

지금 제가 스스로에게 던지는 기준은 "내가 처음부터 혼자 설계했어도, 같은 결론에 닿았을까?" 여기에 "그렇다"고 답할 수 있을 때, 비로소 이 문제를 이해했다고 말할 수 있는 것 같습니다.

3. 빠른 실행의 함정, 불확실성을 먼저 꺼내기

팀원들이 제 강점으로 자주 꼽아준 것은 "주도적으로 움직이는 실행력"이었습니다. 낯설거나 불확실한 문제라도 일단 부딪혀보며 시작하는 편이었거든요. 그런데 이 강점이 오히려 발목을 잡을 때가 있었습니다. 빠르게 결론을 내리는 만큼, 그 결론을 흔드는 신호를 외면하기 쉬웠기 때문입니다.

한번은 일정을 잡으면서 구현 시간에 대해서만 계산하고, 이를 테스트하거나 검증하는 데 쓸 여유는 거의 남겨두지 않았습니다. 빨리 만들어내고 싶은 마음이 앞섰기 때문입니다. 그때 한 팀원이 "이든, 이 일정 가능한 거 맞죠?"라고 지나가듯 말했는데, 저는 인사치레로 흘려듣고 계획대로 밀고 나갔습니다. 제 계획이 맞다는 확신이 강했던 터라, 그 경고를 진지하게 듣지 않았던 겁니다.

그 우려는 얼마 지나지 않아 현실이 되었고, 확인하지 않고 지나친 전제 하나가 뒤늦게 드러나, 일정은 밀렸으며 예정에 없던 작업을 더 해야 했습니다.

한번 '이렇게 하면 되겠다'고 마음을 굳히고 나면 그 판단을 흔드는 신호가 좀처럼 귀에 들어오지 않는다는 걸, 이 일을 겪고서야 알았습니다. 그래서 결론을 내리기 전에 스스로 점검하는 습관을 들이기로 했습니다. 이러한 고민을 팀원과 이야기 나누었는데, '스위스 치즈 모델'을 알려줬습니다. 구멍 난 치즈도 여러 장 포개두면 한 장이 놓친 구멍을 다른 장이 막아준다는 개념입니다. 빠른 속도는 그대로 두되, 그 개념을 빌려 저만의 안전망을 만들었습니다.

• 걸리는 신호는 그 자리에서 확인하기: 누가 조금이라도 우려를 내비치면 넘기지 않고 바로 물어봅니다. "혹시 제가 놓친 게 있을까요?", "이 일정은 타이트해 보이시나요?"
• 답할 수 없는 것을 나열해보기: 일정을 잡기 전에, '이 API가 이미 있는지 확인하였는가', '이 개념을 내가 잘 설명할 수 있는가'처럼 제가 답을 할 수 없는 것들을 적어봅니다. 많아질수록 일정 추정이 틀렸을 가능성이 높았습니다. 모르는 걸 다 알 순 없겠지만, 내가 뭘 모르고 있는지는 셀 수 있으니까요.
• 시작 전에 실패 미리 그려보기: 계획을 세운 뒤 '결국 이 일이 실패했다'고 가정하고, 그 이유를 되짚어 적어봅니다. '무엇이 잘못될까?'를 미리 물으면 왠지 다 괜찮을 것 같아 잘 떠오르지 않는데, '이미 실패했다'고 정해두면 제가 자신 없던 부분, 아직 잘 모르던 지점이 자연스럽게 실패 원인으로 떠올랐습니다.

이런 실수를 안 하는 개발자는 없다고 생각합니다. 중요한 건 같은 실수를 반복하지 않는 겁니다. 그래서 한 번 겪은 실수는 나만의 체크리스트로 남겨두고 활용하고 있습니다. 이렇게 공개되는 글에 제 실패까지 적는 이유도, 부끄럽지만 이렇게 꺼내놓고 나면 오히려 더 깊이 새겨진다고 생각하기 때문입니다.

4. 책임의 위치를 정하기

마지막은 "이 책임을 누가 지는가"에 대한 이야기입니다.

KOS의 통계 차트는 사용자가 날짜를 일/주/월 단위로 묶어서 볼 수 있습니다. 날짜별 집계는 서버가 맡고, 집계 쿼리 결과에는 실제 데이터가 있는 날짜만 행으로 담기고, 없는 날짜는 결과에서 제외됩니다.

그래서 비어 있는 구간까지 채워 연속된 축으로 만드는 일이 남았습니다. 처음엔 이 빈 구간 채우기를 클라이언트가 맡도록 합의했습니다. 어차피 화면에 그리는 건 클라이언트니, 그쪽에 두는 게 자연스럽다고 판단했습니다.

그런데 차트마다 채우는 방식이 조금씩 달랐습니다. 어떤 차트는 데이터가 없는 날짜를 건너뛰어 축이 중간에 끊겼고, 어떤 차트는 주 단위로 묶는 경계가 달라 같은 기간인데도 칸 수가 안 맞았습니다.

파고들어 보니, 이 축을 만드는 곳이 서버와 클라이언트 두 군데였던 게 문제였습니다. 두 곳이 조금씩 다르게 만드니 어긋날 수밖에 없었죠.

그래서 차트에 필요한 데이터를 만드는 책임을 서버로 모았습니다. 서버가 날짜를 단위별로 묶고 빈 구간까지 채운 축을 완성해 내려주고, 클라이언트는 그대로 그리기만 하면 됩니다. 날짜 축을 서버가 단일 출처(SSOT)로 책임지는 겁니다.

그 뒤로 지속적으로 발생하던 차트마다 날짜가 어긋나는 문제는 나오지 않았습니다. 책임이 한 곳으로 모이니 서버와 클라이언트가 각자 할 일에만 집중할 수 있었고, 손볼 곳도 줄었습니다. 이제는 같은 자리에서 버그가 반복되면, 코드를 더 파기 전에 '이 일을 누가 맡고 있나'부터 확인하는 습관이 생기게 되었습니다.

정규직 전환 과정에서

인턴이 끝나갈 무렵, 저 역시 앞으로의 길을 두고 여러 고민을 했습니다. 그럼에도 KOS에 남기로 한 이유는 명확했는데요. 가장 큰 이유는 성장 속도였습니다. 백엔드 엔지니어에게 백엔드뿐 아니라 DevOps, 데이터베이스까지 폭넓은 책임을 주면서도, 언제든 조언을 구할 수 있는 동료들이 있었습니다. 단순히 "어떻게 구현할까"가 아니라 "왜 이걸 만드는가"를 고민하는, 엔지니어이면서 메이커인 사람들에게서 배울 수 있는 환경이기도 했습니다.

정규직 전환 과정에서 들은 피드백 중 한 문장이 특히 인상 깊었습니다. 제가 지금 당장 완성형 엔지니어여서가 아니라, "성장하는 방식"을 보여줬기 때문이라는 이야기였습니다.

팀이 저에게서 봤다고 한 신호들은 이랬습니다. 모르는 것을 숨기지 않되 먼저 찾아보고 정리한 뒤 질문하고, 피드백을 방어적으로 받지 않고 실제 행동으로 옮기고, 시키지 않아도 개선할 지점을 찾아 움직인다는 것이었습니다.

동시에 팀은 제가 아직 부족한 지점도 분명히 짚어줬는데요. 문제를 스스로 깊게 정의하거나 설계 대안을 주도적으로 제시하는 데는 아직 거리가 있고, 설계 논의에서 생각이 있어도 먼저 꺼내지 않는 경향이 있으며, 생각을 나열하기보다 구조로 정리하는 연습이 필요하다는 것이었습니다.

저 역시 더 가파른 성장 곡선을 그리고 싶었습니다. 팀의 시선과 제가 지향하는 것이 맞닿아 있다고 느꼈고, 그래서 이곳에 남고 싶었습니다.

앞으로 이루고 싶은 것

입사 전 저는 "이 6개월이 지나면 분명히 성장해 있어야 한다"고 다짐했습니다. 돌아보면 그때보다 문제를 바라보고 팀과 함께 풀어가는 방식이 분명히 달라졌습니다. 그리고 정규직으로 전환된 지금은, 주어진 문제를 푸는 데서 나아가 스스로 문제를 정의하는 개발자로 가는 출발선에 섰다는 생각이 듭니다.

• 스스로 문제를 정의하는 개발자로: 아직은 주어진 문제를 성실히 푸는 수준입니다. 앞으로는 문제를 직접 정의하고 설계 대안을 먼저 테이블에 올리는 사람이 되고 싶습니다. 확신이 100%가 아니어도, 초안을 먼저 꺼내 팀과 함께 발전시키는 흐름을 만들고, 정답을 맞히는 것보다 다양한 관점을 테이블에 올리는 게 더 중요하다는 걸 이제는 알게 되었습니다.
• 예측 가능한 사람으로: 구현 시간만이 아니라 테스트, 리뷰, 운영 확인까지 포함한 현실적인 일정을 잡고, 그 안에서 안정적으로 마무리하려 합니다. "이든에게 이 범위는 믿고 맡길 수 있다"는 신뢰는 결국 예측 가능한 결과에서 시작된다고 생각합니다.
• 팀과 챕터에 기여하는 사람으로: 제가 겪은 부채와 장애 경험을 개인의 학습으로만 끝내지 않고, "이런 문제가 있었고 이렇게 줄이자"고 챕터 차원에서 기준을 함께 세우는 데 보태고 싶습니다.

KOS 합류를 고민하는 분들께

이런 분들이라면 KOS와 잘 맞을 것 같아요.

• 빠르게 성장하고 싶은 분. 안정적인 환경보다 가파른 성장 곡선을 원하신다면, 책임은 크지만 그만큼 배우는 것도 많습니다.
• 제품을 만드는 일에 관심이 있는 분. 기능 구현을 넘어 "왜"를 고민하고 싶은 분이라면 배울 게 많습니다.
• 본질을 파고드는 것을 즐기는 분. 주어진 것을 그대로 받아들이기보다 한 단계 더 깊이 생각하는 일을 즐기신다면 잘 맞습니다.

도전적인 환경인 것은 분명합니다. 높은 기준이 있고, 빠르게 적응해야 하며, 스스로 문제를 해결해나가는 자율성이 필요합니다. 하지만 6개월 동안의 제 변화를 돌아보면, "그 어떤 조직보다 밀도 높은 경험"이라는 입사 전의 약속은 적어도 제 경험 안에서는 지켜졌습니다.

코드 리뷰에서 설계 철학을 논의하고, 문제의 본질을 먼저 정의하고, 불확실성을 미리 꺼내고, 책임의 위치를 분명히 하는 것. 이런 경험들이 쌓여 개발자로서 문제를 바라보는 방식이 달라졌습니다. 도전을 즐기고 빠르게 성장하고 싶은 분이라면, 충분히 보람 있는 여정이 될 것이라고 자신 있게 말씀드릴 수 있습니다.

감사합니다.