모눈종이에 사각사각

글또를 마무리하며

모눈종이씨 — Fri, 28 Mar 2025 00:15:41 +0900

글또를 마무리하며…

삶의 지도를 작성하여 제출한 날이 2024년 9월 22일이었고,

글또의 첫 글을 올리며 (글또와 함께할 마음다짐) 글을 열심히 써보겠다 마음 다짐을 한 게 2024년 10월 13일이었는데,

어느덧 해가 바뀌어 마지막 제출일인 2025년 3월이 되었습니다.

글또를 시작하게 된 계기는 글 쓰는 두려움을 없애고 싶었고, 글을 꾸준히 작성하는 습관을 들이고 싶었기 때문입니다.

지금 와서 생각해보면 글또는 많은 도움을 주었습니다.

2주에 한 번 어떻게든 글을 완성해서 내보기 위해 노력했고, 시간이 쌓이다보니 조금씩 부담스럽지 않게 작성할 수 있었습니다. 물론 내용에 있어서 부담감은 있었지만, 글을 작성하는 것에 대한 두려움 같은 것들은 많이 완화되었습니다.

회사에서 삽질 하면서 “이건 글또 글로 쓸 수 있겠다”고 생각하니 조금은 즐거움이 더해져서 일을 할 수 있었습니다.

실제로 겪은 일을 글로 쉽게 풀어서 설명하는게 얼마나 어려운 것인지 알게 되었습니다. 막연하게 머릿속으로 생각할 때는 ‘이렇게 저렇게 적으면 되겠군!’ 하고 노트북 앞에 앉아 작성하려고 하면 무엇부터 작성해야 하는가 고민을 많이 했고, 며칠에 걸쳐 작성하기도 했습니다.

다른 블로그 글을 읽으면서 쉽게 정리해 놓은 글을 보고 많은 생각을 하게 되었습니다. 얼마나 고민하면서 쓰셨을까, 어떻게 하면 쉽게 전달할 수 있을지, 정확한 정보일지 지우고 다시 쓰셨을 분들을 생각하니 글을 정성스럽게 마주하게 되었습니다.

“저의 다짐은 12번을 모두 작성하는 것입니다.”

글또를 처음 시작할 때 했던 다짐은 이루지 못했습니다. 중간에 2번의 PASS를 사용했고, 이 글이 열 한 번째 글이 되겠네요.(중간에 제출 기한이 늘어났었지만 2주 간격으로 제출했어서 열 한 번째!)

2주에 한 번이면 당연히 작성할 수 있지 ~ 라고 생각했던 제가 부끄럽습니다...

회사를 다니면서, 약속에 나가면서 꾸준하게 글을 작성하는 것이 쉽지 않았습니다. (매주, 주기적으로 포스팅 하는 분들 정말 존경스럽습니다..)

여행 등의 일정이 있을 때는 미리 작성하면서 11번을 어떻게든 채웠지만, 책상에 앉아 생각을 깊이 하면서 작성해야한다고 생각하니 더 쉽게 작성하지 못했던 것 같아 살짝의 아쉬움이 남습니다.

소통하지 않으면 나만의 작은 세상에 갇힐 수도 있다는 것을 깨달았고, 더 넓은 시야를 가져야 겠다는 다짐도 하게 되었습니다.

글또는 글과 친해지는 계기가 되었고, 개발자들과 소통하는 세상에 한 걸을 다가갈 수 있게 해주는 문이 되었습니다.

글또 활동은 끝이 나지만, 글또로 시작한 글쓰는 습관은 계속 이어지도록 할 것입니다.

미래에 ‘어떻게 꾸준히 글을 쓰게 되었나요?’라는 질문을 받는다면, ‘글또’를 가장 먼저 떠올릴 것입니다.

logback 적용하기

모눈종이씨 — Sun, 16 Mar 2025 15:35:03 +0900

제가 관리하고 있는 서비스에서 로그 설정이 제대로 되고 있지 않아 로그가 쌓이지 않고 있었습니다.

따라서 로깅 체계를 다시 도입하고자 했습니다.

그전에 로깅 체계를 도입하려고 할 때 항상 나오는 SLF4J, Log4j, Logback이 각각 무엇인지 알아봅시다.

SLF4J, Log4j, Logback

SLF4J, Log4j, Logback은 자바 애플리케이션에서 로깅을 처리하는 데 사용되는 라이브러리들입니다.

SLF4J (Simple Logging Facade for Java)

로깅에 대한 추상화 인터페이스 역할을 하는 라이브러리
실제 로깅 구현체(Logback, Log4j 등)와 애플리케이션 코드 사이의 추상화 계층을 제공
특정 로깅 구현체(Logback, Log4j 등)에 종속되지 않고 유연하게 변경 가능

Log4j (Apache Log4j)

Apache에서 만든 로깅 라이브러리 (초창기부터 사용됨)
로깅을 담당하는 실제 구현체

Logback

Log4j의 후속 로깅 라이브러리
SLF4J의 공식 구현체(즉, SLF4J를 사용하면 기본적으로 Logback과 연결 가능)
Log4j보다 성능이 뛰어나고 메모리 효율성이 좋음

가지고 있는 라이브러리는 다음과 같습니다.

log4j-1.2.14.jar
slf4j-log4j12-1.6.6.jar
slf4j-api-1.7.7.jar
logback-classic-1.1.3.jar
logback-core-1.1.3.jar

만약 위의 라이브러리를 모두 사용한다면 다음과 같은 에러에 마주합니다.

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/path/to/your/application/lib/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/path/to/your/application/lib/log4j-slf4j-impl-2.14.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]

그 이유는 구현체 라이브러리가 중복되어 있기 때문입니다.

따라서 한 개의 라이브러리를 선택해야 합니다.

라이브러리 선택

(출처 : [10분 테코톡] ☂️ 검프의 Logging(로깅) #1)

1. Log4j 사용할 경우

log4j-1.2.14.jar
slf4j-log4j12-1.6.6.jar
slf4j-api-1.7.7.jar

2. Logback 사용할 경우

slf4j-api-1.7.7.jar
logback-classic-1.1.3.jar
logback-core-1.1.3.jar

logback-core: 핵심 기능을 제공하는 모듈.
logback-classic: SLF4J와의 통합을 제공하는 모듈.

저는 logback 라이브러리가 SLF4J의 공식 구현체이기도 하기 때문에 logback 라이브러리로 선택했습니다.

logback 설정 파일

Spring Framework 애플리케이션에서 Logback 설정 파일을 불러오는 순서는 다음과 같습니다.

logback-test.xml
logback.xml

참고로 이 파일들은 classpath 하위에 위치해 있어야 하며, 그렇지 않은 경우 따로 설정을 해주어야 합니다. 그러나 번거로우므로 특별한 경우가 아니면 classpath 하위에 넣는 게 좋을 것 같습니다.

<configuration>

    <!-- 로그 파일이 저장될 디렉토리 경로 설정 -->
    <property name="LOG_DIR" value="./log" />

    <!-- 파일 Appender 설정 -->
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 현재 로그 파일 경로 설정 -->
        <file>${LOG_DIR}/application.log</file>
        
        <!-- 롤링 정책 설정 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
            <!-- 롤링된 파일 이름 형식 설정 -->
            <fileNamePattern>${LOG_DIR}/application.log.%i</fileNamePattern>
            <!-- 최대 파일 개수 설정 -->
            <minIndex>1</minIndex>
            <maxIndex>3</maxIndex>
        </rollingPolicy>

        <!-- 크기 기반 트리거 정책 설정 -->
        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <!-- 최대 파일 크기 설정 -->
            <maxFileSize>10MB</maxFileSize>
        </triggeringPolicy>
        
        <!-- 로그 메시지 형식 설정 -->
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} %-5level [%thread] %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
    
    <logger name="com.lotte" level="debug" additivity="false">
				<appender-ref ref="FILE" />
    </logger>

    <!-- 루트 로거 설정 -->
    <root level="error">
        <appender-ref ref="FILE" />
    </root>
