또라이개발자

CHAAK 서비스 종료, 그리고 회고

anyjava — Thu, 6 Feb 2025 21:45:50 +0900

오늘 오전, 일상을 밈처럼 CHAAK 서비스가 종료되었습니다.
출근 후 가장 먼저 한 일이 API 서버들을 종료(shutdown)하는 것이었죠.
지난해 7월에 시작해, 짧지만 5개월간 운영된 서비스였습니다.

우리는 재미있는 제품을 만들어보고 싶다는 마음으로 모였고, 수차례의 피벗 끝에 제품을 출시할 수 있었습니다. 그 과정에서 팀과 저는 많은 것을 배웠습니다.

무엇보다 초기 제품 출시에서 가장 중요한 것은 빠른 대응을 위해 배포 속도를 높이는 것이었습니다.

그 결과, 우리 제품팀은 앱 출시 후 5개월 동안 앱스토어 배포를 총 43번 진행했습니다.
특히 한 달 동안 11번의 앱 배포를 하며, 고객의 니즈에 빠르게 대응하고자 했습니다.
그 기간 동안 Feature Flag와 Trunk-Based 개발 방식을 활용해 API 배포는 하루에도 수십 차례 진행되었습니다.
또한, 클라이언트 개발에는 Flutter를 선택하여 모든 엔지니어가 앱 개발에 참여할 수 있도록 했습니다.
무엇보다도 팀원들이 기술과 직무의 경계를 넘어서 제품 개선에 몰입했던 것이 주요했다고 생각합니다.

결과적으로 서비스 종료라는 성적표를 받았지만, 팀은 빠른 제품 출시 속도를 경험했고, 그 과정에서 작은 성공과 실패를 반복하며 성장했습니다.
이 경험이 앞으로 우리 팀이 더 나아가는 데 있어 큰 도움이 될 것입니다.

안녕, CHAAK!

CHAAK

2024년 회고

anyjava — Tue, 31 Dec 2024 23:56:34 +0900

2024년에서 2025년으로 넘어가고 있는 지금 올해를 기록으로 남기고자 컴퓨터 앞에 앉았다.

2년 만의 회고인데, 24년인 듯 23년부터인 듯 모르겠지만 우선 회고를 적어 보겠다.

1. Close 그리고 CHAAK

작년부터 합류한 Grandeclip에서는 신규 서비스를 만들고 있었다. 처음에는 비공개로 하다가 두어 번의 피봇팅을 거쳐서 CHAAK 이란 이름의 SNS를 오픈하게 되었다. SNS라는 도메인에 처음 접근하여 그럴싸한 계획으로 신나게 두들겨 맞았던 한 해가 되었던 것 같다. 다음 문장을 되네이며 마음을 다시 잡는다.

"잘될 때까지 안 될 것이다."

기술적인 내용은 간단하게는 다음과 같다. 내 커리어에서는 맘시터에서 데이터엔지니어링여역에 이어 클라이언트 개발에 직접 참여하고 생태계를 조금이라도 알게 되었다.

- Typescript NestJS + Prisma 조합으로 Backend 를 만들었다.

- Flutter 를 이용해서 iOS / AOS 앱을 만들었다. ( AppStore | PlayStore )

2. 얼리스테이지 경험

배달의민족은 시리즈 C에 합류를 했다. 그리고 맘편한세상은 시리즈 A -> B 단계를 경험을 했다. 그래서 극초기의 경험을 해보면 좋겠다고 생각을 하고 있던 차에 좋은 기회가 되어 Grandeclip에 합류하게 되었다. BM 성숙하고 제품팀의 조직규모가 10명 이상이 넘는 조직에서 매니징과 극초기의 원팀을 운영하는 것은 완전히 다른 경기장이었다. 내가 이때까지 했던 조직을 운영했던 방식이 무조건적으로 해답이 되지는 못했다.

하루하루가 문제가 바뀌면서 우선순위가 바뀌었고, 한 명 한 명 고객의 반응을 보면서 빠르게 배포를 이어 나가야 했었다. 안정성보다는 빠른 속도가 최우선이 되어야 했었다. 나는 코파운더가 아니었지만, 만약 내가 파운딩 멤버였다면 더 빠른 개발 속도를 지향했을지도 모른다. 그러면서 나의 개발 철학이 자연스럽게 정리가 되기도 했었다. 나는 오로지 문제 상황을 바르게 판단하고 그 문제를 해결하는데 모든 에너지를 쏟는 게 맞다고 생각이 들었다. 그 문제는 당연히 기술적인 문제를 벗어나는 문제가 된다. 초기이면 초기일수록 기술적인 문제는 후 순위가 되었다.

