김대영 개발일지

1. 성신전자에서의 주요 성과 중 가장 기억에 남는 경험을 설명해 주세요.
   • 성신전자에서 가장 기억에 남는 경험은 조달청에 자사 주력 상품을 등록한 일입니다.
     입사 후 약 10개월이 지났을 때 겪은 경험으로 회사는 주로 '전기온돌판넬'이라는 바닥 난방 자재를 제작하는 공장을 운영하고 있었습니다. 하지만 이 제품은 가스난방이 주를 이루는 민간 아파트에서는 수요가 한정적이었고 원자재 가격이 상승하면서 이윤이 줄어드는 상황이었지만, 시장의 치열한 경쟁 때문에 판매가를 올릴 수 없는 어려움이 있었습니다.
     이 문제를 해결하기 위해 방법을 모색중 공기관에 물품을 납품할 수 있는 나라장터 라는곳을 발견했습니다. 나라장터에 상품등록을 하기 위해서는 조달청이라는 기관의 심사를 통과 하여야만 했고 이를 위해 약 6개월 동안 공장의 생산 라인과 안전 수칙, 제품 제조 과정, 자재 성분 검사 등 다양한 심사 요소를 철저히 준비하여 심사에 통과해 상품을 등록하였습니다.
     이후 첫 공기관 주문이 들어왔을 때, 그동안의 노력이 결실을 맺는 성취감을 느꼈습니다. 이 경험을 통해 새로운 시장 개척의 중요성을 배웠고, 회사의 수익성을 높이는 데 기여할 수 있어 큰 보람을 느꼈습니다.
2. 성신전자에서 매출 증가를 위해 어떤 전략을 사용했나요?
   • 성신전자에서 매출을 증가시키기 위해, 먼저 업무 효율성을 높일 방법을 고민했습니다. 제조 공장이기 때문에 하루 생산량이 정해져 있었고, 추가 판매가 이루어지더라도 야근수당과 추가 비용이 발생하면 이익률이 낮아진다는 문제를 인식했습니다.
     이를 해결하기 위해 트리 방식을 활용해 제품의 생산 과정, 작업 방식, 보관 및 출고 방식을 세부적으로 분석하고 실현 가능한 부분을 분류해 나갔습니다. 그 결과, 기존 생산량을 월평균 20% 증가시킬 수 있었고, 이를 통해 회사의 수익성을 높이는 데 기여했습니다.
3. 군복무 중 경험한 리더십 상황이 이후 직장 생활에 어떻게 도움이 되었나요?
   • 군복무 중 경험한 리더십 상황이 이후 직장 생활에 큰 도움이 되었습니다. 구체적으로는 업무 파악 및 세분화 정리, 효율적인 업무 진행을 위한 인원 배치 관리, 체크리스트 작성으로 중복 업무 실수 최소화, 그리고 정기적인 PT 발표로 진행 상황 공유 같은 경험들이 있었습니다.
     이러한 경험은 직장 생활에서 바로 적용할 수 있었습니다. 예를 들어, 업무를 체계적으로 분석하고 세분화하여 정리하는 습관은 프로젝트 관리에서 큰 도움이 되었고, 효율적인 인원 배치와 체크리스트 활용은 업무의 효율성을 크게 높이는 데 기여했습니다. 또한, 정기적인 진행 상황 공유는 회사 직원 들 간의 소통을 원활하게 하고, 협업을 촉진하는 데 중요한 역할을 했습니다
4. Java Spring을 사용한 프로젝트에서 가장 도전적이었던 부분은 무엇인가요?
5. 백엔드 개발에서 팀원들과의 협업을 어떻게 진행하셨나요?
   • 팀원들과의 협업을 진행할 때는 소통, 역할 분담, 코드 리뷰를 중심으로 진행했습니다.
     프로젝트 초기 단계에서 팀원들과 명확한 목표 설정과 기술 스택 결정을 위해 충분한 논의 거쳤으며
     정기적인 회의를 통해 각자 진행 상황을 공유하고, 발생한 문제를 함께 해결했습니다. 특히 디스코드와 노션을 활용하여 실시간으로 소통하며 작업의 효율성을 높였습니다.
     팀원은 프론트 2명, 백엔드 2명으로 각자의 강점과 관심사를 고려해 역할을 분담하였으며 Github의 이슈 등을 최대한 활용하면서 API의 기능별로 코드를 작성, 코드리뷰를 실시함으로 서로의 코드 스타일과 로직을 이해할 수 있었습니다. 이 과정에서 새로운 아이디어나 개선점을 발견할 수 있었고, 코드의 일관성을 유지할 수 있었습니다.
6. 프로젝트에서 Spring Boot를 활용한 경험을 설명해 주세요.
7. RESTful API 설계 경험이 있나요? 있다면 설명해 주세요.
8. Hibernate와 MyBatis 중 어떤 ORM을 선호하며, 그 이유는 무엇인가요?
9. CI/CD 파이프라인을 구축해본 경험이 있나요? 구체적으로 설명해 주세요.
   • HHIVE 프로젝트 진행 당시 개발 생산성 향상과 안정적인 서비스 배포를 위하여 CI/CD를 구축하였습니다.
     GitHub Actions를 활용하여 CI/CD 파이프라인 구축하였고 Docker를 이용한 애플리케이션 컨테이너화하여 독립적인 환경을 만들어 추후 추가적인 개발과정을 겪어도 영향을 받지 않도록 구성했습니다.
     AWS EC2 내 Docker compose 활용하여 여러 컨테이너로 구성된 서비스를 관리하도록 하였습니다.
     CI 과정에서 가볍고 빠른 테스트가 가능한 H2를 테스트 환경으로 활용하였고 이후 서버관리에 용이한 MySQL을 운영환경으로 적용했었습니다.