</configuration>

루트 로거를 debug로 했더니 너무 많은 로그들이 남아서 루트 로거를 error로 설정하고

클래스의 가장 상위 패키지를 따로 debug 레벨로 설정했습니다.

logback을 도입하는 이 서비스의 경우에는 기능이 별로 없는 서비스 이기 때문에 이렇게 설정했지만,

기능이 많은 서비스 같은 경우는 패키지별로 더 세세히 나눠서 관리하는 것이 좋을 것입니다.

스프링 설정

Spring 애플리케이션에서는 별도의 추가 설정 없이 SLF4J와 Logback을 사용할 수 있습니다. Spring은 SLF4J를 기본 로깅 API로 사용하기 때문입니다.

사용 방법

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyApp {
    private static final Logger logger = LoggerFactory.getLogger(MyApp.class);

    public static void main(String[] args) {
        logger.info("Application started");
        logger.debug("This is a debug message");
        logger.error("This is an error message");

        // 비즈니스 로직 추가
        performTask();
    }

    private static void performTask() {
        logger.info("Performing a task");
        // 작업 수행 로직
    }
}

한글이 깨져요! 인코딩 문제 해결 과정(UTF-8 vs MS949)

모눈종이씨 — Sun, 16 Feb 2025 11:25:22 +0900

최근 인프런에서 [김영한의 실전 자바 - 고급 2편]을 수강하고 있습니다.

챕터 1에서는 어떻게보면 가장 기본이고, 꼭 알아야 하지만 시간을 들여 공부할 생각을 하지 못했던 “문자 인코딩”에 대한 내용을 수강했습니다. 이 인코딩 지식을 가지고 회사에서 문제를 해결한 경험을 소개해보겠습니다.

1. 문제 상황

최근 JSP를 통해 외부 시스템과 데이터를 주고받는 작업을 하던 중, Tomcat의 인코딩 설정을 UTF-8로 변경하면 한글이 깨져서 전송되는 문제가 발생했습니다.

기존에는 Tomcat의 인코딩 설정을 MS949로 설정하면 정상 동작했지만, 운영 환경을 UTF-8로 유지하면서도 MS949 기반 시스템과 원활하게 연동해야 했습니다. 따라서, UTF-8 환경에서 한글이 깨지지 않도록 인코딩 변환을 적용하는 방법을 찾아야 했습니다.

문제 코드 분석

1) 서비스단에서 JSP 호출

httpConn.setRequestProperty("Content-Type", "text/html; charset=utf-8");
OutputStream stream = httpConn.getOutputStream();
stream.write(data.getBytes());

서비스단에서 jsp로 전송할 때 UTF-8을 사용.

2) JSP에서 요청을 받을 때의 코드

InputStream in = request.getInputStream();
String text = IOUtils.toString(in, "EUC-KR");
byte[] sendArrayResult = messageSendClient.sendMessage(text);

UTF-8로 보낸 데이터를 JSP에서 EUC-KR로 해석.

3) 타 시스템과 연동하는 메서드 (sendMessage)

requestMessage.setData(sendData.getBytes("MS949"));

sendMessage 메서드는 MS949 인코딩된 데이터를 요구.
연동하려는 시스템에서는 MS949를 요구하기때문에 해당 인코딩은 변경할 수 없음.
JSP에서 올바르게 변환해서 전달해야 함.

2. 해결 과정

1) JSP에서 요청 데이터를 올바르게 읽기

// AS-IS
String text = IOUtils.toString(in, "EUC-KR");
// ❌ UTF-8로 전송된 데이터를 EUC-KR로 해석하면, 한글이 깨지는 문제가 발생

// TO-BE
String text = IOUtils.toString(in, "UTF-8");
// ⭕️ 서비스단에서 UTF-8로 보냈기 때문에, 동일한 UTF-8로 읽어야 한다.

서비스단에서 UTF-8로 보낸 데이터를 UTF-8로 읽도록 변경.
- UTF-8은 한글이 3byte, EUC-KR은 한글이 2byte이기 때문에 호환이 되지 않는다.

2) JSP에서 sendMessage 호출 전, MS949로 변환

// UTF-8로 읽은 후 MS949로 변환
byte[] ms949Bytes = text.getBytes("MS949");
String ms949Text = new String(ms949Bytes, "MS949");

// 타 시스템 호출
byte[] sendArrayResult = messageSendClient.sendMessage(text);

UTF-8 → MS949 변환 후 sendMessage 호출.

3. 깨달은 점

이번 문제를 해결하면서, 서버 간 데이터 교환에서 인코딩 변환의 중요성을 깨달았습니다. 특히 UTF-8로 전송된 데이터를 잘못된 방식(EUC-KR)으로 읽으면 문자 깨짐이 발생한다는 것을 명확히 이해했습니다.

그럼 문자 인코딩 변환에 대해 살짝 알아보겠습니다.

문자 인코딩 이란?

문자 인코딩은 문자를 컴퓨터가 이해할 수 있는 숫자(byte)로 변경하는 것입니다. 문자를 byte로 변경하려면 문자 집합이 필요하고, 어떤 문자 집합을 참고해서 byte로 변경할지를 정해야 합니다.

문자 집합의 종류

ASCII : 초기 표준 문자집합. (한글 미지원)
ISO-8859-1 : 서유럽 문자를 표현하는 문자 집합이 필요해짐에 따라 만들어짐. (한글 미지원)
EUC-KR : 초창기 등장한 한글 문자 집합. 자주 사용하는 한글만 포함. (한글 2바이트)
MS949 : EUC-KR을 확장하여 만듦. 더 많은 한글 글자를 포함. (한글 2바이트)
UTF-8 : 가변 길이 인코딩을 사용하여 전 세계 모든 문자를 표현 가능. (한글 3바이트)
UTF-16 : 자주 사용하는 기본 다국어들은 2byte, 그외 4바이트. (한글 2바이트)

여기서 자주 인코딩 문제가 발생하는 것은 한글입니다.

왜냐하면 영문은 사실 UTF-16 제외하면 다 1바이트이지만, UTF-16은 잘 사용하지 않으므로 한글에서 많은 문제가 발생합니다.

한글이 깨지는 가장 큰 2가지 이유

2byte : EUC-KR(자주 사용하는 한글만), MS949, UTF-16
3byte : UTF-8
UTF-8과 MS949(EUC-KR)는 인코딩 방식이 다르므로 깨짐이 발생합니다.
- UTF-8(한글 3바이트) ↔ MS949(한글 2바이트) 간 변환 시, 바이트 길이가 맞지 않아 문자 해석이 잘못될 수 있음.
- 따라서, 전송과 수신 단계에서 적절한 인코딩 변환이 필요함.
EUC-KR(MS949) 또는 UTF-8로 인코딩한 한글을 ISO-8859-1로 디코딩할 때 발생합니다.
- ASCII, ISO-8859-1은 한글 미지원.

위와같이 한글의 경우 문자 집합에 따라 2byte로 해석하기도 하고, 3byte로 해석하기도 합니다.

인코딩이 일치하지 않으면 바이트 해석이 잘못되어 글자가 깨지는 문제가 발생합니다. 따라서, 데이터가 어떤 인코딩으로 전송되고, 서버에서 어떤 인코딩으로 읽어야 하는지 명확히 정의하는 것이 중요합니다.

4. 마무리

이번 경험을 통해 인코딩 문제를 근본적으로 해결하는 방법을 배웠습니다.

한글이 깨지는 문제는 단순해 보이지만, 요청/응답 인코딩 흐름을 정확히 이해하지 않으면 쉽게 해결되지 않습니다.