지금 하고 있는 이 경험이 미래에 내 모습에 분명하게 도움이 되는건 지금에서도 확신을 할 수 있다.

3. 건강

올해부터 건강을 챙기기 시작했다. 내가 존경하시는 분이 항상 운동 하는 이유가 "나이 들어서도 두발로 걷기 위해서"라고 말씀하셨는데, 올해의 나도 그 목표를 위해서 운동을 꾸준하게 시작했다. 3월부터 월/수/금 새벽 수영을 시작했다. 출석률은 정확하게 측정은 하지 않았지만, 80% 이상은 새벽 수영을 다녀왔다. 그리고 화/목 점심시간에는 필라테스를 다니고 있다. 필라테서는 2년 넘게 꾸준하게 하고 있는 운동이라서 이제는 필라테스를 하지 않으면 몸에서 뻐근함이 몰려온다. 내년에도 꾸준하게 운동을 하고 싶다.

4. 멘토링

아산나눔재단 / 인프런 등을 통해서 소소하게 멘토링을 진행을 했었다. 올 한 해 인프런을 통해서만 53건을 진행을 했다. 많은 개발자분들을 만나서 대화를 나누고 도움을 드렸던 것 같다. 좋은 소식을 전해오는 멘티분들도 있었는데, 그럴 때마다 보람을 느끼게 되었다. (X에서 바이럴 된 글) 하반기로 접어들면서 회사일이 바빠져서 멘토링 비중을 확 줄이게 되었는데, 멘토링을 통해서 새로운 분들도 많이 만나고 나에게도 한 해 동안 긍정적인 영향을 미쳤던 것 같다.

글을 적고 있는 중에 25년이 밝아 왔다.

회고는 치열하게 살아 왔던 한 해를 머릿속에서 흐릿해지는 기억을 잡아두기 위해서 적게 되는 것 같다.

내년에는 더 좋은 일들과 행복한 이야기들이 회고 내용에 가득했으면 한다.

아듀! 2024!

작은 성공 경험을 해보는 것.

anyjava — Wed, 20 Nov 2024 08:48:14 +0900

최근에 가장 생각을 많이 하는 고민이다. 성공 경험을 해본 사람과 안 해본 사람의 차이는 당면한 어려운 문제에 대해서 대처하는 방법이 다르다고 생각한다. 지금 이 문제를 해결 할 수 있는 문제인가? 아니면 해결 할 수 없는 문제인가? 작은 성공 경험들 그리고 큰 성공 경험을 가지고 있다면, 어려운 문제가 눈 앞에 닥쳐도 "하면 돼지"라는 마인드로 그 문제를 해결해 나갈 수 있다고 생각한다.

대학 사물놀이 동호회에서 대회 연습을 하고 있었다. 상모를 돌리면서 각 악기를 쳐야하는 고난도 미션이 주어졌었다. 연습을 하다가 대회를 준비하는 선배가 나에게 벚꾸수(상모 수)를 해보는게 어떻냐고 제안을 했다. 그 때 나의 실력은 상모를 이제 막 돌릴 수 있는 단계였는데, 훨씬 더 어려운 제안이 왔었다. 그 제안 이 후 저녁 연습때 마다 이 악물고 연습을 했고, 결과는 선배에게 실력도 인정 받고 대회에 나가서 1등을 하게 되었다. 이 경험은 내가 노력하면 안되는게 없다는 자신감을 가지게 해주었다.

일을 할 때도 마찬가지다. 페어코딩으로 개발을 하면 흔히 개발 속도가 느려진다고 한다. 하지만 나의 팀장님은 이미 경험해 보았고, 그 경험을 바탕으로 우리팀에게 일정이 빡빡한 프로젝트에서도 페어코딩으로 개발을 꿋꿋하게 진행하셨다. 주변에서 걱정어린 시선으로 팀을 바라 보았지만, 우리 팀은 프로젝트를 성공적으로 해 낼 수 있었다. 이 경험도 나에게는 일에 대한 엄청난 자신감을 가질 수 있게 도움이 되었다.