10. GitHub에 올린 프로젝트 중 하나를 선택해, 기술 스택과 역할을 설명해 주세요.
    • 제가 GitHub에 올린 대표적인 프로젝트로 HHIVE라는 프로젝트가 있습니다. 이 프로젝트는 사용자 위치 기반의 취미 공유 플랫폼으로, 여러 최신 기술 스택을 활용하여 개발했습니다. 
      1. 기술스택 
      • 백엔드:
        • Spring Boot 3.2.1과 JAVA 17을 사용해 애플리케이션의 주요 비즈니스 로직을 구현했습니다.
        • Spring Data JPA를 활용해 MySQL과 H2 데이터베이스와의 상호작용을 간편하게 관리했고, Querydsl을 통해 복잡한 쿼리도 효율적으로 작성했습니다.
        • Spring Security와 **JSON Web Token (JWT)**을 사용해 인증 및 권한 관리를 처리했으며, Spring Validation으로 입력 데이터의 유효성을 검증했습니다.
        • Spring Web Services와 JavaMailSender를 사용해 RESTful API와 이메일 전송 기능을 구현했습니다.
        • SseEmitter를 사용해 실시간 알림 기능을 추가했습니다.
        • Lombok을 통해 코드를 간결하게 유지했습니다.
      • 프론트엔드:
        • Vue.js를 사용해 사용자 인터페이스를 구현하고, 백엔드와의 통신을 통해 데이터를 처리했습니다.
      • 배포 및 인프라:
        • GitHub Actions를 사용해 CI/CD 파이프라인을 구축하여 코드 변경 시 자동으로 빌드, 테스트, 배포가 이루어지도록 설정했습니다.
        • Docker와 Docker Compose를 이용해 애플리케이션을 컨테이너화하고, AWS EC2에서 배포했습니다.
        • S3를 통해 정적 파일을 호스팅하고, Route53으로 도메인 관리를 수행했습니다.
      2. 역할:
      • 백엔드 개발에서는 프로젝트에서 모임을 생성하는 기능과 데이터베이스 설계 및 관리 등을 맡았습니다.
      • CI/CD 파이프라인 구축에서는 GitHub Actions를 활용해 자동화된 빌드, 배포 프로세스를 설정하여, 팀의 개발 생산성을 높였습니다.
      • 또한, Docker를 사용해 애플리케이션을 컨테이너화하고, 이를 AWS EC2에 배포하여 안정적인 서비스 운영을 가능하게 했습니다.
      이 프로젝트에서 저는 백엔드 개발과 CI/CD 파이프라인 구축을 담당하였으며 프로젝트를 통해 다양한 최신 기술 스택을 활용해 실무적인 경험을 쌓을 수 있었고, 팀원들과 협업하면서 프로젝트를 성공적으로 마무리할 수 있었습니다.
11. HTTP 상태 코드 중 자주 사용하는 코드와 그 의미에 대해 설명해 주세요.
    • 1. 200 OK:
      • 의미: 요청이 성공적으로 처리되었음을 나타냅니다. 서버가 요청된 리소스를 성공적으로 반환하거나, POST 요청을 통해 새로운 리소스가 생성되었을 때 사용됩니다.
      • 사용 예시: 클라이언트가 서버에 데이터를 요청했을 때, 서버가 정상적으로 데이터를 찾아서 클라이언트에 반환할 때 이 코드를 사용합니다.
      2. 201 Created:
      • 의미: 요청이 성공적으로 처리되었으며, 새로운 리소스가 생성되었음을 나타냅니다. 이 상태 코드는 주로 POST 요청 이후에 사용됩니다.
      • 사용 예시: 새로운 사용자 계정을 생성한 후, 서버가 클라이언트에게 성공적으로 계정이 만들어졌음을 알릴 때 이 코드를 사용합니다.
      3. 400 Bad Request:
      • 의미: 클라이언트의 요청이 잘못되었거나 유효하지 않음을 나타냅니다. 서버는 요청을 이해할 수 없거나 처리할 수 없습니다.
      • 사용 예시: 클라이언트가 잘못된 형식의 데이터를 서버에 보냈을 때, 서버는 이 코드를 반환하여 클라이언트가 요청을 수정하도록 합니다.
      4. 401 Unauthorized:
      • 의미: 인증이 필요한 리소스에 대해 클라이언트가 인증되지 않았음을 나타냅니다. 즉, 클라이언트가 올바른 자격 증명을 제공하지 않았음을 의미합니다.
      • 사용 예시: 사용자가 로그인을 하지 않은 상태로 인증이 필요한 페이지에 접근하려고 할 때 이 코드가 반환됩니다.
      5. 403 Forbidden:
      • 의미: 클라이언트가 요청한 리소스에 접근할 권한이 없음을 나타냅니다. 클라이언트의 인증 상태와 관계없이, 서버는 요청을 거부합니다.
      • 사용 예시: 인증된 사용자가 관리자 권한이 필요한 페이지에 접근하려고 할 때 이 코드가 반환될 수 있습니다.
      6. 404 Not Found:
      • 의미: 클라이언트가 요청한 리소스를 서버에서 찾을 수 없음을 나타냅니다. 서버는 요청된 리소스가 존재하지 않거나, 경로가 잘못되었을 때 이 코드를 반환합니다.
      • 사용 예시: 사용자가 잘못된 URL을 입력하여 존재하지 않는 페이지에 접근하려고 할 때 이 코드가 반환됩니다.
      7. 500 Internal Server Error:
      • 의미: 서버에서 예기치 않은 오류가 발생했음을 나타냅니다. 이 상태 코드는 서버가 요청을 처리하는 중에 문제가 발생했을 때 반환됩니다.
      • 사용 예시: 데이터베이스 연결 오류나 서버 코드에서 예외가 발생했을 때 이 코드를 반환할 수 있습니다.
      이 외에도 여러 HTTP 상태 코드가 있지만, 위에서 언급한 코드들은 웹 애플리케이션에서 가장 자주 사용되는 기본적인 상태 코드들입니다. 각 상태 코드는 클라이언트와 서버 간의 통신 상태를 명확하게 전달하는 데 중요한 역할을 합니다.
12. Docker를 활용한 컨테이너화 경험이 있나요? 있다면 설명해 주세요.
    • HHIVE 프로젝트 당시, 배포 환경의 일관성을 유지하고 추후 확장성과 관리 용이성을 높이기 위해 Docker에 관심을 가졌습니다. 이를 위해 Spring Boot 애플리케이션을 컨테이너화하기 위한 Dockerfile을 작성했습니다. 이후, CI/CD 파이프라인을 구축하기 위해 GitHub Actions를 사용했습니다. 코드가 변경될 때마다 자동으로 애플리케이션이 빌드되고, Docker 이미지를 생성하여 Docker Hub에 푸시한 후, AWS EC2 인스턴스에 배포했습니다.
