개발자가 된 핏짜

잠시 휴식하느라 정신이 없어서 취업코칭을 위한 이력서 업로드를 수정을 다 해놓은 것 말고 바로 전 버전을 올리고 말았습니다. 근데 왠걸 합격점을 받았습니다. 이러면 좀 곤란한데요. 어느 게 더 나은 이력서인지 판단이 안되네요.

아래는 인텔리픽 취업코칭에서 받은 이력서 피드백입니다.

지난 주는 멘토링을 진행했습니다.

멘토님이 해주신 이력서 피드백은 아래와 같습니다. 

• skill 부분에 대한 부분 추가하기
• Introduce에 개발에 대한 가치 , 내가 개발할 때 중요하게 생각하는것들 개발원칙 추가
• *나는 이런 사람입니다가 필요함
• 잘정리해서 -> 자바, Spring boot 3.0 , nginix aws ec2 s3 cloudfront aws deploy githubaction swagger 스킬로 정리해서 쓰기
• 이미지가 들어가면 좋을 것 같음
  • 왼쪽 기술 스택 | 오른쪽 프로젝트 사진 및 상세내용(나의 역할)
• 영어에 대한 강점 어필…….
  • 나의 강점에 대해서 (쓰기)
  • 금융권 경험, 영어 잘하고, 개발도 할줄앎

취업 스터디 기간도 끝났고 수요일인 내일에는 또 다시 모의 면접날입니다. 5만원 돌려받을 수 있을지는 모르겠지만 모의면접은 참여합니다.

💡문제 상황

첫번째 게시글에서는 좋아요 클릭 시, 반영이 잘 되는데 두번째 게시글부터 게시글 좋아요가 반영이 안되는 현상이 발견됨. 게시글을 조회하고 있는 멤버의 좋아요 여부를 나타내는 isLiked 값이 여러번 연속해서 처리할 때 계속해서 true로만 반환 됨. 트랜잭션이 충돌을 일으킨 것으로 여겨짐.

해당 게시글에 조회하는 멤버가 좋아요를 눌렀을 시, 생성되는 postLike 데이터를 조회하는 과정에서 에러가 나는 것으로 확인됨. 해당 멤버와 해당 게시글 아이디로 데이터를 조회하여 postLike가 이미 있으면 false로 반환(좋아요 취소)하고 없으면 true로 반환(좋아요 성공)하는 로직임.

📒선택지

1. 낙관적 락(Optimistic Lock): version 관리를 통해 application 레벨에서 처리하는 방법으로, JPA가 제공하는 버전 관리 기능(@Version)을 사용함. 대부분의 트랜잭션이 충돌하지 않는 다고 가정하는 방법임. 충돌이 나는 것을 막지 않고, 충돌이 난 것을 감지하면 처리함

2. 비관적 락(Pessimistic Lock): 트랜잭션의 충돌이 발생한다고 가정함. 하나의 트랜잭션이 자원에 접근 시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 함. 데이터 수정 즉시 트랜잭션 충돌 여부 확인이 가능함. DB 단에서 Lock을 함.

🤔 문제 해결

• 이미 충돌이 발생한 것을 확인 했기 때문에 비관적 락을 사용하기로 결정함. 복합키를 이용하여 좋아요 데이터를 찾아오는 메서드에 비관적 락을 걸어주었음.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Transactional
@QueryHints({@QueryHint(name = "javax.persistence.lock.timeout", value ="3000")})
Optional<PostLike> findByPostLikedIdAndMemberId(Long postLikedId, Long memberId);

• 비관적 락에는 두가지 종류가 있음:
  • Exclusive Lock: 데이터를 변경하고자 할 때 사용되며, 트랜잭션이 완료될 때까지 유지되어 해당 Lock이 해제될 때까지 다른 트랜잭션은 해당 데이터에 읽기를 포함하여 접근을 할 수 없음
  • Shared Lock: 다른 사용자가 동시에 데이터를 읽을 수는 있지만 Write는 할 수 없음
• LockModeType으로 PESSIMISTIC_WIRTE 선택하였는데, PESSIMISTIC_WRITE은 Exclusive Lock을 걸고, 데이터를 읽거나, 업데이트 하거나, 삭제하는 것을 막음
• Lock이 길어지면 Latency가 길어지기 때문에,  @QueryHints 를 사용하여 Lock에 3초 타임 아웃을 적용함