어두운 미래에 대해서 비관적으로 걱정만 하는게 아니라. 할 수 있다. 해보자라는 기세를 가지는게 중요하다고 생각한다. 그러면 안될 일 도 되게 할 수 있고, 해내고 나면 엄청난 성취감을 맞 볼 수 있을 것이다. 지금 눈 앞에 어려움이 있다면, 걱정 하지말고 그냥 해보자. 하다 보면 할 수 있게 된다.

스프링 테스트에서 @Transactional 사용에 대한 의견들

anyjava — Mon, 4 Mar 2024 09:35:30 +0900

재민님, 향로님, 토비님이 스프링 테스트에 대한 @Transactional 사용에 대한 의견들을 남겨주셨다. 모두 너무 정성들여 적으글들이라 한번에 모아서 읽어 보시면 Spring Test 시 @Transactional 사용에 대한 다양한 의견을 통해 DB 를 이용한 통합테스트에 대한 시각이 넓힐수 있을 것이다. 저도 몰랐던 사실을 많이 알게 되어 블로그와 영상으로 공유해주신 분들에게 감사한 말씀을 드립니다. :)

재민님의 '테스트에서 @Tansactional을 사용해야할까'
https://youtu.be/PDhN6aiF7QQ?si=4Go7aqNAAL9wGrY8
향로님 '테스트 데이터 초기화에 @Transactional 사용하는 것에 대한 생각'
https://jojoldu.tistory.com/761
토비님의 '테스트가 관리하는 트랜잭션 - 향로 님의 @Transactional 글을 읽고'
https://tobyepril.tistory.com/m/8

간단하게 제의견을 적어보면,

나도 통합테스트 보단 Unit Test 에서 더 시간을 할애하는 편이고 Framework 에 의존하지 않는 테스트 코드를 작성하려고 한다. (최근 Spring -> NestJS 넘어오면서 더 그렇게 느끼기도 함)

토비님의 글 중

"트랜잭션 자체에 대한 테스트는 매우 어렵고 번거롭고 때론 불가능하기 때문이다. 어떤 기술의 트랜잭션 관리 기능을 테스트하는 거야 적절한 학습 테스트를 만들면 된다."

부분이 가장 공감된다.

여러분의 의견은 어떠신가요? :)

자바에서 클래스를 활용한 사용자 정의 타입으로 코드 가독성과 신뢰성 높이기

anyjava — Tue, 20 Feb 2024 20:51:43 +0900

자바나 다른 새로운 프로그래밍 언어를 배우면서 사용자 정의 타입을 만들고 사용하는 기법을 배우게 됩니다.

자바에서 가장 쉽게 사용할 수 있는 것은 클래스(class)입니다. 자바는 모든 것이 클래스로 구성되어 있습니다.

그렇다면, 사용자 정의 타입(이하 클래스)을 어떻게 활용할 수 있을까요?

자바의 클래스를 사용하여 어떻게 신뢰성 있는 프로그램 코드를 작성할 수 있을까요?

이제 이러한 개념을 실제 코드 예제를 통해 더 자세히 살펴보겠습니다.

계좌번호, 전화번호, 카드번호 등은 실무에서 반드시 암호화하여 데이터베이스에 저장해야 하는 정보입니다. 따라서 개발 시 많은 개발자들이 평문으로 된 계좌번호 등을 암호화하여 사용하게 됩니다.

아래 코드에서는 cardNumber가 암호화된 상태인지, 복호화된 상태인지 알기 어렵습니다. API로부터 정보를 받아온 경우 이 구분이 더욱 어려워질 수 있습니다.

class PaymentService {
  public void pay(String cardNumber, int payAmount) {
    // ...
  }
}

저 역시 실무에서 비슷한 경험을 했습니다. 암호화된 값을 기대하며 사용했으나 실제로는 평문이었기 때문에 런타임 오류를 겪었습니다.

『클린 코드(Clean Code)』라는 책에서는 코드를 읽는 시간 대비 작성하는 시간의 비율이 대략 10:1을 넘는다고 언급합니다.

그래서 명확한 타입을 이용해서 코드를 읽는 사람이 빠르게 인지할 수 있게 하자.

예를 들어, String value = "100"보다는 int value = 100과 같이 정확한 타입을 사용하는 것이 코드를 읽기에 더 편리하며, 이로 인해 사칙연산을 적용할 수 있다는 기대감이 자연스럽게 생깁니다.

