신입이 직장에 들어간 3개월 - 첫번째 회고

첫 회고의 시작

사실 저는 회고를 자주 쓰는 사람은 아닙니다..

 

네이버 부스트캠프에서 교육을 받을 때도, 애플 디벨로퍼 아카데미를 할때도 회고의 중요성은 정말 많이 들었어요

실제로 매주 한 주를 돌아보며 정성스럽게 기록하는 러너분들도 많이 봤었죠.

 

그때마다 "와....대단하다"라는 생각은 했지만 막상 내가 쓰려하면...?

낯간지러워서 못쓰겠더라고요... 여기는 개인 일기장이 아닌 모두가 볼 수 있는 곳이니?

 

하지만 제 인생의 첫 회고를 적으려 해요

 

바로 어느새 첫 직장에 취업을 하고 3개월이 된 지금 시점에!! 

짧다면 짧은 3개월 난 그 사이에 많은 생각의 변화가 있었다고 당당히 말할 수 있기 때문입니다

 

절대 짧지 않았어요.

어쩌면… 제가 발전한 속도보다 AI가 발전한 속도가 더 빨랐던 3개월이었을지도요. 😅

 

입사 ~ 한달차(1개월차)

쭈뼛쭈볏 사무실에 들어가 새로운 M4 Pro, 4K 모니터를 본 순간

“아… 나 진짜 취업했구나"

 

기분이 올라간 만큼 자신감도 같이 올라갔습니다. 그런 표현 하잖아요? 뻔하지만  정말 하늘을 찌를 정도로요.

저는 애플 디벨로퍼를 수료했고, 네이버 부스트캠프도 했습니다. 모두가 그랬지만 취준 시절에는 매일 새벽 3시까지 공부하고 아침 9시에 다시 동료분들과 코드리뷰하며 스스로 생각했습니다.

그 모든 노력이 언젠가 저를 증명해줄 거라 믿었습니다.

 

그래서 말과 행동도 자신감으로 가득했습니다.

예를 들어, 얼른 제가 프로젝트를 파악해서 도움을 드린다거나 기존 코드에 대해 너무나 당당하게 아는척을 했던게 있었어요

지금 생각해보면… 많이 부끄럽습니다...

 

그때의 저는 실력보다 자신감이 훨씬 앞서 있었습니다.

첫 업무 UI

첫 업무는 AOS → iOS UI 포팅이었습니다.

코틀린을 아예 모르는 저는 막막했습니다. 그러다보니 저의 가장 가까운 동료는 GPT가 되었습니다.

AOS 코드를 주고 iOS 코드로 바꿔달라 하고 그걸 다시 swift 스럽게 더 다듬고.. 

그러다 문득 이런 생각이 들었습니다.

지금 나는 생각하면서 개발하는 걸까? 아니면 그저 GPT를 한번더 포팅한 존재일까?

그러다 보니 첫달은 사실 기대한 회사생활과 달라 실망감과 회의감이 어느정도 존재했던 것이 사실이였습니다.

제가 취준을 멈추고 회사에 가고 싶었던 가장 큰 이유는 회사에서의 개발 문화와 프로세스가 진행되는 것을 경험해보고 싶었기 때문이죠.

 

하지만 이러다보니 제 실수도 나왔습니다.

실수 중 하나의 예시가 바로 너무나도 기본적인 이미지 처리였습니다.

이미지 리스트를 구현하는 아주 베이직한 Task였는데 죄다 동기처리를 해서 엄청 끊기는 경험을 데드라인날 발견해서 금요일날 10시까지 작업했던 기억도 있습니다. 

더 나아가 KingFisher를 도입해버리는 등 정말 지금 생각해보면 폐급 같은 선택도 했었죠..

 

돌이켜보면 한 달 동안 저는 "이해"보다 "속도"에만 집중을 하며 맡은 일만 처리하는 기계였던것 같아요 

한달차~2달차

클린 아키텍처의 지옥

첫 달의 태도는 결국 두 번째 달에 돌아왔습니다.

프로젝트의 구조를 깊게 이해하지 않고 그냥 받아들인 채로 코드를 쌓았거든요

제가 이전까지 배웠던 구조는 이랬습니다. 

• Domain: UseCase, Entity, Repository Protocol
• Infra: Network, DB, Repository 구현
• App: Feature, UI

UseCase는 반드시 추상화된 Repository에 의존해야 하고, Repository의 구체 구현은 인프라 계층에 둔다.

