우아한테크코스가 끝난지 3주차다. 아직까지는 톡방이나 디스코드도 활발하고 오프라인 스터디도 하고 있어서 그런지 진짜 '끝났다'는 생각은 잘 들지 않는 것 같다. 끝..났나? 22년 겨울 작년 초쯤 학교 선배에게 우아한테크코스라는 것이 있다고 들었다. 그 때는 그런 교육 프로그램이 있구나 하는 가벼운 생각을 하며 흘려들었던 것 같다. 22년 10월 운이 좋게도 선배를 따라 지원한 회사의 최종 면접을 보고왔다. 행복회로를 돌리지 않는 사람이기도 하고 기대하지 않으려 노력했지만 '최종'이라는 글자는 그런 나에게도 기대감을 주기에 충분한 단어였다. 하지만 예상했던 것처럼 떨어졌고, 운동으로 스트레스를 풀어보려했지만 디스크가 터져 그마저도 힘들었다. 나에게 가혹한 시간이었다. 무엇을 해야 할까. 무엇을 할 수 있..
이하 내용은 기술면접대비 CS 전공 핵심 요약집의 내용을 참고하였으며 스터디원들과 나누고 정리한 내용이기 때문에 틀린 부분이 있을 수 있습니다. 💡 데이터 캡슐화란 무엇인가요? 계층간 데이터를 전달하며 정보를 담은 헤더나 트레일러가 붙는 과정을 말합니다. 💡 그렇다면 데이터 캡슐화를 하는 이유는 무엇인가요? 수신부의 같은 계층에서 데이터의 호환성을 높이고 오류의 영향을 최소화하기 위함입니다. 💡 프로토콜은 무엇인가요? 프로토콜은 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계를 의미합니다. 💡 OSI 7계층에 대해 설명해주세요. 네트워크 통신이 이뤄지는과정을 7단계로 나눈 네트워크 표준 모델입니다. 응용 계층 : HTTP, FTP 등의 프로토콜을 응용 프로그램의 UI를 통..
💡 Intro https://krrong.tistory.com/entry/예외처리 위 글을 작성하며 프로젝트에서 예외처리를 어떻게 하면 잘 할 수 있을까 고민을 많이 했고 제이슨의 도움으로 이론적인 해결의 실마리를 찾았다. 이번 글에서는 어떤 고민을 하면서 프로젝트에 적용했는지 적어보려 한다. 항상 생각하고 있는 것이지만 이론적인 것을 아는 것과 그 이론을 프로젝트에 적용하고 코드로 녹여내는 것은 정말 다른 영역인 것 같다. ❓ Before 지금도 예외처리를 안하고 있는 것은 아니다. 그 처리가 체계적이지 않고 어떤 예외인지 한 눈에 알 수 없는 형태일뿐이다. 코드를 실행했을 때 예외의 메시지를 통해 어떤 예외인지는 알 수는 있다. 하지만 구현하는 동안은 어떤 예외가 발생할 수 있을지 생각해보고 이에 맞..
문제 상황1 현재 Interceptor가 굉장히 살이 많이 쪄있다. 만료된 액세스 토큰을 리프레시 하는 기능을 모두 Interceptor안에 몰아두었기 때문인데 이를 역할과 책임을 적절히 분배할 것이다. 현재 프로젝트에는 AuthRepository가 이미 있기 때문에 액세스 토큰의 리프레시 로직을 AuthRepository가 가지고 있는 것이 적절하다고 생각한다. 그러기 위해서는 Interceptor가 AuthRepository를 들고 있어야 한다. 이 것이 적절할까? 에 대해서 많이 고민하긴 했는데, 역할과 책임을 적절히 분배한다 라는 관점에서는 이게 맞는 것 같기도 했고, 이렇게 구현한 레퍼런스가 아예 없는 것도 아니기에 생각을 밀고 나가보기로 결정했다. (팀원의 생각이 다르다면 받아들여야지 하는 생..
💡 Intro 위와 같은 화면을 만들기 위해 어떤 방법을 사용해야 할까 많이 고민했다. 보여줘야 하는 데이터는 읽은 쪽지와 등록한 쪽지다. 그런데 우리가 가진 API는 다음과 같다. letterlogs?gameId={}&logtype={READ/WRITE} 특정 게임의 아이디를 통해 읽은 쪽지를 받아오거나 등록한 쪽지를 받아오거나. 그러니까 읽은 쪽지 + 등록한 쪽지를 모두 가져오려면 총 두 번의 요청이 필요하다. 어? 그러면 읽은 쪽지와 등록한 쪽지 모두를 가지고 있는 상황에서만 뷰를 띄워주어야 하는 것이 아닌가?🤔 하는 생각이 들었다. 그러면 UI State를 통해 성격이 다른 두 개의 데이터를 하나의 클래스안에 캡슐화하고, UI State가 뷰에 표시될 준비가 되면 뷰에서 보여주면 되겠다!😎 는 생..
💡 Intro 레벨4 프로젝트를 진행하고 있는데 출시했던 앱에서 로그인 기능 문제가 생겼다. 앱을 사용하는 사용자의 입장에서 생각해보면 내가 사용하던 앱이 비정상종료가 계속된다? 그러면 나는 그 앱을 더 사용하지 않을 것 같다. 슬프게도 실사용자가 있는 앱은 아니지만.. 굉장히 불편한 요소 중 하나이며 무조건 고쳐야 하는 버그라고 생각한다. 고쳤다는 가정을 해도 한 가지 문제가 더 남는다. 만약 사용자가 고치기 이전 버전을 사용하고 있다면? 사용자가 플레이스토어에 들어가 직접 앱을 업데이트 하지 않는 이상 발생했던 문제는 사라지지 않는다. 이를 해결하기 위해 많은 앱에서 업데이트를 강제하는 방법을 사용하는 것 같다. 공식문서를 보면 API레벨 21 이상의 기기에서는 플레이스토어 인앱 업데이트를 지원한다...
💡 Intro 5단계는 하지 않을 것 같다고 했지만.. 이대로 끝나는 것은 아까워서 내가 만든 di 라이브러리를 걷어내고 힐트를 적용해보았다. 이미 한 번 프로젝트에 적용한 상태지만 그 때와는 또 다른 부분에 시야가 트는 좋은 기회가 되었다. ❗️ 기능 요구 사항 지금까지 만든 쇼핑 장바구니 앱에 적용된 DI 라이브러리를 Hilt 코드로 교체한다. 기존에 만들어 둔 모듈과 테스트 코드를 삭제하진 않아도 된다. 이전 요구사항을 동일하게 만족해야 한다. 🔎 Hilt 적용하기 힐트를 적용하면 1~4단계까지의 고민이 무색해질 정도로 쉽게 구현이 가능하다. 또, 코드가 굉장히 깔끔해진다. 힐트는 어떻게 만든걸까.. 진짜 신기하네 어떻게 적용했는가, 그리고 그 과정에서 어떤 것을 느꼈는가에 더 집중하기 위해 Mai..
💡 Intro 레벨 4 첫 미션인 만들면서 배우는 DI도 어느덧 막바지를 향해 가고있다. 1단계, 2, 3단계, 4단계.. 5단계까지 있는 미션이긴하지만 감사하게도 선택사항으로 남겨주셨다. 5단계는 내가 만든 의존성 주입 라이브러리를 걷어내고 힐트로 바꾸는 것이다. 팀에서 진행하고 있는 프로젝트에서 힐트를 사용해볼 수도 있기도 하고, 내가 만든 라이브러리를 걷어낸다면 결국 무엇이 남는단 말인가.. 그래서 5단계는 하지 않을 것 같다. (마감이 오늘까지인데 하나도 안했다. ㅋㅋㅋ) 이번 미션이 끝나고 다음 미션은 어떤 것일지 매우 기대가 되지만 한편으로는 걱정도 조금된다. 이 정도의 난이도가 또 나온다면 나는 프로젝트에 얼마나 시간을 투자할 수 있을 것인가. 실제로 레벨 4 한 달동안 프로젝트의 진전은 굉..