→ 좋아요 여부 값(isLiked) 반환 정상적으로 실행 됨

기타 고려사항

• 단일 DB 환경이기 때문에 비관적 락을 사용해서 문제가 발생하지 않지만 추후에 분산 DB를 사용하는 환경일 경우에는 분산 락(Distributed Lock) 도입도 고려해 볼 수 있음. (위의 이미지는 현재 아키텍쳐; RBS 하나를 사용)

• 비관적 락은 모든 트랜잭션에 대해 Lock을 사용하기 때문에 트래픽이 많은 경우, O(N^2) 정도로 성능이 저하된다는 문제가 생길 수 있음.

웹 서버와 WAS의 차이는?

대표적인 웹서버는 Apache, Ngnix가 있습니다.웹서버란 HTTP 프로토콜을 기반으로 클러이언트가 웹 브라우저에 요청을하면 그 요청을 받아서 정적 컨텐츠를 제공하는 서버입니다. 정적 컨텐츠는 단순 HTML 문서, CSS, 이미지, 파일 등 즉시 응답 가능한 컨텐츠를 말합니다. 웹서버가 정적 컨텐츠가 아닌 동적 컨텐츠를 요청 받으면 WAS가 요청을 처리하게 되고 그 결과를 웹서버가 클라이언트가 전달하는 역할도 하게 됩니다. 

WAS(Web Application Server)는 서블릿 컨테이너, 웹 컨테이너라고 불리기도 하는데 웹 서버의 기능들을 구조적으로 분리하여 처리하는 목적으로 만들어졌습니다. 분산 트랜젝션, 보안, 쓰레드 처리 등을 처리하는 분산 환경에서 사용이 됩니다. WAS는 프로그램 환경과 DB 접속 기능을 제공하고 여러개의 트랜잭션을 관리할 수 있습니다. WAS의 종류로는 Tomcat, JBOSS, WebSphere 등이 있습니다.

Stack과 Queue 그리고 Array와 Linked List 자료구조에 대해 말씀해주시고 차이점에 대해 설명해주세요.

배열(Array)와 Linked List에 설명을 드리자면 먼저 배열은 구조가 간단하고 데이터를 읽는데 걸리는 access time이 짧은 편입니다. 단점으로는 크기를 변경할 수 없고, 크기 변경을 피하기 위해 충분히 큰 배열을 생겅하면 메모리가 낭비가 됩니다. 또 비순차적인 데이터의 추가, 삭제에 시간이 많이 걸린다는 단점이 있습니다. LinkedList는 이런 배열의 단점을 보완한 것이 특징입니다. 비연속적으로 존재하는 데이터를 연결하고 단 한번의 참조 변경으로 데이터 삭제가 가능합니다. 또 한번의 Node 객체 생성과 두번의 참조 변경만으로 데이터 추가가 가능합니다. 링크트리스트는 데이터 접근성이 나쁘다는 단점이 있는데 이중 연결 리스트는 이러한 문제를 보완하여 접근성을 향상시켰습니다. 배열은 빠른 접근이 요구되고, 데이터의 삽입과 삭제가 적을 때 사용하고 링크드리스트는 삽입과 삭제 연산이 잦고, 검색 빈도가 적을 때 사용합니다.

@SpringBootTest와 @WebMvcTest의 차이점을 설명해 주세요.

@SpringBootTest는 프로젝트 내부에 있는 스프링 빈을 모두 등록해서 사용해서 테스트가 느리다는 특징이 있습니다. 실제 운영 환경에서 사용되는 클래스들을 통합해서 테스트하기 때문에 실제 환경과 가장 유사하게 테스트가 가능합니다. Service 의 메서드가 변경이 되어도 Mocking 값을 수정하지 않아도 되서 변경이 자유롭습니다. 그러나 테스트 단위가 크기 때문에 디버깅이 어렵다는 단점이 있습니다.

@WebMvcTest는 컨트롤러의 역할만을 테스트합니다. Web Layer에 해당하는 빈만 생성해서 테스트하기 때문에 @SpringBootTest보다 빠르다는 장점이 있습니다. 그러나 Mock 객체를 사용해서 실제 동작과는 차이가 날 수 있습니다. 또한 메서드 변경이 일어날 때 Mocking값을 수정해줘야 한다는 번거로움이 있습니다. 