그런데 현실은 달랐습니다.

• 일부 Usecase가 다른 Usecase를 의존했다.
• Usecase 내부에 Reposiotry뿐 아니라 여러 UseCase가 섞여 의존성이 생겨있었다.
• 이전까지 UseCase의 책임이 명확하고 단일이여야 한다고 배웠는데 그 당시 내 생각으로는 UseCase의 범위가 컸다.

그래서 다른 선배 개발자분들에게 질문을 했습니다 (사실 한번 똑같은거 여러번 물어보고 실수도 해서....)

전체 구조에 영향이 주는 작업은 동료분들과 상의해야 함에도 불구하고, 밑 기반이 되는 DB 접근이나 Reposiotry 즉 Core 영역의 코드를 제 멋대로 수정했다가 다른 곳에 영향을 주어 혼이 나기도 했습니다. 

가장 중요한 것은 결국 "우리 팀이 약속한 범위"를 지키는 것이였습니다.

그리고 나름대로 세 가지 선택지를 고민했습니다.

 

1. UseCase안에 Repository로만 의존을 하고 UseCase를 의존하지 못하도록 한다면?

• UesCase를 도메인 규칙 실행단위로 만들고 결합을 없애 책임/경계를 강하게 만들 수 있다.
• 의존성 그래프는 단순해 질거다.
• UseCase의 테스트가 쉽다.

하지만 명확한 단점이 있다. 코드를 짜다보니 시나리오(여러 단계를 조합)해야 하는 순간에는 같은 흐름이 여러 UseCase에 반복적으로 만들어야하거나 UseCase 하나가 점점 커지고 UseCase의 수가 많아집니다

 

2. UseCase는 단일 기능만 하고 Feature에서 해당 UseCase를 조립하여 사용

• 단일 UseCase이기에 명확하다. 그런데 명확한 만큼 파일 수는 엄~~~청 많아질 것이다.
• 그리고 어떻게 보면 도메인 시나리오가 Feature에 있는 것이니 이것은 클린아키텍처를 위반한다고 판단했습니다.

3. 오케스트레이터 UseCase를 만들어 UseCase들만 의존하도록 하는것 

• UseCase를 두 층으로 나눈다.
• 하나는 Repository에 의존하는 단위 UseCase이고, 다른 하나는 단위 UseCase들만 의존해 비즈니스 시나리오를 조립하는 오케스트레이터 UseCase다.
• 이 방식은 도메인 시나리오를 Domain 계층에 유지할 수 있다는 장점이 있다. 대신 계층이 하나 더 생겨 구조 복잡도는 높아진다.

결론적으로 저는 3번이 더 현실적이라고 깨달았습니다. 그때 처음으로 깨달은 것은 클린 아키텍처를 그저 책속의 지식으로 이해하는 걸 넘어 왜 다른 분들이 반복적으로 왜 이렇게 나누는지를 이해하라고 말씀을 하신걸요.

 

또 하나, 왜 우리는 기본 TCA 의존성 방식을 쓰지 않고 Needle을 쓰고 있을까?에 대해 저는 깊게 생각해보지 않았습니다. 

의존성 

그때 한 선배분이 

왜 우리 프로젝트가 기본 TCA에서의 의존성 라이브러리 방식을 사용하지 않고 Needle을 썻을까요? 

https://codeisfuture.tistory.com/160

TCA + Clean Architecture에서 의존성 관리, Needle 도입한 이유

부끄럽게도 저는 그 질문에 바로 답할 수 없었습니다. 기존 구조가 당연히 정답이라 믿고, 그 속에 담긴 설계 철학을 깊이 파고들지 않은 채 코드를 쌓아 올리기만 했기 때문입니다.

그저 Needle을 검색하며 어~ 런타임때 체크안하고 컴파일때 체크해서 런타임의 안정성을 챙기는 대신 빌드에서의 사이드 이펙트를 얻었구나!

딱 그정도였습니다

 

이 질문도 어떻게 보면 위의 클린아키텍처와도 이어지는 내용이였습니다.

TCA의 디폴트 의존성 관리는 DependencyKey에 등록해두면 어디서든 편하게 꺼내 쓸 수 있는 구조였습니다.

하지만 이는 의존성의 전역화를 의미하기도 했죠.