자 그럼 다음 예제 코드를 보시죠. (전체코드) (테스트코드)

package net.anyjava.blogcode.ecrypt;

import org.springframework.stereotype.Component;

import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
import javax.crypto.spec.IvParameterSpec;
import java.util.Base64;

@Component
public class CardNumberEncryptor {
    private final String key = "1234567890123456";
    private final String iv = key.substring(0, 16); // 16byte

    // AES 암호화
    EncryptCardNumber encrypt(PlainCardNumber plainCardNumber) {
        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
            SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), "AES");
            IvParameterSpec ivParamSpec = new IvParameterSpec(iv.getBytes());
            cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivParamSpec);

            byte[] encrypted = cipher.doFinal(plainCardNumber.getPassword().getBytes("UTF-8"));
            return EncryptCardNumber.of(Base64.getEncoder().encodeToString(encrypted));
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    // AES 복호화
    PlainCardNumber decrypt(EncryptCardNumber encryptedData) {
        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
            SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), "AES");
            IvParameterSpec ivParamSpec = new IvParameterSpec(iv.getBytes());
            cipher.init(Cipher.DECRYPT_MODE, keySpec, ivParamSpec);

            byte[] decodedBytes = Base64.getDecoder().decode(encryptedData.getPassword());
            byte[] decrypted = cipher.doFinal(decodedBytes);
            return PlainCardNumber.of(new String(decrypted));
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

위 코드에서 주목해야할 부분은 파라미터와 반환 타입으로 String 대신 사용자 정의 클래스인 PlainCardNumber와 EncryptCardNumber를 사용합니다. 이 컴포넌트를 통해 암호화와 복호화를 진행함으로써, 사용자는 타입을 통해 카드 번호가 암호화되었는지 여부를 쉽게 구분할 수 있습니다.

사용자 정의 타입을 정의해 사용하면, 테스트의 용이성이 향상되고 코드의 가독성도 더욱 높아집니다.

또한, 계좌번호나 회계시스템을 다룰 때, 공급가액과 부가세는 항상 함께 다뤄지므로, long saleAmount, long vatAmount로 파라미터를 전달하기보다는, saleAmount와 vatAmount를 속성으로 갖는 Revenue라는 클래스를 정의해 사용하는 것이 좋습니다.

결론적으로, 사용자 정의 타입을 활용함으로써 우리는 코드의 가독성과 신뢰성을 높이고, 보다 효과적으로 데이터를 관리할 수 있습니다. 작은 단계부터 시작하여 이러한 접근 방식을 점진적으로 적용해보세요.

코드 신뢰성 향상: 올바른 데이터 타입 사용하기! (DateType편)

anyjava — Sun, 4 Feb 2024 17:44:13 +0900

혹시 String createdAt 로 선언하지 사용하지 않으신가요?

DateTimeParseException 으로 고통받고 있지 않으신가요?

하지만 String 타입으로 데이터를 처리하고 있다면 버그나 Exception 이 발생하는 코드를 작성할 확률이 높아진다.
강타입 언어를 사용하는 장점을 전혀 활용하고 있지 못하기 때문에 적절한 타입을 사용하는 게 중요하다.

왜 도움이 되는지는 찬찬히 설명해 보려고 한다.

java 표준 API 사용되는 타입을 사용한다면 데이터에 대한 유효성 검증을 library level (정확히는 Type 이 생성되는 시점) 에서 검증이 된다. Exception Handling이나 validation check를 코드를 작성하는 개발자가 직접 하지 않아도 된다는 뜻이다.
그렇다면 “9999-99-99” 라는 String type 이 있을 경우, 이 변수로 오늘부터 몇이 남았는지 를 구현하게 된다면 어떻게 될까?

바로 아래와 같은 예외를 마주하게 될 것이다.

java.time.format.DateTimeParseException: Text '9999-99-99' could not be parsed: Invalid value for MonthOfYear (valid values 1 - 12): 99

	at java.base/java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:2023)
	at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1958)
	at java.base/java.time.LocalDate.parse(LocalDate.java:430)
	at java.base/java.time.LocalDate.parse(LocalDate.java:415)

