시험 장소는 서울특별시 동작구에 위치한 성남고등학교에서 시험을 치뤘습니다. 신림선 '서울지방병무청역' 에서 도보로 이동 가능한 곳입니다.

집에서 가까운 곳으로 선택했는데, 주변에 주택가가 있어서 조용하고 시험 환경은 준수한 편입니다.

https://place.map.kakao.com/8441234

📌 SQLD란?

SQL 개발자(SQLD*, SQL Developer)란 데이터베이스와 데이터 모델링에 대한 지식을 바탕으로 응용 소프트웨어를 개발하면서 데이터를 조작하고 추출하는데 있어서 정확하고 최적의 성능을 발휘하는 SQL을 작성할 수 있는 개발자를 말한다.

(출처 : https://www.dataq.or.kr/www/sub/a_04.do)

과목은 '데이터 모델링의 이해', 'SQL 기본 및 활용' 총 2과목으로 구성되어 있으며, SQL 기본 및 활용 과목의 비중이 매우 높음(80%)을 알 수 있습니다. 하지만 과목별 과락이 존재하기 때문에 데이터 모델링의 이해 과목 역시 소홀히하면 안 되겠습니다.

문항 중 주관식 문항도 있는데, 2023.3.19일 기준, 주관식은 총 5문제가 나온걸로 기억합니다. 주관식도 기출문제 수준의 내용을 풀 수 있다면 크게 어렵지 않을 것으로 보입니다. (회차별로 난이도 상이) (출처 : https://www.dataq.or.kr/www/sub/a_04.do)

📌 응시 계기

현재 2년차 백엔드 개발자로 일하면서 SQL에 관한 공부가 필요하다고 느꼈고, 자격증을 취득함으로써 공부를 지속적으로 하게 되는 발판을 마련하고 싶었습니다. 개발자는 끊임 없이 공부해야하니까요. ^^

📌 공부 방향

흔히 말하는 CRUD (Create, Read, Update, Delete) 및 간단한 Join 문을 사용 가능한 수준의 지식을 가졌고 약 2주간 시험을 위해 준비했습니다.

주로 Maria DB 및 MySQL을 이용하다 보니, Oracle DB에서 사용하는 함수들이 다소 생소해서 익히는 시간을 가졌습니다. 더욱이 '데이터 모델링의 이해' 과목은 암기 위주의 내용이 많아 암기할 시간이 필요했습니다.

공부시간 평일 : 점심시간 및 퇴근 후 12시간 주말 : 45시간

저는 아래와 같이 2권의 책으로 공부를 시작했는데, 많이들 추천하는 책은 SQL 자격검정 실전문제 입니다. 개인적으로 기본기가 부족하다고 판단해서 이론 내용도 병행하고 싶어서 2023 이기적 SQL 개발자 이론서+기출문제 도 병행해서 봤습니다.

SQL 자격검정 실전문제

https://product.kyobobook.co.kr/detail/S000001399867

2023 이기적 SQL 개발자 이론서+기출문제

https://product.kyobobook.co.kr/detail/S000061583675

추가로 네이버 카페 데이터 전문가 포럼 에서도 많은 정보를 얻을 수 있어 유익했습니다. 데이터를 다루는 직군을 준비하시는 분들은 가입을 추천 드립니다.

데이터 전문가 포럼 https://cafe.naver.com/sqlpd

📌 응시 결과

자랑할 정도로 높은 점수는 아니지만, 비교적 안전하게 합격했다는 생각이 들었습니다. 기출문제는 꼭! 풀어보고 시험에 응시하시길 권장드립니다. (유사하거나 동일한 문제가 꽤 나왔던 것으로 기억합니다.)

📌 시험 총평

SQL에 대한 이해도가 높다면 어렵지 않게 느낄 수 있지만 비전공자가 처음 도전하기에 만만한 시험은 아니라는 생각이 들었습니다. 저 역시 비전공자 + 국비지원 학원을 거쳐 개발자가 되었지만, 백엔드 개발자로 진로를 선택하셨다면 SQL에 대한 이해는 필수입니다.

또한 저도 주관식이 출제된다는 사실에 대해 겁이 많았는데, 객관식에서 정확도를 높게 가져가면 충분히 합격할 수 있다는 생각이 들었습니다.

작고 독립적이며 자율적으로 배포 가능한 서비스로 구성된 애플리케이션 아키텍처

MSA란 MicroService Architecture의 줄인 말로 소프트웨어 아키텍처 디자인 패턴 중 하나입니다. 애플리케이션을 작은 독립적인 서비스 단위로 분할하고, 이러한 서비스 단위들을 조합하여 전체 애플리케이션을 구성하는 방식

각각의 서비스는 특정 비즈니스 기능을 수행하며 서로 다른 서비스와 API를 통해 통신합니다.

예를 들어 쇼핑몰 홈페이지를 MSA로 구현했다고 가정해보도록 합시다. 로그인 및 권한을 담당하는 서비스, 상품 주문을 담당하는 서비스, 상품 판매를 위해 상품을 업로드 하는 서비스 등 비즈니스 로직을 처리하는 각각의 서비스가 존재하고 A 서비스에서 B 서비스를 호출해야 하는 경우, API를 통해 통신합니다.

📌 탄생배경

이미지 출처 - https://www.lgcns.com/blog/cns-tech/36171/

MSA는 기업이나 조직의 비즈니스 요구사항이 급격히 변화하고 서비스의 빠른 개발과 배포, 확장성과 가용성을 보장하는 것이 중요해진 현대의 IT 환경에서 발전해왔습니다.

이전의 Monolithic Architecture에서는 애플리케이션 전체를 한 번에 빌드하고 배포하는 것이 일반적이었지만, 이러한 방식은 대규모 애플리케이션에서 많은 문제점을 유발했습니다.

MSA는 이러한 문제점을 극복하고자, 각각의 서비스 단위를 개별적으로 개발, 배포 및 관리함으로써 애플리케이션의 유연성, 확장성, 가용성을 높이는 것을 목표로 합니다.

이러한 아키텍처의 탄생 배경은 클라우드 컴퓨팅, 분산 시스템, DevOps 등의 기술의 발전과 함께 나타난 것으로 볼 수 있습니다.

그럼 Monolithic Architecture와 MicroService Architecture를 비교해보도록 하겠습니다.

📌 Monolithic VS MSA

이미지 출처 - https://kr.tmaxsoft.com/info/storyTView.do?seq=345

아래에서는 MSA의 장점과 단점을 알아보도록 하겠습니다.

📌 MSA 장점 및 단점

📌 MSA 구현시 고려사항

MSA를 도입하기 전에 현재의 프로젝트 규모, 개발 팀의 기술 역량, 인프라 및 운영 부서와의 협업 등을 고려해야 합니다.

초기 단계의 스타트업이나 작은 프로젝트에서는 모놀리식 아키텍처가 더 적합할 수 있으며, 시스템이 점점 커지면서 복잡도가 높아지는 경우에 MSA를 고려하는 것이 좋습니다.

실제로 Netflix, Amazon, eBay, Uber 등의 유수의 글로벌 기업에서는 MSA를 구현함으로써 빠르게 확장하고 변화하는 시장 요구에 대응할 수 있는 높은 유연성을 얻었습니다.

📌 결론

프로젝트의 규모나 복잡도 등을 고려하여 MSA의 도입 여부를 결정해야 하며, 간단한 프로젝트에서는 모놀리식 아키텍처를 적용하는 것이 더 적절할 것입니다.

상황에 맞게 잘 판단하여 아키텍처 도입 여부를 결정하는 편이 좋겠습니다.