13. 성능 최적화를 위해 어떤 방법을 사용해보셨나요?
14. Spring Security를 사용하여 인증과 인가를 구현한 경험이 있나요?
    • 네, Spring Security를 사용하여 인증과 인가를 구현한 경험이 있습니다. 제가 진행했던 SpaghettiCodingClub 프로젝트에서 이를 적용했습니다.
      1. 인증(Authentication):
      
      • Spring Security와 JWT (JSON Web Token) 기반의 인증 방식을 사용했습니다. 사용자가 로그인하면, Spring Security를 통해 자격 증명(이메일과 비밀번호)을 검증하고, 유효한 사용자인 경우 JWT 토큰을 생성하여 클라이언트에 반환했습니다.
      • 이 JWT 토큰은 이후의 모든 요청 헤더에 포함되며, 서버는 토큰을 검증하여 사용자가 인증된 상태인지 확인했습니다. 이를 통해 서버는 상태를 유지하지 않으면서도, 사용자의 인증 상태를 효율적으로 관리할 수 있었습니다.
      2. 인가(Authorization):
      • Spring Security의 **Role-Based Access Control (RBAC)**을 사용해 사용자 권한을 관리했습니다. 예를 들어, 일반 사용자에게는 ROLE_USER를, 관리 권한이 있는 사용자에게는 ROLE_ADMIN을 부여했습니다.
      • URL별 접근 제어를 설정하여, 특정 역할만 접근할 수 있는 경로를 명확히 구분했습니다. 예를 들어, /api/auths/withDraw와 같은 요청은 인증된 사용자만 접근할 수 있도록 설정했습니다.
      • 이를 위해 JwtAuthorizationFilter를 구현하여, 모든 요청에 대해 JWT 토큰을 검증하고, 사용자의 권한을 확인한 후 적절한 접근을 허용했습니다.
      3. 구현된 기능:
      • 회원가입 및 이메일 인증: 사용자가 회원가입을 하면 이메일로 인증 링크를 발송하고, 이 링크를 통해 이메일 인증을 완료하도록 했습니다. 이메일 인증이 완료된 사용자만 로그인을 할 수 있도록 Spring Security를 통해 추가적인 인증 절차를 구현했습니다.
      • 로그인 처리: JwtAuthenticationFilter를 통해 사용자의 로그인 요청을 처리하고, 인증 성공 시 JWT 토큰을 생성하여 클라이언트에 반환했습니다. 이 과정에서 사용자의 참여 트랙 정보 등도 함께 반환하여, 클라이언트가 필요한 데이터를 한 번에 받을 수 있도록 했습니다.
      • 보안 강화: JWT 토큰의 유효성 검사, 만료 처리, 잘못된 서명 검증 등을 통해 보안을 강화했습니다. 토큰이 만료되었거나 서명이 잘못된 경우, 클라이언트에 적절한 에러 메시지를 반환하도록 했습니다.
      이 프로젝트를 통해, Spring Security를 활용한 인증 및 인가 시스템을 설계하고 구현하는 경험을 쌓을 수 있었습니다. 특히, JWT를 사용해 무상태(stateless) 인증 시스템을 구축함으로써, 확장 가능하고 유지보수하기 쉬운 인증 구조를 만들 수 있었습니다.
15. 프로젝트에서 발생한 충돌 상황을 어떻게 해결했는지 설명해 주세요.
16. 학습한 기술 중 실제 프로젝트에 적용해본 사례를 설명해 주세요.
17. 블로그를 운영하면서 가장 기억에 남는 기술 포스트 주제는 무엇인가요?
18. 팀 프로젝트에서 맡았던 역할과 기여도를 설명해 주세요.
19. Spring Batch를 활용한 경험이 있나요? 있다면 설명해 주세요.
20. 코드 리뷰를 통해 얻은 가장 큰 배움은 무엇인가요?
    • 코드 리뷰를 통해 얻은 가장 큰 배움은 협업의 중요성과 코드 품질 향상입니다.
      코드 리뷰는 단순히 코드의 오류를 찾는 과정이 아니라, 팀원들과 소통하며 서로의 생각과 접근 방식을 공유하는 중요한 기회라는 것을 배웠습니다. 다른 개발자의 피드백을 통해 제 코드의 개선점을 발견할 수 있었고, 반대로 제가 제공한 피드백이 팀원의 성장을 도울 수 있다는 점에서 협업의 가치를 깊이 느꼈습니다.
      또한 리뷰 과정에서 코드의 가독성을 높이기 위해 변수명과 함수명을 더 명확하게 짓거나, 불필요한 중복 코드를 제거, 놓치기 쉬운 예외 처리나 성능 문제를 발견하고 수정하는 경험을 통해 코드 품질을 향상 시킬수 있었다는것이 가장 큰 배움이었습니다.