적적한 Exception 처리를 하지 않았다면, 서비스에서 에러가 발생할 것이다. 예외가 발생한 라인에 validation 코드를 적절히 처리했다고 해도, String type의 날짜 문자열이 코드에 존재하는 한 언제 가는 또 발생할 수 있다. 그리고 API request의 parameter 나 request body로 데이터가 전달되었다면, 디버깅을 하고 어떤 API 요청이 왔는지 찾는데 시간이 걸릴 것이다.

(참고로 Json 은 Number, boolean, String type 만 표현이 가능하다)

그렇다면, 처음부터 LocalDate type 을 사용하면 어떻게 될까?

WebApplication을 개발하는 상황에서 데이터가 생성되는 상황은 외부 시스템에 의존된 상황이다.
좀 더 쉽게 설명을 한다면, HTTP API request 시 파라미터로 전달받거나, DB에서 조회해 올 수가 있다.

데이터 베이스의 경우에는 Date type 이 있기때문에 해당 타입의 칼럼을 사용하면 좋다.
그렇다면 HTTP request 에서는 어떻게 처리할 수 있을까?

LocalDate createdAt 으로 타입을 선언한다면 쉽게 반영이 된다. 그렇게 사용한다면 Framework 혹은 언어 Level에서 타입의 안정성을 보장해 준다.
하지만 현실세계는 그렇게 호락호락하지 않다.

"2000.01.01" "2000/10/01" 과 같이 다양한 문자열형태로 인터페이스를 하고 있을지도 모른다.

아래는 예제 코드 이다.

package net.anyjava.blogcode.controller;

import org.springframework.format.annotation.DateTimeFormat;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import java.time.LocalDate;

@RestController
public class LocalDateController {

    @GetMapping("/localdate-default")
    public LocalDate localDateDefault(@RequestParam LocalDate createdAt) {
        return createdAt;
    }

    @GetMapping("/localdate")
    public LocalDate localDate(
            @DateTimeFormat(pattern = "yyyy.MM.dd")
            @RequestParam LocalDate createdAt) {
        return createdAt;
    }
}

위 Controller 코드에 대한 테스트 코드는 GitHub에서 확인하길 바란다.

위 코드처럼 내가 운영하는 시스템에서 Input 이 되는 지점부터 정확한 타입을 사용한다면, 에러상황을 사전에 예방할 수 있다.

그렇지 않고 String type의 date 형태의 문자열을 시스템에 전반적인 영역에서 사용된다면 언제든지 DateTimeParseException의 고통에서 자유로울 수 없다.

강타입언어를 사용한다면, Stirng에 타입에 "2022-01-01", "Y", "N", "10.9"처럼 동적 타입처럼 사용하지 않길 바란다. 나도 개발하면서 4,5년 차에 알게 되었다. 이제부터라도 제대로 된 타입을 사용하기 위해 노력해 보길 바란다.

이번에는 간단하게 Language에서 제공하는 기본 타입에 대해서 설명을 했다.

다음번에는 우리가 직접 만드는 Class를 어떻게 적절하게 타입을 사용할 수 있게 되는지 글을 작성해 보려고 한다.

UnitTest 로 빠른 피드백 얻기 - Prisma 버젼 Update 사례

anyjava — Tue, 12 Dec 2023 08:00:02 +0900

Prisma의 주요 단점 중 하나는 JOIN 절이 지원되지 않았던 것이었다. 이 문제는 최근 5.7 버젼에서 FeaturePreview로 추가되었고, 이 소식을 듣고 반가운 마음에 즉시 적용을 시작했다. 이렇게 고민 없이 적용할 수 있는 이유는 바로 테스트에 있다.

일반적으로 대부분은 주요 라이브러리의 버전 업데이트를 하지 않거나, 할 경우에도 매우 보수적으로 진행하는 경향이 있다.

그럼 어떻게 진행했는지 진행과정을 공유해 보겠다.

1. 패키지 업데이트 & 전체 테스트 수행

패키지 매니져를 통해서 업데이트를 하고 모든 테스트를 수행했지만, 실패하는 테스트 케이스는 없었다. 일단은 안심이다. 아직 추가된 Feature를 사용하지 않아서 쉽게 성공했을 수도 있다.

2. 기능 리팩토링

이제 가장 중요한 Repository 를 구현체를 새롭게 추가된 Join을 사용할 수 있도록 리팩토링을 해나갔다. 첫 번째 케이스에서 무난이 통과했고 다음 케이스를 작업을 진행했지만, 에러에 직면하게 되었다.

