Ryan - IT

[회고] 2025년 회고 및 2026년 목표

라이언 IT — Sun, 4 Jan 2026 19:17:49 +0900

"일을 미루는 사이에 인생은 빠르게 지나간다."

- 세네카 -

작년 이맘때 작성했던 글의 일부이다.

일을 미루지는 않았지만 단순히 '일' 만 했던 해였던 것 같다.

2025년 회고

2025년 한 해 동안 아래의 성과를 정리하였다.

사실 목표를 이루지 못 한 실패가 많다.

[IT 학습]

업무를 통한 학습을 하였지만 깊이는 부족했고, 2025년에 계획했던 학습 중 일부만 진행했다.

- Spring Boot

- Kubernetes

[책]

기술 서적 보단 일반 서적을 많이 보아서 애매했다.

[언어 공부]

토익 스피킹 시험을 보았지만 목표한 IM이 아닌 IL(Intermediate Low ) 단계로 미흡했다.

일본어(JLPT N4) 시험은 취득하지 못했다.

물론 업무적으로 바쁜 한 해를 보냈다.

정신없는 한 해이긴 했지만 하나의 일을 끝낸 후 회고하지 못한 것과, 개인적인 목표를 집중하지 않았다는 것에 큰 아쉬움이 남는다.

1. DB 이관 (MariaDB -> MySQL)

이관을 위해 다음과 같은 작업을 진행하였다.

- DB 인프라 구성 -> 테이블 분석 (이관 작업 시 테이블 값이 변경되는지 안되는지 구분 정리) -> 쿼리/프로시저 분석 -> 소스 수정 -> 개발 DB DB Test -> 성능 테스트 (모든 쿼리 실행)

하지만 MySQL 에선 시퀀스 기능을 제공하지 않아 직접 시퀀스 테이블을 생성하여 테스트를 하였고 이후 운영 환경에서 성능 이슈가 발생하기도 하였다.

2. AICC (AI Contact Center) 구축

- 자체 Contact Center 가 있기에 업무의 효율성을 극대화하기 위해 도입하였다.

STT/TTS 기능이 추가 되었고 고객의 대화 시나리오를 분석하여 유의미한 대화 프로세스를 구성하였고 이를 상담원 개입없어 자체적으로 해결되도록 구성하였다.

3. 고객사 신규 인터페이스 개발 프로젝트

4. 해외 출장

2026년 목표

매년을 돌이켜 보니 목표는 거창하게 쓸 필요가 없다.

결국 이루는 건 거의 없는 것 같기에 올해는 딱 이룰 것만 쓰려고 한다.

1. 기술 스킬 향상

2025년 목표치와 동일하게 깊이 있게 기술을 접근하고 정리하려고 한다.

k8s와 spring boot의 방향은 맞았지만 큰 역량 향상은 아니었다.

올해는 Udemy 교육도 수강했기에 (Certified Kubernetes Application Developer, CKAD) 를 계획하고 있다.

추가로 바이브 코딩도 진행하려고 한다.

2. 어학 공부

영어와 일본어 2개를 진행하였지만 원하는 목표에는 실패하였다.

2026년에는 다른 방식으로 공부를 진행하려고 한다.

예를 들면 논문과 일기를 쓰는 방식을 염두하고 있다.

3. 블로그 정리

2025년 목표치에는 실패했기에 올해는 다시 새로운 배움을 블로그에 정리하려고 한다

2025년를 지내면서 스스로에게 하나 느꼈던 게 있었다.

내가 생각보다 겁이 많다는 것이다.

예를 들어 어떤 행동을 하고자 했을 때 시작과 마지막을 어느정도 모두 생각하고 움직인다는 것이다.

완벽을 추구하고 내가 행동하는 데 사유가 있어야 한다고 회로를 돌렸던 것 같다.

그치만 생각보다 많은 기회를 놓치고 있단 생각이 들었다.

마지막이 좋지 않은 결과라고 생각된다면 소극적이 되니 다른 결과가 될 수 있음에도 실패하는 것 같았던 것이다.

때론 일단 Go 마인드로 가야할 것 같다.

AI World 2025 컨퍼런스 후기

라이언 IT — Tue, 7 Oct 2025 19:04:52 +0900

첫 기조 연설을 시작으로 전반적인 AI 생태계를 이해하고 정리하는 것으로 시작했다.

알파고 vs 이세돌의 경기가 일반 사람들도 AI를 인식하게 된 계기가 아닌 가 싶다.