• 웹 개발 (Backend)
  1. Class와 Object에 대해 설명해주세요.
     • Class와 Object는 객체지향 프로그램의 기본 개념입니다.
       Class는 객체의 속성 과 동작을 정의하는 틀을 제공하는데 예를 들어 '자동차'라는 Class안에 '색상, 모델, 속도'속성 과 '전진,후진,정지'같은 동작을 정의한다는 개념으로 생각하시면 됩니다.
       Object는 Class를 기반으로 생성된 실체를 말하는대 예시로 '검은 색의 스포츠카'라는 Object는 '자동차'라는 Class를 기반으로 생성된 인스턴스로 여기서 Class에 정의된 속성값을 가지며, 정의된 동작을 수행 할 수 있습니다.
       간단히 말해, Class는 개념적 정의나 설계도이고, Object는 이 설계도를 기반으로 생성된 실제 사용 가능한 실체라고 이해할 수 있습니다.
  2. Polymorphism 개념에 대해 설명하고, 개인/팀 프로젝트에 적용한 사례가 있다면 이야기해주세요.
  3. Object 의 특성에 따라 사용할 수 있는 Data Structure 에는 어떤 것이 있는지 설명해주세요.
     
     • Array와 List 는 순서가 중요한 경우 사용합니다. 예를 들어, 학생들의 이름을 순서대로 저장할 때 Array나 List를 씁니다.
       Set 은 중복을 허용하지 않을 때 사용합니다. 참가자 명단처럼 중복이 없어야 하는 경우 Set이 적합합니다.
       Map 은 Key와 Value 쌍으로 데이터를 저장할 때 사용합니다. 예를 들어, 학생의 ID와 이름을 연결할 때 Map을 사용합니다.
       Queue와 Stack의 경우는 처리 순서가 중요할 때 사용합니다. Queue는 먼저 들어온 것이 먼저 처리될 때, Stack은 마지막에 들어온 것이 먼저 처리될 때 사용합니다.
  4. 개인/팀 프로젝트에 적용해 보았거나 / 사용할 줄 아는 RDB 에 대해 이야기해주세요.
     •  
  5. Java(Kotlin) 으로 구성된 프로젝트의 Kotlin(Java) 컨버팅 작업이 가능한지, 무엇을 염두/고려 해야하는지 이야기해주세요.
     •  
  6. Legacy Spring 과 최근 Spring 혹은 Spring Boot 의 차이점에 대해 아는대로 설명해주세요.
     
     • 설정 방식
       • Legacy Spring에서는 대부분의 설정이 XML 파일로 이루어졌습니다. 빈(bean) 정의나 의존성 주입 등을 모두 XML로 작성해야 했기 때문에 설정이 복잡하고 관리가 어려웠습니다. 반면, 최근의 Spring과 Spring Boot는 애노테이션 기반 설정을 주로 사용합니다. 설정이 훨씬 간단해지고, 코드와 설정이 밀접하게 연관되어 있어 가독성과 유지보수성이 크게 향상되었습니다. Spring Boot는 특히 자동 설정을 제공하여 개발 속도를 더욱 빠르게 합니다. 
     • 프로젝트 초기 설정과 의존성 관리
       • Legacy Spring에서는 프로젝트를 시작할 때 여러 라이브러리와 설정 파일을 직접 관리해야 했습니다. Maven이나 Ant 같은 도구를 사용해 의존성을 관리했지만, 설정이 복잡하고 일부는 수동으로 추가해야 했습니다. Spring Boot는 스타터 패키지를 통해 필요한 의존성을 자동으로 추가하고, Maven과 Gradle을 통해 의존성을 쉽게 관리할 수 있습니다. 덕분에 초기 설정 과정이 간소화되고, 프로젝트를 빠르게 시작할 수 있습니다.
     • 내장 서버
       
       • Legacy Spring은 별도의 애플리케이션 서버(Tomcat, JBoss 등)에 배포해야 했습니다. Spring Boot는 내장 서버(Embedded Server)를 제공해, 별도의 서버 설치 없이 애플리케이션을 바로 실행할 수 있습니다. 이로 인해 개발과 배포가 매우 간편해졌습니다.
     • 이런 차이점들 덕분에, 최근의 Spring과 Spring 이런 차이점들 덕분에, 최근의 Spring과 Spring Boot는 개발 생산성을 높이고, 유지보수가 더 쉬운 환경을 제공합니다.
  7. RDB와 NoSQL DB의 차이점에 대해 이야기해주세요.
     • RDB는 정형화된 테이블 구조를 사용해 데이터를 행과 열로 구성된 테이블에 저장합니다. SQL이라는 언어를 통해 데이터를 관리하며, 복잡한 쿼리와 조인을 통해 관계형 데이터를 조회할 수 있습니다. 또한, ACID 특성을 지켜 데이터의 무결성과 일관성을 보장합니다. 대표적인 RDB로는 MySQL과 PostgreSQL이 있습니다.
       대표적인 RDB로는 MySQL, PostgreSQL  등이 있습니다.
       반면, NoSQL DB는 정형화된 테이블 구조가 없고, 문서, 키-값, 그래프 등 다양한 형식으로 데이터를 저장할 수 있습니다. 이를 통해 비정형 데이터나 복잡한 데이터 구조를 유연하게 처리할 수 있습니다. SQL 대신 JSON 형식의 쿼리를 사용하며, 수평적 확장성이 뛰어나 대규모 데이터를 분산하여 저장하고 처리하는 데 유리합니다. 대표적으로 MongoDB와 Cassandra가 있습니다.
       이러한 차이로 인해, RDB는 주로 금융이나 ERP 시스템에, NoSQL은 소셜 미디어나 실시간 분석 시스템에 많이 사용됩니다. RDB는 정형화된 데이터와 복잡한 관계 관리에 강점이 있고, NoSQL은 유연한 데이터 구조와 대규모 데이터 처리에 적합합니다.
  8. RESTful API의 설계 원칙을 설명해주세요.
     • RESTful API는 웹 서비스를 설계할 때 자주 사용되며, 몇 가지 중요한 원칙이 있습니다.
       1. 자원(Resource) 기반: URL을 통해 자원을 식별합니다. 예를 들어, /users는 사용자 목록을, /users/123은 특정 사용자를 나타냅니다.
       2. HTTP 메서드 사용: GET (조회), POST(생성), PUT(전체 수정), PATCH(부분 수정), DELETE(삭제)
       3. 무상태성(Stateless): 서버는 각 요청을 독립적으로 처리하며, 이전 요청의 상태를 기억하지 않습니다. 모든 필요한 정보는 요청 안에 포함되어야 합니다.
       4. 캐싱 가능성: 응답이 캐시될 수 있어야 하며, 서버는 응답에 캐시 가능한지 여부를 명시합니다. 이를 통해 불필요한 트래픽을 줄일 수 있습니다.
       5. 일관된 인터페이스(Uniform Interface): API는 일관된 방식으로 설계되어야 합니다. 자원에 접근하는 경로, 사용되는 HTTP 메서드, 응답 형식 등이 일관성 있게 유지됩니다.
       6. 계층화된 시스템(Layered System): 클라이언트는 서버와 직접 통신하는지, 아니면 중간에 다른 계층이 있는지 알지 못합니다. 이는 보안과 확장성을 높이는 데 도움이 됩니다.
       이 원칙들을 따르면, RESTful API는 확장 가능하고 유지보수하기 쉬운 구조가 됩니다.
  9. 서버 사이드 렌더링과 클라이언트 사이드 렌더링의 차이점을 설명해주세요.
     •  
  10. 웹훅(Webhook)이란 무엇인지 설명해주세요.
      •  
  11. Redis의 주요 사용 사례를 설명해 주세요.
      •  
  12. API 버전 관리의 중요성과 방법을 설명해 주세요.
      •  
  13. 서버 보안의 기본 원칙에 대해 설명해 주세요.
      • 서버 보안의 기본 원칙은 CIA 원칙으로 요약할 수 있습니다. 이는 기밀성(Confidentiality), 무결성(Integrity), **가용성(Availability)**을 의미합니다.
        기밀성(Confidentiality): 서버에 저장된 데이터가 허가된 사용자만 접근할 수 있도록 보호하는 것입니다. 이를 위해 암호화, 접근 제어, 인증 등의 기술을 사용합니다. 예를 들어, 사용자의 비밀번호나 개인 정보는 암호화하여 저장하고, 접근 권한이 없는 사용자가 볼 수 없도록 해야 합니다.
        무결성(Integrity): 데이터가 변조되거나 손상되지 않도록 보호하는 것입니다. 데이터를 전송하거나 저장할 때, 이를 안전하게 유지하는 것이 중요합니다. 예를 들어, 데이터 전송 중 중간에서 누군가가 데이터를 변경하지 못하도록 디지털 서명이나 해시를 사용하는 방식이 있습니다.
        가용성(Availability): 서버와 데이터가 필요할 때 언제든지 접근 가능하도록 유지하는 것입니다. 이를 위해 서버의 안정성을 확보하고, DDoS 공격 같은 방해 행위로부터 서버를 보호하는 것이 필요합니다. 예를 들어, 정기적인 백업, 부하 분산, 그리고 서버 모니터링 등을 통해 서버가 항상 가동 상태를 유지하도록 합니다.
  14. 백엔드 성능 최적화 방법을 설명해 주세요.
      •  
  15. 쿠키와 세션의 차이점이 무엇인지 설명해 주세요.
      • 쿠키와 세션은 모두 사용자 상태를 관리하는 방법이지만, 작동 방식과 저장 위치에서 차이가 있습니다.
        쿠키는 사용자의 브라우저에 저장되는 작은 데이터 파일입니다. 사용자가 웹사이트를 방문할 때 서버가 브라우저에 쿠키를 저장하고, 이후 방문할 때 브라우저가 이 쿠키를 서버에 보내 사용자 정보를 전달합니다. 쿠키는 주로 사용자 설정이나 로그인 정보 등을 기억하는 데 사용되며, 만료 시간을 설정할 수 있습니다. 다만, 쿠키는 클라이언트 측에 저장되기 때문에 보안에 주의해야 합니다.
        세션은 서버 측에서 관리되는 방식입니다. 사용자가 웹사이트에 접속하면 서버가 세션을 생성하고, 사용자의 상태나 정보를 서버에 저장합니다. 브라우저에는 세션 ID라는 고유한 식별자만 저장되며, 서버가 이 식별자를 통해 사용자를 식별합니다. 세션은 서버 측에서 관리되므로 보안이 더 강화된 방법입니다. 하지만 서버의 자원을 사용하기 때문에, 많은 세션이 유지될 경우 서버에 부하가 발생할 수 있습니다.
        간단히 말해, 쿠키는 클라이언트 측에 저장되어 정보가 브라우저에 남는 반면, 세션은 서버 측에서 관리되어 보안이 더 강화된 방식입니다. 쿠키는 간편하지만 보안이 취약할 수 있고, 세션은 보안이 좋지만 서버 자원을 더 소모하는 차이가 있습니다.