Inconsistent column data: Unexpected conversion failure from String(2023-12-06T17:43:39.515686+00:00) to DateTime. Reason: $trailing input

Github Issues 에 검색해 봤더니 역시 이미 버그 리포팅되어 있었다. 해당 개발자가 버그를 인지하였고 NativeType 들에 대한 케이스를 놓쳤다고 코멘트를 했다. (이슈 링크 참고)

3. 테스트 코드의 빠른 피드백

나는 테스트 코드를 통해서 실제 프로던션 혹은 개발서버에 코드를 배포하지 않고도 라이브러리의 버젼업과 새로운 기능에 대해서 테스트를 진행할 수 있었다. 만약 테스트코드가 없었다면? 코드를 추가하고 Local에서 API 서버를 기동 하고 데이터 셋업 후 API 호출하고 문제가 발생했는데, 어떤 부분이 문제인지 파악하고 있었을지도 모른다.

하지만 테스트 코드를 통해서 극도로 좁은 범위인 Repository 코드만 수행했으며 문제가 발생하더라도 테스트 범위가 적기 때문에 고려 대상이 적다. 그리고 무엇보다 코드 변경후 수초 안에 다시 테스트 가능하며, 심지어 디버깅도 가능해진다.

우리가 겪는 SpringBoot 1.x 버젼이라 어려워요. Java 버전이 너무 낮아요. 관련된 문제들도 테스트를 작성하면서 조금씩 커버리지를 올리다 보면 과감하게 버전업 할 수 있는 날이 올 것이다.

테스트 코드와의 첫 만남 : 시작과 성장

anyjava — Mon, 11 Dec 2023 08:00:24 +0900

ChatGPT 로 작성된 이미지

최근에 작성한 테스트 관련 글이 조회수가 상당히 높았다.
그러나 처음부터 테스트 코드를 잘 작성했던 것은 아니었다.
이번 기회에 과거를 돌아보며 어떻게 공부했는지 나누고자 한다.

나도 'TDD by Example'이라는 책을 통해 테스트와 처음 만났다. 회사에서 진행한 스터디에 참여하며 테스트에 대한 이해를 높였다.
테스트가 프로그램의 스펙이라는 개념은 새롭게 다가왔다. Java에서는 Junit과 Test 키워드에 익숙했지만, Ruby나 다른 언어 및 테스트 프레임워크에서는 'Spec'을 사용하는 것도 흥미로웠다.

또한, 테스트 코드에 능숙한 동료가 복잡한 부가세 계산을 위한 테스트 케이스를 작성하며 그 실행 과정을 보여주었는데, 이는 매우 인상 깊었다.
당시 CTO께서는 빠른 피드백을 통해 즐거운 개발 환경을 조성한다고 말씀하셨는데, 이러한 변화를 실제로 피부로 느꼈던 것이다. (사실 그당시에 느꼇기 보단. 지금 되돌아 보니 그랫던것 같다. ㅎㅎㅎ)

그 경험 이후, 나는 테스트 코드에 깊이 몰입하게 되었다. 첫 프로젝트에서 테스트 코드 작성을 시도했는데, 이는 내가 존경하는 시니어 개발자와 함께한 매우 만족스러운 작업이었다. 하지만, 나는 테스트 코드에 너무 집중하여 프로젝트 일정이 2주나 지연되는 상황에 이르렀다.

지금 생각해보니, 주니어 개발자로서 자주 저지르는 실수, 바로 주화입마에 빠져 테스트 코드에 과도하게 몰두했던 것 같다. 당시 함께했던 선배 개발자는 참을성을 가지고 나를 기다려 주셨고, 그 덕분에 많이 배울 수 있었다. 그 시간들을 떠올리면 지금도 미안함과 감사함이 교차한다. 프로젝트를 마무리 짓고, 늦은 밤까지 이어진 퇴근길의 대화와 그때의 공간, 분위기는 아직도 선명하게 떠오른다.

설계에 대한 고민은 언제나 필요한 일이죠. 훌륭한 설계를 위해 꾸준히 고민하고 리팩터링하는 것이 중요하다고 생각해요.

첫 시도에 완벽함을 기대할 수는 없다. 테스트를 하나씩 작성하며 배우고, 실패를 경험하며, 깨달음을 얻으면서 어제보다 더 나은 코드를 만들어 나가는 것이다.