클린 아키텍처에서는 Domain 레이어가 Infra 레이어를 알면 안 되고, 각 모듈은 정해진 인터페이스로만 소통해야 합니다.

그런데 모든 의존성이 전역적으로 열려 있다면, 개발자의 실수로 레이어 간의 경계를 허무는 의존성이 침투하기 너무 쉽습니다.

Needle은 '부모-자식' 관계를 코드로 직접 연결해야 하므로, 이 의존성이 어디서부터 왔고, 어디까지 흐르는가를 물리적으로 제한하고 시각화해 줍니다.

 

 

이렇게 그저 놓치고 넘어간 부분에 대해서도 한번 더 생각할 수 있었죠

알림 구조 설계

어떻게 보면 처음으로 맡은 단순 UI, 기능 구현이 아니라 전체적으로 구조를 설계하는 업무였습니다.

 그렇기에 열정도 더 뛰어났죠. 하지만 열정과 달리 설계를 탄탄하게 하지 못하고 설계를 1차적으로 50퍼정도 하고 구현하면서 수정해야겠다!라는 생각으로 진행을 했더니 여기저기서 문제가 발생했엇습니다.

다국어 프로젝트에서 APN 기반이 아닌 로컬 알림으로만 처리해야 했고, 상황에 따라 예약 알림도 필요했고, 특정 트리거 발생 시 알림을 띄워야 했습니다.

기술적으로 어떻게 구현했는지는 이 두글에 더 잘 정리했습니다

https://codeisfuture.tistory.com/159

푸시 알람을 어떻게 설계할까?

https://codeisfuture.tistory.com/162

로컬 알림 다국어 적용기: 언어가 바뀌어도 알림을 다시 등록하지 않아도 되는 이유

하지만 여기서 정말 말하고 싶은 건 “기술을 어떻게 구현했는가”가 아닙니다.

나는 정말 엣지케이스를 끝까지 검토했는가?

이 질문이 더 중요했습니다

 

 

제대로 찾아보지 않고 AI를 믿고 불가능하다고 단정 지었던 착각

우리 프로젝트는 APNs 기반이 아니었기에 Notification Service Extension을 사용할 수 없었고, 저는 이 제약 조건 때문에 "로컬 알림의 다국어 처리는 불가능하다"고 섣불리 결론 내렸습니다.

하지만 이는 기술적 한계가 아니라 제 검토의 문제였습니다.

지금 생각하면 너무 빨랐습니다. 

깊게 찾아보지도 않았고, 공식 문서를 끝까지 읽어보지도 않았고, AI에게 몇 번 물어본 뒤 “안 된다”는 답을 그대로 받아들였습니다.

한참 뒤에야 localizedUserNotificationString API를 발견했습니다.

저는 GPT를 도구로 쓴 게 아니라, 판단을 대신 맡기고 있었습니다

 

설계 없이 구현부터 시작했을 때 생기는 일

• 기획이 조금만 바뀌어도 여러 군데를 수정해야 했고
• 하나의 버그를 고치면 다른 흐름이 깨졌고
• 데이터와 알림 상태의 책임이 애매하게 섞여버렸습니다

UI 구현 위주의 작업만 할 때는 “동작하면 된다”가 어느 정도 통했지만 구조 설계는 달랐습니다.

결국 이 시기에 깨달은 것은 첫달의 회의감과 달리 내 자신이 충분히 생각도 안하고 구현을 하고 있구나를 깨달았습니다. 

 

2달차~3달차

반성의 시기 

여전히 비즈니스 로직은 제대로 파악하지 못한 채, 겉에서 보이는 일만 속도 위주로 쳐내고 있었습니다

그러다 처음으로 중요한 비즈니스 로직 버그를 맡았습니다.

그때 처음 깨달았습니다.

 

나는 여전히 이 프로젝트를 모른다

데이터 흐름이 어떻게 이어지는지 그 기본조차 이해하지 않은 채 그저 내 업무가 있는 곳만 보고 있었던 것이니 당연했죠.

결국 내가 할 수 있는 건 새로 생긴 친구 Claude Code에게 묻는 것 뿐

 

그리고 처음으로 제대로 로그를 통해 분석을 할때는 거짓말 안하고, 토할뻔 했습니다. 속이 울렁거려 6시면 칼퇴를 안하면 쓰러질꺼 같다...라는 생각까지 들었어요

 

한 업무를 3주동안 붙잡고 있을떄야 로그가 조금씩 보이기 시작했습니다.