1. 우리 회사에 지원한 동기를 말씀해주실 수 있을까요?
   •  
2. 직무가 되기로 한 이유에 대해 말씀해주실 수 있을까요?
   • 저는 다양한 직무를 경험하면서 문제를 해결하고 지식을 습득하는 과정에서 큰 성취감을 느껴왔습니다. 일을 사랑하고 끊임없는 자기계발을 통해 발전하는 삶을 지향하며, 자연스럽게 IT 분야에 관심을 가지게 되었습니다. 특히, 개발 분야에서는 사용자의 요구를 충족시키는 서비스를 직접 설계하고 구현하는 과정에서 더욱 깊은 만족감을 느낄 수 있었습니다.
     결국, 제가 백엔드 개발자가 되기로 결심한 이유는, 사용자 중심의 효율적인 서비스 개발을 통해 고객과 회사에 가치를 전달하고, 동료들과 함께 성장하는 문화를 만드는 데 기여할 수 있다는 확신 때문입니다."
     백엔드 개발에 관심을 두게 된 계기는, 시스템의 핵심 로직을 설계하고 성능 최적화를 통해 서비스의 효율성을 극대화하는 데 매력을 느꼈기 때문입니다. 처음 개발 공부를 시작할 때, Java와 Spring을 선택한 이유는 안정적이고 확장 가능한 시스템을 구축하는 데 있어 강력한 도구라는 점이 큰 영향을 주었습니다. 또한, Java의 탄탄한 기초 지식을 바탕으로 백엔드 개발자로서의 길을 시작하는 것이 저의 장기적인 목표와도 부합한다고 판단했습니다.
3. 첫 직장 / 다음 직장에서 어떤 걸 기대하고 있나요?
   • 이론적으로 학습한 지식을 실제 프로젝트에 적용해보고, 그 과정에서 다양한 문제를 해결하며 경험 많은 선배 개발자들과 협업하면서 실무적인 노하우와 모범적인 개발 습관을 배우고, 이를 통해 제 역량을 빠르게 키워나가고 싶습니다.
4. 지원자 님을 동기부여하게 만드는 요인이 무엇인가요?
   • 저를 동기부여하게 만드는 가장 큰 요인은 문제 해결의 과정과 결과에서 오는 성취감입니다. 복잡한 문제를 해결하거나 새로운 기술을 익히면서 겪는 도전은 저에게 큰 동기를 부여합니다. 문제를 하나씩 해결해 나가면서 느끼는 성취감은 제 스스로를 더욱 발전시키고, 더 나은 결과를 위해 노력하게 만듭니다.
5. 회사가 지원자 님을 꼭 뽑아야 하는 요소가 있다면 말씀해주실 수 있나요?
   • 저는 다양한 직무 경험을 통해 문제 해결 능력과 협업의 중요성을 깊이 이해하고 있습니다. 이를 통해 문제를 분석하고 해결하는 능력을 키웠습니다. 또한, 군복무 시절 다양한 계급과 역할을 수행하며 조직 내에서 리더십을 발휘하고 팀을 이끌어가는 경험을 쌓았습니다. 이러한 경험은 제가 조직 내에서 소통과 협력을 통해 시너지를 창출하는데 큰 기여 할수 있을거라고 생각 합니다.
     또한 스파르타 내일배움캠프에서 Java와 Spring 을 집중적으로 학습하며 대표작인 HHIVE 프로젝트를 통해 문제 해결 능력을 검증받았으며, CI/CD 구축 및 성능 최적화를 경험 하였으며 부족한점을 보충하기 위해 수료후 수료자 인원들을 모아서 추가적인 프로젝트를 진행하면서 Git의 세세한 활용과 코드리뷰는 추후 근무시에 회사에서 좀더 제 능력을 발휘하는데 크게 기여할 수 있을거라고 생각합니다.
6. 5년, 10년 후에 어떤 사람이 되고 싶나요?
   
   • 5년 후에는 기술적으로 깊이 있는 백엔드 개발자가 되고 싶습니다. 다양한 프로젝트를 경험하며, 복잡한 문제를 해결할 수 있는 능력을 갖추고, 팀 내에서 신뢰받는 개발자가 되는 것이 목표입니다.
     10년 후에는 기술 리더로서 팀을 이끌며, 회사의 중요한 프로젝트에 전략적으로 기여하는 사람이 되고 싶습니다. 더 나아가, 제가 속한 조직이 지속적으로 성장할 수 있도록 방향을 제시하고, 동료들과 함께 '함께 성장하는 문화'를 더욱 확고히 하는 역할을 하고 싶습니다. 
7. 팀 프로젝트에서 스트레스를 받거나 갈등 상황이 있을 때 어떻게 대처하나요?
   • 팀 프로젝트에서 갈등이 발생하면, 먼저 문제를 파악하고 해결 방안을 찾습니다. 업무량을 분석하고, 문제가 되는 부분을 세분화해 우선순위를 정합니다. 우선순위가 높은 일이 지체될 경우, 일정 타임라인을 설정하고 팀원들과 공유해 신속히 해결하려 노력합니다. 만약 해결이 어렵다면, 차순위 업무부터 진행해 전체 프로젝트가 원활하게 진행되도록 합니다.