(이때가 2016년인데 거의 10년 가까이 되었다는 것에 신기할 따름이다.)

정부에선 AI 생태계를 위해 지원을 하겠다고 한다.

현재 소버린 AI 정예 5팀(네이버클라우드, 업스테이지, SK텔레콤, NC AI, LG AI연구원)이 선정되었고

2027년 최종 2팀을 선정할 예정이라고 한다.

자체적인 AI 모델, 데이터, 인프라를 기반 외국 기술, 클라우드 의존을 줄이는 게 소버린 1.0 이라면,

소버린 2.0은 1.0을 기반하여 B2B/B2C 산업 현장에 적용하는 것을 뜻한다.

국방부나 은행처럼의 국가의 중요시 되는 부분을 국내 AI가 맡아야 하는 것도 포함될 수 있다.

인상 깊었던 시간은 업스테이지 이활석 CTO와 퓨리오사AI 백준호 대표의 기조대담이었다.

< 백준호 퓨리오사AI 대표 >

- 반도체 칩 스타트업으로 많은 도전을 받고 있지만 결국에는 생태계에 한 축을 담당할 수 있도록 도전할 것이다.
- 자동차 업계로 비유한다면 글로벌 현대차 처럼의 위치로 성장하고자 한다.

- 자신감이 필요하며 안 되는 이유보다 되는 이유 한 가지라도 있다면 자신감과 용기를 가지고 도전해야 한다.

<이활석 업스테이지 CTO>
- 현재는 AI 탑티어 급으로 발전하며 그 후 차별화 서비스로 성장하고자 한다. (Document AI 등의 차별화)
- 고객 클라이언트가 갖춰야 할 사항은 AI, Agent 를 적용하려면 Ready 가 필요하다.

그래야 제대로 LLM 기능을 활용할 수 있고 성공할 수 있다.
- 현재의 서비스를 AI 중심으로 재개편이 필요할 수 있다. (시대 변화를 Catch 하여 적용)

개인적으로 많은 사람들이 글로벌 업체와 경쟁하며 싸우고 있다는 것을 느꼈다.
국내 서비스 SI 업을 하면서 경쟁이라는 것이 조금 낯설게 느껴졌던 나에게 신선한 자극이었다.
글로벌한 기술 향상과 그것이 국가 경쟁력이 되며 앞으로 미래 성장이 된다는 것...
또한 기술뿐만 아니라 고객 클라이언트를 만족시키며 서비스하는 영업력도 필요하고...
이번 컨퍼런스는 세상을 넓게 바라볼 수 있는 시간이었다.

[Kubernetes] 파드(Pod) yaml 정보 확인 명령어

라이언 IT — Sat, 19 Jul 2025 16:23:27 +0900

1. 현재 실행 중인 Pod YAML 정보 보기

kubectl get pod <pod-name> -n <namespace> -o yaml

(예시)

kebectl get pod my-pod -n default -o yaml

2. 어떤 ConfigMap이 마운트되었는지 확인 방법

- 출력 결과에서 Volumes 섹션이나 Mounts 섹션을 보면 어떤 ConfigMap이 마운트되었는지 확인 할 수 있음

- Pod 성격에 따라서 ConfigMap yaml 이 없을 수도 있음.

kubectl describe pod <pod-name> -n <namespace>

(예시)

kebectl describe pod my-pod -n default

ConfigMap 정보 있음

ConfigMap 정보 없음

3. ConfigMap 정보 확인

kubectl get configmap <configmap-name> -n <namespace> -o yaml

(예시)

kebectl get configmap my-configmap -n default -o yaml

[Spring] Spring / Java 버전 확인 사이트

라이언 IT — Mon, 3 Feb 2025 20:02:29 +0900

스프링 버전 확인

- https://spring.io/projects/spring-framework#support

Spring Framework

The Spring Framework provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform. A key element of Spring is infrastructural support at the application level: Spring focuse

spring.io

스프링 부트 버전 확인

- https://spring.io/projects/spring-boot#support

Spring Boot

spring.io

Oracle JAVA 버전 및 지원 기간 확인

- https://www.oracle.com/java/technologies/java-se-support-roadmap.html?form=MG0AV3

Oracle Java SE Support Roadmap

Oracle provides this Oracle Java SE Support Roadmap, to help you understand maintenance and support options and related timelines. If you are looking for the latest free JDK release from Oracle, please see oracle.com/javadownload or under an open source li