물론 인코딩 문제가 발생할 때마다 구글링을 하면서 해결할 수도 있겠지만, 이렇게 한 번 깨지는 이유를 명확히 분석하고, 단계별로 변환 과정을 적용하는 방법을 터득했기 때문에 비슷한 문제가 발생해도 침착하게 해결할 수 있을 것 같습니다.

2024 회고 및 2025 다짐

모눈종이씨 — Sun, 2 Feb 2025 12:43:34 +0900

조금 늦은 2024 회고

들어가기 전

어느덧 2025년이 되고 한 달이 지났습니다. 2025년 1월 초에 2024년 회고를 하고 싶었으나, 여행 중이었기도 했고, 조금 더 깊게 생각해볼 시간이 필요해서 한 달이 걸렸습니다. 2024년을 어떻게 보냈는지, 그리고 2025년은 어떻게 지내야 할지 기록해보려고 합니다.

나의 2024년

음.. 2024년 목표를 어떻게 세웠더라~ 라고 하면서 이곳저곳 돌아다녀보는데 2024 계획을 세워놓은 기록을 찾을 수 없었습니다. 대신 2024년에 어떤 나날들을 살아왔는지 간략하게 적어보겠습니다.

1. 블로그 일상 기록 꾸준히 하기

지금까지 아날로그 다이어리를 꾸준히 써왔었습니다. 할 일 관리는 물론, 일기 까지도. 그러면서 단 한가지 아쉬운 점이 있었다면, 사진을 같이 기록하기 어렵다는 점이었습니다. 네이버 블로그 블챌에 참여한 뒤 습관이 생겨 올해는 블로그에 일상 기록을 꾸준히 해야겠다고 다짐했습니다. 매주 한 주를 정리한 위클리 일기를 작성하고, 한 달동안 일어난 일들을 정리한 월간결산을 작성하기로 했습니다.

1월부터 시작해서 12월까지 총 52개의 주간일기를 작성했고,

총 12개의 월간 결산을 작성했습니다.

2. 독서

퇴근길에 책 읽는 습관을 본격화 하기로 했습니다. 최대한 책을 읽기 위해 노력했으나 돌아오는 길에 책을 읽기 시작하면 잠에 들어서 많이 읽지 못했던 것 같습니다. 그래도 1년동안 총 28권을 읽었습니다! 한달 평균 2.3권을 읽었으니 살짝 아쉽긴 하지만 만족했습니다. 기록은 북적북적 앱을 통해 진행했습니다.

그리고 지인의 소개로 독서 모임에 참여하게 되었습니다. 한 달에 한 번씩 한 명이 책 한 권을 선택하고 발제하여 의견을 나누는 시간을 갖습니다. 가벼우면서도 진지한 모임에 앞으로의 활동이 기대되는 모임입니다.

3. 주식 투자하기

2023년 말에 만든 ISA 계좌를 통해 본격적으로 주식 투자를 조금씩 해보기로 했습니다. 씨드가 충분해진 다음에 해야 한다는 말도 많이 들었지만, 제 생각에는 씨드가 커지기 전에 작은 금액으로 조금씩 투자 연습을 하는 게 좋을 것이라 생각했습니다. 매달 일정 금액을 투자했고, 주로 ETF에 투자했습니다. 하반기에는 미국 주식도 도전해보고자 해외주식용 통장을 하나 더 만들어서 진행했습니다. 다방면으로 미래를 위한 투자를 늘려 나가고 싶습니다. 아직 부족한 점이 많지만 꾸준히 공부하며 투자해나갈 계획입니다.

4. 개발 공부 및 프로젝트

개인 프로젝트를 해보고자 다짐했고, 실제로 연초에 일부 진행했지만 중간부터 흐지부지 되어 거의 잊어버리고 지냈습니다...

5. 회사 생활

1년 만근을 한 첫 해였습니다. 프로젝트도 있었고, 이후 유지보수를 하면서 많은 것을 배웠습니다. 이제는 개발 이외에 일이 익숙해져 온전히 개발에만 집중할 수 있는 시간이 늘었습니다. 단순히 개발하는 것에 그치는 것이 아니라 이후 확장성, 유지보수를 고려하며 코드를 작성하기 위해 노력했습니다. 그리고 그럴수록 저 자신의 부족한 점을 깊게 깨달았습니다.

6. 운동

2023년에는 PT를 받았고, 2024년에는 PT 를 받지 않고 혼자서 운동을 도전했습니다. 일주일에 2회 이상 꾸준히 다녔습니다. 유튜브와 같은 채널이 있어 운동을 배우며 할 수 있었지만 여전히 아쉬웠던 점은 정말 바르게 운동하고 있는 것이 맞는가 의문이 들 때 물어볼 사람이 없다는 것이었습니다. 2025년에 다시 PT를 받아보고 싶은 생각이 있긴 하지만 금액적인 문제도 있고 하여 조금 더 고민해봐야겠습니다.

7. 외국어공부

영어 회화 자격증을 반드시 따야겠다는 2024년 초의 마음을 가지고, 처음으로 전화 영어에 도전하고, 영어 자격증 준비를 열심히 했지만 중간에 여러 이슈들이 있었고, 공부하던 흐름을 놓쳤더니 다시 돌아오기가 힘들었습니다.

⭐️HAPPY NEW YEAR 2025⭐️

즐거운 일이 가득하고, 행복한 일이 가득한 한 해가 되길, 기록을 즐기며 개발자로서 성장하는 한 해가 되길 바라는 2025년입니다.

1. 기록 즐기기

조금 더 부지런하게 기록을 즐겨보고자 합니다. 아날로그 방식으로 작성하던 일기를 다시 부활시켜 데일리 일기로 작성하고, 주간일기와 월간일기는 그대로 진행할 예정입니다. 여기에 더해 3년 일기장을 장만했습니다! 3년동안 매일 작성해 하루하루를 쌓아보고자 합니다.

2. 독서

2024년의 28권을 넘어서 2025년에는 30권 이상의 책을 읽고 싶습니다. 책을 읽는 것뿐만아니라 내용 정리 및 회고 또한 기록할 예정입니다.

3. 개발 공부 및 프로젝트

개인 프로젝트를 하나 진행해보려고 합니다. 회사를 다니면서 진행할 예정이기에 기한은 넉넉하게 1년으로 잡고, 현재 아이디어까지 정립해놓은 상태입니다. Java, Spring, Database등, 필요한 부분을 공부하면서 적용하는 방식으로 개발을 진행하고자 합니다. 물론 혼자 진행하기에 계획대로 되지 않을 수 있습니다.

4. 외국어 공부

영어, 일본어 회화 자격증 취득을 반드시 하겠습니다. 매해 세우는 다짐인 것 같지만, 올해는 정말 반드시...!!!

HttpSessionListener 사용하기

모눈종이씨 — Sun, 19 Jan 2025 20:10:06 +0900

HttpSessionListener

같은 아이디로 중복 로그인을 했을 경우, 먼저 들어온 사용자의 세션을 차단하는 기능을 만들어야 하는 상황입니다. 어떻게 구현하면 좋을까 검색을 하다가 HttpSessionListener를 사용해서 구현하는 방법을 알게 되었고, 이를 공부하면서 알게 된 점을 글로 작성해보았습니다.

HttpSessionListener란?

HttpSessionListener는 Java Servlet API에서 제공하는 인터페이스 중 하나로, 웹 애플리케이션에서 HttpSession 객체의 생명주기 이벤트를 감지하고 처리할 수 있도록 해줍니다. 즉, 세션이 생성되거나 소멸될 때 이를 감지하여 특정 로직을 실행할 수 있는 기능을 제공합니다. HttpSessionListener는 javax.servlet 패키지에 포함되어 있으며, 다음 두 가지 메서드를 제공합니다

default void sessionCreated(HttpSessionEvent se)
- 새로운 세션이 생성될 때 호출됩니다.
- 사용자 인증, 초기 설정, 세션 관리 로직 등을 실행할 수 있습니다.
default void sessionDestroyed(HttpSessionEvent se)
- 세션이 소멸될 때 호출됩니다.
- 리소스 정리, 로그 기록, 세션 통계 계산 등을 처리하는 데 유용합니다.

