So how will this extra debug logs affect the performance?

It affects the performance of the application as loggers are disc I/O calls (assuming you are writing to file system) and DEBUG log level is strictly NOT recommended for production environments.

Is there any automagical way of removing the log.debug() statements while deployment?

No, there is no magical way of removing the log.debug() statements, BUT when you set the logging level to INFO, then as long as you are NOT doing heavy computations while passing the parameters to the debug() method, it should be fine. For example, if you have logger level set to INFO and assume you have got the below two loggers in your code:

logger.debug(" Entry:: "); //this logger is fine, no calculations
//Below logger, you are doing computations to print i.e., calling to String methods
logger.debug(" Entry : product:"+product+" dept:"+dept);//overhead toString() calls

I recommend to use slf4j so that you can avoid the second logger computations overhead by using {} (which replaces with actual values using it's MessageFormatter) as shown below:

//Below logger product and dept toString() NOT invoked
logger.debug(" Entry : product:{} dept{}", product, dept);

One more important point is that with slf4j is just an abstraction and you can switch between any logging frameworks, you can look below text taken from here.

The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at deployment time.

You can wrap your "debug" statements in a call to isDebugEnabled()

if (log.isDebugEnabled()) {
    log.debug("my debug statement");
}

Likewise, wrap your "info" statements in a call to isInfoEnabled() etc.

The idea behind doing this is that checking whether a logging level is enabled is an inexpensive (fixed cost) operation. The cost to generate the statement that is being logged will vary depending on what you are doing.

You can minimize this by how you write your logging statements. If you write

Object a = .... 
log.debug("I have an a: " + a);

then regardless of the logging framework you're using the argument has to get evaluated before the debug function gets run. That means that even if you're at INFO level, you're paying the performance cost of calling toString on a and building the argument string. If you instead write e.g. (depending on what formatting your logging framework uses, this works in log4j and slf4j)

log.debug("I have an a: {}", a);

you don't pay this cost but only the cost of the logger checking whether or not you're in DEBUG mode - unless you need it you don't pay for the argument evaluation.

The other thing to check is that you're buffering output (again, in slf4j, there are buffering appenders) which will minimize the writes.