8. 작업 일정이 촉박할 때 어떤 생각을 하는 편인가요?
   • 작업 일정이 촉박할 때는 우선순위 확인이 제일 먼저 생각이 듭니다
     우선 순위 확인으로 작업간에 중요도를 구분해 가장 중요한 작업에 집중하도록 하며 목록중 시간에 맞추지 못한다면 하순위 부터 제거하며 주어진 상황에서 최대한의 결과를 이끌어 내야 한다고 생각 합니다.
9. 프로젝트 / 업무 진행 중 동료와 갈등이 있었던 경험이 있나요?
   • 대표 프로젝트 진행 도중에 동료와 갈등을 겪었던 경험이 있습니다. 당시 저는 담당부분 이었던 취미모임방 만드는 부분에있어서 상황이었습니다. 모임방을 조회시 사람이 원하는 취미별로 카테고리화 하여 검색 적용하는 등의 추가 기능을 구현하는 데 있어 여러 문제가 발행했습니다. 이를 해결하기위해 기존의 엔티티 설계를 수정하여 다대다 관계에서 복합키를 사용한 중간 테이블을 생성하는 '1 대 N 관계'로 변경하는 방안을 제안 했었습니다.
     그러나 팀원 중 일부는 기존 설계를 유지하려 했고, 이로 인해 생긴 갈등을 해결하기 위해, 기존 설계의 문제점과 변경안의 장점인 데이터 무결성, 쿼리 작성의 용이성을 토대로 설득하여 테이블 설계를 변경하는 것에 팀원 모두가 동의했습니다.
10. 가장 좋았던 / 힘들었던 협업 경험을 소개해주세요.
    • 가장 좋았던 협업 경험은 HHIVE 프로젝트의 마지막 단계에서 페이지를 조성할 때였습니다. 저희 팀은 모두 백엔드 개발자들이었기 때문에, 페이지 디자인과 연동 방법에 대해 고민이 많았습니다. 그런 상황에서 우리는 빠르고 효과적인 결과를 낼 수 있는 Vue3를 선택했습니다.
      그 후 일정 기간 동안 함께 공부하며, 각자가 학습한 내용을 공유하고 기초 지식을 쌓았습니다. 이후, 각자가 맡은 부분을 Vue3를 통해 구현하고, 서로의 작업을 검토하면서 프로젝트가 점점 완성되어 갔습니다. 그 과정에서 프로젝트가 눈에 보이는 형태로 완성될 때의 성취감과 팀원들과의 협업이 정말 즐겁고 뜻깊은 경험이었습니다.
11. 소통이 어려운 상황에서 어떻게 대처하시나요?
    • 저같은 경우 소통이 어려운 상황이라는 것은 문제의 원인, 전체 맥락이 파악이 안된것이라고 생각합니다.
      이때 주로 트리 형태로 글을 정리하는데 각 인원의 요구 사항과 문제점을 세분화하여 정리하다 보면, 미처 생각하지 못했던 문제점이나 해결방안을 발견하는 데 큰 도움이 됩니다.
12. 타인과의 협업에서 가장 중요하게 생각하는 것이 무엇인가요?
    • 타인과의 협업에서 가장 중요하게 생각하는 것은 소통과 신뢰 라고 생각합니다.
      무엇보다 소통은 협업의 뼈대이자 기본이라고 생각합니다. 프로젝트를 진행하면서 발생할 수 있는 문제나 아이디어를 팀원들과 명확하게 공유하고, 서로의 의견을 경청해야 합니다. 특히 프로젝트 진행시 의문점에 대해서도 혼자 고민하지않고 팀원들과 공유하여 해결한다면 효율적인 업무진행을 이룰수 있을거라 생각합니다.
13. 친구 / 동료는 지원자 님을 어떤 사람이라고 말하나요?
    • 제 친구나 동료들은 저를 문제 해결에서 맺고 끊음이 확실한 사람이라고 말합니다.
      프로젝트 진행당시 문제의 원인을 명확하게 파악하고 팀원들의 의견조합으로 이에대한 해결책을 신속하게 끌어내고자 하였으며 프로젝트 진행과정에서도 복잡한 상황을 최대한 간소화하고 팀원간의 작업구역을 세분화하여 혼한을 최소화 하려고 노력하였습니다.
      이런 점 때문에 추후 다시 프로젝트를 진행하려고 할때 팀원들이 저를 찾는 이유였다고 생각합니다.
14. 동료와 서로 의견이 다른 경우 어떻게 조율하시나요?
    • 동료와 의견이 다를 때는 먼저 상대방의 의견을 경청하는 것이 중요하다고 생각합니다. 서로의 입장을 충분히 이해하려고 노력하면서, 왜 그런 의견을 가지고 있는지 파악하려고 합니다. 그런 다음, 객관적인 데이터나 사실을 바탕으로 논의를 진행합니다. 감정적인 논쟁을 피하고, 논리적인 근거를 통해 최선의 해결책을 찾는 것이 핵심입니다.
      예를 들어 프로젝트 진행 중에 다대다 관계의 중간 테이블 설계 문제로 팀원과 의견이 충돌했던 경험이 있습니다. 저는 복합키를 사용해 문제를 해결하자고 제안했지만, 동료는 기존 방식을 고수하려 했습니다. 이때 우리는 각자의 의견을 명확히 설명하고, 데이터와 예제를 통해 장단점을 논의했습니다. 결과적으로, 데이터에 기반한 논의를 통해 더 나은 방법을 선택할 수 있었습니다.
15. 최근에 동료에게 들은 긍정적 / 부정적 피드백을 알려주세요. 부정적 피드백은 개선하고자 어떻게 노력했나요?
    •  

이력서 작성하기

1. 뉴스피드 프로젝트

• 프로젝트명 : 직관 메이트 만들기
• 프로젝트 소개 : 우리나라에서 가장 경기 관람 인원이 많은 스포츠인 야구. 혼자 관람하고 싶지 않은 날 경기를 함께 볼 사람을 구하는 피드형 웹사이트를 제작하고자 합니다.

Github :　https://github.com/hyeon9won/newsfeed

담당부분 : 로그인 기능 구현

• Password Encoder 이해함

2. 팔팔하조 프로젝트

• 프로젝트명 : 팔팔잇츠
• 프로젝트 소개 : 배달 사이트

Github : https://github.com/palpalTeam/Palpal-Eats

Notion : https://teamsparta.notion.site/8abced91c2a8471daa12612c1754d7b2

담당부분 : Review CRUD 구현

평점 입력 구현

3.트렐로 프로젝트

• 프로젝트명 : Mission log
• 프로젝트 소개 : Trello를 모티브로한 할일목록 정리 프로젝

Github : https://github.com/sparta-spring/mission-log

Notion : https://teamsparta.notion.site/04345ca0ede5460692c051f380ad00d7

담당부분 : Board CRUD 구현