동작 원리

세션 생성 감지
- 사용자가 웹 애플리케이션에 접근할 때 새로운 세션이 필요하면 sessionCreated 메서드가 호출됩니다.
세션 소멸 감지
- 세션이 만료되거나 명시적으로 제거될 때 sessionDestroyed 메서드가 호출됩니다.
- 이 이벤트는 서버의 설정된 세션 타임아웃에 의해 자동으로 발생하거나, HttpSession.invalidate() 메서드를 호출하여 강제로 발생시킬 수 있습니다.

HttpSessionListener 사용 방법

HttpSessionListener를 구현한 SessionUtil 클래스 생성

import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;

public class SessionUtil implements HttpSessionListener {
		private final Logger logger = LoggerFactory.getLogger(SessionUtil.class);
		
		@Override
		public void sessionCreated(HttpSessionEvent event) {
			HttpSession session = event.getSession();
			sessions.put(session.getId(), session);
			logger.debug("sessionCreated :: {} ", session.getId());
		}
		
		@Override
		public void sessionDestroyed(HttpSessionEvent event) {
			String sessionId = event.getSession().getId();
			sessions.remove(sessionId);
			logger.debug("sessionDestroyed :: {} ", sessionId);
		}
}

web.xml에 등록

<web-app>
	<listener>
		<listener-class>com.example.SessionUtil</listener-class>
	</listener>
</web-app>

멀티스레드 환경을 고려한 SessionUtil

중복 로그인 구현 시, 다수의 사용자가 동시에 로그인을 시도하거나 로그아웃할 때 세션 정보를 관리하는 과정에서 동시성 문제가 발생할 수 있습니다. 이를 방지하기 위해 ConcurrentHashMap을 사용해 스레드 안전성을 보장하고, 필요한 경우 synchronized 키워드로 추가 동기화를 적용했습니다.

public class SessionUtil implements HttpSessionListener {
	private static final Map<String, HttpSession> sessions = new ConcurrentHashMap<>();
	private final Logger logger = LoggerFactory.getLogger(SessionUtil.class);

	@Override
	public void sessionCreated(HttpSessionEvent event) {
		HttpSession session = event.getSession();
		sessions.put(session.getId(), session);
		logger.debug("sessionCreated :: sessionId={}, userId={}", session.getId(), session.getAttribute("USER_ID"));
	}
	
	@Override
	public void sessionDestroyed(HttpSessionEvent event) {
		String sessionId = event.getSession().getId();
		sessions.remove(sessionId);
		logger.debug("sessionDestroyed :: sessionId={} ", sessionId);
	}
	
	public synchronized static void removeSessionForDoubleLogin(String userId, String nowSessionId) {
		for (String key : sessions.keySet()) {
			HttpSession session = sessions.get(key);
			if (
					userId.equals((String) session.getAttribute("USER_ID"))
					&& !nowSessionId.equals(session.getId())
					) {
						sessions.remove(session.getId());
						break;	
				}		
		}
	}
	
	public static boolean isValidSession(String sessionId) {
		return sessions.containsKey(sessionId);
	}
}

사용자가 로그인을 할 경우 사용자의 Id를 세션에 담게 됩니다. 따라서 세션에서 USER_ID에 해당하는 값으로 어떤 사용자인지 파악할 수 있습니다.
중복 로그인 세션을 지울 때 먼저 sessions Map 안에 현재 진입한 사용자의 id와 같은 id를 사용하는 세션이 있는지 찾습니다.(sessions에 이미 자신의 세션도 들어가 있으므로, 그 경우는 제외합니다.)
그리고 같은게 있다면 기존에 있던 세션을 제거합니다.

세션을 확인하고 지우는 과정에서 여러 스레드가 접근할 수 있으므로 synchroinized 키워드를 사용해 하나의 스레드만 처리할 수 있도록 했습니다.

아직 개선할 점이 많은 코드이지만, 전반적인 흐름을 잡고 다음 단계로 나아가는 데 도움이 되었으면 합니다.

JSP 페이지의 실행 순서와 컴파일 과정 이해하기 : JSP 오류 해결

모눈종이씨 — Sun, 22 Dec 2024 12:32:34 +0900

갑자기 JSP 페이지를 다뤄야 하는 상황..!

평소 JSP를 사용하지 않기 때문에 거의 모른다고 봐도 무방합니다. 그렇기 때문에 오류가 발생했을 때 해결하기 힘들더군요.

마주한 오류는 대략 다음과 같았습니다.

UT005023: Exception handling request to {경로}.jsp:java.lang.NullPointerException at 
~~ {jsp이름}_jsp.java

스택 트레이스에서 내뱉은 라인을 봐도 해당 코드가 아니고, 도대체 왜 오류가 나는가...

이를 JSP의 컴파일 순서와 함께 다뤄본다면 좋을 것 같아 글로 남겨보기로 했습니다.

JSP란 무엇일까요?

다들 아시겠지만, 일단 정의부터 한 번 보시죠.

JSP(JavaServer Pages)는 Java 기반의 웹 기술로, 정적 HTML과 동적 Java 코드를 결합하여 동적으로 웹 콘텐츠를 생성할 수 있는 서버 측 스크립팅 언어입니다. JSP는 서블릿(Servlet) 기술을 확장한 형태로, HTML 코드에 Java 코드를 삽입하여 동적인 웹 페이지를 쉽게 개발할 수 있도록 설계되었습니다.

JSP 페이지의 Life Cycle

JSP 페이지는 다음과 같은 라이프 사이클을 가지고 있습니다.

1. JSP 페이지 번역 & 컴파일 단계
2. 로딩 및 초기화 단계
3. 요청 처리 단계
4. 소멸 단계

이번 글에서는 JSP 페이지의 라이프 사이클을 따라서 어떻게 번역되고 실행되는지를 알아보려고 합니다.

JSP 컴파일 & 로딩 및 초기화

1. 클라이언트(브라우저)가 JSP 페이지를 요청한다.
2. 웹서버는 JSP 파일을 Java 서블릿 코드로 변환한다.
   - JSP의 HTML은 서블릿의 출력 메서드(`out.println`)를 통해 HTML 응답으로 변환된다.
   - JSP의 Java코드(`<% %>`, `<%= %>`)는 서블릿의 service 메서드에 포함된다.
3. 서블릿 컴파일
   - 변환된 Java 서블릿은 `.class` 파일로 컴파일된다.
   - 이후 `.class` 파일은 JVM에서 실행가능한 바이트코드로 변환된다.
   - 참고로 JSP에서 Javascript 코드는 서버에서 처리되지 않으며, 클라이언트로 전달된 후 브라우저가 해석하고 실행한다.
4. 서블릿 로드
   - 컴파일된 서블릿은 서버 메모리에 로드되고 초기화된다.
   - 이 과정은 서블릿의 `init()` 메서드에 의해 수행된다.

여기서 정리 한 번 해보면
- JSP 변환 : JSP ➡️ 서블릿 ➡️ 바이트코드 ➡️ 실행
이 순서로 된다는 것을 알 수 있습니다.

컴파일된 jsp의 java파일, class 파일 위치

여기서 의문의 드는 점 한가지, 컴파일 된 class 파일은 어디에 위치하게 될까요?
jsp 파일이 서블릿으로 변환될 때 변환된 java 파일과 컴파일된 클래스 파일은 서버의 work 디렉토리 또는 서버 설정에 따라 지정된 임시 디렉토리에 저장됩니다. 이 경로는 웹 서버 (Tomcat 등)의 설정에 따라 달라질 수 있습니다.
그리고 파일의 이름은 보통 abc.jsp -> abc_jsp.java -> abc_jsp.class 이렇게 지어집니다. (그래서 에러 스택 트레이스에 ~~_jsp.class 이런 문구들이 보였던 것입니다.)