www.oracle.com

Spring Framework 및 JAVA 버전 확인

Spring Framework WIKI -> JDK 및 JAVA EE 범위 확인 가능

- https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions

Spring Framework Versions

Spring Framework. Contribute to spring-projects/spring-framework development by creating an account on GitHub.

github.com

[회고] 2024년 회고 및 2025년 목표

라이언 IT — Sun, 5 Jan 2025 20:24:00 +0900

2024년은 작은 변화와 마음에 위기감이 든 해 였다.

Mind Control 이 생각보다 안 되었지만 연말에 여러 지인들과 만남을 통해 한 가지를 제대로 느꼈다.

"내가 현실에 너무 안주하고 있었구나"

지인들의 변화하는 모습을 보니 꾸준한 노력과 목표 설정이 중요하단 생각이 들었다.

2024년 회고를 정리하고 2025년 목표 설정을 해보려 한다.

2024년 상/하반기 회고

1. 신규 인력 보강

2024년 초 신규 인력 보강이 되었다.

그동안 나는 2년 8개월 동안 혼자서 시스템을 운영해왔다.

그 과정 중에 파트 선배님들의 도움도 많이 주셨지만 실질적인 시스템 운영자는 나 혼자라 모든 연락과 대응을 도맡아 했다.

주기적인 인력 보강 요청에 대한 결과는 굴곡이 많았지만 결국 올해 결실을 거둬 적절한 업무 분장이 진행되었다.

(한편으론 당시에 조금 더 강하게 어필을 했어야 했나 생각은 든다.)

SI 업계에서 이익을 남기기 위한 인력 구조는 순탄하지 않다.

우리가 운영할 시스템이라면 합당한 값어치를 받고 일을 해야 한다고 생각한다.

고객이 적정 값어치를 지불 할 수 없다면 더 작은 규모의 SI 업체 선택을 권유하는 게 맞다고 본다.

그 후 남은 인력에 대해선 업무 순환이 빠르게 되어야 하고,

팀에 일이 없다면 다른 팀으로 이동이 자유로워야 하지만 그게 잘 안되는 것 같아 아쉬울 뿐이다.

2. 개인 시간 확보

신규 인력 추가로 야근 횟수가 줄었고 개인 시간을 확보할 수 있었다.

하지만 IT 공부 비중이 크지 않아 아쉬움이 남는다.

다음과 같은 일을 시도했다.

- 일본어 공부

- 운동 (헬스장 다니기)

- IT 공부

3. 시스템 구조 파악

사내 시스템 중에서도 가장 최신 기술 스택이 접목된 시스템을 운영하는 중이다.

그전까지 Spring 정도만 알고 있던 나로선 바로 적응하기 쉽지 않은 구조였다.

그동안 1인 운영이라는 핑계로 상세한 구조 파악까지는 할 수 없었지만,

2025년에는 하나 씩 정리하여 블로그에 남길 계획이다.

운영 시스템 구조는 다음과 같다.

- Azure PaaS 서비스 사용 (DB, Redis)

- MSA 구조

- Kubernetes 환경 (컨테이너 오케스트레이션)

- JPA

- Spring Boot

- Jenkins

2025년 목표

2024년 연말에 많은 사람들을 만났다.

사업을 하고 있는 지인, 멘토였던 선배님, 타 회사로 이직했던 선배님 등등

그리고 제대로 위기감을 느꼈다.

예전에는 같은 선상에 있었던 분들이 저만치 앞서 나가고 있는 것이었다.

보통 나는 감정 기복이 없는 편이지만 이 순간들 만큼은 예전 20대처럼의 도전 의식을 일깨워 주었다.

나는 무엇을 하고 있었을까?

2025년에는 기합넣고 시작해본다.

1. IT 학습

1) 학습 방향

- Spring Boot

- 코틀린

- 리액트(기본적인 부분만)

- 객체지향

- TDD

- JPA

- Kubernetes

2) 책

- Clean Code

- 객체지행의 사실과 오해

- 자바ORM 표준 JPA 프로그래밍

3) 기타

- 블로그 주 1회 포스팅

- 인프런 강의

2. 언어 공부

이미 일정을 선언해버렸기에 진행 중이다.

- 영어(토익 스피킹 IM~IH) (~2025년 01월)

- 일본어(JLPT N4~N3) (~2025년 1차 시험)