메인 페이지 구현

작업자 추가, 조회, 삭제 구현

4. 최종 프로젝트

• 프로젝트명 : HHive
• 프로젝트 소개 : Trello를 모티브로한 할일목록 정리 프로젝

Github : https://github.com/H-Hive/HHive

Notion : https://teamsparta.notion.site/HHive-56f9924035a34b94ae3b5e4ec4d1421a

담당부분 : Hive CRUD 구현

메인 페이지 구현

작업자 추가, 조회, 삭제 구현

오늘 공부한 내용

• 면접대비 2문항 공부
• 마지막 프로젝트 / 중간 발표!!

새로 알게된점

프로세스 와 쓰레드

프로세스 : 운영체제에 의해 관리되는 독립적인 작업 단위

- 각 프로세스는 독립된 메모리 공간을 할당받고, 자체적인 자원을 가지며, 다른 프로세스와는 독립적으로 실행되며 동시에 여러개의 프로세스를 실행할 수 있습니다.

쓰레드 : 프로세스 내에서 실행되는 작은 작업 단위

- 하나의 프로세스는 여러 개의 쓰레드를 가질 수 있으며, 각각의 쓰레드는 프로세스의 주소 공간을 공유하고, 동시에 실행가능하며 쓰레드는 프로세스 내에서 병렬적으로 작업을 수행하여 프로세스의 성능을 향상 시킬 수 있습니다.

프로세스와 쓰레드 의 차이점

1. 자원 소비: 프로세스는 독립된 메모리 공간과 자원을 할당받으므로, 프로세스 간의 자원 공유가 어렵고, 자원 소비가 크다. 반면에 쓰레드는 하나의 프로세스 내에서 자원을 공유하여 사용하기 때문에 자원 소비가 상대적으로 적습니다.
2. 독립성: 프로세스는 독립된 실행 단위로, 각각의 프로세스는 독립적으로 실행된다. 하지만 쓰레드는 하나의 프로세스 내에서 실행되기 때문에, 쓰레드 간의 통신과 동기화가 필요합니다. 
3. 생성과 소멸: 프로세스는 운영체제로부터 자원을 할당받아 별도로 생성되지만 쓰레드는 프로세스 내에서 생성되며, 쓰레드의 생성과 소멸은 비교적 빠르고 경제적입니다.

프로세스와 쓰레드로 구분지어서 사용하는 이유

- 운영체제에서 시스템 자원을 효율적으로 관리하기 위해서 스레드를 사용하는것 !

• 멀티 프로세스로 실행되는 작업을 멀티 스레드로 실행 할 경우, 프로세스를 생성하여 자원할당하는 시스템 콜이 줄어들어 자원을 효울적응로 관리
• 프로세사 간의 통신보다 스레드 간의 통신의 비용이 적으므로 작업들 간의 통신의 부담이 줄어듬

새로 느낀점

오늘 팀프로젝트간의 중간 발표가 있는 날이었다.

어제부터 못다한 페이지 프론트 css 작성과 코드 리펙토링으로 밤을 세우고 발표 PPT까지 만들어 제출후 팀장 동하님이 발표를 맡게되었다.

순서는 역순으로 하여 9조였던 우리조가 오히려 초반에 발표하니 맘이 좀 편했던것도 없지않아 있었다.

이후 다른 팀의 발표들을 시청하면서 우리가 생각하지 못했던 개발 방법이나 주제로 어떤방식으로 해왔는지 다양하게 알수 있어서 좋은 시간 이었다.

앞으로 마지막까지 최선을 다하여 좋은 결과를 얻고 싶다

오늘 공부한 내용

• 면접대비 2문항 공부
• 마지막 프로젝트 / 프론트 작성을 위해서 CSS 웹개발강의 재시청

새로 알게된점

OAuth

- 인터넷 사용자가 웹 사이트 또는 애플리케이션에 로그인할 때 다른 웹 사이트 또는 애플리케이션의 자원에 대한 접근 권한을 부여하는 프로토콜, 즉 외부 서비스에서도 인증을 가능하게 하고 그 서비스의 API를 이용하게 해주는 것

OAuth 의 사용배경

- 기존의 회원가입, 로그인시 아이디와 비밀번호를 제공하지 않고 싶은 욕구와 이를 통하지 않고 가입, 로그인을 하기위하여 인증과 권한을 부여하기 위한 인증방식을 찾기위해서 탄생하게 됨.

OAuth 작동 구조

1. 리소스 소유자(이하 유저)가 클라이언트 서비스를 이용하고자 이용 요청을 보냄.
2. 클라이언트는 검증 서버에 액세스 토큰을 요청.
3. 검증 서버는 유저에게 인가 동의를 요청.
4. 유저는 인가 동의를 응답.
5. 검증 서버는 리소스에 접근할 수 있는 액세스 토큰을 생성해 클라이언트로 전송.
6. 클라이언트는 액세스 토큰을 저장.
7. 클라이언트는 액세스 토큰을 가지고 리소스 서버에 요청을 보냄.
8. 리소스 서버는 액세스 토큰의 유효성을 파악하고 나서, 요청한 리소스를 클라이언트에 응답.
9. 클라이언트는 유저에 서비스 이용을 응답.

여기서 중요한것이 하나 있는데 그것은 바로 액세스 토큰!

OAuth에서 액세스 토큰 이란?

• 사용자가 인증된 후에 리소스에 접근할 수 있는 권한을 부여하는 보안 토큰을 말함.
• 제한된 기간 동안 유효하며, 인증된 사용자가 자원에 접근할 때마다 이 토큰을 제출하여 인증 및 권한 부여를 받음.
• 액세스 토큰은 애플리케이션과 인증 서버 간에 안전하게 교환되며, OAuth 프로토콜을 통해 보안을 유지하고 인가된 접근을 관리하는 데 사용됨

오늘 공부한 내용

• 코드카타 2문제
• 면접대비 2문항 공부

어려웠던 내용

새로 알게된점

• 대용량 트래픽 발생 시 에 대한 대처 방법

로드 밸런싱: 로드 밸런싱은 트래픽을 여러 대의 서버로 분산시켜 처리하는 방법입니다. 이를 통해 각 서버의 부하를 분산시켜 전체 시스템의 성능을 향상시킬 수 있습니다. 로드 밸런서를 사용하여 트래픽을 효율적으로 분산시킬 수 있습니다.

캐싱: 캐싱은 반복적으로 요청되는 데이터나 연산 결과를 저장하여 다음 요청 시에는 데이터베이스나 서버에 접근하지 않고 캐시에서 바로 응답하는 것을 의미합니다. 캐싱을 통해 서버 부하를 줄일 수 있으며, 대량의 트래픽에 대한 응답 속도를 향상시킬 수 있습니다.