JSP 실행 순서

JSP가 서블릿으로 변환되고 컴파일된 후, 클라이언트 요청이 들어올 때 다음의 단계를 거칩니다.

1. 클라이언트 요청
   - 클라이언트(브라우저)가 URL을 통해 HTTP 요청(GET/POST)을 보낸다.
2. 요청 전달 및 매핑
   - 웹 서버(Tomcat 등)가 요청된 URL을 확인하고 해당 JSP 파일에 매핑된 서블릿을 호출한다.
3. 서블릿 실행
   - 서블릿 컨테이너는 서블릿의 service 메서드를 호출한다.
   - 요청 메서드(GET, POST)에 따라 `doGet` 또는 `doPost`메서드가 실행된다.
4. 동적 HTML 생성
   - 서블릿은 요청 처리 후 동적 HTML을 생성한다.
5. 응답 반환
   - 생성된 HTML이 HTTP 응답으로 클라이언트(브라우저)에 반환한다.
   - 이때, JSP 파일에 포함된 Javascript도 클라이언트로 전송한다.
   - 브라우저는 HTML을 렌더링하여 사용자 화면에 표시한다.
   - 렌더링하면서 Javascript 코드를 실행한다.

JSP 파일을 수정하면 재기동이 필요할까?

java 소스를 고치면 재기동을 해야 변경사항이 적용됩니다.
그렇다면 JSP 파일을 수정할 경우에는 어떠할까요?
정답은 재기동 하지 않아도 된다 입니다.

그 이유는 다음과 같습니다.

컴파일은 최초 요청 시에만 발생합니다. 그리고 JSP가 수정되면 서버가 변경 사항을 감지하여 서블릿을 다시 생성하기 때문에 재기동하지 않아도 됩니다. JSP 파일을 수정하면 서버는 해당 JSP 파일의 변환된 서블릿과 컴파일된 클래스 파일을 자동으로 삭제 및 재생성합니다. 이때 서버는 JSP 파일의 최종 수정 시간을 감지하여 필요할경우 재컴파일합니다.

그러나,, 언제나 이대로 작동하지는 않죠?!

재기동 하지 않아도 되지만 서버 설정 및 캐싱 문제로 변경사항이 적용되지 않는 경우가 종종 있습니다.
따라서 JSP 페이지를 변경했는데 계속 적용이 되지 않는다면 바로 재기동 해보시길 바랍니다.

오류 발생 원인 파악하기

그렇다면 다시 처음으로 돌아가서 오류 로그를 파악해 봅시다.

UT005023: Exception handling request to {경로}.jsp:java.lang.NullPointerException at 
~~ {jsp이름}_jsp.java

위에서 서술한 JSP 페이지의 컴파일 및 실행 과정으로부터 추측해 보았을 때
JSP 파일이 서블릿으로 변환된 후 컴파일 된 Java 클래스 파일에서 발생한 예외입니다.

에러 스택 트레이스에서 나온 라인 번호의 JSP 페이지에 가도 해당 부분에서 발생한 에러가 아니었던 이유는, 컴파일 된 파일에서 내뱉은 에러이기 때문입니다. JSP 코드가 서블릿으로 변환된 후의 라인 번호를 출력하므로, 실제 JSP 파일의 라인을 찾아 보아도 소용이 없을 것입니다.

따라서 위의 NullPointerException 에러는 Java 코드 부분에 객체가 초기화 되지 않았거나, null 인 상태에서 메서드 호출 또는 필드 접근을 시도했을 가능성이 있다는 뜻입니다.
실제로 컨트롤러에서 JSP로 전달된 데이터가 null인 상태로 전달되었고, 해당 필드를 접근하니 발생한 에러였습니다.

한 단계 더 나아가 생각해봤을 때 JSP 페이지가 실행은 되지만, 화면에서 에러가 발생한다?

F12 개발자도구로 봤을 때 뭔가 이상하다?

그러면 Javascript나 HTML 소스에서 문제가 발생하고 있을 가능성이 높습니다.

참고
[JSP Life Cycle | Learn JSP Basics - Life Cycle of JSP]

NAS 마운트 하기

모눈종이씨 — Mon, 9 Dec 2024 12:25:37 +0900

마운트 되어있는 경로가 바뀌는 상황..
루트 권한이 없어 인프라 부서에 요청을 해야합니다.
어떻게 요청할 수 있을까요?

현재 ABC 서버에 연결되어 있는 NAS 서버의 A경로를 NFS 프로토콜로 B 경로로 마운트해주세요.

적어도 이게 무슨 뜻인지 정확하게 알고 요청드려야할 것 같아서 기본부터 파악해보기로 했습니다.

NAS(Network Attached Storage) 란?

모두가 공통으로 접근할 수 있는 디렉토리가 아닐까? 라고 생각했었습니다.

정확한 정의를 살펴보자면 다음과 같습니다.

NAS는 여러 사용자가 Wi-Fi 또는 이더넷 케이블을 통해 TCP/IP 네트워크로 파일을 저장하고 공유할 수 있는 중앙 집중식 파일 서버입니다.

저는 쉽게 "네트워크로 연결되어 있는 저장공간" 이라고 이해했습니다.

마운트(mount) 란?

그럼 마운트 한다는 표현은 어떤 뜻일까요?
마운트(mount)는 원격 파일 시스템(NAS, NFS 등)을 로컬 파일 시스템의 디렉토리 경로에 연결하는 행위를 말합니다.

NFS vs CIFS

NFS와 함께 항상 언급되는 프로토콜에는 CIFS가 있습니다.
이 둘을 함께 알아보도록 하겠습니다.

NFS와 CIFS는 네트워크상의 데이터 전송 및 파일 공유를 지원하는 프로토콜입니다.

예를 들어 NAS를 사용하면 파일을 중앙에서 저장하고 네트워크를 통해 여러 사용자가 공유할 수 있습니다. 하지만 운영 체제와 네트워크 환경이 다르기 때문에 모든 시스템이 동일한 방식으로 파일을 접근할 수는 없습니다. 이를 해결하기 위해 표준화된 프로토콜이 필요하며, NFS와 CIFS는 서로 다른 환경에서 파일 공유를 원활히 하기 위한 대표적인 프로토콜입니다.

NFS
- UNIX/Linux 기반 시스템에서 주로 사용

CIFS
- Windows 시스템에서 주로 사용

리눅스에서 NAS 마운트(Mount) 하는 방법

실제로 마운트를 진행할 때 어떤 정보들이 필요한 지 알면 요청을 할 때도 편하게 할 수 있을 것 같다고 생각했습니다.
리눅스에서 NAS 마운트를 어떤 과정을 통해 하는지 살펴보도록 하겠습니다.

1. 마운트 포인트 생성

mkdir /mnt/nas

2. 마운트 실행
   - NAS 볼륨 생성 시 부여받은 마운트 정보를 이용해 해당 볼륨을 마운트 포인트에 NFS 를 이용하여 마운트
   - mount : 파일시스템을 마운트하는 명령어. 지정한 원격 볼륨을 로컬 파일 시스템 경로에 연결한다.
   - -t : 파일 시스템 타입을 지정.

 mount -t nfs [NAS server ip]:[공유폴더경로] [로컬경로]
 mount -t nfs 10.00.00.00:/n000000_volume1 /mnt/nas

3. 마운트 정보 유지 설정
- 리눅스 서버가 재부팅 한 후에도 마운트 정보를 유지하기 위해 /etc/fstab 파일에 볼륨 정보 추가

vi /etc/fstab

- 볼륨의 마운트정보 추가

10.00.00.00:/n0000000_volume1 /mnt/nas nfs vers=3,defaults 0 0