"기다리지 말라. 적절한 때는 결코 오지 않을 것이다."

- 나폴레온 힐 -

"일을 미루는 사이에 인생은 빠르게 지나간다."

- 세네카 -

연말에 느꼈던 또 다른 감정은 '변화'에 대한 두려움을 가지고 있었던 것이었다.

20대라면 그냥 Go 를 외쳤을 것인데, 직장을 다니고 있는 지금은 변화를 느끼고 싶지 않았던 것 같다.

20대에는 이루고자 하는 확고한 목표(취업)가 있었다.

이후 그 목표를 이루고 다른 목표가 없으니 굳이 변화를 해야 할까? 라는 생각이 스스로를 잠식시킨 게 아닐까 싶다.

이번에 다시 확고한 목표로 또 한 번 변화를 이루겠다.

[개념정리] SOA와 MSA 차이점

라이언 IT — Sun, 7 Jul 2024 15:41:20 +0900

* 공부와 업무 정리를 위해 포스팅 합니다.

* 정확하지 않는 내용이 있을 수 있으니 참고해주시면 감사하겠습니다.

<SOA, MSA 란?>

1. SOA (서비스 지향 구조)

1) 서비스가 서로 통신하는 거대한 서비스 모음.

2) SOA 프레임워크는 모든 구성 요소를 보는 서비스로서, 소프트웨어 구조를 사용하는 시스템을 설계하는 데 사용.

3) 통신은 일반적으로 데이터 전달을 위해 사용했던 SOA에서 제공되며, 두 개 이상의 서비스를 통신하고 여러 활동을 완료할 수 있음.

4) SOA 특징

- Loosely coupled (느슨한 결합)

- Reusable (재사용성)

- Composable (구성 가능)

- Autonomic (자율성)

- Standardized (표준화)

2. MSA (마이크로서비스 구조)

1) 대다수 서비스를 필요로 하고 작은 서비스 또는 공유 가능한 요소들로 분해.

-> 모든 기능이 단일 프로세스로 정립되는 것을 '모놀리스'라고도 함. (모놀리스 > SOA > MSA)

2) 다양한 프로그래밍 언어와 데이터 저장소에서 작성하는 다양한 접근 방식으로 애플리케이션과 통신을 개발하기 위해 사용.

3) MSA 특징

- Business capabilities (사업 역량)

- Products (제품)

- Smart End Point (스마트 엔드 포인트)

- Automation (자동화)

- Evolutionary (혁신)

출처 : https://medium.com/@SoftwareDevelopmentCommunity/what-is-service-oriented-architecture-fa894d11a7ec

<SOA 장점>

1. 재사용성

- 재사용되도록 서비스가 설계되고, 다양한 애플리케이션에서 사용될 수 있음.

2. 확장성

- SOA는 애플리케이션의 쉬운 확장을 위해 고려되었고, 서비스가 시스템의 영향없이 추가될 수도 삭제될 수 있음.

3. 유연성

- SOA는 조직을 새로운 사업 요구사항을 쉽게 변화나 적응을 가능하게 하고, 서비스로서 시스템 영향없이 교체하거나 업데이트할 수 있음

4. 상호운용성

- SOA는 다양한 기술과 플랫폼의 통합을 허용하므로, 다양한 시스템과 애플리케이션 연결을 더 쉽게 만듦.

5. 비용 효율성

- SOA는 장기적으로 비용 효율적이며 개발 시간을 감소시키고 애플리케이션 관리를 더 쉽게 만듦.

6. 느슨한 결합

- SOA는 서비스 사이에 느슨한 결합을 촉진하고, 이는 서비스는 서로 종속적이지 않는다는 것을 뜻함.

- 이로 인해 시스템의 유연성, 확장성과 유지보수성이 향상됨.

<SOA 단점>

1. 복잡성

- SOA는 특히 큰 규모의 시스템과 여러 서비스를 처리할 때 설계/구현/관리를 위해 복잡할 수 있음.

- 이는 전문 기술과 자원이 필요하고, 개발 시간과 비용이 증가될 수 있음.

2. 성능

- 서비스는 대기시간과 오버헤드가 발생할 수 있으며 시스템 성능에 부정적으로 영향을 미칠 수 있음.

- 서비스와 인프라 간 주의 깊은 설계와 최적화가 필요.

* In computer science, overhead is any combination of excess or indirect computation time, memory, bandwidth, or other resources that are required to perform a specific task.