자동화된 스케일 업 및 스케일 아웃: 대용량 트래픽이 발생하면 서버 용량을 자동으로 확장시키는 스케일 업(Vertical Scaling) 또는 서버 자체를 추가하여 시스템을 확장시키는 스케일 아웃(Horizontal Scaling)과 같은 자동화된 방법을 고려할 수 있습니다. 이를 통해 트래픽에 따라 시스템을 유연하게 조정할 수 있습니다.

성능 모니터링: 대용량 트래픽 상황에서는 실시간으로 시스템의 성능을 모니터링하는 것이 중요합니다. 성능 모니터링 도구를 사용하여 서버 부하, 응답 시간, 자원 사용률 등을 지속적으로 모니터링하고, 이를 기반으로 대응 전략을 수립할 수 있습니다.

오늘 공부한 내용

• 코드카타 2문제
• 면접대비 2문항 공부
• 마지막 프로젝트 / CI/CD 구현을 위한 도커 수정

새로 알게된점

도커 

- 리눅스 컨테이너에 리눅스 어플리케이션을 프로세스 격리 기술을 사용하여 더쉽게 컨테이너로 실행하고 관리할 수 있게 해주는 오픈소스 프로젝트

도커의 구성요소로는 크네 도커파일, 도커이미지, 도커컨테이너 로 이루어져 있는데 

위 순서 대로 도커 컨테이너가 생성이 된다.

Dockerfile을 작성하고 빌드하여 도커 이미지를 생성한 후, docker run 명령을 통해 컨테이너를 실행할 수 있습니다. 이를 통해 도커 컨테이너를 생성하고 실행하여 개발 및 운영 환경을 구축할 수 있다.

• 도커파일 : 컨테이너 내부에 설치할 소프트웨어, 설정값, 실행 명령 등을 명시하는 스크립트 형태의 파일

도커파일은 다음과 같은 구조로 작성 된다.

FROM base_image     	// 베이스 이미지 선택
WORKDIR / app			// 작업 디렉토리 설정
COPY source destination	// 파일복사
RUN command				// 명령실행
ENY var iable value		// 환경변수 설정
EXPOSE port				// 포트개방
CMD [""executable]		// 실행할 명령 지정 

• 도커 이미지 : 컨테이너를 생성할 때 필요항 요소, 가상 머신을 생성할때 사용하는 iso파일과 비슷한 개념
  • 저장소 이름 : 이미지가 저장된 장소
  • 이미지 이름 : 해당 이미지가 어떤 역할을 하는지 나타내며 필수로 설정해야함. ex) ubuntu:lastest -> 우분투 컨테이너를 생성하기 위한 이미지라는걸 나타냄
  • 태그 : 이미지의 버젼을 나타냄. 태그를 생략하면 도커엔진은 latest로 인식함.

• 도커 컨테이너 : 가상화된 공간을 생성하기 위해 리눅스 자체 기능인 chroot, 네임스페이스, cgroip을 사용하여 프로세스 단위의 격리 환경을 만들어낸 공간

• 도커를 사용하는 이유
  1. 성능손실이 거의 없다. / 가상공간 생성시 리눅스 자체기능을 사용하여 프로세스 단위의 격리 환경 생성
  2. 용량이 작다. / 가상 머신과 달리 커널을 공유, 컨테이너에는 라이브러리 및 실행파일 만 존재
  3. 배포하는 시간이 가상머신에 비해 빠름, 사용할때 성능손실 거의없음 / 컨테이너를 이미지로 만들었을때

어려웠던 내용

오늘 공부한 내용

• 코드카타 2문제
• 면접대비 2문항 공부
• CI/CD 구현을 위해서 스파르타 강의 시청

어려웠던 내용

새로 알게된점

• DI, IoC에 대하여

DI(Dependency Injection, 의존성 주입): DI는 IoC의 한 형태로, 클래스가 자신이 의존하는 객체를 직접 만들지 않고 외부에서 주입받는 패턴입니다. 예를 들어, 클래스 A가 클래스 B의 메서드를 사용해야 할 때, A는 B를 직접 생성하지 않고 외부에서 B의 인스턴스를 주입받아 사용합니다. 이 방식을 통해 클래스 간의 결합도를 낮추어 코드의 재사용성을 높이고, 테스트하기 편하게 만듭니다.

IoC(Inversion of Control, 제어의 역전): 전통적인 프로그래밍에서는 객체가 자신의 행동을 제어합니다. 그러나 IoC 패턴에서는 이러한 제어 흐름이 외부 컨트롤러에 의해 결정됩니다. 즉, 객체가 프로그램의 흐름을 제어하는 대신 외부에서 그 흐름을 관리하고 제어하는 것입니다. 이로 인해 코드 간의 결합도를 낮추고, 유연성과 확장성을 높일 수 있습니다.

• 객체지향 프로그래밍이란 무엇이고 어떻게 활용할 수 있나요?

정의 : 프로그램을 객체들의 집합으로 보고 이들이 서로 상호작용하도록 설계하는 방법론

ORM 이란 :  객체와 관계형 데이터베이스 간의 매핑을 자동화하는 기술을 말하며 이를 사용하면 개발자는 SQL 쿼리를 직접 작성하지 않고도 객체 지향적인 방식으로 데이터베이스와 상호 작용할 수 있다.

객체지향 프로그래밍의 핵심 원칙에는 캡슐화, 상속, 다형성이 있다.

1. 캡슐화는 객체의 상태와 행동을 하나로 묶어 외부의 접근을 제한한다.

2. 상속은 코드의 재사용성을 높이고 중복을 줄이는데 도움을 준다.

3. 다형성은 하나의 인터페이스나 클래스가 다양한 형태로 동작할 수 있게 하여 유연성과 확장성을 높인다.

이런 원칙들을 활용하면, 코드의 재사용성을 높이고, 유지보수와 테스트를 용이하게 하며, 실제 세계의 문제를 더욱 효과적으로 모델링할 수 있습니다. 예를 들어, 웹사이트에서 '사용자'라는 클래스를 만들어 각 사용자의 정보와 행동을 모델링하고, 이를 통해 각 사용자가 독립적으로 행동하도록 만드는 것입니다."

절차지향 프로그래밍과 차이점

객체지향 프로그래밍은 상속, 다형성 등의 원칙 덕분에 코드의 재사용성이 높고, 새로운 기능을 추가하거나 변경하기 쉽습니다.

하지만 절자지향 프로그래밍은 데이터와 함수를 사용하다보니 명확한 문제에 대해 직관적으로 접근하는 데 유리하지만 코드의 재사용이 상대적으로 어렵고, 기능의 변경이나 확장이 기존 코드에 영향을 미칠 수 있어서 간단한 문제나 알고리즘 구현에 많이 쓰입니다.