위의 명령어 과정으로 보았을 때, NAS 마운트를 할 때 필요한 것은
NAS 서버의 ip, NAS서버의 공통 디렉토리 경로, 내 서버에서 연결할 디렉토리 경로, (연결 프로토콜 방식) 등이 있습니다.

Volume 이란?

그렇다면 위에 볼륨이라는 이야기가 나오는데 볼륨이 무엇일까요?

볼륨은 데이터를 저장하는 데 사용되는 논리적인 저장 단위를 의미합니다. 쉽게 말해서, NAS의 물리적인 저장 공간(디스크)을 사용자가 이해하고 사용할 수 있도록 묶거나 나눠 놓은 "가상의 공간"입니다.
마운트하면 사용자는 NAS의 볼륨을 마치 내 컴퓨터의 폴더처럼 사용할 수 있게 됩니다.

스토리지와 볼륨의 차이 // 시놀로지 나스 이 동영상을 봐도 도움이 될 것 같습니다.

만약에 마운트 경로가 바뀌면 어떻게 될까요?

당연히 경로가 바뀌게 되는 거니까 접근을 할 수 없을 것입니다. 그러나 다행히 마운트 경로가 바뀌는 것은 파일이나 데이터 자체에는 영향을 주지 않습니다.

참고
https://aws.amazon.com/ko/compare/the-difference-between-nfs-and-cifs/
https://guide.ncloud-docs.com/docs/nas-use-linux-classic
https://www.ibm.com/kr-ko/topics/network-attached-storage

⌜개발자 오늘도 마음 튼튼하게 성장하기⌟를 읽고

모눈종이씨 — Sun, 24 Nov 2024 19:31:39 +0900

이번 주는 다른 종류의 글을 쓰려 했지만, 너무나 감사하게도 길벗 출판사의 책 후원 이벤트에 당첨되었습니다!

여러 책이 마음에 들었으나 이번에 선택한 책은 “개발자 오늘도 마음 튼튼하게 성장하기” 입니다.

선정 이유

이 책을 선정한 이유는 좋은 개발자가 되기 위해 필요한 마음가짐과 성장 방법을 알고 싶어 선택하게 되었습니다.

최근 좋은 개발자가 되기 위해 어떠한 역량과 마음가짐이 필요한지 고민하고 있었고, 이 책이 제가 가진 질문에 대한 실마리를 제공해 줄 수 있을 것 같았습니다.

후기

처음 이 책을 읽기 시작했을 때 든 느낌은 <프로그래머, 열정을 말하다>의 조금 더 현대판 같은 느낌이었습니다. 단순하게 이론적 지식만 실려있는 것이 아니라 직접적으로 실천할 수 있는 방법까지 제시되어 있었기 때문입니다. 이 책은 집중하기 힘들고, 귀찮고, 미루고 싶은 이러한 “전투 상황”에서 우리가 마인드셋을 변화하여 어떻게 살아남을 수 있을지에 대한 구체적인 사례와 방법을 소개한 책입니다.

인상 깊게 읽었던 몇 가지의 내용을 소개해 보겠습니다.

1. 습관은 어려운 일을 쉽게 만드는 열쇠다.

우리가 평소에 하는 행동은 무의식중에 이루어지며 이것이 바로 습관입니다. “습관이 참 무서워”라는 말을 많이 하는데, 자신도 모르게 그러한 행동을 하기 때문에 그런 것이라 생각합니다. 습관이 되면 우리는 굳이 의식하지 않고도 그 행동을 하게 됩니다. 이것을 공부에 적용시키면 좋은 효과가 발생합니다.

저의 경우에는 퇴근 - 운동 - 저녁 - 휴식 - 취침 이 루틴이었는데, 여기서 휴식 대신 조금씩 공부를 하는 습관을 들여보려고 합니다. 분명히 취업하고 얼마 되지 않아서는 공부하는 습관을 가지고 있었는데 한동안 공부를 쉬었더니 다시 공부를 하지 않는 자신을 발견하게 되었습니다. 다시 공부를 시작해 봐야겠습니다.

2. 좋은 에코 체임버를 통해 최고의 프로그래머가 되어라.

에코 체임버는 자신의 생각이 반향을 일으켜 자신에게로 되돌아오는 사회적 환경을 가리킵니다. 한마디로 비슷한 사람들끼리 모인 집단에서는 이러한 환경이 잘 만들어질 수 있습니다.

에코 체임버는 좋은 쪽(예: 공부모임)으로도, 나쁜 쪽(예: 사이비)으로도 발전할 수 있습니다. 최고의 프로그래머가 되기 위해서는 좋은 에코 체임버를 찾아야 합니다.

책에서는 부트 캠프나 대학원에 들어가는 것도 좋고, 콘퍼런스에 참여하는 것, 최고의 기술 기업에서 일하는 것, 그리고 관심사에 맞는 모임에 찾아 들어가는 것을 제안합니다. 올해 네이버에서 주최한 DAN24, 인프런에서 주최하는 인프콘 등 여러 가지 참여 가능한 것들이 있는데 잘 알아보지 않았던 것 같습니다. 내년에는 이러한 행사를 수시로 확인하고 참여 등록을 하겠다고 다짐했습니다.

3. 분석 마비에 절대 빠지지 않는 방법.

목표를 향해서 무엇인가를 하기는 해야 하는데 무엇을 해야 할지 몰라 망설였던 적이 있을 것입니다. 여러 선택지에 어떤 걸 해야 할지 몰라 선택지 중에 하나를 고르는 대신 미루게 되거나, 생성적인 활동을 선택했지만 결정하기까지 오랜 시간이 걸렸던 적이 있을 것이다. 이러한 현상을 “분석 마비”라고 합니다.

이러한 분석 마비 현상을 막는 데는 수도자 정신이 효과적입니다. 지금 이 글에서 수도자 정신에 대해 자세히 소개하지는 않겠지만, 이러한 고민을 하지 않도록 루틴으로 사전에 만들어둔다면 고민하는 시간이 적어질 것입니다.

저도 위에서 다짐한 저녁에 공부하는 시간에 다음과 같은 것을 하기로 결심했습니다.

- 김영한의 자바 고급 강의 수강

- 일주일에 코딩 테스트 4문제 풀기

- 경제 서적 한 권 읽기

하루에 다 하는 것이 아니라 매일 한 가지씩 돌아가면서 해보도록 하겠습니다.

총평

위의 내용 말고도 책에서는 개발자로서 성장하기 위한 여러 가지 분석과, 설명, 실천 방법에 대해 이야기하고 있습니다.

개발자로서 성장하고 싶지만 구체적인 방법을 몰라 고민 중인 분들에게 좋은 책이 될 것이라 생각합니다. 실천 가능한 구체적인 사례와 마음가짐에 대한 조언이 직접 실천으로 옮길 수 있는 것들이라 큰 도움이 되었습니다.

길벗 출판사의 후원을 받아 서평을 작성했습니다

2024 인프콘 강의 - 경력이 늘수록 CS이론이 중요해지는 이유(최호성, 널널한 개발자)

모눈종이씨 — Sun, 10 Nov 2024 10:20:14 +0900