It is a special case of engineering overhead - wikepidia

* 즉, 오버헤드는 특정 기능을 수행하는데 드는 간접적인 시간, 메모리 등 자원을 말함.

3. 보안

- 서비스는 네트워크를 통해 접근하기 때문에 보안이 중요하고 데이터 보안을 위해 추가 조치를 취해야 함.

- 보안 조치를 신중하게 설계/구현해야 함.

4. 테스트

- 테스트 서비스는 복잡해질 수 있고 모든 서비스가 함께 올바른 동작을 보장하는 것은 어려울 것임.

- 전문적인 테스팅 도구와 기법이 필요하고 테스팅 시간과 비용이 증가할 수 있음.

5. 거버넌스

- 확립된 표준화와 모범사례에 따라 서비스가 설계/개발/배포를 위해 적절한 거버넌스가 필요.

- 이를 위해서 포괄적인 거버넌스 프레임워크와 규정 준수 및 책임 문화 필요.

<MSA 장점>

1. 확장성

- 마이크로서비스는 쉽게 수평적으로 확장이 가능하여 시스템 성능에 영향없이 증가된 트래픽과 사용자 요청을 처리할 수 있음.

2. 민첩성

- 마이크로서비스는 팀이 서로 독립적으로 서비스를 개발하고 배포하므로 변화하는 사업 요구사항을 빠르게 적응할 수 있음.

3. 복원력 (Resilience)

- 마이크로서비스는 내결함성을 위해 설계되었고 이는 하나의 서비스가 실패하더라도 나머지 시스템에 영향을 주지 않음.

4. 재사용성

- 마이크로서비스는 여러 애플리케이션을 재사용할 수 있어서 개발 시간과 비용을 줄이고 조직의 일관성을 향상시킬 수 있음.

5. 기술 다양성

- 마이크로서비스는 다양한 서비스를 위해 다양한 기술과 플랫폼을 사용하므로, 팀이 각 서비스를 위해 가장 좋은 기술을 선택할 수 있도록 함.

6). 지속적인 전달 (Continuous Delivery)

- 마이크로서비스는 서로 독립적으로 배포와 업데이트를 할 수 있기에 지속적인 전달과 출시 시간이 단축됨.

7. 쉬운 유지관리

- 마이크로서비스는 각 서비스가 더 작고 종속성이 적기 때문에 모놀리식 애플리케이션보다 유지 관리가 더 쉬움.

8. 협업 증가

- 마이크로서비스는 팀이 독립적으로 일하게 하고 효과적으로 협업을 하기에 향상된 생산력과 개발 주기가 빨라짐.

<MSA 단점>

1. 복잡성

- 마이크로서비스는 모놀로식 애플리케이션에 비해 높은 수준의 복잡성을 도입.

- 이 복잡성은 증가된 개발 시간과 비용과 전문적인 기술과 자원이 필요.

2. 분산 시스템

- MSA는 분산된 시스템 구축을 포함하고 이는 대기 시간, 네트워크 오버헤드와 통신 복잡성이 증가될 수 있음.

3. 데이터 관리

- 다양한 서비스 간 데이터 관리는 어려울 수 있고 조직은 효과적인 데이터 관리와 동기화 전략을 구현해야 함.

4. 테스팅

- 마이크로서비스 테스트는 복잡하고 시간이 많이 소요될 수 있기에 조직은 모든 서비스가 올바르게 함께 작동하기 위해 효과적인 테스팅 전략을 구현해야 함.

5. 배포 및 인프라 관리

- 특히, 다수의 서비스를 다룰 때, 마이크로서비스를 배포와 관리하는 것은 어려울 수 있음.

- 효과적인 배포와 인프라 관리 전략을 가져야 함.

6. 보안

- 마이크로서비스는 분산되었기 때문에, 보안이 중요하며 안전한 데이터를 위해 추가적인 조치를 취해야 함.

7. 거버넌스

- 서비스가 설계/개발/확립된 표준화와 모범사례에 따라 배포되는 적절한 거버넌스 필요.

Reference

- 서비스 지향(SOA)과 마이크로 서비스 아키텍처(MSA)의 차이점

Difference between service-oriented (SOA) and Micro service Architecture (MSA) - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

- https://medium.com/@SoftwareDevelopmentCommunity/what-is-service-oriented-architecture-fa894d11a7ec

What Is Service-Oriented Architecture?