트랜잭션이 무엇인지 설명해 주세요.

트랜잭션이란 데이터베이스의 상태를 변화시키기 위해서 수행하는 작업의 단위를 뜻합니다. 원자성(Atomicity)은 트랜잭션의 가장 큰 특성으로 트랜잭션 안의 작업들이 분리되어 작업불가하고 모두 반영되던가 전혀 반영되지 않아야 합니다. 일관성은 트랜잭션이 진행되는 동안 데이터베이스가 변경되었더라도 기준은 트랜잭션을 진행하기 위해 참조한 데이터베이스 정보로 진행되어야 합니다. 고립성은 둘 이상의 트랜잭션이 동시에 실행되고 있을때 서로 트랜잭션 연산에 관여되지 않아야합니다. 지속성은 트랜잭션이 성공적으로 완료 되었다면 그 결과는 영구적으로 반영되어야 합니다.

TCP와 UDP의 공통점과 차이점을 설명해보세요.

TCP(Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 지원하는 연결 지향형 프로토콜로 일반적으로 TCP와 IP가 함께 사용되는데, IP가 데이터의 전송을 처리한다면 TCP는 패킷 추적 및 관리를 하게 됩니다. 연결 지향형인 TCP는 3-way handshaking이라는 과정을 통해 연결 후 통신을 시작하는데, 흐름 제어와 혼잡 제어를 지원하며 데이터의 순서를 보장합니다. UDP(User Datagram Protocol)는 비연결형 프로토콜로써, 인터넷상에서 보내는 쪽에서 일방적으로 데이터를 전달하는 통신 프로토콜로 TCP와는 다르게 연결 설정이 없으며, 혼잡 제어를 하지 않기 때문에 TCP보다 전송 속도가 빨라 실시간 동영상 스트리밍 서비스 같은 서비스에 적합합니다. 그러나 데이터 전송에 대한 보장을 하지 않기 때문에 패킷 손실이 발생할 수 있습니다.

하루종일 코딩을 하다가 거북목이 악화되는 게 매우 느껴져서 잠시 넷플릭스 다큐멘터리를 봤습니다. spaceX가 어떻게 화성에 가려고 하는지, 일론 머스크는 어떻게 로켓맨이 되었는지에 대한 흥미로운 다큐멘터리였습니다. 

저는 화성 이주 같은 거창한 꿈은 꾸지 못하지만 나름 생각하고 꿈만 꿨던것을 하나하나 이루어 가고 있습니다. 훌륭한 개발자가 되는 것을 장기프로젝트라고 생각하고 지금 당장 좌절하고 실패하더라도 꾸준히 나아가겠습니다. 

취준생이긴하지만...! 부트캠프 때문에 주말에 친구들을 안만난지 꽤 됐는데 오랜만에 만나서 폭풍수다를 떨었습니다. 물론 만나기 직전까지 카페에서 공부하다가 갔답니다.

개발자는 즐겁습니다. 왜냐면 생각하면 다 만들 수 있기 때문이죠. 오늘만 미팅을 2개 했습니다. 하나는 항해99 최종 프로젝트 발전 시키기 위한 회의이고 하나는 제가 제안한 미니(not so mini) 프로젝트에 대해서 기능을 확정하기 위한 회의였습니다. 제가 예전에 꿈꾸던 삶을 살고 있어서 행복하긴 한데 물리적으로 시간이 부족함을 느낍니다. 저는 아이디어는 정말 많은데 바로 구현할 수 없는 점이 늘 아쉬웠거든요. 지금은 부트캠프에서 만난 인연들과 아이디어를 떠올리기만 하면 바로 팀이 만들어져서 (순식간에 무려 8명이 모였습니다;) 바로 실현 가능성이 보이거든요. 더 빨리 개발자를 하지 못한 것이 아쉬울 따름입니다. 

최종 프로젝트 발전 시키기

최종 프로젝트 관해서는 리팩토링(interface를 사용해서 서비스 구현하기 등), 페이지 추가, 서비스 보완, 부하 테스트, 성능 테스트 등 기능 구현하기에 급급해서 놓쳤던 부분들을 채워나가기로 했습니다. 장기 프로젝트로 전에 시간에 쫓기면서 하던 것과는 달리 취업 준비도 하면서 좀 여유를 가지고 진행하기로 했습니다. 밤새기 금지를 룰로 넣을까도 했습니다. 프론트에 열정맨이 계셔서 잠을 안주무시거든요. 트러블 슈팅을 하다보면 저도 새벽까지 하는 게 허다하긴 하지만 그분은 아예 잠을 안주무시더라구요. 그분께 미니프로젝트도 같이하자고 한 거였는데 8명이 되버렸습니다. 열정맨과 함께하니 좋습니다 🤦‍♀️

미니 프로젝트 - DEVELOP SPACE

백엔드 3명, 프론트 3명, 디자이너 2명이 함께하는 전혀 미니미 하지못한 이 프로젝트를 처음 기획하게 된 의도는 '우리끼리 재밌게 뭐 하나 하면 좋겠다~ 면접 공부할 때 폰에 단어장처럼 들고 다니면 어떨까?' 였는데 뭔가 본격적으로 시작이 되어버렸습니다. 안드로이드 앱 출시를 목표로 달리려고 합니다. 2주가 될 줄 알았던 프로젝트는 아마 디자인이 나오는데만 2주가 소요 될 것으로 예상이 됩니다. 다행히 api가 복잡하거나 많지는 않아서 (20개 안쪽) 부하 테스트라던지 좀더 백엔드 적인 것들을 시도해보려고 합니다. 테스트 코드도 꼭꼭 해보고 싶어서 제가 얼른 기능 구현 끝내버리고 하자고 이야기 하고 있습니다. 

저는 이번에 회원가입, 로그인 쪽을 맡게 되었습니다. CI/CD 구축과 Swagger 세팅도하고 Spring Security까지 제가 부트캠프 내내 안해봤던 것들을 해보고 싶어서 자진해서 나섰습니다. 다들 github action 쓰고 aws 능숙하게 다루고 linux도 마찬가지로 많이 안해봐서 이번 기회에 좀 파고들면 좋을 거라고 생각했습니다. 현재 CI/CD를 할려면 shell script라는 걸 써야 한다고 해서 열심히 찾아보고 있습니다. github action을 쓰는 이유는 저희가 협업 툴로 github을 쓰기 때문입니다. 버전 관리하는 것도 훨씬 익숙하기도 합니다. 우선 제 아이디로 ec2 인스턴스랑랑 rds를 생성 해놨습니다. 

취업은 언제?

이제 수료한지 겨우 일주일이 지난 시점이지만 조금은 조급합니다. 벌써부터 면접보러 가시는 분들도 있고요. 저는 이력서용 사진을 하나 찍었습니다. 사진을 넣고 싶지 않았는데 사진을 넣으라는 조언들이 많아서 넣었습니다. 라떼는 상상도 못할일이죠. 아는 분이 개발 팀장인데 그냥 제가 아는 이력서 형식으로 하라고 말씀해 주셔서 그렇게 하려다가 아무래도 붙캠 출신들의 화려한 이력서 사이에서 눈에 띄지는 못할 거 같아 사진을 박았습니다.  아직까지는 서류 합격률이 그렇게 좋지는 않습니다. 한방에 합격하면 좋겠지만 커리어 전환이 쉬울거라고 생각하지도 않았어서 일단은 최선을 다하겠습니다. 코딩하는 것도 재밌고 취업 공부하면서 cs를 배우는 것도 재밌으니까요!

Parameter와 Argument의 차이에 대해 설명해주세요.

parameter는 매개변수명을 말하고 argument는 함수와 메서드의 입력 값(value)를 뜻합니다. 함수를 정의할 때 사용되는 변수를 매개변수, 실제로 함수가 호출될 때 넘기는 변수값을 argument(인수)라고 설명할 수 있습니다. 

프로세스와 스레드의 차이에 대해 설명해 주세요

프로세스는 운영체제로부터 자원을 할당받는 작업의 단위이고, 스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위입니다. 프로세스는 실행될 때 운영체제로부터 프로세서, 필요한 주소공간, 메모리 등 자원을 할당받습니다. 스레드란 한 프로세스 내에서 동작되는 여러 실행의 흐름으로 프로세스 내의 주소공간이나 자원들을 같은 프로세스내에 스레드끼리 공유하면서 실행됩니다.

어제 밤에 미니 프로젝트 멤버들과 회의를 했는데 인원이 늘어난 만큼 제대로 하자는 의견이 많아서 프로젝트가 더이상 미니가 아니게 되었습니다. 2주정도 생각했던 프로젝트는 한달 정도 될 것 같습니다. 백엔드의 업무가 늘어나긴 했지만 2명이 감당하지 못할 정도는 아니어서 저는 이번달 안에 끝낼 계획입니다. 개발하면서 밤새는 건 괜찮습니다라고 생각했는데 백엔드 1명이 더 추가되었습니다아! 총 8명의 중형 프로젝트가 되었습니다.

저는 그냥 제가 안해본 CI/CD, Spring Security 쪽을 건들여보고 싶었는데요 인원이 늘면서 여유가 생겼습니다. 같이 interface로 service 구현하기 등등을 해보려고 합니다.

MSA(Microservice Architecture)란?

하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐를 말합니다. 예전에는 Monolithic Architecture라는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태로 개발을 하였습니다. 소규모프로젝트에는 합리적일지 모르나 일정 규모 이상의 서비스에서 Monolithic Architecture 는 비효율적입니다. Microservice Architecture에서는 하나의 어플리케이션을 작은 서비스 단위로 나누어서 작업을 하기 때문에 각각의 서비스의 독립적 배포가 가능하고 다른 서비스에 대한 의존성이 낮아집니다. 또한 확장성이 높으며 에러가 발생해도 그 에러가 발생한 단위의 서비스를 격리가 가능하기 때문에 유연한 대처가 가능합니다. 

MSA의 단점으로는 상대적으로 복잡하다는 점이 있고 서비스가 커질 수록 그 복잡도가 늘어날 수 있다는 점이 단점입니다. 서비스가 분리되어 있기 때문에 트랜잭션의 복잡도가 증가하고 많은 자원을 필요로 하게 됩니다. 또 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기가 어려울 수 있고, 데이터의 정합성도 관리하기 어렵습니다. 성능면에서는 서비스간 호출시 API를 사용하기 때문에 통신 비용이나, latency가 그만큼 늘어난다는 단점이 있습니다. 

제네릭에 대해서 설명하고, 컬렉션 클래스에서 왜 제네릭을 사용하는 지 설명해주세요.

데이터 타입을 일반화한다는 의미를 가지고 있으며 클래스나 메서드에서 사용할 내부 데이터 타입을 컴파일 시에 미리 지정하는 방법입니다. 클래스에서 사용할 타입을 클래스 외부에서 설정하는 것 입니다. 제네릭의 장점은 객체 타입의 안정성을 높일 수 있고 반환 값에 대한 타입 변환을 쉽게 할 수 있다는 점입니다. 타입 체크와 형변환을 생략할 수 있어서 코드가 간결해진다는 장점도 있습니다. 컬렉션은 이러한 장점 때문에 제네릭 기법으로 구현이 되어 있습니다. 컬렉션을 특정 타입만 다루지 않고 여러 종류의 타입으로 변환할 수 있도록 컬렉션을 일반화 시키기 위해 제네릭을 사용합니다. 

List, Set, Map, HashMap의 차이에 대해서 설명해주세요.

List는 데이터들이 순서대로 저장되고 중복을 허용합니다. 

Set은 데이터의 집합으로 순서가 없고 중복되는 데이터를 허용하지 않아서 중복되지 않는 데이터를 사용할 때 유용합니다. 

Map은 key와 value라는 페어로 이루어지는 데이터의 집합입니다. key는 중복되지 않고 순서를 보장하지 않습니다. 인덱스가 따로 존재하지 않기 때문에 iterator를 사용해야합니다. HashMap은 마찬가지로 key에 대한 중복이 없으며 순서를 보장하지 않습니다. 동기화가 보장이 되지 않고, key와 value값으로 null을 허용한다는 특징이 있습니다. 

정리하자면, list는 데이터들이 순서대로 저장되며 중복을 허용하고,  set은 순서가 보장되지 않고 중복을 허용하지 않고, Map은 순서가 보장되지 않고 key값의 중복은 허용하지만 value값은 중복될 수 없다는 특징이 있습니다.