널널한 개발자(https://www.youtube.com/@nullnull_not_eq_null)는 취준때부터 종종 들었던 채널이다.

네트워크에 대한 이론을 공부하고 싶어서 찾던 중 알게 된 채널으로, 그림을 그려가면서 굉장히 친절하고, 얕은듯 하지만 깊고 이해하기 쉽게 설명해주셔서 좋아했던 채널이다.

널널한 개발자이신 최호성님께서 2024년 인프콘에서 “경력이 늘수록 CS이론이 중요해 지는 이유”에 대해 강의를 해주셔서 정리해보았다.

많은 강의 중에 가장 먼저 이 강의를 선택한 이유는 내가 요즘들어 고민하고 있는 주제이기 때문이다.

지난 글 프로그래머 열정을 말하다 에서 나온 내용인 “진정한 전문가가 되어라”에 대한 고민은 계속 이어지고 있기 때문이다.

발표는 다음의 순서로 이어진다.

CS이론과 경력자의 흔한 고민
개발자의 기본기
4년 전공자 vs 6개월 부트캠프 출신 비전공자
지나간 이야기
결론 및 질의응답

각 세션별로 내용을 조금씩 정리해보고, 나의 생각을 적어보고자 한다.

#1 CS이론과 경력자의 흔한 고민

경력자들이 많이 하는 고민중의 하나가 바로 “물경력”일 것이다.

5년간 일을 하고 이직을 했는데, 이직한 회사에서는 경력자이기 때문에 어느정도의 원하는 퍼포먼스가 있을 것이다.

그리고 이 경력자가 이직한 회사에서 문제가 발생해 해결해야 하는데, 원인을 찾아야 하는 상황에서 실력이 별로 없다면? 굉장히 쉽지 않은 상황이 될 것이다.

그때 사람들이 이러한 생각을 많이 한다고 한다.

“나는 경력을 잘못 쌓았구나”

“웹의 성능이나 운영에 대한 지식이 없구나..”

“5년간 실력이 늘지 않았구나 ..”

그럼 이제 묻는다.

“저 이제 어떻게 해야 하나요 .. ? ? ?”

정답은 ,, CS 공부를 해야한다는 것이다.

나도 사실 이게 제일 무섭다.

회사에서 주어진 일만 하다 보면 작은 세상에 갇히는 느낌이 든다. 그러다보면 모든 것을 아는 것처럼 착각하여 공부를 멈추게 될 수도 있다. 왜? 나는 주어진 회사 일을 잘 하고 있으니까.

하지만 갑자기 이직을 하게 되거나, 다른 업무를 맡게 되어 새로운 도메인에서 일을 해야 하는데, 경력은 어느정도 쌓여 있으면서 아무것도 할 수 없는 상태라면 .. 얼마나 부끄러운 일인가. 5년정도 되었으면 모른다고 말하기도 부끄럽지 않을까?

운영체제, 컴퓨터 구조 등 기초를 알고 있어야 한다.

그리고 이것에 배우는 순서가 있는가 하면 그렇지 않다.

예를 들어 운영체제를 공부하다가 보면 컴퓨터 구조를 공부해야 하는 게 생기고, 그래서 컴퓨터 구조를 공부하다가 보면 운영체제를 공부해야 하는 게 생김과 더불어 운영체제에서 했던 내용들이 이해가 되는 순간이 있을 것이다.

순서가 없기 때문에 일단 어떤 것이든 공부를 시작하는 게 좋을 것 같다.

공부를 하다보면 부족한 부분이 드러나고(물론 엄청 많겠지만), 그때 다시 학습해 나가면 된다.

#2 개발자의 기본기

운동선수들은 어렸을 때부터 시작하여 기본기를 갖춘다. 개발자들도 어렸을 때부터 갖추면 좋기야 하겠지만 꼭 그래야 하는 것은 아니다.

그러나, 경력이 어느정도 쌓이고 나서 다시 CS 공부를 하는 것은 결코 쉬운 선택이 아니다.

조금이라도 빨리 공부를 하는 게 좋지 않을까?

CS 이론은 거의 바뀌지 않는다. CS 지식과 같은 원론적인 이해가 없다면 계속 외우기만 하고, 응용할 수가 없다. 새로운 프레임워크 같은 것들은 계속 나오는데, 그때마다 외우기만 할 것인가?

내가 동경하는 사람의 유형 중 하나는 응용을 잘하는 사람이다. 무조건 외우기보다는 타당한 근거를 가지고 응용하는 것이다.

내가 동경하는 사람, 즉 내가 되고 싶은 사람은 그렇게 탄탄한 기초를 기반으로 응용을 잘하는 사람이다.

나는 CS 이론을 철저하게 공부하고 싶다.

CS 이론은 중요하다. 이제라도 늦지 않았으니 하루에 2시간이라도 공부를 해야 한다.

#3 4년 전공자 vs 6개월 부트캠프 출신 비전공자

4년동안 전공을 하면서 배운 사람의 지식의 양에 해당하는 내용을 6개월간 공부를 하려면 쉽지 않을 것이다.

그만큼 노력해야 한다.

복수 전공으로 하기는 했지만 나도 찐 전공자는 아닌듯하다.

그만큼 경각심을 가지고 더욱 노력해야겠다.

우리가 해볼 고민들

(필수) CS 공부를 하지 않으면 결국 개발자로 살아가는 동안 후회한다.

모든 개발자에게 CS 이론은 중요하다.
나는 왜 개발자가 된 것인지 다시 생각해보자
분야에 따른 차등을 인정하더라도 최소한의 지식은 필수이다.

(선택) 목표에 대해 진지하게 다시 생각해 볼 것

나는 어떤 이유로 개발자가 되려는 것인지 스스로에게 질문하기
앞으로 얼마나 오랫동안 개발자로 살아갈 것인가?
다양한 분야에 대해 알아가고 자기 분야에 대한 ‘독보적’ 전문성 확보

(선택) 고령화 및 AI시대가 가져올 변화에 충실히 대비

2차 베이비부머 세대(1964~1974)의 은퇴에 따른 사회적 변화에 대비
신입과 경력의 차이를 두지 않을 가능성에 대비 (실력있는 개인 ,,)
AI를 너무 두려워할 이유는 없음.
- 이제는 인공지능을 빼고 이야기할 수는 없음.

프로그래머, 열정을 말하다

모눈종이씨 — Sun, 27 Oct 2024 15:42:52 +0900

제가 좋아하는 유튜브인 “드림 코딩”.

드림 코딩에 첫 영상이 올라왔을 때 우연한 알고리즘으로 만나게 되어 꾸준히 잘 보고 있는 유튜브입니다.(최근에는 바쁘신지 영상 올리는 텀이 길어진 듯 하네요.)

https://youtu.be/bdYiZzNa278?si=XDRzwgpHg4sVXSN0

이 영상이 올라왔을 때 흥미롭게 봤고, 곧바로 해당 영상에서 추천하는 책을 사서 읽어보았기에 2년 정도 지났지만, 이번 글을 쓰기 위해 다시 한번 읽어 보았습니다.

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

프로그래머 열정을 말하다 | 채드 파울러 - 교보문고

프로그래머 열정을 말하다 | 『프로그래머 열정을 말하다』는 재즈 색소폰 연주자 출신 저자 채드 파울러가 자신의 경력에서 성취와 행복을 찾는 방법을 소개한 책이다. '올바르게 선택하라.', '

product.kyobobook.co.kr

그중 가장 감명 깊게 읽었던 몇 개의 챕터를 정리해 보았습니다.

가장 못하는 사람이 되어라

가장 못하는 사람이 되라니? 이게 무슨 소리지? 라고 생각할 수 있습니다.

여기서 가장 못하는 사람이 되라는 것은 더 잘하는 사람들을 찾아서 그 무리에 들어가라는 뜻입니다.

누구와 일하느냐는 것만으로도 기술이 엄청나게 늘거나 퇴보할 수 있다. 사람이 집단을 이뤄 오래 일하면 업무 수행 능력에 지속적으로 영향을 받을 수 있다.
주변 사람이 자신의 능력에 영향을 준다.
주변 사람을 신중하게 선택하라.

내가 마음대로 회사 사람을 바꾸거나 친구들을 바꿀 수 있을까? 그럴 수 없는 게 현실입니다.

그러나 지금이 어떠한 시대일까요? 오프라인보다 온라인이 훨씬 더 발달해 있는 시대입니다.

그런 의미에서 글또에 들어오게 된 건 정말 좋은 기회인 것 같습니다.

훨씬 열심히 살고 잘하시는 분들이 많다는 사실을 슬랙을 읽으면서 알고 있기 때문이죠.

그리고 책에서 알려준 방법은 내가 이루려는 높은 단계에 있는 오픈소스 프로젝트를 하나 고르고 코드를 짜서 제출하라는 것이었습니다.

두 달 정도밖에 남지 않았지만, 올해 안으로 오픈소스 프로젝트를 하나 골라서 들여다봐야겠습니다.

다재다능한 사람이 되어라

만물박사는 애플리케이션 코드가 어떻게 동작하는지 알 뿐 아니라 웹 서버 프로세스의 하위 수준 유닉스 디버깅도 할 줄 안다.

하나를 습득하고 다른 하나에 능숙해지라. 자신의 기술이 기술 플랫폼을 넘나들어야 한다. 기술은 단지 도구일 뿐이다.

제가 동경하고, 되고 싶은 사람의 모습. 다재다능한 사람입니다.

개발자로서 다재다능한 사람이란 어떤 사람일까요?

백엔드 개발자로서 다재다능한 사람은 본인의 개발 영역은 물론 서버, DB, 네트워크까지 할 수 있는 사람이 아닐까 하는 생각을 했습니다.

지금은 신입 개발자로서 개발 실력을 키우는 데 집중하고, 네트워크와 DB 등 조금씩 영역을 확장해 나갈 예정입니다.

진정한 전문가가 되어라

상위 수준 추상화를 다루면서 그러한 추상화 구현의 세세한 부분을 이해하는 사람을 원했다. 앞으로 부딪힐 수 있는 배치 문제를 풀 수 있다거나 풀지 못한다면 최소한 도움을 요청할 만한 사람을 아는 사람이 필요했다.

책에서 자바 전문가 수천 명이 공개 채용에 응시했지만 자바 클래스 로더가 어떻게 작동하는지 설명하거나 JVM이 일반적으로 메모리 관리를 어떻게 처리하는지 요약할 수 있는 사람은 아무도 없었다고 합니다.

그러나 전문가라고 말하기 위해서는 적어도 위의 내용들은 알아야 하는 게 아닐까요?

곧바로 정확히 답변할 수 있는 저의 모습을 보고 부끄러웠고, 반성했습니다.

적어도 주로 사용하는 자바 정도는 어떻게 동작하는지 다시 공부해야겠습니다.

물 양동이 속 자갈

결코 편해지면 안 된다는 것이었다. 그는 매일 일어나면서 자신이 언제든지 현재 지위에서 떨어질 수도 있다고 의도적으로, 그리고 분명하게 상기한다고 고백했다. "그게 오늘일지도 몰라요." 그가 말했다.

우리는 모두 대체될 수 있다. 이것을 사실로 받아들이고 그렇게 일하는 사람은 자신을 실제로 변화시킬 수 있고 두말할 것 없이 자신만의 기회를 활용할 수 있다. 그리고 여러분이 누구와도 대체될 수 있다면, 더 크고 나은 직장으로 떠나는 것은 당연한 일로 아무도 못 말린다.

회사에서 우리의 존재는 물 양동이 속 자갈입니다.

자갈 때문에 물 높이는 더 올라가지만, 내 일을 다하고 양동이에서 자갈을 꺼내어 뒤돌아보면 그렇게 큰 차이가 없죠.

회사에 들어가자마자 조금 많은 조직 변동이 있었고, 그 과정을 거치면서 위의 내용을 실감하게 되었습니다.

회사에 굉장히 오래 있고, 앞 챕터에서 나온 설명처럼 다재다능한 분께서 회사를 떠나게 된다면, 과연 돌아갈까? 잘 살아남을 수 있을까? 걱정했지만, 회사는 아무 일 없었다는 듯이 돌아갔습니다. 그분께서 회사 생활 내내 남겨 놓은 문서와 기록들 덕분이 아닐까 생각합니다.

저도 회사에서 프로세스를 분석할 때 모두가 볼 수 있는 곳에 문서로 정리하면서 분석하는 편입니다.

그러면 저 자신도 나중에 프로세스를 다시 들여다볼 때 이해하기 쉽고, 같이 일하시는 분도 이해하기 편할 것 같아서 하는 것이었습니다.

해당 내용이 책에도 있어서 새삼 즐겁게 읽었습니다.

유지보수를 즐기라

버그가 나타나 애플리케이션 하부 시스템을 다시 설계해야 한다면 어떻게 될까? 하부 시스템 재설계는 버그 수정의 일부다. 설계는 낡고 진부할 것이고 깨진 창문은 시스템 여기저기에 흩어져 있을 것이다. 자신의 리팩터링 능력을 시험해 볼 기회다. 어떻게 하면 이 시스템이 우아해질 수 있을까? 이번 리팩터링으로 다음번에는 얼마나 더 빨리 이 부분을 고치거나 개선할 수 있을까?

유지보수는 현재 저의 주 업무이다. 유지 보수는 어떻게 보면 열심히 해도 티도 안나고 지루할 수도 있습니다.

하지만 이것들 모두 마인드셋의 차이가 아닐까 생각합니다.

유지 보수를 저의 “리팩터링 능력을 시험해 볼 기회”로 삼고 열심히 해봐야겠습니다.

당장 내일 회사에 가서 적용해 보겠습니다.

모험 여행 안내자

뻔한 이야기이지만, 일터에서 말을 주고받을 때 가장 중요한 측면은 의사소통 능력이다.
고객은 자기가 하는 프로젝트에 대해 편하게 말해줄 사람을 찾으려 한다.
고객은 개발자를 두려워한다.
개발자는 IT 세계라는 까다로운 세계를 여행하는 고객의 안내자다.
소프트웨어 관련 문제를 토론할 때는 고객에게 약간 쉽게 이야기할 필요가 있다. 너무 기술적이지도 너무 우둔하지도 않게, 섬세하게 균형을 잡아야 한다.

고객사분들과 일을 하면서 느낀 점 중에 하나는 그분들은 IT의 전문가가 아닌 우리가 다루는 서비스의 도메인의 전문가 라는 것입니다.

회사에 들어간지 얼마 되지 않아 고객사분들과 이야기 할 기회가 있었습니다.

내용은 정확히 기억나지 않지만, 제가 말을 했더니 바로 선배가 옆에서 쉬운 단어로 순화해서 이야기해주는 걸 보고 아차 싶었습니다.

이분들은 모르는 개념일 수 있고, 그렇기에 이해하기 쉽도록 이야기해야 한다는 것을 깨달았습니다.

그 뒤로는 최대한 어떻게 하면 이해하실 수 있을까 고민하고 이야기할 수 있는 계기가 된 사건이었습니다.

자신의 목소리가 들리게 하라

실력이 좋다고 해서 항상 취업이 잘되지는 않는다.
네트워크에 연결된 곳이 많을수록 완벽한 일자리나 경력 전환점에 연결될 가능성이 더 높아진다. 스스로 자신을 현재 일하는 회사에 묶어두면 형성할 수 있는 네트워크 연결 수에 심각한 한계까 생긴다.
어떻게 해야 아무개 프로그래머에서 소문난 발표자나 저자(또는 역자)가 될까? 웹에서 시작하라.
첫째, 블로그를 읽는다.
둘째, 자신만의 블로그를 개설한다.
셋째, 글쓰기 기술을 연습하라.

지금 하고 있는 것! 글쓰기란 참 쉽지 않은 것 같습니다. 그럼에도 불구하고 열심히 할 것입니다.

책의 초반에 다음과 같은 구절이 나옵니다.

큰 투자를 하려고 한다. 큰돈을 투자하는 게 아니라 자신의 시간, 바로 자신의 삶을 투자하는 것이다.

내 시간, 내 삶을 투자해서 살아가는 만큼 신중하고, 소중하게 투자하고 싶습니다.

앞으로 어떻게 될지는 모르지만,

개발자로서의 삶을 선택한 만큼 개발자로서 의미 있게 살아가고 싶습니다.