A Look At the Nuts and Bolts of Service-Oriented Architecture

medium.com

[개념정리] 추상 클래스 & 인터페이스 차이점 및 특징

라이언 IT — Sat, 15 Jun 2024 16:38:38 +0900

* 공부와 업무 정리를 위해 포스팅 합니다.

* 정확하지 않는 내용이 있을 수 있으니 참고해주시면 감사하겠습니다.

<추상 클래스 / 인터페이스 차이점>

Abstract Class	Interface
인스턴스화 될 수 없는 클래스 (객체 생성할 수 없음)	인스턴스화 될 수 없는 클래스 (객체 생성할 수 없음)
abstract, non-abstract 메소드 선언	모두 abstract 메소드 선언
일부 메소드 구현 가능 및 일부는 추상적(abstract)으로 남김	모든 메소드는 추상적(abstract) 으로 남김
추상 메소드는 상속하는 하위 클래스에서 재정의(Overriding) 필요	상속하는 하위 클래스에서 모두 재정의(Overriding) 필요

<추상 클래스 특징>

추상 클래스는 직접 인스턴스화 될 수 없는 객체 지향 프로그래밍(OOP)의 특정 유형의 클래스이며,

파생된 다른 클래스를 위한 '청사진'이나 '템플릿'의 역할을 함

1) 인스턴스화 할 수 없음

- 직접 인스턴스화 할 수 없고 객체를 생성할 수 없음

2) 하나 이상의 순수 가상 함수 포함

- 하나 이상의 순수 가상 함수를 포함해야 하고, 함수에 구현이 없으면 다른 파생된 클래스에서 구현되어야 함

3) 추상 메소드와 비추상(non-abstarct) 메소드 모두 포함할 수 있음

- 추상/비추상 클래스 메소드 모두 가질 수 있음

- 비추상 클래스 메소드는 완벽한 구현을 가지고 직접 호출할 수 있음

4) 생성자와 소멸자 가질 수 있음

- 다른 클래스처럼 생성자와 소멸자(Finalize())를 가질 수 있음

5) 멤버 변수 가질 수 있음

- 클래스 객체에 속하는 멤버 변수를 가질 수 있음

6) 기본 클래스로 사용 가능

- 기본 클래스로 사용할 수 있고, 이는 다른 클래스에 상속될 수 있는 클래스를 의미

전반적으로, 추상 클래스는 여러 관련 클래스에 의해 공유할 수 있지만 파생 클래스의 특정 구현을 사용하여 공유할 수 있는 공통 인터페이스 또는 동작을 정의하는 데 사용된다.

<인터페이스 특징>

1) 메소드와 속성 집합 정의

- 인터페이스를 구현하는 다른 클래스나 구조에 의해 구현되어야 하는 메소드 및 속성 정의

2) 공통 프로토콜 제공

- 서로 통신하기 위해 다른 소프트웨어 요소를 허용하는 공통 프로토콜 제공

3) 다형성 지원

- 인터페이스는 다형성을 달성하기 위해 사용될 수 있음

- 다만, 다른 클래스의 객체들이 동일한 인터페이스를 구현하는 한 동일한 유형에 속하는 것처럼 처리될 수 있음

4) 관심사 분리 가능

- 관심사 분리가 가능하게 함

- 즉, 인터페이스 명세서를 준수하는 한 소프트웨어 시스템의 여러 부분을 서로 독립적으로 개발될 수 있음

5) 코드 재사용성 향상

- 인터페이스는 동일한 인터페이스를 구현하는 한, 다른 소프트웨어 요소를 동일한 코드 베이스를 재사용하여 코드 재사용성 향상

6) 디자인 패턴 적용

- 디자인 패턴을 적용을 사용되게 할 수 있음

- 예를 들어, '어댑터 패턴'은 구현 클래스에서 특정 메소드나 속성을 구현하도록 요구

7) 테스트 가능

- 인터페이스를 구현하는 모의(Mock) 객체를 사용하여 서로 독립적으로 소프트웨어 요소를 테스트하게 되는 것을 허용함으로써 인터페이스는 테스트를 용이하게 함.

Reference

- Java의 추상 클래스와 인터페이스의 차이점

[개념정리] 자바(JAVA) 상속(implements / extends)

라이언 IT — Sun, 2 Jun 2024 17:52:28 +0900

* 공부와 업무 정리를 위해 포스팅 합니다.