한 줄씩 다라가다 보며 다음 흐름을 추적하여 실제로 코드 한줄을 수정해 버그를 해결한 순간, 방탈출게임에서 힌트로 자물쇠를 푸는 느낌과 비슷했습니다

 

기술적인 부분뿐만이 아니었습니다. 또 한 번 부끄러웠던 순간은 선배님의 질문에서 시작되었습니다.

 

우리 경쟁앱을 기획적으로 분석해본적이 있나요?

뭐라고 대답했을까요? 저는 당당하게 "네"라고 대답했습니다. 실제로 써보긴 했으니까요.

하지만 선배님의 이어지는 질문에 저는 아무 말도 할 수 없었습니다. 저는 그저 '일반 유저'처럼 앱을 즐겼을 뿐이었습니다.

특정 기능이 어떤 트리거로 발동되는지, 어떤 구조로 설계되었을지, 엣지 유저들은 어떤 불편을 느낄지... '설계자'로서 고민해본 적이 단 한 번도 없었다는 사실을 깨달았습니다.

 

돌이켜보면 저는 입사 직후부터 자신감이 너무 가득 차 있었습니다. '증명해야 한다'는 강박에 사로잡혀 모르는 것도 아는 척했고, 이해가 덜 된 부분도 고개를 끄덕였습니다. 그런 저를 지켜보던 선배님이 한마디를 건네주셨습니다.

"자신감은 좀 줄여도 돼요. 지금 모르는 건 당연한 겁니다. 오히려 자신감이 너무 넘치면 사람들이 '이미 다 아는구나' 싶어 굳이 알려주지 않을 수도 있어요. 지금은 겸손하게 채워 넣을 때입니다."

 

그 말을 듣는 순간 제가 그동안 부렸던 자신감은 사실 불안함을 감추기 위한 가면이었음을 깨달았습니다. 

마무리

이 모든 과정을 겪으며 제가 가장 크게 고쳐야 할 점을 하나 더 발견했습니다. 바로 커뮤니케이션, 그중에서도 '질문'의 방식입니다.

그동안 저는 제가 커뮤니케이션을 잘하는 사람인 줄 알았습니다. 하지만 실상은 질문조차 제대로 할 줄 모르는 사람이었죠.

1부터 9까지의 고민 과정이 있었다면, 저는 선배님들께 1만 보여주고 질문을 던졌습니다.

제 나름대로는 치열하게 고민했지만, 듣는 사람 입장에서는 '이 사람은 노력도 안 하고 정답만 날로 먹으려 하는구나'라고 오해하기 딱 좋은 방식이었습니다.

 

그래서 현재는 이 책을 읽고 있는데 강추!!

https://product.kyobobook.co.kr/detail/S000001834395?utm_source=google&utm_medium=cpc&utm_campaign=googleSearch&gad_source=1

일 잘하는 사람은 단순하게 말합니다 | 박소연 - 교보문고

no ppl

• 상대방이 필요한 정보부터 말하기
• 장황한 정보보다 한문장으로 정리하고 말하기
• 9까지 고민했던 것을 보여주기 위해서는 결국 A안 B안 더 나아가 C안까지 그에 대한 의견까지 더해 질문을 드리는 것입니다. 

지난 3개월은 제 인생에서 가장 당당했던 자신감이 꺾인 시기였습니다.

하지만 그 덕분에 더 분명한 목표가 생겼습니다. 

1. 연차와 상관없이 함께 일하면 좋은 개발자
2. 커뮤니케이션에서의 비용과 오해를 줄이는 개발자(장황함 대신 명확함으로 말하는 사람)
3. 서비스 도메인에 대해서는 적어도 다른 사람에게 구조와 맥락을 설명할 수 있는 개발자.
4. 그리고 무엇보다, 실력과 관계없이 겸손을 잃지 않는 개발자.

예전에는 “잘하는 신입”으로 증명하고 싶었습니다.
지금은 생각이 조금 달라졌습니다.

아직은 많이 부족합니다.
하지만 이 3개월 동안 받은 피드백을 하나씩 고쳐나간다면
1년 뒤 저는 분명 다른 사람이 되어 있을 겁니다.

 

그것이 제가 이 회고를 쓰는 목적중 하나입니다. 

길고 낯간지러운 첫 회고를 읽어주셔서 감사합니다. 이제 다시 겸손하게 채워 나가보겠습니다!