결론적으로, 테스트 코드를 완벽하게 작성하고 TDD로 개발한다고 자신 있게 말할 수는 없다. 여전히 부족함을 느끼고 있고 그래서 나는 테스트 추종자라고 소개할 뿐이다.

참고로 내가 7년전에 작성했던 글을 공유한다.

https://techblog.woowahan.com/2504/

첫 Java 프로젝트의 생생한 후기 | 우아한형제들 기술블로그

{{item.name}} 이번에 처음으로 Java 8 + Spring Boot + JPA 를 이용하여 프로젝트를 진행 하였는데, 그 때 느꼈던 점을 공유 하고자 합니다. 첫 자바 프로젝트 시작과 기대 저는 이전 회사에서는 Java 를 사

techblog.woowahan.com

성공한 삶

anyjava — Tue, 28 Nov 2023 08:37:54 +0900

사진: Unsplash의Edu Lauton

성공이란 당신 삶의 목 적을 깨닫고, 당신의 잠 재력을 전부 발휘하고, 남들에게 도움이 되는 씨를 뿌리는 것이다.

오늘 아침 알라미 앱에서 기상미션을 하다가 알게 된 글귀이다. 성공을 어떻게 정의해야 할까?

오늘 본 이 내용이 가슴을 울리게 만드는 내용이라 내 생각을 적어보려 한다.

삶의 목적

나의 삶의 목적은 재밌는 일을 하는 것이다. 시기에 따라 행복한 삶일 때도 있었지만, 바뀐다고 무슨 문제가 있겠나. 삶의 대부분을 집과 회사에서 보내는데, 가족과의 행복, 일터에서 재밌게 보내려고 한다.
삶의 목적을 고민해 보라. 그렇다면 선택에 있어서 더 쉬워진다.

잠재력을 전부 발휘

나의 잠재력의 끝은 어디일까. 나의 잠재력의 한계를 알고 눈을 감을 수 있으려나? 나는 아직도 나의 잠재력이 있다고 판단하고, 잠재력을 발휘하기 위해 최선울 다하고 있다. 어제의 나보다 더 나은 오늘의 내가 멋지다고 생각한다.

남들에게 도움이 되는 씨앗

가장 마음에 와 닫는 문구였다. 최근에 집중하고 있는 키워드인데, 남들에게 도움이 되는 씨앗을 어떻게 뿌릴까 고민중이다.
나름 카카오톡 오픈챗에서 개발자 무료 고민 상담방도 운영하고 있다.
그리고 같이 일하는 동료들에게도 촤대한 도움이 되고 싶다. (꼰대와 지식의 나눔 사이에 잘 위치해야겠지만…ㅎㅎ)

마지막으로 자주 글을 적으려고 한다. 나의 지식을 온라인 공간에 올려두면 필요한 사람들이 쉽게 접근할 수 있게 된다. 대부분이 아는 내용이라도 누군가에게는 분명히 도움이 될 것이다.

여러분도 성공한 삶을 살고 계신가요?

후회하지 않기

anyjava — Tue, 21 Nov 2023 08:22:15 +0900

예전 메모했던 내용을 소개해보고자 한다.

여러 가지 일로 바쁠 때는 작은 것 때문에 큰 것을 잃을 수 있습니다. 80세가 되어 인생을 뒤돌아볼 때 1994년도 1년 중 하필 왜 보너스 받는 시기를 앞두고 그 순간에 사직서를 냈을까 하고 후회하지는 않을 겁니다. 나중에 나이가 들어 중요하게 생각할 일은 그런 것들이 아니지요. 동시에, 인터넷이 세상을 바꿀 혁명적 사건임을 알면서도 여기에 뛰어들지 않는다면 정말 후회하게 될 것이라 믿었습니다. 이러한 각도에서 생각해보니…… 결정을 내리기가 매우 쉬워졌어요."

사진: Unsplash의Vladislav Babienko

배민을 퇴사했을 때 배민을 퇴사한걸 후회하지 않냐고 묻는 사람이 많았었다. 그때마다 위 내용을 이야기해 준다.

지나간 건 지나간 것일 뿐 나의 선택을 올바른 선택을 만들기 위한 책임은 이제 나의 몫이라 생각한다.

지금 내가 할 수 있는 것에 최선을 다하면 80세가 되었을 때 나의 인생 스토리가 완성되지 않을까?