* 정확하지 않는 내용이 있을 수 있으니 참고해주시면 감사하겠습니다.

업무를 하면서 implements와 extends 로 상속된 소스를 많이 본다.

그때마다 "상속 되었구나" 정도만 생각하고 넘어갔지만 자세한 개념 이해의 필요성을 느껴 정리해본다.

<상속(Inheritance)>

- 클래스는 단 하나의 추상 클래스를 상속할 수 있고 여러 개의 인터페이스를 구현할 수 있다.

- 추상 클래스는 객체 타입을 나타내고 인터페이스는 일련의 행동(동작)을 나타내기 때문이다.

<implements>

- 선언만 있는 interface를 상속하여 재정의(Overriding)하여 사용

- implements 로 상속할 경우 해당 interface의 메소드를 모두 재정의해야 함

- class 파일에서 implements 로 상속받아 선언 메소드를 구현하여 사용

<extends>

- 클래스/인터페이스에서 상속하여 해당 변수/메소드를 재정의(Overriding) 없이 그대로 사용 가능

- interface에서 extends 로 상속받으면 사용하고 싶은 메소드만 가져올 수 있음

Reference

- Java의 추상 클래스와 인터페이스의 차이점

로그백(Logback) / 로깅(Logging) 수준 설정

라이언 IT — Sun, 5 May 2024 11:48:22 +0900

스프링 부트 스타터 패키지(spring-boot-stater-web)에서 제공하는 로그백(Logback)을 정리해본다.

slf4j의 구현체로서 스프링 부트의 기본 로그이다.

(또 다른 구현체로는 Log4j2 가 있다)

<로깅 수준>

1. TRACE(추적) : 가장 상세한 로그 레벨

2. DEBUG(디버그) : 디버깅 목적으로 사용

3. INFO(정보) : 정보성 메시지 기록

4. WARN(경고) : 경고성 메시지 기록

5. ERROR(에러) : 오류 메시지 기록

6. FATAL(치명적) : 가장 심각한 오류 메시지 기록

7. OFF(해제) : 로그 사용안함

로깅 수준은 스프링부트에서는 application.properties 파일에서 구성할 수 있다.

INFO로 지정하면 INFO 레벨 이상에 해당하는 메시지를 볼 수 있다.

* 기본 로깅 수준은 INFO

* 운영환경에서 로깅 수준 변경은 위험할 수 있다.

- 예전 운영환경 로깅 수준을 ERROR -> DEBUG 로 변경했다가 성능 장애를 겪은 적이 있다.

'진짜' 목표를 가져야 하는 순간

라이언 IT — Sun, 7 Apr 2024 17:10:09 +0900

"시간이 정말 빠르게 지나가는 구나" 라는 것을 체감한다.

그런데 왜 시간의 소중함을 또 다시 잊는 것일까?

지금이 작년과 같을 수 없고 내년이 올해와 같을 수 없다.

수많이 계획했던 목표들은 왜 계속 반복되는 것일까?

스스로를 객관적으로 들여다 보는 시간을 소요하지 않았다고 결론을 내렸다.

말로만 목표였지 진실된 목표는 아니었다.

단순히 지금의 흥밋거리를 채우기 위한 '가짜' 목표였던 것이다.

이렇게 올해도 지나갈 것인가?

지금 블로그에 글을 쓰는 것도 이렇게 하지 않으면 작년과 똑같이 보낼 것 같단 불안감이 있기 때문이다.

많은 책을 읽었음에도 추구했던 이상적인 모습이 아닌 것은, 현재에 대한 편안함, 만족감, 안주함 이 있기 때문이다.

때로는 미래가 불안했던 20대 처럼 스스로를 긴장감에 빠트려야겠다는 생각을 한다.

아니면 우주에 식민지를 만들겠다는 것처럼 '진짜' 목표를 가슴에 새긴다면 또 모른다.

한편으론 '가짜' 목표들에서도 내가 그 순간을 진심으로 했다면 기회 창출을 이뤘을 것이다.

1. 일정관리 웹 서비스 Open (스프링부트 + 리액트)

2. 다양한 인적 네트워크 확장

3. 연애를 했었을지도..

그 기회를 놓친 것은 오로지 나의 의지이다.

스스로에게 재밌는 삶을 만들어야 하는 책임이 있다는 것을 기억하자.

앞으로 3개월.

어떤 재밌는 일을 만들 것인가 스스로를 시험해본다.